Steps to Reproduce: 1. Have core backports configured but not enabled 2. In drakrpm select to install task-lamp 3. Popup lists dependencies, among them PHP 8.1 -But 8.1 is not in any enabled media, only in backports, which is disabled! This is a real problem as backports may not be compatible per what users actually expect to install. i.e for users installing Nextcloud server which need PHP8.0 , as in https://forums.mageia.org/en/viewtopic.php?t=14436 Also see https://bugs.mageia.org/show_bug.cgi?id=26922#c15 We also see similar problems regarding kernels, and VirtualBox driver https://ml.mageia.org/l/arc/qa-discuss/2021-06/msg00065.html https://bugs.mageia.org/show_bug.cgi?id=29507#c2 __NOTE__ "urpmi --test task-lamp" do select the correct PHP version: 8.0.14 from updates. So why do drakrpm differ?
Assignee: bugsquad => mageiatools
It seems also upgrade applet suffers this bug somehow https://forums.mageia.org/en/viewtopic.php?t=14445#p84897
Severity: normal => majorPriority: Normal => HighSummary: drakrpm autoselects dependencies from a disabled repo, and install them => drakrpm autoselects dependencies from a disabled repo, and install them (upgrade applet too?)
If upgrade applet is verified having this problem, it should get noted in errata and that note linked from update applet update descriptions in release notes.
Keywords: (none) => FOR_ERRATA8
CC: (none) => filip.komar
Also see discussion in bug 29148
*** Bug 29148 has been marked as a duplicate of this bug. ***
CC: (none) => herman.viaene
CC: (none) => chb0
*** Bug 30084 has been marked as a duplicate of this bug. ***
CC: (none) => LpSolit
Also, if Core Backports is enabled, then mgaapplet doesn't list any newer versions of PHP. I have PHP 8.0.13 on my machine, and mgaapplet doesn't list 8.0.15 in Core Updates nor 8.1.0 in Core Backports. If I disable Core Backports, then mgaapplet correctly reports that 8.0.15 is available. About drakrpm, I can reproduce what Morgan said. I tried to look at the code of drakrpm and other Rpmdrake and urpm Perl files, but I go nowhere. @tv: any idea on how to fix this problem?
CC: (none) => thierry.vignaud
I suspect this is related, but I get no kernel updates, probably because PHP 8.1.0 is in Backports and I don't want it for now. Disabling this repo makes no difference. For instance, I missed kernel 5.15.28 despite it's available for 2 weeks now: https://advisories.mageia.org/MGASA-2022-0100.html
Added in Errata: In section https://wiki.mageia.org/en/Mageia_8_Errata#Backports_problems with link from https://wiki.mageia.org/en/Mageia_8_Errata#Various_upgrade_issues For comment 1, upgrade applet, we should probably add something in https://wiki.mageia.org/en/Mageia_8_Release_Notes#Upgrading_online.2C_using_mgaonline_.28GUI.29 But what can user do? Letting mgaonline run makes it configure all repos including backports and then just go ahead possibly installing from backports?
Keywords: FOR_ERRATA8 => FOR_RELEASENOTES8, IN_ERRATA8
For Comment 6 & 7, I reopened Bug 30084.
Copied from a comment in Bug 29148, since that bug is now closed as a duplicate and probably won't be looked at again: Here is the terminal output from running "drakrpm-update" on this desktop (no backports, testing [except for QA testing], or 32-bit repos enabled: > tom@localhost ~]$ drakrpm-update > Ignore the following Glib::Object::Introspection & Gtk3 warnings > Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. > getting lock on urpmi > comparing /home/tom/qa-testing/x86_64/media_info/MD5SUM and /var/lib/urpmi/QA Testing (64-bit)/MD5SUM > medium "QA Testing (64-bit)" is up-to-date > not using metalink since requested downloader does not handle it > retrieved http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/core/updates media_info/MD5SUM > comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Updates (distrib3)/MD5SUM > medium "Core Updates (distrib3)" is up-to-date > retrieved http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/nonfree/updates media_info/MD5SUM > comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Updates (distrib13)/MD5SUM > medium "Nonfree Updates (distrib13)" is up-to-date > retrieved http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/tainted/updates media_info/MD5SUM > comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Updates (distrib23)/MD5SUM > medium "Tainted Updates (distrib23)" is up-to-date > unlocking urpmi database > getting lock on urpmi > examining synthesis file [/var/lib/urpmi/QA Testing (64-bit)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Core Release (distrib1)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Nonfree Release (distrib11)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Tainted Release (distrib21)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Tainted Updates (distrib23)/synthesis.hdlist.cz] > unlocking urpmi database Note that when it examines the various hdlists, it only does so for those enabled for updates. Now, take a look at the output from running simply "drakrpm" : > [tom@localhost ~]$ drakrpm > Ignore the following Glib::Object::Introspection & Gtk3 warnings > Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. > Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. > Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. > Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. > Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. > Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. > Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. > Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. > Impossible to set by_group view as default > getting lock on urpmi > examining synthesis file [/var/lib/urpmi/QA Testing (64-bit)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Core Release (distrib1)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Core Backports (distrib7)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Nonfree Release (distrib11)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Nonfree Backports (distrib17)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Tainted Release (distrib21)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Tainted Updates (distrib23)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Tainted Backports (distrib27)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Core 32bit Backports (distrib34)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Nonfree 32bit Backports (distrib39)/synthesis.hdlist.cz] > examining synthesis file [/var/lib/urpmi/Tainted 32bit Backports (distrib44)/synthesis.hdlist.cz] > unlocking urpmi database Note that it is examining ALL backport hdlists, even though none of them are enabled. Why is it doing that??? And furthermore, why can't we seem to fix drakrpm to stop it?
CC: (none) => andrewsfarm
confirming magaapplet does check backports too, even if disabled: urpmq --list-media active Core Release (distrib1) Core Updates (distrib3) Nonfree Release (distrib11) Nonfree Updates (distrib13) Tainted Release (distrib21) Tainted Updates (distrib23) killall mgaapplet mgaapplet: no process found [me@localhost ~]$ mgaapplet --testing Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. retrieved testing-i586?product=Default&version=8&mgaonline_version=3.31 Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. getting exclusive lock on urpmi unlocking urpmi database medium "Core Updates (distrib3)" is up-to-date medium "Nonfree Updates (distrib13)" is up-to-date medium "Tainted Updates (distrib23)" is up-to-date medium "Core Backports (distrib7)" is up-to-date medium "Nonfree Backports (distrib17)" is up-to-date medium "Tainted Backports (distrib27)" is up-to-date examining synthesis file [/var/lib/urpmi/Core Release (distrib1)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Release (distrib11)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Release (distrib21)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Updates (distrib23)/synthesis.hdlist.cz]
CC: (none) => westel
its been a while, but I did notice it during pre-release testing, upgrades from 7 => 8. no bug was created at the time (time issues)
I dug up my Mga-1(Virtualbox) install: $ uname -r 2.6.38.7-desktop-1.mga $ mgaapplet --testing Deprecated use of my() in false conditional at /usr/bin/mgaapplet line 712. Deprecated use of my() in false conditional at /usr/bin/mgaapplet line 918. getting exclusive lock on urpmi unlocking urpmi database invalid MD5SUM file (downloaded from rsync://mirrors.ustc.edu.cn/mageia/distrib/1/i586/media/core/updates/media_info) invalid MD5SUM file (downloaded from rsync://mirrors.ustc.edu.cn/mageia/distrib/1/i586/media/nonfree/updates/media_info) invalid MD5SUM file (downloaded from rsync://mirrors.ustc.edu.cn/mageia/distrib/1/i586/media/tainted/updates/media_info) invalid MD5SUM file (downloaded from rsync://mirrors.ustc.edu.cn/mageia/distrib/1/i586/media/core/backports/media_info) invalid MD5SUM file (downloaded from rsync://mirrors.ustc.edu.cn/mageia/distrib/1/i586/media/core/backports_testing/media_info) invalid MD5SUM file (downloaded from rsync://mirrors.ustc.edu.cn/mageia/distrib/1/i586/media/nonfree/backports/media_info) invalid MD5SUM file (downloaded from rsync://mirrors.ustc.edu.cn/mageia/distrib/1/i586/media/nonfree/backports_testing/media_info) invalid MD5SUM file (downloaded from rsync://mirrors.ustc.edu.cn/mageia/distrib/1/i586/media/tainted/backports/media_info) invalid MD5SUM file (downloaded from rsync://mirrors.ustc.edu.cn/mageia/distrib/1/i586/media/tainted/backports_testing/media_info) using mirror rsync://mirrors.ustc.edu.cn/mageia/distrib/1/i586 examining synthesis file [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Updates (distrib23)/synthesis.hdlist.cz] seems this issue has been around for some time ;)
According to the output in comment 11 & 13, mgaapplet is not *examining* backport. That it (tries to) download disabled repos synthesis files is unnecessary, cost time and download, but do nothing to package install. A seen in comment 10 second half, drakrpm is examining the disabled backports repos. Ben, what do drakrpm do on that mga1 system?
# drakrpm getting lock on urpmi using mirror rsync://mirrors.ustc.edu.cn/mageia/distrib/1/i586 examining synthesis file [/var/lib/urpmi/Core Release (distrib1)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core Backports (distrib7)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core Backports Testing (distrib9)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Release (distrib11)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Backports (distrib17)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Backports Testing (distrib19)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Release (distrib21)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Updates (distrib23)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Backports (distrib27)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Backports Testing (distrib29)/synthesis.hdlist.cz] unlocking urpmi database luckily I can remember the root password
only core release / core updates, nonfree release / nonfree updates and tainted release / tainted updates are enabled.
Thank you. So the problem this bug is about existed already in mga1. Apart from getting it fixed, is it would be good to verify if upgrading from mga7 to is affected (Comment 1) - and if so note it in upgrade instructions in release notes. Also interesting is bug 30084.
(In reply to Morgan Leijström from comment #17) > Thank you. np > > So the problem this bug is about existed already in mga1. so it seems. I had hoped that the problem was something introduced sometime after Mga1, so that the change could be pinpointed. In saying that, there has been a change, as drakrpm, in Mga1, was also examining at the ~ backports testing repos. In Mga8, no longer are the ~ backports testing repos examined. maybe, look to see when this change was made, and supplement it to include the ~ backports repos? > > Apart from getting it fixed, is it would be good to verify if upgrading from > mga7 to is affected (Comment 1) - and if so note it in upgrade instructions > in release notes. > . if I have time this weekend, I will clone my mga7 vbox. what info exactly do you want verified?
(In reply to Ben McMonagle from comment #18) > (In reply to Morgan Leijström from comment #17) > if I have time this weekend, I will clone my mga7 vbox. > > what info exactly do you want verified? Try to replicate https://forums.mageia.org/en/viewtopic.php?t=14445 : * On mga7 have all normal repos enabled, backports disabled. * have PHP installed * Full update * Upgrade to mga8 by using the applet * See if PHP8.0 is installed from updates (should be) or 8.1 from backports (this bug)
(In reply to Morgan Leijström from comment #19) > (In reply to Ben McMonagle from comment #18) > > (In reply to Morgan Leijström from comment #17) > > if I have time this weekend, I will clone my mga7 vbox. > > > > what info exactly do you want verified? > > Try to replicate https://forums.mageia.org/en/viewtopic.php?t=14445 : > > * On mga7 have all normal repos enabled, backports disabled. > * have PHP installed > * Full update > * Upgrade to mga8 by using the applet > * See if PHP8.0 is installed from updates (should be) or 8.1 from backports > (this bug) part #1: updated my mga7 to latest: uname -a Linux localhost 5.10.46-desktop-1.mga7 #1 SMP Thu Jun 24 16:07:44 UTC 2021 i686 i686 i386 GNU/Linux urpmq --list-media Core Release (distrib1) Core Release Debug (distrib2) Core Updates (distrib3) Core Updates Debug (distrib4) Core Updates Testing (distrib5) Core Updates Testing Debug (distrib6) Core Backports (distrib7) Core Backports Debug (distrib8) Core Backports Testing (distrib9) Core Backports Testing Debug (distrib10) Nonfree Release (distrib11) Nonfree Release Debug (distrib12) Nonfree Updates (distrib13) Nonfree Updates Debug (distrib14) Nonfree Updates Testing (distrib15) Nonfree Updates Testing Debug (distrib16) Nonfree Backports (distrib17) Nonfree Backports Debug (distrib18) Nonfree Backports Testing (distrib19) Nonfree Backports Testing Debug (distrib20) Tainted Release (distrib21) Tainted Release Debug (distrib22) Tainted Updates (distrib23) Tainted Updates Debug (distrib24) Tainted Updates Testing (distrib25) Tainted Updates Testing Debug (distrib26) Tainted Backports (distrib27) Tainted Backports Debug (distrib28) Tainted Backports Testing (distrib29) Tainted Backports Testing Debug (distrib30) urpmq --list-media active Core Release (distrib1) Core Updates (distrib3) Nonfree Release (distrib11) Nonfree Updates (distrib13) Tainted Release (distrib21) Tainted Updates (distrib23) # drakrpm Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 525. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 791. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 791. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 791. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 791. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 791. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 791. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 791. Impossible to set by_group view as default GLib-LOG **: posix_spawn avoided (fd close requested) at /usr/lib/perl5/vendor_perl/Glib/Object/Introspection.pm line 67. getting lock on urpmi examining synthesis file [/var/lib/urpmi/Core Release (distrib1)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core Backports (distrib7)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Release (distrib11)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Backports (distrib17)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Release (distrib21)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Updates (distrib23)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Backports (distrib27)/synthesis.hdlist.cz] unlocking urpmi database ~ task-lamp (search in drakrpm GUI) To satisfy dependencies, the following package(s) also need to be installed: - apache-mod_dav-2.4.48-1.mga7.i586 - apache-mod_php-7.4.21-1.mga7.i586 - apache-mod_userdir-2.4.48-1.mga7.i586 - libc-client0-2007f-13.1.mga7.i586 - libmcrypt-2.5.8-22.mga7.i586 - libmcrypt4-2.5.8-22.mga7.i586 - libphp_common7-7.4.21-1.mga7.i586 - php-bz2-7.4.21-1.mga7.i586 - php-channel-phpunit-1.3-16.mga7.noarch - php-cli-7.4.21-1.mga7.i586 - php-ctype-7.4.21-1.mga7.i586 - php-dom-7.4.21-1.mga7.i586 - php-filter-7.4.21-1.mga7.i586 - php-ftp-7.4.21-1.mga7.i586 - php-gd-7.4.21-1.mga7.i586 - php-gettext-7.4.21-1.mga7.i586 - php-imap-7.4.21-1.mga7.i586 - php-ini-7.4.21-1.mga7.i586 - php-json-7.4.21-1.mga7.i586 - php-mbstring-7.4.21-1.mga7.i586 - php-mcrypt-1.0.2-4.mga7.i586 - php-mysqli-7.4.21-1.mga7.i586 - php-mysqlnd-7.4.21-1.mga7.i586 - php-openssl-7.4.21-1.mga7.i586 - php-pdo-7.4.21-1.mga7.i586 - php-pear-1.10.9-1.2.mga7.noarch - php-pear-File_Iterator-1.3.4-6.mga7.noarch - php-posix-7.4.21-1.mga7.i586 - php-session-7.4.21-1.mga7.i586 - php-sqlite3-7.4.21-1.mga7.i586 - php-sysvsem-7.4.21-1.mga7.i586 - php-sysvshm-7.4.21-1.mga7.i586 - php-tokenizer-7.4.21-1.mga7.i586 - php-xmlreader-7.4.21-1.mga7.i586 - php-xmlwriter-7.4.21-1.mga7.i586 - php-zip-7.4.21-1.mga7.i586 - php-zlib-7.4.21-1.mga7.i586 - phpmyadmin-4.9.7-1.mga7.noarch - task-lamp-extras-3-7.mga7.noarch - task-lamp-perl-3-7.mga7.noarch - task-lamp-php-3-7.mga7.noarch 42MB of additional disk space will be used. *note* php-7.4.21-1.mga7.src.rpm is listed under eg: https://mirror.math.princeton.edu/pub/mageia/distrib/7.1/SRPMS/core/backports/ chose not to install via drakrpm. # urpmi task-lamp To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release (distrib1)") libmcrypt 2.5.8 22.mga7 i586 libmcrypt4 2.5.8 22.mga7 i586 php-channel-phpunit 1.3 16.mga7 noarch (recommended) php-mcrypt 1.0.2 1.mga7 i586 php-pear-File_Iterator 1.3.4 6.mga7 noarch (recommended) task-lamp 3 7.mga7 noarch task-lamp-extras 3 7.mga7 noarch (recommended) task-lamp-perl 3 7.mga7 noarch task-lamp-php 3 7.mga7 noarch (medium "Core Updates (distrib3)") apache-mod_dav 2.4.48 1.mga7 i586 (recommended) apache-mod_userdir 2.4.48 1.mga7 i586 (recommended) libc-client0 2007f 13.1.mga7 i586 php-bz2 7.3.29 1.mga7 i586 (recommended) php-gd 7.3.29 1.mga7 i586 php-imap 7.3.29 1.mga7 i586 php-mbstring 7.3.29 1.mga7 i586 (recommended) php-mysqli 7.3.29 1.mga7 i586 (recommended) php-mysqlnd 7.3.29 1.mga7 i586 php-pdo 7.3.29 1.mga7 i586 php-pear 1.10.9 1.2.mga7 noarch php-sqlite3 7.3.29 1.mga7 i586 php-zip 7.3.29 1.mga7 i586 (recommended) phpmyadmin 4.9.7 1.mga7 noarch (recommended) 38MB of additional disk space will be used. 7.9MB of packages will be retrieved. Proceed with the installation of the 23 packages? (Y/n) y $ killall mgaapplet $ mgaapplet --testing Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 525. retrieved testing-i586?product=Default&version=7&mgaonline_version=3.30 Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 525. getting exclusive lock on urpmi unlocking urpmi database medium "Core Updates (distrib3)" is up-to-date medium "Nonfree Updates (distrib13)" is up-to-date medium "Tainted Updates (distrib23)" is up-to-date medium "Core Backports (distrib7)" is up-to-date medium "Nonfree Backports (distrib17)" is up-to-date medium "Tainted Backports (distrib27)" is up-to-date examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Core Release (distrib1).cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Core Updates (distrib3).cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Nonfree Release (distrib11).cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Nonfree Updates (distrib13).cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Tainted Release (distrib21).cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Tainted Updates (distrib23).cz] Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 525. retrieved testing-i586?product=Default&version=7&mgaonline_version=3.30 getting exclusive lock on urpmi unlocking urpmi database removing medium "Core Release (distrib1)" removing medium "Core Release Debug (distrib2)" removing medium "Core Updates (distrib3)" removing medium "Core Updates Debug (distrib4)" removing medium "Core Updates Testing (distrib5)" removing medium "Core Updates Testing Debug (distrib6)" removing medium "Core Backports (distrib7)" removing medium "Core Backports Debug (distrib8)" removing medium "Core Backports Testing (distrib9)" removing medium "Core Backports Testing Debug (distrib10)" removing medium "Nonfree Release (distrib11)" removing medium "Nonfree Release Debug (distrib12)" removing medium "Nonfree Updates (distrib13)" removing medium "Nonfree Updates Debug (distrib14)" removing medium "Nonfree Updates Testing (distrib15)" removing medium "Nonfree Updates Testing Debug (distrib16)" removing medium "Nonfree Backports (distrib17)" removing medium "Nonfree Backports Debug (distrib18)" removing medium "Nonfree Backports Testing (distrib19)" removing medium "Nonfree Backports Testing Debug (distrib20)" removing medium "Tainted Release (distrib21)" removing medium "Tainted Release Debug (distrib22)" removing medium "Tainted Updates (distrib23)" removing medium "Tainted Updates Debug (distrib24)" removing medium "Tainted Updates Testing (distrib25)" removing medium "Tainted Updates Testing Debug (distrib26)" removing medium "Tainted Backports (distrib27)" removing medium "Tainted Backports Debug (distrib28)" removing medium "Tainted Backports Testing (distrib29)" removing medium "Tainted Backports Testing Debug (distrib30)" Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 525. cached mirror list uses an old format, invalidating it URPMI_ADDMEDIA_REASON reason=upgrade getting mirror list from http://mirrors.mageia.org/api/mageia.8.i586.list?reason=upgrade retrieved mageia.8.i586.list?reason=upgrade found geolocalisation NZ -35.13 174.77 from timezone Pacific/Auckland using mirror http://mirror.aarnet.edu.au/pub/mageia/distrib/8/i586 retrieving media.cfg file... retrieved $MIRRORLIST media/media_info/media.cfg adding medium "Core Release" adding medium "Core Release Debug" (ignored by default) adding medium "Core Updates" adding medium "Core Updates Debug" (ignored by default) adding medium "Core Updates Testing" (ignored by default) adding medium "Core Updates Testing Debug" (ignored by default) adding medium "Core Backports" (ignored by default) adding medium "Core Backports Debug" (ignored by default) adding medium "Core Backports Testing" (ignored by default) adding medium "Core Backports Testing Debug" (ignored by default) un-ignoring non-free medium `Nonfree Release' b/c nonfree packages are installed adding medium "Nonfree Release" adding medium "Nonfree Release Debug" (ignored by default) un-ignoring non-free medium `Nonfree Updates' b/c nonfree packages are installed adding medium "Nonfree Updates" adding medium "Nonfree Updates Debug" (ignored by default) adding medium "Nonfree Updates Testing" (ignored by default) adding medium "Nonfree Updates Testing Debug" (ignored by default) adding medium "Nonfree Backports" (ignored by default) adding medium "Nonfree Backports Debug" (ignored by default) adding medium "Nonfree Backports Testing" (ignored by default) adding medium "Nonfree Backports Testing Debug" (ignored by default) un-ignoring tainted medium `Tainted Release' b/c tainted packages are installed adding medium "Tainted Release" adding medium "Tainted Release Debug" (ignored by default) un-ignoring tainted medium `Tainted Updates' b/c tainted packages are installed adding medium "Tainted Updates" adding medium "Tainted Updates Debug" (ignored by default) adding medium "Tainted Updates Testing" (ignored by default) adding medium "Tainted Updates Testing Debug" (ignored by default) adding medium "Tainted Backports" (ignored by default) adding medium "Tainted Backports Debug" (ignored by default) adding medium "Tainted Backports Testing" (ignored by default) adding medium "Tainted Backports Testing Debug" (ignored by default) retrieved $MIRRORLIST media/core/release media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Release/MD5SUM retrieving source synthesis of "Core Release"... retrieved $MIRRORLIST media/core/release media_info/20210224-164801-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/core/release media_info/pubkey examining pubkey file of "Core Release"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/core/release media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Release Debug/MD5SUM retrieving source synthesis of "Core Release Debug"... retrieved $MIRRORLIST media/debug/core/release media_info/20210224-164912-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/core/release media_info/pubkey examining pubkey file of "Core Release Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/core/updates media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Updates/MD5SUM retrieving source synthesis of "Core Updates"... retrieved $MIRRORLIST media/core/updates media_info/20220512-134254-synthesis.hdlist.cz computing md5sum of retrieved source synthesis error: aria2 failed: exited with 4 retrieved $MIRRORLIST media/core/updates media_info/pubkey examining pubkey file of "Core Updates"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/core/updates media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Updates Debug/MD5SUM retrieving source synthesis of "Core Updates Debug"... retrieved $MIRRORLIST media/debug/core/updates media_info/20220512-134335-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/core/updates media_info/pubkey examining pubkey file of "Core Updates Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/core/updates_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Updates Testing/MD5SUM retrieving source synthesis of "Core Updates Testing"... retrieved $MIRRORLIST media/core/updates_testing media_info/20220514-125938-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/core/updates_testing media_info/pubkey examining pubkey file of "Core Updates Testing"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/core/updates_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Updates Testing Debug/MD5SUM retrieving source synthesis of "Core Updates Testing Debug"... retrieved $MIRRORLIST media/debug/core/updates_testing media_info/20220514-125613-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/core/updates_testing media_info/pubkey examining pubkey file of "Core Updates Testing Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/core/backports media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Backports/MD5SUM retrieving source synthesis of "Core Backports"... retrieved $MIRRORLIST media/core/backports media_info/20220429-204925-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/core/backports media_info/pubkey examining pubkey file of "Core Backports"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/core/backports media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Backports Debug/MD5SUM retrieving source synthesis of "Core Backports Debug"... retrieved $MIRRORLIST media/debug/core/backports media_info/20220429-204927-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/core/backports media_info/pubkey examining pubkey file of "Core Backports Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/core/backports_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Backports Testing/MD5SUM retrieving source synthesis of "Core Backports Testing"... retrieved $MIRRORLIST media/core/backports_testing media_info/20220512-232448-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/core/backports_testing media_info/pubkey examining pubkey file of "Core Backports Testing"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/core/backports_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Backports Testing Debug/MD5SUM retrieving source synthesis of "Core Backports Testing Debug"... retrieved $MIRRORLIST media/debug/core/backports_testing media_info/20220512-201256-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/core/backports_testing media_info/pubkey examining pubkey file of "Core Backports Testing Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/nonfree/release media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Release/MD5SUM retrieving source synthesis of "Nonfree Release"... retrieved $MIRRORLIST media/nonfree/release media_info/20210224-171905-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/nonfree/release media_info/pubkey examining pubkey file of "Nonfree Release"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/nonfree/release media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Release Debug/MD5SUM retrieving source synthesis of "Nonfree Release Debug"... retrieved $MIRRORLIST media/debug/nonfree/release media_info/20210224-171905-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/nonfree/release media_info/pubkey examining pubkey file of "Nonfree Release Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/nonfree/updates media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Updates/MD5SUM retrieving source synthesis of "Nonfree Updates"... retrieved $MIRRORLIST media/nonfree/updates media_info/20220428-224246-synthesis.hdlist.cz computing md5sum of retrieved source synthesis error: aria2 failed: exited with 4 retrieved $MIRRORLIST media/nonfree/updates media_info/pubkey examining pubkey file of "Nonfree Updates"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/nonfree/updates media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Updates Debug/MD5SUM retrieving source synthesis of "Nonfree Updates Debug"... retrieved $MIRRORLIST media/debug/nonfree/updates media_info/20220428-224246-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/nonfree/updates media_info/pubkey examining pubkey file of "Nonfree Updates Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/nonfree/updates_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Updates Testing/MD5SUM retrieving source synthesis of "Nonfree Updates Testing"... retrieved $MIRRORLIST media/nonfree/updates_testing media_info/20220511-160309-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/nonfree/updates_testing media_info/pubkey examining pubkey file of "Nonfree Updates Testing"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/nonfree/updates_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Updates Testing Debug/MD5SUM retrieving source synthesis of "Nonfree Updates Testing Debug"... retrieved $MIRRORLIST media/debug/nonfree/updates_testing media_info/20220428-224242-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/nonfree/updates_testing media_info/pubkey examining pubkey file of "Nonfree Updates Testing Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/nonfree/backports media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Backports/MD5SUM retrieving source synthesis of "Nonfree Backports"... retrieved $MIRRORLIST media/nonfree/backports media_info/20220429-205504-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/nonfree/backports media_info/pubkey examining pubkey file of "Nonfree Backports"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/nonfree/backports media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Backports Debug/MD5SUM retrieving source synthesis of "Nonfree Backports Debug"... retrieved $MIRRORLIST media/debug/nonfree/backports media_info/20220429-205504-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/nonfree/backports media_info/pubkey examining pubkey file of "Nonfree Backports Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/nonfree/backports_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Backports Testing/MD5SUM retrieving source synthesis of "Nonfree Backports Testing"... retrieved $MIRRORLIST media/nonfree/backports_testing media_info/20220429-205503-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/nonfree/backports_testing media_info/pubkey examining pubkey file of "Nonfree Backports Testing"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/nonfree/backports_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Backports Testing Debug/MD5SUM retrieving source synthesis of "Nonfree Backports Testing Debug"... retrieved $MIRRORLIST media/debug/nonfree/backports_testing media_info/20220429-205503-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/nonfree/backports_testing media_info/pubkey examining pubkey file of "Nonfree Backports Testing Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/tainted/release media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Release/MD5SUM retrieving source synthesis of "Tainted Release"... retrieved $MIRRORLIST media/tainted/release media_info/20210224-172108-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/tainted/release media_info/pubkey examining pubkey file of "Tainted Release"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/tainted/release media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Release Debug/MD5SUM retrieving source synthesis of "Tainted Release Debug"... retrieved $MIRRORLIST media/debug/tainted/release media_info/20210224-172110-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/tainted/release media_info/pubkey examining pubkey file of "Tainted Release Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/tainted/updates media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Updates/MD5SUM retrieving source synthesis of "Tainted Updates"... retrieved $MIRRORLIST media/tainted/updates media_info/20220324-085943-synthesis.hdlist.cz computing md5sum of retrieved source synthesis error: aria2 failed: exited with 4 retrieved $MIRRORLIST media/tainted/updates media_info/pubkey examining pubkey file of "Tainted Updates"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/tainted/updates media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Updates Debug/MD5SUM retrieving source synthesis of "Tainted Updates Debug"... retrieved $MIRRORLIST media/debug/tainted/updates media_info/20220324-085948-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/tainted/updates media_info/pubkey examining pubkey file of "Tainted Updates Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/tainted/updates_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Updates Testing/MD5SUM retrieving source synthesis of "Tainted Updates Testing"... retrieved $MIRRORLIST media/tainted/updates_testing media_info/20220511-071652-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/tainted/updates_testing media_info/pubkey examining pubkey file of "Tainted Updates Testing"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/tainted/updates_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Updates Testing Debug/MD5SUM retrieving source synthesis of "Tainted Updates Testing Debug"... retrieved $MIRRORLIST media/debug/tainted/updates_testing media_info/20220511-071650-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/tainted/updates_testing media_info/pubkey examining pubkey file of "Tainted Updates Testing Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/tainted/backports media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Backports/MD5SUM retrieving source synthesis of "Tainted Backports"... retrieved $MIRRORLIST media/tainted/backports media_info/20210224-172302-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/tainted/backports media_info/pubkey examining pubkey file of "Tainted Backports"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/tainted/backports media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Backports Debug/MD5SUM retrieving source synthesis of "Tainted Backports Debug"... retrieved $MIRRORLIST media/debug/tainted/backports media_info/20210224-172302-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/tainted/backports media_info/pubkey examining pubkey file of "Tainted Backports Debug"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/tainted/backports_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Backports Testing/MD5SUM retrieving source synthesis of "Tainted Backports Testing"... retrieved $MIRRORLIST media/tainted/backports_testing media_info/20210224-172246-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/tainted/backports_testing media_info/pubkey examining pubkey file of "Tainted Backports Testing"... getting exclusive lock on rpm unlocking rpm database retrieved $MIRRORLIST media/debug/tainted/backports_testing media_info/MD5SUM comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Backports Testing Debug/MD5SUM retrieving source synthesis of "Tainted Backports Testing Debug"... retrieved $MIRRORLIST media/debug/tainted/backports_testing media_info/20210224-172247-synthesis.hdlist.cz computing md5sum of retrieved source synthesis retrieved $MIRRORLIST media/debug/tainted/backports_testing media_info/pubkey examining pubkey file of "Tainted Backports Testing Debug"... getting exclusive lock on rpm unlocking rpm database wrote config file [/etc/urpmi/urpmi.cfg] wrote config file [/etc/urpmi/urpmi.cfg] medium "Core Release" is up-to-date medium "Core Updates" is up-to-date medium "Nonfree Release" is up-to-date medium "Nonfree Updates" is up-to-date medium "Tainted Release" is up-to-date medium "Tainted Updates" is up-to-date upgrade continues.....
upgrade continues.... reboot. uname -a Linux localhost 5.15.35-desktop-2.mga8 #1 SMP Fri Apr 22 20:08:11 UTC 2022 i686 i686 i386 GNU/Linux # urpmq --list-media active Core Release Core Updates Nonfree Release Nonfree Updates Tainted Release Tainted Updates $ urpmf -f --name -m php ~ php-ftp-8.0.11-1.mga8.i586:Core Updates ~
Good you did not update mga7 by drakrpm when it wanted to erroneously use backports. I see you got a lot of "error: aria2 failed" but it apparently got sorted. I usually have to switch to wget on the systems I use, per: https://wiki.mageia.org/en/Mageia_8_Errata#Downloading_software Anyway, the important thing here is that mgaapplet at least under this circumstance behave. Thus now edited errata entry to mention drakrpm instead of mgaapplet, and removing FOR_RELEASENOTES8 for now, assuming mgaapplet works. Mystery: https://forums.mageia.org/en/viewtopic.php?t=14445 user only used upgrade applet, but still got PHP from mga8 backport...?
Keywords: FOR_RELEASENOTES8 => (none)
only way to be sure is to request upgrade log from user "flink". hypothesis: user "flink" likely initially installed the php packages via drakrpm, got lucky with his install and all dependencies matched. upgrade via mgaapplet noted the "backports" packages, and so activated the "backports" media.
(In reply to Ben McMonagle from comment #23) > only way to be sure is to request upgrade log from user "flink". > > upgrade via mgaapplet noted the "backports" packages, and so activated the > "backports" media. eg, from my upgrade above: un-ignoring non-free medium `Nonfree Release' b/c nonfree packages are installed un-ignoring non-free medium `Nonfree Updates' b/c nonfree packages are installed un-ignoring tainted medium `Tainted Release' b/c tainted packages are installed un-ignoring tainted medium `Tainted Updates' b/c tainted packages are installed
Interesting theory. That would be another bug; having enabled backports in mga7 should not trig using backports in mga8, as mga8 release or updates should have at least same version anyway. Backports should never be enabled automatically. I have now asked for the upgrade log from that user.
(In reply to Morgan Leijström from comment #25) > I have now asked for the upgrade log from that user. No log available. I am still reluctant to remove "(upgrade applet too?)" from bug description, until we find what is happening and am sure upgrade is not affected.
Now this is totally insane: drakrpm operates wrong *randomly*! Today I installed kernel from updates testing, and it did NOT fail per this bug; it did NOT install any part from backport_testing despite it is configured. I use to need to fight it or use urpmi - why not this time? Investing a bit further, as test using the current situation of having new nvidia-current divers in both updates testing and backports testing: 1) $ LC_ALL=C drakrpm 2) enter my password (i am wheel) 3) Selections: "All updates", "All", "nvidia" 4) I clicked the topmost package, the testing update dkms-nvidia-current 470 Response: As dep, it want to install nvidia-current-utils-510. As expected by this bug. But why not more related packages? 5) I clicked cancel and 6) again *clicked the same package* Now it wanted to install three correct 470 version depdencies; nvidia-current-cuda-opencl, nvidia-current-utils, x11-driver-video-nvidia-current. I then repeatedly clicked and selecting dkms-nvidia-current I randomly get either the responses per 4 and 6 above, but also a third variant, like 6 but without x11-driver-video-nvidia-current. Amusing, we can use drakrpm as a dice... :/ ?? How can this happen ?? *Randomly* ! Do it use more than one thread and not syncing between evaluation steps?
Created attachment 13255 [details] autoselected -current-utils from backport (wrong)
Created attachment 13256 [details] Autoselected three deps of correct version
Created attachment 13257 [details] Autoselected only 2 deps (missing x11-*), correct versions
Some comments on the package filtering: Selections: "All updates", "All", "nvidia" -> per the attachment just submitted it lists updates from updates(testing) as well as from backports(testing). As backport is not enabled IMO it should not display them at all. But then, there IS a special selection that can be made, i.e: Selections: "Backports", "All", "nvidia" -> Only backports packages are displayed. (even though no backport repo is enabled) Now, interestingly: Selections: "All", "All", "nvidia" -> Do NOT list the backports packages. Selections: "Backports", "Not installed", "nvidia" Only list ONE package: nvidia-current-devel. Because I have the other even though in earlier versions? A bit deceiving, IMO, and inconsistent, because: Selections: "All", "Not installed", "nvidia" This do list all non installe dpackages, *including* the available updates for packages. And it list no backport.
Addendum to comment 27: installed nvidia packages: $ rpm -qa | grep nvidia lib64nvidia-egl-wayland1-1.1.5-3.mga8 x11-driver-video-nvidia-current-470.103.01-1.mga8.nonfree nvidia-current-utils-470.103.01-1.mga8.nonfree nvidia-current-doc-html-470.103.01-1.mga8.nonfree dkms-nvidia-current-470.103.01-1.mga8.nonfree libnvidia-egl-wayland1-1.1.5-3.mga8 nvidia-current-lib32-470.103.01-1.mga8.nonfree nvidia-cuda-toolkit-11.4.3-1.mga8.nonfree nvidia-current-cuda-opencl-470.103.01-1.mga8.nonfree
Here's another tidbit of information: If you run drakrpm from the terminal you'll see where it "examines" all of the hdlists of the active repos, plus the backport repos, whether they are active or not. (Curiously, on my machines only the backport repos are examined, not backports testing or debug.) The hdlists are stored in /var/lib/urpmi, in individual folders. If you look at the dates on each of those hdlists, you'll see that the active ones have been updated, but the inactive backport ones have not been. On this install, for example, I changed mirrors and then back again in April because math.princeton was having problems. The hdlists for the active repos are dated today, but the backport repos are still dated the day I last set up the mirror. So when drakrpm insists on installing a dependency from backports, if backports is disabled it's probably out of date.
Oops. I had that wrong. Any hdlist set up as an update repo is updated. Core, Nonfree, Tainted, and Backports are not. But, here's something: If you disable Nonfree release and/or tainted release, and then run drakrpm, those disabled repos are NOT "examined," but all of the backports hdlists ARE. So the problem all seems to boil down to this: Backports hdlists are being "examined" when drakrpm is run, whether disabled or not. None of the other repo hdlists are treated this way, including Core Release, the most basic of the repos. Disable them, and they are not "examined." WHY is this???
Martin W replied on QA mail list "urpm does resolve dependencies in a random order, and if there are multiple ways a dependency can be resolved, this will lead to different results from run to run." That does not help debugging.
Created attachment 13258 [details] drakrpm say dep version is not satisfied, but it is. I clicked x11-driver-video-nvidia-current-470.129.06-1.mga8.nonfree.x86_64, end the corresponding nvidia-current-utils of same version, 470.129.06-1.mga8.nonfree, is listed, but still it pops up: "Sorry, the following package cannot be selected: - x11-driver-video-nvidia-current-470.129.06-1.mga8.nonfree.x86_64 (due to unsatisfied nvidia-current-utils[== 470.129.06-1.mga8.nonfree])" Workaround is to select the update packages in a different order (and abort whenever it propose backport packages) I wonder if the quirks we see are symptoms of some kind of general issue like interpreter compatibility with old code, or...?
*** Bug 30504 has been marked as a duplicate of this bug. ***
CC: (none) => nk0885
Please can we get work done on this? This bug is making us reluctant to provide updated software! i.e Bug 29758 Comment 18
Summary: drakrpm autoselects dependencies from a disabled repo, and install them (upgrade applet too?) => drakrpm autoselects dependencies from a disabled repo (i.e backports), and install them.
Observation: 1) Disable both core_backports and core_backports_testing 2) In drakrpm dialogue to update medias: core_backports is listed, while core_backports_testing is not. None should be, but why is *one* of them? Weird.
(In reply to Thomas Andrews from comment #34) > So the problem all seems to boil down to this: Backports hdlists are being > "examined" when drakrpm is run, whether disabled or not. None of the other > repo hdlists are treated this way, including Core Release, the most basic of > the repos. Disable them, and they are not "examined." > > WHY is this??? From reading the code, and subsequently reading bug 12786 comment 76, this is intentional - it allows rpmdrake to list them when you select the "Backports" filter. But clearly this is only safe if back-ported packages are leaf packages and don't get pulled in as dependencies. I can't see an easy way to fix this bug without removing that functionality. (In reply to Morgan Leijström from comment #39) > Observation: > > 1) Disable both core_backports and core_backports_testing > > 2) In drakrpm dialogue to update medias: core_backports is listed, while > core_backports_testing is not. > > None should be, but why is *one* of them? Weird. This is again deliberate - see bug 13606 for the rationale. NOTE: To reproduce this bug I had to first enable then disable the backports media. Before that the synthesis files for those media haven't been downloaded, so rpmdrake skipped them.
CC: (none) => mageia
"NOTE: To reproduce this bug I had to first enable then disable the backports media. Before that the synthesis files for those media haven't been downloaded, so rpmdrake skipped them." It's been a while since I did this, and I'm on vacation and not in a position to check it now, but as I recall if I used drakrpm-edit-media to change mirrors, I saw "hdlists" for all the media downloaded, even those that weren't enabled. Some took some time, and others were all but instantaneous. If my recollection is accurate, it would mean that if someone installed MGA8 today, and then used drakrpm-edit-media to switch from, say, MIRRORLIST to a specific mirror, then he could be hit by the bug. Or, if a mirror went down and the user switched to another.
(In reply to Thomas Andrews from comment #41) ... > If my recollection is accurate, it would mean that if someone installed MGA8 > today, and then used drakrpm-edit-media to switch from, say, MIRRORLIST to a > specific mirror, then he could be hit by the bug. Or, if a mirror went down > and the user switched to another. I used 'urpmi.addmedia --distrib' with a specific mirror (in a fresh VirtualBox install of Mageia 8). But drakrpm-edit-media could well behave differently.
when drakrpm is adding (or removing) repos, does it create a new configuration file or does it edit an existing one? if the later, could the "fix" be as simple as causing drakrpm to discard the now *old* configuration file and recreate a new one? maybe I am being too simplistic.
further not in a position at the moment to test this => enable "backports" in an existing system setup. add a package from this new repo. disable the backports repo. confirm issue is now apparent. urpmi.removemedia -a (I am guessing this removes the configuration file and any associated files) urpmi.addmedia --distrib ........ do not enable the "backports" repo. this (re)creates the configuration file. does this new configuration file exhibit the issue? y/N if No, how can this new correct configuration file be created seamlessly for the user?
@Ben, this bug occurs because rpmdrake allows the user to install backported packages *without* enabling the backport media. Your suggestion would disable that feature. If disabling/dropping that feature was an option, then it would be easy to fix rpmdrake.
(In reply to Martin Whitaker from comment #45) > @Ben, this bug occurs because rpmdrake allows the user to install backported > packages *without* enabling the backport media. Your suggestion would > disable that feature. If disabling/dropping that feature was an option, then > it would be easy to fix rpmdrake. I honestly think we should drop that feature. If a user wants to install a backported package, then he should enable the Backports repo. Period. This "feature" causes more trouble than it helps.
(In reply to Frédéric "LpSolit" Buclin from comment #46) > I honestly think we should drop that feature. If a user wants to install a > backported package, then he should enable the Backports repo. Period. This > "feature" causes more trouble than it helps. Agreed.
CC: (none) => davidwhodgins
(In reply to Dave Hodgins from comment #47) > (In reply to Frédéric "LpSolit" Buclin from comment #46) > > I honestly think we should drop that feature. If a user wants to install a > > backported package, then he should enable the Backports repo. Period. This > > "feature" causes more trouble than it helps. > > Agreed. You won't get any arguments from me. "Disabled" should mean disabled. Until this bug came up, I always thought it did.
From https://wiki.mageia.org/en/Backports_policy "Backports can be cherry-picked (ie, enable backports, install, disable backports). It means too that there must be strict requires between backported packages, in order to make sure they can be cherry-picked." At the present time, drakrpm ignores the enable/disable part of the above policy.
However the backports policy also says that only the following may be included in the backports media: - leaf packages - leaf group of packages (a group of packages no external package depends on). - packages not present in the distribution If that policy was followed, this bug would not occur. As rpmdrake is working as designed, this isn't something I feel I can change - you'll need to persuade the package maintainer (tv).
The policy is badly worded. "packages not present in the distribution (provided it doesn't obsolete or provide stuff that would impact the distribution, like backporting a new jvm with an obsolete on the current one)" The example in the brackets contradicts the "not present in the distribution" line by making it clear that newer versions of a package in the distribution are allowed. It's the newer versions being selected from a disabled repo that is the problem.
(In reply to Dave Hodgins from comment #51) > The policy is badly worded. I don't think so, although maybe it does't spell things out clearly enough. > The example in the brackets contradicts the "not present in the distribution" > line by making it clear that newer versions of a package in the distribution > are allowed. No, because of the parenthetical "provided it doesn't obsolete or provide stuff that would impact the distribution". If a new version of an existing package is backported, it must a) Have a different package name (e.g. including the version number). b) Not have any "provides" that would cause it to be selected as a dependency when installing a non-backported package. We have an example of a new JDK in Mageia 8 backports. It is named java-latest-openjdk to distinguish it from the versions in release & updates. And all its "provides" incorporate the version number (e.g. java-11-openjdk provides both "java" and "java-11" but java-latest-openjdk provides "java-16" but not "java"). > It's the newer versions being selected from a disabled repo that is the > problem. But only because the updates policy hasn't been followed. As I said, it's the intended behaviour, as stated in bug 12766 comment 76, and also in bug 2317 comment 67 (and further in bug 2317 comment 81).
P.S. I'm not saying you can't or shouldn't change the policy and/or the rpmdrake behaviour, but I think that needs to be discussed more widely than in a bug report.
I agree policy should be discussed, changed, written down. Then behaviour fixed. How/where do we lift it for discussion?
My understanding was that backports would only be used to select dependencies if either the backports media were enabled, or urpmi --searchmedia was used. In addition, the backports hdlist files would be updated as part of checking for updates so that they could be used with searchmedia. I did not expect that backports would be used for satisfying dependencies with normal install/update commands.
(In reply to Martin Whitaker from comment #42) > (In reply to Thomas Andrews from comment #41) > ... > > If my recollection is accurate, it would mean that if someone installed MGA8 > > today, and then used drakrpm-edit-media to switch from, say, MIRRORLIST to a > > specific mirror, then he could be hit by the bug. Or, if a mirror went down > > and the user switched to another. > > I used 'urpmi.addmedia --distrib' with a specific mirror (in a fresh > VirtualBox install of Mageia 8). But drakrpm-edit-media could well behave > differently. Confirming that it does. My mirror of choice is down temporarily, so I just switched to another, using drakrpm-edit-media through MCC. To avoid this bug, under my old mirror the backports repos had been removed altogether, but the switch to the new mirror restored them. They had not been activated. I went to drakrpm through MCC. There had been no dkms packages installed on this system before, so no kernel-devel packages had been installed. I asked to install dkms-broadcom-dl, and included in the long list of dependencies was the 5.18.x kernel-devel-latest (and the kernel devel package itself) from backports. I went back to drakrpm-edit-media, and removed the backports repos once more, which made the unwanted "dependencies" go away.
(In reply to Morgan Leijström from comment #54) > I agree policy should be discussed, changed, written down. > Then behaviour fixed. > > How/where do we lift it for discussion? I have attempted to start a discussion on the dev ML.
Good, it is being discussed :) Noting the there given link also here in the bug: https://wiki.mageia.org/en/Feature:BackportsSupport
Also related https://wiki.mageia.org/en/Feature:Backports_update_applet
I'm not sure why the message on dev said the backports policy hadn't been followed. The issue is that this is misbehavior by our tools. MageiaUpdate really needs to be rethought and completely re-implemented. For updates, it should not allow you to cherry pick individual RPMs. It should list applicable updates by the Source RPMs they were built from and let you enable/disable each set en masse, and that's it (and obviously the GUI should list somewhere within each the list of RPMs that would be updated if that entry is selected). As for backports, as has previously been suggested, it should probably be handled by a completely different tool, but just the same it should only allow you to enable/disable things built there by their SRPM name so that only those get pulled in (and I suppose possibly any needed dependencies those would pull in, though ideally in most cases, there wouldn't be any outside deps from another SRPM, but in some cases I suppose it could happen). As for why MageiaUpdate currently silently pulls things in from backports, I have no earthly idea. I can't believe the situation has been allowed to persist for this long.
But it's not Mageia Update that is "silently pulling things in from backports." It's rpmdrake (install software) that's doing it. The biggest issue, IMO, has been with the kernels currently in backports, because installing dkms-xxxxxx on a system that doesn't have a kernel-whatever-devel already installed will pull whatever is the latest in backports, too. Then, when the next kernel comes along, the now-installed kernel-whatever-devel-latest will see that "new" kernel-whatever-devel as a lower version than the one already installed, and won't update it. And that means that the dkms-xxxxxx won't build, and won't work with the new kernel. I believe the same sort of thing has happened with other packages, like php, but I don't know it from personal experience.
(In reply to David Walser from comment #60) > As for why MageiaUpdate currently silently pulls things in from backports, I > have no earthly idea. I can't believe the situation has been allowed to > persist for this long. (In reply to Thomas Andrews from comment #61) > But it's not Mageia Update that is "silently pulling things in from > backports." It's rpmdrake (install software) that's doing it. According to the forum thread linked in c#1 it did fail on upgrade. However, we failed to verify that misbehaviour, c#20.
Those using the workaround of removing backports media altogether should be sure to remove the 32-bit backports media as well. I was almost caught by that with a new 64-bit-only install that needed a "dkms" driver. I had removed the 64-bit backports media, but didn't think about the 32-bit repos. When I went to install that dkms driver, rpmdrake wanted to draw in the 32-bit kernel-devel and kernel-devel-latest packages from backports as dependencies, as well as some other 32-bit packages.
To remove all backports repos use "urpmi.removemedia -y Back".
(In reply to Martin Whitaker from comment #53) > P.S. I'm not saying you can't or shouldn't change the policy and/or the > rpmdrake behaviour, but I think that needs to be discussed more widely than > in a bug report. Just disable the feature to get us out of this mess. The discussion on council@ died out, but atleast no-one objected to it.
Agreed. It's causing many problems. Installing packages from a repo that has not been enabled should never have been added as a feature.
Status?
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=31208
+1, please disable this "feature" in rpmdrake for mageia8, at the moment it wants to install nvidia 515.86.01 from backport nonfree (even if repo is disabled), instead of installing 470.161.03 from nonfree updates. On the contrary, urpmi is consistent with urpmi.cfg and doesn't try to use a disabled repo, which looks like the correct behaviour
CC: (none) => npomarede
Setting for errata 9 for now. Am tempted to set it as a release blocker. - that it have been causing troubles for long is no excuse to never fix it.
Whiteboard: (none) => MGA8TOOKeywords: (none) => FOR_ERRATA9Version: 8 => Cauldron
Had a quick look at the sources, problem is in /usr/share/perl5/vendor_perl/Rpmdrake/open_db.pm where it adds media having "backport" in their name in case rpmdrake is doing some updates. See attached patch to fix this. I tested it using mga8 install with all backport media disabled without patch, rpmdrake wants to install for example : - cpupower 6.0.12 from backport instead of cpupower 5.15.82 from core - x11-driver-video-nvidia-current 515.86.01 from backport nonfree instead of 470.161.03 from nonfree with patch applied no more disabled backport rpm are shown. If I really enable backport media in urpmi.cfg, then these rpm appear as expected this time, so the patch doesn't seem to break anything. Patch will work with rpmdrake in mga8 and mga9/cauldron Nicolas
Created attachment 13615 [details] fix to not use disabled backport media This is the patch from comment #70
The patch has a few cosmetic issues: + # 2023/01/04 : stop using disabled backport media in case of update It's already not used for updates. + # my $searchmedia = $urpmi_options{update} ? undef : join(',', get_inactive_backport_media($urpm)); + undef $searchmedia; "my $searchmedia" declares $searchmedia as a local variable. As you have commented out that line, the undef is redundant. but yes, this is the way to disable this feature. I still think this is a decision that should be made by Thierry as the rpmdrake author/maintainer, but he isn't responding.
(In reply to Martin Whitaker from comment #72) > The patch has a few cosmetic issues: > > + # 2023/01/04 : stop using disabled backport media in case of update > > It's already not used for updates. ? on the contrary, backport media are currently used for updates, that's the problem I see with MGA8 > > + # my $searchmedia = $urpmi_options{update} ? undef : join(',', > get_inactive_backport_media($urpm)); > + undef $searchmedia; > > "my $searchmedia" declares $searchmedia as a local variable. As you have > commented out that line, the undef is redundant. yes I know, that's just I prefer explicitly undef'ining variables when they're used later, I find it clearer when looking at the code later :) > > but yes, this is the way to disable this feature. I still think this is a > decision that should be made by Thierry as the rpmdrake author/maintainer, > but he isn't responding. that was just a proof of concept, even if it works as is. It can be further simplified by completely removing $searchmedia and doing instead : urpm::media::configure($urpm, media => $media, undef, %urpmi_options);
(In reply to Martin Whitaker from comment #72) > but yes, this is the way to disable this feature. I still think this is a > decision that should be made by Thierry as the rpmdrake author/maintainer, > but he isn't responding. IMO, council can make this decision too, see tmb's comment 65. And I don't remember having seen any comment objecting to fix this problem.
Simply not forcing the updating of the backports doesn't fix the problem. Consider the case a user chooses to install one package from backports. They enable, update and update the media ifo, install the package, and then disable the backports as the backports were previously used. From that point on that user is subject to the problem in a way that is very difficult to debug. The only way to fix it is not to allow installing packages from a repo that is disabled.
Even if a user never activates any backports repo, he may still be hit by this problem. It's happened to me, several times. Consider if a user's mirror-of-choice goes down, for whatever reason, and he switches to an alternative. When the repos for that alternative are set up, they are all updated, whether they are enabled or not. From then on, the user is subject to the problem, unless he removes the backport repos altogether. It's interesting that this is only a problem with the backports repos. If A user chooses to run a completely FOSS system, he has the option of disabling the nonfree and tainted repos, and that will be respected. But not backports. Consider this: In a vbox M8 Plasma guest, I disabled all repos but 64-bit core and core updates. None of the backports repos had ever been enabled. Then I ran drakrpm, and this showed in the terminal: Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805. Impossible to set by_group view as default getting lock on urpmi examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Core Release.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Core Updates.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Core Backports.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Nonfree Backports.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Tainted Backports.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Core 32bit Backports.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Nonfree 32bit Backports.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Tainted 32bit Backports.cz] unlocking urpmi database Note that all of the backports repos were "examined," including 32-bit, but the Release and Update repos for Nonfree and Tainted were not. When drakrpm came up, I asked to install dkms-rtl8192eu, the noarch driver for a usb wifi device. Among the dependencies that it wanted to install were these: - kernel-desktop-devel-5.15.82-1.mga8-1-1.mga8.x86_64 - kernel-desktop-devel-6.0.12-1.mga8-1-1.mga8.x86_64 - kernel-desktop-devel-latest-6.0.12-1.mga8.x86_64 The last two were from Core_Backports. If I had followed through with the install, it would have worked. But, when the next core kernel update came along, kernel-desktop-devel would NOT have been updated, because of the "latest" package that had been installed from backports, and the wifi wouldn't build for the new kernel. BTW, I have yet to be hit by this bug when running drakrpm-update. That respects the user's wishes for disabled repos to actually BE disabled.
(In reply to Thomas Andrews from comment #76) > It's interesting that this is only a problem with the backports repos. If A > user chooses to run a completely FOSS system, he has the option of disabling > the nonfree and tainted repos, and that will be respected. But not backports. The backports are handled differently intentionally. The reason the change was introduced was to ensure that if a user enables backports, installs a package from backports, and then disables the backports, then mgaapplet can still be used to make them aware there's an updated version and be used to install that update. Without this problem code the user has no way to know when there is an update for the backports without manually periodically checking for an update, which is not good if there's a critical security update. When used as per the backports policy, it works fine. When non-leaf packages such as the kernel and php are allowed in the repo, then other updates such as a dkms module or an application that uses php are installed, that may (or may not) select packages from the backports repo to as they have names or provides that match those from the release repo.
(In reply to Nicolas Pomarède from comment #73) > (In reply to Martin Whitaker from comment #72) > > The patch has a few cosmetic issues: > > > > + # 2023/01/04 : stop using disabled backport media in case of update > > > > It's already not used for updates. > > ? > on the contrary, backport media are currently used for updates, that's the > problem I see with MGA8 drakrpm-update sets $Rpmdrake::pkg::probe_only_for_updates = 1. If you are running a stable version of Mageia, that in turn passes { update => 1 } as the %urpmi_options parameter to open_urpmi_db(). With the unpatched code, that causes $searchmedia to be set to undef. So unless /etc/product.id on your system contains the wrong information, your patch won't affect the behaviour of drakrpm-update. I did some tests, installing some packages from the release media that had newer versions in both the updates media and the backports media. drakrpm-update correctly chose the updates from the updates media. So I can't reproduce the problem you are seeing. (In reply to Dave Hodgins from comment #75) > Simply not forcing the updating of the backports doesn't fix the problem. ... > The only way to fix it is not to allow installing packages from a repo that > is disabled. That's what Nicolas's patch does. It doesn't stop mgaonline from updating the backports media.
(In reply to Martin Whitaker from comment #78) > drakrpm-update sets $Rpmdrake::pkg::probe_only_for_updates = 1. If you are > running a stable version of Mageia, that in turn passes { update => 1 } as > the %urpmi_options parameter to open_urpmi_db(). With the unpatched code, > that causes $searchmedia to be set to undef. So unless /etc/product.id on > your system contains the wrong information, your patch won't affect the > behaviour of drakrpm-update. > > I did some tests, installing some packages from the release media that had > newer versions in both the updates media and the backports media. > drakrpm-update correctly chose the updates from the updates media. So I > can't reproduce the problem you are seeing. my /etc/product.id is vendor=Mageia.Org,distribution=Mageia,type=Basic,version=8,branch=Official,release=8,arch=x86_64,product=Default As for what my patch is doing, you can see in comment #70 : without the patch rpmdrake will try to install for example nvidia driver 515.86 from 'backport' instead of using nvidia 470.161 from 'nonfree' (note that in my case I never installed anything from backport so far, so there's no reason that rpmdrake adds nvidia 515.86 from backport to the list of possible rpm) and with the patch, all rpm from backport (which is disabled) are gone. I can reproduce this easily on my MGA8 PC and it seems that the same issue people are complaining about, I don't know why you can't reproduce the same result, maybe it's specific on a few rpm packages only
(In reply to Nicolas Pomarède from comment #79) > As for what my patch is doing, you can see in comment #70 : without the > patch rpmdrake will try to install for example nvidia driver 515.86 from > 'backport' instead of using nvidia 470.161 from 'nonfree' (note that in my > case I never installed anything from backport so far, so there's no reason > that rpmdrake adds nvidia 515.86 from backport to the list of possible rpm) > > and with the patch, all rpm from backport (which is disabled) are gone. > > I can reproduce this easily on my MGA8 PC and it seems that the same issue > people are complaining about, I don't know why you can't reproduce the same > result, maybe it's specific on a few rpm packages only I can reproduce *this* bug without any problem. But this bug is about what happens when you install a new package, not what happens when updating. And your "on the contrary, backport media are currently used for updates, that's the problem I see with MGA8" in comment 73 made me think you were seeing a different bug. As I said in comment 72, it's a cosmetic issue, but your comment "stop using disabled backport media in case of update" in the patch is misleading, because the patch does not change the behaviour when updating, only when installing new packages.
(In reply to Martin Whitaker from comment #80) > As I said in comment 72, it's a cosmetic issue, but your comment "stop using > disabled backport media in case of update" in the patch is misleading, > because the patch does not change the behaviour when updating, only when > installing new packages. maybe my wording is not exact, but in my case rpmdrake settings when I start it is in the 1st drop down list : "all the updates" and in the second drop down list just on the right of the 1st one "All". so this looks like in that case rpmdrake is only showing installed packages for which a newer version / update is available (it's not showing new packages not installed yet), hence the comment in my patch about "stop using disabled backport media in case of update" I'm using 'update' in the case of updating some already installed packages to a newer version ; maybe you're using 'update' in the case of completely updating the distro from one version to another (mga8->mga9) ?
I'm using update to mean when using drakrpm-update to automatically select and install updates, either by running it directly, or through "Update your system" in the MCC, or via mgaonline. So yes, we are talking about different things. My understanding (admittedly from a very quick read-through of the rpmdrake source code) was that packages in the disabled backports media should only be displayed in rpmdrake when you select "Backports" in the 1st drop-down list, so maybe you have found another bug.
(In reply to Dave Hodgins from comment #77) > (In reply to Thomas Andrews from comment #76) > > It's interesting that this is only a problem with the backports repos. If A > > user chooses to run a completely FOSS system, he has the option of disabling > > the nonfree and tainted repos, and that will be respected. But not backports. > > The backports are handled differently intentionally. > > The reason the change was introduced was to ensure that if a user enables > backports, installs a package from backports, and then disables the > backports, > then mgaapplet can still be used to make them aware there's an updated > version > and be used to install that update. > > Without this problem code the user has no way to know when there is an update > for the backports without manually periodically checking for an update, which > is not good if there's a critical security update. > > When used as per the backports policy, it works fine. When non-leaf packages > such as the kernel and php are allowed in the repo, then other updates such > as a dkms module or an application that uses php are installed, that may > (or may not) select packages from the backports repo to as they have names or > provides that match those from the release repo. Yes, this issue exists because we stopped using Backports strictly according to current published policy. So it seems there are two potential solutions: 1. Leave drakrpm alone, and strictly support our current Backports policy. 2. Amend Backports policy, and change drakrpm accordingly. Each solution has its advantages and disadvantages, but one of them must be chosen for Mageia 9. The current situation is intolerable.
> Each solution has its advantages and disadvantages, but one of them must be > chosen for Mageia 9. The current situation is intolerable. ...and time passes The fancy functions in drakrpm we stumble on seem not documented and far from well known to users. I would vote to update policy to how it is really used, and make drakrpm not do smarts behind users back.
Keywords: FOR_ERRATA9 => IN_ERRATA9
ping...
(In reply to Morgan Leijström from comment #84) > > Each solution has its advantages and disadvantages, but one of them must be > > chosen for Mageia 9. The current situation is intolerable. > > ...and time passes > > The fancy functions in drakrpm we stumble on seem not documented and far > from well known to users. > > I would vote to update policy to how it is really used, and make drakrpm not > do smarts behind users back. +1 Prio 1: drakrpm needs to stop updating from a disabled repo. urpmi --auto-update doesn’t do it. Why should drakrpm do it? Prio 2: not a prerequisite for above, update Backport policy. That being said, users enabling Backport should be more advanced and should be ready to follow by themselves; until a functionality to alert on updates but not to install them is implemented.
(In reply to christian barranco from comment #86) > (In reply to Morgan Leijström from comment #84) > > > Each solution has its advantages and disadvantages, but one of them must be > > > chosen for Mageia 9. The current situation is intolerable. > > > > ...and time passes > > > > The fancy functions in drakrpm we stumble on seem not documented and far > > from well known to users. > > > > I would vote to update policy to how it is really used, and make drakrpm not > > do smarts behind users back. > > +1 > > Prio 1: drakrpm needs to stop updating from a disabled repo. urpmi > --auto-update doesn’t do it. Why should drakrpm do it? > Prio 2: not a prerequisite for above, update Backport policy. That being > said, users enabling Backport should be more advanced and should be ready to > follow by themselves; until a functionality to alert on updates but not to > install them is implemented. Agree, i end without intention with a backport version of the kernel in mageia 8
Fixed for mga9 in Bug 31208
Keywords: IN_ERRATA9 => (none)
(In reply to Morgan Leijström from comment #88) > Fixed for mga9 in Bug 31208 Thanks, so changing the version of this report to 8
CC: (none) => marja11Whiteboard: MGA8TOO => (none)Version: Cauldron => 8