On my mageia 64-bit installation, only 32bit packages for certain functions are available, which require 32bit Mageia packages. Rpmdrake always offers to update these required 32bit packages to their 64bit equivalents. Rpmdrake is not respecting the implicit strict-arch setting. To remedy this, I tried putting "strict-arch" in the global section at the beginning of the /etc/urpmi/urpmi.cfg configuration file. (There previously was no related setting in the file.) However rpmdrake still offers to update 32bit packages to their 64bit equivalent. Thus rpmdrake is not respecting the explicit "strict-arch" setting. Note that the man page for urpmi says : "--strict-arch Upgrade only packages if the newer version has the same architecture as the one installed. Mostly useful on machines that support several architectures (32 and 64 bit)." And for urpmi.cfg says : "strict-arch Same as --strict-arch for urpmi. Boolean option, enabled by default, meaning that packages can not be upgraded with versions for another architecture." So evidently rpmdrake is not respecting the implicit (default) or explicit settings for strict-arch. Note that this may also affect urpmi-7.31-1.mga4.src.rpm (not tested)
CC: (none) => doktor5000Assignee: bugsquad => thierry.vignaud
I did a test with urpmi using : urpmi --test --debug --auto-select and it did not show any updates of 32bit packages to 64bit (where they would uninstall the 32bit). (I only have a few installed, so it was easy to check.) I redid the test after removing "strict-arch" from urpmi.cfg, same correct result. So the bug is only with rpmdrake.
I ran rpmdrake --test in console, to see if it had any useful info. It showed === 12:39 /home/andr $ rpmdrake --test Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 296. Use of uninitialized value $value in numeric eq (==) at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 545. Use of uninitialized value $value in numeric eq (==) at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 545. Use of uninitialized value $value in numeric eq (==) at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 545. Use of uninitialized value $value in numeric eq (==) at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 545. Use of uninitialized value $value in numeric eq (==) at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 545. Use of uninitialized value $value in numeric eq (==) at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 545. Use of uninitialized value $value in numeric eq (==) at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 545. Impossible to set by_group view as default (drakrpm:17165): Gtk-WARNING **: GtkImage 0x46e7ce0 adjusted size vertical min 51 natural 51 must not decrease below min 52 natural 52 (drakrpm:17165): Gtk-WARNING **: GtkImage 0x46e7ce0 attempted to adjust its size allocation from -12,1 930x58 to 0,0 918x59. adjust_size_allocation must keep allocation inside original bounds getting lock on urpmi using mirror http://mirror.pw/mageia/distrib/4/x86_64 examen de la liste de synthèse [/var/lib/urpmi/mga4/synthesis.hdlist.cz] ... ... (more synthesis files) ... unlocking urpmi database === Doesn't seem to give useful info for this "strict-arch" bug. But the error messages at the beginning seem to point to the cause of setting by group view not being selectable, despite displaying as such. (Gtk3.pm lines 296 and 545.)
(context = 32bit apps installed on 64bit system, with the default "strict-arch" option active.) Further tests show that : 1) In both rpmdrake and urpmi, "strict-arch" is applied by default for updates. 2) rpmdrake proposes updating 32bit packages to 64bit. However rpmdrake ends up saying the update is not possible, without giving a reason given to the user. 3) urpmi similarly seems to accept updating, only to fail, without giving the correct reason why. output of $ urpmi --debug flash-player-plugin-11.2.202.429-1.mga4.nonfree.x86_64 ==== getting lock on urpmi parsing: /etc/urpmi/mediacfg.d/Official-2-x86_64 parsing: /etc/urpmi/mediacfg.d/Official-3-x86_64 parsing: /etc/urpmi/mediacfg.d/Official-4-x86_64 parsing: /etc/urpmi/mediacfg.d/Official-4.1-x86_64 parsing: /etc/urpmi/mediacfg.d/Stable-2-x86_64 loading mirrors cache using mirror http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/4/x86_64 using mirror http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/4/x86_64 using mirror http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/4/x86_64 using mirror http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/4/x86_64 examen de la liste de synthèse [/var/lib/urpmi/mga4/synthesis.hdlist.cz] examen de la liste de synthèse [/var/lib/urpmi/dvd4-core/synthesis.hdlist.cz] examen de la liste de synthèse [/var/lib/urpmi/dvd4-nf/synthesis.hdlist.cz] examen de la liste de synthèse [/var/lib/urpmi/mga5/synthesis.hdlist.cz] examen de la liste de synthèse [/var/lib/urpmi/Core Release (distrib1)/synthesis.hdlist.cz] examen de la liste de synthèse [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz] examen de la liste de synthèse [/var/lib/urpmi/Nonfree Release (distrib11)/synthesis.hdlist.cz] examen de la liste de synthèse [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz] paquetage meld-1.8.2-1.mga4.noarch ignoré paquetage task-obsolete-4-18.mga4.noarch ignoré getting exclusive lock on rpm search_packages: found flash-player-plugin-11.2.202.429-1.mga4.nonfree.x86_64 matching flash-player-plugin-11.2.202.429-1.mga4.nonfree.x86_64 found package(s): flash-player-plugin-11.2.202.429-1.mga4.nonfree.x86_64 opening rpmdb (root=, write=) no packages match flash-player-plugin (it is either in skip.list or already rejected) no packages match flash-player-plugin (it is either in skip.list or already rejected) scheduled sets of transactions: unlocking urpmi database unlocking rpm database EXITING (pid=13669) ==== Suggested solution : 1) For rpmdrake, do not propose the 64bit package as an update. Ie, do not show it at all if the left button is set to updates instead of all packages. 2) If showing all packages, and the user selects the 64bit package, reject the update, with a msg explaining why. Alternately, could accept that as "strict-arch=n" for that particular package, since both 32bit and 64bit versions of the package would be visible. Note that in show-all-packages mode, it would be useful to show that the 64bit package exists. Just not allow it to be selected if in "strict-arch" mode. 3) For urpmi, immediately reject the update, with a msg explaining why, instead of going through the long process of attempting the update, and finishing with an incorrect error message. BTW, it would be useful to correct this before the classic dvd's are released for mga5.
Adjusted title to reflect actual problem.
Summary: rpmdrake does not respect implicit or explicit strict-arch setting => rpmdrake offers to update 32bit packages to 64bit, even when the default "strict-arch" is set
hmm this is an historical problem... i think there is a similar bug somwhere
CC: (none) => anaselli
very close to Bug# 6942
bug# 6942 would be solved by not selecting the 32bit repos. (If he is correctly describing the problem.) In this case, that is irrelevant. But I wouldn't be surprised if this bug was already filed in another form. It took me a while to narrow down the problem.
Adjusted the title again (I'll get it right eventually ... ) It also affects urpmi. See comment 3 for details.
Summary: rpmdrake offers to update 32bit packages to 64bit, even when the default "strict-arch" is set => rpmdrake offers to update 32bit packages to 64bit and ultimately refuses, when the default "strict-arch" is set
This bug is still present on Mageia5beta3. I needed to deactivate all 32 bit media to have only update for 64bits arch. I didn't test to update 32bits package so I can't tell if it would fail or not.
CC: (none) => stephane_oss
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
As announced over a month ago, Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. This issue may have been fixed in a later Mageia release, so, if you still see it and didn't already do so: please upgrade to Mageia 5 (or, if you read this much later than this is written: make sure you run a currently maintained Mageia version) If you are able to reproduce it against a maintained version of Mageia, you are encouraged to 1. reopen this bug report, by changing the "Status" from "RESOLVED - OLD" to "REOPENED" 2. click on "Version" and change it against that version of Mageia. If you know it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. 3. give as much relevant information as possible. If you're not an experienced bug reporter and have some time: please read this page: https://wiki.mageia.org/en/How_to_report_a_bug_properly If you see a similar issue, but are _not_sure_ it is the same, with the same cause, then please file a new bug report and mention this one in it (please include the bug number, too). If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
Status: NEW => RESOLVEDResolution: (none) => OLD