#ubuntu-kernel 2005-08-01 <fabbione> morning <fabbione> hey jbailey <jbailey> Heya Fabio <jbailey> I'm about to upload initramfs-tools 0.14 <fabbione> nice <jbailey> Just need to figure out why bzr doesn't feel like commiting. <fabbione> jbailey: did you hear anything about binutils to fix that link problem on sparc? <jbailey> No, but I haven't had a chance to dig in yet. <jbailey> Sorry about that. =( <fabbione> no need to be sorry please <fabbione> :) <fabbione> i was only asking... <fabbione> the situation still looks good <jbailey> Well, I feel bad that I haven't had a chance. <jbailey> Feeling a bit swamped. <fabbione> but the gnome pkgs starts to pile up <jbailey> bzr commit done. <jbailey> This version actually now detects IDE correctly on my box, SATA on another one, and LVM and Raid1. <fabbione> nice <fabbione> i hope i won't crash today <fabbione> and give it a shot <fabbione> i am so tired you have no idea <jbailey> Still no evms or cryptroot. <jbailey> I just don't have test scenarios for those, so it'll be a bitch. <fabbione> if you have md and lvm you also have evms <jbailey> I do? <jbailey> I'll ask you sometime when I'm awake. <jbailey> I promised mdz that I'd put out a call for testers today on what I have. <fabbione> as it stands now.. evms and lvm are "only" 2 interfaces towards device-mapper <fabbione> if you get one, somehow you get the other <jbailey> Ah, okay. <fabbione> but mdz can give you more details about evms <fabbione> he was the maintainer <jbailey> 'cept that he's insanely busy. <fabbione> well he can spend 2 minutes <fabbione> at least this is at kernel level.. <fabbione> if userland does something "weird" i dunno <fabbione> i was never able to make evms work in a decent way <jbailey> evms ate my partition table <jbailey> So I'm not inclined to try it again. <fabbione> ehhe <jbailey> Rejected: binary uploads are not allowed - please only upload source. <jbailey> Bah <jbailey> I must get that wrong like *half* the time. <fabbione> ehhehe <fabbione> jbailey: when i am linking.. can i avoid to specify -m $emulation ? <fabbione> or is it somewhat mandatory? <jbailey> Mmm, I thought it was supposed to detect it from the module. <jbailey> I might be mistaken. <fabbione> what i mean is: <jbailey> It's been so long since I've used ld directly. <fabbione> ld -m elf_i386 -r -o $dest $modules <jbailey> Right. <fabbione> if i omit -m elf_i386, which one will be selected? <jbailey> I think you ought to be able to leave it out. <jbailey> It should be detected, so in this case elf_i386 <fabbione> i guess i need to try it <fabbione> yeah it works on i386 <jbailey> Sleep time. <jbailey> fabbione: Hey - did you get a chance to try the initramfs-tools stuff at all? <fabbione> no :( <zul> heylo <fabbione> hey zul <zul> hey how is it going? <fabbione> as usual <zul> exciting <fabbione> what's exciting about it? <zul> i was being sarcastic <lamont__> fabbione: rebooting now <fabbione> kw33l <lamont__> well. that was painful <fabbione> so? <lamont__> good news for doko... it's not 3.4 <fabbione> bad news for the ia64 porter :P <lamont__> bad news for me: it's not 3.4 <lamont__> yeppers <lamont__> means I have to actually work on it. <fabbione> lamont__: the only thing i try to do is disable acpi on ia64 <lamont__> ?? <fabbione> it's the only big ia64 chunk of code that's different from Debian <fabbione> sorry. "i would try to do".. <lamont__> I should try booting with noacpi? or there's a kernel patch I should try removing? <fabbione> try booting with noacpi first <jbailey> W00t Got my drivers license. <jbailey> Angie has to wait until she gets better proof of residence. <jbailey> So stupid. <zul> its the same in ontario dude <jbailey> Umm, no. <jbailey> Her lease was good enough, and a bank statement was good enough for me. <zul> well..for health card i guess <jbailey> Well + old license. =) <jbailey> But here, I needed passport, ontario health card, ontario drivers license, and a current bill showing transactions only in quebec since I moved sent to this address. <jbailey> Andit has to be a bill from a 'respectable place' <zul> so pornos are out? :) <jbailey> The fact that she bought $3500 worth of appliances from Future Shop that got sent to the appartment that she leased isn't good enough. <jbailey> Nor is the confirmation from Hydro Quebec saying that her account is now open good enough. <jbailey> She had a visa bill with her, but the lady just said that it doesn't matter. The bank will send a statememnt anywhere. <jbailey> *my* visa bill was fine, though, since it has a u-haul on it, a bunch of gas stops along the 401 and a dozen or so transactions in montreal after that. <zul> lol...stupid quebec <jbailey> I thought it was a bit extreme. <jbailey> But I got mine for now, anyway. <jbailey> The Hydro bill is in her name, so when that gets sent, that'll be good enough. <zul> getting married in quebec is pretty extreme i hear as well <jbailey> Oh? <jbailey> What's the story there? <zul> i dont really remmeber unforuntately.. <jbailey> fabbione: ping? <jbailey> fabbione: any idea if this is going anywhere upstream: http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.7d-2.6.12.patch <fabbione> jbailey: acpi -> mjg59 .. really... <jbailey> Hmm. This is more initramfs handling, but alright. =) <jbailey> mjg59_: *poke* ^^^ <jbailey> It looks like we need to apply either that one or this one: <jbailey> http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initramfs-fix-2.6.10-cleanup.patch <mjg59_> acpi upstream aren't keen on it <mjg59_> If it's needed for initramfs, then push it <lamont__> mjg59_: the ia64 issue is more basic... nothing from the kernel but timeout/machine-checks <mjg59_> lamont__: Mm? <lamont__> 2.6.10-5 boots fine and all, 2.6.12-current is not so happy. with or without 'noacpi' <lamont__> so somewhere in there, I have issues to figure out. <mjg59_> Can you revert the acpi patch? <lamont__> could be a fun little bios interaction <mjg59_> Hmm. Hang on - I seem to remember something that may be related. Hang on. <lamont__> mjg59_: that's certainly on the list... <lamont__> mjg59_: the "one console" issue? <jbailey> mjg59_: Do they have specific concerns that I should work with? Having it right in the filesystem is elegant in a number of ways. <mjg59_> jbailey: "Vendors should fix their hardware" <jbailey> mjg59_: Not the least of which that you can swap dsdt's at boottime with a trivial hack to grub. <mjg59_> lamont__: If it boots without that, can you grab the latest bleeding-edge ACPI patch and see if that's any better? <lamont__> mjg59_: certainly. will probably pester you for where to grab said bleeding-edge razor <jbailey> fabbione: I have a really strong preference of the acpi-dsdt-initrd-v0.7d.... patch. It has the advantage that if someone does a custom kernel, they just won't get a DSDT. With the other one, if they run a stock kernel, the kernel can't load an initramfs with a DSDT in it. <jbailey> mjg59_, fabbione: What prep/testing do you need me to do in order to test it adequately for you to bless it? <fabbione> jbailey: are the 2 patches mutal exclusive? <fabbione> so it's either one or the other <jbailey> No <mjg59_> jbailey: The initramfs one looks correct. Break your DSDT, boot with it, see if your machine breaks <mjg59_> If so, I'm happy with it <jbailey> mjg59_: The one that just alters the read size to compensate for the DSDT hanging off the end? <mjg59_> Hang on * jbailey hangs <zul> ding dong the wicked witch...er.. <mjg59_> jbailey: Ok. What's the precise issue? <jbailey> zul: Funny enough, there are bells rining outside. <zul> lol <jbailey> mjg59_: With an initramfs, using the traditional way of appending the DSDT to the initramfs causes a boot failure. The people at this web site are proposing two solutions. 1) (http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initramfs-fix-2.6.10-cleanup.patch) makes the initramfs read function calculate the size of the initramfs without including the files so that it unpacks the initramfs correctly. The rest of th <jbailey> e sstem should go on to process the dsdt correctly. <mjg59_> Yes. That looks clean enough. <jbailey> 2) http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.7d-2.6.12.patch makes the initramfs system available earlier so that acpi can simply open the file off of the filesystem and read it in. <mjg59_> Right. I've no preference. <mjg59_> The first seems less invasive <jbailey> So here's the catch. <jbailey> 1) Means that if someone does a custom kernel, but includes a DSDT at the end, they won't have the patch, so the machine won't boot. <mjg59_> Yes <jbailey> 2) Means that if someone does a custom kernel, and includes a DSDT in the initramfs, it simpy won't get read by anything. <mjg59_> Well, either is fine with me. <jbailey> Have you seen either of these on upstream lists? I have a preference for #2 to reduce the support nightmare. <jbailey> But I suspect that #1, being less invasive, is more likely to get accepted. But that's entirely a guess. <mjg59_> Neither is going to make it upstream while acpi upstream are hostile <jbailey> If neither will make it upstream, then I'll do #2 =) <jbailey> fabbione: What sort of testing do you want me to do before I say "Please include this patch"? <fabbione> jbailey: it's enough it works for you.... <jbailey> 'kay <jbailey> I guess I need to figure out how to compile a kernel now. =) <fabbione> it looks to me we already have 2 * jbailey blinks <jbailey> Oh? * jbailey apt-get source's the kernel to check <mjg59_> fabbione: I think we only have an earlier version of the patch that doesn't deal with initramfs <jbailey> Hmm, can I apt-get source the i386 kernel from a ppc? * jbailey hops onto concordia <fabbione> jbailey: the kernel is only one <fabbione> there is only ONE source <zul> use the source luke <fabbione> mjg59_: well i have no issues to update it.. <jbailey> Ah, handy * jbailey blinks. <jbailey> 26k source? <jbailey> Oh, that's linux-meta <jbailey> 47mb, much better <jbailey> Err.. Is i386 cisneroselizabeth@example.net ? <jbailey> That's all concordia seems to have in its chroot's apt sources <fabbione> jbailey: you can grab the sources from my home on concordia <fabbione> take 4.4 please <fabbione> 4.5 is the playground atm <jbailey> Hmm <fabbione> desrt: what kernel flavour do you use? <jbailey> I thought drivers-acpi-osl_attach-dsdt-to-initrd.dpatch <jbailey> was already upstream <lamont__> hrm.. external-global-acpi_update.dpatch is pretty *&(^^%_ invasive <desrt> fabbione; 686-smp and powerpc64-smp <fabbione> desrt: ok.. i will make 686-smp for you to test <lamont__> mjg59_: external-global-acpi_update* were the two you wanted me to pull? <desrt> fabbione; the hardware arrived today for our cluster :) <desrt> fabbione; so, as of tomorrow i'm gonna be running 5 boxes with powerpc64-smp :) <desrt> (and some time later about 12) <fabbione> desrt: cool! <fabbione> desrt: what kind of cluster are you going to run? <desrt> our own thing <fabbione> yeah.. i mean. HA or HP cluster? <fabbione> A=Availability <fabbione> P=Performance <mjg59_> lamont__: Yeah <jbailey> Anyone have a SuSE kernel source handy? <jbailey> I'd love to see if they apply this other one, it's one of their folks that wrote it: <jbailey> http://gaugusch.at/acpi-dsdt-initrd-patches/acpi_dsdt_initrd_initramfs.patch <jbailey> http://gaugusch.at/acpi-dsdt-initrd-patches/initramfs-before-acpi.patch <fabbione> dpkg-deb: building package `linux-image-2.6.12-4-686-smp' in `../linux-image-2.6.12-4-686-smp_2.6.12-4.5_i386.deb'. <fabbione> and NO ABI breakage! <fabbione> (....yet) <jbailey> This too shall pass ;) <fabbione> desrt: http://people.ubuntu.com/~fabbione/ <fabbione> desrt: there are 3 linux-*-4.5*.deb <fabbione> can you test inotify with them? <fabbione> they include all the latest fixed <fabbione> fixes <fabbione> just rememeber that is NOT 4.5 final <fabbione> so you might have to upgrade it later * lamont__ watches the whole *&%)_ world rebuild, curses acpi * fabbione goes offline * desrt downloading now <desrt> sorry for the delay. got busy for a moment <fabbione> desrt: no problem, take your time to test. <fabbione> i need to go out now <fabbione> i will bbl <fabbione> ps don't use SYSCALLS 289 and 290.. they are fake and unsecure atm <fabbione> i already have a better patch done.. <fabbione> but i need to know if it works for you now with the 291/292/293 <fabbione> in sync with * <fabbione> later <desrt> fabbione; problem is not fixed <desrt> :q <desrt> erp <desrt> fabbione; looking at your source package, nothing has changed <desrt> fabbione; (from looking at source) sys_inotify_rm_watch is still doing improper input validation and (from testing against your binary) i'm still getting the crash <desrt> from 2.6.13-rc3-git8: http://manic.desrt.ca/inotify.c <desrt> search for /* verify that this is indeed an inotify instance */ * lamont__ adds external-drivers-ide_sleep to his list, since it's ftbfs without acpi... <fabbione> desrt: i didn't put any source there... <fabbione> did you take 4.5 ? <fabbione> or by mistake you took 4.4? <desrt> i took linux-source-diff that was in the group of them :) <fabbione> it's not the one to look at <desrt> ahh <desrt> well, in any case, the binary still exibits the crash :) <fabbione> /* verify that this is indeed an inotify instance */ <fabbione> this is there <desrt> uname -a shows Jul 27 <fabbione> twice <desrt> weird..... <fabbione> dpkg -l linux-image-2.6.12-4-686-smp <desrt> 2.6.12-4.5 <fabbione> yeah that's it <desrt> want me to send you a testcase? <fabbione> it's all the latest inotify <fabbione> desrt: did you change the syscalls to match the real ones? <desrt> yes <desrt> i'm using 293 now, i think <fabbione> well.. can you recheck please :) <desrt> you're using the same syscall numbers as the official 2.6.13, right? <fabbione> also.. did you check that it is fixed in git8? <fabbione> yes. right <desrt> no. i haven't. <fabbione> by running it... <fabbione> well that would be something to do :) <desrt> cool <desrt> 293 is, in fact, the right number <desrt> will test git <fabbione> thanks <zul> ohwee...i got business cards <desrt> man... it's times like this when i'm building a kernel that i wish i had a nice pentium D system <desrt> crimsun; w3rd. <crimsun> 'lo desrt * desrt plays a good beatles song to honour your presence <desrt> "nothing's gonna change my world....." <desrt> fabbione; i get -EINVAL on that syscall on 2.6.13-rc3-git8 <desrt> and no crash <desrt> so 2.6.13-rc3: bad <desrt> so 2.6.13-rc3-git8: good <desrt> and 2.6.12-4.5: bad <fabbione> desrt: ok.. i will give you another kernel in a few minutes.. <desrt> :) <fabbione> it looks like not all the patches in git as commented as they should... <fabbione> desrt: it's building.. <fabbione> if this one still crash, i know exactly what it is <fabbione> but <fabbione> it's not going to be fun at all <fabbione> desrt; http://people.ubuntu.com/~fabbione/desrt/ <- <fabbione> i will be back in few minutes.. <fabbione> desrt: ? <desrt> fabbione; just installed and am rebooting now <fabbione> cool <desrt> Jul 27 18:25:09 UTC <desrt> no crash <fabbione> perfect <desrt> ship it! :) <fabbione> do you want to know what it was? <desrt> ya. for sure <fabbione> NEVER TRUST PATCH! <desrt> uhm... what happened? <fabbione> basically i was doing cg-mkpatch -r $id | patch -d $pathtokernel -p1 <fabbione> on all inotify commit <fabbione> no rejects <fabbione> no fuzzyness <fabbione> it ended with 2 different files <fabbione> (same base of course) <desrt> like what? <fabbione> there were diffs in the order of some hunks <fabbione> the final inotify.c was different <fabbione> @@ -990,6 +991,8 @@ <fabbione> filp = fget_light(fd, &fput_needed); <fabbione> if (unlikely(!filp)) <fabbione> return -EBADF; <fabbione> + dev = filp->private_data; <fabbione> + ret = inotify_ignore (dev, wd); <fabbione> <fabbione> /* verify that this is indeed an inotify instance */ <fabbione> if (unlikely(filp->f_op != &inotify_fops)) { <fabbione> @@ -997,9 +1000,6 @@ <fabbione> goto out; <fabbione> } <fabbione> <fabbione> - dev = filp->private_data; <fabbione> - ret = inotify_ignore(dev, wd); <fabbione> - <fabbione> something like this <desrt> er <desrt> that's the inverse of the patch you need :) <desrt> actually, it's just nonsense <fabbione> yes sorry.. <desrt> it's like "do it first, check later" :) <fabbione> i did it the wrong way <fabbione> but it still landed in the wrong order in the final inotify.c <fabbione> that's the point <desrt> nod. <desrt> well <desrt> it all seems to be working fine now <fabbione> never mind the direction of that patch <desrt> maybe the cg-mkpatch wasn't generating enough lines of context <desrt> so it just went blindly by linenumber and put it in the wrong place <fabbione> possibly <desrt> that'd also explain why it didn't mention any fuzz <fabbione> baz commit -s'Update inotify' <desrt> ok. so is this when a bug becomes PENDINGUPLOAD? <fabbione> M patches/sth-fs_inotify.dpatch <fabbione> M changelog <fabbione> yes <fabbione> but iirc you can't change from UPSTREAM to PENDINGUPLOAD directly <fabbione> so we will close it after we upload... <fabbione> not a big deal <desrt> nod. <fabbione> jbailey mjg59_: ping? <jbailey> pong <fabbione> otherwise you need to put it as ASSIGNED and than PENDINGUPLOAD <desrt> ya. evil bugzilla :P <fabbione> jbailey: remember i will be VAC from 1st of Aug <fabbione> infinity will take care of the kernel <fabbione> but i plan an upload for no later than friday <fabbione> so if there is something important or urgent, it has to be withing friday morning <fabbione> mjg59_: the above is valid also for ACPI <fabbione> because the 8th of Aug is Feature Freeze <fabbione> (or the 5th.. i can never remember) <zul> hmmm...i think im going to be busy this weekend ;) <fabbione> zul: no crack please.. only tested committs... <fabbione> we need to go very stable and very fast <zul> yep <fabbione> zul: specially.. test before commit <fabbione> or at least build <fabbione> i don't want to come back and have to cleanup a mess :) <zul> heh... <zul> all of my group has gone home for the day. and its only 3:13pm <zul> slackers <fabbione> ok <fabbione> time to stop <fabbione> it's only 9:20 pm <fabbione> and i started at 6am <desrt> :) <desrt> fabbione++ <fabbione> another 2 bug fixes done.. <fabbione> desrt: i might upload tomorrow.. <fabbione> or max friday <fabbione> you can use the temp kernel in the meanwhile <desrt> it's cool. it's not actually affecting me <desrt> i can just avoid passing an invalid fd to inotify :P <fabbione> uh no.. the other 2 bug fixes are ACPI and USB related <zul> i think we might have to close some more non-responsive user bugs tonight as well <fabbione> zul: go ahead <fabbione> KILL THEM ALL! <zul> users or bugs? <fabbione> users of course <Mithrandir> both, preferably * fabbione switches to bastart mode <fabbione> Mithrandir: why so much blood? <fabbione> users are enough <fabbione> unresponsive user on bug -> CLOSE <fabbione> i need to buy another THX <fabbione> after i moved mine in the living room i miss to listen to music in a decent way * fabbione goes offlinw <fabbione> there.. i can't even type anymore... <jbailey> <fabbione> unresponsive user on bug -> CLOSE <jbailey> <fabbione> i need to buy another THX <jbailey> buy another user? <jbailey> Dude, you don't PAY for those. <jbailey> They come free. =0 <jbailey> =) * Mithrandir tickles the man with blue streaks in his hair. <lamont__> Mithrandir: who went tropical-fish on us? <Mithrandir> lamont__: http://www.raspberryginger.com/jbailey/weblog/entries/photos/hpim2587.jpg <jbailey> Mithrandir: eh... =) <jbailey> Mithrandir: I'm *not* adding a highlight on "blue". That would be a bit too much. =) <lamont__> jbailey: you need more elmers glue. <jbailey> lamont__: Err. Why? <Mithrandir> jbailey: looks nice, though <lamont__> jbailey: no spikes. that's why. :-) <jbailey> Mithrandir: Thanks. What's fun is that 1) There are 10 of them, but most are buried, so they only poke out occasionally. 2) They're all on the side and the back, so I still look respectable if I tie my hair back. <jbailey> lamont: *lol* <jbailey> lamont__: The funny part is that they're extensions, so they're basically epoxied onto other hair near the roots. <lamont__> heh <Mithrandir> jbailey: have you read citizen cyborg? I think you may find it interesting. <Mithrandir> s/may/might/ <jbailey> I haven't, I'll look for it. <lamont__> fabbione: still awake <lamont__> ? <fabbione> lamont__: not for more than 2 minutes <fabbione> i am crashing <fabbione> /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory <fabbione> GREAT <fabbione> now what did reintroduce this... <fabbione> bah <fabbione> i am going to sleep <fabbione> good night <lamont__> g'night fabbione <lamont__> jbailey: ping #ubuntu-kernel 2005-08-02 * netjoined: irc.freenode.net -> kornbluth.freenode.net * desrt wonders why all of this work is being done on 2.6.12 <lamont__> mjg59_: btw - sent someone your way wrt latest thinkpad acpi stuff. <mjg59_> lamont__: Ah, thanks * lamont__ adds one beer to what he owes mjg59_ <jbailey> lamont__: pong <TheMuso> .c <TheMuso> crap <weridcreep> hello <lamont__> jbailey: figured it out... although... <lamont__> what's the easiest way to abuse an initrd to debug in it? <weridcreep> what kernel does ubuntu run <jbailey> lamont__: Existing one, or can you create a new one? <lamont__> jbailey: (original question involved a brainfart trying to mount the initrd locally to look)( <jbailey> Editting existing ones is teh suck. <lamont__> given the recipie, I could create a new one... <jbailey> Okay, edit /etc/mkinitrd/mkinitrd.conf <jbailey> Set DELAY=5 and BUSYBOX=yes <jbailey> (Make sure busybox-cvs-static is installed) <jbailey> as root: <jbailey> mkinitrd -o /boot/initrd.img-$(uname -r) $(uname -r) <jbailey> NOTE: This will overwrite your current initrd. <lamont__> yeah - I see that <jbailey> If you have a sane bootloader (That is, grub grub or grub), you can make it /boot/initrd or something like that and just change it at boot time. <lamont__> jbailey: elilo :-( <jbailey> Add an entry for your testing then. <lamont__> yep <jbailey> You won't get grub2 for efi for another couple of months. <jbailey> (although someone has now started on it) <lamont__> actually, the current state is that 'Linux' doesn't boot, and 'Good' does. :-) <jbailey> Great! Overwrite the one for Linux then, nothing to lose. <lamont__> yeah <jbailey> Oh! <lamont__> yeah <jbailey> Missed a step. <lamont__> ?? <jbailey> Edit /etc/mkinitrd/modules and add the modules you need to have a working keyboard. <lamont__> serial atm <jbailey> 'k =) * lamont__ has a 2700+ line config diff, and somewhere in there is a fatal option <jbailey> *blink* <jbailey> config? <lamont__> happy happy joy joy. binary searches are _SO_MUCH_FUN_!!! <lamont__> kernel config <lamont__> defconfig vs itanium <jbailey> I didn't think there were 2700 options in there. <jbailey> 'sthis breezy? <lamont__> rather, defconfig vs breezy/itanium <lamont__> just a sec and I'll dump stats for you - Good has almost booted. <jbailey> If you feel up to it after this, I'd appreciate feedback on the initramfs-tools, since it's scheduled to become default on Friday. <jbailey> Since I will be away this weekend, I'd rather clobber as few UndercluedUsers as possible. <jbailey> (You know... For the racks of Itaniums running Breezy out there...) <lamont__> diff -u debian/config/itanium debian/config/ia64/itanium | wc <lamont__> 2732 5643 61682 <jbailey> *ouc* <jbailey> +h <lamont__> yeag <lamont__> must run <lamont__> back later <fabbione> morning <desrt> word. <desrt> i have a question that i asked earlier after you'd gone to bed :P <desrt> why are you packaging 2.6.12? <fabbione> what should i be packaging? <desrt> 2.6.13-rc's <fabbione> no <fabbione> we are in UVF <fabbione> Upstream Version Freeze <fabbione> we need to release quite soon <desrt> since how long? <desrt> hmm <fabbione> 3 weeks? <fabbione> more or less <desrt> so 2.6.12 is the breezy kernel <desrt> weird <fabbione> yes <desrt> ok. that's a good reason :) <fabbione> that's what in our conffile <fabbione> ops <desrt> is gnome a blanket exception to UVF or is 2.11 considered like a 2.12 prerelease? <fabbione> gnome is an exception <fabbione> it has been since the beginning <desrt> it's a good exception :) <fabbione> infinity: ping? * lamont__ starts to fade fast, heads for home <calc> any chance of getting a working version of ipw2200 into the kernel soon? <calc> fabbione: still here? <fabbione> calc: ipw2200 is working <calc> 1.0.4 -> 1.0.1 for WEP but broke WPA completely <fabbione> calc: 1.0.4 did break completely ipw2100 <fabbione> and i had no time for that release to test 1.0.6 <calc> too bad its not even for the ipw2100 <calc> i have 1.0.4 on ipw2200 and it works more or less fine <fabbione> also.. people should read what's on the ipw2x00 sties <fabbione> sites <calc> i get those error messages about resetting firmware but 1.0.4 does actually work 1.0.1 doesn't at all <fabbione> 1.0.X releases <fabbione> for x = 0 stable <fabbione> for x > 0 development <fabbione> 1.0.6 = development <calc> 1.x.y <calc> x is stable <calc> when x = 0 <calc> or else why not go all the way back to 1.0.0 ? :) <fabbione> Versions with the last number is not a zero is an unstable release, for example 1.0.1, 1.1.3, etc. <calc> yes <calc> 1.0.0 is basically useless <calc> 1.0.1 is nearly that way <fabbione> because ipw2100 is alligned with 1.0.1 ipw2200 <calc> what does ipw2100 have to do with ipw2200? <fabbione> so your x.y interpration is wrong <fabbione> calc: they share ieee8$something layer <fabbione> they splitted only recently in 3 projects <calc> that doesn't avoid the point that ubuntu is still using a development driver and one that is more broken than the current one which fixes about an additional 30 bugs <calc> ah yea i see about the 802.11 stuff <fabbione> calc: the plan was to revert to a more stable release <fabbione> and than try the new split in the next kernel <fabbione> before the ieee code was duplicated and misalligned between the 2 <fabbione> (ipw2x00) <fabbione> so it was creating all sorts of problems <fabbione> only recently they splitted ieee out of the 2 trees <fabbione> and that needs to be tested <calc> ok i'll just hang onto my -3 kernel since its the only one that will work for the forseeable future then <fabbione> so if you can be nice to give us the time to merge <fabbione> you will get it <calc> i thought you said earlier that the final kernel will be out within 3 weeks? <fabbione> who said so? <calc> 23:37 < fabbione> we need to release quite soon <calc> 23:37 < fabbione> 3 weeks? <fabbione> 3 weeks was related to UVF <fabbione> 3 weeks ago... <fabbione> the release will probably be tomorrow <fabbione> there is no final kernel until breezy releases <calc> oh is this just a temporary colony freeze? <calc> ok :) <fabbione> and we will start doing only security updates to the kernel approx 2/3 weeks before final release <calc> sorry i was confused * fabbione starts fetching the latest ipw2*00 crack... <fabbione> calc: will you be able to test for me? <calc> yea <calc> what types of tests do you need run? <fabbione> hmm this also means another ABI change... <fabbione> SUCKAGE <calc> changing the driver causes abi change? <fabbione> calc: yes. the ieee thing has an abi change <fabbione> and ipw2* depends on it <fabbione> you can't change interchange the modules at your own pleasure <calc> oh <calc> oh btw i am using 2915abg on amd64 arch <fabbione> what's that? <fabbione> i am not 100% familiar with all these wireless drivers.. <fabbione> i only use cisco stuff <calc> its the intel 802.11a/b/g minipci <calc> uses same driver as ipw2200 <fabbione> ah ok <calc> i'm going to bed now, bbl <fabbione> night <infinity> I'm using a 2915abg on i386. ;) <fabbione> hey JaneW <fabbione> see... <fabbione> even after the split they are still not synced properly <fabbione> GRRRRRRRRRRRRRRRRRRRRR <fabbione> #define IPW_HEADER_802_11_SIZE sizeof(struct ieee80211_header_data) <fabbione> infinity: do you have any clue about the size of that struct? <fabbione> never mind.. i found it <fabbione> now they share code... <fabbione> so let's TRIPLICATE all the definitions <fabbione> JaneW: i will need a name for tomorrow my far far away so lovely lady :) * fabbione hopes he got the define right or ipw2100 won't work <fabbione> JaneW: ?? <fabbione> ok guys we need a name for the kernel <fabbione> + release <fabbione> JaneW disappeared... <fabbione> The: <fabbione> begin 644 - <fabbione> 41S%"0C!2($TS(%0S2"!#4C1#2PH` <fabbione> ` <fabbione> end <fabbione> Release <desrt> that's an interesting name <fabbione> eheh * desrt g1bb0rs you some cr4ck <fabbione> nah i did set it to something more normal <fabbione> people have lost the sense of humor.. <fabbione> they won't get the joke part <desrt> boo to people <fabbione> desrt: i know.. i am talking from experience <fabbione> i have to issue to write *interesting* stuff :) <fabbione> time to start the build orgy :) <desrt> exciting. * desrt thinks we should have a build-pr0n package to lure former-gentoo users to ubuntu land <fabbione> aha <desrt> just videos of compiles scrolling by <fabbione> HAHHAAH <fabbione> desrt: if you collect the videos and make them BSD/GPL licence <fabbione> i am going to upload them as gentoo-emulator <desrt> :) <fabbione> we can make it as a screensaver or something <desrt> hey.. that'd be a pretty sexy screensaver <fabbione> similar to cappuccino <desrt> mmm. i think gnome-screensaver needs a module called "gentoo" :) <fabbione> desrt: ehehe sure... <fabbione> if you do it, i will upload it for you <fabbione> just the code.. no need to package it <fabbione> making a deb for it will take 2 minutes <desrt> hmmm :) <desrt> ok. i'll look into it <fabbione> actually <fabbione> it would be even more cool to use the kernel screen blanking <fabbione> CONFIG_GENTOO_EMULATION <desrt> ....as compared to the X one? <desrt> oooh. <desrt> i see <fabbione> that you can enable or disable with a syscall/ioctl or whatever <desrt> and you can have a bunch of kernel options <fabbione> that will just fake to compile hello.c millions of times :) <desrt> [*] Include build log from Xorg <desrt> [*] Include build log from kernel source <fabbione> ahahah <desrt> etc <fabbione> the problem is that it would bloat the kernel or the module... <desrt> nah <fabbione> including these logs <desrt> you gotta imagine that build logs compress really well <desrt> every single line is like gcc -flags -flags -flags -Dsomething -Isomething blah blah blah flags filename.c <fabbione> desrt: X builg log is 10MB uncompressed <desrt> and the only part that changes is filename.c <fabbione> even if you compress it to death is still 300K <desrt> hmm <desrt> this is problematic. <desrt> ! <desrt> i know <desrt> we launch a project <desrt> gentoo@home <desrt> as an outreach programme to gentoo users <fabbione> aHAHAHA <desrt> donate our spare CPU cycles to actually help them compile <fabbione> desrt: it would be easier to write a name generator to print gcc -O31337 blablabla foo.c <desrt> you forgot to omit the framepointer <desrt> man... it's so easy to get caught-up in the gentoo-teasing <desrt> i used to use gentoo... and i liked it a lot... i still do <desrt> if, for example, sadfdl were to ever pull another ubuntu_spatial type thing i'd go back to gentoo :P <fabbione> eheheh <fabbione> i doubt he is going to do it again <desrt> ok <desrt> my screensaver is about done now :) <fabbione> ehehhe <desrt> so far it just says "test" once per second <desrt> i have to find something more interesting for it to say <fabbione> desrt: can i see the code? <desrt> it's pretty rough <desrt> but sure <fabbione> we can work on it together... <fabbione> given i just uploaded the kernel i have the right for 10 minutes free :) <desrt> http://manic.desrt.ca/gentoovision.c <fabbione> heheh <desrt> hmm * desrt encounters chicken + egg problem <desrt> fabbione; if you want to help, there's a good task needs to be done <fabbione> desrt: i first need to figure where is gtk.h :) <desrt> there needs to be a program that opens a pseudotermial or listens on a pipe and gets the output of a compile complete with timing information <desrt> gcc -o gentoovision gentoovision.c -Wall `pkg-config --cflags --libs gtk+-2.0` <desrt> it might segfault :) <fabbione> gentoovision.c:118: warning: passing argument 2 of 'gtk_timeout_add' from incompatible pointer type <fabbione> tsk :) <desrt> pfft <desrt> i didn't feel like looking up the right cast type :) <desrt> it's some (GTimeoutFunc) or something <fabbione> ahah <fabbione> it works here :) <fabbione> so what's the task? <desrt> there needs to be a program that opens a pseudotermial or listens on a pipe and gets the output of a compile complete with timing information <desrt> i think the file format will be like <desrt> 1234:gcc -o some compile output blah blah blah <desrt> where 1234 is how many ms that output should stay on the screen <fabbione> why not just generating random gcc stuff? <desrt> it'd be cool to have authentic builds :) <desrt> they'd be the new ringtones <desrt> instead of downloading a blink182 ringtone for your phone you download a glibc build log for your screensaver :) <fabbione> actually... gentoo@home is an easy project to do :) <desrt> well.. there's already distcc... <fabbione> exactly :) <desrt> fabbione; are you working on that program? <fabbione> desrt: not right now.. sorry.. i did a little mistake building on hppa <desrt> s'ok <desrt> i'm gonna go to bed now anyway :P <desrt> it's waay past my bedtime <fabbione> eheh good night :) <Nafallo> could you please sync rt2400 && rt2500 from CVS before next upload? <mjg59_> fabbione: I'm a bit stuck getting stuff integrated until I actually have internet connectivity here. What are you defining as feature freeze in the context of the kernel? <fabbione> mjg59_: like the rest of the distro and i will be vac from tomorrow <fabbione> Nafallo: why? <Nafallo> fabbione: lot's of bugfixes. <fabbione> Nafallo: i will look if i have the time <mjg59_> fabbione: Sure, but what's a feature in terms of the kernel? <Nafallo> fabbione: it might actually begin to work without all those ifdown && ifups I have to do now :-) <fabbione> mjg59_: adding new crack.. bug fixes are ok of course <Nafallo> fabbione: k, kewl. <mjg59_> fabbione: Ok. There's one (trivial) driver that I'd like to push, but there's no way I can generate a dpatch by tomorrow. <mjg59_> I just don't have bandwidth at the moment <fabbione> mjg59_: for the next 2 weeks (while i am away) infinity will take care of the kernel <fabbione> iirc Feature Freeze is by the 5th of Aug <fabbione> or something around that <fabbione> so you have sometime <fabbione> but don't count on me being around <fabbione> so you will have to triple check everything <fabbione> from patches to configs to portability and so on... <mjg59_> 11th of August <mjg59_> Ok, no problem <mjg59_> fabbione: There's a load of PCI drivers that need fixing up for suspend/resume to work. I'm looking into it. <fabbione> mjg59_: *sighs* <mjg59_> (biggest problem is with sound cards, since we unload network drivers) <fabbione> hmm what has net to do with sound? <mjg59_> Basically, due to ACPI changes (to fix a bug) PCI drivers all need to call pci_disable_device on suspend and pci_enable_device on resume <mjg59_> The same bug is present in sound and network drivers, but we unload network drivers <fabbione> JEEEEEE <fabbione> dude that patch is going to be A BIG FAT MOFO to maintain <mjg59_> It's only a problem with devices on shared interrupts, so IDE isn't an issue <mjg59_> USB is, but we unload that as well, so... <mjg59_> Which leaves, uh, 47 drivers to fix up. Hmph. <mjg59_> The ALSA people may already have done it. I'll check their tree. <fabbione> i have the feeling that with all these big fat crack .12 is going to suck more than .10 <fabbione> hey zul <zul> hey fabbione <mjg59_> fabbione: The alternative is to revert that hunk, which takes us back to .10 for that behaviour <Nafallo> zul: yay! maybe you should do what I asked fabbione earlier? :-) <mjg59_> However, it is a real bug that gets fixed <Nafallo> zul: update rt2400 && rt2500 from CVS. fixes lots of bugs. <Nafallo> zul: also we might want to consider rt2570? <fabbione> mjg59_: ok.. try to contain the mess :)) <fabbione> Nafallo: please stop nagging <fabbione> it's the 3rd time you ask the same <fabbione> gimme a break and the time to do it <mjg59_> Oh argh. <Nafallo> fabbione: oki. <mjg59_> Alsa has its own power management layer. How horrible. * ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://cisneroselizabeth@example.net/ playground: kernel-debian--preX,6--2.6.12 <zul> wtf? <fabbione> zul: what? <zul> oops...typo...was commenting code <fabbione> ahha <zul> holy crap Nafallo i just woke up and am at work so its not going to be done anytime soon <Nafallo> oki. I will not ask before they fix another one of those _really_ irritating bugs that seems to be in the driver :-). <fabbione> Nafallo: let me explain <fabbione> between your request and time i can upload such change <fabbione> i need AT LEAST 4 hours <fabbione> you asked this morning.. wait <fabbione> AT LEAST = update the patch, build everywhere, fix the breakage, go back <fabbione> the build = 3 hours <fabbione> if you are in such a hurry, you can provide us with .dpatches directly <fabbione> tested of course... <fabbione> so i can save 4 hours <fabbione> and you can spend 2 days building around... <fabbione> because the patch needs to work on N arches <Nafallo> fabbione: I know. I didn't know if you saw it this morning. and last time they fixed a big one I do not believe it was updated. that's why I asked when you where alive aswell. <fabbione> Nafallo: this morning i did even answer to you <fabbione> and we did talk <fabbione> so.. i fail to see how i could have missed that... <fabbione> 12:19Nafallocould you please sync rt2400 && rt2500 from CVS before next upload? <fabbione> 12:26fabbioneNafallo: why? <fabbione> 12:26Nafallofabbione: lot's of bugfixes. <fabbione> 12:27fabbioneNafallo: i will look if i have the time <fabbione> so that was 2 hours ago :) <Nafallo> fabbione: I asked in #ubuntu-devel earlier (I belive yesterday after checking the logs). <fabbione> Nafallo: that's why i said 3 times.. <fabbione> when i read the backlog you were not around.. <Nafallo> fabbione: anyway. no hard feelings. those bugs keeps me on cable, that's why I wanted to make sure you knew. and the when zul came along, I asked him because he's been my SPOC on this driver :-). <Nafallo> until now indeed... <zul> oh if im not needed ill just go away..thanks.. <zul> besides i dont see you submitting patches <Nafallo> zul: I will not touch the kernel before I got lot's more experience. I watch the changelogs on this driver, and that's all I will do :-). I belive the issue is sorted now anyway :-). <Nafallo> sorry for the nagging, now I'm sure this will get fixed and can get on with MOTU-things. <JaneW> chmj: I thought someting interesting was happening here <chmj> what you mean ? <chmj> JaneW: O.o <lamont> morning JaneW <fabbione> hey lamont <fabbione> lamont: do you happen to remember why you were pinging me yesterday? <lamont> fabbione: actually running out the door... need to leave 5 min ago. <fabbione> ok <fabbione> ttyl <lamont> about 45-60 min <fabbione> sure <zul> heh i might be conververting my boss from fedora to ubuntu <JaneW> hi lamont * JaneW is off to a meeting <lamont> Adding console on ttyS0 at MMIO 0xff5e0000 (options '9600n8') <lamont> RAMDISK: cramfs filesystem found at block 0 <lamont> RAMDISK: Loading 9152KiB [1 disk] into ram disk... done. <lamont> XFS: bad magic number <lamont> XFS: SB validate failed <lamont> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,3) <lamont> hrm... clearly I'm missing something important... <fabbione> is that ia64? <lamont> yeah... I mutilated the .config, and it booted. now to add some more stuff back. <mjg59_> Is it an XFS filesystem? <lamont> mjg59_: no <lamont> ext3 everywhere, although hda1 is fat <lamont> actually vfat <fabbione> oh you have a copy of Windows IA64? <lamont> elilo partition is vfat <fabbione> ah ok <lamont> because vfat is so cool. that and intel engineers are windoze-centric, so that's what they made it. <lamont> you should see the builtin editor in efi... <fabbione> notepad? ;) <fabbione> or word? <lamont> notepad like/nano-like. but absolutely sucky termio <fabbione> brrrrrr <fabbione> ok .. last universe full kick back before starting to check the c++ transition status... <fabbione> and that's it for today... <fabbione> i can't work anylonger... * lamont pushes the kernel back to the top of the hill again <fabbione> so.. should i try to remount some extra i386 hw or should i mount the 2 mk68k ?? <fabbione> m68k even <fabbione> lamont: did you find what's wrong? <lamont> dude. take the m68k to the firing range <lamont> fabbione: well, I have a kernel that at least gets started, and one that doesn't. the diff is rather large still <fabbione> ok :/ <lamont> but since it's mostly driver crap, I just added back in PCCARD support, to see how fatal that is. <fabbione> lamont: remember you still have baz capabilities... <fabbione> and i will go VAC from tomorrow around 14:00 UTC <lamont> fabbione: yeah, yeah... once I actually have a fix... <fabbione> lamont: it's more because of me going away.. <fabbione> you know i don't mind to do merges and changes around for porting <lamont> % diff -u config.last itanium | wc <lamont> 2701 5585 60917 <fabbione> sh: line 1: gcc: command not found <lamont> yeah - np <fabbione> doh! <lamont> lol <lamont> you're gonna kinda need that... :-) <fabbione> lamont: that's in a chroot buildd <fabbione> there is gcc <fabbione> OPS * lamont notes that gcc is almost always a symlink <fabbione> sbuildd and buildd SHOULD fail if the chroot-$release is NOT there <lamont> which sbuild are you using? <fabbione> the standard one from db.d.o * lamont looks, finds that he only changed ubuntu's to require --dist, not that the chroot must exist <fabbione> if the chroot doesn't exists, it uses the "host" system <fabbione> BAD BAD sbuild <fabbione> at least it explains the several give-backs... <lamont> fabbione: that's per specification... the chroot is optional... <lamont> although a config variable might be nice <fabbione> desrt: http://people.ubuntu.com/~fabbione/gentoovision_random_o.diff <- <fabbione> desrt: changelog: <fabbione> * switch to use gcc-snapshot <fabbione> * use random -O <fabbione> for better code corruption/optimization <fabbione> desrt: note that the gtk_timeout_add is dangerous <fabbione> i get it to segfault with timeouts < 200 <zul> hmmm..../proc/apci/button has disappeared <zul> mjg59_: ^^^^ should we add it back some users are complaining <zul> http://bugzilla.kernel.org/show_bug.cgi?id=1920 <fabbione> OMG! <fabbione> there is no /dev/inotify! <fabbione> it MUST BE BROKEN!!!! <jbailey> zul: die, proc... DIE! <fabbione> i am supposed to cook dinner, but i really don't feel like... * fabbione considers the option of junk food (again) <karlheg> jbailey, You there? <jbailey> karlheg: Yup! <jbailey> karlheg: How's things? <karlheg> Just emailed you... re: the move-mount of dev from initramfs to real root fs. <desrt> hmm <desrt> what do we have here <desrt> a new kernel? i think so. <karlheg> I thought I'd submitted a patch for that against initramfs-tools init, but it's not there afaict. The 'udev' /etc/init.d script is set up to deal with that now. <desrt> Les NOUVEAUX paquets suivants seront installs: linux-image-2.6.12-5-686-smp <jbailey> karlheg: You had submitted a patch, but I wanted the udev maintainer in DEbian to be on board with it as well. <karlheg> Right, and I think he was, since it looks like the udev init can deal with it now. <jbailey> karlheg: A guy from RH said that they've just removed udev from their initramfs because it's just easier to walk through sysfs yourself and create the block devices we need. <jbailey> Cool. <karlheg> He made my recommended changes. <jbailey> I'll tkae a look at that, since that would work nicely too, for capturing early events. <jbailey> When I had been thinking was a small hotplug handler to buffer all the events to be replayed later. <karlheg> I don't see how that's easier. It's more work and a whole 'nuther routine to write and maintain. <jbailey> Then just make the /dev stuff as discardable and do it as soon as possible on the new system. <karlheg> It seems easier to just re-use 'udevinit'. <jbailey> Well, the case that my thing covers is how to deal with events where the driver isn't available in the initiramfs. Right now it'll get lost. <jbailey> We could ideally skip the whole coldplug phase by just grabbing all the events as they come from the kernel <karlheg> It seems to me that there's no real need for hotplug in the initramfs, since we first probe all modules and then run the udevinit... ? <jbailey> Right. The only thing is that there's a ton of events right now that go by - we just ignore them and trust hotplug to pick them up in the coldplug pass. <jbailey> Either is fine, I think. <karlheg> I need to study that system some more, I think. so, hotplug-ng is dead, and should be ignored? <karlheg> I should look only at 'udev' then? <karlheg> ... and at the Linux kernel support for it? <jbailey> Yes. <jbailey> The whole thing is shifting around, it's hard to keep up with. <jbailey> udevsend gets the event - it sits on the hotplug handler. <karlheg> Ok. I think if we move mount the /dev onto the real file system, that anything having a file in /dev open can keep running no problem. <jbailey> It serialises it to make sure that if it's handling something once, that it doesn't run over itself. It then calls out to various hotplug scripts to handle the event (load drivers, etc) <jbailey> I don't know enough about move mounts to say that it's true, but I suspect it is. <karlheg> So a dummy hotplug script setup could queue the events for replay? <karlheg> I tracked around in the kernel source for that information, and am fairly certain that moving a mount point is Ok in the case where files are open on it. They stay open and the inode is the same. <jbailey> Right. <jbailey> Sweet, thanks for cisneroselizabeth@example.net. <karlheg> Sorry I got side-tracked and did not work on any of this for the last few weeks. <karlheg> I think I have a few days at least, and will try and stay busy on it. <jbailey> No prob, I appreciate the time you're putting into it. =) <karlheg> Any work in progress re porting udev to klibc? <jbailey> My task right at the moment is to finish the DSDT stuff that I need and then do evms. <jbailey> Nope, since I was going to get rid of it. =) <jbailey> It really should replace a 60k binary with a couple hundred lines of shell to generate the block devices that exist on the system. <karlheg> So... does 'udev' do device detection somehow? I'm not clear on that yet... Hmmm... for USB and PCI only, I suppose, plus perhaps a few easy to recognize devices? Even 'discover' has dropped support for ISA; it was not designed for device detection and the heuristics do not always work right. <karlheg> Ah, ok; you are dumping 'udev' from initramfs then? <jbailey> Well, udev just receives the events from the kernel. It's entirely up to each subsystem. <jbailey> udev hands it off to the scripts in /etc/hotplug.d <jbailey> Basically blindly by subsystem. <karlheg> Ah, ok... Hey, let me read code a while before I try to discuss this. <jbailey> It took me a bit to wrap my head around it. Going to OLS helped alot. <karlheg> OLS? <jbailey> Ottawa Linux Symposium. <karlheg> Are you coming to Portland for the OSScon? <karlheg> Fun. <jbailey> It was 820 or so people involved in various bits of Linux development. <jbailey> I like it because it gives me a chance to swap ideas with other distro folks. <jbailey> Like the tip to get rid of udev came from a redhat guy. <karlheg> I cannot afford to attend any pay-for events, but if the convention center is open for booths, etc. I'll probably walk over there and hang out a while. <karlheg> Huh. Are you sure he's not throwing you a red herring? <jbailey> Unfortunately, portland is a little far right now. I'd love to get out there for alot of reasons. (Lots of friends that I miss) <karlheg> I don't know if they do that... some people are just like that. <karlheg> Most in OSS are probably not though. <jbailey> Pretty certain. It was all in context. <karlheg> I quit eating beef. <jbailey> Besides, I c ould grab rawhide and verify it easy enough. * jbailey blinks. <karlheg> Can we get a copy of their code? <jbailey> Yup <jbailey> It's all public. <karlheg> :-) <karlheg> I've not looked into how to do that. Do they use CVS or what? (I'll google it) <jbailey> karlheg: I can recommend a number of good vegan places in Portland, assuming any of them are still open. =) <jbailey> SRPMS. <jbailey> I don't grab stuff from there often, so I have to fiddle with it to get it out. <jbailey> I think you just apply alient to turn it into a .tar.gz or somethign. <karlheg> I'm not going vegan; just no more beef. <karlheg> Alright; I'll try that. <jbailey> I'm vegan. That's the limit of the places I've been to in recent memory. =) <jbailey> (Where recent memory == ~4.5 years ago) <karlheg> Do you know what they call the relevant package? udev is probably same-name. <jbailey> Dunno <karlheg> Ok. <karlheg> Well, I'm off now to grab a sandwich and then to read code. BBL8r. <jbailey> Thanks, Karl! * jbailey needs food <zul> jbailey: yes die proc
{'channel': 'ubuntu-kernel', 'month': 8}