On Line 278 of bootstrap.sh the STAGE1_USE flags that are supposed to be supported (lines 195-222) during the bootstrap (nls, nptl, nptlonly, multilib, userlocales) are overwritten by the eval'ed python command on line 278 when STAGE1_USE is empty in the profile (which is by default). The FAQ tells users to modify this script for their own needs but does not indicate that the script itself has a glaring bug that will prevent nptl, multilib, nls, and userlocales from being applied during the bootstrap phase of the script. This "bug" can be verified by changing the assignment of the --pretend argument in STRAP_EMERGE_OPTS on line 76 from -p to -pv and running the bootstrap. It clearly shows that the USE flags present in make.conf are not set during the build of the package.
Created attachment 78079 [details, diff] The Fix
Created attachment 78084 [details, diff] A different approach With that change, we never get the value of the profile's STAGE1_USE anywhere. Perhaps something a little different?
(In reply to comment #2) > Created an attachment (id=78084) [edit] > A different approach > > With that change, we never get the value of the profile's STAGE1_USE anywhere. > > Perhaps something a little different? > Actually, to avoid confusion, perhaps it should be something along the lines ALLOWED_BOOTSTRAP_USE, since it won't apply to the subsequent emerge -e system. Shouldn't the usage of STAGE1_USE be local to catalyst anyway?
I don't see a point in calling it ALLOWED_BOOTSTRAP_USE, at all. I think it is fairly explanatory. As for STAGE1_USE, not really. It is almost a misnomer, since STAGE1_USE are things that should be in all stages. The reason why we never ran across this bug is because in all stages we build, there is nothing in STAGE1_USE that isn't *also* in USE by default. Basically, STAGE1_USE is for things that should be in stage1 that are required for that optional capability later. It would probably be best to simply skip everything from STAGE1_USE and give a slightly larger list of allowed flags (pam, unicode, gcc64) instead. Perhaps that would clear up some of the confusion?
(In reply to comment #4) > fairly explanatory. As for STAGE1_USE, not really. It is almost a misnomer, > since STAGE1_USE are things that should be in all stages. The reason why we > never ran across this bug is because in all stages we build, there is nothing > in STAGE1_USE that isn't *also* in USE by default. Basically, STAGE1_USE is > for things that should be in stage1 that are required for that optional > capability later. It would probably be best to simply skip everything from > STAGE1_USE and give a slightly larger list of allowed flags (pam, unicode, > gcc64) instead. Perhaps that would clear up some of the confusion? As far as I know the bootstrap phase of a stage1 build is the only place that the build and bootrap USE flags are utilized, which is what distinguishes a stage1 install. The only other location that I have ever noticed the usage of STAGE1_USE is in catalyst, no other utility sets/reads that variable, unless you know something I don't (which is very likely). Obviously bootstrap.sh has never actually used it. What the variable name should reflect is that it contains the only USE flags that should be set along with the bootstrap/build flags during the bootstrap phase, i.e. USE flags that effect the toolchain and other packages built during the bootstrap phase.... You can call it BIG_MOMMA for all I care. I just want it to work :)
(In reply to comment #5) > As far as I know the bootstrap phase of a stage1 build is the only place that > the build and bootrap USE flags are utilized, which is what distinguishes a This is completely inaccurate. The build USE flag is utilized by catalyst when *building* a stage1 tarball, not during the course of a stage1 installation. Yes, I know that portage uses it once in bootstrap.sh, but it is designed for the process of building a stage1 tarball itself, not installing from one. > stage1 install. The only other location that I have ever noticed the usage of > STAGE1_USE is in catalyst, no other utility sets/reads that variable, unless > you know something I don't (which is very likely). Obviously bootstrap.sh has > never actually used it. It definitely *has* used it. Want an example? Add STAGE1_USE="nptl" to a profile, then bootstrap. It will be used. What wasn't happening, was STAGE1_USE from the profile was overriding the STAGE1_USE that we were appending in the bootstrap script itself. > What the variable name should reflect is that it contains the only USE flags > that should be set along with the bootstrap/build flags during the bootstrap > phase, i.e. USE flags that effect the toolchain and other packages built during > the bootstrap phase... The variable name means exactly 0, really. > You can call it BIG_MOMMA for all I care. I just want it to work :) I was thinking something a little more meaningful to myself, like FSCKING_USE or something... :P Anyway, I need to determine what to do with this simply because we have already created the snapshot for 2006.0 and I need to figure out if I want to make changes to bootstrap at this time and possibly incur further delays in our release builds. One thing that this does prove is that we don't really *need* the ALLOWED_USE, at all, since they were never being used in the first place. Perhaps it would be better to completely remove that capability, sticking with simply pulling from the profile, which is much cleaner IMO and reduces possible locations for errors to occur. I'm going to discuss this with some of the other release engineers before making a decision on it.
> I was thinking something a little more meaningful to myself, like FSCKING_USE > or something... :P > > Anyway, I need to determine what to do with this simply because we have already > created the snapshot for 2006.0 and I need to figure out if I want to make > changes to bootstrap at this time and possibly incur further delays in our > release builds. One thing that this does prove is that we don't really *need* It shouldn't affect your stages at all since you use catalyst to build them. The only difference will be that stage1 will not have nptl, it can't anyway, unless you hacked glibc to allow nptl with an i386 chost. > the ALLOWED_USE, at all, since they were never being used in the first place. > Perhaps it would be better to completely remove that capability, sticking with > simply pulling from the profile, which is much cleaner IMO and reduces possible > locations for errors to occur. I'm going to discuss this with some of the > other release engineers before making a decision on it. Pulling from the profile might be simpler for you, but not for the users who build systems or custom stages directly from stage1 (without catalyst). It would be an extremely simple fix to just remove the STAGE1_USE from the python eval loop. This is gentoo, not gnometoo :)
(In reply to comment #7) > It shouldn't affect your stages at all since you use catalyst to build them. > The only difference will be that stage1 will not have nptl, it can't anyway, > unless you hacked glibc to allow nptl with an i386 chost. Please don't bother commenting on things that you aren't familiar with, it doesn't help in any way. What I meant was the other architectures that have things in STAGE1_USE *other* than nptl. Please try to understand that I am more concerned with the global implications of making bootstrap changes than you appear to be. > Pulling from the profile might be simpler for you, but not for the users who > build systems or custom stages directly from stage1 (without catalyst). We are currently pulling from the profile. This is not going to change. What we are not doing currently is allowing for changes to be made in make.conf to actually effect the output of the bootstrap process. This is a bug, but your solution to the bug is not the one I'm interested in using. > It would be an extremely simple fix to just remove the STAGE1_USE from the > python eval loop. This is gentoo, not gnometoo :) However, doing so would be incorrect, as I stated before. I really don't know what the reference to Gnome was supposed to mean, but there's really no place for it here. You also need to remember that just because you want something does not mean that we have to accept it or implement it. That is the joy of open source, you can do your own thing and we can take it or leave it.
(In reply to comment #8) > Please don't bother commenting on things that you aren't familiar with, it > doesn't help in any way. What I meant was the other architectures that have Hey, I'm familiar enough with it to see that there is a major bug in it. It ain't rocket science. > for it here. You also need to remember that just because you want something > does not mean that we have to accept it or implement it. That is the joy of > open source, you can do your own thing and we can take it or leave it. Oh don't worry, I won't make that mistake... I'm just reporting the bug, it's your baby.
I've added my patch to CVS...
(In reply to comment #10) > I've added my patch to CVS... > Thank you Chris.
