| Summary: | urpmi doesn't help installing security updates on cauldron | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Guillaume Bedot <geex+mageia> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Normal | CC: | fri, lewyssmith |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | urpmi-8.131-1.mga9.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: |
Output of LANG=C urpmi --auto-update --test
Output of LANG=C urpmi --auto-update --keep --test Output of dnf up |
||
and dnf does not try to update rpm (obviously that's why I tried with one urpmi --skip option) and lib64modulemd2, it can become a liste à la Prévert pretty quick. It is not clear what you were doing: a global update, but with special condition(s). What has "I wish to install lib64ssh4" got to do with it? Or "security updates", rather than just updating the whole system? Why exclude 'rpm' from the urpmi update? "dnf up does the work , by not selecting gdb-minimal." Please elaborate. Are you saying that DNF worked by excluding 'gdb-minimal'? If so, what made you do that? Did you try first with urpmi? What exact command did you use for DNF that worked? Was it essentially the same as the urpmi command? "dnf does not try to update rpm ... and lib64modulemd2": excludes them automatically? or did you exclude them explicitly? Why the latter? Trying to identify the exact difference between the usage of urpmi (failed) and dnf (worked). CC:
(none) =>
lewyssmith I usually used "urpmi --auto-update", but that asked to remove a lot packages. So I added --keep option. It then tried to update rpm and dependencies of it, and failed. So I added the --skip rpm option, and it still failed. I gave up. I tried "dnf up" without any option, and it worked. I tried to keep the same configuration for repositories as I had for urpmi. # dnf repolist id du dépôt nom du dépôt cauldron-i586 Mageia Cauldron - i586 cauldron-i586-nonfree Mageia Cauldron - i586 - Nonfree cauldron-i586-tainted Mageia Cauldron - i586 - Tainted cauldron-x86_64 Mageia Cauldron - x86_64 cauldron-x86_64-nonfree Mageia Cauldron - x86_64 - Nonfree cauldron-x86_64-tainted Mageia Cauldron - x86_64 - Tainted The only difference is the geex-tests repository with vlc-plugin-wayland package (which did not work well) (In reply to Guillaume Bedot from comment #3) > I usually used "urpmi --auto-update", but that asked to remove a lot > packages. > > I tried "dnf up" without any option, and it worked. Without any log this bug seems quit sketchy. As urpmi and dnf use different mirrors (unless you have specified the exact same dedicated tier 1 mirrors), you maybe hit a mirror for urpmi which wasn‘t synced completely. (In reply to sturmvogel from comment #6) > As urpmi and dnf use different mirrors (unless you have specified the exact > same dedicated tier 1 mirrors), you maybe hit a mirror for urpmi which > wasn‘t synced completely. Nope. http://[::1]/distrib/cauldron/ in the 2 cases. # grep -e ^baseurl /etc/yum.repos.d/* /etc/yum.repos.d/cauldron-i586.repo:baseurl=http://[::1]/distrib/cauldron//i586/media/core/release/ /etc/yum.repos.d/cauldron-nonfree-i586.repo:baseurl=http://[::1]/distrib/cauldron//i586/media/nonfree/release/ /etc/yum.repos.d/cauldron-nonfree-x86_64.repo:baseurl=http://[::1]/distrib/cauldron//x86_64/media/nonfree/release/ /etc/yum.repos.d/cauldron-tainted-i586.repo:baseurl=http://[::1]/distrib/cauldron//i586/media/tainted/release/ /etc/yum.repos.d/cauldron-tainted-x86_64.repo:baseurl=http://[::1]/distrib/cauldron//x86_64/media/tainted/release/ /etc/yum.repos.d/cauldron-x86_64.repo:baseurl=http://[::1]/distrib/cauldron/x86_64/media/core/release/ I see there are still some double "//" where not needed, caused by my inability to use sed efficiently, but there are the same repos. What you are showing are no valid URLs. It is not possible to see if you are using mirrorlist or dedicated mirrors because you truncated the important part ands replaced it with [::1] A valid URL for a dedicated mirror looks like this as example: https://mirrors.kernel.org/mageia/distrib/cauldron/i586/media/core/release/ urpm* examples: To list the medias used by urpmi: $ urpmq --list-media active --list-url What does it say? If you want to reconfigure them, maybe easiest: First remove them all: # urpmi.removemedia -a To add a full set of new for mga9 64 bit, from the reliable umu.se mirror: # urpmi.addmedia --distrib http://ftp.acc.umu.se/mirror/mageia/distrib/9/x86_64/ CC:
(none) =>
fri (In reply to Morgan Leijström from comment #10) > urpm* examples: > > To list the medias used by urpmi: > $ urpmq --list-media active --list-url # urpmq --list-media active --list-url geex-tests file:///container/cauldron/home/packager/rpm/RPMS/x86_64 Core Release http://[::1]/distrib/cauldron/x86_64/media/core/release Core Updates http://[::1]/distrib/cauldron/x86_64/media/core/updates Nonfree Release http://[::1]/distrib/cauldron/x86_64/media/nonfree/release Nonfree Updates http://[::1]/distrib/cauldron/x86_64/media/nonfree/updates Tainted Release http://[::1]/distrib/cauldron/x86_64/media/tainted/release Tainted Updates http://[::1]/distrib/cauldron/x86_64/media/tainted/updates Core 32bit Release http://[::1]/distrib/cauldron/i586/media/core/release Core 32bit Updates http://[::1]/distrib/cauldron/i586/media/core/updates Nonfree 32bit Release http://[::1]/distrib/cauldron/i586/media/nonfree/release Nonfree 32bit Updates http://[::1]/distrib/cauldron/i586/media/nonfree/updates Tainted 32bit Release http://[::1]/distrib/cauldron/i586/media/tainted/release Tainted 32bit Updates http://[::1]/distrib/cauldron/i586/media/tainted/updates my local mirror is perfectly fine, updated from T1 distrib-coffee, and you can test with geex.ovh instead of [::1] if you want. And, if you look at the ipv4 addresses: # dig @1.1.1.1 geex.freeboxos.fr [...] ;; ANSWER SECTION: geex.freeboxos.fr. 2699 IN A 82.66.74.112 # dig @1.1.1.1 geex.ovh [...] ;; ANSWER SECTION: geex.ovh. 3600 IN A 82.66.74.112 It's the same host as provided in mirrorlists, but with ipv6 working. Despite serving only ipv4-only hosts, it seems to serve the purpose. Excerpts from the awstats (i tweaked a bit the config) page for december: Navigateurs Hits Pourcentage aria2 665 997 97.8 % Types de fichiers Hits Pourcentage Bande passante Pourcentage rpm Package 315 906 46.4 % 583.93 Go 76.6 % around half the hits seems to be the MD5SUM files, and for the bandwidth, it's shared with the isos. Noone complained so far So you are still avoiding to provide full informations. Additionally you claim to sync your local mirror against distrib-coffee but later provide geex.freeboxos.fr references... According the mirror staus page, geex is broken. https://mirrors.mageia.org/status Simple tests with the geex mirror show that it is not even able to open a reliable connection (ERR_CONNECTION_TIMED_OUT). As nobody else from cauldron users reported such an issue, it seems that your local setup in connection with broken mirrors lead to your reported behaviour. Somebody else may spend some time with this bug... So my mirror is broken, but dnf is so magical that it manages to install the updates anyway ?? As I said, I do not sync geex.ovh from geex.freeboxos.fr, they are the same (82.66.74.112). With geex.ovh address, ipv4 and ipv6 work. With geex.freeboxos.fr address (unfortunately, the one served by mirrors.mageia.org), the connection either reliably fails on ipv6, or reliably work with ipv4. I've seen I could remove the bogus address setting all the fields blank, but then the site prevents me to add the good one because they share the same ipv4. Feel free to delete the mirror from the list if you think it will cause issues. I think ipv6 users will just have a line in .aria2-adaptive-stats telling urpmi not to use it anymore. As already pointed out by Lewis in comment 2, you are mixing different topics and fail to provide clear informations. - Cauldron users should be able to solve basic problems and know how to use tools to provide clear informations. Also a base understanding of programs, tools, interconnections and how linux works is required. - instead of providing unexplained heavy tinkered commands, it is required to provide reproducible „builds“ for bugsquad to be able to reproduce. A self hosted local mirror with missing setup informations is useless as bugsquad is not able to reproduce this without any informations about sync setup. - as pointed out in the wiki, a bugreport needs to be in english. That means you need to prepend commands with LANG=C e.g. „LANG=C sudo urpmi —-auto-update“. See https://wiki.mageia.org/en/How_to_report_a_bug_properly - also many of the conflicts shown un you strange output are self explanatory and should be clear to all cauldron users. As example, gdb-minimal conflicts with gdb-headless. You can‘t install them at the same time and need to resolve the conflict manually by uninstalling one of the packages. - to be able to ping an IP-address means nothing about the synchronisation status of a mirror. IPV4 and IPV6 are not connected to a mirror status. Basics of networking and mirroring… - as described in the cauldron wiki, it is strongly recommended to use a tier 1 mirror. You are using a broken mirror sitting behind a tier 1 and sync it to a local mirror with unknown setup. A reciepe for disaster…. https://wiki.mageia.org/en/Cauldron Morgan named you alread a good mirror in comment 10. - You failed to provide the comparism between a simple „urpmi —-auto-update --test“ and the equivalent dnf command which you did not even show… - then you mention a geex-test server but fail to provide any output which show any URL or whatever this server is This is only a small collection of problems within this bugreport, which makes it impossible to reproduce any possible issue… (In reply to sturmvogel from comment #16) > As already pointed out by Lewis in comment 2, you are mixing different > topics and fail to provide clear informations. I tried to answer clearly and shortly in comment 3 already. The goal was to do a global update, including security fixes. > - instead of providing unexplained heavy tinkered commands, it is required > to provide reproducible „builds“ for bugsquad to be able to reproduce. A > self hosted local mirror with missing setup informations is useless as > bugsquad is not able to reproduce this without any informations about sync > setup. Sorry for that. > - also many of the conflicts shown un you strange output are self > explanatory and should be clear to all cauldron users. As example, > gdb-minimal conflicts with gdb-headless. You can‘t install them at the same > time and need to resolve the conflict manually by uninstalling one of the > packages. The conflicts correctly ensures that gdb-headless and gdb-minimal are the same version when using dnf. > - as described in the cauldron wiki, it is strongly recommended to use a > tier 1 mirror. I'll retry with a mirror not listed as broken by mirrors.mageia.org, that's understood. > - You failed to provide the comparism between a simple „urpmi —-auto-update > --test“ and the equivalent dnf command which you did not even show… Using http://ftp.acc.umu.se/mirror/mageia/distrib/cauldron/x86_64/ , I obtain similar results with urpmi wanting to uninstall lots of packages. I'd like to avoid to mimic broken urpmi behavior with dnf --best --allowerasing or similar command and I don't see the point. Which commands exactly do you wish to compare ? > - then you mention a geex-test server but fail to provide any output which > show any URL or whatever this server is It's answered in comment 5. It's just a folder with only vlc. I removed it. It is quite common that packages get removed when as example the naming changes (e.g. test1-1.0 and test2-1.0). Thisalso happens an stable distributions and not only developement releases. You could start by providing the full output from „urpmi —-test —-auto-update“. The —-test option will guarantee that no real changes are done to your system. It is a test run (see man urpmi). Better LANG=C urpmi —-test —-auto-update Created attachment 14238 [details]
Output of LANG=C urpmi --auto-update --test
I did not proceed with uninstallation test and stopped there.
Created attachment 14239 [details]
Output of LANG=C urpmi --auto-update --keep --test
TLDR; Fails with:
Installation failed: gdb-headless < 13.2-6.mga10 conflicts with gdb-minimal-13.2-6.mga10.x86_64
While some packages may have been installed, there were failures.
Created attachment 14240 [details]
Output of dnf up
As I'm new to dnf and I haven't found the option for dry-run / test, I just proceeded the real install
(In reply to sturmvogel from comment #18) > It is quite common that packages get removed when as example the naming > changes (e.g. test1-1.0 and test2-1.0). Thisalso happens an stable > distributions and not only developement releases. Yes, and I'll allow uninstallation of some unneeded packages once certbot is rebuilt. Anyway, it was more to document howto use a cauldron installation as a rolling release, and keep it up to date, than to open a bug. As this use infers some custom config, it renders more complicated to "provide reproducible „builds“ for bugsquad to be able to reproduce". Don't waste your time on this. Resolution:
(none) =>
INVALID (In reply to Guillaume Bedot from comment #24) > Anyway, it was more to document howto use a cauldron installation as a > rolling release, and keep it up to date OK then :) I suggest you write a wiki page and link it to https://wiki.mageia.org/en/Cauldron Cauldron is a developement release and no rolling release. Rolling releases are properly tested and don‘t tend to break. A developement release is not tested in complete and may be unuseable for days/weeks. So there are big differences. Promoting a developement release as rolling release will cause much harm to users which want to use a stable rolling release. Please understand that if 'urpmi --auto-update' does not work, but the equivalent 'dnf up' does, we do want to know about it. But without any small differences which cloud the issue. The two tests comment 21 comment 22 were not identical because of the '--keep' urpmi option which has no equivalent for dnf, but did not seem to matter. The attachments are good evidence, and are similar; suggesting that urpmi and DNF would have done/did the same updates despite the (again similar) list of errors. urpmi looks vindicated in the end. It is not a good idea to mix urpm* and dnf. I too have searched for a way to test run dnf like the --test flag for urpmi, but could not find... strange. --- A wiki page about how to (mis)use our deveopment branch should clearly state that it is by design occasionally broken - i.e temporarily incompatible updates of desktops or system parts. And care should be taken not to update any time without paying attention to dev mailig list, build system status and bugzilla. Also any user of such system must be prepared to fix convoluted problems, and any critical data secured by backups etc. (In reply to sturmvogel from comment #26) > Cauldron is a developement release and no rolling release. Rolling releases > are properly tested and don‘t tend to break. A developement release is not > tested in complete and may be unuseable for days/weeks. That's why I started forthe start "I know there is some heavy lifting on the distrib" And it may not be a good idea to document this use on the wiki. (In reply to Lewis Smith from comment #27) > It is not a good idea to mix urpm* and dnf. I've read about this (on the wiki I think), and it's yet an other reason not to document this. Also, I've checked the certificates, and there are still valid for while, so I updated to python-3.12 and removed not up-to-date packages (316 packages for a few days !). One thing to document would be that "dnf list extras" can help identifying packages that are obsolete in cauldron, as well as identifying 3rd parties packages causing problems (the intended use-case considering the name) dnf list —-extras does not help to identify obsolete packages. For this usecase dnf list —-obsolete is needed See man dnf or the linked documentation in https://wiki.mageia.org/en/Using_DNF You may also want to https://wiki.mageia.org/en/Using_DNF#Synchronize_with_repos My system needed that after testing phase of mga9... (In reply to sturmvogel from comment #32) > dnf list —-extras does not help to identify obsolete packages. For this > usecase dnf list —-obsolete is needed # LANGUAGE=C dnf list —-obsolete Last metadata expiration check: 3:26:20 ago on sam. 30 déc. 2023 19:36:09. Error: No matching Packages to list # I'll test again in few hours / days, but there are no more yet. @sturmvogel @Morgan Leijström Definitely, I have to have an other look at this wiki page... (If you not sure about the spelling of definitely, have a look at https://)xkcd.com/2871/) |
Description of problem: urpmi doesn't help installing security updates on cauldron. Say I wish to install lib64ssh4. I know there is some heavy lifting on the distrib so I use : # urpmi --auto-update --keep --skip rpm le média « geex-tests » est à jour http://[::1]/distrib/cauldron/x86_64/media/core/release/media_info/20231228-190737-synthesis.hdlist.cz média « Core Release » mis à jour le média « Core Updates » est à jour le média « Nonfree Release » est à jour le média « Nonfree Updates » est à jour le média « Tainted Release » est à jour le média « Tainted Updates » est à jour http://[::1]/distrib/cauldron/i586/media/core/release/media_info/20231228-190004-synthesis.hdlist.cz média « Core 32bit Release » mis à jour le média « Core 32bit Updates » est à jour le média « Nonfree 32bit Release » est à jour le média « Nonfree 32bit Updates » est à jour le média « Tainted 32bit Release » est à jour le média « Tainted 32bit Updates » est à jour Certains paquetages demandés ne peuvent pas être installés : dnf-data-4.18.1-2.mga10.noarch (afin de garder python3-dnf-4.18.1-1.mga10.noarch) gdb-headless-13.2-5.mga10.x86_64 (afin de garder gdb-13.2-2.mga10.x86_64) lib64comps0-0.1.18-4.mga10.x86_64 (afin de garder python3-libcomps-0.1.18-3.mga9.x86_64) lib64dnf2-0.72.0-2.mga10.x86_64 (afin de garder python3-libdnf-0.72.0-1.mga10.x86_64) lib64gpgme11-1.23.2-2.mga10.x86_64 (afin de garder python3-gpg-1.23.2-1.mga10.x86_64) lib64modulemd-gir2.0-2.15.0-3.mga10.x86_64 (afin de garder python3-libmodulemd-2.15.0-2.mga10.x86_64) lib64peas1.0_0-1.36.0-2.mga10.x86_64 (afin de garder lib64peas1.0_0-loader-python3-1.36.0-1.mga9.x86_64) lib64rpm10-4.19.0-7.mga10.x86_64 (afin de garder rpm-4.19.0-6.mga10.x86_64) libdnf-i18n-0.72.0-2.mga10.noarch (afin de garder lib64dnf2-0.72.0-1.mga10.x86_64) libreoffice-core-7.6.4.1-3.mga10.x86_64 (en raison de conflit avec libreoffice-data-7.6.4.1-3.mga10.x86_64, Tentative de promouvoir libreoffice-data) libreoffice-data-7.6.4.1-3.mga10.x86_64 (afin de garder libreoffice-writer-7.6.4.1-2.mga10.x86_64) libreoffice-opensymbol-fonts-7.6.4.1-3.mga10.noarch (afin de garder libreoffice-core-7.6.4.1-2.mga10.x86_64) libreoffice-ure-7.6.4.1-3.mga10.x86_64 (afin de garder libreoffice-gtk3-7.6.4.1-2.mga10.x86_64) libreoffice-ure-common-7.6.4.1-3.mga10.x86_64 (afin de garder libreoffice-ure-7.6.4.1-2.mga10.x86_64) python3-3.12.1-1.mga10.x86_64 (afin de garder system-config-printer-libs-1.5.18-1.mga9.noarch) python3-matplotlib-data-3.8.2-2.mga10.noarch (afin de garder python3-matplotlib-3.6.2-2.mga9.x86_64) python3-matplotlib-data-fonts-3.8.2-2.mga10.noarch (en raison de conflit avec python3-matplotlib-data-3.8.2-2.mga10.noarch, en raison de conflit avec python3-matplotlib-data-3.8.2-2.mga10.noarch, Tentative de promouvoir python3-matplotlib-data, python3-matplotlib-data) python3-opengl-3.1.5-6.mga10.x86_64 (en raison de conflit avec python3-3.12.1-1.mga10.x86_64, Tentative de promouvoir python(abi)) python3-rpm-4.19.0-7.mga10.x86_64 (car rpm[== 1:4.19.0-7.mga10] est non satisfait) rpm-build-4.19.0-7.mga10.x86_64 (car rpm[== 1:4.19.0-7.mga10] est non satisfait) system-config-printer-libs-1.5.18-2.mga10.noarch (car python3dist(pycurl) est non satisfait) system-config-printer-udev-1.5.18-2.mga10.x86_64 (en raison de conflit avec system-config-printer-libs-1.5.18-2.mga10.noarch) Désirez-vous tout de même continuer ? (O/n) ATTENTION : L'option --keep est activée. Des problèmes étranges peuvent se produire Pour satisfaire les dépendances, les paquetages suivants vont être installés : Paquetage Version Révision Arch (média « Core Release ») autocorr-fr 7.6.4.1 3.mga10 noarch cifs-utils 7.0 2.mga10 x86_64 cracklib-dicts 2.9.11 1.mga10 x86_64 gdb-minimal 13.2 5.mga10 x86_64 lib64crack2 2.9.11 1.mga10 x86_64 lib64modulemd2 2.15.0 3.mga10 x86_64 lib64selinux1 3.4 3.mga10 x86_64 lib64semanage2 3.4 5.mga10 x86_64 lib64ssh-devel 0.10.6 1.mga10 x86_64 lib64ssh4 0.10.6 1.mga10 x86_64 lib64xen3.0 4.18.0 4.mga10 x86_64 lib64yui-ncurses16 4.4.4 5.mga10 x86_64 lib64yui-qt16 4.4.4 5.mga10 x86_64 lib64yui16 4.4.4 5.mga10 x86_64 libreofficekit 7.6.4.1 3.mga10 x86_64 libselinux 3.4 3.mga10 x86_64 libsemanage 3.4 5.mga10 x86_64 perl-Net-DNS 1.420.0 1.mga10 noarch pyproject-rpm-macros 1.5.0 24.mga10 noarch xen-licenses 4.18.0 4.mga10 x86_64 (média « Core 32bit Release ») libssh4 0.10.6 1.mga10 i586 un espace additionnel de 955Ko sera utilisé. 7.7Mo de paquets seront récupérés. Procéder à l'installation des 21 paquetages ? (O/n) http://[::1]/distrib/cauldron/x86_64/media/core/release/lib64selinux1-3.4-3.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/lib64yui-ncurses16-4.4.4-5.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/lib64modulemd2-2.15.0-3.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/lib64yui-qt16-4.4.4-5.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/lib64ssh4-0.10.6-1.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/libsemanage-3.4-5.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/xen-licenses-4.18.0-4.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/cifs-utils-7.0-2.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/lib64yui16-4.4.4-5.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/gdb-minimal-13.2-5.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/pyproject-rpm-macros-1.5.0-24.mga10.noarch.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/libreofficekit-7.6.4.1-3.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/cracklib-dicts-2.9.11-1.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/perl-Net-DNS-1.420.0-1.mga10.noarch.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/lib64xen3.0-4.18.0-4.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/autocorr-fr-7.6.4.1-3.mga10.noarch.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/lib64ssh-devel-0.10.6-1.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/lib64crack2-2.9.11-1.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/lib64semanage2-3.4-5.mga10.x86_64.rpm http://[::1]/distrib/cauldron/x86_64/media/core/release/libselinux-3.4-3.mga10.x86_64.rpm http://[::1]/distrib/cauldron/i586/media/core/release/libssh4-0.10.6-1.mga10.i586.rpm installation de lib64yui16-4.4.4-5.mga10.x86_64.rpm xen-licenses-4.18.0-4.mga10.x86_64.rpm cifs-utils-7.0-2.mga10.x86_64.rpm pyproject-rpm-macros-1.5.0-24.mga10.noarch.rpm libreofficekit-7.6.4.1-3.mga10.x86_64.rpm gdb-minimal-13.2-5.mga10.x86_64.rpm cracklib-dicts-2.9.11-1.mga10.x86_64.rpm lib64xen3.0-4.18.0-4.mga10.x86_64.rpm autocorr-fr-7.6.4.1-3.mga10.noarch.rpm perl-Net-DNS-1.420.0-1.mga10.noarch.rpm lib64crack2-2.9.11-1.mga10.x86_64.rpm lib64semanage2-3.4-5.mga10.x86_64.rpm libssh4-0.10.6-1.mga10.i586.rpm lib64ssh-devel-0.10.6-1.mga10.x86_64.rpm libselinux-3.4-3.mga10.x86_64.rpm lib64yui-ncurses16-4.4.4-5.mga10.x86_64.rpm lib64selinux1-3.4-3.mga10.x86_64.rpm lib64modulemd2-2.15.0-3.mga10.x86_64.rpm lib64yui-qt16-4.4.4-5.mga10.x86_64.rpm lib64ssh4-0.10.6-1.mga10.x86_64.rpm libsemanage-3.4-5.mga10.x86_64.rpm depuis /var/cache/urpmi/rpms L'installation a échoué : gdb-headless < 13.2-5.mga10 entre en conflit avec gdb-minimal-13.2-5.mga10.x86_64 lib64modulemd2(x86-64) = 2.15.0-2.mga10 est nécessaire pour (déjà installé) lib64modulemd-gir2.0-2.15.0-2.mga10.x86_64 Certains paquets ont été installés mais d'autres ont échoué. Certains paquetages demandés ne peuvent pas être installés : dnf-data-4.18.1-2.mga10.noarch (afin de garder python3-dnf-4.18.1-1.mga10.noarch) gdb-headless-13.2-5.mga10.x86_64 (afin de garder gdb-13.2-2.mga10.x86_64) lib64comps0-0.1.18-4.mga10.x86_64 (afin de garder python3-libcomps-0.1.18-3.mga9.x86_64) lib64dnf2-0.72.0-2.mga10.x86_64 (afin de garder python3-libdnf-0.72.0-1.mga10.x86_64) lib64gpgme11-1.23.2-2.mga10.x86_64 (afin de garder python3-gpg-1.23.2-1.mga10.x86_64) lib64modulemd-gir2.0-2.15.0-3.mga10.x86_64 (afin de garder python3-libmodulemd-2.15.0-2.mga10.x86_64) lib64peas1.0_0-1.36.0-2.mga10.x86_64 (afin de garder lib64peas1.0_0-loader-python3-1.36.0-1.mga9.x86_64) lib64rpm10-4.19.0-7.mga10.x86_64 (afin de garder rpm-4.19.0-6.mga10.x86_64) libdnf-i18n-0.72.0-2.mga10.noarch (afin de garder lib64dnf2-0.72.0-1.mga10.x86_64) libreoffice-core-7.6.4.1-3.mga10.x86_64 (en raison de conflit avec libreoffice-data-7.6.4.1-3.mga10.x86_64, Tentative de promouvoir libreoffice-data) libreoffice-data-7.6.4.1-3.mga10.x86_64 (afin de garder libreoffice-writer-7.6.4.1-2.mga10.x86_64) libreoffice-opensymbol-fonts-7.6.4.1-3.mga10.noarch (afin de garder libreoffice-core-7.6.4.1-2.mga10.x86_64) libreoffice-ure-7.6.4.1-3.mga10.x86_64 (afin de garder libreoffice-gtk3-7.6.4.1-2.mga10.x86_64) libreoffice-ure-common-7.6.4.1-3.mga10.x86_64 (afin de garder libreoffice-ure-7.6.4.1-2.mga10.x86_64) python3-3.12.1-1.mga10.x86_64 (afin de garder system-config-printer-libs-1.5.18-1.mga9.noarch) python3-matplotlib-data-3.8.2-2.mga10.noarch (afin de garder python3-matplotlib-3.6.2-2.mga9.x86_64) python3-matplotlib-data-fonts-3.8.2-2.mga10.noarch (en raison de conflit avec python3-matplotlib-data-3.8.2-2.mga10.noarch, en raison de conflit avec python3-matplotlib-data-3.8.2-2.mga10.noarch, Tentative de promouvoir python3-matplotlib-data, python3-matplotlib-data) python3-opengl-3.1.5-6.mga10.x86_64 (en raison de conflit avec python3-3.12.1-1.mga10.x86_64, Tentative de promouvoir python(abi)) python3-rpm-4.19.0-7.mga10.x86_64 (car rpm[== 1:4.19.0-7.mga10] est non satisfait) rpm-build-4.19.0-7.mga10.x86_64 (car rpm[== 1:4.19.0-7.mga10] est non satisfait) system-config-printer-libs-1.5.18-2.mga10.noarch (car python3dist(pycurl) est non satisfait) system-config-printer-udev-1.5.18-2.mga10.x86_64 (en raison de conflit avec system-config-printer-libs-1.5.18-2.mga10.noarch) Désirez-vous tout de même continuer ? # And it still doesn't work. dnf up does the work , by not selecting gdb-minimal.