[Bug 1762445] 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
https://bugzilla.redhat.com/show_bug.cgi?id=1762445 Petr Pisar changed: What|Removed |Added Status|NEW |CLOSED CC||dm...@redhat.com, ||jmra...@redhat.com, ||jro...@redhat.com, ||mbl...@redhat.com, ||mhat...@redhat.com, ||packaging-team-maint@redhat ||.com, pkrat...@redhat.com, ||rpm-software-management@lis ||ts.fedoraproject.org, ||vmukh...@redhat.com Component|perl-HTTP-Tiny |dnf Resolution|--- |WORKSFORME Assignee|ppi...@redhat.com |rpm-software-management@lis ||ts.fedoraproject.org Last Closed||2019-11-04 09:05:06 --- Comment #7 from Petr Pisar --- 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. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762445] 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
https://bugzilla.redhat.com/show_bug.cgi?id=1762445 --- Comment #6 from John Florian --- (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' > > perl5.24 minimal, default > > Practical Extraction and Report Language > > perl5.26 minimal, default [d] > > Practical Extraction and Report Language > > perl5.26 minimal, default [d] > > Practical Extraction and Report Language > > perl5.28 minimal, default [d] > > Practical Extraction and Report Language > > perl5.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 > NameStreamProfiles Summary > > skimrolling [d] default [d] Fuzzy Finder in > Rust > > Fedora Modular 29 - x86_64 - Test Updates > NameStreamProfiles Summary > > skimrolling [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
[Bug 1762445] 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
https://bugzilla.redhat.com/show_bug.cgi?id=1762445 --- Comment #5 from Petr Pisar --- (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' > perl5.24 minimal, default > Practical Extraction and Report Language > perl5.26 minimal, default [d] > Practical Extraction and Report Language > perl5.26 minimal, default [d] > Practical Extraction and Report Language > perl5.28 minimal, default [d] > Practical Extraction and Report Language > perl5.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 NameStreamProfiles Summary skimrolling [d] default [d] Fuzzy Finder in Rust Fedora Modular 29 - x86_64 - Test Updates NameStreamProfiles Summary skimrolling [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
[Bug 1762445] 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
https://bugzilla.redhat.com/show_bug.cgi?id=1762445 --- Comment #4 from John Florian --- (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 > perl5.24 minimal, default > Practical Extraction and Report Language > > perl5.26 minimal, default [d] > Practical Extraction and Report Language > > perl5.26 minimal, default [d] > Practical Extraction and Report Language > > perl5.26 minimal, default [d] > Practical Extraction and Report Language > > perl5.28 minimal, default [d] > Practical Extraction and Report Language > > perl5.28 minimal, default [d] > Practical Extraction and Report Language > > perl5.30 common, minimal, default [d] > Practical Extraction and Report Language > > perl5.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' perl5.24 minimal, default Practical Extraction and Report Language perl5.26 minimal, default [d] Practical Extraction and Report Language perl5.26 minimal, default [d] Practical Extraction and Report Language perl5.28 minimal, default [d] Practical Extraction and Report Language perl5.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
[Bug 1762445] 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
https://bugzilla.redhat.com/show_bug.cgi?id=1762445 --- Comment #3 from Ben Cotton --- 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. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762445] 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
https://bugzilla.redhat.com/show_bug.cgi?id=1762445 --- Comment #2 from Petr Pisar --- Actually the package is part of perl-bootstrap:5.26:20180816141919:6c81f848 module. So please check perl-bootstrap modules. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762445] 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
https://bugzilla.redhat.com/show_bug.cgi?id=1762445 --- Comment #1 from Petr Pisar --- 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 perl5.24 minimal, default Practical Extraction and Report Language perl5.26 minimal, default [d] Practical Extraction and Report Language perl5.26 minimal, default [d] Practical Extraction and Report Language perl5.26 minimal, default [d] Practical Extraction and Report Language perl5.28 minimal, default [d] Practical Extraction and Report Language perl5.28 minimal, default [d] Practical Extraction and Report Language perl5.30 common, minimal, default [d] Practical Extraction and Report Language perl5.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. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
