Summary: | dev-perl/Params-Validate-1.70.0-r1 fails src_configure CPAN::Meta::YAML 0.011 is not available at /usr/lib64/perl5/5.20.1/CPAN/Meta.pm line 613. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | [OLD] Development | Assignee: | Gentoo Perl team <perl> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=519974 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge log
emerge --depclean -p -v perl-core/CPAN-Meta-YAML |
Description
Toralf Förster
2015-03-04 15:28:31 UTC
same for dev-perl/Test-Class-0.390.0-r1 and dev-perl/Test-Most-0.310.0-r1 > at /usr/lib64/perl5/5.20.1/CPAN/Meta.pm line 613.
= Problem in CPAN::Meta
Please report:
for i in virtual/perl-CPAN-Meta perl-core/CPAN-Meta virtual/perl-CPAN-Meta-YAML perl-core/CPAN-Meta-YAML; do equery l $i; done
Ugh, thought that looked familiar. Its a dup of 540500 which also hasn't been explained. *** This bug has been marked as a duplicate of bug 540500 *** (In reply to Kent Fredric from comment #3) > Ugh, thought that looked familiar. Its a dup of 540500 which also hasn't > been explained. > > *** This bug has been marked as a duplicate of bug 540500 *** ick - forget my own bug list ... (In reply to Kent Fredric from comment #2) > > at /usr/lib64/perl5/5.20.1/CPAN/Meta.pm line 613. > > = Problem in CPAN::Meta > > Please report: > > for i in virtual/perl-CPAN-Meta perl-core/CPAN-Meta > virtual/perl-CPAN-Meta-YAML perl-core/CPAN-Meta-YAML; do equery l $i; done tor-relay / # for i in virtual/perl-CPAN-Meta perl-core/CPAN-Meta virtual/perl-CPAN-Meta-YAML perl-core/CPAN-Meta-YAML; do equery l $i; done * Searching for perl-CPAN-Meta in virtual ... [IP-] [ ] virtual/perl-CPAN-Meta-2.140.640:0 * Searching for CPAN-Meta in perl-core ... !!! No installed packages matching 'perl-core/CPAN-Meta' * Searching for perl-CPAN-Meta-YAML in virtual ... !!! No installed packages matching 'virtual/perl-CPAN-Meta-YAML' * Searching for CPAN-Meta-YAML in perl-core ... [IP-] [ ] perl-core/CPAN-Meta-YAML-0.8.0-r1:0 (In reply to Toralf Förster from comment #5) > virtual/perl-CPAN-Meta-YAML perl-core/CPAN-Meta-YAML; do equery l $i; done > * Searching for perl-CPAN-Meta in virtual ... > [IP-] [ ] virtual/perl-CPAN-Meta-2.140.640:0 > * Searching for CPAN-Meta in perl-core ... > !!! No installed packages matching 'perl-core/CPAN-Meta' > * Searching for perl-CPAN-Meta-YAML in virtual ... > !!! No installed packages matching 'virtual/perl-CPAN-Meta-YAML' > * Searching for CPAN-Meta-YAML in perl-core ... > [IP-] [ ] perl-core/CPAN-Meta-YAML-0.8.0-r1:0 Ooh, that last one definitely shouldn't be installed. Is this the same machine as the other bug? The symptoms look different. ( ie: different CPAN-Meta-YAML packages according to what you've reported ). A pretend depclean as follows would be really helpful now in understanding why it is in tree. emerge --depclean -p -v perl-core/CPAN-Meta-YAML I think this is arising because nothing in your system pulls the virtual, and the virtual ensures removal of spurious perl-core/*. Ugh. This sucks and we need a better solution :/ Also, report what `equery l virtual/perl-ModuleBuild` and `equery l perl-core/Module-Build` you have. Q) How do you have "virtual/perl-CPAN-Meta-2.140.640" but not ">=virtual/perl-CPAN-Meta-YAML-0.11.0" Because here's the relevant part from that ebuild: --- RDEPEND=" || ( =dev-lang/perl-5.20* ~perl-core/${PN#perl-}-${PV} ) !<perl-core/${PN#perl-}-${PV} !>perl-core/${PN#perl-}-${PV}-r999 >=virtual/perl-CPAN-Meta-YAML-0.11.0 >=virtual/perl-JSON-PP-2.271.30 " # see bug 519974 ---- And those lines are there to solve this issue. Your report says you don't have the virtual for CPAN-Meta-YAML, thus you've somehow disabled portage virtual handling (or it seems as such) (In reply to Kent Fredric from comment #7) > Also, report what `equery l virtual/perl-ModuleBuild` and `equery l > perl-core/Module-Build` you have. tor-relay / # equery l perl-core/Module-Build * Searching for Module-Build in perl-core ... [IP-] [ ] perl-core/Module-Build-0.420.500:0 tor-relay / # equery l virtual/perl-ModuleBuild * Searching for perl-ModuleBuild in virtual ... !!! No installed packages matching 'virtual/perl-ModuleBuild' This is a stable chroot, no strange individual changes were made to it, more or lest just CFLAGS and USE were adapted to cover a lot of packages eligible to be installed. Something is *seriously* wrong with your setup ( or portage itself ) then.
Because all the copies of dev-perl/Params-Validate say:
---
>=virtual/perl-Module-Build-0.35
---
Portage, under normal conditions, will refuse to install a package where its dependencies are unsatisfied.
And according to the data you have given me:
a) Portage is emerging Params-Validate
b) virtual/perl-Module-Build is not present
So I don't know where to go from here. ( Please personally verify the contents of Params-Validate-1.70.0-r1.ebuild indeed has
---
DEPEND="${RDEPEND}
>=virtual/perl-Module-Build-0.35
test? (
dev-perl/Test-Fatal
)
"
---
So, can you please dump the contents of `emerge -eavt dev-perl/Params-Validate`.
Because now were possibly in "work out why portage is broken " mode =)
*** Bug 540500 has been marked as a duplicate of this bug. *** Created attachment 398170 [details] emerge log (In reply to Kent Fredric from comment #10) > DEPEND="${RDEPEND} > >=virtual/perl-Module-Build-0.35 > test? ( > dev-perl/Test-Fatal > ) > " > --- > yes it has it > So, can you please dump the contents of `emerge -eavt > dev-perl/Params-Validate`. > attached for sudo ./chr.sh amd64 'emerge -epvt dev-perl/Params-Validate' | tee -a log1.txt Created attachment 398172 [details] emerge --depclean -p -v perl-core/CPAN-Meta-YAML (In reply to Kent Fredric from comment #6) > emerge --depclean -p -v perl-core/CPAN-Meta-YAML attached Hah. Interesting. This indicates you do have virtual/perl-Module-Build already installed, so equery was misleading us for some reason.
( You were running equery on the chroot and not the host right? )
It also indicates that portage *has* decided that it will the offending perl-core/ as part of the update, so the question now remains why that didn't happen sooner.
> [nomerge ] perl-core/Module-Build-0.420.500 USE="{-test}"
> [nomerge ] virtual/perl-CPAN-Meta-YAML-0.12.0
> [blocks b ] <perl-core/CPAN-Meta-YAML-0.12.0 ("<perl-core/CPAN-Meta-YAML-0.12.0" is blocking virtual/perl-CPAN-Meta-YAML-0.12.0)
> [uninstall ] perl-core/CPAN-Meta-YAML-0.8.0-r1
> [ebuild N ] virtual/perl-CPAN-Meta-YAML-0.12.0
In fact, there's a *lot* of uninstall hints there that probably should have been taken already.
Also, can we have a copy of:
grep -E 'virtual/perl-|perl-core' /var/lib/portage/world
from the chroot? Thanks.
You'll have to solve the one real blocker before everything else. As long as there are hard blockers portage can't do much. [blocks B ] <sys-apps/openrc-0.13 ("<sys-apps/openrc-0.13" is blocking sys-fs/udev-init-scripts-27) [blocks B ] <sys-apps/openrc-0.13.8 ("<sys-apps/openrc-0.13.8" is blocking sys-apps/kmod-19) Not perl-related. Guess the first step will be to update openrc. Well, yes, probably that chroot is "full" and therefore the root cause was something different - so I'll move it away into /old and try with a new one. Just FWIW : $> grep -E 'virtual/perl-|perl-core' /var/lib/portage/world is tmpty. *** Bug 543140 has been marked as a duplicate of this bug. *** |