https://bugzilla.redhat.com/show_bug.cgi?id=1762445 --- Comment #6 from John Florian <jflorian@xxxxxxxxxxxxx> --- (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. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ perl-devel mailing list -- perl-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to perl-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
