Created attachment 434878 [details] emerge --info '=sys-apps/texinfo-6.1::gentoo' After upgrading perl to 5.24 i ran emerge @preserved-rebuild. texinfo tries to merge but fails.
Created attachment 434880 [details] emerge -pqv '=sys-apps/texinfo-6.1::gentoo'
Created attachment 434882 [details] /var/tmp/portage/sys-apps/texinfo-6.1/temp/build.log
Created attachment 434884 [details] /var/tmp/portage/sys-apps/texinfo-6.1/temp/environment
It is depending on dev-perl/libintl-perl that provides it... but I am unsure if all is properly done there for making it to be rebuilt when perl is bumped :/ I think it is the case as libintl-perl ebuild is not overwriting the default yes value for GENTOO_DEPEND_ON_PERL_SUBSLOT and, then, it should get rebuilt
looks like a problem with dev-perl/libintl-perl
I ran perl-cleaner --all that rebuilt the following packages that included dev-perl/libintl-perl and texinfo emerged fine. sys-apps/texinfo:0 dev-perl/XML-Parser:0 dev-perl/Text-Unidecode:0 dev-perl/XML-Simple:0 dev-perl/XML-SAX-Base:0 dev-perl/libintl-perl:0 dev-perl/XML-NamespaceSupport:0 dev-perl/Unicode-EastAsianWidth:0 dev-perl/XML-SAX:0 dev-perl/XML-LibXML:0
Yeah, but it's supposed we should be able to not need to rely on perl-cleaner :/
Hi Bill, this is one of those mystery bugs that we haven't been able to solve yet... What might be very helpful is to see your emerge history since the last dev-lang/perl update. I.e., install genlop (if you dont have it yet), run genlop -l and add to this bug all lines since and including the build of dev-lang/perl-5.24.0 ... TIA!
*** Bug 567552 has been marked as a duplicate of this bug. ***
*** Bug 575960 has been marked as a duplicate of this bug. ***
Created attachment 435364 [details] genloop -l
(In reply to bill from comment #11) > Created attachment 435364 [details] > genloop -l Thanks but... (and sorry if I was unclear)... the interesting part is the one after perl-5.24 :)
Oups, my bad. Here is the log from perl-5.24 up to the rebuild of texinfo & libintl caused by perl-cleaner.
Created attachment 435590 [details] genloop -l
does `perl -MLocale::Messages -e1` have any problems when run as the portage user?
(In reply to Kent Fredric from comment #15) > does `perl -MLocale::Messages -e1` have any problems when run as the portage > user? Everything seems fine. (no output)
(In reply to Pacho Ramos from comment #7) > Yeah, but it's supposed we should be able to not need to rely on > perl-cleaner :/ It seems this is what happens with every major perl upgrade. At least 5.22 -> 5.24 wasn't as bad as 5.20 -> 5.22...
(In reply to Joshua Kinard from comment #17) I made it now generic here at my tinderbox : https://github.com/toralf/tinderbox/commit/2654d69813ca9bd1f9e8dc96e23ce356da863bd6
(In reply to bill from comment #14) > Created attachment 435590 [details] > genloop -l Sat May 21 01:04:18 2016 >>> dev-lang/perl-5.24.0 [...] Tue May 24 21:21:41 2016 >>> dev-perl/libintl-perl-1.240.0 Tue May 24 21:21:44 2016 >>> dev-perl/Unicode-EastAsianWidth-1.330.0-r1 Tue May 24 21:21:48 2016 >>> dev-perl/XML-SAX-0.990.0-r1 Tue May 24 21:22:14 2016 >>> sys-apps/texinfo-6.1 Uh, this is seriously weird. You clearly have new perl, then libintl-perl is rebuilt, and afterwards texinfo fails.
OK I found out what might be causing this. If you look into the source of libintl-perl you find this nice comment: # FIXME: This is really a hack! Problem: Depending on the build system, # we may or may not build and install the XS version. If the XS version # is being built, the directory blib/arch will be populated, if it is # not being built, blib/arch will be empty. Unfortunately, if blib/arch # is not empty, *all* library files will be installed in the architecture # dependent locations, if it is empty, they will be installed in the # architecture independent tree. # # Unfortunately, ExtUtils::MakeMaker does not take care of uninstalling # files from previous installations. Consequently, we cannot determine # which version of the library will be loaded, since this depends on the # current value of @INC. # # The solution does not really make me happy. The Makefile will be patched, # so that instead of ExtUtils::Install a custom module MyInstall.pm will # be used. This custom module overwrites the subroutine that detects # whether a directory is empty in ExtUtils::Install, and will lie if that # directory happens to be "blib/arch". This little hack effectively disables # the annoying behavior of ExtUtils::Install (and I sincerely hope that # this is portable). Basically upstream is trying to sanitize Perl native installation and does weird stuff. I haven't got a proof yet that this causes our problem, since the situation (in the middle of a Perl upgrade) is hard to reproduce. However, I've pushed dev-perl/libintl-perl-1.240.0-r1 where the weirdness is patched out and the build system is reduced to the essentials. Please test. Toralf, it would be great if you could run a test with a Perl update where this libintl-perl version is visible and no specific hacks are applied.
Let's hope it works for the people who have not updated yet. :)
(In reply to Andreas K. Hüttel from comment #20) will do - BTW I had a braino too over this weekend therefore a test image is now (few minutes ago) *really* started
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=74b555904aae62f64a5c48085d30195a4c1ee6a8 commit 74b555904aae62f64a5c48085d30195a4c1ee6a8 Author: Kent Fredric <kentnl@gentoo.org> AuthorDate: 2018-04-01 19:45:27 +0000 Commit: Kent Fredric <kentnl@gentoo.org> CommitDate: 2018-04-01 19:45:27 +0000 dev-perl/libintl-perl: Cleanup old re bug #613804 Closes: https://bugs.gentoo.org/613804 Closes: https://bugs.gentoo.org/583674 Package-Manager: Portage-2.3.24, Repoman-2.3.6 dev-perl/libintl-perl/Manifest | 1 - .../libintl-perl/libintl-perl-1.200.0-r1.ebuild | 30 -------------------- dev-perl/libintl-perl/libintl-perl-1.240.0.ebuild | 33 ---------------------- 3 files changed, 64 deletions(-)
