I tested mock several ways 

1) Inside a Mageia8 system
a)    with mock I can build for Mageia-8-armv7hl or aarch64 
it creates inside the bootstrap :
/var/lib/mageia-8-armv7hl-bootstrap/root/var/cache/dnf/mageia***/packages
and 
/var/lib/mageia-8-armv7hl-bootstrap/root/var/cache/dnf/mageia***/repodata

These directories are then copied to 
/var/lib/mageia-8-armv7hl/root/var/cache/dnf/


b) in this same Mageia8 system
with mock I can't build for Mageia-cauldron-armv7hl or aarch64
the cache/dnf/ remains empty !


2) Inside a Mageia9 system
no way to create any arm arches rpm for Mageia8, for Mageia9 or for Cauldron

same kind of message for all of them related to util.py: 446 

 Problem 1: conflicting requests
- nothing provides python3-libcomps >= 0.1.8 needed by python3-dnf-4.6.0-1.mga8.noarch from mageia
- nothing provides python3-libdnf >= 0.57.0 needed by python3-dnf-4.6.0-1.mga8.noarch from mageia
 - nothing provides python3-libmodulemd >= 2.9.3 needed by python3-dnf-4.6.0-1.mga8.noarch from mageia
- nothing provides python3-rpm >= 4.14.0 needed by python3-dnf-4.6.0-1.mga8.noarch from mageia
- nothing provides deltarpm needed by python3-dnf-4.6.0-1.mga8.noarch from mageia
- nothing provides python3-gpg needed by python3-dnf-4.6.0-1.mga8.noarch from mageia
- nothing provides python(abi) = 3.8 needed by python3-dnf-4.6.0-1.mga8.noarch from mageia
- nothing provides python3-hawkey >= 0.57.0 needed by python3-dnf-4.6.0-1.mga8.noarch from mageia

Problem 2: conflicting requests
- nothing provides python3-dbus needed by python3-dnf-plugins-core-4.0.19-1.mga8.noarch from mageia
- nothing provides python(abi) = 3.8 needed by python3-dnf-plugins-core-4.0.19-1.mga8.noarch from mageia
- nothing provides python3-hawkey >= 0.46.1 needed by python3-dnf-plugins-core-4.0.19-1.mga8.noarch from mageia
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)


3) to conclude
A)
There seems to be a problem with the version of python3 used by Mageia9 and Cauldron (and embedded inside mock for Mageia9 and Cauldron) when trying to build for arm arches with mock inside a Mageia8 system

this problem doesn't exist inside Mageia8 when building 
for Mageia8 arm arches with mock

B) mock doesn't work at all inside Mageia9 to build rpm for arm arches
for Mageia8 Mageia9 Cauldron


The title of this bug may perhaps be changed since the problem seems to come from the last version of  Python inside Mageia9 or Cauldron
And it apparently doesn't concern the infrastructure but a package (Python)

I will attach a root.log from mock for Mageia-9-armv7hl inside Mageia9

Created attachment 14205 [details]
root.log from mock showing the problem with Python

root.log created by mock when trying to build a rpm for mageia-9-armv7hl
inside a Mageia9 system

we get the same kind of root.log when trying to build a rpm with mock 
for mageia-8-armv7hl or aarch64 inside a Mageia9 system

we get the same kind of root.log when trying to build a rpm with mock
for mageia-Cauldron-armv7hl or aarch64 inside a Mageia9 system


NB 
no such a problem happens when building a rpm with mock for mageia-8-armv7hl or aarch64
inside a Mageia8 system !!!

The problem seems related to the fact that 

1) When mock functions inside a Mageia8 system

to create rpm for Mageia8 arm arches 

/var/lib/mock/mageia-8-armv7hl-bootstrap/root/var/cache/dnf/ is filled with repodata
and mock works normally

BUT
to create rpm for Mageia-cauldron arm arches 

/var/lib/mock/mageia-8-armv7hl-bootstrap/root/var/cache/dnf/ is empty
and mock can't find some python3-* rpms  (even if they are really in the repo

2) When mock functions inside a Mageia9 system

to create rpm for arm arches for Mageia8 Mageia9 or Cauldron

/var/lib/mock/mageia-*-armv7hl-bootstrap/root/var/cache/dnf/ is empty
or
 /var/lib/mock/mageia-*-aarch64-bootstrap/root/var/cache/dnf/ is empty

