=== TheMuso_ is now known as TheMuso | ||
Hobbsee | is it intentional that all jaunty upgrades pull lilo in by default, due to the kernel? | 08:48 |
---|---|---|
apw | Hobbsee, i am not aware of our dependancies changing specifically on lilo | 10:19 |
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:21 |
apw | (and wrong) | 10:22 |
Hobbsee | apw: well, I suspect it's a bug in intrepid upgrades too then | 10:30 |
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:31 |
apw | frankly i would expect them to conflict: with each other | 10:34 |
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:35 |
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:36 |
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:37 |
apw | i wonder if apt has changed behaviour somewhere | 10:38 |
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:39 |
Hobbsee | could be. I didn't use update-manager | 10:40 |
* apw gets the source | 10:40 | |
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:51 |
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:52 |
* apw is suspicious of the 32 bit installer now | 10:53 | |
Hobbsee | did you dist-upgrade it? | 10:53 |
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:54 |
apw | yes it does have proposed enabled too | 10:55 |
apw | according to the logs in /var/log/apt, it was installed in the initial install burst | 10:58 |
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:28 |
dholbach | is the preliminary schedule | 11:29 |
Keybuk | Thought of the day: | 11:56 |
Keybuk | what happens if init calls clone() with CLONE_PARENT? :p | 11:56 |
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:58 |
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 | 11:59 |
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:00 |
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:23 |
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:24 |
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:26 |
Keybuk | I can blow the kernel up from init easily ;) | 12:28 |
mjg59 | exit(-1) | 12:28 |
Keybuk | just one function call ... exit() | 12:29 |
apw | yeah i know, but that is 'deliberate' it is designed. this is a blammo, they are unsatisfactory at best | 12:31 |
apw | i am sure linus would agree with you | 12:32 |
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:27 |
dholbach | BenC: I could imagine that it's still interesting - if you have something better ... sure :) | 14:28 |
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:29 |
dholbach | BenC: will you just grab a slot on there? | 14:30 |
BenC | dholbach: ok | 14:31 |
* dholbach hugs BenC | 14:32 | |
dholbach | you ROCK :) | 14:32 |
BenC | dholbach: no YOU rock! | 14:33 |
* 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:34 |
* dholbach is too slow today :) | 14:35 | |
dholbach | BenC: which slot would you like to have? we can always change the session title afterwards | 15:09 |
BenC | dholbach: late on a Friday is good | 15:10 |
dholbach | 20 UTC? 19 UTC? | 15:10 |
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:18 |
dholbach | BenC: added | 15:22 |
alex_joni | can I use ppa to build custom flavours for a kernel? | 16:47 |
_MMA_ | alex_joni: A custom kernel? Sure. I couldn't tell you how though. :P | 16:48 |
abogani | I can confirm it. | 16:50 |
alex_joni | abogani: can you then build other packages that depend on that kernel (e.g. with installed header files) ? | 16:52 |
abogani | alex_joni: I have done that job for rt kernel, headers and rt-tests packages without problems. | 16:55 |
rtg | tmiller0 | 16:55 |
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:56 |
abogani | alex_joni: I think that you'll do it without problems and without any helps. ;) | 16:58 |
=== _Traxer is now known as Traxer | ||
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:06 |
rtg | johanbr: I believe it is being built as a module: CONFIG_INPUT_PCSPKR=m | 20:15 |
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:16 |
johanbr | I assumed it was due to the "stuff more stuff into the kernel" move. | 20:17 |
zackr | are any of the people maintaining the lpia kernel online? | 20:24 |
rtg | zackr: that is sconklin | 20:27 |
* sconklin ducks | 20:27 | |
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:28 |
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:30 |
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:32 |
sconklin | zackr: still looking | 20:38 |
sconklin | zackr: so I understand - you want to cross-compile, this is not a native build, right? | 20:43 |
zackr | sconklin: no, it's a native build. i just want to have 2.6.28 lpia packages | 20:44 |
sconklin | ok, just making sure | 20:45 |
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:05 |
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:09 |
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:12 |
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:13 |
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:20 |
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:25 |
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:28 |
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:30 |
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. | 21:36 |
=== pgraner_ is now known as pgraner | ||
=== TheMuso_ is now known as TheMuso |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!