[00:04] <Kano> Sarvatt: it is definitely a very bad idea...
[00:07] <bjf> Kano, we review *all* the flavours that we support at every UDS
[00:08] <Kano> well the server one was obsolete, i never used that
[00:08] <Kano> only generic + generic-pae
[08:41]  * smb considers just going back to bed
[09:34] <smb> gah
[09:53] <brendand> has anyone tried to build the kernel with gcov on recently?
[10:17] <apw> brendand, not recently no
[10:21] <brendand> apw - do you normally need anything extra to do it? 
[10:22] <apw> i don't think i have ever done it, though iirc it is an external patch set and lags the kernel mostly
[10:32] <apw> UBUNTU: SAUCE: rtl8192se: Force a build for a 2.6/3.0 kernel
[12:25] <Fudge> cjwatson  are you about cobber
[12:27]  * Fudge pokes apw 
[12:40] <cjwatson> Fudge: it helps to give a reason rather than just poking people.
[12:41] <Fudge> sry cjwatson , we spoke a few weeks ago about kernel sound, i wondered if i can show u a bug report Attila submitted, i tink i saw ur name on there
[12:42] <cjwatson> I know nothing about kernel sound
[12:42]  * cjwatson <- not a kernel hacker
[12:43] <Fudge> mm my mistake
[12:43] <Fudge> wonder who it was loL
[13:03]  * apw looks at Fudge
[13:08] <_jmp_> good $localtime
[13:47] <apw> _jmp_, hiya
[13:58]  * tgardner reviews 104 stable patches
[14:05] <smb> tgardner, Most of them just are as from upstream. I would say the ones that can use a bit more thought would be the two drm ones and the adaption I made as noted in the pull request
[15:00] <ogasawara> tgardner: I'm getting ready to push over the top of precise master-next.  just want to make sure you haven't got anything locally that you wanted to push.  am also going to push up sforshee's alps patches at the same time.
[15:01] <tgardner> ogasawara, whack away
[15:01] <tgardner> smb, just pushed lucid master-next with a small compile fix to 'NLM: Don't hang forever on NLM unlock requests'
[15:02] <smb> tgardner, Gosh I managed to break it with copy and paste. :(
[15:02] <tgardner> smb, your forgot a ','
[15:02] <tgardner> you*
[15:03] <smb> tgardner, Bah. Thanks for fixing it.
[15:03] <tgardner> smb, the DRM patches look fine. I'm gonna reboot with that kernel here shortly
[15:04] <smb> tgardner, ok, probably should do the same here. are you building on gomeisa or tangerine
[15:04] <tgardner> smb, I built locally
[15:05] <smb> Someone has too much powerful gear... On the other hand its noisy enough nobody else wants it...
[15:06] <tgardner> smb, indeed. its probably time to ship that one to 1SS
[15:09]  * ogasawara back in 20
[15:12] <smb> tgardner, guess I will hammer gomeisa a bit with that master-next plus that xen fixup. Then I can test that on various places
[15:21] <alexbligh> smb, we talked a week ago about the Ubuntu kernels not booting on Xen PV-on-HVM because xen-platform-pci is missing from  the udeb. I have Iain Watson sitting next to me who is happy to provide a patch. Would you rather it put it in the udeb as a module or built it in to the kernel (the latter definitely works, the former we haven't got working yet).
[15:21] <alexbligh> (i.e. we got it into d-i but have not yet discovered what filters the modules into what appears in the udeb and what doesn't).
[15:23] <smb> alexbligh, Well, from the mailing list I think that it will be built-in at least for newer kernels, so it feels like that approach would be simpler
[15:23] <alexbligh> OK, so if Iain provides a patch for that, and puts it against one of the LP bugs, you would apply it? (in principle)
[15:24] <smb> It sounds reasonable. Btw, are we talking about Oneiric or Peecise target
[15:25] <alexbligh> smb, both ideally, but mostly Oneiric, as we'd actually like a version of Oneiric we can run on Xen :-)
[15:26] <smb> alexbligh, It is not that you cannot *run* it on Xen. You want the paravirt disk for install
[15:26] <alexbligh> It won't run at all on Xen because it unplugs the non-PV disk.
[15:27] <alexbligh> And cloud customers don't have the option of disabling all PV emulation...
[15:27] <alexbligh> therefore it just 'doesn't run on Xen' :-)
[15:27] <alexbligh> (yes, I know they can do xen_emul_unplug=never)
[15:27] <alexbligh> s/never/unnecessary/
[15:28] <smb> alexbligh, or unnecessary, but yeah if you need HVM it gets a bit difficult of that option is not put into your pv-grub commandline
[15:28] <apw> alexbligh, so if he is supplying the patch get him to send it to kernel-team@ directly
[15:29] <alexbligh> apw, hi Andy, OK, I will get Iain to do that. Our problem is that we need one Xen config that works with everything as we don't know what is in the image that we will run
[15:29] <apw> an admirable goal if it can be done for sure,y
[15:29] <alexbligh> Iain is iwatson@flexiant.com, and is just looking over my shoulder, so I shall leave it to him.
[15:30] <apw> yeah as long as we have the bug reference in there we'll be good and get the right people looking at it quickest
[15:30] <apw> bugs dissappear in the quagmire
[15:45] <apw> tgardner, ogasawara, i have the armhf bits pending to push, is the tree stable enough for me to push them on the top... they have a config copy in them so i neeed to have a stable config when i push
[15:46] <ogasawara> apw: go for it, I pushed the bits I wanted already.
[15:51] <apw> ogasawara, tgardner, ok pushed
[15:52] <tgardner> apw, ack, will have a look when I get back in a couple of hours.
[15:52] <ogasawara> bjf: I'm looking at kteam-tools/ktl/ubuntu.py .  It notes db["12.04"]["supported"] = False.  Will that remain False for the remainder of the dev cycle and then flip to True once we release 12.04?
[15:52] <apw> tgardner, ogasawara, the config is identicle to armel at this point.  the config does maintain them separatly and this needs to be considered when doing config changes for arm
[15:52] <ogasawara> apw: ack
[15:53] <tgardner> apw, I assume we must have an armhf chroot ? or did you just use the armel chroot
[15:53] <apw> tgardner, we have no way to build it without the right cross compilers and the right chroot
[15:54] <tgardner> ah
[15:54] <apw> tgardner, and you can't make those without the libc from the kernel.  so its a test it as well as you can and pray job
[15:54] <bjf> ogasawara: i think so but i need to dbl check the meaning of "supported" in some of the tools, there was a specific reason for that at the time i did it
[15:54] <apw> bjf, yeah i think that means 'stable teams repsonsibility' in there effectivly
[15:56] <ogasawara> bjf: only reason I ask is because I've got a script using supported_series which I believe included the dev release (it at least oneiric when it was in development)
[15:56] <ogasawara> bjf: so I'm just curious if it's meaning of supported has indeed changed and i need to fix up my script
[15:56] <bjf> ogasawara, that's what i was going to check, then it probably needs to go to "True"
[15:57] <bjf> ogasawara, the Precise block was added before Oneiric was final so i probably made it False so scripts wouldn't use it
[15:57] <ogasawara> bjf: I'll make the change and push.  let me know if it buggers up any of your scripts.
[15:58] <bjf> ogasawara: thanks
[16:15] <smb> alexbligh, Btw, for precise XEN_PCI_PLATFORM does not exist anymore as configurable option
[16:38]  * apw has to pop to the store for a washer, else we won't be using the loo
[16:44]  * smb now probably has more info than he wanted to have...
[16:50] <brendand> Does anyone know why, if I have GCOV_KERNEL enabled I get:
[16:50] <brendand> II: Done
[16:50] <brendand> make: *** [abi-check-generic] Error 1
[16:51] <brendand> when I don't without it enabled?
[16:52] <smb> brendand, because enabling gcov changes some structures and thus the abi
[16:53] <brendand> smb - fair enough
[16:53] <brendand> smb - do i build just the headers with gcov to begin with then?
[16:53] <brendand> smb - i'm very green on kernel building
[16:55] <smb> That won't help you to get a gcov enabled kernel. Depending on whether you do local builds or on a ppa you can disble the abi check...
[16:55]  * smb tries to find that wiki page again
[16:57] <smb> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI
[17:19] <brendand> smb - thanks
[17:45] <komputes> Hi everyone, I was wondering if someone can explain to me how the Linux kernel decides to assign a specific driver when a particular device when detected. From what I understand each module has a table of IDs it supports. Can I view this table? Where in the source should I look for this information?
[17:58] <tgardner> komputes, in any particular driver you can look for the usb_device_id or pci_device_id table.
[18:04] <komputes> tgardner: How would I go about looking for the USB ID in /lib/modules/2.6.32-34-generic/kernel/drivers/media/video/usbvideo/usbvideo.ko
[18:05] <komputes> it is not ASCII text but ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
[18:06] <apw> komputes, also that information is extracted and forms the module.dep stuff that modprobe uses; thats all in ascii
[18:06] <tgardner> komputes, get the source code?
[18:07] <tgardner> apw, thats kind of the hard way isn't it?
[18:08] <apw> tgardner, i'd say it was the easy way if you only have the binary
[18:08] <tgardner> I guess if you already know the ID and able to format your search correctly
[18:08] <apw> komputes, so you can see the matches which will map to a specific driver like this: grep i915 /lib/modules/`uname -r`/modules.alias
[18:08] <tgardner> komputes, look in /lib/modules/`uname -r`/modules.alias
[18:14] <komputes> That works.
[18:26]  * jsalisbury has recovered from changing Unity settings 8-O
[18:35] <tgardner> ogasawara, I'm test building the rebased seccomp_filter patches from kees
[18:36] <ogasawara> tgardner: ack
[19:14]  * tgardner -> lunch
[19:33] <kees> tgardner: oh excellent, thanks!
[19:34] <kees> tgardner: please double-check it on ARM. I *think* will fixed it for ARM, but that was the main thing I wanted to double-check when I was going to do the rebase.
[19:35] <kees> tgardner: and, if you want, qrt has seccomp_filter tests in it, but, again, I haven't tested them against the newer patch set. it _should_ pass, but it's possible something subtle changed that I was accidentally depending on in the test.
[19:48] <tgardner> kees, were you going to consider any of Tetsuo's suggestions ?
[19:55] <kees> tgardner: I replied to his email, I'm happy to switch from #if to #ifdef. the code changes I disagree with, but am curious if he sees something I don't.
[19:55] <tgardner> kees, ok, I just hadn't seen anything on the kteam list
[19:56] <tgardner> kees, I'll pull 'em into Precise for now. We've got plenty of time to fix any issues.
[19:56] <jjohansen> kees: often not, he likes to pick on style
[19:57] <kees> jjohansen: I think he wanted to just minimize the patch, but I like having it be as functional as it is.
[19:57] <kees> tgardner: hrm, is that a subscriber-only posting list? maybe it got moderated.
[19:57] <jjohansen> kees: ah could be
[19:57] <tgardner> kees, um, likely
[19:58] <tgardner> kees, ok, moderated
[19:58] <kees> hm, weird. https://lists.ubuntu.com/archives/kernel-team/2011-November/017663.html went through
[19:58] <tgardner> kees, 'cause I'm the moderator
[19:58] <kees> hah, okay :)
[19:58] <kees> I'll get my @chromium subscribed...
[19:58] <tgardner> kees, thanks
[19:59] <kees> though frankly, I'm already in there as @ubuntu and read it that way. I just did stuff from @chromium because of the @google in the original email. :P
[19:59] <kees> wheee
[19:59] <kees> too many email addresses
[20:21] <hallyn> smb: bug 795717 is the one which needs a patch sent to -proposed
[20:21] <ubot2> Launchpad bug 795717 in linux "32bit rhel and centos 5.(5|6) hangs on boot on natty" [Medium,Confirmed] https://launchpad.net/bugs/795717
[20:38]  * ogasawara lunch
[21:33] <tgardner> ogasawara, what is the name of the kernel config spec ?
[21:33] <tgardner> blueprint, I mean
[21:33] <ogasawara> tgardner: https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-config-review
[21:33] <tgardner> ogasawara, thanks
[21:39] <ogasawara> pgraner: you want me to take over filling in the monthly report blurb each month for ya?
[21:44]  * tgardner is off to bike in the snow.
[22:09] <pgraner> ogasawara, sure
[22:45] <bjf> jsalisbury: did you look into whether bugs are being expired ?