Problem with gnap/catalyst/genkernel and USE-flags

Hi!

My builds fail during livecd-stage2. The part that is
failing is the  
emerge-command run by genkernel after running genkernel and
the  
reason is that i use a different kernel than gentoo sources
and net- 
misc/htbinit is failing because the esfq patch is not
applied to the  
kernel i use. I tried to fix that by adding net-misc/htbinit
-esfq to  
my package.use, but it does not seem to work. Changes
applied to  
package.keywords i did before affect the build. Does the
callback of  
genkernel use package.use? Any other idea how i could fix
this?

Thanks,
	Philipp

Sorry if you get this twice, i use an email address that is
not  
subscribed to the list. Therefore the resend.

On 18.06.2007, at 16:14, Philipp Riegger wrote:

> My builds fail during livecd-stage2. The part that is
failing is  
> the emerge-command run by genkernel after running
genkernel and the  
> reason is that i use a different kernel than gentoo
sources and net- 
> misc/htbinit is failing because the esfq patch is not
applied to  
> the kernel i use. I tried to fix that by adding
net-misc/htbinit - 
> esfq to my package.use, but it does not seem to work.
Changes  
> applied to package.keywords i did before affect the
build. Does the  
> callback of genkernel use package.use? Any other idea
how i could  
> fix this?
>

Ok, i seem to have mixed up the stages. portage_confdir is
used in  
stage3 and livecd-stage1 target, of course, but not in
livecd-stage2.  
Is there any specific reason, why it is not supported (like
the  
documentation says)? What is the right way to set use-flags
for  
genkernels callback function? boot/kernel/[boot/kernel]/use
? What  
does [boot/kernel]
stand for?

Philipp

On 18.06.2007, at 16:29, Philipp Riegger wrote:

> Ok, i seem to have mixed up the stages. portage_confdir
is used in  
> stage3 and livecd-stage1 target, of course, but not in
livecd- 
> stage2. Is there any specific reason, why it is not
supported (like  
> the documentation says)? What is the right way to set
use-flags for  
> genkernels callback function?
boot/kernel/[boot/kernel]/use
? What  
> does [boot/kernel]
stand for?

I got some info on that on IRC. Sorry for the noise, this is
fixed now.

Philipp

On 18.06.2007, at 17:21, Philipp Riegger wrote:

>> Ok, i seem to have mixed up the stages.
portage_confdir is used in  
>> stage3 and livecd-stage1 target, of course, but not
in livecd- 
>> stage2. Is there any specific reason, why it is not
supported  
>> (like the documentation says)? What is the right
way to set use- 
>> flags for genkernels callback function?
boot/kernel/[boot/ 
>> kernel]/use
? What does [boot/kernel]
stand for?
>
> I got some info on that on IRC. Sorry for the noise,
this is fixed  
> now.

Ok, more noise from me. I was asked about how i fixed this
for me and  
when i re-read my email, i figured out, that i don't know
all the  
things i want to know:

The problem i had was due to a use-flag injected in
livecd.conf in  
gnap, the line was more or less
"boot/kernel/gentoo/use: esfq". I  
missed it when i grep'ed my conf dir before, probably some
typing  
mistake in the regex.

So my USE-flag was injected this way, and it did not work
disabling  
it using a portage_confdir, as i stated in the second
email.

But: In livecd-stage2 there is the genkernel callback
function, which  
is in my case a emerge call. I don't know how it is in
general, but  
probably the same. And for this emerge call it might be
quite handy  
to have package.mask and package.keywords. So, why was the
desicion  
made to use boot/kernel/whatever/use instead of
portage_confdir,  
which is much more flexible?

Again, what does the [boot/kernel] in
the documentation stand for?

Thanks a lot,
	Philipp

On Wed, 2007-06-20 at 01:06 +0300, Philipp Riegger wrote:
> But: In livecd-stage2 there is the genkernel callback
function, which  
> is in my case a emerge call. I don't know how it is in
general, but  
> probably the same. And for this emerge call it might be
quite handy  
> to have package.mask and package.keywords. So, why was
the desicion  
> made to use boot/kernel/whatever/use instead of
portage_confdir,  
> which is much more flexible?

