[08:48] <Hobbsee> is it intentional that all jaunty upgrades pull lilo in by default, due to the kernel?
[10:19] <apw> Hobbsee, i am not aware of our dependancies changing specifically on lilo
[10:21] <apw> yep, our specified dependancies have not changed from Intrepid to Jaunty
[10:21] <apw> debian/control.stub:Recommends: lilo (>= 19.1) | grub
[10:21] <apw> would we expect that form to force lilo on?  that sounds bad to me
[10:22] <apw> (and wrong)
[10:30] <Hobbsee> apw: well, I suspect it's a bug in intrepid upgrades too then
[10:31] <Hobbsee> i'm not sure if it actually turns lilo on or not, but installing two boot loaders by a normal dist-upgrade seems...strange?
[10:34] <apw> frankly i would expect them to conflict: with each other
[10:35] <Hobbsee> they don't seem to (as that's what I'd expect too). how strange.
[10:35] <apw> Hobbsee, as the kernel only recommends them surly that wouldn't ever install them?  do we not rely on the d-i at first install to have picked one, and normal upgrades to keep that one up to datge
[10:36] <Hobbsee> apw: a dist-upgrade installs recommends for new packages by default, i think.  and the new kernel qualifies as a new (binary) package.
[10:37] <Hobbsee> (it keeps the metapackages right, but the bit that recommends grub itself is actually the kernel image binary, which keeps changing)
[10:37] <apw> Hobbsee, hmmm well that might allow it to install one or the other, but i would hope that it would only install recommends with 'or' in them if one was not already installed
[10:38] <apw> i wonder if apt has changed behaviour somewhere
[10:39] <Hobbsee> apw: indeed.  it would be odd that apt doesn't say "the second is installed, don't install hte first"
[10:39]  * apw wonders if there is any magic in update-manager to solve this
[10:39] <apw> that makes it feel like a bug, but a bug in the update
[10:40] <Hobbsee> could be.  I didn't use update-manager
[10:40]  * apw gets the source
[10:51] <apw> Hobbsee, is your dual installed machine 32 or 64 bit?
[10:51] <Hobbsee> apw: 32
[10:51]  * apw notes his 32 bit Intrepid install has both installed
[10:51] <apw> but his 64 does not
[10:51] <Hobbsee> i clean installed intrepid today, then dist-upgraded it
[10:51] <Hobbsee> got jaunty, and lilo installed
[10:51] <Hobbsee> haven't rebooted it yet.
[10:52] <apw> well i have a laptop here (32 bit) which was installed from the Intrepid final CD and only has official updates on it
[10:52] <apw> and that also has both loaders installed
[10:52] <apw> my other laptop installed from the amd64 CD image only has grub
[10:53]  * apw is suspicious of the 32 bit installer now
[10:53] <Hobbsee> did you dist-upgrade it?
[10:54] <Hobbsee> oh, wait, i misread you sorry
[10:54] <apw> nope this was a virgin install from a CD, and the most it has is -proposed enabled
[10:54] <apw> always updated using update-manager
[10:54] <Hobbsee> very strange.
[10:54] <apw> proper user stylee, and it seems to be infected with both
[10:55] <apw> yes it does have proposed enabled too
[10:58] <apw> according to the logs in /var/log/apt, it was installed in the initial install burst
[11:28] <dholbach> hello my Kernel friends!
[11:28] <dholbach> who of you would like to give a session at the next Ubuntu Developer Week? something about module packaging with DKMS maybe?
[11:28] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
[11:29] <dholbach> is the preliminary schedule
[11:56] <Keybuk> Thought of the day:
[11:56] <Keybuk> what happens if init calls clone() with CLONE_PARENT? :p
[11:58] <dholbach> hey Keybuk
[11:58] <mjg59> Keybuk: Looks like failure
[11:58] <dholbach> Keybuk: you could give a session about upstart at Ubuntu Developer Week - what do you think?
[11:59] <Keybuk> mjg59: the clone() doesn't look like it'll fail?
[11:59] <Keybuk> but it looks like if that process exited, lots of things assume that real_parent is not 0?
[11:59] <mjg59> Keybuk: Right
[12:00] <mjg59> Hence, failure :)
[12:00] <Keybuk> in fact, it looks like there's lots of -> after that ;)
[12:00] <Keybuk> definitely a "don't do that, then"
[12:00] <mjg59> I think it's assumed that anyone writing init can already DoS the system whenever they want to
[12:23] <apw> Keybuk, i concur with your analysis, bad karma will result from that
[12:23] <apw> i suspect a very simple fix is possible, and probabally desirable
[12:24] <Keybuk> *shrug* I tend to agree with mjg59 here ;)
[12:24] <Keybuk> very few people write init daemons, and those who do already need to know about various special behaviours
[12:26] <apw> i tend to be suspicious of anything which allows user space to blow the kernel up
[12:26] <apw> yeah you are already winning if you can run init, but hey
[12:28] <Keybuk> I can blow the kernel up from init easily ;)
[12:28] <mjg59> exit(-1)
[12:29] <Keybuk> just one function call ... exit()
[12:31] <apw> yeah i know, but that is 'deliberate' it is designed.  this is a blammo, they are unsatisfactory at best
[12:32] <apw> i am sure linus would agree with you
[14:27] <dholbach> BenC: would you like to give a session at the next Ubuntu Developer Week? something about module packaging with DKMS maybe? :)
[14:27] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
[14:27] <dholbach> it'd be nice to have something like a "hands on" session where people could get involved in the kernel team somehow
[14:27] <BenC> dholbach: I did dkms last time :) you want a new topic?
[14:28] <dholbach> BenC: I could imagine that it's still interesting - if you have something better ... sure :)
[14:29] <dholbach> pgraner: you could give a session about "mass-testing kernel fixes" :)
[14:29] <BenC> dholbach: ok, If I don't come up with something better, I'll do dkms
[14:30] <dholbach> BenC: will you just grab a slot on there?
[14:31] <BenC> dholbach: ok
[14:32]  * dholbach hugs BenC
[14:32] <dholbach> you ROCK :)
[14:33] <BenC> dholbach: no YOU rock!
[14:34]  * dholbach looks forward to seeing everybody in Berlin soon
[14:34] <Nafallo> you both rock... now, where's the fire? ;-)
[14:34] <dholbach> Nafallo: eh? :)
[14:34] <Nafallo> two rocks (stones) should lead to fire ;-)
[14:35]  * dholbach is too slow today :)
[15:09] <dholbach> BenC: which slot would you like to have? we can always change the session title afterwards
[15:10] <BenC> dholbach: late on a Friday is good
[15:10] <dholbach> 20 UTC? 19 UTC?
[15:18] <BenC> dholbach: 19
[15:18] <dholbach> BenC: alright, I'll add you to it
[15:18] <BenC> dholbach: thanks...still catching up on email
[15:18] <dholbach> BenC: same here :)
[15:22] <dholbach> BenC: added
[16:47] <alex_joni> can I use ppa to build custom flavours for a kernel?
[16:48] <_MMA_> alex_joni: A custom kernel? Sure. I couldn't tell you how though. :P
[16:50] <abogani> I can confirm it.
[16:52] <alex_joni> abogani: can you then build other packages that depend on that kernel (e.g. with installed header files) ?
[16:55] <abogani> alex_joni: I have done that job for rt kernel, headers and rt-tests packages without problems.
[16:55] <rtg> tmiller0
[16:56] <alex_joni> abogani: cool, that's nice to know
[16:56] <alex_joni> one day I might bug you about details (if I can't figure it out ;)
[16:58] <abogani> alex_joni: I think that you'll do it without problems and without any helps. ;)
[20:06] <johanbr> Would it be possible to go back to building pcspkr as a module? The only 100% reliable way I've found to get rid of the noise is to blacklist the module.
[20:15] <rtg> johanbr: I believe it is being built as a module: CONFIG_INPUT_PCSPKR=m
[20:16] <johanbr> really? hmm... then my blacklisting stopped working for some other reason
[20:16] <johanbr> it stopped working when jaunty rebased to 2.6.28
[20:17] <johanbr> I assumed it was due to the "stuff more stuff into the kernel" move.
[20:24] <zackr> are any of the people maintaining the lpia kernel online?
[20:27] <rtg> zackr: that is sconklin
[20:27]  * sconklin ducks
[20:28] <sconklin> zackr: the mobile group has a tree for their work, and I'm in the process of bringing it into our main tree. What do you need?
[20:30] <zackr> sconklin: ah, great. i have a machine with jaunty here and need to test a driver on 2.6.28, "fakeroot make-kpkg --initrd kernel_image" fails with "debian/ruleset/misc/checks.mk:36: *** Error. I do not know where the kernel image goes" is there any quick way of compiling 2.6.28 lpia package ?
[20:32] <sconklin> zackr: oh, that's out of my knowledge base since I don't actually *build* those kernels yet, and everything we have for lpia is based on Hardy. But hold on a sec and let me see if I can find someone who should know.
[20:32] <zackr> sconklin: that'd be great, thanks
[20:38] <sconklin> zackr: still looking
[20:43] <sconklin> zackr: so I understand - you want to cross-compile, this is not a native build, right?
[20:44] <zackr> sconklin: no, it's a native build. i just want to have 2.6.28 lpia packages
[20:45] <sconklin> ok, just making sure
[21:05] <sconklin> zackr: You have to build it in a chroot, and here's a procedure for setting up that chroot environment: http://lwn.net/Articles/247003/ - I tried s/gutsy/intrepid/ in those instructions (on an intrepid host). I don't have a jaunty machine at the moment to make sure it also works for jaunty.
[21:09] <zackr> sconklin: i'm a little confused. i have a lpia system running ubuntu already, i just wanted to compile new kernel on it. what would chroot give me in this case?
[21:12] <sconklin> zackr: Sorry, I left out the important bit.  No one I talked to does native builds, they are all done on other archs as chroot.
[21:12] <sconklin> but it should work
[21:13] <zackr> sconklin: could you ask the person who's building the lpia kernels to write up a procedure for building a new kernel? in particular the make-kpkg line
[21:20] <sconklin> zackr: the lpia kernels in the chroots are build using "fakeroot debian/rules <target>", so I don't think make-kpkg has been used or tested. Another option that was mentioned is to use a launchpad PPA to build them, but that's not really what you asked for at all.
[21:25] <zackr> sconklin: ok, and what <target> are you using on those then? on my lpia machine "fakeroot debian/rules lpia" returns exact the same error as make-kpkg which is "debian/ruleset/misc/checks.mk:36: *** Error. I do not know where the kernel image goes to [kimagedest undefined] ...", so it looks like there's some patch to the debian/ that you guys are applying before building those kernels
[21:28] <sconklin> zackr: that's possible. all my time has been spent looking at hardy, and there may have been something missed in Jaunty. Give me a few mins to have a look
[21:30] <zackr> sconklin: thanks. btw, i had the same problem on hardy. essentially the question is how to get debian packages for either git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git on hardy or linux-source-2.6.28 if running jaunty
[21:36] <sconklin> zackr: you can look at the current (hardy) lpia tree as easily as I can - it's here:  git://kernel.ubuntu.com/mid-team/hardy-netbook.git
[21:36] <sconklin> That's what I'm doing now.