The same specfiles that built properly under 1.0.1-r1 break under 1.0.4 (and 1.0.3). I think something basic is missing, but can't figure out what. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: See the attached logfile.
Created attachment 27126 [details] log of stage1 build apptempt, captured by script This file was captured by the script utility. It's the output from attempting a stage1 build.
The output looks fine to me. I didn't see any problems with the build process - what is your problem again?
1) The build should take about 12 hours on my system. It's finishing in less than 2. 2) Error messages like: >>> emerge (1 of 2) sys-kernel/linux-headers-2.4.21 to /tmp/stage1root/ >>> extracting linux-headers-2.4.21 cat: write error: Broken pipe >>> Merging sys-kernel/linux-headers-2.4.21 to /tmp/stage1root/ and Recalculating the counter... FAILED to update counter. !!! This is a problem. chmod: failed to get attributes of `/tmp/stage1root/var/cache/edb/dep/*': No such file or directory and (at the end) /usr/bin/gcc-config: line 1: /dev/null: No such file or directory /usr/bin/gcc-config: line 1: /dev/null: No such file or directory /usr/bin/gcc-config: line 1: /dev/null: No such file or directory Switching to alpha-unknown-linux-gnu-3.3.2 compiler... Deleting invalid mtimedb key: packages Deleting invalid mtimedb key: eclass bash: line 1: /dev/null: No such file or directory /usr/bin/gcc-config: line 226: /dev/null: No such file or directory If you intend to use the gcc from the new profile in an already running shell, please remember to do: # source /etc/profile bash: line 1: /dev/null: No such file or directoryM >>> Regenerating /etc/ld.so.cache... All of this is leading me to believe that the stage1 build has failed. Has it? If it's taking so little time because the stuff has already been built, how do I clean that out so it starts from scratch? Why the error messages complaining about/dev/null, and are they causing things not to be built? Is there a way to verify the build without going all the way through to stage3 (which will take about another 16 hours) and then discovering that something is missing?
>>All of this is leading me to believe that the stage1 build has failed. Has it? Nope. If catalyst finishes and tarballs the stage, then you are set. >>If it's taking so little time because the stuff has already been built, how do >>I clean that out so it starts from scratch? rm -rf /var/tmp/catalyst/packages/* >>Why the error messages complaining about/dev/null, and are they causing >>things not to be built? They look like errors with gcc-config. Perhaps file a bug about gcc-config spewing those messages? >>Is there a way to verify the build without going all the way through to stage3 >>(which will take about another 16 hours) and then discovering that>> >>something is missing? Not formally, but if the tarball was created ok, it means that all of the packages compiled fine (which should mean that the stage is complete). closing since there is no real catalyst bug here.
