[00:15] <bryce> sconklin, you around?
[00:16] <bryce> on this resolutions timing bug, we're trying to figure out where we get the edid from.  Is there some kernel code that handles this?
[00:17] <bryce> looking at the control file for read-edid, it says it uses real-mode x86 instructions on i386 and a a VESA VBE 2 interrupt service routine request
[00:17] <bryce> sconklin, if you are around, maybe pop in #ubuntu-x ?
[00:31] <jjohansen> bryce: sconklin is out until monday now
[00:32] <sconklin> jjohansen: no, they caught me 
[00:32] <jjohansen> sconklin: ah cool
[00:54] <dtchen> so, I have some good news and some bad news.
[00:55] <dtchen> the good news is that I've pinpointed the regression on HDA chipsets for ALSA apps routed through the pulse pcm plugin.
[00:55] <dtchen> the bad news is that it touches sound/pci/hda/hda*.c
[00:56] <dtchen> this is reproducible on 2.6.29+, so it hits just about all current desktop distros.
[00:56] <dtchen> so, out of the fire and back into the frying pan for me
[00:58] <rtg> dtchen, float the patch through the list. I'm sure it will garner some interest :)
[04:24] <MTecknology> What module do I need to load to have apparmor running on a system that I don't want to reboot?
[04:26] <MTecknology> ok - looks like it uses upstart..
[06:35] <cooloney> yzhao: hello, 
[08:24] <ghostcube> guys, IMHO karmic is the worsest release ever gone in the wild
[08:24] <ghostcube> :|
[08:24] <ghostcube> and this is hard for me to say i luv (k)ubuntu
[08:24] <ghostcube> i never needed to reinstall any pc after an upgrade 
[08:24] <ghostcube> now i have to do on 3 machines
[08:24] <ghostcube> -_-
[08:24] <ghostcube> i hope lucid will get better
[08:24] <ghostcube> this is topping the gutsy desaster
[08:24] <Appiah> :)
[10:44] <apw> ghostcube, what made you need to reinstall following upgrade
[10:44] <apw> most of us have upgraded without incident
[10:44] <Appiah> I was gonna wipe my install and install karmic from fresh
[10:45] <Appiah> but the kernel fix for wireless+ethernet was not fixed in the newest kernel release
[10:45] <Appiah> so I'm gonna wait
[10:45] <apw> Appiah, was that fixed in smb's pre-propposed kerenl?
[10:46] <Appiah> umm
[10:46] <Appiah> not quite sure?
[10:47]  * apw remembers working on your bug, but i can't recall the outcome
[10:47] <Appiah> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/407824
[10:47] <ubot3> Malone bug 407824 in linux "BOTH Network controller: Intel Corporation Wireless WiFi Link 5100 AND Ethernet controller: Marvell Technology Group Ltd. 88E8040T PCI-E Fast Ethernet Controller (rev 12) FAIL TO LOAD!" [Medium,Fix committed] 
[10:47] <smb> Appiah, If you don't know what apw is talking about, probably not :)
[10:47] <Appiah> several duplicates
[10:47] <Appiah> smb: :)
[10:48] <smb> Appiah, If you have not before, you might give this a try: https://launchpad.net/~stefan-bader-canonical/+archive/karmic
[10:48] <Appiah> I have a working kernel made by apw 
[10:49] <Appiah> the kernel that ships with karmic , and the update that came yesteday or 2 days ago , did not include this fix
[10:49] <smb> * pci: increase alignment to make more space for hidden code
[10:49] <smb>     - LP: #407824, #480144, #474577
[10:49] <smb> It might be this from upstream stable
[10:49] <apw> Appiah, yep, if its 'FIX COMMITTED" then its not yet released into updates
[10:50] <smb> The latest update, does not include it, yet
[10:50] <apw> smb, yes its that one ... just checked with my test kernel
[10:50] <Appiah> oh
[10:50] <apw> Fix Rleased means its hits -updates ...
[10:50] <Appiah> fix commited =! fix released
[10:50] <apw> correct
[10:50] <smb> Appiah, no, just in the repo, but not released
[10:50] <apw> fix committed == fix on its way
[10:50] <apw> fix released == fix in your hands
[10:50] <Appiah> but it says relased on ubuntu
[10:51] <Appiah> and karmic commited
[10:51] <apw> yes.  ubuntu == lucid
[10:51] <apw> are you running lucid?
[10:51] <smb> == next release
[10:51] <Appiah> ah ofcourse
[10:51] <Appiah> nope karmic
[10:51] <Appiah> so will this never ever come into karmic?
[10:51] <apw> you get fixes faster in the development release, and pain to go with it of course
[10:51] <smb> Appiah, It will
[10:51] <apw> Fix Commited == coming soon
[10:51] <smb> There are jsut sometimes deleays
[10:51] <Appiah> I see
[10:52] <apw> but it has to make it into -proposed, be tested in -proposed, then it gets released
[10:52] <smb> as apw says
[10:52] <apw> this blob of updates was waiting for the previous blob to move to -updates which you just saw occur
[10:52] <apw> now the process starts again ...
[10:52] <apw> apply any security fixes, release that, apply proposed fixes push to -propose, test, release to -updates
[10:53] <apw> i'd say it'll be in -proposed within the week ... but thats a guess
[10:53]  * smb shuts his ears and eyes
[10:53] <Appiah> One thing that I never bothered with was that bluetooth dont seam to work. Pressing the BT button on my laptop just tries to incresse brightness(?) . Been like this is in Jaunty too, what info should be included in a bug report?
[10:53] <Appiah> execpt lspci
[10:53] <apw> report it with ubuntu-bug and it'll add everything under the sun including the kitchen sink
[10:54] <smb> Appiah, You also might have a look at https://wiki.ubuntu.com/Hotkeys
[10:54] <Appiah> oki , even though it may include alot of crap you dont need? :)
[10:54] <Appiah> smb: its not a matter of keyboard mapping
[10:54] <Appiah> I made sure of that first :D
[10:55] <apw> smb, i wonder if the general flow there might be better documented ...
[10:55] <smb> apw, Maybe
[10:55] <apw> "Life Cycle of a Fix to a Stable Release"
[10:55] <apw> Appiah, do you have -proposed enabled ... ?
[10:55] <apw> for instance recommending -proposed to those waiting on a Fix Committed bug etc
[10:55] <Appiah> I have no idea on what that is apw 
[10:55] <smb> apw, Oh, you did not mean the hotkeys... Yeah, that too
[10:56] <Appiah> something on launchpad?
[10:56] <apw> -proposed is an extra source of packages which gets them before they are released to -updates
[10:56] <smb> No thats one bullet in your sources when you look at installation sources
[10:56] <apw> a preview of -updates to come as it were
[10:56] <Appiah> oh
[10:56] <Appiah> I do not have that repo
[10:56] <apw> it is where your fix will go first, and hopefully shortly.  you will be asked to test that, and confirm it fixes you
[10:57] <apw> as part of the acceptance criteria for the update to move to -updates
[10:57] <Appiah> I will enbable that then
[10:58] <smb> Appiah, As soon as the fix goes there, the bug report will get updated and people are generically asked to test and give feedback. If you can reply to that it helps to speed getting things into updates
[11:00]  * smb looks at his watch: "I'll be late, I'll be late…"
[11:24]  * apw is struggling to see smb as a fluffy white rabbit ...
[11:30] <akheron> smb & gnarl: the include/linux/version.h issue was apparently caused by bad version numbers in debian/changelog entries
[11:31] <akheron> hmm, gnarl isn't here :(
[11:31] <akheron> anyway, I have been able to build a few working images and I'm on my way bisecting this bug
[11:31] <apw> akheron, that happens yes, some characters in there break things
[11:31] <apw> -'s are bad i think
[11:34] <akheron> ok, i'll keep that in mind
[11:35] <akheron> I tried to include git describe output into the version number, but it didn't work
[11:35] <akheron> now I just have an increasing number to not overwrite old images and have the git describe output in the changelog message
[12:09] <ghostcube> apw: it just doesnt boot
[12:09] <ghostcube> all machines hanging on apparmor
[12:09] <ghostcube> the mac and the server installs
[12:09] <ghostcube> better the last i see is apparmor and then it starts blinking
[12:09] <ghostcube> karmic isnt the best release ever :D
[12:10] <apw> ghostcube, heh for you no it sounds not
[12:10] <apw> so you don't see a panic on the console if you boot without quiet and usplash
[12:10] <apw> as flashing sounds like a panic, i assume here you mean flashing capslock ?
[12:47] <ghostcube> apw: nah the screen keeps flashing on off
[12:47] <ghostcube> it says loading apparmor
[12:47] <ghostcube> and just the screen begins to blink
[12:47] <ghostcube> :|
[12:49] <apw> apparmor is the last thing we init i think before X starts
[12:49] <apw> perhaps X is restarting contantly
[12:49] <ghostcube> yeah seems so
[12:49] <apw> there was a bug in upstart doing that, a bug in gdm's config
[12:49] <ghostcube> i think an radeon problem
[12:49] <ghostcube> all 3 machines on ati cards
[12:49] <ghostcube> apw: yep this could be the prob
[12:50] <ghostcube> its an xubuntu install
[12:50] <apw> what graphics do you have
[12:51] <ghostcube> 2 times rage 128 pro and one time radeon 9200
[12:51] <apw> all in the failing machine?
[12:51] <ghostcube> nah 3 machines failing
[12:51] <ghostcube> 3 different ones
[12:51] <ghostcube> all with xubuntu
[12:51] <apw> all radeon ... hrm
[12:51] <ghostcube> yep
[12:52] <apw> i'd expect radon to work if anything, using binary drivers?
[12:52] <apw> ghostcube, from the symptoms i recon that one needs referring to #ubuntu-x
[12:52] <ghostcube> i cant do anything i need to load repair console tonight
[12:52] <ghostcube> i cant access any tty
[12:53] <ghostcube> :)
[12:53] <apw> ghostcube, indeed.  they may know how to stop it doing that
[12:53] <apw> perhaps booting 'single' and disabling the gdm upstart job
[12:53] <ghostcube> apw: ok thx will tell them if iam back at the machines
[12:53] <apw> sounds good, if there is a bug, get an xorg task on it
[12:53] <smb> Wasnt there something like saying "text" on the command line
[12:56] <smb> akheron, Thanks for the feedback. It really sounded strange why one build works and the next not. I'd probably just automatically avoid the bad chars there.
[12:57] <akheron> smb: as you probably already know, debian.master/rules.d/0-common-vars.mk expects quite a lot from versions in changelog :)
[12:57] <smb> ghostcube, Seems anything of "text|-s|s|S|single" should prevent gdm from starting on ubuntu. Might be worth trying...
[12:58] <ghostcube> ok but i first need to get into it with any console cause i cant access the machine
[12:58] <ghostcube> if so i had more infos thats the problem
[12:58] <ghostcube> :D
[12:58] <smb> akheron, There is a lot of magic in there for sure.
[12:59] <smb> ghostcube, Well, that was for using at the command line from grub. Or do you have no physical access to them?
[12:59] <ghostcube> smb: ah ok sorry misunderstood
[13:00] <ghostcube> sure i can get to the grub manager sorry
[13:00] <smb> ghostcube, No worries. :) I misunderstand a lot ;-)
[13:00] <ghostcube> heh
[15:43] <Keybuk> apw: why has usbfs turned itself back on in our kernels?
[15:43] <apw> Keybuk, which one
[15:44] <Keybuk> CONFIG_USB_DEVICEFS=y
[15:44] <Keybuk> the one I keep saying to set to =n just about every other week :p
[15:45] <soren> Keybuk: Google for "CONFIG_USB_DEVICEFS launchpad" and you'll see.
[15:45] <apw> Keybuk, well its on in every release back to intrepid
[15:47] <Keybuk> soren: yes, and the correct answer to any bug is Won't Fix
[15:47] <Keybuk> go fix your stupid broken software
[15:48] <Keybuk> enabling that option *breaks* correct behaviour of udev
[15:48] <Keybuk> it changes the usb uevents in wrong ways
[15:48] <Keybuk> and breaks things like firmware loading
[15:48] <soren> Keybuk: I'm not disagreeing.
[15:49] <BenC> IIRC, the only thing still using it was vmware
[15:49] <BenC> did they ever fix themselves?
[15:49] <Keybuk> yes, finally
[15:49] <Keybuk> only after we removed it ;)
[15:50] <Keybuk> apw: in fact, a quick grep through launchpad shows that we have a lot of usb firmware loading regressions again
[15:50] <BenC> I thought we always had it disabled, but udev had some compatibility layer for it
[15:50] <Keybuk> looks like amit enabled it again
[15:50] <soren> Yes. First hit on google for that search I mentioned.
[15:51] <soren> Bug #417748 
[15:51] <ubot3> Malone bug 417748 in linux "Please enable CONFIG_USB_DEVICEFS" [Medium,Fix released] https://launchpad.net/bugs/417748
[15:51] <Keybuk> *sigh*
[15:51] <soren> Sorry, should have just posted the bug number, I suppose.
[15:51] <apw> fun ... so Keybuk whats the story with it... why is it bad, why is it good, what does it do
[15:52] <Keybuk> apw: it's the config option for the old /proc/bus/usb virtual filesystem
[15:52] <Keybuk> which we don't use
[15:52] <Keybuk> enabling it changes the usb uevents to refer to that instead of being udev compatible
[15:52] <Keybuk> we use udev to populate /dev/bus/usb
[15:52] <Keybuk> so, enabling that option, *breaks* udev
[15:52] <Keybuk> and because it populates the uevent with /proc/bus/usb paths, it breaks anything else using them
[15:52] <Keybuk> like firmware loaders
[15:52] <apw> Keybuk, ok so i am happy to zap it for lucid if that is what we need
[15:53] <Keybuk> apw: I've asked for it to be zapped every single release since hardy
[15:53] <BenC> IMO, it's always been needed
[15:53] <apw> we will get people wanting it i am sure ... sigh
[15:53] <Keybuk> in fact, maybe even before
[15:53] <BenC> but random bug reports about ancient proprietary programs keep yanking it back
[15:53] <BenC> iirc, the only reason we kept it around was because of vmware
[15:54] <apw> so we can add it to the config checker with a comment on why you don't want to enable it
[15:54] <BenC> I don't think any other bit of software has enough user base to make that so any longer
[15:54] <apw> is there some way we can stop it changing udev even when enabled
[15:54] <Keybuk> no
[15:54] <Keybuk> not without basically removing all the code that supports it
[15:54] <apw> BenC, sounds positive at least
[15:54] <Keybuk> honestly, we don't want it
[15:54] <Keybuk> it's wrong, broken
[15:54] <Keybuk> we haven't enabled it since before hardy
[15:54] <Keybuk> stop turning the option back on!
[15:54] <apw> well except we have, its enabled in every release i've checked currenlty
[15:54] <apw> and they all work 
[15:55] <apw> even hardy has it enabled
[15:56] <Keybuk> no, I mean the userspace portion is disabled
[15:56] <apw> Keybuk, so ... the justification is it breaks firmware loading on usb devices in lucid ... right?
[15:56] <Keybuk> apw: right
[15:56] <Keybuk> in karmic actually
[15:56] <apw> ok ... thanks
[15:56] <apw> la la la :)
[15:56] <Keybuk> I background remember seeing a whole bunch of bugs near karmic beta and not caring
[15:57] <apw> so udev in karmic and lucid are affected here.
[15:57] <apw> sounds like we need a bug then as we'll need to consider sru
[15:57] <apw> BenC, thanks for the background
[15:58] <Keybuk> apw: I'd also point out http://markmail.org/message/3mw5yw465qmxgnwp
[15:58] <Keybuk> it'd be nice if you guys didn't keep turning back on options that I have patches to remove upstream ;)
[15:59] <apw> Keybuk, if your patches made it into upstream we'd not be able to turn them on !!
[15:59] <apw> :)
[15:59] <Keybuk> apw: it did, it's in the "sunset queue"
[15:59] <Keybuk> to give people enough notice
[16:00] <apw> what the heck is the sunset queue ...
[16:00] <apw> Keybuk, ok you filing a bug or am i
[16:00] <Keybuk> apw:  you do it
[16:00] <Keybuk> apw: you know, where greg queues things he's going to remove ;)
[16:00] <Keybuk> he actually did submit the patch for a while
[16:01] <Keybuk> but poor RH actually use /proc/bus/usb in their initrd :p
[16:01] <Keybuk> so he backed off to "this is going to be submitted soon, fix it QUICKLY"
[16:01] <Keybuk> it is marked DEPRECATED still ;)
[16:02] <Keybuk> with my config text
[16:05] <apw> Keybuk, the bug in karmic which mentioned it, claims it stops VirtualBox/VMWare from working
[16:05] <apw> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/417748
[16:05] <ubot3> Malone bug 417748 in linux "Please enable CONFIG_USB_DEVICEFS" [Medium,Fix released] 
[16:07] <Keybuk> apw: old versions only afaik
[16:08] <apw> Keybuk, thanks for that
[16:08] <Keybuk> we even made a new devices.txt file path for those that *really* wanted it
[16:08] <Keybuk> /sys/kernel/debug/usb/devices
[16:08] <Keybuk> (which is one of the reasons we always mount /sys/kernel/debug on boot now)
[16:42] <Keybuk> apw: hey
[16:42] <Keybuk> and another thing
[16:43] <Keybuk> is there a way to turn on/off kernel options like initcall_debug on the fly? :p
[16:43] <apw> initcall_debug is that not a command line option
[16:45] <Keybuk> it is
[16:46] <apw> so on the fly meaning ?
[16:47] <Keybuk> as in, toggle off again in sysfs
[16:47] <Keybuk> core_param(initcall_debug, initcall_debug, bool, 0644);
[16:47] <Keybuk> aha!
[16:48] <Keybuk> that means it should be in /sys/module/kernel/parameters ;)
[16:48] <Keybuk> (all those initcall debug messages were adding ~1.5s to the boot after kernel starts)
[16:48] <Keybuk> since you get them every time you load a module, etc.
[16:48] <apw> ahh so the thing to measure the kernel makes it slow?
[16:49] <Keybuk> it makes the boot slower
[16:49] <Keybuk> which is annoying
[16:49] <Keybuk> it doesn't add much to the kernel itself, since it's all ring buffer at that point
[16:49] <Keybuk> but it keeps on debugging after the kernel is init'd and all through user boot and stuff
[16:49] <Keybuk> those are backed by file, so that *does* slow things down
[16:50] <apw> ahh ... 
[16:50] <apw> so it sounds like yu have what you wanted
[16:51] <Keybuk> yup
[16:51] <Keybuk> thanks for being an excellent teddy bear
[16:51] <maco> teddy bears? where?
[16:52] <Keybuk> http://www.downloadsquad.com/2009/10/16/troubleshooting-with-your-teddy-bear/
[17:06] <Keybuk> apw: now to try and work out how to turn that off ;)
[17:08] <apw> Keybuk, heheh thanks
[17:09] <Keybuk> sed -e "/-t sysfs/a \
[17:09] <Keybuk> echo 0 > /sys/module/kernel/parameters/initcall_debug
[17:09] <Keybuk> " /usr/share/initramfs-tools/init
[17:09] <Keybuk> should do it <g>
[18:01] <Keybuk> apw: yay, that all worked
[18:01] <Keybuk> I have initcall debugging for the kernel, but it switches off once the real boot starts
[18:03] <apw> most excellent
[18:41] <Keybuk> according to my bug folder, floppy drives aren't working
[18:41] <Keybuk> there's a lot of mails about it ;)
[18:45] <Keybuk> DK issue apparently
[19:58] <bjaglin> hi! is there a reason why the staging drivers are not included in the 2.6.32 packages in the kernel ppa? I am missing rt2870sta in 2.6.32-rc8
[20:06] <apw> Keybuk, DK ?
[20:07] <apw> bjaglin, no obvious reason i can think of ... if you mention which thing is missing and email the kernel-team list we'll see what we can figure out
[20:24] <Keybuk> apw: DeviceKit-Disks
[20:25] <apw> Keybuk, phew :)  yeah the ones i've looked at seem to have udev and below in place
[20:26] <Keybuk> yeah
[20:27] <Keybuk> the problem smells like stuff at the top going "oh, but it doesn't have a filesystem on it" because stuff at the bottom didn't look BECAUSE IT'S A FLOPPY DISK!
[20:27] <Keybuk> we don't look at floppy disks
[20:27] <Keybuk> because the ker-chunk-thunk-thunk-cha-cha-cha-thunk during every single boot, and every random package upgrade that calls udevadm trigger, really pisses people off
[20:27] <Keybuk> (not to mention it's slow)
[20:46] <Kano> hi, did somebody disable NFS for 2.6.32
[20:47] <Kano>  * Not starting NFS kernel daemon: no support in current kernel.
[20:51] <ghostcube> oha
[23:01] <Kano> rt2860sta seems to have got problems too