Description of problem: urpmi wants to install 32bit packages from the 32bit media, instead of the correct x86_64 packages. See for example this: $ LC_ALL=C sudo urpmi rpm-build rpmlint To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release (distrib1)") elfutils 0.152 1.mga1 x86_64 gcc-c++ 4.5.2 4.mga1 x86_64 gettext 0.18.1.1 2.mga1 x86_64 lib64gettextmisc 0.18.1.1 2.mga1 x86_64 lib64unistring0 0.9.3 4.mga1 x86_64 libstdc++-devel 4.5.2 4.mga1 x86_64 libtool-base 2.4 3.mga1 x86_64 m4 1.4.16 1.mga1 x86_64 perl-List-MoreUtils 0.300.0 3.mga1 x86_64 perl-Module-ScanDeps 1.20.0 1.mga1 noarch python-pkg-resources 0.6.14 7.mga1 noarch python-rpm 4.8.1 10.mga1 x86_64 rpm-build 4.8.1 10.mga1 x86_64 rpm-mageia-setup-build 1.133 1.mga1 x86_64 rpmlint 1.2 1.mga1 noarch (medium "Core 32bit Release (distrib31)") autoconf 2.68 1.mga1 noarch automake 1.11.1 3.mga1 noarch perl-JSON 2.510.0 1.mga1 noarch perl-YAML 0.730.0 1.mga1 noarch python-enchant 1.6.5 1.mga1 noarch (suggested) python-magic 5.06 1.mga1 noarch spec-helper 0.31.5 2.mga1 noarch 35MB of additional disk space will be used. 9MB of packages will be retrieved. Proceed with the installation of the 22 packages? (Y/n) n If i disable the 32bit repositories, it works as expected. This was also the case with mozilla-thunderbird-de package, which is actually noarch, but present in both repos. It offered to install this twice (x86 & x86_64 noarch), then downloaded both, but installed only one. Just a pity i don't have logs of that. Repositories were setup with drakrpm-edit-media, choosing a specific mirror for all repositories. Of the 32bit repositories, only Core_Release and Core_Updates are activated.
Well, it seems the problem occurs only with noarch packages which are present for both architectures, x86 and x86_64.
this is noarch packages so this doesn't matter if they come from 32 bit or 64bit repo.
Status: NEW => RESOLVEDCC: (none) => dmorganecResolution: (none) => FIXED
but if we have a local repo in x86_64 and ftp mirror for i586, it search on the ftp
True, I've seen this too only with noarch packages, urpmi seems to prefer to get them from i586 repos even if the same package(s) is available in the x86_64 repos. However, it doesn't matter much, the noarch package is the same in all of the repos.
Hmmm, so should i set this to RESOLVED INVALID or leave it open?
Whoops. Seen to late that it is RESOLVED FIXED. Was that me accidentaly or doesn't mageia bugzilla send mails about bug status changes?
you must be in the cc list for that
It's wontfix (just a nitpick).
Resolution: FIXED => WONTFIX
(In reply to comment #7) > you must be in the cc list for that I'm the reporter. Why should i add mself to the CC list? Or is this some strange kind of new feature or misconfiguration? All bugzillas that i have used send also status notifications, no matter if you're reporter or only CC'ed.
(In reply to comment #9) > (In reply to comment #7) > > you must be in the cc list for that > > I'm the reporter. Why should i add mself to the CC list? Or is this some > strange kind of new feature or misconfiguration? All bugzillas that i have used > send also status notifications, no matter if you're reporter or only CC'ed. AFAIK we didn't change anything regarding the email preferences in bugzilla, we're using the upstream defaults. Please check your prefs at https://bugs.mageia.org/userprefs.cgi?tab=email , particularly the "Reporter" column.
Well for me it's a real bug.
Status: RESOLVED => REOPENEDResolution: WONTFIX => (none)Assignee: bugsquad => thierry.vignaudSummary: urpmi wants to install 32bit packages when 32bit media are activated => urpmi wants to download noarch from the 32bit repository on a x86_64 hostSource RPM: urpmi-6.40-9.mga1.src.rpm => urpmi
(In reply to comment #11) > Well for me it's a real bug. ?!
CC: (none) => sander.lepik
(In reply to comment #12) > (In reply to comment #11) > > Well for me it's a real bug. > > ?! ?! = why ? I have a local mirror with only the x86_64 repository aka core, nonfree and tainted with (release, updates, updates_testing, backports, backports_testing) And and online reposity for i586 core (release, updates, updates_testing, backports, backports_testing) . If I install a x86_64 package who require or suggest a noarch package, the noarch package is not pick on my local repo but on the online one. So why should I again download a package that I have already on my local repo ? (noarch on i586 and x86_64 are the same)
moreover, by pointing on 2 different repositories (local and remote) you can encounter synchronisation problems...
CC: (none) => grenoya
That is indeed a bug. I guess urpmi sorts arches with the requested package alphabetically so i586 gets used before x86_64. urpmi knows to prioritize local media as in cd/dvd/harddisk, but when you add network media, it cant easily decide what is local and what is remote I wonder if the urpmi --strict-arch flag would help on x86_64 even if rpms are noarch. A "workaround" is of course to keep the i586 medias disabled, and only enable them when needed.
CC: (none) => tmb
(In reply to comment #13) > > If I install a x86_64 package who require or suggest a noarch package, the > noarch package is not pick on my local repo but on the online one. Well, actually this is related, but a slightly different bug, IMHO. AFAIK urpmi always prefers local packages over remote ones. This can be easily seen if after a default installation you don't remove the CD/DVD repos, and want to install packages. It will always want that CD/DVD even if the packages are also in the online repos. So there must be something that's buggy about this behavior.
(In reply to comment #15) > > urpmi knows to prioritize local media as in cd/dvd/harddisk, but when you add > network media, it cant easily decide what is local and what is remote Can a "local" mirror (but only accessible over network) be marked as such somehow in urpmi.cfg to make this known to urpmi, like in Manuels case?
(In reply to comment #15) > I wonder if the urpmi --strict-arch flag would help on x86_64 even if rpms are > noarch. --strict-arch is the default on x86_64.
So this one is a duplicate of bug 1546 ? (or my bug :) )
(In reply to comment #19) > So this one is a duplicate of bug 1546 ? > (or my bug :) ) Nope. your bug is about missing local media -> should switch to external mirror this bug is about pulling noarch rpms from x86_64 (local) media before trying external media
Priority: Normal => LowSeverity: major => normal
tracked at https://bugs.launchpad.net/rpm/+bug/913208
CC: (none) => n3npq
I think this bug and bug #4322 would be better fixed by spliting noarch packages in their own repository
Source RPM: urpmi => perl-URPM
Fixed
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
Note sure I will push this as an update for mga1 though.
Version: 1 => Cauldron