Created attachment 14210 [details]
root.log from mock aborting for arm arch

Created attachment 14211 [details]
root log from mock succeeding for x86_64 arch

this root.log is here to compare what happens with a success with what happens when mock aborts shown by the previous root.log

PS
in my Mageia8 x86_64 system
I can build with mock rpms for Mageia Cauldron arm arches

but I can't inside my Mageia9 x86_64 system

Something wrong in Mageia9 ?
dnf ?
dnf-plugins-core ?
libdnf ?
mock ?
mock-core-configs ?

I have updated all of them to their last upstream sources for Mageia9
and tried again to build rpms in my Mageia9 x86_64 system

Mock aborts immediately for arm arches



NB maybe a problem with the mock-core-configs inside Mageia9
now in /etc/mock/templates/
mageia-branched.tpl
and mageia-branched.tpl

config_opts['bootstrap_image'] = 'docker.io/library/mageia:cauldron'
config_opts['use_bootstrap_image'] = False

inside Mageia8
there was
config_opts['bootstrap_image'] = 'mageia:{{ releasever }}'

Thank you for the report.

This would have been best for luigi... In his absence, assigning globally; CC'ing packagers who have touched it recently.

CC: (none) => geiger.david68210, jani.valimaa
Assignee: bugsquad => pkg-bugs

new test : (easily done since my computer has a triple boot Mageia8, Mageia9 and Windows)

I wanted to know if the new mock-core-configs brings any problem :
for Mageia9 system :
in /etc/mock/templates/
I renamed 
mageia-branched.tpl      to mageia-branched.tplbak

I copied from my Mageia8 system
/etc/mock/templates/mageia-branched.tpl to /etc/mock/templates/ in my Mageia9 system

In the Mageia9 system :
tested mock with this old version of mageia-branched.tpl to build for Mageia9-i586 and for Mageia9-x86_64
it's OK

BUT when I test to build  for Mageia9-armv7hl or Mageia9-aarch64 it aborts with the same root.log as https://bugs.mageia.org/attachment.cgi?id=14210
(same useful extract as provided in 
https://bugs.mageia.org/show_bug.cgi?id=32620#c0)

After this test
I have reverted the templates to their initial state in my Mageia9 system

So it'

Conclusions :
1) the new version of mock-core-configs is not the culprit

2)the repodata are not the culprit (since mock can use them inside a Mageia8 system since I could use them with a modified mageia-9-armv7hl.cfg so that it's not a link to  mageia-cauldron-armv7hl.cfg


Let's look now at mock itself or at dnf or at python3-backoff

The problem didn't exist for Mageia9 with mock-3.5.1 in the original core/release
(the only problem was then in mock-mageia-configs-8.2 in which mageia-9-*.cfg
was a link to mageia-cauldron-*.cfg
 I could correct this manually and mock could then build for all arches)

The problem has appeared since the updates with
mock-5.1.1 which needs now python-backoff

mock-core-configs-39.1.1 (the templates for Mageia seems to be not involved)

mock-mageia-configs-9.1 (it only corrected which mageia-9-*.cfg and created 
mageia-10-*.cfg linked to mageia-cauldron-*.cfg

the dnf stuff has not been updated since Mageia9/core/release

The only things to investigate now are mock itself 
and maybe python-backoff which perhaps let not enough time to download the repodata
(the root.log indicates bug in python : util.py:446 and util.py:448 )

I have spent hours to test lots of things :
1)
building rpms with the latest source of dnf dnf-plugins-core libdnf 
and mock mock-core-configs 
installing them with python-backoff and mock-mageia-configs

no way to build for arm arches

2)
uninstalling these updated stuff reinstalling them from core/release

modify the /etc/mock/mageia-9-*.cfg so that they are not simple links to 
mageia-cauldron-*.cfg

Then big surprise : I can build  for arm arches !! but no more for i586 or x86_64!!
with a strange message in the console (I will attach part of it)

3)
I uninstalled all the mock stuff from core release
I install the updated mock stuff from core updates

I can build now for all the arches !!!!!
and now for each arches
/var/lib/mock/mageia-9-(arch)-bootstrap/root/var/cache/dnf/   is filled



