[12:19] <BenC> jbailey: hey, are you sure your G5 hangs, or does it drop to busy box after 3 minutes?
[12:20] <BenC> jbailey: No way to pull from Linus's tree now, he's on to 2.6.18
[12:23] <crimsun> we may have a fix for bug 34831; just waiting for more feedback before pushing
[12:30] <BenC> excellent
[12:30] <BenC> zul: ping
[12:31] <BenC> crimsun: I'm assuming that any patches I get from you for dapper sound can be merged into edgy now?
[12:32] <crimsun> BenC: yes, with the caveat that since I target dapper, there may be some backported typedefs, etc. I can attach a note for Edgy to each dapper patch if you'd like.
[12:33] <BenC> yeah, that'd be nice
[12:33] <crimsun> all right, will do.
[12:39] <BenC> zul, crimsun: all patches from you guys are in dapper, will pull to edgy soon
[12:39] <crimsun> BenC: many thanks.
[12:40] <BenC> crimsun: no, thank you :)
[01:32] <Keybuk> zul: ping
[02:01] <zul> Keybuk: pong
[02:02] <Keybuk> zul: you did an upload of kernel-package today
[02:02] <Keybuk> but didn't take the opportunity to merge it
[02:02] <Keybuk> do you want to do that?
[02:02] <zul> yes i did..
[02:02] <zul> i only added the xen stuff i dont know what will break in edgy if i merge it
[02:03] <zul> i think that might be up to benC
[02:03] <Keybuk> ok, I ask because now you've uploaded, you've cleared the "outstanding merge" flag :p
[02:04] <Keybuk> and you've put your name against it for nagging
[02:04] <zul> meh...
[02:04] <zul> ill take a crack at it after i do the kernel security stuff on my todo list 
[02:06] <crimsun> Keybuk: question about effects of Edgy's udev if you have a few moments
[02:10] <Keybuk> crimsun: sure
[02:10] <crimsun> Keybuk: I'm looking at the Edgy alsa-utils merge, and there's a udev rule from Debian Sid, "KERNEL=="controlC[0-7] ", ACTION=="add", RUN+="/lib/udev/alsa-utils".  Do you prefer the older (Dapper's) [..] RUN+="/sbin/start-stop-daemon --start --background --pidfile /var/run/alsa/bogus --startas /etc/init.d/alsa-utils -- start %n"? The question is whether /lib/udev/ is the Right place to have alsa-utils versus /etc/init.d/ .
[02:10] <Keybuk> so I prefer the Debian way of having it in /lib/udev
[02:11] <Keybuk> though that rule should be fixed to just RUN+="alsa-utils"
[02:11] <Keybuk> there's a potential bug though ... does alsa-utils still use stuff in /usr ?
[02:12] <crimsun> not that I can see.
[02:13] <Keybuk> ok, then go with the Debian stuff
[02:13] <crimsun> all right, and thanks for your time.
[02:37] <BenC> zul, Keybuk: I'll do kernel-package merging
[02:37] <BenC> it's a hell of a lot of work, because we have some special cases that need to be handled (auto run of boot loaders, update-initramfs, etc)
[02:38] <Keybuk> *nods*
[02:38] <Keybuk> just as long as it's not forgotten :p
[02:38] <zul> BenC, thats what i thought
[03:34] <Keybuk>    * ata_piix: Disable PATA support for now.
[03:34] <Keybuk> BenC: ? ^
[03:41] <BenC> Keybuk: there's no way to blacklist it and have sata_piix work
[03:41] <BenC> ata_piix handles both pata and sata in Alan's patched up stuff
[03:42] <BenC> it broked my ia64
[03:42] <BenC> probably break others as well
[03:54] <Keybuk> ah, I see
[03:55] <Keybuk> by "broke" I assume you mean the migration stuff wasn't in place
[03:55] <Keybuk> rather than flat-out-didn't-work?
[04:14] <BenC> that would have been the case, but the reality was the pata part crashed on boot
[04:14] <BenC> zul: !!!!!
[04:14] <BenC> /usr/share/kernel-package/rules:2198: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.
[04:14] <BenC> kernel-package is causing FTBFS on latest kernel upload :/
[04:15] <BenC> zul: please fix ASAP, and reupload
[04:26] <BenC> zul: nm I got it
[04:26] <zul> frig...sorry
[04:36] <BenC> np, just gotta find someone to redo the kernel upload after this gets through
[04:36] <BenC> get it out of failed state that is
[05:51] <crimsun> awesome, confirmed fix for 34831
[02:22] <zul> hiho..
[03:37] <jbailey> BenC: 'kay.  I'll try and twiddle that change so that it applies against our tree and send it to you.
[03:37] <jbailey> BenC: I'm not sure if it'll drop to busybox or not.  yaboot sucks enough that I haven't thought to remove 'splash' from the bootup so I can see what's going on.
[04:04] <makx> BenC: concerning kernel-package you could use mkinitramfs-kpkg too
[04:05] <makx> it's the default in Debian and does basically the same than update-initramfs -c -k <kernelversion> but with old style compat mkinitrd calling option..
[04:05] <makx> although that would need an initramfs-tools merge first *hint*
[04:05] <makx> and there you have special cases as we don't do the fb stuff right now
[04:09] <jbailey> makx: Adam's most likely to do the initramfs-tools merge, and he's not around this week.
[04:33] <BenC> jbailey: If it drops to busybox, usplash will disappear...you have to give it like 3-5 minutes though
[04:34] <BenC> jbailey: does your G5 use sata_svw for the rootfs?
[04:35] <jbailey> BenC: Is there any easy way to get a /proc/mounts to /proc/modules mapping? =)
[04:44] <BenC> wish there was
[04:44] <BenC> lsmod | grep sata_
[04:44] <BenC> if it's in the module list, then you are likely using it
[04:44] <jbailey> It's not.
[04:44] <jbailey> Lemme check dmesg
[04:44] <jbailey> Meh
[04:44] <jbailey> ntpd(23977): floating-point assist fault at ip 4000000000030e11, isr 0000020000000008
[04:44] <jbailey> filled up my logs.
[04:45] <BenC> it's weird on my G5, it hangs waiting for the rootfs, and finally drops to busy box after the timeout
[04:45] <BenC> it hasn't even tried to load sata_svw, and when I modprobe it from busybox shell, it just hangs further
[04:45] <BenC> I need a way to do a dmesg
[04:46] <jbailey> BAHa
[04:46] <jbailey> that was myia64.
[04:46] <jbailey> Lemme check the right box.
[04:47] <BenC> rofl
[04:47] <jbailey> sata_svw               14852  12
[04:47] <BenC> yeppers
[04:58] <fabbione> hey BenC 
[04:58] <fabbione> BenC: Keybuk did punch back the kernels
[05:26] <BenC> fabbione: cool, thanks
[05:26] <fabbione> BenC: yoo
[05:26] <fabbione> BenC: bzr merge -r somerev foobranch <- what's the git equivalent for that?
[05:27] <BenC> cherry pick?
[05:27] <fabbione> yeah but if i need to cherry pick from another branch that's not local
[05:27] <BenC> git-cherry-pick <sha of commit>
[05:27] <BenC> it will still grab it
[05:27] <BenC> ah, hold on
[05:27] <zul> is there a way to save the chatlog on irssi?
[05:27] <fabbione> BenC: non local?
[05:27] <BenC> do you have the branch in your local git?
[05:28] <fabbione> BenC: nope
[05:28] <BenC> git-fetch <remote>
[05:28] <BenC> then use git-cherry-pick for the sha
 is the remote repo i guess
