Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 165768 - boot/kernel/gentoo/packages ignored when using cached kernel
Summary: boot/kernel/gentoo/packages ignored when using cached kernel
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: Catalyst (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Catalyst Developers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-07 14:58 UTC by Gruffi Gummi
Modified: 2007-02-19 15:55 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gruffi Gummi 2007-02-07 14:58:49 UTC
Hello, I'm making a livecd that runs kismet.  Builing stage1 works fine.  Building Stage2 works fine for the first time.
I use boot/kernel/gentoo/packages:kismet to make it merge kismet after installing the kernel.  When i try to build stage2 again after that it uses the allready saved kernel, this should be good because it saves time, but it forgets to merge kismet again.

A workaround is to delete /var/tmp/catalyst/packages everytime, but then it compiles the kernel again wich takes up to an hour.

Reproducible: Always

Steps to Reproduce:
0. delete everything in /var/tmp/catalyst
1. build stage1
2. build stage2
3. build stage2 again

Actual Results:  
In the last run kismet is not merged.

Expected Results:  
I expect kismet to be merged.

This command (including -callback=emerge  kismet) is not run when unpacking an allready cached kernel:
"Running with options: --callback=emerge  kismet --no-mountboot --kerneldir=/usr/src/linux --kernel-config=/var/tmp/gentoo.config --minkernpackage=/usr/portage/packages/gk_binaries/gentoo-2006.1.tar.bz2 all"

stage2 file:
subarch:i586
version_stamp:2006.1
target:livecd-stage2
rel_type:default
profile:default-linux/x86/2006.1
snapshot:latest
source_subpath:default/livecd-stage1-i586-2006.1
livecd/cdfstype:zisofs
livecd/archscript:/usr/lib/catalyst/livecd/runscript/x86-archscript.sh
livecd/runscript:/usr/lib/catalyst/livecd/runscript/default-runscript.sh
livecd/cdtar:/usr/lib/catalyst/livecd/cdtar/isolinux-3.09-cdtar.tar.bz2
livecd/iso:/root/gummidrive/gummidrive.iso
livecd/bootargs: dokeymap
livecd/type:generic-livecd
livecd/volid:Gummidrive 2.0
boot/kernel:gentoo
boot/kernel/gentoo/sources:gentoo-sources
boot/kernel/gentoo/config:/root/gummidrive/kernelconfig
boot/kernel/gentoo/use:-X pcmcia usb
#livecd/unmerge: *removed long list here*
#livecd/empty: *removed long list here*
boot/kernel/gentoo/packages:kismet
Comment 1 Andrew Gaffney (RETIRED) gentoo-dev 2007-02-07 17:01:15 UTC
AFAIK, catalyst has no way to know that the boot/kernel/foo/packages option has changed from the last run. This makes it very difficult to do anything about this.
Comment 2 Gruffi Gummi 2007-02-07 17:11:09 UTC
The thing is: it has not changed, kismet is there and stays there.  The packages are never changed.  I just try to make the cd smaller by unmerging stuff.

It should just emerge kismet after unpacking the kernel.  Why does it emerge kismet when i remove the cached kernel in /var/tmp/packages/ (and thus building the same kernel again).  And why doesn't it emerge kismet when it just unpacks a previous kernel.
Comment 3 Chris Gianelloni (RETIRED) gentoo-dev 2007-02-07 23:52:43 UTC
Ugh...

It's LIVECD-STAGE1 and LIVECD-STAGE2!!!

*sigh*

Anyway, this seems a bit strange.  Which options are you using for catalyst.conf?  What version of catalyst are you using?  Without some *basic* information, there's not much else that can be done.  Also, be sure to update to catalyst 2.0.2, if you haven't already.
Comment 4 Gruffi Gummi 2007-02-19 14:11:54 UTC
the bug is no longer there in 2.x
the latest catalyst in my tree was 1.x so that was what i was using.
Comment 5 Chris Gianelloni (RETIRED) gentoo-dev 2007-02-19 15:55:28 UTC
Thanks, we haven't really been doing any work on catalyst 1.x for more than a year.  It is still "supported" insofar as where it works, but no new caode (not even patches) are being made for that branch.  We're hoping to have catalyst 2.0 stable some time soon after the upcoming release.