if i run: # emerge perl |& tee ~/log it fails on me. it seems to be related to this new warning: ls: ignoring invalid width in environment variable COLUMNS: -1 except coreutils has always worked this way (i checked back to version 7.4, and we're currently at 8.14). so maybe something else has changed to trigger this (bash? portage?). at any rate, adding `unset COLUMNS` to the top of src_configure in the perl ebuild seems to fix things for me ...
Created attachment 295239 [details] emerge --info perl
Created attachment 295241 [details] perl build log
(In reply to comment #0) > if i run: > # emerge perl |& tee ~/log > > it fails on me. it seems to be related to this new warning: > ls: ignoring invalid width in environment variable COLUMNS: -1 > > except coreutils has always worked this way (i checked back to version 7.4, and > we're currently at 8.14). Sorry, i lack the background: What's referenced by "this way"? > so maybe something else has changed to trigger this > (bash? portage?). I think COLUMNS gets exported by mysettings["COLUMNS"] = columns in the following commit in doebuild.py: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=7c5e61b3f44 > at any rate, adding `unset COLUMNS` to the top of src_configure in the perl > ebuild seems to fix things for me ...
the perl configure script is such crap. looks like it fails because it tests stderr output to see if a file exists. for filelist in x??; do (cd "$rsrc"; ls `cat "$tmppwd/$filelist"` \ >/dev/null 2>>"$tmppwd/missing") done although we use `ls` in a few places in the tree which would also trigger this warning. most places shouldn't be using `ls` anyways due to the behavior being changeable based on the user's env. zac: maybe get_term_size() should return 0,0 rather than -1,-1 ?
(In reply to comment #4) > zac: maybe get_term_size() should return 0,0 rather than -1,-1 ? Okay, fixed now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=93c60fc277e37109a4ead36f69a6a50b7f72b229
(In reply to comment #5) > (In reply to comment #4) > > zac: maybe get_term_size() should return 0,0 rather than -1,-1 ? > > Okay, fixed now: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=93c60fc277e37109a4ead36f69a6a50b7f72b229 This is fixed in 2.1.10.40 and 2.2.0_alpha80.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > zac: maybe get_term_size() should return 0,0 rather than -1,-1 ? > > > > Okay, fixed now: > > > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=93c60fc277e37109a4ead36f69a6a50b7f72b229 > > This is fixed in 2.1.10.40 and 2.2.0_alpha80. Zac, this regression in Portage is now breaking stages. Can you please apply this fix to portage-2.1.10.41 or do a new release so we can get it marked stable?
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > (In reply to comment #4) > > > > zac: maybe get_term_size() should return 0,0 rather than -1,-1 ? > > > > > > Okay, fixed now: > > > > > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=93c60fc277e37109a4ead36f69a6a50b7f72b229 > > > > This is fixed in 2.1.10.40 and 2.2.0_alpha80. > > Zac, > > this regression in Portage is now breaking stages. Can you please apply this > fix to portage-2.1.10.41 or do a new release so we can get it marked stable? It's already in 2.1.10.41. You can see the get_term_size commit in the log: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/tags/v2.1.10.41
@perl: The stages are failing to build because of this issue. Can we get a "fixed" version marked stable, please?
Apparently complains about COLUMNS=0 too, so there's a portage patch in git to set it to 80 in that case: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=93c60fc277e37109a4ead36f69a6a50b7f72b229 Meanwhile, I'd suggest to export COLUMNS=0 if you need a workaround for this bug.
(In reply to comment #10) > Apparently complains about COLUMNS=0 too, so there's a portage patch in git to > set it to 80 in that case: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=93c60fc277e37109a4ead36f69a6a50b7f72b229 I meant this commit: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5f5f54b524b22e85c14539a9bb2ce52c7a4e312b
(In reply to comment #11) > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5f5f54b524b22e85c14539a9bb2ce52c7a4e312b This is included in sys-apps/portage-2.1.10.42 and 2.2.0_alpha82, so the COLUMNS=80 workaround should not be necessary starting with these versions.
(In reply to comment #10) > Apparently complains about COLUMNS=0 too, so there's a portage patch in git to > set it to 80 in that case: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=93c60fc277e37109a4ead36f69a6a50b7f72b229 > > Meanwhile, I'd suggest to export COLUMNS=0 if you need a workaround for this > bug. @perl, this is still breaking stages. (In reply to comment #12) > (In reply to comment #11) > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5f5f54b524b22e85c14539a9bb2ce52c7a4e312b > > This is included in sys-apps/portage-2.1.10.42 and 2.2.0_alpha82, so the > COLUMNS=80 workaround should not be necessary starting with these versions. Zac, Would it be ok to get portage-2.1.10.42 marked stable? This is an issue with perl, not portage, but it would allow us to build stages again.
(In reply to comment #13) > Would it be ok to get portage-2.1.10.42 marked stable? This is an issue with > perl, not portage, but it would allow us to build stages again. I'm planning to do that in about 3 weeks.
Created attachment 297547 [details] Unset columns on src_configure @perl: unless you object or fix the underlying test, I'll update perl-5.12.4-r1 with this patch so we can get stages building again until the new portage version is marked stable.
I don't think it is correct to "unset COLUMNS" in the perl ebuilds just because stable portage exports a non-valid COLUMNS value. But if you do not agree, feel free to add it.
As a compromise you could do something like this: [[ ${COLUMNS:-1} -lt 1 ]] && unset COLUMNS
I've patched all of the ebuilds like this: diff -u -b -B -r1.7 perl-5.12.4-r1.ebuild --- perl-5.12.4-r1.ebuild 7 Nov 2011 17:45:03 -0000 1.7 +++ perl-5.12.4-r1.ebuild 2 Jan 2012 22:50:01 -0000 @@ -151,6 +151,7 @@ declare -a myconf export LC_ALL="C" + [[ ${COLUMNS:-1} -ge 1 ]] || unset COLUMNS # bug #394091 # some arches and -O do not mix :) use ppc && replace-flags -O? -O1
Anything left to do here?
i don't think so
