I want to build a new stage1 for ppc32 with our current tree. But it fails on sys-apps/coreutils-5.94-r1 with a missing perl-file: Making all in sort make[3]: Entering directory `/var/tmp/portage/coreutils-5.94-r1/work/coreutils-5.94/tests/sort' test 'sort' = test && prog=../../src/sort || prog=sort; \ perl -I. -w -- ./../mk-script . $prog > sort-tests.n Can't locate auto/POSIX/assert.al in @INC (@INC contains: . /etc/perl /usr/lib/perl5/vendor_perl/5.8.8/powerpc-linux /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.8.8/powerpc-linux /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/5.8.8/powerpc-linux /usr/lib/perl5/5.8.8 /usr/local/lib/site_perl .) at ./../mk-script line 33 make[3]: *** [sort-tests] Error 255 make[3]: Leaving directory `/var/tmp/portage/coreutils-5.94-r1/work/coreutils-5.94/tests/sort' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/coreutils-5.94-r1/work/coreutils-5.94/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/coreutils-5.94-r1/work/coreutils-5.94' make: *** [all] Error 2 !!! ERROR: sys-apps/coreutils-5.94-r1 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile coreutils-5.94-r1.ebuild, line 103: Called die perl is not installed yet into the /tmp/stage1root. The used 2006.1-stage3 for building the stage1 does not contain that file "assert.al" either: power1 stage1-ppc-2006.1-r1 # ls usr/lib/perl5/5.8.8/powerpc-linux/auto/POSIX/ POSIX.bs POSIX.so autosplit.ix fstat.al load_imports.al stat.al tmpfile.al power1 stage1-ppc-2006.1-r1 # Please note, that perl has been installed with the minimal USE-Flag set for 2006.1, but that USE-flag has been removed from the perl-ebuild after the release (or in the meantime between snapshot-creation and release).
I installed perl in the stage3-buildroot without the build-USE-flag. Now I have the missing file. mcummings said on IRC, that he can remove the file from the list of files which will be removed by using the build-USE-flag. But that does not solve the problem completely, as we don't have the file in the stage3-buildroot. There are two solutions: a) make a "fixed" perl-ebuild DEPEND for coreutils, so that perl will be upgraded in the stage3-buildroot b) try to find out if coreutils can be installed without that file; yuval volunteered for that action ;-)
(In reply to comment #1) > b) try to find out if coreutils can be installed without that file; yuval > volunteered for that action ;-) coreutils would require some ugly hacking to be installed w/o that file :-( Let's consider other possibilities...
*** Bug 151211 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > *** Bug 151211 has been marked as a duplicate of this bug. *** > Still broken on x86 as of 2006-10-27. Wouldn't it be simpler to use some stage3 other than the default (stage3-x86-2006.0.tar.bz2) as the seed? Or do they *all* lack this perl module?
(In reply to comment #4) > Still broken on x86 as of 2006-10-27. Wouldn't it be simpler to use some stage3 > other than the default (stage3-x86-2006.0.tar.bz2) as the seed? Which other seed? We use the seeds from the previous build so that users can do the same like the release-engineering-team and build their own release. As soon as we use 'hacks' it's will not be transparent any more. > Or do they *all* lack this perl module? Seems so.
It must have worked once -- when 2006.1 was released (or re-released). If I use that stage1 and that snapshot, shouldn't it work?
(In reply to comment #6) > It must have worked once -- when 2006.1 was released (or re-released). If I use > that stage1 and that snapshot, shouldn't it work? > Oops -- I meant that stage1 *seed* (stage3).
(In reply to comment #7) > (In reply to comment #6) > > It must have worked once -- when 2006.1 was released (or re-released). If I use > > that stage1 and that snapshot, shouldn't it work? > > > Oops -- I meant that stage1 *seed* (stage3). > Bah ... see bug 153175. Dropping back to the snapshot and stage3 from the 2006.1 release doesn't work either. :(
this is a symptom of perl built with USE=minimal.
Well, I'm building releases weekly and am not running across this. When is your snapshot from? Which stage3 are you using as your seed? I'm using 2006.1's stage3 as a seed. Anyway, stage1's perl *is* built with USE="build" (not USE=minimal, though they're functionally the same) which shouldn't cause an issue unless the profile that you're using to build against is causing coreutils stuff to be pulled in before perl is rebuilt in stage3. If that's the case, it's likely either an issue with your profile, or *somewhere* (yeah, somewhere) in the dependency tree that needs to be looked into. Anyway, this doesn't really fall under release, nor catalyst, so I don't really know where to reassign this.
I don't care any more for that bug. I have a proper seed now with the solution from comment #1 (building perl in the seed-root without USE=build). Yes, I know that breaks update consistency between releases. But I already had to do such a step for 2006.1. And providing no ppc-release is even worse than providing a release which can be reproduced with some manual fixes only.
May not be this: I am using a Pentium/3 for hardened/2005.1/x86 + selinux. To avoid an emerge "world" at the end, I am combining both sets of install instructions. After the first boot - normal add a real user - I use the selinux add base policy, etc. The next instruction is re: emerge sysvinit pam coreutils ... openssh This fails for both pam (#134515) and coreutils (? this one ?). The result a la selinux is a non-bootable system. I got out of that-one, but am well and truly stuck !!!
For me: WRONG problem - DUP: #85879. Cause is mostly features=...test..., but also collision-detect... (maybe) on /bin/chcon and runcon. The starter was 2006.1 with portage tarball and emerge-webrsync as of 2006-12-14. The test failure is in check-recursive for ./src.
*** Bug 171781 has been marked as a duplicate of this bug. ***
Created attachment 114064 [details, diff] [PATCH] Update ebuild to add the required file to the perl minimal installation (with USE="build") This bug is caused because the new coreutils require an additional file from the minimal perl installation (i.e. when perl is built with USE="build"). I am not sure whether the correct fix for this bug should be to fix coreutils to remove the extra requirement, or to include that extra file in the minimal perl install. I have attached a patch which implements the later fix and I have tested this by building a stage1 (using catalyst) based on the 20070319 snapshot of portage.
patch added, thanks ;) Marking closed for now (since his was the first comment in 3 months). Thanks :)
*** Bug 173439 has been marked as a duplicate of this bug. ***
*** Bug 187737 has been marked as a duplicate of this bug. ***
*** Bug 187929 has been marked as a duplicate of this bug. ***
This just happened to me doing an emerge -e system after a stage 1 install.
This just happened to me with 2007.0 stage1 and stage2 images.