and mock aborts ! complaining of missing python3-*


That's definitively a problem appearing with mock inside Mageia9 system (or Cauldron) when creating rpms for arm arches 

this problem doesn't exist for mock inside Mageia8 system when creating rpms for Mageia8 arm arches but does exist now to create rpms for Mageia-Cauldron arm arches

NB In 2021 and 2022 I could use mock inside a Mageia8 system to create rpms for Mageia Cauldron (aka Mageia9) arm arches (I often used it before updating rpms that I maintain, to test if they could be built !  and it worked !)

Has something changed in the way metadata are written in Mageia9 ?

An other track to follow :

Is there something wrong in yum-utils (or dnf-utils that has replaced it in Cauldron) or in dnf-plugins-core  inside Mageia9 and Cauldron

Mock was OK for arm arches inside a Mageia8 system
with yum-utils-4.0.19-1.mga8.noarch.rpm 
and dnf-plugins-core-4.0.19-1.mga8.noarch.rpm 


But
Mock is NOT OK for arm arches inside a Mageia9 system
with yum-utils-4.3.1-1.mga9.noarch.rpm
and dnf-plugins-core-4.3.1-1.mga9.noarch.rpm
or
 with dnf-utils-4.4.3-1.mga10.noarch.rpm
and dnf-plugins-core-4.4.3-1.mga10.noarch.rpm

a last track :
python-backoff 2.2.1 has been added as a dependency of mock 5.1

Has it problem to access to arm arches repodata ?

The worst thing is a considerable amount of components related that are outdated dnf,mock, mock-core-configs-

in Mageia9 updates

mock is 5.1.1 
mock-core-configs 39.1
they are quite up to date

in Mageia9 core
dnf is 4.14 it's one year old 
maybe needs to be updated to 4.18.1 same as for Cauldron

There's perhaps some incompatibility between a recent mock and an old dnf ?

