[08:21] <smb> infinity, Argh, I should add those at the same time as I add the index number. I do not seem to be able to remember long enough to finish a paragraph in between.
[08:21] <smb> ... and morning, btw
[08:23] <smb> https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1064475
[08:23] <ubot2> Launchpad bug 1064475 in crash (Ubuntu) "crash version is outdated. Needs to import Debian version of the package" [Medium,In progress]
[09:09] <dupondje> disabling my VGA card with switcheroo, and then unloading the module causes a cpu hang :s
[09:09] <dupondje> bleh :)
[09:49] <apw> (flavour powerpc-smp &/ value CONFIG_NVRAM y) | \
[09:49] <apw>  value CONFIG_NVRAM m | \
[09:49] <apw>  !exists CONFIG_NVRAM | \
[09:49] <ubot2> apw: I am only a bot, please don't think I'm intelligent :)
[09:49] <apw>  value CONFIG_NVRAM y
[09:50] <apw> ubot2, given the the dumb things you say and do, trust me i don't
[09:50] <ubot2> apw: I am only a bot, please don't think I'm intelligent :)
[09:50]  * apw sighs
[09:54] <cking> perhaps we need a predicate to english translator :-)
[09:55] <apw> <-- predicate to UK engish translator
[09:55]  * cking sees a job for life
[10:01] <cking> http://en.wikipedia.org/wiki/Ternary_logic
[10:02] <cking> http://en.wikipedia.org/wiki/Balanced_ternary
[10:03] <smb> http://en.wikipedia.org/wiki/Fuzzy_logic
[10:57] <cking> apw, what about this https://bugzilla.redhat.com/show_bug.cgi?id=811227
[10:58] <ubot2> bugzilla.redhat.com bug 811227 in libvirt "RFE: Ability to specify custom BIOS for QEMU/KVM using <loader> XML (for WHQL testing)" [Unspecified,Closed: errata]
[11:09] <smb> http://libvirt.org/formatdomain.html
[11:12] <smb> http://www.redhat.com/archives/libvir-list/2009-September/msg00001.html
[12:52]  * henrix -> lunch
[14:23] <xnox> Do we ship ndiswrapper in generic ubuntu kernels?
[14:24] <xnox> the package says that it is provided, yet lsmod does not show ndiswrapper, nor modprobe -r ndiswrapper work on the LiveCD without network access.
[14:26] <rtg> xnox, indeed we do not provide ndiswrapper
[14:27] <xnox> rtg: can you figure out _when_ you stopped doing this?
[14:27] <rtg> xnox, its been awhile. lemme check
[14:27] <xnox> rtg: cause it means I have an argument on ubuntu-devel to drop ndiswrapper tools from the CD \0/
[14:28] <rtg> xnox, we disabled ndiswrapper in Precise (3.2.0-1.1)
[14:30] <xnox> rtg: interesting. And why / how come?
[14:31] <rtg> xnox, ogasawara dropped it completely as of 3.2.0-17.26, but there are no notes in the changelog as to why.
[14:31] <rtg> likely because its now a DKMS package ?
[14:31] <ogasawara> rtg: yep, dkms if I recall correctly
[14:32] <ogasawara> rtg: and I thought we'd dropped it a few releases ago actually
[14:32] <xnox> ogasawara: rtg: ok. since it's dropped, can you drop the provides from the linux-image package?
[14:32] <xnox> do you need a bug for that?
[14:32] <rtg> xnox, that would be good for an SRU
[14:32] <xnox> ack.
[14:32] <ogasawara> xnox: yes please.  it'll make sure it stays on our radar and is useful for SRU paperwork
[14:35] <xnox> ogasawara: rtg: bug 1076395
[14:35] <ubot2> Launchpad bug 1076395 in linux (Ubuntu Raring) "ndiswrapper module is not provided any more" [Low,Confirmed] https://launchpad.net/bugs/1076395
[14:35] <ogasawara> xnox: thanks
[14:36] <xnox> after checking ndiswrapper there is dogpile of bugs along the lines "ndiswrapper module is missing"
[14:37] <xnox> *sigh*
[14:37] <rtg> ogasawara, I can crank those out if you wish. I'm kind of idle  waiting on arm test builds.
[14:37] <ogasawara> rtg: sweet, its all yours then
[14:38] <ogasawara> rtg: I've been hammering on these haswell patches.  I've got the v3.6 and v3.7 ones applied, but of course the i915 driver is then oopsing on load.  so am digging further.
[14:39] <rtg> ogasawara, have fun with that :)
[14:46] <BenC> rtg: will the master package still build linux-libc-dev on powerpc? I ask because when I enable it on .ppc it errors out saying that it's not supposed to build outside of the master build
[14:46] <rtg> BenC, I would think it ought to be provided by your source package.
[14:46] <rtg> apw, whaddya think ? ^^
[14:50] <BenC> echo "non-master branch building linux-libc-dev, aborting"
[14:51] <BenC> What is going to happen on powerpc when it tries to build master? Maybe it will actually produce the package?
[14:52] <rtg> BenC, I don't think it will. I was just checking, but it looks like _all_ support for powerpc has been removed except for the config enforcer.
[14:52] <BenC> I'm going to checkout master-next and see what it does when I run binary-arch...
[14:53] <apw> yeah that is in there to stop derivatives producing them ... i note that we did used to produce them linux-libc-dev for arm
[14:53] <rtg> BenC, if there is no rules file in debian.master/rules.d/ for power, then it ain't gonna do nothing.
[14:53] <apw> even when we did not have arm in our package flavour wise.  perhaps it makes sense for us to do the same here
[14:53] <apw> as getting versioning wrong on that is fatal across the board
[14:54] <apw> rtg, so perhaps we should have a flavour free powerpc in ours to make that
[14:54] <BenC> I would suspect that is the ideal solution
[14:55] <BenC> I can create the commit for that and send a pull request when I can test that it works as expected
[14:55] <apw> something similar to what we have just done for aarm64 should be sufficient
[14:55] <apw> in theory at least
[14:56] <rtg> BenC, works for me
[14:56] <apw> BenC, thanks, did you see my update to your enforcer patch
[14:56] <BenC> What is the plan of action for ABI handling in this package? Should I just hold off anything I do that causes an ABI bump until one is incremented in master?
[14:56] <BenC> apw: I did, thanks
[14:57] <apw> i appologise in advance for the opacity of the syntax
[14:57] <apw> infinity, did i not see you dropping the dkms headers linkage during UDS ?
[14:58] <apw> ogasawara, rtg, i have spun through the main blueprints and kicked them into shape, copied out the work-items and moved them approved and the like
[14:58] <rtg> BenC, ABI handling for a separate source package should be independent of master, right ?
[14:58] <ogasawara> apw: thanks
[14:59] <apw> rtg, that reminds me, does ppc produce a common headers or share ours ?
[14:59] <BenC> So if I bump the ABI in powerpc, it won't cause any random conflicts with master, but how do I detect that master ABI bumped and then also ABI bump my side?
[14:59] <rtg> BenC, after you rebase and build ? if thereis an ABI change then the ABI checker should catch it.
[14:59] <apw> rtg, as if it shares ours it needs to be insync abi wise, if not, then the common headers needs to be renamed or have a different avi series
[14:59] <apw> abi
[15:00] <rtg> apw, maybe thats why ppc should produce its own header packages
[15:00] <apw> Package: linux-headers-3.7.0-0
[15:01] <apw> not linux-libc-dev, that should be ours, but the common headers
[15:01] <apw> that needs to be a differnt name
[15:01] <rtg> linux-headers-ppc ?
[15:02] <apw> rtg i think it should ve SRCPKG-headers
[15:02] <apw> or whatever the sub variable is
[15:02] <rtg> apw, what  are you doing for rt ?
[15:02] <rtg> or lowlatency rather
[15:02] <apw> rtg, right now they are sharing our headers, which we need to fix anyhow
[15:02] <apw> else they will prevent our kernel getting out of -proposed
[15:02] <apw> BenC_, hi
[15:02] <rtg> apw, ok, then the same for ppc
[15:03] <apw> BenC_, ok i think there is a bug here.  we need to change the link from linux-headers-PKGVER-ABINUM-FLAVOUR from Depends: linux-headers-PKGVER-ABINUM -> SRCPKGNAME-headers-PKGVER-ABINUM
[15:04] <apw> BenC_, and change the name of it in stub to the same
[15:04] <apw> so that it produces non-overlapping common headers naming
[15:04] <BenC_> Ok
[15:04] <BenC_> makes sense
[15:04] <rtg> and fix your meta accordingly
[15:04] <apw> else you and we will argue over common headers and bad poop will happen
[15:04] <BenC> right
[15:05] <apw> rtg, i don't think that file is mentioned in meta anywhere
[15:05] <BenC> bad poop is never good
[15:05] <apw> it is not the names of the per-flavour ones, just the shared common one
[15:05] <apw> rtg, you going to reneable the linux-libc-dev in our packaging yes ?
[15:05] <BenC> It is only mentioned in the linux-headers-*-FLAVOUR depends
[15:05] <apw> BenC, right, so i think that is the only one we can clash with
[15:06] <apw> as flavour names are necessarily unique otherwise the installer gets all miffed
[15:06] <apw> BenC, perhaps once you have done that you could build a set of packages and put them somewhere so we can review thats the only issues -- before we upload them and break the archive :)
[15:07] <apw> we made a bit of a pigs ear of lucid this way
[15:08] <BenC> No problem
[15:12] <BenC> apw, rtg: Same pull request as the last change will get the enablement of linux-libc-dev headers for master branch
[15:12] <BenC> That's all it builds
[15:12] <apw> BenC, thanks ... 
[15:13] <rtg> BenC, got it
[15:13]  * apw lets rtg handle it
[15:36] <rtg> apw, I'm gonna upload to the c-k-t de-virt PPA first to make sure we've got the powerpc bits correct.
[15:37] <rtg> I also put the whammy no +master-next to put Ubuntu-3.7.0-0.4 at HEAD
[15:37] <rtg> s/no/on/
[15:39] <StFS> does anybody know of a way to make apt prefer a locally installed package rather than a package with the same version number from the repository?
[15:40] <StFS> woops... probably the wrong channel... although in my defence the packages _are_ the kernel packages ;)
[15:45] <apw> StFS, heh you would likely get more help elsewhere indeed.  i think the term for that is 'apt pinning' though quite what incantion you would need is beyond my apt foo
[15:53] <StFS> ok, I'm sorry if this next question was already answered (I got logged out before I noticed one at least), but I submitted a patch to a bug a little while back which got applied and I was told it would show up in the Ubuntu kernel. However, the last kernel from the repo (3.5.0-18) does not seem to have this fix. Is there a way for me to see when my patch will end up in the official ubuntu kernel? The bug in question is this one: https://bugs.launchpad
[15:54]  * ogasawara back in 20
[15:54] <apw> StFS, seems the bug number got truncated here
[15:54] <apw> rtg makes sense
[15:54] <StFS> here it is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1060372
[15:54] <ubot2> Launchpad bug 1060372 in linux (Ubuntu) "No audio from headphone jack on Ultrabase Series 3 with ThinkPad T430" [Medium,In progress]
[15:57] <apw> StFS, it does seem to be applied to quantal's master-next
[15:57] <apw> StFS, so it will be in the next kernel which hits proposed, which would be wrapped up sometime next week in the normal flow of things
[15:59] <apw> StFS, and it is pending for the first upload to raring as well.  so nearly there
[16:02] <StFS> apw: awesome :-) thanks.
[16:03] <StFS> apw: just out of curiosity (mostly), can you tell me how to figure this out myself? you know, teach a man to fish and all that :-)
[16:03] <apw> i've updated the bug to indicate the same.  you should watch the bug for quantal as you will be asked to confirm the -proposed kernel as built works for you
[16:03] <apw> i am looking at the kernel git repositories and looking for the patch by bug number
[16:03] <apw> http://kernel.ubuntu.com/git under ubuntu/ubuntu-<series>
[16:04] <StFS> ok sorry, I'm an absolute n00b here.. watch the bug for quantal? so there's another one than the one on launchpad?
[16:10] <bjf> StFS, when the quantal kernel reaches -proposed, a comment will be added to the bug asking that you test that kernel to verify it fixes the issue
[16:10] <apw> StFS, heh, no that bug is the right one -- note it ha two tasks now, one for quantal and one for raring
[16:11] <apw> as bjf says there will be a request in your bug there
[16:11] <bjf> StFS, if we do not get a verification, we will revert the commit
[16:14] <apw> jsalisbury, hmmm when you did the patch for bug #1060372 you didn't use the BugLink: format, so it will not close the bugs out correctly ... you'll have to monitor and do that manually ...
[16:14] <ubot2> Launchpad bug 1060372 in linux (Ubuntu Quantal) "No audio from headphone jack on Ultrabase Series 3 with ThinkPad T430" [Medium,Fix committed] https://launchpad.net/bugs/1060372
[16:14] <apw> jsalisbury, for mainline, you can use it even there
[16:16] <jsalisbury> apw, so any patches send upstream should also contain the BugLink line?
[16:16] <rtg> jsalisbury, that is ideal
[16:16] <apw> jsalisbury, there is no harm indeed.  then when we get the fixed via mianline or stable we find out
[16:17] <StFS> bjf, apw: ok awesome... I'll wait for that comment and verify as soon as it appears
[16:17] <jsalisbury> rtg, apw, got it.  I'll be sure to include it from now on
[16:17] <apw> jsalisbury, for upstreaming i tend to include it in the s-o-b area so it tends to get left alone
[16:18] <jsalisbury> apw, ack. 
[16:23] <rtg> apw, https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/3967077
[16:33] <apw> looks good rtg 
[16:33] <rtg> apw, I'm about uploading BenC's branch as well.
[16:33] <rtg> to the PPA I mean
[16:33] <rtg> I'm thinking*
[16:33] <rtg> can't freaking type today
[16:34] <apw> rtg, as we might kill the PPA if its wrong, i'd wait till we see benc's builds
[16:34] <apw> i'd hate to have to respec that PPA
[16:34] <rtg> apw, can't we just delete the packages ?
[16:34] <apw> if the version are wrong and higher than we want, its just as irrevokable as the main archive, i am told
[16:35] <rtg> well, that doesn't provide much isolation
[16:36] <apw> now i can't say as to having tested that of course
[16:36] <apw> but that is what i am told.  that the version cannot be lower bit still exists
[16:36] <apw> you can zap a ppa and remake it, and for any other PPA that is easy, but that one, not so much
[16:37] <rtg> apw, if versioning carnage were possible then anyone could wreak havoc on the archive
[16:38] <apw> rtg, i am not saying it breaks the archive, i am saying you could break the PPA itself
[16:38] <rtg> apw, hmm
[16:50] <apw> rtg, they are very archive-esk in design
[16:51] <apw> if davis wasn't broken i'd suggest building there
[16:51] <apw> but with 4 flavours you are going to be in a world of pain either ways
[16:52] <rtg> apw, I thought infinity provisioned a new poerpc porter, or was that just a buildd ?
[16:52] <rtg> powerpc*
[16:52] <apw> rtg, hmmm, a good point indeed
[17:25] <infinity> rtg: No, davis is the only porter.  It's dead?
[17:25] <apw> infinity, it was yesterday indeed
[17:25] <apw> it looks to be back today
[17:25] <apw> infinity, is it still the same sluggard it has always been?
[17:26] <infinity> It's not magically turned into something better than an Xserve.
[17:26] <infinity> apw: Also, yes, I dropped the dkms->headers dep.  Is this having a sad somehow?
[17:26] <apw> infinity, no there is a work item in your name for it, i'll close it
[17:27] <apw> infinity, done
[17:28] <apw> infinity, i also added that Suggests: link for raring for our first upload
[17:29] <infinity> apw: image suggesting headers?  I was going to test that that actually does what I want it to do (keeps the headers installed on autoremove), but it certainly doesn't hurt, and feels like a sane suggests anyway.
[17:30] <apw> infinity, indeed, well it helps to have some old kernels with it, so i'll let it be
[17:33] <infinity> apw: I'd suggest that the suggests should be a recommends (which would definitely have the desired effect), but minimalist folks would probably scream about having to install kernels with --no-install-recommends then. :P
[17:34] <infinity> rtg, apw: Is someone on top of fixing the raring kernel on ARM?
[17:34] <apw> infinity, fixing ?
[17:34] <rtg> infinity, test building on non-virt PPA right now
[17:34] <infinity> rtg: Yay.
[17:35] <infinity> And if it weren't the for LP bug preventing me from seeing /builders, I'd know that.
[17:36] <rtg> infinity, its still grinding away in https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages
[17:36] <apw> ahh its in, woopeedoo
[17:38] <infinity> Does this upload include the discussed -generic image for ARM, or will that happen later?
[17:38] <rtg> infinity, somewhat later (if at all). amitk was not very optimistic.
[17:38] <infinity> (Granted, it would be a generic with one platform, since we dropped highbank, but whatever, I don't want to fight that political battle today, I just want the bits in place some time)
[17:39] <infinity> rtg: Alright, fair enough.  Just want to know what I need to mangle in d-i.  So, for now, I just need to drop highbank from d-i, and the rest is business as usual?
[17:39] <infinity> Oh, and I need to decouple powerpc from master.  Ugh.
[17:39] <rtg> infinity, thats sound about right
[17:39] <infinity> Yay for creating more work in the name of reducing workload. :P
[17:44] <apw> rtg, ignore -signed for raring for the moment, as although i think it is ready cjwatson wants to interlock before upload in case it breaks the images
[17:44] <rtg> apw, works for me. its pushed to the repo
[17:45] <apw> rtg, yep all pushed just not closed out once your bits are built and in -proposed then i'll upload it to the ppa for final testing
[18:03] <apw> rtg, if that build works in the PPA i assume you'll just copy it out into -proposed ?
[18:06] <janimo> pgraner, USB_SERIAL=y in current nexus kernel. Is that ok for your testing lab?
[18:07] <rtg> apw, works for me
[18:14] <pgraner> janimo, ack
[18:35]  * rtg -> lunch
[18:39]  * apw wanders off out for the evening ... shock horrot
[19:13]  * henrix -> EOD
[20:44]  * ogasawara lunch
[21:22]  * rtg -> EOD