To conclude the problem seems to be caused by the fact that mock looks for the fastest mirror ... and sometimes this goes wrong !

Created attachment 14212 [details]
message in the console when mock 3.5.1 fails

This appears in the console when mock 3.5.1 (from core/release) fails to build for Mageia9 i586 or x86_64
when it can build for Mageia9 arm arches with modified mock-mageia-9-*.cfg so that they are no more a link to cauldron

It's not a bug !!!

It seems to be only caused by some mirrors that are not synchronized preventing mock to use the fastest one

So much time to understand this...

Nevertheless
Mock shouldn't select a mirror with for only criteria " the fastest one"

Game over !!!!!

(In reply to Philippe Didier from comment #10)
> Game over !!!!!

One more nasty side effect as I comment on https://bugs.mageia.org/show_bug.cgi?id=30089#c15 , the api mirror must only provide trusted/already in sync mirrors

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=30089

(In reply to Philippe Didier from comment #9)
> Nevertheless
> Mock shouldn't select a mirror with for only criteria " the fastest one"

In /etc/mock/templates/mageia-branched.tpl (from the mock-core-configs rpm)

we find this option :
fastestmirror=1

line 36  line 47  line 58  and line 69

This option seems not to be pertinent because the fastest mirror is not always well updated 

Besides this, when the core/release repodata is written once the 
the core/updates repodata is very often rewritten...

You may launch mock when everything has not been yet synchronized that may cause mock to abort
Then you must wait for some time before launching mock again

That should be written in the wiki page of mock and prevent to open new bug reports
about mock !  ;o)

(In reply to Philippe Didier from comment #12)
> (In reply to Philippe Didier from comment #9)
> > Nevertheless
> > Mock shouldn't select a mirror with for only criteria " the fastest one"
> 
> In /etc/mock/templates/mageia-branched.tpl (from the mock-core-configs rpm)
> 
> we find this option :
> fastestmirror=1
> 
> line 36  line 47  line 58  and line 69
> 
> This option seems not to be pertinent because the fastest mirror is not
> always well updated 
> 
> Besides this, when the core/release repodata is written once the 
> the core/updates repodata is very often rewritten...
> 
> You may launch mock when everything has not been yet synchronized that may
> cause mock to abort
> Then you must wait for some time before launching mock again
> 
> That should be written in the wiki page of mock and prevent to open new bug
> reports
> about mock !  ;o)

Wait is not an option if the "fastest mirror" you get is a rotten mirror, my attempts were with enough time between them to solve an issue of mirror in sync process :(

How about just using a specific mirror instead of mirrorlist?

Comment all mirrorlist lines in mock config temlate and uncomment #baseurl lines. Modify baseurl to point to mirror you want to use.

(In reply to Jani Välimaa from comment #14)
> How about just using a specific mirror instead of mirrorlist?
> 
> Comment all mirrorlist lines in mock config temlate and uncomment #baseurl
> lines. Modify baseurl to point to mirror you want to use.

Hi Jani

I could add to the initial title :
"But sometimes mock can build for arm arches and no more for i586 or x86_64 ! "

That's what I discovered during my several tests...

This allowed me to think that if I launch mock during a mirror synchronization of its updates part, mock will abort...

About the templates, they are created upstream but even if we patch them to only use a specific mirror, (distrib-coffee for instance) this will not be OK for every part of the world (not always very fast for them) and may overload this repo with several requests.

Besides this the problem of a request coinciding with a mirror synchronization will not be resolved since it randomly appears...

What may be a solution would be to banish from the mirrors list the mirrors that are very often too lately updated.

I think we may close this bug report :
It was a temporary problem : mock have been working normally for 2 weeks now

something to do with some mirrors synchronization ?

I was too optimistic

Once again I can't use mock to build on arm arches (armv7hl or aarch64)

I can't test a correction to build on BS a package that failed to build on those arches !

looking at https://mirrors.mageia.org/status I maybe discovered why :
it's apparently caused by a problem of synchronization of the mirrors !!!

It's always the same message when mock fails

 Problem 1: conflicting requests
  - nothing provides python3-libdnf needed by python3-dnf-4.18.2-1.mga10.noarch from mageia-cauldron
  - nothing provides python(abi) = 3.12 needed by python3-dnf-4.18.2-1.mga10.noarch from mageia-cauldron
  - nothing provides python3-hawkey >= 0.71.1 needed by python3-dnf-4.18.2-1.mga10.noarch from mageia-cauldron
  - nothing provides python3-libcomps >= 0.1.8 needed by python3-dnf-4.18.2-1.mga10.noarch from mageia-cauldron
  - nothing provides python3-libdnf >= 0.71.1 needed by python3-dnf-4.18.2-1.mga10.noarch from mageia-cauldron
  - nothing provides python3-rpm >= 4.14.0 needed by python3-dnf-4.18.2-1.mga10.noarch from mageia-cauldron
 Problem 2: cannot install the best candidate for the job
  - nothing provides python3-dbus needed by python3-dnf-plugins-core-4.4.3-2.mga10.noarch from mageia-cauldron
  - nothing provides python3-systemd needed by python3-dnf-plugins-core-4.4.3-2.mga10.noarch from mageia-cauldron
  - nothing provides python(abi) = 3.12 needed by python3-dnf-plugins-core-4.4.3-2.mga10.noarch from mageia-cauldron
  - nothing provides python3-hawkey >= 0.64.0 needed by python3-dnf-plugins-core-4.4.3-2.mga10.noarch from mageia-cauldron


But these packages are indeed in 
https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/aarch64/media/core/release/

Maybe not found on other mirrors whose the repodata is not yet synchronized

I tried several workarounds without any success :
1) To work on a clean context, I have deleted :
/var/cache/mock/mageia-9-aarch64-nonfree
/var/cache/mock/mageia-9-aarch64-nonfree-bootstrap
/var/lib/mock/mageia-9-aarch64-nonfree
/var/lib/mock/mageia-9-aarch64-nonfree-bootstrap

and then I modified
/etc/mock/templates/mageia-branched.tpl
and 
/etc/mock/mageia-9-aarch64-nonfree.cfg
by suppressing the line "fastestmirror=1" each time it appears

I get always the same error as in comment 19 when trying to build a package

2)
To work on a clean context, I have deleted :
/var/cache/mock/mageia-9-aarch64-nonfree
/var/cache/mock/mageia-9-aarch64-nonfree-bootstrap
/var/lib/mock/mageia-9-aarch64-nonfree
/var/lib/mock/mageia-9-aarch64-nonfree-bootstrap

and then I modified
/etc/mock/templates/mageia-branched.tpl
and 
/etc/mock/mageia-9-aarch64-nonfree.cfg
by modifying the line "fastestmirror=1" into "fastestmirror=0" each time it appears

I get always the same error as in comment 19 when trying to build a package


NB
If I do the same workarounds 
for mageia-9-x86_64-nonfree
or for mageia-cauldron-x86_64-nonfree

mock can build the rpm !


It's not understandable !!!

(In reply to Philippe Didier from comment #20)
> I tried several workarounds without any success :
> 1) To work on a clean context, I have deleted :
> /var/cache/mock/mageia-9-aarch64-nonfree
> /var/cache/mock/mageia-9-aarch64-nonfree-bootstrap
> /var/lib/mock/mageia-9-aarch64-nonfree
> /var/lib/mock/mageia-9-aarch64-nonfree-bootstrap
> 
> and then I modified
> /etc/mock/templates/mageia-branched.tpl
> and 
> /etc/mock/mageia-9-aarch64-nonfree.cfg
> by suppressing the line "fastestmirror=1" each time it appears
> 
> I get always the same error as in comment 19 when trying to build a package
> 
> 2)
> To work on a clean context, I have deleted :
> /var/cache/mock/mageia-9-aarch64-nonfree
> /var/cache/mock/mageia-9-aarch64-nonfree-bootstrap
> /var/lib/mock/mageia-9-aarch64-nonfree
> /var/lib/mock/mageia-9-aarch64-nonfree-bootstrap
> 
> and then I modified
> /etc/mock/templates/mageia-branched.tpl
> and 
> /etc/mock/mageia-9-aarch64-nonfree.cfg
> by modifying the line "fastestmirror=1" into "fastestmirror=0" each time it
> appears
> 
> I get always the same error as in comment 19 when trying to build a package
> 
> 
> NB
> If I do the same workarounds 
> for mageia-9-x86_64-nonfree
> or for mageia-cauldron-x86_64-nonfree
> 
> mock can build the rpm !
> 
> 
> It's not understandable !!!
What I think is for arm arches dnf get the repos configuration from the chroot, but even if you produce a package with tweaked configuration , you can't install it because the initial chroot fail to be created

I forgot to say that I have also tested what Jani proposed in comment 14

Comment all mirrorlist lines in mock config template and uncomment #baseurl lines. Modify baseurl to point to mirror you want to use.

I did this for the template : mageia-branched.tpl in /etc/mock/templates/
and for the config file mageia-9-aarch64-nonfree.cfg in /etc/mock/

Then I have deleted :
/var/cache/mock/mageia-9-aarch64-nonfree
/var/cache/mock/mageia-9-aarch64-nonfree-bootstrap
/var/lib/mock/mageia-9-aarch64-nonfree
/var/lib/mock/mageia-9-aarch64-nonfree-bootstrap

Then I launched mock to build a rpm for aarch64-nonfree

It failed after having downloaded correctly the repodata
unable to create the bootstrap

The /var/lib/mock/mageia-9-aarch64-nonfree-bootstrap/root is quite empty :
the only folder being correctly fulfilled is :
/var/lib/mock/mageia-9-aarch64-nonfree-bootstrap/root/usr/share/distribution-gpg-keys/ 

There's no bin link, no lib link, no lib64 link, no sbin link
and of course no /usr/bin/ , no /usr/lib , no /usr/lib64 ,  no /usr/sbin/ folders



The strangest is that from December 16th to 18th the problem was strictly the contrary
I could build for arm arches but not for i586 nor for x86_64
(see comment 15)

(In reply to Philippe Didier from comment #22)
> The strangest is that from December 16th to 18th the problem was strictly
> the contrary
> I could build for arm arches but not for i586 nor for x86_64
> (see comment 15)

I not test again build for arm arches, but I'm using mock as part of personal/for blogdrake packagers, project and I can build without issues for i586 and x86_64, just one time I get issues building a package for x86_64 but after wait a prudent time I test again and the package build without issues

It's really a big problem that mock can't work for arm arches 
I use mock inside Mageia9 
I maintain packages for Mageia9 and Cauldron

I submit them to the BS without being able to test them with mock for arm arches

If a build fails in the BS for arm arches I can't easily blindly find what to modify in the spec file or patches

I got this problem recently to build a rpm for Cauldron or Mageia9
Fortunately, I have kept Mageia8 on my computer 
(triple boot Mageia8 Mageia9 Windows)

I can use mock for arm arches on my Mageia8 system to build this problematic rpm for Mageia8 !!!
I could then find what was wrong in its spec file
This shouldn't be a workaround !!!

Worse I can't use mock inside my Mageia8 system to build rpms neither for Cauldron arm arches nor for Mageia9 arm arches
I get the same message as in comment 19

Something must be wrong in the repodata for arm arches 
inside Cauldron repo 
and inside Mageia9 repo

One last test
Its less and less understandable !


Today I booted on my Mageia8 system, and inside it, using mock, I could build rpms for Cauldron aarch64

Then I booted on my Mageia9 system, and inside it, mock couldn't build anything with the same srpm for Cauldron aarch64 : same message as in comment 19


Inside my Mageia8 system
/var/lib/mock/mageia-cauldron-aarch64-bootstrap/root/var/cache/dnf/mageia-cauldron-nnnnnnnn/
contains 2 subfolders :
repodata/ containing 2 gz files
packages/ containing all the rpms used to create the bootstrap

Inside my Mageia9 system
/var/lib/mock/mageia-cauldron-aarch64-bootstrap/root/var/cache/dnf/mageia-cauldron-nnnnnnnn/
contains only the repodata/ with the 2 gz files
but there's no packages/ folder

It looks like if mock couldn't use the gz files to create the list of rpms to download and where to find the requested packages


But, looking at the list of rpms present inside a repo 
https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/aarch64/media/core/release/
I can find them

new try today for aarch64

determining the fastest mirror (1 hosts).. done.
Mageia Cauldron - aarch64                                                                                 2.2 kB/s | 2.5 kB     00:01    
determining the fastest mirror (3 hosts).. done.
Mageia Cauldron - aarch64                                                                                 2.1 MB/s |  39 MB     00:18    
Last metadata expiration check: 0:00:17 ago on Sun Jan 28 15:34:57 2024.

and then 
the same error as in comment 19

for armv7hl

determining the fastest mirror (10 hosts).. done.
Mageia Cauldron - armv7hl                                                                                 2.1 MB/s |  39 MB     00:18    
Last metadata expiration check: 0:00:16 ago on Sun Jan 28 15:41:05 2024.

and then 
the same error as in comment 19


It seems that there's something wrong when mock reads repodata

Created attachment 14317 [details]
errors with mock for aarch64

I have seen a difference when mock begins inside Mageia9


for cauldron aarch64  (from line 1 of the attached file)
and for cauldron x86_64 (from line 70 of the attached file)

NB for aarch64 It's a test with no existing 
/var/cache/mock/mageia-cauldron-aarch64-bootstrap/
and no /var/lib/mock/mageia-cauldron-aarch64-bootstrap/

line 24 
INFO: Package manager dnf detected and used (fallback)
Start(bootstrap): installing dnf tooling

NB for x86_64 the bootstrap already existed
Line 90
INFO: Package manager dnf detected and used (fallback)
Finish(bootstrap): chroot init

Line 101
INFO: Package manager dnf detected and used (direct choice)
Start: dnf update


NB I did a test for cauldron i586 with no existing 
/var/cache/mock/mageia-cauldron-i586-bootstrap/
and no /var/lib/mock/mageia-cauldron-i586-bootstrap/

mock starts without any problem

It seems that mock can't use software emulation for arm arches !

mock seems to fail to install dnf tooling for arm arches

@ Jani
Just saw that you are rebuilding dnf for arm arches for Cauldron

I will try again mock for arm arches when dnf will be uploaded...

Maybe this is the origin of the bug ?

@ Jani

Hi again, my test for the dnf having been rebuilt for arm arches  inside Cauldron was really stupid since I use mock inside a Mageia9 system... ;-(


An interesting point is that I have a triple boot (Mageia9 Mageia8 Windows7)
so that I can use mock on my Mageia8 system to build for Cauldron-aarch64 and it works : dnf does its job correctly and fulfill correctly 
/var/lib/mock/mageia-cauldron-aarch64-bootstrap/root/var/cache/dnf/!!!

Maybe the problem  for mock in Mageia9 when it emulates an arm arch system is linked to dnf badly built for arm arches ?
/var/lib/mock/mageia-cauldron-aarch64-bootstrap/root/var/cache/dnf/
is not completely fulfilled : some files and folders are missing

It would be interesting to rebuild dnf for arm in Mageia9/core/updates_testing
so that I could test again mock with this rebuilt dnf

I wasn't even able to build cauldron armv7hl pkgs with mock in Fedora 39 aarch64 environment with default options.

Build succeeds if '--no-bootstrap-chroot' and '--forcearch <ARCH>' switches are used.

'--forcearch <ARCH' is not needed if /etc/mock/templates/mageia-cauldron.tpl contains:
[main]
arch={{ target_arch }}

Hi Jani

You have found the good trick

I added only '--no-bootstrap-chroot' and could build for cauldron aarch64

To understand what happens :

I had a look at the content of 
/var/cache/mock/mageia-cauldron-aarch64-bootstrap/dnf_cache/mageia-cauldron-990e6cf1d6f900bc/
and 
/var/cache/mock/mageia-cauldron-aarch64/dnf_cache/mageia-cauldron-990e6cf1d6f900bc/

Both of them contain /repodata/ folder with the same .gz files

But there's a big difference :
/var/cache/mock/mageia-cauldron-aarch64-bootstrap/dnf_cache/mageia-cauldron-990e6cf1d6f900bc/
doesn't contain the /packages/ folder

It seems that mock is unable to do for arm arches what it is able to do for x86_64 or i586 : 
creating inside a bootstrap 
(/var/lib/mock/mageia-cauldron-aarch64-bootstrap/)  a subfolder /packages/ containing the basic rpms of a Cauldron system

and using this basic bootstrap  to add this rpms to the subfolder /packages/ inside
/var/lib/mock/mageia-cauldron-aarch64/

This can't be done since 
/var/cache/mock/mageia-cauldron-aarch64-bootstrap/dnf_cache/mageia-cauldron-990e6cf1d6f900bc/
doesn't contain the /packages/ folder

NB take care reading this ! I'm talking of different paths :
/var/cache/mock
/var/lib/mock

To simplify things:

For some reason mock can't create bootstrap chroot for 'foreign' arch.

$ mock -r mageia-cauldron-armv7hl --scrub=all
$ mock -r mageia-cauldron-armv7hl --bootstrap-chroot --init --forcearch armv7hl

...snip...

Error: Transaction test error:
  package rpm-mageia-setup-2.73-7.mga10.armv7hl is intended for a different architecture

And when using dnf5 as a package manager.

$ mock -r mageia-cauldron-armv7hl --bootstrap-chroot --init

...snip...

Problem 1: conflicting requests
  - package dnf5-5.1.10-2.mga10.armv7hl does not have a compatible architecture
  - nothing provides ld-linux-armhf.so.3 needed by dnf5-5.1.10-2.mga10.armv7hl

This might be a fallout of the fact that we're not using bootstrap image. Not sure is it's related, but according to https://rpm-software-management.github.io/mock/Release-Notes-5.0.html

"Even though the requested buildroot is cross-arch (must be initialized with cross-arch packages using the --forcearch RPM feature), the bootstrap chroot is newly always prepared with the native architecture. This change has been done to optimize the final buildroot installation — using the “arch natively” compiled DNF stack is much faster than cross-arch emulation using qemu-user-static. As a benefit, we can newly simply use the “native” Podman-pulled bootstrap_image even for cross-arch builds (we have to play with Glibc’s “personality” a bit, but still). See issue#1110."

https://github.com/rpm-software-management/mock/issues/1110

Hi Jani

I just see that you are testing mock inside a cauldron system (mga10.armv7hl rpms)

I forgot to say that my failing tests for using mock are done inside a Mageia9 system 

I said in a previous comment that I didn't have any problem with mock inside my (other) Mageia8 system : Comment 25


For Mageia9  there seems to be a problem not for mock itself but with dnf, not able to create the bootstrap for arm arches (mageia-cauldron-aarch64-bootstrap/ )
by downloading rpms into the :
/dnf_cache/mageia-cauldronnnnnnnnnnnn/packages/ folder even if the 
/dnf_cache/mageia-cauldronnnnnnnnnnnn/repodata/ gz files  have been correctly downloaded

And as a consequence mageia-cauldron-aarch64/ can't be fulfilled 


What is astonishing is the fact that dnf works with the option 
'--no-bootstrap-chroot'

and then everything is OK to build for mageia-cauldron-aarch64/

The dnf problem seems to be the same 
for my Mageia9 system 
and for your Cauldron system

Mga9 and cauldron is using the same mock version, mock v5.1.1, and the "breaking" change was introduced in mock v5.0.

The issue can be workarounded and behavior changed to not use bootstrap chroot by using the following in mock templates:
config_opts['use_bootstrap_container'] = False

(In reply to Jani Välimaa from comment #37)
> Mga9 and cauldron is using the same mock version, mock v5.1.1, and the
> "breaking" change was introduced in mock v5.0.
> 
> The issue can be workarounded and behavior changed to not use bootstrap
> chroot by using the following in mock templates:
> config_opts['use_bootstrap_container'] = False

Actually it might be better to only add this to armv7hl and aarch64 configs.

Indeed mock 5.1.1 was added in Mageia9/core/updates


Then this must be corrected by mageia :

The templates (etc/mock/templates/mageia-cauldron.tpl) applies to all arches 

but this part of /etc/mock/ comes from mageia :
(etc/mock/mageia-n-arch.cfg)

Modifying the templates is not necessary for non arm arches : is it useful to modify the templates for all arches ?

But I don't know if modifying the cfg files for arm arches will be taken into account by the templates

I'm gonna try to modify a mageia-cauldron-aarch64.cfg and see if this work

NB
Error
the config files come from upstream and are provided by mock-core-config
the source is
https://github.com/rpm-software-management/mock/

if the change inside mageia-cauldron-aarch64.cfg works
all the arm cfg files  will need to be modified upstream
(or the source will need a mageia patch)

Tested with the modified content of mageia-cauldron-aarch64.cfg


config_opts['target_arch'] = 'aarch64'
config_opts['legal_host_arches'] = ('aarch64',)
config_opts['use_bootstrap_container'] = False

include('templates/mageia-cauldron.tpl')

mock works now !

But since there's no more bootstrap, for each build you need to download all the rpms for each new rpm building by mock ...
(when a bootstrap exists mock only needs to download the rpms not already previously downloaded inside /var/cache/mock/mageia-n-arch-bootstrap)

It's not really an improvement but a workaround that needs to be applied to all cfg files for arm arches

@ Jani
@ katnatek

This bug report is becoming too long and not easy to follow and to understand

Should I close it and open a new one with a summary of the problem, and the diagnosis and workaround found by Jani 

It's an upstream bug that may be partially and temporarily corrected by a patch applied to the
mock-core-config rpm for mageia

(In reply to Philippe Didier from comment #42)
> @ Jani
> @ katnatek
> 
> This bug report is becoming too long and not easy to follow and to understand
> 
> Should I close it and open a new one with a summary of the problem, and the
> diagnosis and workaround found by Jani 
> 
> It's an upstream bug that may be partially and temporarily corrected by a
> patch applied to the
> mock-core-config rpm for mageia

Please not, is hard to me follow multiple reports of the same thing

According to https://github.com/rpm-software-management/mock/commit/58684e072d7e05563c43d73205ccc1c2074ac9e2

config_opts['bootstrap_forcearch'] = '{{ target_arch }}'

can be used instead of disabling bootstrap feature.

(In reply to katnatek from comment #43)
> (In reply to Philippe Didier from comment #42)
> > @ Jani
> > @ katnatek
> > 
> > This bug report is becoming too long and not easy to follow and to understand
> > 
> > Should I close it and open a new one with a summary of the problem, and the
> > diagnosis and workaround found by Jani 
> > 
> > It's an upstream bug that may be partially and temporarily corrected by a
> > patch applied to the
> > mock-core-config rpm for mageia
> 
> Please not, is hard to me follow multiple reports of the same thing

OK I let it as it is

(In reply to Jani Välimaa from comment #44)
> According to
> https://github.com/rpm-software-management/mock/commit/
> 58684e072d7e05563c43d73205ccc1c2074ac9e2
> 
> config_opts['bootstrap_forcearch'] = '{{ target_arch }}'
> 
> can be used instead of disabling bootstrap feature.

This works for me!, Now we need to release a fix

(In reply to Jani Välimaa from comment #44)
> According to
> https://github.com/rpm-software-management/mock/commit/
> 58684e072d7e05563c43d73205ccc1c2074ac9e2
> 
> config_opts['bootstrap_forcearch'] = '{{ target_arch }}'
> 
> can be used instead of disabling bootstrap feature.

You have really resolved the problem :


I added to the mageia-cauldron-aarch64.cfg
this line :
config_opts['bootstrap_forcearch'] = 'aarch64'

Now a bootstrap is used (mageia-cauldron-aarch64-bootstrap)
and mock uses this bootstrap (that prevent to download again rpms already present in the bootstrap)

More than this the previous workaround you proposed in Comment 37 had the result of letting all the rpms downloaded inside mageia-cauldron-aarch64 ...
That might prevent to see that a BuildRequires had been forgotten in the spec file if this particular rpm had been previously downloaded for an other build...

Now, to solve this bug

This line 
config_opts['bootstrap_forcearch'] = 'aarch64'
must be added to all 
the mageia-n-aarch64.cfg files 

and this line 
config_opts['bootstrap_forcearch'] = 'armv7hl'
must be added to all
the mageia-n-armv7hl.cfg files

NB that means nonfree and tainted cfg files too

These cfg files are in the mock-core-config rpm which needs to be patched (that means 18 cfg files to modify for mageia-8 , mageia-9 and mageia-cauldron)

@ katnatek
thanks for the issue that you opened upstream

I added a comment to inform them of the tainted and nonfree cfg files for each mageia version and arch so that they are not omitted

@ katnatek

I wrongly asked upstream to modify the cfg files for tainted and nonfree

Indeed these cfg files are created by mock-mageia-configs which add them on the basis of the basic cfg files of upstream from mock-core-configs

That means that after mock-core-configs has been modified upstream, and updated for Mageia9 and Cauldron...
mock-mageia-configs will have to be rebuilt and updated too

Many thanks to Jani (Wally) for his skill and perseverance :

He found the shortest way to correct mock-core-configs (proposed by him on upstream github)

You only have to add this line
config_opts['bootstrap_forcearch'] = '{{ target_arch }}'

inside two templates :
mageia-branched.tpl
mageia-cauldron.tpl

I tested this for arm arches for Mageia9 for cauldron
and for core and nonfree and tainted
It works perfectly

There's nothing to change inside any cfg file from mock-core-configs

There's nothing to modify inside mock-mageia-configs : it works as it is to adapt the templates to the nonfree or tainted builds

When Jani's commit will be accepted upstream, and the corrected source used to build an updated rpm this bug will be soon resolved :o)

@ Jani

I just saw that you have submitted for cauldron a new patched version (39.4-2) of
 mock-core-configs

Could you submit it for mageia-9/core/updates_testing too ?
I might test it and if it's OK this would allow to close this bug by asking to QA to test this update...

Unless you wait that your patch is merged upstream.

Thanks again for having found the way to solve this long lasting bug 
(it appeared when mock was updated from 3.5-1 to 5.1.1-1 in september)

@Jani
I'm following your work on
https://github.com/rpm-software-management/mock/issues/1304

I really admire your patience to obtain a little commit on mageia-core-configs that its dev seems to not simply accept, and resits to apply even if it has been tested and justified by and for Mageia users...

If this ends with a deadlock we can always add your patch for Mageia
It works ;-) 

Best Regards

@jani
@katnatek
If you are OK with this I may create an update request to correct this bug for Mageia9

I will attach here the spec file
and the patch

I have built this rpm and installed it as an update on my Mageia-9-x86_64 system :
it works : I can now build for arm arches

Created attachment 14342 [details]
spec file for an update correcting this bug for Mageia9

spec file for an update correcting this bug for Mageia9

Created attachment 14343 [details]
patch from jani allowing mock  to build for arm arches

patch from jani allowing mock to build for arm arches

If you are OK I can push it to http://svnweb.mageia.org/ 
and then submit it to Mageia9/core/updates_testing

Last news from
https://github.com/rpm-software-management/mock/issues/1304

Last comment from the mock dev :

praiskup moved this from Needs triage to Someday in future in CPT Kanban 

https://github.com/orgs/fedora-copr/projects/1/views/1

as you may see it's in the bottom of the Someday in future list (is he kidding ?
or doesn't he understand that this commit concerns only Mageia and won't affect the other distributions? )

That means no correction to the templates from upstream before a long time

We have no other choice than adding a patch to mock-core-configs for Mageia-9 
(Jani already did this for Cauldron)

Since apparently there won't be any change from upstream
Since  mock has not been working correctly for months
Since Jani found a solution (a patch)

It's time to close this !!

I have submitted mock-core-configs-39.1-2 to the BS for Mageia9/core/updates_testing

I have created an Update Request ( bug 32814 ) short and easy to read for QA

(In reply to Philippe Didier from comment #58)
> 
> I have created an Update Request ( bug 32814 ) short and easy to read for QA

The Update Request is indeed bug 32816 !!!

Close because bug#32816 fix this

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

Also thank you to sysadmins for fix the dnf metadata issue