Release Engineering *never* uses portage_confdir for our
official builds
and never will.  Everything must reside in the spec file
itself.  The
only reason that portage_confdir exists is for you guys to
allow you to
hack up your own builds in a manner that would be totally
unacceptable,
by Release Engineering standards.

The best/most tested method for changing USE is
boot/kernel/$x/use in
your spec file.

> Again, what does the [boot/kernel] in
the documentation stand for?

Huh?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

On 20.06.2007, at 01:44, Chris Gianelloni wrote:

> The best/most tested method for changing USE is
boot/kernel/$x/use in
> your spec file.
>
>> Again, what does the [boot/kernel] in
the documentation stand for?
>
> Huh?

You call it $x above, the documentation calls it
[boot/kernel]  
(e.g. boot/kernel/[boot/kernel]/use
).

Philipp

On Wed, 2007-06-20 at 13:23 +0300, Philipp Riegger wrote:
> On 20.06.2007, at 01:44, Chris Gianelloni wrote:
> 
> > The best/most tested method for changing USE is
boot/kernel/$x/use in
> > your spec file.
> >
> >> Again, what does the [boot/kernel] in
the documentation stand for?
> >
> > Huh?
> 
> You call it $x above, the documentation calls it
[boot/kernel]  
> (e.g. boot/kernel/[boot/kernel]/use
).

That's completely inconsequential.  I could have called it:
boot/kernel/pinkponies/use and it still means the same
thing.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

On Wed, 2007-06-20 at 15:35 -0700, Chris Gianelloni wrote:
> On Wed, 2007-06-20 at 13:23 +0300, Philipp Riegger
wrote:
> > On 20.06.2007, at 01:44, Chris Gianelloni wrote:
> > 
> > > The best/most tested method for changing USE
is boot/kernel/$x/use in
> > > your spec file.
> > >
> > >> Again, what does the [boot/kernel] in
the documentation stand for?
> > >
> > > Huh?
> > 
> > You call it $x above, the documentation calls it
[boot/kernel]  
> > (e.g. boot/kernel/[boot/kernel]/use
).
> 
> That's completely inconsequential.  I could have called
it:
> boot/kernel/pinkponies/use and it still means the same
thing.
> 

To actually provide an answer:

In your spec you specify boot/kernel: followed by an
arbitrary number of
arbitrary kernel names for your livecd, following that you
are required
to have a block of config options describing each of those
kernels.

So for example, lets take the spec for the 2007.0 release
media for
ppc64. First we specify:

boot/kernel: ibmpower G5

What that states is that we are going to have two kernels on
this CD,
one with the name of ibmpower and the other with the name of
G5.

Next we describe these kernels:

## IBM hardware
boot/kernel/ibmpower/sources: sys-kernel/gentoo-sources
boot/kernel/ibmpower/use: usb extlib
boot/kernel/ibmpower/config:
/2007.0/kernel_configs/installcd-power-gentoo.config
boot/kernel/ibmpower/console: ttyS0,9600 hvc0 hvsi0
boot/kernel/ibmpower/machine_type: ibm
boot/kernel/ibmpower/extraversion: ibm

## Apple hardware
boot/kernel/G5/sources: sys-kernel/gentoo-sources
boot/kernel/G5/use: usb extlib
boot/kernel/G5/config:
/2007.0/kernel_configs/installcd-G5-gentoo.config
boot/kernel/G5/console: ttyS0,57600
boot/kernel/G5/extraversion: G5

As you can see above the third parameter (what Chris calls
$x or
pinkponies and you call [boot/kernel])
comes from the list of kernel
names provided in boot/kernel.

Hope that answers your question.

--Dan

On Wed, 2007-06-20 at 16:08 -0700, Daniel Ostrow wrote:
> Hope that answers your question.

Thanks, Dan.  I didn't realize this was what he was asking.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

On 21.06.2007, at 03:00, Chris Gianelloni wrote:

>> Hope that answers your question.
>
> Thanks, Dan.  I didn't realize this was what he was
asking.

That's exactly it. Thanks a lot. Sorry for the confusing way
of asking.

Philipp