Description of problem: Doing routine package upgrade fails. Version-Release number of selected component (if applicable): perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch How reproducible: 100% (on this host, at least) Steps to Reproduce: $ sudo dnf upgrade Actual results: <snip> Dependencies resolved. Problem: package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch requires perl(:MODULE_COMPAT_5.26.2), but none of the providers can be installed - cannot install both perl-libs-4:5.26.2-410.module_1681+b405d8e2.armv7hl and perl-libs-4:5.28.2-435.fc29.armv7hl - cannot install both perl-libs-4:5.26.2-413.module_2073+eebc5b71.armv7hl and perl-libs-4:5.28.2-435.fc29.armv7hl - cannot install the best update candidate for package perl-libs-4:5.28.2-435.fc29.armv7hl - cannot install the best update candidate for package perl-HTTP-Tiny-0.076-1.fc29.noarch - package perl-libs-4:5.26.3-415.module_2543+eed510a0.armv7hl is excluded =============================================================================================================================================================================================================================================================================== Package Architecture Version Repository Size =============================================================================================================================================================================================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): perl-libs armv7hl 4:5.26.2-410.module_1681+b405d8e2 fedora-modular 1.4 M perl-libs armv7hl 4:5.26.2-413.module_2073+eebc5b71 fedora-modular 1.4 M Skipping packages with broken dependencies: perl-HTTP-Tiny noarch 0.076-1.module_2073+eebc5b71 fedora-modular 55 k Transaction Summary =============================================================================================================================================================================================================================================================================== Skip 3 Packages Nothing to do. Complete! Expected results: For the upgrade to succeed. Additional info: I have done nothing with Fedora Modules on any of my hosts and know little to nothing about them, but this looks like borked packaging dependencies in the default stream.
I cannot reproduce it. "perl" module has no default stream thus it's not enabled by default. You can check it with "dnf module list | grep '^perl\s'". There shouldn't be any [d] or [e] next to the stream identifier. This is what I can see: # dnf module list | grep '^perl\s' | sort perl 5.24 minimal, default Practical Extraction and Report Language perl 5.26 minimal, default [d] Practical Extraction and Report Language perl 5.26 minimal, default [d] Practical Extraction and Report Language perl 5.26 minimal, default [d] Practical Extraction and Report Language perl 5.28 minimal, default [d] Practical Extraction and Report Language perl 5.28 minimal, default [d] Practical Extraction and Report Language perl 5.30 common, minimal, default [d] Practical Extraction and Report Language perl 5.30 common, minimal, default [d] Practical Extraction and Report Language I suspect that you either enabled 5.26 stream by an accident, or set module_hotfixes YUM repository configuration variable, or your repository mirror is broken (e.g. missing a modular metadata), or you found some bug in DNF. You can locate a repository the offending packages comes from with "dnf info perl-HTTP-Tiny" commnd and then check the appropriate modular metadata in /var/cache/dnf/*/repodata/*modules.yaml.gz whether the package is listed under data/artifacts/rpms YAML node.
Actually the package is part of perl-bootstrap:5.26:20180816141919:6c81f848 module. So please check perl-bootstrap modules.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Petr Pisar from comment #1) > "perl" module has no default stream thus it's not enabled by default. You > can check it with "dnf module list | grep '^perl\s'". There shouldn't be any > [d] or [e] next to the stream identifier. This is what I can see: > > # dnf module list | grep '^perl\s' | sort > perl 5.24 minimal, default > Practical Extraction and Report Language > > perl 5.26 minimal, default [d] > Practical Extraction and Report Language > > perl 5.26 minimal, default [d] > Practical Extraction and Report Language > > perl 5.26 minimal, default [d] > Practical Extraction and Report Language > > perl 5.28 minimal, default [d] > Practical Extraction and Report Language > > perl 5.28 minimal, default [d] > Practical Extraction and Report Language > > perl 5.30 common, minimal, default [d] > Practical Extraction and Report Language > > perl 5.30 common, minimal, default [d] > Practical Extraction and Report Language I'm not sure I follow the whole [d] or [e] thing. Yours has a mix of [d] and no [d]. Mine looks the same from what I can tell: $ dnf module list | grep '^perl\s' perl 5.24 minimal, default Practical Extraction and Report Language perl 5.26 minimal, default [d] Practical Extraction and Report Language perl 5.26 minimal, default [d] Practical Extraction and Report Language perl 5.28 minimal, default [d] Practical Extraction and Report Language perl 5.30 common, minimal, default [d] Practical Extraction and Report Language And per your 2nd comment, I guess this is relevant: $ dnf module list | grep '^perl-bootstrap\s' perl-bootstrap 5.24 Perl bootstrap module for bootrapping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootrapping Perl module Here I have no [d], so is that the problem? > I suspect that you either enabled 5.26 stream by an accident, or set > module_hotfixes YUM repository configuration variable Those seem quite unlikely -- I manage everything with puppet and only this one host is affected. > or your repository > mirror is broken (e.g. missing a modular metadata), or you found some bug in > DNF. No idea on these, but the problem continues two weeks later so I'd be inclined to maybe rule out a broken mirror. > You can locate a repository the offending packages comes from with "dnf info > perl-HTTP-Tiny" commnd and then check the appropriate modular metadata in > /var/cache/dnf/*/repodata/*modules.yaml.gz whether the package is listed > under data/artifacts/rpms YAML node. Hmmm... the query reports "From repo : local-fedora" which is my config to a local mirror. But I can't chase that further because I see no such *modules.yaml.gz for this repo. Here's all of them: $ sudo find /var/cache/dnf -name '*modules.yaml.gz' /var/cache/dnf/fedora-modular-454f0a18da8ca968/repodata/9264d8d10ad5a5def81c888fb16bd7ce6b063a259a03af6eac2953f263078527-modules.yaml.gz /var/cache/dnf/updates-modular-fb00c2f37a3d46d7/tmpdir.vUVR7v/repodata/31aee6cab351765d685156ff1f8a3d1b09caaa525bbf5e78c0942289d1964a05-modules.yaml.gz /var/cache/dnf/updates-modular-fb00c2f37a3d46d7/repodata/f472f4b1daad95a6583d847e8454567f586b32b12f6c38d69d8873ec9018b02b-modules.yaml.gz So maybe my mirror is bad, but then that seems easily disproved by ignoring my mirror (and private repo) to use stock Fedora repos: $ sudo dnf upgrade --disablerepo 'local-*' --disablerepo doubledog No read/execute access in current directory, moving to / Last metadata expiration check: 0:00:46 ago on Fri 01 Nov 2019 09:48:43 AM EDT. Dependencies resolved. Problem: package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch requires perl(:MODULE_COMPAT_5.26.2), but none of the providers can be installed - cannot install both perl-libs-4:5.26.2-410.module_1681+b405d8e2.armv7hl and perl-libs-4:5.28.2-435.fc29.armv7hl - cannot install both perl-libs-4:5.26.2-413.module_2073+eebc5b71.armv7hl and perl-libs-4:5.28.2-435.fc29.armv7hl - cannot install the best update candidate for package perl-libs-4:5.28.2-435.fc29.armv7hl - cannot install the best update candidate for package perl-HTTP-Tiny-0.076-1.fc29.noarch - package perl-libs-4:5.26.3-415.module_2543+eed510a0.armv7hl is excluded ====================================================================================================================================== Package Architecture Version Repository Size ====================================================================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): perl-libs armv7hl 4:5.26.2-410.module_1681+b405d8e2 fedora-modular 1.4 M perl-libs armv7hl 4:5.26.2-413.module_2073+eebc5b71 fedora-modular 1.4 M Skipping packages with broken dependencies: perl-HTTP-Tiny noarch 0.076-1.module_2073+eebc5b71 fedora-modular 55 k Transaction Summary ====================================================================================================================================== Skip 3 Packages Nothing to do. Complete!
(In reply to John Florian from comment #4) > I'm not sure I follow the whole [d] or [e] thing. Yours has a mix of [d] > and no [d]. Mine looks the same from what I can tell: > > $ dnf module list | grep '^perl\s' > perl 5.24 minimal, default > Practical Extraction and Report Language > perl 5.26 minimal, default [d] > Practical Extraction and Report Language > perl 5.26 minimal, default [d] > Practical Extraction and Report Language > perl 5.28 minimal, default [d] > Practical Extraction and Report Language > perl 5.30 common, minimal, default [d] > Practical Extraction and Report Language > That's fine. The [d] you can see is for a profile. E.g. perl:5.24 has two profiles "minimal" and "default". And none of the profiles is default. perl:5.26 has the same profiles, but "default" profile is default. What I was interested was [d] or [e] at a stream, compare with a "skim" module: # dnf --quiet module list skim Fedora Modular 29 - x86_64 - Updates Name Stream Profiles Summary skim rolling [d] default [d] Fuzzy Finder in Rust Fedora Modular 29 - x86_64 - Test Updates Name Stream Profiles Summary skim rolling [d] default [d] Fuzzy Finder in Rust Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled > And per your 2nd comment, I guess this is relevant: > > $ dnf module list | grep '^perl-bootstrap\s' > perl-bootstrap 5.24 > Perl bootstrap module for bootrapping Perl module > perl-bootstrap 5.26 > Perl bootstrap module for bootrapping Perl module > > Here I have no [d], so is that the problem? > That's as it should look like. No problem. > > I suspect that you either enabled 5.26 stream by an accident, or set > > module_hotfixes YUM repository configuration variable > > Those seem quite unlikely -- I manage everything with puppet and only this > one host is affected. > So do you have more hosts with the same configuration and only one of them manifests this bug? > > You can locate a repository the offending packages comes from with "dnf info > > perl-HTTP-Tiny" commnd and then check the appropriate modular metadata in > > /var/cache/dnf/*/repodata/*modules.yaml.gz whether the package is listed > > under data/artifacts/rpms YAML node. > > Hmmm... the query reports "From repo : local-fedora" which is my config > to a local mirror. But I can't chase that further because I see no such > *modules.yaml.gz for this repo. Do you I understand correctly, that local-fedora repository contains the perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch.rpm package, but does not have any modular metadata? That could be the cause. By default DNF considers all packages as a non-modular and only those listed in modular metadata as belonging to a module are handled as modular. If a module is active (i.e. enabled or default and not disabled), all packages from that module mask all other same-named packages (even non-modular one). If a module is not active, the packages of that module are not visible and only non-modular packages are considered. I assume that "dnf info perl-HTTP-Tiny" shows two packages for you: perl-HTTP-Tiny-0.076-1.fc29 and perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71. And because "module_2073+eebc5b71" is lexicographically higher than "fc29", DNF wants to upgrade perl-HTTP-Tiny to perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71. > Here's all of them: > > $ sudo find /var/cache/dnf -name '*modules.yaml.gz' > /var/cache/dnf/fedora-modular-454f0a18da8ca968/repodata/ > 9264d8d10ad5a5def81c888fb16bd7ce6b063a259a03af6eac2953f263078527-modules. > yaml.gz > /var/cache/dnf/updates-modular-fb00c2f37a3d46d7/tmpdir.vUVR7v/repodata/ > 31aee6cab351765d685156ff1f8a3d1b09caaa525bbf5e78c0942289d1964a05-modules. > yaml.gz > /var/cache/dnf/updates-modular-fb00c2f37a3d46d7/repodata/ > f472f4b1daad95a6583d847e8454567f586b32b12f6c38d69d8873ec9018b02b-modules. > yaml.gz > Technically DNF somehow merges modular metadata from all repositories, thus DNF should know that the problematic package is modular by getting the metadata from fedora-modular repository. But it's possible there is some bug about the merging in DNF of some of the underlying libraries. I tested my hypothesis by adding the package into a new repository without modular medata and DNF recognized the package as a modular. > So maybe my mirror is bad, but then that seems easily disproved by ignoring > my mirror (and private repo) to use stock Fedora repos: > > $ sudo dnf upgrade --disablerepo 'local-*' --disablerepo doubledog > No read/execute access in current directory, moving to / > Last metadata expiration check: 0:00:46 ago on Fri 01 Nov 2019 09:48:43 AM > EDT. > Dependencies resolved. > > Problem: package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch > requires perl(:MODULE_COMPAT_5.26.2), but none of the providers can be > installed How's it possible? If you disable local-fedora repository, the perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch should not be available because you said it comes from local-fedora repository. Where does "dnf --disablerepo 'local-*' info perl-HTTP-Tiny" find the package? Provided you do not use any modules, you could disable all modular repositories (fedora-modular, updates-modular, updates-testing-modular) and try it again if it helps? Also try deleting all files in /var/cashe/dnf. Maybe the cache is broken. At least I saw a spurious tmpdir.vUVR7v subdirectory there.
(In reply to Petr Pisar from comment #5) > (In reply to John Florian from comment #4) > > I'm not sure I follow the whole [d] or [e] thing. Yours has a mix of [d] > > and no [d]. Mine looks the same from what I can tell: > > > > $ dnf module list | grep '^perl\s' > > perl 5.24 minimal, default > > Practical Extraction and Report Language > > perl 5.26 minimal, default [d] > > Practical Extraction and Report Language > > perl 5.26 minimal, default [d] > > Practical Extraction and Report Language > > perl 5.28 minimal, default [d] > > Practical Extraction and Report Language > > perl 5.30 common, minimal, default [d] > > Practical Extraction and Report Language > > > That's fine. The [d] you can see is for a profile. E.g. perl:5.24 has two > profiles "minimal" and "default". And none of the profiles is default. > perl:5.26 has the same profiles, but "default" profile is default. > > What I was interested was [d] or [e] at a stream, compare with a "skim" > module: > > # dnf --quiet module list skim > Fedora Modular 29 - x86_64 - Updates > Name Stream Profiles Summary > > skim rolling [d] default [d] Fuzzy Finder in > Rust > > Fedora Modular 29 - x86_64 - Test Updates > Name Stream Profiles Summary > > skim rolling [d] default [d] Fuzzy Finder in > Rust > > Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled > > > And per your 2nd comment, I guess this is relevant: > > > > $ dnf module list | grep '^perl-bootstrap\s' > > perl-bootstrap 5.24 > > Perl bootstrap module for bootrapping Perl module > > perl-bootstrap 5.26 > > Perl bootstrap module for bootrapping Perl module > > > > Here I have no [d], so is that the problem? > > > That's as it should look like. No problem. > > > > I suspect that you either enabled 5.26 stream by an accident, or set > > > module_hotfixes YUM repository configuration variable > > > > Those seem quite unlikely -- I manage everything with puppet and only this > > one host is affected. > > > So do you have more hosts with the same configuration and only one of them > manifests this bug? I do, although only one other host is armv7hl, most are typical x86_64. The one other one is locked up apparently as I cannot ssh until I get a chance to reset it. So if it *is* my local mirror at fault, it's only the one arch. > > > You can locate a repository the offending packages comes from with "dnf info > > > perl-HTTP-Tiny" commnd and then check the appropriate modular metadata in > > > /var/cache/dnf/*/repodata/*modules.yaml.gz whether the package is listed > > > under data/artifacts/rpms YAML node. > > > > Hmmm... the query reports "From repo : local-fedora" which is my config > > to a local mirror. But I can't chase that further because I see no such > > *modules.yaml.gz for this repo. > > Do you I understand correctly, that local-fedora repository contains the > perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch.rpm package, but does not > have any modular metadata? Well, I mean I see no other evidence under /var/cache/dnf. I exclude the Modular/ directory in my own mirrors as I don't use it. Maybe that's the problem here? dnf always has seemed to be happy before with that directory excluded but maybe that was a side-effect or luck that it worked. My bandwidth is limited so I was aiming to use public mirrors for Modular if that was ever needed as that might be less demanding than maintaining the mirror of it. > That could be the cause. By default DNF considers all packages as a > non-modular and only those listed in modular metadata as belonging to a > module are handled as modular. If a module is active (i.e. enabled or > default and not disabled), all packages from that module mask all other > same-named packages (even non-modular one). If a module is not active, the > packages of that module are not visible and only non-modular packages are > considered. Hmm... so maybe I really want the Modular metadata local anyway? Possibly to resolve this issue but to speed up dnf use even when not using modules. I'm still a little blurry on when they come into play. The way you worded this, I take it that a module can be active if it's default so long as it's not disabled, which is not to say it simply isn't enabled; sort of a tri-state situation. > I assume that "dnf info perl-HTTP-Tiny" shows two packages for you: > perl-HTTP-Tiny-0.076-1.fc29 and perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71. > And because "module_2073+eebc5b71" is lexicographically higher than "fc29", > DNF wants to upgrade perl-HTTP-Tiny to > perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71. Nope, just the one: $ dnf info perl-HTTP-Tiny doubledog on Fedora 29 - released 27 kB/s | 3.0 kB 00:00 Installed Packages Name : perl-HTTP-Tiny Version : 0.076 Release : 1.fc29 Architecture : noarch Size : 147 k Source : perl-HTTP-Tiny-0.076-1.fc29.src.rpm Repository : @System From repo : local-fedora Summary : Small, simple, correct HTTP/1.1 client URL : https://metacpan.org/release/HTTP-Tiny License : GPL+ or Artistic Description : This is a very simple HTTP/1.1 client, designed for doing simple GET requests : without the overhead of a large framework like LWP::UserAgent. : : It is more correct and more complete than HTTP::Lite. It supports proxies : (currently only non-authenticating ones) and redirection. It also correctly : resumes after EINTR. > > Here's all of them: > > > > $ sudo find /var/cache/dnf -name '*modules.yaml.gz' > > /var/cache/dnf/fedora-modular-454f0a18da8ca968/repodata/ > > 9264d8d10ad5a5def81c888fb16bd7ce6b063a259a03af6eac2953f263078527-modules. > > yaml.gz > > /var/cache/dnf/updates-modular-fb00c2f37a3d46d7/tmpdir.vUVR7v/repodata/ > > 31aee6cab351765d685156ff1f8a3d1b09caaa525bbf5e78c0942289d1964a05-modules. > > yaml.gz > > /var/cache/dnf/updates-modular-fb00c2f37a3d46d7/repodata/ > > f472f4b1daad95a6583d847e8454567f586b32b12f6c38d69d8873ec9018b02b-modules. > > yaml.gz > > > Technically DNF somehow merges modular metadata from all repositories, thus > DNF should know that the problematic package is modular by getting the > metadata from fedora-modular repository. But it's possible there is some bug > about the merging in DNF of some of the underlying libraries. I tested my > hypothesis by adding the package into a new repository without modular > medata and DNF recognized the package as a modular. > > > So maybe my mirror is bad, but then that seems easily disproved by ignoring > > my mirror (and private repo) to use stock Fedora repos: > > > > $ sudo dnf upgrade --disablerepo 'local-*' --disablerepo doubledog > > No read/execute access in current directory, moving to / > > Last metadata expiration check: 0:00:46 ago on Fri 01 Nov 2019 09:48:43 AM > > EDT. > > Dependencies resolved. > > > > Problem: package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch > > requires perl(:MODULE_COMPAT_5.26.2), but none of the providers can be > > installed > > How's it possible? If you disable local-fedora repository, the > perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch should not be available > because you said it comes from local-fedora repository. Where does "dnf > --disablerepo 'local-*' info perl-HTTP-Tiny" find the package? Ooh, good Q! And the answer has me confused: $ dnf --disablerepo 'local-*' info perl-HTTP-Tiny Last metadata expiration check: 0:02:18 ago on Fri 01 Nov 2019 02:50:54 PM EDT. Installed Packages Name : perl-HTTP-Tiny Version : 0.076 Release : 1.fc29 Architecture : noarch Size : 147 k Source : perl-HTTP-Tiny-0.076-1.fc29.src.rpm Repository : @System From repo : local-fedora Summary : Small, simple, correct HTTP/1.1 client URL : https://metacpan.org/release/HTTP-Tiny License : GPL+ or Artistic Description : This is a very simple HTTP/1.1 client, designed for doing simple GET requests : without the overhead of a large framework like LWP::UserAgent. : : It is more correct and more complete than HTTP::Lite. It supports proxies : (currently only non-authenticating ones) and redirection. It also correctly : resumes after EINTR. > > Provided you do not use any modules, you could disable all modular > repositories (fedora-modular, updates-modular, updates-testing-modular) and > try it again if it helps? That does work. I should have mentioned this before. I wasn't sure if the problem would just creep back in this or some other semi-similar issue. > Also try deleting all files in /var/cashe/dnf. Maybe the cache is broken. At > least I saw a spurious tmpdir.vUVR7v subdirectory there. I thought about this too, but was afraid of destroying bug seeking evidence. Too late now. :-) I did a `dnf clean all` but that many dirs under /var/cache/dnf so I clobbered those by hand just to be extra clean. The verdict: $ sudo dnf upgrade No read/execute access in current directory, moving to / Fedora 29 - armhfp 207 kB/s | 56 MB 04:36 Last metadata expiration check: 0:05:18 ago on Fri 01 Nov 2019 03:40:06 PM EDT. Dependencies resolved. Nothing to do. Complete! Your call on what to do with this issue now. I appear to be good, but will be happy to help if you wish to investigate further. I genuinely appreciate the all the Modularity info you've provided here.
Your "dnf info" showed only an already installed package (Repository: @System). The "From repo: local-fedora" is a value remembered when installing the package. It does not have to reflect current location of the package in repositories. It's better to use "dnf --disablerepo=... --enablerepo=... repoquery PACKAGE" to verify where the package is now. But because the modular package was not located with "dnf info", while "dnf upgrade" saw it, I conclude it is some bug in DNF that manifests with some state of the repositories. I will reassign this bug to DNF (it's not specific to perl-HTTP_Tiny package) and close it because it cannot be reproduced. If the problem emerges again, please reopen this issue.