(In reply to Philippe Didier from comment #8)
> in Mageia9 updates
> 
> mock is 5.1.1 
> mock-core-configs 39.1
> they are quite up to date

https://github.com/rpm-software-management/mock/releases/tag/mock-core-configs-39.3-1

https://github.com/rpm-software-management/mock/releases/tag/mock-5.2-1
> 
> in Mageia9 core
> dnf is 4.14 it's one year old 
> maybe needs to be updated to 4.18.1 same as for Cauldron
> 
> There's perhaps some incompatibility between a recent mock and an old dnf ?

About this, the errors include this message

ERROR: Command failed: 
 # /usr/bin/dnf-3 --installroot /home/katnatek/mock/mageia-9-aarch64-bootstrap/root/ --releasever 9 --setopt=deltarpm=False --setopt=allow_vendor_change=yes --allowerasing --disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock install python3-dnf python3-dnf-plugins-core

Don't know if dnf-3 is used for the others chroots because the command not is part of the messages in the successful builds

I have done some more investigations

I have built dnf-4.18.1
I have built dnf-plugins-core-4.4.3
I have built libdnf-0.72.0
and installed all the rpms created

then
I have built mock 5.2 and installed it with mock-filesystem, mock-lvm, mock-scm 
I have built mock-core-configs 39.3 and installed it

Then I use all this to build with mock 
(after having installed in mock the dnf stuff)

Building a new rpm for i586 or x86_64 is OK


But building for arm arches aborts (even if I install in mock the updated dnf stuff)

The most astonishing is in the root.log :

DEBUG util.py:446:  Error: 
DEBUG util.py:446:   Problem 1: conflicting requests
DEBUG util.py:446:    - nothing provides python3-libcomps >= 0.1.8 needed by python3-dnf-4.14.0-1.mga9.noarch from mageia
DEBUG util.py:446:    - nothing provides python3-libdnf >= 0.66.0 needed by python3-dnf-4.14.0-1.mga9.noarch from mageia
DEBUG util.py:446:    - nothing provides python3-libmodulemd >= 2.9.3 needed by python3-dnf-4.14.0-1.mga9.noarch from mageia
DEBUG util.py:446:    - nothing provides python3-rpm >= 4.14.0 needed by python3-dnf-4.14.0-1.mga9.noarch from mageia
DEBUG util.py:446:    - nothing provides deltarpm needed by python3-dnf-4.14.0-1.mga9.noarch from mageia
DEBUG util.py:446:    - nothing provides python3-gpg needed by python3-dnf-4.14.0-1.mga9.noarch from mageia
DEBUG util.py:446:    - nothing provides python(abi) = 3.10 needed by python3-dnf-4.14.0-1.mga9.noarch from mageia
DEBUG util.py:446:    - nothing provides python3-hawkey >= 0.66.0 needed by python3-dnf-4.14.0-1.mga9.noarch from mageia
DEBUG util.py:446:   Problem 2: conflicting requests
DEBUG util.py:446:    - nothing provides python3-dbus needed by python3-dnf-plugins-core-4.3.1-1.mga9.noarch from mageia
DEBUG util.py:446:    - nothing provides python(abi) = 3.10 needed by python3-dnf-plugins-core-4.3.1-1.mga9.noarch from mageia
DEBUG util.py:446:    - nothing provides python3-hawkey >= 0.64.0 needed by python3-dnf-plugins-core-4.3.1-1.mga9.noarch from mageia
DEBUG util.py:448:  (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Same errors even if now python3-dnf-4.18 is installed on my system and for mock

I will attach the root.log

Created attachment 14209 [details]
root.log with mock-5.2 and dnf updated to 4.18.1 and libdnf

NB
the updated dnf has been built with the cauldron patches

when I look inside the repo of 
https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/9/armv7hl/media/core/release/

The supposed missing python3 stuff is indeed present

and worse the log talks about python3-dnf-4.14.0-1.mga9.noarch when it's supposed to use python3-dnf-4.18.1-1.mga9.noarch

the reason is perhaps that mock can't  find the repodata to fill 
/var/lib/mock/mageia-9-armv7hl-bootstrap/root/var/cache/dnf/

when it can fill /var/lib/mock/mageia-9-x86_64-bootstrap/root/var/cache/dnf/


It begins to become an aporia

I just had the curiosity to look at the files in the core/repodata for each arch
inside distrib-coffee

i586 :     5 .gz files  from 2023-09-19 (september)
x86_64 :   5 .gz files  from 2023-09-19
armv7hl :  5 .gz files and 3 .zck files all of them from  2023-12-09 (december ?)
                  NB the appstream.xml file has only a .gz version

aarch64 :  3 .gz files and 3 .zck files from 2023-09-16

           the appstream.xml file has only .gz  version from 2023-12-09

(In reply to Philippe Didier from comment #12)
> when I look inside the repo of 
> https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/9/armv7hl/
> media/core/release/
> 
> The supposed missing python3 stuff is indeed present
> 
> and worse the log talks about python3-dnf-4.14.0-1.mga9.noarch when it's
> supposed to use python3-dnf-4.18.1-1.mga9.noarch
> 
> the reason is perhaps that mock can't  find the repodata to fill 
> /var/lib/mock/mageia-9-armv7hl-bootstrap/root/var/cache/dnf/
> 
> when it can fill /var/lib/mock/mageia-9-x86_64-bootstrap/root/var/cache/dnf/
> 
> 
> It begins to become an aporia

I don't know what you do, but this is what we have in the wiki https://wiki.mageia.org/en/Using_Mock#Using_packages_not_in_repositories

Do you have a copr with that packages to do a test?

Why don't those files from armv7hl  have not the same date of creation as the ones from i586 or x86_64 ? (december instead of september)

Why is there a mix of recent date (december) or original date (september) for aarch64 ?

Has somebody tried to rewrite the repodata files to verify if the problem of mock for arm arches comes from the original repodata files ?

Can a problem be created to mock by the duplicate of .gz and .zck files for 
primary.xml
others.xml
filelists.xml

(In reply to Philippe Didier from comment #15)
> Why don't those files from armv7hl  have not the same date of creation as
> the ones from i586 or x86_64 ? (december instead of september)
> 
> Why is there a mix of recent date (december) or original date (september)
> for aarch64 ?
> 
> Has somebody tried to rewrite the repodata files to verify if the problem of
> mock for arm arches comes from the original repodata files ?
> 
> Can a problem be created to mock by the duplicate of .gz and .zck files for 
> primary.xml
> others.xml
> filelists.xml

In the mail list thread, Pascal Terjan say something about rebuild repodata https://ml.mageia.org/l/arc/dev/2023-12/msg00055.html

(In reply to katnatek from comment #14)

> 
> I don't know what you do, but this is what we have in the wiki
> https://wiki.mageia.org/en/Using_Mock#Using_packages_not_in_repositories
> 
> Do you have a copr with that packages to do a test?

To build packages depending of new created packages not yet in the repos
I proceed with mock in 2 steps, as it is written in the wiki.

I create first the rpms that are dependencies then in a second time create the rpm depending on them (I already did this in the past for other packages depending on a new one not yet imported)

(In reply to katnatek from comment #16)

> 
> In the mail list thread, Pascal Terjan say something about rebuild repodata
> https://ml.mageia.org/l/arc/dev/2023-12/msg00055.html

I had not read this mail...

So it is not a problem with the repodata files

I will dig again, step by step

I finally did again what I had done
with mock for x86_64
I built libdnf dnf dnf-plugins-core mock mock-core-configs in that order using the spec from Cauldron adapted to the last versions of the sources
(installing the built rpms  inside mock when there were dependencies on them, before
running mock)

Then I installed all this stuff

I tested mock again to build a rpm for x86_64
It's OK

I tested mock again to build a rpm for i586
It's OK

but mock can't build anything for arm arches

I don't know if it is unable to emulate this arches even if it tries

"INFO: Unable to build arch aarch64 natively on arch x86_64. Setting forcearch to use software emulation."

"INFO: Unable to build arch armv7hl natively on arch x86_64. Setting forcearch to use software emulation."



or it it is unable to fetch the metadata :
in the console I get this

"No matches found for the following disable plugin patterns: spacewalk
Mageia 9 - armv7hl                         5.4 kB/s | 4.3 kB     00:00    
Mageia 9 - armv7hl - Updates              702  B/s | 1.5 kB     00:02    "

or
"No matches found for the following disable plugin patterns: spacewalk
Mageia 9 - aarch64                        5.6 kB/s | 4.3 kB     00:00    
Mageia 9 - aarch64 - Updates              2.0 kB/s | 1.5 kB     00:00  "


it is the same problem in the root.log
DEBUG util.py:448:  Mageia 9 - aarch64                                                                                                                                           5.6 kB/s | 4.3 kB     00:00    
DEBUG util.py:448:  Mageia 9 - aarch64 - Updates                                                                                                                                 2.0 kB/s | 1.5 kB     00:00    


I think there may be a problem because mock is trying to emulate the arm system but can't


What is surprising is that I didn't have this kind of problem with mock on my Mageia8 system :
I could test the build for all the arches before submitting to the BS the rpms I maintain

I will submit them blindly now, hoping they build on arm arches !

@katnatek

to conclude 
the problem is not inside the repodata for arm arches and it's not a problem of infrastructure

You may change the title of this bug report

it seems to be a problem of mock itself or libdnf dnf dnf-plugins-core mock-core-configs inside a Mageia9 system (even with those programs updated to their last sources)

Perhaps a problem with the software used for arm emulation ?

Nevertheless It would be useful to try to build with mock for arm inside a Cauldron x86_64 system : the emulation of arm will use the same versions of rpms for each arch

(In reply to Philippe Didier from comment #19)
I also noted that the "root" folder on bootstrap for aarch64 is incomplete

@ katnatek

I think we should open a new bug report for the mock rpm
This one was about infrastructure and we discovered that it's not a problem with the repodata files : it may be closed

the new report would be shorter and clearer now we have narrowed the problem

(nevertheless we could create a link to this bug in the new created one)

@ katnatek

I have just created a new bug report
https://bugs.mageia.org/show_bug.cgi?id=32620
since it's not an infrastructure problem  but more specifically a rpm problem

@ katnatek

I have just created a new bug report
https://bugs.mageia.org/show_bug.cgi?id=32620
since it's not an infrastructure problem  but more specifically a rpm problem

Should we mark this bug 32607 as a duplicate of 32620 ?

(In reply to Philippe Didier from comment #24)
> @ katnatek
> 
> I have just created a new bug report
> https://bugs.mageia.org/show_bug.cgi?id=32620
> since it's not an infrastructure problem  but more specifically a rpm problem
> 
> Should we mark this bug 32607 as a duplicate of 32620 ?

Not sure, close as invalid
I did want just change this of component, but you make the other report

Resolution: (none) => INVALID
Status: NEW => RESOLVED