=== TheMuso_ is now known as TheMuso [08:48] is it intentional that all jaunty upgrades pull lilo in by default, due to the kernel? [10:19] Hobbsee, i am not aware of our dependancies changing specifically on lilo [10:21] yep, our specified dependancies have not changed from Intrepid to Jaunty [10:21] debian/control.stub:Recommends: lilo (>= 19.1) | grub [10:21] would we expect that form to force lilo on? that sounds bad to me [10:22] (and wrong) [10:30] apw: well, I suspect it's a bug in intrepid upgrades too then [10:31] 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] frankly i would expect them to conflict: with each other [10:35] they don't seem to (as that's what I'd expect too). how strange. [10:35] 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] 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] (it keeps the metapackages right, but the bit that recommends grub itself is actually the kernel image binary, which keeps changing) [10:37] 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] i wonder if apt has changed behaviour somewhere [10:39] 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] that makes it feel like a bug, but a bug in the update [10:40] could be. I didn't use update-manager [10:40] * apw gets the source [10:51] Hobbsee, is your dual installed machine 32 or 64 bit? [10:51] apw: 32 [10:51] * apw notes his 32 bit Intrepid install has both installed [10:51] but his 64 does not [10:51] i clean installed intrepid today, then dist-upgraded it [10:51] got jaunty, and lilo installed [10:51] haven't rebooted it yet. [10:52] 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] and that also has both loaders installed [10:52] 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] did you dist-upgrade it? [10:54] oh, wait, i misread you sorry [10:54] nope this was a virgin install from a CD, and the most it has is -proposed enabled [10:54] always updated using update-manager [10:54] very strange. [10:54] proper user stylee, and it seems to be infected with both [10:55] yes it does have proposed enabled too [10:58] according to the logs in /var/log/apt, it was installed in the initial install burst [11:28] hello my Kernel friends! [11:28] who of you would like to give a session at the next Ubuntu Developer Week? something about module packaging with DKMS maybe? [11:28] https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep [11:29] is the preliminary schedule [11:56] Thought of the day: [11:56] what happens if init calls clone() with CLONE_PARENT? :p [11:58] hey Keybuk [11:58] Keybuk: Looks like failure [11:58] Keybuk: you could give a session about upstart at Ubuntu Developer Week - what do you think? [11:59] mjg59: the clone() doesn't look like it'll fail? [11:59] but it looks like if that process exited, lots of things assume that real_parent is not 0? [11:59] Keybuk: Right [12:00] Hence, failure :) [12:00] in fact, it looks like there's lots of -> after that ;) [12:00] definitely a "don't do that, then" [12:00] I think it's assumed that anyone writing init can already DoS the system whenever they want to [12:23] Keybuk, i concur with your analysis, bad karma will result from that [12:23] i suspect a very simple fix is possible, and probabally desirable [12:24] *shrug* I tend to agree with mjg59 here ;) [12:24] very few people write init daemons, and those who do already need to know about various special behaviours [12:26] i tend to be suspicious of anything which allows user space to blow the kernel up [12:26] yeah you are already winning if you can run init, but hey [12:28] I can blow the kernel up from init easily ;) [12:28] exit(-1) [12:29] just one function call ... exit() [12:31] yeah i know, but that is 'deliberate' it is designed. this is a blammo, they are unsatisfactory at best [12:32] i am sure linus would agree with you [14:27] BenC: would you like to give a session at the next Ubuntu Developer Week? something about module packaging with DKMS maybe? :) [14:27] https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule [14:27] it'd be nice to have something like a "hands on" session where people could get involved in the kernel team somehow [14:27] dholbach: I did dkms last time :) you want a new topic? [14:28] BenC: I could imagine that it's still interesting - if you have something better ... sure :) [14:29] pgraner: you could give a session about "mass-testing kernel fixes" :) [14:29] dholbach: ok, If I don't come up with something better, I'll do dkms [14:30] BenC: will you just grab a slot on there? [14:31] dholbach: ok [14:32] * dholbach hugs BenC [14:32] you ROCK :) [14:33] dholbach: no YOU rock! [14:34] * dholbach looks forward to seeing everybody in Berlin soon [14:34] you both rock... now, where's the fire? ;-) [14:34] Nafallo: eh? :) [14:34] two rocks (stones) should lead to fire ;-) [14:35] * dholbach is too slow today :) [15:09] BenC: which slot would you like to have? we can always change the session title afterwards [15:10] dholbach: late on a Friday is good [15:10] 20 UTC? 19 UTC? [15:18] dholbach: 19 [15:18] BenC: alright, I'll add you to it [15:18] dholbach: thanks...still catching up on email [15:18] BenC: same here :) [15:22] BenC: added [16:47] 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] I can confirm it. [16:52] abogani: can you then build other packages that depend on that kernel (e.g. with installed header files) ? [16:55] alex_joni: I have done that job for rt kernel, headers and rt-tests packages without problems. [16:55] tmiller0 [16:56] abogani: cool, that's nice to know [16:56] one day I might bug you about details (if I can't figure it out ;) [16:58] alex_joni: I think that you'll do it without problems and without any helps. ;) === _Traxer is now known as Traxer [20:06] 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] johanbr: I believe it is being built as a module: CONFIG_INPUT_PCSPKR=m [20:16] really? hmm... then my blacklisting stopped working for some other reason [20:16] it stopped working when jaunty rebased to 2.6.28 [20:17] I assumed it was due to the "stuff more stuff into the kernel" move. [20:24] are any of the people maintaining the lpia kernel online? [20:27] zackr: that is sconklin [20:27] * sconklin ducks [20:28] 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] 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] 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] sconklin: that'd be great, thanks [20:38] zackr: still looking [20:43] zackr: so I understand - you want to cross-compile, this is not a native build, right? [20:44] sconklin: no, it's a native build. i just want to have 2.6.28 lpia packages [20:45] ok, just making sure [21:05] 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] 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] 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] but it should work [21:13] 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] zackr: the lpia kernels in the chroots are build using "fakeroot debian/rules ", 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] sconklin: ok, and what 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] 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] 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] 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] That's what I'm doing now. === pgraner_ is now known as pgraner === TheMuso_ is now known as TheMuso