Description of problem: I'm attempting to set up a Mageia armv5tl chroot on a Fedora 25 armv7hl host to do some work building and testing packages on an ARM system. However, when I attempt to do this (either through mock or dnf itself), it fails saying the packages requested aren't available. A quick dnf repoquery reveals that they are there. For example: [root@ ~]# sudo dnf --disablerepo=* --repofrompath=mageia,http://mirrors.kernel.org/mageia/distrib/6/armv5tl/media/core/release/ --enablerepo=mageia --installroot=/var/lib/machines/mga6-armv5tl/ --exclude=urpmi --exclude=perl-URPM repoquery basesystem Added mageia repo from http://mirrors.kernel.org/mageia/distrib/6/armv5tl/media/core/release/ Last metadata expiration check: 1:58:00 ago on Mon Apr 10 15:03:05 2017. basesystem-1:6-0.4.mga6.armv5tl At first, I thought it might have something to do with missing 'armv5tl' in the 'arm' basearch, so I added it. But even after that, it didn't work. Everything I know about how this ARM stuff goes indicates that this should work... Version-Release number of selected component (if applicable): 1.1.10-5.fc25 How reproducible: Always Steps to Reproduce: 1. Set up Fedora 25 armv7hl (RPi 2+ or similar) 2. sudo dnf --disablerepo=* --repofrompath=mageia,http://mirrors.kernel.org/mageia/distrib/6/armv5tl/media/core/release/ --enablerepo=mageia --installroot=/var/lib/machines/mga6-armv5tl/ --exclude=urpmi --exclude=perl-URPM install basesystem mageia-release dnf Actual results: Last metadata expiration check: 1:51:43 ago on Mon Apr 10 15:03:05 2017. No package basesystem available. No package mageia-release available. Error: Unable to find a match. Expected results: Full package set selected for building a chroot is offered Additional info:
For what it's worth, it also breaks the ability to build packages targeting Mageia's armv5tl target from armv7hl hosts with Mock, which is definitely supposed to work.
I've also tested using an armv7hl Mageia 6 image with DNF 2.2.0 and libdnf 0.8.1, and it still appears to be the case. I imagine this would still be the case in DNF 2.3.0, too.
> "armv7hl", "armv7hl:armv6hl", Which means armv7hl is not compatible with armv5tl.
(this was paste from libsolv's poolarch.c code)
Proposed PR to libsolv: https://github.com/openSUSE/libsolv/pull/192
With those changes, libsolv lets me do stuff, now rpm complains: package thai-data-0.1.26-1.mga6.armv5tl is intended for a different architecture And similar messages show for all arched packages...
Proposed PR to rpm: https://github.com/rpm-software-management/rpm/pull/199
PR for RPM rejected. RPM suggested that DNF gain some way to ignore/forcibly allow arches for certain circumstances (specifically when building chroots/containers).
oh, now I finally read this...
This was fixed in dnf-2.6.2-1.fc26.