This report refers to the January 9, 2008 version of <http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-linux.xml>. Code listing 1.11 says to emerge coreutils. This step fails because coreutils is downloaded in "lzma" format which cannot be unpacked. The problem can be solved by inserting these commands just before emerging coreutils: emerge --oneshot gnuconfig emerge --oneshot lzma-utils It turns out that gnuconfig is needed when emerging lzma-utils. Without gnuconfig the lzma-utils step fails because config.guess and config.sub are nowhere to be found. Perhaps this should be the subject of a separate bug report (automake should pull in gnuconfig?).
sorry, the linux bootstrap guide is horribly out of date. The order is indeed incorrect, it needs to be more like the solaris bootstrap guide.
The guide may be out of date but it is in fact quit close to working. Right now all I need to do for successful bootstrapping is the lzma workaround, plus I add ACCEPT_KEYWORDS="~x86-linux" to etc/make.conf, plus I add a few lines to package.mask (rsync-3.0.0_pre9, rsync-3.0.0_pre10, gcc-4.3.0).
your masks should be solved by uploading a new image (sparc64-solaris finished bootstrapping on it, so I guess it's sort of ok). The ACCEPT_KEYWORDS should not be necessary, unless the bootstrap script fails to set a profile for you?
(In reply to comment #3) > The ACCEPT_KEYWORDS should not be necessary, unless the bootstrap script fails > to set a profile for you? Confirming, it is not needed, bootstrapping works fine without it this morning.
Ok, I added the changes. A new snapshot is being uploaded right now, so all issues should be addressed then.
I am doing some bootstrapping tests today, using the 20080412 version of prefix portage (according to def="yyyymmdd" in bootstrap-prefix.sh). It turns out that m4 version 1.4.11, which is selected since a few days at most, also comes in lzma format. I have shuffled around the emerge commands accordingly and at the moment my best bet is that 1. gnuconfig and lzma-utils need to be emerged just before m4 2. bash should be deferred until after libtool, or it will complain about a circular dependence 3. lzma-utils should be emerged with --nodeps, or it will mysteriously pull in lots of things (perl, bash, automake)
bleh, this lzma-utils stuff sucks badly.
Yes, it messes things up for prefix portage. But the filesize savings are irresistible I guess. This is the sequence that worked for me today. emerge --oneshot sed emerge --oneshot --nodeps "=autoconf-2.6*" "autoconf-wrapper" emerge --oneshot --nodeps help2man texinfo emerge --oneshot gnuconfig emerge --oneshot --nodeps lzma-utils emerge --oneshot --nodeps "m4" emerge --oneshot --nodeps "=autoconf-2.1*" "=autoconf-2.6*" emerge --oneshot --nodeps "=automake-1.4*" "=automake-1.5*" "=automake-1.6*" "=automake-1.7*" "=automake-1.8*" "=automake-1.9*" "=automake-1.10*" "automake-wrapper" emerge --oneshot --nodeps libtool emerge --oneshot bash env USE="-ssl" emerge --oneshot --nodeps wget emerge --oneshot --nodeps sys-apps/coreutils emerge --oneshot --nodeps python emerge --oneshot --nodeps findutils emerge --oneshot --nodeps tar emerge --oneshot gawk env FEATURES="-collision-protect" emerge --oneshot --nodeps portage emerge --oneshot --nodeps baselayout-prefix ... etc ...
Related, I made a "fix" in m4, not to call eautoreconf, which caused a circular dep. I rereleased the 20080412 snapshot with this fix, not sure if you have it or not, but it would probably remove the need of first doing some autoconf.
This morning bootstrapping failed in a peculiar way. My sequence of emerge commands is the same. When doing the first `emerge -e system' there is a failure when emerging lzma-utils, with these diagnostics: .... checking for objdir... .libs checking for i686-pc-linux-gnu-ar... i686-pc-linux-gnu-ar checking for i686-pc-linux-gnu-ranlib... i686-pc-linux-gnu-ranlib checking for i686-pc-linux-gnu-strip... i686-pc-linux-gnu-strip checking for correct ltmain.sh version... no configure: error: *** [Gentoo] sanity check failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.26, ltmain.sh = 1.5.22) *** Please run: libtoolize --copy --force if appropriate, please contact the maintainer of this package (or your distribution) for help. make: *** [config.status] Error 1 * ERROR: app-arch/lzma-utils-4.32.5 failed:
Isn't the easy way to avoid lzma ? Gnu M4 is still available in gzip or bzip2, so what's the purpose of downloading it using lzma ?
a) bandwidth but most important b) gentoo-x86 does it this way, and I don't want to deviate from that
Some additional observations on the showstopper in Comment #10 (let me state right away that I know very little about the autotool system): - When searching in usr, etc, bin, var, sbin, lib for ltmain.sh I find 2 files, namely usr/share/libtool/ltmain.sh and usr/share/libtool/libltdl/ltmain.sh. Both claim VERSION=1.5.26 although there are differences between the files. - A post-mortem search in app-arch/lzma-utils-4.32.5/work yields yet another file, ./lzma-4.32.5/ltmain.sh. This script claims 1.5.22, which probably explains the error message seen. What to do next?
I didn't see the interix patch actually also patches configure.ac. That makes the build system itself want to reconf itself. I disabled the interix patch for now. Will have to rerelease a new snapshot.
(In reply to comment #14) > I didn't see the interix patch actually also patches configure.ac. That makes > the build system itself want to reconf itself. I disabled the interix patch > for now. Will have to rerelease a new snapshot. > Why not really just create a patch that puts the eautoreconf'd stuff in ?
that's what I suggested in http://bugs.gentoo.org/show_bug.cgi?id=217411#c3
Done with bug#217411.
Is this problem actually resolved? My attempt to bootstrap from scratch this morning failed. The failure looks just like the one described in Comment #10. My sequence of steps follows the 2008-04-12 webpage closely, except that I emerge gnuconfig+lzma-utils before m4, and I defer emerging bash until after libtool.
The following sequences works for me yesterday, just before coreutils : emerge --oneshot autoconf-wrapper emerge --oneshot --nodeps autoconf emerge --oneshot -atv automake emerge --oneshot -atv libtool emerge --oneshot -atv =lzma-utils-4.32.4 emerge --oneshot -atv autoconf
I lost track of what's right and what's wrong. I need to make a new bootstrap image and try bootstrapping.
Like on the latest Solaris bootstrap document, $ emerge --oneshot "<m4-1.4.11" will avoid the circular dependency on todays snapshot.
I tried replacing the existing "emerge --oneshot --nodeps m4" command with the one you suggested but it doesn't work for me. The failure occurs when emerging bash, still complaining about a circular dependence. Maybe it would work if the "emerge m4" is done earlier (before bash). An alternative, which did work for me, is to create an etc/portage/package.mask file before the first emerge and put ">=sys-devel/m4-1.4.11" in it. Later on, e.g. after emerging baselayout-prefix, this entry can be removed from the package.mask file.
yeah, but you have to make sure you don't emerge the latest bash, but the one <3.2_p33 which doesn't do eautoreconf.
I checked my script, it does not mask any bash versions right now. It is actually quite clean, the only small workaround relative to the webpage is the temporary masking of m4. I just discovered that I have a probably obsolete masking of rsync-3.0.0_pre9 and _pre10; I'll remove that as my next step.
yes, but running autotools during bootstrap is really undesired, hence the simple bootstrapping of an older bash. Also, lzma is causing trouble since it needs autotools as well, hence forcing an older m4. In a bootstrap image with stable keywords I'd stable the same packages as now are selected in the latest Solaris guide.
OK, I'll try that approach instead.
I tried to follow the new webpage, dated April 25, 2008, but it does not work for me yet. When the `emerge --oneshot bash' should happen I am getting >>> sys-apps/sed-4.1.5-r1 merged. >>> Auto-cleaning packages... >>> No outdated packages were found on your system. emerge --oneshot bash !!! Problem with sandbox binary. Disabling... Calculating dependencies ... done! [nomerge ] app-shells/bash-3.2_p33 USE="-afs -bashlogger -nls -plugins -vanilla" [nomerge ] sys-devel/automake-1.10.1 [nomerge ] sys-devel/autoconf-2.61-r01.1 USE="-emacs" [ebuild N ] sys-devel/m4-1.4.11 USE="-examples -nls" [ebuild N ] app-arch/lzma-utils-4.32.5 [ebuild N ] sys-devel/libtool-1.5.26 USE="-vanilla" [ebuild N ] sys-devel/automake-1.10.1 [ebuild N ] sys-devel/autoconf-2.61-r01.1 USE="-emacs" !!! Error: circular dependencies: ('ebuild', '/', 'sys-devel/automake-1.10.1', 'merge') depends on ('ebuild', '/', 'sys-devel/autoconf-2.61-r01.1', 'merge') (hard) ('ebuild', '/', 'sys-devel/autoconf-2.61-r01.1', 'merge') depends on ('ebuild', '/', 'sys-devel/m4-1.4.11', 'merge') (hard) ('ebuild', '/', 'sys-devel/m4-1.4.11', 'merge') depends on ('ebuild', '/', 'app-arch/lzma-utils-4.32.5', 'merge') (hard) ('ebuild', '/', 'sys-devel/libtool-1.5.26', 'merge') depends on ('ebuild', '/', 'sys-devel/automake-1.10.1', 'merge') (hard) ('ebuild', '/', 'sys-devel/autoconf-2.61-r01.1', 'merge') (hard) ('ebuild', '/', 'app-arch/lzma-utils-4.32.5', 'merge') depends on ('ebuild', '/', 'sys-devel/automake-1.10.1', 'merge') (hard) ('ebuild', '/', 'sys-devel/autoconf-2.61-r01.1', 'merge') (hard) ('ebuild', '/', 'sys-devel/libtool-1.5.26', 'merge') (hard)
I made a new snapshot that hopefully solves this once and for all.
