Description of problem: urpmi has founded 42 pkgs to install: [root@mga6-64 alain4]# LANGUAGE=C urpmi --auto-update 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 medium "Core 32bit Release" is up-to-date medium "Core 32bit Updates" is up-to-date medium "Nonfree 32bit Release" is up-to-date medium "Nonfree 32bit Updates" is up-to-date medium "Tainted 32bit Release" is up-to-date medium "Tainted 32bit Updates" is up-to-date To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") lib64opus-devel 1.3.1 3.mga8 x86_64 (medium "Core Updates") firefox 78.9.0 1.mga8 x86_64 firefox-fr 78.9.0 1.mga8 noarch glib-gettextize 2.66.8 1.mga8 x86_64 glib2.0-common 2.66.8 1.mga8 x86_64 lib64gio2.0_0 2.66.8 1.mga8 x86_64 lib64glib2.0-devel 2.66.8 1.mga8 x86_64 lib64glib2.0_0 2.66.8 1.mga8 x86_64 lib64llvm11.0 11.0.1 4.2.1.mga8 x86_64 lib64nspr-devel 4.30 1.mga8 x86_64 lib64nspr4 4.30 1.mga8 x86_64 lib64nss-devel 3.63.0 1.mga8 x86_64 lib64nss3 3.63.0 1.mga8 x86_64 lib64opencv_calib3d4.5 4.5.1 1.3.mga8 x86_64 lib64opencv_core4.5 4.5.1 1.3.mga8 x86_64 lib64opencv_dnn4.5 4.5.1 1.3.mga8 x86_64 lib64opencv_features2d4.5 4.5.1 1.3.mga8 x86_64 lib64opencv_flann4.5 4.5.1 1.3.mga8 x86_64 lib64opencv_highgui4.5 4.5.1 1.3.mga8 x86_64 lib64opencv_imgcodecs4.5 4.5.1 1.3.mga8 x86_64 lib64opencv_imgproc4.5 4.5.1 1.3.mga8 x86_64 lib64opencv_objdetect4.5 4.5.1 1.3.mga8 x86_64 lib64opencv_video4.5 4.5.1 1.3.mga8 x86_64 lib64opencv_videoio4.5 4.5.1 1.3.mga8 x86_64 lib64sndfile-devel 1.0.31 1.mga8 x86_64 lib64sndfile1 1.0.31 1.mga8 x86_64 lib64usb1.0-devel 1.0.24 2.1.mga8 x86_64 lib64usb1.0_0 1.0.24 2.1.mga8 x86_64 lib64zmq5 4.3.4 1.1.mga8 x86_64 llvm-plugins 11.0.1 4.2.1.mga8 x86_64 nss 3.63.0 1.mga8 x86_64 thunderbird 78.9.0 1.mga8 x86_64 thunderbird-fr 78.9.0 1.mga8 noarch (medium "Core 32bit Release") libflac8 1.3.3 3.mga8 i586 libogg0 1.3.4 2.mga8 i586 libopus0 1.3.1 3.mga8 i586 libvorbis0 1.3.7 1.mga8 i586 libvorbisenc2 1.3.7 1.mga8 i586 (medium "Core 32bit Updates") libgio2.0_0 2.66.8 1.mga8 i586 libglib2.0_0 2.66.8 1.mga8 i586 libsndfile1 1.0.31 1.mga8 i586 libusb1.0_0 1.0.24 2.1.mga8 i586 5.1MB of additional disk space will be used. 153MB of packages will be retrieved. Proceed with the installation of the 42 packages? (Y/n) n [root@mga6-64 alain4]# while dnf --refresh upgrade returns no pkg: [root@mga6-64 alain4]# LANGUAGE=C dnf --refresh upgrade created by dnf config-manager from http://dl.google.com/linux/chrome/rpm/stable/x86_64 67 kB/s | 1.3 kB 00:00 google-earth-pro 85 kB/s | 1.3 kB 00:00 Mageia 8 - i586 5.7 kB/s | 4.3 kB 00:00 Mageia 8 - i586 - Updates 24 kB/s | 3.3 kB 00:00 Mageia 8 - i586 - Nonfree 28 kB/s | 3.8 kB 00:00 Mageia 8 - i586 - Nonfree - Updates 26 kB/s | 3.3 kB 00:00 Mageia 8 - x86_64 - Nonfree 23 kB/s | 3.8 kB 00:00 Mageia 8 - x86_64 - Nonfree - Updates 25 kB/s | 3.3 kB 00:00 Mageia 8 - i586 - Tainted 26 kB/s | 4.3 kB 00:00 Mageia 8 - i586 - Tainted - Updates 24 kB/s | 3.3 kB 00:00 Mageia 8 - x86_64 - Tainted 45 kB/s | 4.3 kB 00:00 Mageia 8 - x86_64 - Tainted - Updates 19 kB/s | 3.3 kB 00:00 Mageia 8 - x86_64 - Tainted - Updates 13 kB/s | 3.3 kB 00:00 Mageia 8 - x86_64 37 kB/s | 4.3 kB 00:00 Mageia 8 - x86_64 - Updates 35 kB/s | 3.3 kB 00:00 Opera packages 35 kB/s | 2.9 kB 00:00 skype (stable) 81 kB/s | 2.9 kB 00:00 vivaldi 161 kB/s | 2.9 kB 00:00 Dependencies resolved. Nothing to do. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
Just trying this: $ sudo urpmi --auto-update --test ... Estynnir 264MB o becynnau. [264Mb will be fetched] Parhau i osod 33 o becynnau? (Y/n) n [Continue to install 33 pkgs] $ sudo dnf --refresh upgrade ... Transaction Summary Install 2 Packages Upgrade 32 Packages Total download size: 265 M Is this ok [y/N]: n Looks pretty similar to me. I hope you are not mixing urpmi and dnf: it is recommended NOT to do so. Is this complaint a recurring one, or was this example one-off? What made you try both methods?
CC: (none) => lewyssmithEver confirmed: 1 => 0Status: NEW => UNCONFIRMED
DNF unreliable? Will wait for updates and will test this on the weekend.
CC: (none) => ouaurelien
(In reply to Lewis Smith from comment #1) > Just trying this: > > $ sudo urpmi --auto-update --test > ... > Estynnir 264MB o becynnau. [264Mb will be fetched] > Parhau i osod 33 o becynnau? (Y/n) n [Continue to install 33 pkgs] > > $ sudo dnf --refresh upgrade > ... > Transaction Summary > Install 2 Packages > Upgrade 32 Packages > Total download size: 265 M > Is this ok [y/N]: n > > Looks pretty similar to me. > > I hope you are not mixing urpmi and dnf: it is recommended NOT to do so. when I do updates, I begin to run dnf --refresh upgrade and I finish with: urpmi --auto-update > > Is this complaint a recurring one, or was this example one-off? this happens very rarely > What made you try both methods? because dnf adress not only to mageia repos, but also to non mageia repos (google chrome, skype, opera...) while urpmi doesn't
Regarding DNF + urpmi potential problem: https://wiki.mageia.org/en/Using_DNF#Warning_about_orphans_mechanisms Apart from that, should we add more information or warnings? I believe it should be OK if you don not use automatic orphan removal by any of them.
CC: (none) => fri
(In reply to peter lawford from comment #3) > because dnf adress not only to mageia repos, but also to non mageia repos > (google chrome, skype, opera...) while urpmi doesn't # urpmq --list-url|head -n 1 google-earth http://dl.google.com/linux/earth/rpm/stable/x86_64 If they have rpm repository, urpmi can handle it . In /etc/urpmi/urpmi.cfg, I have google-earth http://dl.google.com/linux/earth/rpm/stable/x86_64 { key-ids: 7fac5991,d38b4796 update } That was added using urpmi.addmedia, and the keys downloaded from one of the pgp public key servers, and then imported using rpmkeys. Mixing urpmi and dnf is not a good idea.
CC: (none) => davidwhodgins
@Peter > when I do updates, I begin to run > dnf --refresh upgrade > and I finish with: > urpmi --auto-update Curious, because if the first one (DNF) does its job, the second (urpmi) should have nothing left to do. Yet in the example you give at the beginning, the order was reversed. The first urpmi update (but you replied 'N') somehow thinks it happened, so DNF then found nothing to do. Puzzle. Also, in your example, why did you reply 'N' to the first urpmi update list, when you would have normally replied 'Y' - unless you suspected that DNF would then report no updates. OTOH in a normal situation, you would have accepted (Y) the urpmi updates and then tried DNF for any non-Mageia ones.
Created attachment 12561 [details] urpmi/dnf tests For understand: Did tests: 1) urpmi: 81 packages to updates/install with urpmi --auto-update command with core/nonfree/tainted repo. 2) Same test with dnf # dnf makecache <=== this is mandatory to do before asking to look for update as the timer should not be triggered since a while. # dnf upgrade 81 packages. Same names. See attached text. Normally there is a dnf-makecache.timer that refreshs dnf/yum repositories. $ systemctl status dnf-makecache.timer ● dnf-makecache.timer - dnf makecache --timer Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled) Active: active (waiting) since Sat 2021-04-03 16:32:45 CEST; 10min ago Trigger: Sat 2021-04-03 16:44:12 CEST; 44s left Triggers: ● dnf-makecache.service avril 03 16:32:45 localhost systemd[1]: Started dnf makecache --timer. This timer does not triggers at boot but 5 minutes later after logon...
Also note that by default, only $ARCHcore/release and $ARCH/core/updates are enabled in dnf configuration (where $ARCH = x86_64 or i586 depending how you installed Mageia). You have to edit several files in /etc/yum.repo.d/... Note also that both packages managers use different methods to look for dependencies. Sometimes, dnf wants to install more packages, sometimes it is urpmi...
Note also urpmi uses $MIRRORLIST to look for best bandwidth and nearest mirror. dnf uses same but both can choose different mirror at same time! Some mirrors chosen can be out-of-date...
Resolution: (none) => INVALIDStatus: UNCONFIRMED => RESOLVED
Note also urpmi uses $MIRRORLIST to look for best bandwidth and nearest mirror. dnf uses same but both can choose different mirror at same time! Some mirrors chosen can be out-of-date... (Oups, too quick.) that's why this can happen. Not a bug. Perhaps, try to tell urpmi to use a unique mirror like http://ftp.free.fr/mirrors/mageia.org/distrib And do the same for DNF under /etc/yum.repo.d/ files. mageia-x86_64.repo : [mageia-x86_64] name=Mageia $releasever - x86_64 ## Uncomment following: baseurl=http://ftp.free.fr/mirrors/mageia.org/distrib/8/x86_64/media/core/release/ #metalink=https://mirrors.mageia.org/metalink?distrib=mageia-$releasever&arch=x86_64§ion=core&repo=release Comment: #mirrorlist=https://www.mageia.org/mirrorlist/?release=$releasever&arch=x86_64§ion=core&repo=release gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Mageia fastestmirror=1 enabled=1 Feel free to reopen if this occurs again with making sure both package manager use same mirror.