[05:29] <BenC> yeah
[05:29] <fabbione> ok thanks a lot
[05:29] <BenC> something like : git-fetch rsync.kernel.org:/pub/.../linux-2.6 upstream-linux
[05:29] <BenC> the "upstream-linux" will create a branch with that name refering to the remote, but wont merge/pull it into your local HEAD
[05:30] <fabbione> thanks
[05:31] <BenC> You can also create a file to make it easier
[05:31] <BenC> $ cat .git/remotes/upstream-linux
[05:31] <BenC> URL: ssh://master.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
[05:31] <BenC> Pull: master:upstream-linux
[05:31] <BenC> then I just do "git-fetch upstream-linux" whenever I want to grab Linus's stuff
[05:32] <fabbione> ah nice
[05:32] <fabbione> BenC: thanks for the explanation
[05:33] <fabbione> BenC: the overall was for thombot that's trying to test a patch for #37452
[05:33] <fabbione> BenC: it seems pretty straightforward
[05:33] <fabbione> thom can probably test the fix for you
[05:34] <thom> i have ~15 4100s sat next to me that i'd quite like to use, so yeah
[05:35] <BenC> *   edgy sparc   Successfully built 
[05:35] <BenC> fabbione: sparc builds again :)
[05:36] <fabbione> BenC: neat :)
[05:36] <BenC> fabbione: also, sparc is now included in the kernel daily builds
[05:37] <fabbione> ehhe
[05:37] <fabbione> faure?
[05:37] <fabbione> or some other fancy toys
[05:38] <thom> BenC: the interesting patch is http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=816aa907b909177bdf6e6e6b0d00c5e5a6e2be8c FWIW
[05:39] <fabbione> thom: i guess you need kernel and installer to test, right?
[05:39] <fabbione> thom: is a netboot image an acceptable solution?
[05:39] <fabbione> or do you need a cdrom based install?
[05:40] <thom> well, given an updated git tree i have the rest of the stuff i need to blow updated cds
[05:40] <fabbione> (at least to test)
[05:40] <fabbione> oh it's because it's easier for me to build you a netboot image :)
[05:40] <thom> i have lots of idle cpu cycles round here that i can happily use
[05:41] <BenC> thom: if it works, shoot me an email and I'll pull that into dapper's next upload
[05:42] <BenC> which will likely be very soon
[05:42] <fabbione> BenC: he needs a git tree :)
[05:43] <BenC> shit, I can probably build you a kernel with that patch very quickly :)
[05:43] <thom> BenC: i suspect it'll take me some hours to get my head round exactly which patches i need, so if you have any spare cycles to do a backport that'd be lovely :-)
[05:43] <thom> (that patch doesn't apply cleanly fwict)
[05:44] <fabbione> it's probably faster to backport the driver, but be aware that's the same on the T1000/T200
[05:44] <fabbione> i won't be happy if it breaks :D
[05:47] <thom> fabbione: but presumably you have the same problem - that you can't use raid on the controller?
[05:47] <fabbione> thom: i wish i could tell you because the firmware doesn't allow you to setup raid yeet
[05:47] <fabbione> yet
[05:47] <thom> heh, ok
[05:47] <fabbione> but yes. it's supposed to support RAID 
[05:47] <BenC> wow, there's been at least 20 commits against drivers/message/fusion/ since dapper
[05:48] <BenC> the diff against that directory is > 300k :/
[05:50] <BenC> you may just be SOL
[05:50] <thom> ok, no worries if that's the case
[05:51] <BenC> if you can narrow down the patch you need to something more manageable, I'd take it for dapper
[05:51] <thom> sure, i'll give it a go
[05:51] <BenC> pointless for me to guess
[05:51] <fabbione> BenC: i guess looking at the commit above isn't enough
[05:51] <fabbione> tho it's pretty simple commit
[05:52] <BenC> not sure if it depends on any of the 20 other commits that came before it though
[05:52] <BenC> that's the guessing part :)
[05:52] <BenC> it should be easy to manually merge that code in
[05:52] <BenC> give it a whirl and see what happens
[05:53] <BenC> FYI, mutex_unlock() == up() in dapper
[05:53] <BenC> fuck it, let me just get you a working diff to build with
[05:54] <fabbione> go ben!
[05:56] <thom> BenC: cheers!
[05:59] <BenC> email?
[05:59] <thom> thom@ubuntu.com 
[05:59] <BenC> this is a down and dirty simple merge, it's missing the topology locks (something that isn't present in dapper) so I'm a little leary about it actually working
[06:00] <BenC> sent
[06:01] <thom> thanks, we'll see how it goes
[06:02] <BenC> if you need help getting the ubuntu git tree, see topic...there's a nice wiki that walks you through it
[06:02] <BenC> or just grab linux-source-2.6.15 from the archive
[06:04] <thom> yeah, was just gonna grab l-s
[06:49] <BenC> mjg59: ping
[07:01] <mjg59> BenC: Hi
[07:07] <BenC> mjg59: I have a fix for nsc-ircc
[07:07] <BenC> it was using pnp_register_wrong...expecting non-zero to mean success, when in reality it returned the number of devices that matched
[07:07] <BenC> err, pnp_register_driver wrong
[07:08] <BenC> so it wasn't calling pnp_unregister_driver on unload because it thought the reg failed
[07:11] <mjg59> Ah
[07:11] <mjg59> Cunning
[07:16] <thom> BenC: unsurprisingly that patch went bang, i'll see if i can cook a reasonable one up a bit later
[07:17] <zul> BenC: i applied the ppc fix for breezy
[07:17] <BenC> zul: how's breezy look otherwise?
[07:17] <BenC> I'm updating the vuln page
[07:17] <zul> builds, havent run it yet...will do when i get home
[07:17] <BenC> did the ppc fix apply to hoary at all?
[07:18] <BenC> so breezy has all the patches?
[07:18] <zul> havent gotten to it yet..still at work
[07:18] <zul> yes
[07:19] <BenC> IPC: access to unmapped vmalloc area in grow_ary()
[07:19] <BenC> what about that one?
[07:19] <BenC> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9a5cd5d2a57fb76dbae2115450f777b69beccf7
[07:19] <zul> no i didnt see it
[07:20] <zul> ill do the patch when i get home
[07:20] <BenC> was sent under a seperate email
[07:20] <BenC> ok
[07:20] <zul> hmmm...when was it sent?
[07:21] <BenC> couple of days after the initial list
[07:21] <zul> i dont think i got it
[07:27] <zul> arggh...this is riduculus 128 people on an adsl connection
[10:55] <crimsun> Keybuk: ping (regarding alsa-utils's /lib/udev/ usage)
[10:55] <Keybuk> crimsun: hello
[10:56] <crimsun> Keybuk: yesterday you mentioned there may be a bug if /usr is still used, and having inspected the alsa-utils initscript, I see /usr/bin/amixer is called. Does this have anything to do with said bug?
[10:57] <Keybuk> yup
[10:57] <Keybuk> people with /usr on a separate partition wouldn't get their sound card initialised
[10:57] <Keybuk> which is why we have the evil start-stop-daemon while/sleep hack
[10:58] <crimsun> ok, so we'll still need that in udev.rules in addition to the sleep in the initscript
[11:09] <Keybuk> for now, yes
[11:10] <Keybuk> this may be fixable within edgy by using an upstart event instead
[11:11] <crimsun> ok, I'll read that spec after I finish this merge
[11:11] <crimsun> thanks
[11:11] <Keybuk> basically udev would trigger a "sound card found" event at that point
[11:11] <Keybuk> and we'd start the "restore alsa mixer levels" service
[11:12] <Keybuk> that service would define that it needs writable filesystems (/usr) to function
[11:12] <Keybuk> so would inherently wait for that to happen