| 1 |
On Wed, 2005-12-14 at 16:20 -0600, Mikey wrote: |
| 2 |
> > No, you do what I said and make a profile. I am honestly getting a |
| 3 |
> > little frustrated with having to repeat this. With a proper profile, |
| 4 |
> > you can have a stage2/stage3 with nptl. It isn't possible to have a |
| 5 |
> > stage1 with nptl on x86, since nptl isn't ported to i386 CHOST. Look at |
| 6 |
> > default-linux/x86/dev/2006.0 as a good example, as we're using nptl by |
| 7 |
> > default there. |
| 8 |
> |
| 9 |
> Is stage4 ok with nptl in the USE flags? Or am I going to HAVE to go the |
| 10 |
> profile route to get nptl? You can't stick nptl in the profile and expect |
| 11 |
> generic x86 arch builds to work, unless the chost was changed... |
| 12 |
|
| 13 |
*Only* if stage4 is your final target. As for nptl, it is 100% safe |
| 14 |
even with CHOST=i386 because glibc ignores it. Also, don't set |
| 15 |
STAGE1_USE="nptl"... If you would look at the example that I told youto, |
| 16 |
you would realize this. |
| 17 |
|
| 18 |
> It is still broken. I won't bother to file any more bug reports about it. |
| 19 |
> You can try building a stage1-x86 from the stage3-x86 yourself if you want |
| 20 |
> to verify, or you can wait for a release to break, or whatever. It keeps |
| 21 |
> trying to install glibc in /tmp/stage1root, before linux-headers, and the |
| 22 |
> glibc build keeps looking for those headers to be present |
| 23 |
> in /tmp/stage1root. The weird thing about it is that before the actual |
| 24 |
> emerge start it indicates the headers will be installed first, then |
| 25 |
> proceeds to do glibc before. Maybe it is a circular dependency, I don't |
| 26 |
> know. I am sick of screwing with it, I just mounted everything and |
| 27 |
> installed the headers into /tmp/stage1root and resumed. Maybe it is just a |
| 28 |
> bug somewhere in the snapshot from 20051205, I don't know. I give up. |
| 29 |
|
| 30 |
It is a bug in the snapshot/tree, as I stated in bug #115445. I'm |
| 31 |
almost getting tired of explaining things seeing as how I have to do it |
| 32 |
multiple times. Rather than me repeating myself, please read each |
| 33 |
message a few times instead? ;P |
| 34 |
|
| 35 |
The issue is something with the tree that is being investigated. I was |
| 36 |
unable to reproduce it because I am using an older snapshot for my |
| 37 |
builds. I also mentioned this in the aforementioned bug. I guess you |
| 38 |
missed it. |
| 39 |
|
| 40 |
> > Unfortunately, in many cases, catalyst is a "fix it yourself" |
| 41 |
> > application. If it doesn't break our release-building, it is reduced in |
| 42 |
> > priority, as catalyst is first and foremost our release-building tool. |
| 43 |
> |
| 44 |
> Just out of curiosity, WHY is it designed to be so inflexible as far as use |
| 45 |
> flags in stage2? The bootstrap.sh in stage2 strips all use flags except |
| 46 |
|
| 47 |
Because making changes outside of the scope of the profile is broken. |
| 48 |
It produces an inconsistent stage, since the USE flags passed via an |
| 49 |
envscript *never* see the inside of make.conf, giving you a stage that |
| 50 |
*will not* behave as you expect it to. Why leave this option available |
| 51 |
when it is *obviously* misunderstood and causes errors? You have proven |
| 52 |
here exactly *why* the option is not there. |
| 53 |
|
| 54 |
> nls, userlocales, nptl, nptlonly, multilib I think, and runs with USE="-* |
| 55 |
> build bootstrap allowed_flags", so why the restriction from using nptl and |
| 56 |
|
| 57 |
There is no such restriction, as stated over and over and over and over |
| 58 |
again. Use a profile to make these changes. |
| 59 |
|
| 60 |
> such in the stage2 via catalyst? And stage3 for that matter. I am not |
| 61 |
> trying to be facetious here, I am just wondering what the reasoning behind |
| 62 |
> the design is... |
| 63 |
|
| 64 |
No, you're being dense, rather. I have explained it. You just seem to |
| 65 |
dislike my answer. Stages 2 and 3 must match the profile or they will |
| 66 |
not install properly in all cases. Period. |
| 67 |
|
| 68 |
> > Patches are always welcome, however. |
| 69 |
> |
| 70 |
> Believe me, you wouldn't like what patches I would have in mind :) |
| 71 |
|
| 72 |
Then I wouldn't accept them. Catalyst is modular. You're more than |
| 73 |
welcome to replace any of the scripts to do things the way you want |
| 74 |
them. Just don't come asking us for help when you do things that we |
| 75 |
know will not work as expected. We are not stupid. We have been |
| 76 |
working with portage and Gentoo for a long time and know what is and is |
| 77 |
not possible quite well by now. |
| 78 |
|
| 79 |
-- |
| 80 |
Chris Gianelloni |
| 81 |
Release Engineering - Strategic Lead |
| 82 |
x86 Architecture Team |
| 83 |
Games - Developer |
| 84 |
Gentoo Linux |
Archives