[04:19] 686-smp-dbg being built [05:55] morning [05:56] zul: still here? [05:56] lamont: ? [05:59] infinity: ping?? === send [~WinNT@221.218.42.179] has joined #ubuntu-kernel === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel === doko [~doko___@dsl-082-082-206-179.arcor-ip.net] has joined #ubuntu-kernel === JaneW [~JaneW@dumbledore.hbd.com] has joined #ubuntu-kernel [08:42] 686-dbg builds right after 386-dbg, right? [08:44] yes [08:44] it should [08:44] AH AH [08:44] Alright, then we're almost at the point of failure. [08:44] davis has hardware problems [08:44] it started segfaulting also on a hoary chroot [08:44] And by 'hardware problems', you mean 'it came from Apple'? === infinity goes to have a smoke and expects the kernel build to be dead or succeeded by the time he gets back. [08:45] ehhe [08:45] oh shit [08:45] i just trashed the build on concordia! [08:45] oh well it doesn't take long to redo it [08:49] Building 686-dbg now.. [08:49] Please fail, please fail... === infinity joins a religion breifly so he can pray to some god or other, then unjoins. [08:51] hehe [09:00] \o/ [09:00] Yay. It failed the same way. [09:01] And, ofr the record, the chroot is completely up to date. [09:03] oh great suckage [09:04] now it would be interesting to see if the same chroot moved to concordia will complete the build [09:05] infinity: let's try something... [09:06] go where the kernel has been unpacked [09:06] rm debian/build/build-686-dbg/stamp-build (if there is any) [09:06] and do..... [09:07] (Should we try KALLSYMS_EXTRA_PASS?) [09:07] sed -i -e's/# CONFIG_KALLSYMS_EXTRA_PASS is not set/CONFIG_KALLSYMS_EXTRA_PASS=y/g' debian/build/build-686-dbg/.config [09:07] Heh. [09:08] then try to complete the build [09:10] Oh, for.... === infinity forgot the -nc switch to dpkg-buildpackage. [09:10] Thankfully, this is a reasonably speedy machine. [09:10] yeah but you lose the config change [09:10] I know. [09:11] you need to stop and edit debian/config/i386/686-dbg [09:11] so it will be done automatically === infinity tries this again, with his brain engaged. [09:13] infinity: good idea :) [09:18] "There is a simple workaround that is to increase the WORKING_SET define [09:18] in scripts/kallsyms.c to something like 65536. This will include every [09:18] symbol in the token table calculation, so that even if symbol position [09:18] changes, the token table should be the same." [09:18] http://seclists.org/lists/linux-kernel/2005/May/2010.html [09:19] "The problem with this approach is that it takes longer to calculate the [09:19] token table. (~3secs on my P4 2.8GHz, 11300 symbols)" [09:19] I think we can spare 3 seconds on the buildds in the name of working kallsyms. Perhaps this is a patch/fix we should apply. :) [09:20] (Or does it change the installed token table (System.map) to be huge?... That would be a runtime issue, not a build issue. Hrm) [09:23] no idea really [09:23] but than... why does it build on concordia??? [09:23] and locally? [09:23] but not in the buildd? [09:23] i don't believe the patch is the real solution to the problem, tho it can be used to workaround it [09:23] And here's an explanation of the bug [09:23] http://seclists.org/lists/linux-kernel/2005/May/1727.html [09:24] I think the answer to "why does it only happen sometimes?" is "pure luck." [09:25] make sense [09:25] (It may also have something to do with the running kernel, phase of the moon, and your favourite lunch item) [09:26] ehhee [09:27] infinity: we can just test it :) [09:27] infinity: do you still have the unpacked tree? [09:27] Well, Im rebuilding with EXTRA_PASS right now. [09:27] But I like Sam's patch better (expecially since he seems confident it will make mainline) [09:28] i am checking if it has been committed after rc5 [09:28] the problem is that shitnezz is in bk [09:28] and linus doesn't use bk [09:29] no it's not upstream yet [09:33] JaneW: ping? [09:36] Ahh, here's why: [09:36] "As noted in mail sent to you the 14th of March I have this patch queued [09:36] up. But since Linus has asked for a calm down period it will wait [09:36] until next kernel release opens up." [09:37] So we may not see Sam's patch in mainline until 2.6.13 [09:38] After this build, I'll check to see if the problem we're having is, indeed, the problem Sam's patch solves, or a differentone. [09:38] (looks like kallsyms alignment has just been messy in general lately... Look at all the patches to arch-specific areas in the tree for alignment issues...) [09:39] infinity: cool thanks [09:39] IOW, someone broke something recently in the name of "elegance", and everyone else is cleaning up the mess. Yay. [09:40] (Is it too late to switch Ubuntu to a BSD kernel?) [09:40] [09:40] infinity: ahaha [09:40] we can probably consider to create a derivate once lp is in place [09:40] the main issue is "when lp is in place" [09:42] we need a name for the security release [09:42] fabbione: pong [09:42] JaneW: right in time :) [09:42] we need 2 names lady :) [09:42] 2! [09:43] one vegetable/fruit based for the security release [09:43] don;t be greedy [09:43] and the usual nut for breezy :) [09:43] 2 releases.. 2 different targets ;) [09:45] fabbione: kernel - Laughing Lentil [09:45] fabbione: security - Prickly Pear [09:46] JaneW: rocking!! [09:47] oh rc6 is out :) [09:48] JaneW : Nice to see that you've found a niche in Ubuntu. :) [09:49] Yeah, -rc6 is out. That's what I was grepping for alignment changes. :) [09:49] no i was checking directly in git [09:49] and it's not there yet [09:49] there are already a bunch of commits after rc6 including build fixes [09:50] for today let's get this rc5 out with ppc64 and dbg support [09:50] rc6 can wait [09:50] BUT RC6 IS SO MUCH BETTER CAUSE IT HAS A HIGHER NUMBER ON THE END!!! [09:50] even if it should take too long to switch [09:50] hahahahhaha [09:51] So, do you watch the build logs, make a note of every driver that has "I can't write C to save my life" compile warnings, and make a mental note to neevr use those modules on your own system? :) [09:52] no.. i just don't use ubuntu kernels on my machine :) [09:52] ahhahha [09:52] Alternately, there's the "you're using stuff that's been deprecated for 3 years, so obviously you don't maintain your dirvers" warnings. I don't like those much either. :) [09:54] yes [09:54] ops [09:54] infinity: heh yes, it's a tough job, but someone has to do it ;P === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-kernel [10:12] fabbione : Builds fine with EXTRA_PASS. Will try Sam's patch instead now, for kicks. [10:13] (Though EXTRA_PASS should be a good enough bandaid to get this going for now) [10:26] infinity: ok. remember to unset the EXTRA_PASS with the patch [10:27] Yes, obviously. [10:27] If you want to upload a -1.3 with EXTRA_PASS for now, though, it'll work on the buildds, it seems. [10:29] nah i can wait for your extra test [10:29] but hmmm [10:29] yeah [10:29] i will upload 1.3 with EXTRA_PASS [10:29] and we can figure the proper fix for 1.4 [10:30] actually there is another thing we forgot to set in the -dbg packages... [10:30] the ramdisk size that zul was talking about [10:32] Oh? [10:32] infinity: a -dbg initrd is HUGE [10:32] -dbg ramdisks are too big? [10:32] Yeah. That makes sense. :0 [10:32] and the kernel default is not enough [10:32] so either i change the BLK_DEV_RAM_SIZE to a reasonable size [10:32] or we need to figure a hook for grub [10:33] and i guess the former > latter [10:33] now the point is that i trashed all the -dbg images to test :) [10:33] BUT WE HAVE BATTLE STAR CONCORDIA! [10:34] with ccache :) [10:35] goody.. both gcc-4.0 and gcc-3.4 are running the test suite on sparc [10:39] Pfft. I'd feel your pain if I wasn't building gcc-3.3 and gcc-3.4 on m68k right now, after having just done two gcc-4.0 builds in a row. [10:40] ehhehe [11:08] [ ] linux-image-2.6.12-1-686-dbg_2.6.11.93-1.3_i386.deb 07-Jun-2005 09:57 147M [11:08] what's wrong with this???? [11:11] Ouch. [11:11] Also, ouch. [11:11] No one's going to install that. [11:11] Which makes it effectively useless. [11:11] IMO. [11:12] and elmo will hang us on a cross, starts the witch dance and burns us alive [11:12] can you image over a GB of kernel push to the mirror on each update? [11:13] hehehe [11:16] ok backup solution [11:17] we can provide the configs, but not build them by default [11:23] who needs it, will build it [11:24] +he [11:24] That's probably better. [11:25] I'm on 1.5k DSL, and in most of the world, that's still considered a "really good" connection (though I think it's crap), and as a regular user, I would never download a 147 MB package to debug a bug I filed. [11:25] yeah i see no other solution [11:25] And when downloading the source is less bandwidth than downloading the debug package, one starts to wonder. :) [11:25] infinity: actually.. that would be a good way to scare users in filing bugs [11:25] ahhaha [11:26] i need a big fat cigarette [11:26] infinity: 1.5k DSL is fairly measly. :P === infinity heads off to go grocery shopping. [11:26] Back soon. [11:26] Mithrandir : Oh, I know, but it's still "decent" to most poeple. Just not geeks. [11:27] infinity: 1.5k? You mean 1.5M, I hope. [11:27] 1.5k is measly. It's slower than what you get from a 28.8 modem [11:27] Err, yeah. [11:27] 1.5M, obviously. [11:28] I can only dream about 1M+ adsl [11:28] Brain == Lame. [11:28] I need to get a faster networking card, since my router only has a 11Mbit WLAN card which limits my speed to ~2Mbit on my DSL. [11:28] apparently, I have 4Mbit now. [11:28] Lucky. [11:28] I'm hoping to see reasonable DSL speeds here within a year or so. [11:29] that a lot off bandwidth [11:29] not my fault. They're upgrading the DSL for free once in a while ATM. [11:29] I miss my old 7Mbps DSL in Calgary.. [11:29] Mithrandir, what country u in ? [11:29] I ordered 2Mbit which then went to 2.2, 2.4, 2.6, then 4 [11:29] chmj: Norway. [11:29] They claim we'll get ADSL2 and ADSL2+ (14Mbps and 28Mbps, I think) here within a year or so. [11:29] infinity: that's decent enough [11:29] Personally, I can't wait. [11:29] Mithrandir, ahh, the land off lots and lots of bandwidth [11:30] Anyhow. Groceries. Back later. [11:30] you all suck [11:30] infinity: but they'll still steal your money by charging you 100 AUD per microbit. [11:30] but i will probably get 100Mb in a year or 2 [11:30] (O.o) [11:30] Mithrandir : I pay 100AUD flat rate right now for 1.5Mbps unlimited. It's not the kind of cheap I was used to in Canada, but it's reasonable for around here. [11:31] infinity: heh, around 20AUD more than I pay for my 4Mbit unlimited. === Mithrandir tries to debug the acx100 problem [11:31] fabbione: the new driver and i386 worked, at least [11:32] Mithrandir: ah good to know [11:33] fabbione: nah, because then the bug is mine. :-P [11:33] that too :) [11:33] infinity: unpacked kernel is like 500MB ! [11:33] ahhaha [11:33] 41764 -rw-r--r-- 1 root root 42717184 Jun 7 11:33 initrd.img-2.6.12-1-686-dbg === fabbione crashes on the floor [11:34] Hahahahahaha [11:34] *chuckle* [11:34] fabbione: I think something very odd has happened there [11:34] 42 MB initrd! Rock! [11:34] does it come with a free 1GB memory module too? [11:34] mjg59: with all _DEBUG configs turned on [11:35] i will try to rebuild it [11:39] time to get some food [12:40] oddbjoh: fabbione it still blows up with latest upstream. [12:45] Mithrandir: also on i386? [12:45] or only on amd64? [12:45] fabbione: I didn't try very long on i386. [12:46] loads and loads of warnings while compiling on amd64. [12:47] Mithrandir: no shit.. [01:16] mjg59: i did the rebuild.. it's 147MB [01:16] so no -dbg by default [01:22] g'm all. [01:23] hi jeff [01:23] hey jb === doko [~doko___@dsl-084-059-046-215.arcor-ip.net] has joined #ubuntu-kernel [01:30] Hmm. Something is very odd on this machine. [01:30] PCI is basically broken after suspend/resume [01:31] PCI devices are overrated. [01:36] fabbione: Got time for me, or do you need to wait for a bit? [01:36] jbailey: yes in 5 minutes i will be completely your :) [01:36] Excellent. I'll afk for 5 then. [01:46] fabbione : FWIW, Sam's patch also fixed the kallsyms bug. [01:47] infinity: cool [01:51] jbailey: ready to start? [02:00] fabbione: Yup, back now. [02:00] i was almost ready to go again :) [02:02] so what are we going to hack? [02:05] i was gonn ask that [02:09] fabbione: making make-kpkg or whatever the piece is flexible enough to do mkinitramfs as well as mkinitrd [02:09] jbailey: ok than we are talking about kernel-package postinst files that are installed in the linux-image postinstalls [02:10] fabbione: Lovely. [02:10] I'm glad you know where all that crap is. My brain started to go square while reading make-kpkg [02:12] there are a few files that make use of mkinitrd [02:12] or call it [02:13] for what i can see we need to modify image.preinst and image.postinst [02:13] Are they all after /etc/kernel-img.conf has been sourced? [02:14] i am checking... [02:14] If yes, we can just do ramdisk = /usr/sbin/mkinitrd, and then refer to "${ramdisk}" [02:15] jbailey: for the preinstall 1) source the config and check the path to mkinitrd [02:15] i guess the call happens later on [02:16] probably only in postinst [02:16] preinstall looks more like a sanity check before messing around [02:16] MAkes sense. No sense unpacking the kernel for 30 minutes on an m68k box if it's setup poorly. [02:18] right [02:18] the postinst creates the image and does all the work of checking/unchecking [02:20] jbailey: we definetely want to make the change as smooth as possible and configurable [02:20] Right. [02:20] I can make the initramfs args the same as the initrd ones, that's easy enough. [02:21] jbailey: i think we shouldn't get crazy to make the same [02:21] but if you think that the args can be the same [02:21] it's even easier [02:21] I think it sounds less miserable than making the interface from the postinst configurable. =) [02:22] Yeah, there isn't a problem. [02:22] uh that's easy enough :) [02:22] also because we want to get these changes upstream [02:22] we don't want to blindly replace mkinitrd, do we? [02:22] or we want? [02:22] Well, that's why I'm thinking with a variable [02:23] If we call it as ${ramdisk}, where the default is /usr/sbin/mkinitrd [02:23] I will override it during my development here as /usr/sbin/mkinitramfs [02:23] And when it's time to switch, we just change the default, and what the Depends: line has. [02:23] that's more complicate than my solution :) [02:24] well actually... why do we need to touch kernel postinstall at all??? [02:24] let's make it in a very simpler way [02:25] 1) make mkramfsthingy to accept the same options as mkinitrd [02:26] 2) upload a mkinitrd package with the wrapper in place of mkinitrd [02:26] (and rename mkinitrd as mkinitrd.whatever) [02:26] And then alternatives it? [02:26] 3) upload ramfsthingy with the config file for the wrapper [02:26] no.. the wrapper will read the config file and use mkinitrd or the other one [02:26] Oh ugh. [02:26] This is simpler? [02:27] at this point all the changes are done outside the kernel [02:27] yes [02:27] becuase you change the default in the config file and you are done [02:27] when you want to kill mkinitrd, you just do it, changing the default and removing the mkinitrd.orig [02:27] and you didn't touch any of the other packages [02:28] it's all done at a lower level that the kernel doesn't give a rat ass about :))) [02:28] I think we're talking about a 2 line change to the kernel postinst, though. [02:28] jbailey: it's a 2 line changes that are objects of other variables... [02:29] first we need to change kernel-package [02:29] 3 line. [02:29] my $ramdisk = "/usr/sbin/mkinitrd"; # initrd generating program [02:29] the configs in kernel-packages can be overridden by the user and that affects also kernel postinstall [02:29] + upload the kernel with the new postinstalls [02:30] $ramdisk = "$1" if /ramdisk\s*=\s*(\S+)/ig; [02:30] and your packages to make all the above working :) [02:30] And change the line that contains "mkinitrd" to '$ramdisk' [02:30] And the solution of futzing with the postinst means that anyone can change this at a later tim. [02:31] Otherwise mkinitrd has to grow a wrapper, has to analyse a foreign config file and there's no future flexibility. [02:31] Like in case the yaird folks want to make it possible to use their setup under Debian. [02:31] hte configfile only has one entry... mkinitrd.real = true|false [02:32] Ugh You mean use an extra config file? [02:32] it doesn't need to use a foreign config file [02:32] I think that's wrong. [02:32] I think it needs to be in kernel-img.conf [02:32] Otherwise people are having to look in yet another place for this. [02:32] And there's still no flexibility [02:32] that is right, but you said you needed this for testing, didn't you? [02:32] So it would wind up having to parse it out, and forces us to keep the mkinitrd name. [02:32] or do you want to go directly for final solution? [02:33] Right, but why not make it flexible enough to do more when it appears to be a 3 line change in one file. =) [02:33] because take into account that a change to kernel-package might not go into debian :) [02:33] I'll NMU it in if I need to. [02:33] =) [02:33] initramfs is coming to town there too. [02:33] As is yaird [02:33] jbailey: that'd be Manoj's toy :) [02:33] (I will likely sponsor) [02:33] I haven't had NMU wars with someone in ages. =) [02:35] hmm ok [02:35] if you prefer that way we can do it [02:35] I'mve pinged manoj to check with him. [02:35] i really don't mind [02:36] But for 6 lines of changes (including the preinst check), it seems... excessive to add a new config file and a wrapper and all that. [02:36] sure i understand your point [02:36] i was considering the option to keep all the initrd/ramfs creation stuff outside of kernel build-deps and depends... [02:37] that will also require the ramfs to Depends: on kernel-package [02:37] that is actually only a build-dep for the kernel [02:38] hmm. [02:38] forgot about the depends: thing. [02:38] specially if you want it configurable [02:39] hmmhmmhm [02:39] Well, I suppose that could be done with provides on our side. [02:40] uh????????? [02:40] if you want /etc/kernel-img.conf you want kernel-package [02:40] that right now is only a b-d [02:40] with your change it needs to be a depends [02:41] if not for linux-image, it needs to be for the ramfs package [02:41] for linux-image is enough it's unpacked and the config there [02:42] Sorry, lagging a second from the phone.. [02:43] sure [02:43] don't worry [02:44] i am preparing 1.3 for upload [02:44] just to get ppc64 to boot and i386 to build :) [02:46] brb [02:47] Umm. [02:47] Okay, I don't think your statemenet about kernel-img.conf coming from kernel-package is true. [02:47] I think it's placed there by d-i. [02:47] If it's not there, the kernel will refuse to install, since it won't have do_initrd = Yes [02:52] dpkg -c /mirrors/ubuntu/pool/main/k/kernel-package/kernel-package_8.135ubuntu2_all.deb [02:52] -rw-r--r-- root/root 965 2004-11-17 17:33:32 ./etc/kernel-pkg.conf [02:52] oh kernel-img.conf [02:52] =) [02:52] hell i was looking at the wrong file [02:53] which package provides kernel-img.conf? [02:53] Nothing does. [02:53] kernel-package: /usr/share/doc/kernel-package/examples/sample.kernel-img.conf [02:53] kernel-package has the manpage and so on [02:53] but not the config file [02:54] asking Kamion in #u-d [02:59] yo [03:00] hey zul [03:00] zul: i have a bad news [03:00] hmm? [03:00] we need to revert the -dbg stuff [03:00] just the 686 image is like 147MB [03:00] * Do not build -dbg flavours automatically since images are huges, but still [03:00] provide configs in debian/config/debugging/$flavour for the users. [03:01] that's the best we can do :( [03:01] thats fine.. [03:02] less work for me then [03:02] btw 12rc6 is out [03:02] goody [03:03] heh...it seems like everything i do is dropped ;( [03:04] zul: it wasn't really an option to push more than a GB of data on each kernel upload [03:04] sorry.. [03:04] i didn't expect them to be so big [03:04] i know..i said that tongue in cheek [03:07] fabbione: rc6 should contain the module information that you told me about, yes? =) [03:08] jbailey: yes it does [03:08] w00t === jbailey asks nicely for it. =) [03:08] jbailey: so if you want to go ahead and change kernel-package is fine for me [03:08] fabbione: What I was thinking of for the build-dep, is that I could make mkinitrd Provides: kernel-ramdisk [03:08] jbailey: that will be tomorrow's stuff [03:09] fabbione: For now if you depend on mkinitrd | kernel-ramdisk, and change it later to initramfs | kernel-ramdisk that might solve the problem. [03:09] Depends: initrd-tools (>= 0.1.78ubuntu1), coreutils | fileutils (>= 4.0), module-init-tools (>= 0.9.13) [03:10] jbailey: can't the 2 packages co-exist? [03:10] ok.. hold on.. [03:10] let's make a point here [03:10] Sure... [03:10] are we doing all this config stuff only for testing?? [03:10] It's not a conflicts, it's just to make sure you have something providing it. [03:10] or is it going to be the final solution? [03:11] because given that NOBODY owns /etc/kernel-img.conf [03:11] I'd like it to remain forever to allow some flexibility. [03:11] i am really unhappy of something mangling it [03:11] nobody owns it, but you're the only one using it. [03:11] given that we don't have the previous state of the config file [03:11] jbailey: are you sure? [03:11] i am one of the package using it [03:11] we are not sure i am the only one [03:12] also.. who is going to mangle it? [03:12] to switch default? [03:12] I haven't encountered anything else using it, and the name suggests that it's for you. [03:12] No, nothing should ever need to mangle it. [03:12] That's why everything just defaults to initrd-tools for now. [03:12] so if you make it configurable, how are we supposed to switch default? [03:12] if the default is in the config? [03:12] We just change the default when no configuration is provided. [03:12] Default doesn't go in the config. [03:12] ok [03:14] so let's summarize the steps: [03:15] 1) change kernel-package/kernel/postinst to look for that ramdisk var [03:15] 2) upload initrd-tools to provide kernel-ramdisk [03:16] 3) switch the images to Depends: initrd-tools | kernel-ramdisk [03:16] 4) test test test [03:16] 5) switch linux-image Depends: to initramfs | kernel-ramdisk [03:17] even if i really don't see the point in the kernel-ramdisk thingy [03:17] we could just switch the default and that's it [03:18] or perhaps you want to have kernel-ramdisk Provided by both initramfs and initrd-tools preferring one of them? [03:25] jbailey: are you still around? [03:25] i need to stop soon [03:25] i am tired to death [03:25] fabbione: Right. The only advantage of the kernel ram,disk stuff [03:25] is flexibility. [03:25] I'm not too worried about that. [03:25] ok [03:25] The config file on its own would make me happy. [03:26] I'll ping manoj to figure out how likely it is that he'll accept it. [03:26] do you want to start with kernel-package? [03:26] Yes. [03:26] ok [03:26] Mind if I do the hackery and upload? [03:26] not at all [03:26] go ahead :) [03:26] Lovely. [03:26] I'll try to push it into Debian sanely so that you can just sync again. [03:27] i don't care who uploads my package, until i know who is working on them and why :) [03:27] meh kernel-package is desynced anyway [03:27] i did try to talk with Manoj unsuccessfully for a few days now [03:27] Yup. Ilike to check to make sure I'm not running over other work that's being done. [03:27] well there are the changes to make powerpc64 a buildable image :) [03:27] If he doesn't reply, it's easy. I NMU in Debian because of unresponsive maintainer. [03:28] jbailey: not all ubuntu changes should go in Debian [03:28] No, just this one. [03:28] I know you're trying to keep it the same. [03:28] exactly [03:28] but for ubuntu go ahead and do it... [03:29] so we can test the solution and propose it to Manoj as "tested and it works" [03:29] Cool. I'll get that in by the end of my day. [03:29] perfect [03:29] This is supposed to be my support day, so I'll be writing specs today. [03:29] Perhaps I'll wake up the laptop and do so on the roof deck. [03:29] jbailey: poing 1 and 2 is your stuff :) [03:29] i will do point 3 in prepartion with 12rc6 [03:29] that would be my tomorrow [03:30] I'll just do point 1 for today. [03:30] I'm not fussed about the kernel-ramdisk bit for now. [03:30] ok [03:30] I haven't thought that part through completely. [03:30] I've only thought through the config file. [03:31] ok well.. there is always the option to upload an ramfs that Conflicts/Provides mkinitrd [03:31] And it solves my immediate need that all my systems should be running initramfs' now to make sure I'm testing enough. [03:31] just for the testing time [03:31] Can't, kernel-packages have a versioned depends. [03:31] The provides lose out. [03:31] ah crap [03:31] ok [03:31] well let [03:32] well let's go trough point 1/3 asap [03:32] so you get an easy working environment [03:32] we can rethink the other bits later [03:32] initrd and initramfs coexist. [03:32] So there's no fuss. I don't care for now what gets depended upon until we switch. [03:32] That's why I'm content to leave it alone for my testing. [03:32] oky [03:33] i guess i am off [03:33] i might pass by later [03:33] Thanks for staying up for me, Fabio. g'd evening! [03:34] no problem dude [03:34] it's just that today i am more tired than usual [03:34] otherwise i would have done the implementation with you [03:35] I think I've actually finished the implementation now, I just need to test. === lamont__ [~lamont@15.238.5.47] has joined #ubuntu-kernel [05:08] fabbione: did you put up rc6? [05:33] zul: He said that was tomorrow's work. [05:43] ah ok === Nafallo [~nafallo@nafallo.user] has joined #ubuntu-kernel === Nafallo [~nafallo@nafallo.user] has left #ubuntu-kernel ["Read] [07:14] there is a cc meeting today isnt there? === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel [09:47] i hate dealing with recuriters [10:31] zul: i will start 12rc6 tomorrow.. [10:31] i am off to bed now [10:35] ok [11:25] mjg59: ping