[01:46] <LLStarks> hi
[01:46] <LLStarks> i'm having a problem with b44 loading in 2.6.31-10
[01:47] <LLStarks> can someone help me?
[09:01] <Q-FUNK> howdy!  would anyone know what broke KMS yesterday and how to fix it?
[09:10] <smb> Q-FUNK, There had been disturbances in the (buildd) force which broke things in general. I am currently checking whether it is better now
[09:11] <Q-FUNK> smb: buildd and upstart, yes.
[09:12] <Q-FUNK> this transition to event-based eveything is extremely ill-timed, to say the least.  it really should have been pushed to karmic+1.
[09:14] <smb> I agree, the timing was not ideal. It seems if you can do an upgrade using a chroot now, it seems to be at least in a usable state
[09:14] <smb> I saw some errors flying by but at least a gui comes up with a usable mouse
[09:14] <smb> and bash
=== mzz_ is now known as mzz
=== mzz_ is now known as mzz
[12:11] <Unggnu> hi all
[12:12] <Unggnu> I just wanted to ask if someone can take a look at this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/421662
[12:12] <ubot3> Malone bug 421662 in linux "Dell Inspiron 1525 WLAN (Intel 3945) doesn't work with Ubuntu Kernel in Karmic [regression]" [Undecided,New] 
[12:12] <Unggnu> Karmic release isn't far away so I am worried :)
[12:14] <Unggnu> It seems that the Ubuntu kernel thinks that WLAN is disabled while it is not. At least the mainline kernel and the old ones don't have this problem
[12:33] <JanC> hm, I have a laptop with a 3945ABG wlan, but it's not a Dell
[12:34] <Unggnu> JanC, yes, someone else confirmed that it worked with his 3945
[12:35] <Unggnu> I also need the backport modules in Hardy so I guess it is a special card :)
[12:37] <JanC> Unggnu: maybe different radio chip ?
[12:38] <Unggnu> It was the standard model. You couldn't change it when you were ordering the Ubuntu Dell Notebook.
[12:38] <Unggnu> I would have prefered the 4945 or how it is called but it was not possible from Dell
[12:40] <JanC> hm, main pci-id is the same, but yours is subsystem 8086:1021, mine is subsystem 8086:1001
[12:41] <Unggnu> I guess we need another one with a Dell Inspiron 1525 and the same radio chip :)
[14:06] <apw> cjwatson, is ia64 ok for builds?  that one failed to build for chroot issues for .34, are we expecting admins to resubmit those or at this stage is it do your own?
[14:07] <cjwatson> ia64 is hosed
[14:07] <cjwatson> package maintainers don't need to worry about it
[14:07] <apw> ok thanks
[14:08] <cjwatson> basically, ignore ia64 for the time being, until somebody gets dbus ported
[14:08] <cjwatson> http://launchpadlibrarian.net/29635553/buildlog_ubuntu-karmic-ia64.dbus_1.2.16-0ubuntu2_FAILEDTOBUILD.txt.gz
[14:09] <cjwatson> also, in general, you can ignore "chroot problem" as a failure - buildd admins will take care of that
[14:10] <apw> cjwatson, thanks for the info
[14:11] <rtg> apw, have you noticed if ccache is still working for you?
[14:11] <apw> can't say i have noticed ...
[14:11] <rtg> on karmic, tha is
[14:11]  * apw looks at his stats
[14:32] <apw> smb, do you have karmic available for testing on your aspire one?
[14:32] <apw> wondering if the rfkill works ok on there
[14:33] <smb> apw, Yep, got a card with it. Should I upgrade it or not for the test?
[14:33] <apw> wouldn't need upgrading i don't think if its pretty recent
[14:34] <smb> lets see
[14:34]  * smb is booting
[14:34] <smb> Looks a bit old -9 kernel only
[14:38] <smb> apw, At least with that kernel I got wireless
[14:39] <apw> does rfkill work do you know
[14:39] <smb> The physical switch or the command?
[14:41] <smb> If I pull the wireless switch I loose connection but it is something hardware internal as it is not reflected in hard blocked state
[14:42] <apw> so the wireless disable switch works ok on yours ... with the default kernel
[14:43] <apw> and it comes back ok when you toggle it again?
[14:43]  * smb just says goodbye to his card games adn updates
[14:43] <smb> apw, Right
[14:43] <apw> strange, we have a patch to fix your machine which is not in karmic, and seems to apply
[14:43] <smb> It acts a bit weird as the software is not notified (nm tries to reconnect like mad)
[14:43] <apw> yet you are ok without it, i guess i'll drop it then
[14:44] <smb> if you mean the patch to not do soft rfill in acer-wmi
[14:44] <apw> yeah that one
[14:44] <smb> upstream acer-wmi completely blacklists the aa1
[14:44] <apw> ahh ok, then its got fixed that way, nice
[14:44] <smb> seems the whole wmi interface there is buggered
[14:44] <apw> so i can sensibly drop it
[14:45] <smb> ack
[14:45] <apw> good enough
[14:48] <rtg> *sigh* it doesn't pay to update some days. my raid0 server has stopped booting after running /scripts/init-bottom
[14:49] <ogra> rtg, it really helps to read the topic in #ubuntu-devel where such breakage gets pre-announced 
[14:49] <ogra> (or at least announced on discovery)
[14:49] <rtg> ogra, too many channels...
[14:50] <ogra> pfft
[14:50] <ogra> but i agree we should kill things like -kernel, -arm, -mobile -desktop and go back to just use #ubuntu-devel again
[14:51] <ogra> all that annoying fragmentation only came up over the last years
[14:51] <rtg> ogra, maybe I'll just install Hardy 'cause its my build box.
[14:51] <gaspa> ogra: +1
[14:52] <ogra> gaspa, sadly its way harder to close channels than to open them :)
[14:52] <gaspa> I know.
[14:53] <gaspa> but for me it's quite a problem, I'm interested in lots of different areas... and I just can't have so much opened tabs ...
[14:54] <ogra> i only have 26 open atm
[14:54] <gaspa> O_o you won.
[14:54] <ogra> on bad days its 40 :)
[14:54] <gaspa> usually over the 15th I start to kill them.
[14:54] <gaspa> :P
[14:58] <apw> pgraner, do you now have a PC Beep channel in your alsa mixers?  wondering if you are affected by bug #331589 on karmic or not
[14:58] <ubot3> Malone bug 331589 in linux "Extremely loud and intrusive system beep with (some?) HD Audio devices" [Medium,Fix committed] https://launchpad.net/bugs/331589
[15:00] <pgraner> apw: on which box (or all of them?)
[15:00] <apw> i am unsure which one you were seeing it on, i think you are listed as affected, but likely your 1330
[15:00] <pgraner> apw: that one no longer has karmic on it :-(
[15:01] <apw> manjo has one, i'll ask him
[15:01] <pgraner> apw: I'll have to boot a usb stick and test. I have yesterday's daily on usb, I'll try as soon as I can get access to it
[15:01] <pgraner> apw: manjo is onsite today
[15:01] <apw> he likely has the kit with him then, and running karmic :)
[15:02] <pgraner> apw: right now I can get to the 1330 due to -EWIFE
[15:02] <apw> i suspect touching that machine before the weekend is a bad plan for you full stop
[15:02] <apw> it can wait for manjo and i've sent email to TheMuso as the bug i am wondering about was from him
[15:21]  * rtg has his server running in recovery mode. 
=== arvind_k is now known as arvind_khadri
[15:52] <apw> rtg, deliberate action or a disaster recovery?
[15:53] <rtg> apw, total borkage after this last update
[15:54] <apw> rtg ahh i was lucky to miss that, left just in time
[16:25] <apw> rtg in jaunty we enabled GADGET_DUMMY_HCD and that had some fallout for the ABI and you worked round it with:
[16:25] <apw> index e69de29..b711024 100644
[16:25] <apw> --- a/debian/abi/perm-blacklist
[16:25] <apw> +++ b/debian/abi/perm-blacklist
[16:25] <apw> @@ -0,0 +1,3 @@
[16:25] <apw> +net2280_set_fifo_mode
[16:25] <apw> +usb_gadget_register_driver
[16:25] <apw> +usb_gadget_unregister_driver
[16:25] <apw> would it be more reasonable to just bump the abi in karmic, or should i follow that?
[16:25] <rtg> apw, just bump the ABI
[16:26] <apw> will do
[17:16] <Q-FUNK> re
[17:29] <Q-FUNK> has anyone found the reason why KMS no longer works in Karmic?
[17:32] <cdE|Woozy> Q-FUNK, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/430694 ?
[17:32] <ubot3> Malone bug 430694 in linux "agpgart-intel not loaded before drm sometimes, causes KMS to fail" [Undecided,New] 
[17:34] <Q-FUNK> cdE|Woozy: could be it. any known cure?
[17:34] <cdE|Woozy> I "solved" it by rebooting until it loads in the correct order :)
[17:35] <cdE|Woozy> I don't know how the order in which those modules are loaded is determined
[17:39] <apw> normally load order is determined by udev
[17:39] <apw> the new parallel probe for pci in the kernel might trigger some instability in order
[17:46] <apw> rtg there seem to be 6 patches applied to jaunty that didn't get upstream or into karmic, since we forked off karmic.  do you want me to mail them to the list for review or you happy for me to apply them
[17:54] <rtg> apw, lets run 'em through the list first
[17:55] <apw> rtg ack
[18:36] <apw> rtg ok ... the analysis in all its gory details is up, as is a separate thread with the patches i want in
[18:37] <apw> smb, jaunty sru review is out on email
[18:37] <smb> apw, ok, I have a look
[18:37] <rtg> apw, reading...
[18:38] <devinheitmueller> Hello all.  I filed bug #403642 almost two months ago and it's supposedly milestoned for Karmic Alpha 6.  Is there any chance this is going to happen?  It's just a PULL request - no actual code changes required.
[18:38] <ubot3> Malone bug 403642 in linux-firmware "Include xc5000 firmware in Karmic (now properly licensed)" [Medium,In progress] https://launchpad.net/bugs/403642
[18:39] <rtg> devinheitmueller, its on my todo list, but its likely too late for A6
[18:39] <devinheitmueller> :-/
[18:42] <devinheitmueller> I'm obviously pretty disappointed to hear that, especially since the linux-firmware module got three updates since the ticket was filed, and it's just a pull request (it's not like I'm demanding that somebody investigate and fix a bug).
[18:44] <devinheitmueller> rtg: Is there anything I could have done differently that would have effected the outcome here?
[18:45] <rtg> devinheitmueller, actually, I din't even notice the bug until a couple of days ago when I was working on something else. You could always send a git pull request to the u-k-t list, which would have gotten my attention.
[18:46] <devinheitmueller> But weren't you were the one that set the milestone to A6?
[18:46] <rtg> devinheitmueller, uh, maybe. I can't remember.
[18:47] <devinheitmueller> (yes, you were)
[18:48] <devinheitmueller> If I had any reason to believe that sending pull requests to the ml would have helped, I would have been doing that weekly.  Instead I sat by and waited patiently after being told it was "in progress".  I guess lesson learned for next time.
[20:48] <devinheitmueller> rtg: Thank you very much!
[20:49] <rtg> np
[20:54] <Wicked> is there any legit reason why ipv6 was hard coded into the kernel...and not as a module....so the only way one can truely disable ipv6 is to compile there own kernel?
[20:55] <Wicked> it seems like a big mistake to me....and to think its such a small fix...that with all the kernel updates it has not been fixed...
[20:55] <Wicked> which makes me think there may be something else im not seeing.......as to make sense of why its not fixed.
=== cjwatson_ is now known as cjwatson
=== zul_ is now known as zul
=== bjf is now known as bjf-afk