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