On Friday 27 January 2006 16:32, MIkey wrote:
> Paul de Vrieze wrote:
> > Would you mind sharing the useflags you mean, and which packages you want
> > to build? It might be bugs in the packages involved.
>
> My standard USE flags for building a lamp server. No X, no cruft.
>
> USE="-X -alsa -apm
Paul de Vrieze wrote:
> Would you mind sharing the useflags you mean, and which packages you want
> to build? It might be bugs in the packages involved.
My standard USE flags for building a lamp server. No X, no cruft.
USE="-X -alsa -apm -arts -avi -cups -doc -eds -emboss -gnome -gpm -gstreamer
MIkey wrote:
> To further educate you, there was a bug shortly after the
> release of 3.4.4 into stable that did, in fact, automatically switch you
> over to the new gcc. It was in the toolchain eclass.
Great, there was a bug. Yeah, there was. Please notice the word "was".
It means that it has be
Stephen P. Becker wrote:
> Which is precisely your problem. You are blindly eating your food
> without contemplating the contents.
Perhaps I am just contemplating a little deeper than you are.
>
>>> pre-existing install != installing from a fresh stage. First, running
>>> bootstrap.sh with t
MIkey wrote:
>>>A bug, again, that the stage1 installation method was immune to,
>>
>>How come? (I'm not familiar with toolchain.eclass at all.)
>
>
> Because the first pass of the bootstrap, that prepares a working gcc/glibc,
> uses the bootstrap USE flag and disables all but a few other basic U
On Thursday 26 January 2006 11:06, MIkey wrote:
> Why should system packages (determined by your profile) be present in the
> world file on official stage1/3 tarballs?
whether they are in the world file itself doesnt really matter
the "world" target includes all the packages listed in the world f
Jan Kundrát wrote:
> MIkey wrote:
>> A bug, again, that the stage1 installation method was immune to,
>
> How come? (I'm not familiar with toolchain.eclass at all.)
Because the first pass of the bootstrap, that prepares a working gcc/glibc,
uses the bootstrap USE flag and disables all but a few
On Thu, Jan 26, 2006 at 10:42:04AM -0600, MIkey wrote:
> Why I explained a couple of posts further down. I could not duplicate the
> problem either, I think it went away in 3.4.4-r1. I don't like posting bug
> reports that I can't duplicate and I prefer to be able to either post a
> patch or sugg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
MIkey wrote:
>
>>As for the stage 1 problems you described, this is exactly what i
>>already told you in the same thread. Supporting stage 1 costs extra
>>resources, this thread is a perfect example of it.
>
>
> And this is the primary point I am ar
On 1/26/06, MIkey <[EMAIL PROTECTED]> wrote:
> Dale wrote:
> I'm not asking for support, I'm giving it.
are you still freaking writing? you have proven yourself ignorant in
at least a dozen emails so far. you don't understand portage. you
don't understand system. you don't understand how to re
Dale wrote:
> I thought that if you chose to do a stage 1 install you were on your
> own. That was my understanding. If that is true, he is getting support
> for something that is not supported, right?
I'm not asking for support, I'm giving it.
--
gentoo-dev@gentoo.org mailing list
Wernfried Haas wrote:
> You already complained about that on the forums [1] in a rather
> similar thread and yet you still haven't filed a bug report about
Why I explained a couple of posts further down. I could not duplicate the
problem either, I think it went away in 3.4.4-r1. I don't like po
Mike Frysinger wrote:
>>
>> Why should system packages (determined by your profile) be present in the
>> official stage1/3 tarballs?
>
> do you even realize what you're asking ?
> -mike
Duh, let me clarify that:
Why should system packages (determined by your profile) be present in the
world fil
13 matches
Mail list logo