=== smb` is now known as smb [08:21] 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] ... and morning, btw [08:23] https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1064475 [08:23] Launchpad bug 1064475 in crash (Ubuntu) "crash version is outdated. Needs to import Debian version of the package" [Medium,In progress] [09:09] disabling my VGA card with switcheroo, and then unloading the module causes a cpu hang :s [09:09] bleh :) === henrix_ is now known as henrix [09:49] (flavour powerpc-smp &/ value CONFIG_NVRAM y) | \ [09:49] value CONFIG_NVRAM m | \ [09:49] !exists CONFIG_NVRAM | \ [09:49] apw: I am only a bot, please don't think I'm intelligent :) [09:49] value CONFIG_NVRAM y [09:50] ubot2, given the the dumb things you say and do, trust me i don't [09:50] apw: I am only a bot, please don't think I'm intelligent :) [09:50] * apw sighs [09:54] perhaps we need a predicate to english translator :-) [09:55] <-- predicate to UK engish translator [09:55] * cking sees a job for life [10:01] http://en.wikipedia.org/wiki/Ternary_logic [10:02] http://en.wikipedia.org/wiki/Balanced_ternary [10:03] http://en.wikipedia.org/wiki/Fuzzy_logic === caribou_ is now known as caribou [10:57] apw, what about this https://bugzilla.redhat.com/show_bug.cgi?id=811227 [10:58] bugzilla.redhat.com bug 811227 in libvirt "RFE: Ability to specify custom BIOS for QEMU/KVM using XML (for WHQL testing)" [Unspecified,Closed: errata] [11:09] http://libvirt.org/formatdomain.html [11:12] http://www.redhat.com/archives/libvir-list/2009-September/msg00001.html [12:52] * henrix -> lunch [14:23] Do we ship ndiswrapper in generic ubuntu kernels? [14:24] the package says that it is provided, yet lsmod does not show ndiswrapper, nor modprobe -r ndiswrapper work on the LiveCD without network access. === edamato is now known as edamato-brb [14:26] xnox, indeed we do not provide ndiswrapper [14:27] rtg: can you figure out _when_ you stopped doing this? [14:27] xnox, its been awhile. lemme check [14:27] rtg: cause it means I have an argument on ubuntu-devel to drop ndiswrapper tools from the CD \0/ [14:28] xnox, we disabled ndiswrapper in Precise (3.2.0-1.1) [14:30] rtg: interesting. And why / how come? [14:31] 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] likely because its now a DKMS package ? [14:31] rtg: yep, dkms if I recall correctly [14:32] rtg: and I thought we'd dropped it a few releases ago actually [14:32] ogasawara: rtg: ok. since it's dropped, can you drop the provides from the linux-image package? [14:32] do you need a bug for that? [14:32] xnox, that would be good for an SRU [14:32] ack. [14:32] xnox: yes please. it'll make sure it stays on our radar and is useful for SRU paperwork [14:35] ogasawara: rtg: bug 1076395 [14:35] Launchpad bug 1076395 in linux (Ubuntu Raring) "ndiswrapper module is not provided any more" [Low,Confirmed] https://launchpad.net/bugs/1076395 [14:35] xnox: thanks [14:36] after checking ndiswrapper there is dogpile of bugs along the lines "ndiswrapper module is missing" [14:37] *sigh* [14:37] ogasawara, I can crank those out if you wish. I'm kind of idle waiting on arm test builds. [14:37] rtg: sweet, its all yours then [14:38] 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] ogasawara, have fun with that :) [14:46] 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] BenC, I would think it ought to be provided by your source package. [14:46] apw, whaddya think ? ^^ [14:50] echo "non-master branch building linux-libc-dev, aborting" === edamato-brb is now known as edamato [14:51] What is going to happen on powerpc when it tries to build master? Maybe it will actually produce the package? [14:52] 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] I'm going to checkout master-next and see what it does when I run binary-arch... [14:53] 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] BenC, if there is no rules file in debian.master/rules.d/ for power, then it ain't gonna do nothing. [14:53] 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] as getting versioning wrong on that is fatal across the board [14:54] rtg, so perhaps we should have a flavour free powerpc in ours to make that [14:54] I would suspect that is the ideal solution [14:55] I can create the commit for that and send a pull request when I can test that it works as expected [14:55] something similar to what we have just done for aarm64 should be sufficient [14:55] in theory at least [14:56] BenC, works for me [14:56] BenC, thanks, did you see my update to your enforcer patch [14:56] 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] apw: I did, thanks [14:57] i appologise in advance for the opacity of the syntax [14:57] infinity, did i not see you dropping the dkms headers linkage during UDS ? [14:58] 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] BenC, ABI handling for a separate source package should be independent of master, right ? [14:58] apw: thanks [14:59] rtg, that reminds me, does ppc produce a common headers or share ours ? [14:59] 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] BenC, after you rebase and build ? if thereis an ABI change then the ABI checker should catch it. [14:59] 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] abi [15:00] apw, maybe thats why ppc should produce its own header packages [15:00] Package: linux-headers-3.7.0-0 [15:01] not linux-libc-dev, that should be ours, but the common headers [15:01] that needs to be a differnt name [15:01] linux-headers-ppc ? [15:02] rtg i think it should ve SRCPKG-headers [15:02] or whatever the sub variable is [15:02] apw, what are you doing for rt ? [15:02] or lowlatency rather [15:02] rtg, right now they are sharing our headers, which we need to fix anyhow [15:02] else they will prevent our kernel getting out of -proposed [15:02] BenC_, hi [15:02] apw, ok, then the same for ppc [15:03] 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] BenC_, and change the name of it in stub to the same [15:04] so that it produces non-overlapping common headers naming [15:04] Ok [15:04] makes sense [15:04] and fix your meta accordingly === BenC_ is now known as BenC [15:04] else you and we will argue over common headers and bad poop will happen [15:04] right [15:05] rtg, i don't think that file is mentioned in meta anywhere [15:05] bad poop is never good [15:05] it is not the names of the per-flavour ones, just the shared common one [15:05] rtg, you going to reneable the linux-libc-dev in our packaging yes ? [15:05] It is only mentioned in the linux-headers-*-FLAVOUR depends [15:05] BenC, right, so i think that is the only one we can clash with [15:06] as flavour names are necessarily unique otherwise the installer gets all miffed [15:06] 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] we made a bit of a pigs ear of lucid this way [15:08] No problem [15:12] apw, rtg: Same pull request as the last change will get the enablement of linux-libc-dev headers for master branch [15:12] That's all it builds [15:12] BenC, thanks ... [15:13] BenC, got it [15:13] * apw lets rtg handle it [15:36] 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] I also put the whammy no +master-next to put Ubuntu-3.7.0-0.4 at HEAD [15:37] s/no/on/ [15:39] 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] woops... probably the wrong channel... although in my defence the packages _are_ the kernel packages ;) [15:45] 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] 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] StFS, seems the bug number got truncated here [15:54] rtg makes sense [15:54] here it is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1060372 [15:54] Launchpad bug 1060372 in linux (Ubuntu) "No audio from headphone jack on Ultrabase Series 3 with ThinkPad T430" [Medium,In progress] [15:57] StFS, it does seem to be applied to quantal's master-next [15:57] 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] StFS, and it is pending for the first upload to raring as well. so nearly there [16:02] apw: awesome :-) thanks. [16:03] 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] 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] i am looking at the kernel git repositories and looking for the patch by bug number [16:03] http://kernel.ubuntu.com/git under ubuntu/ubuntu- [16:04] 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] 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] StFS, heh, no that bug is the right one -- note it ha two tasks now, one for quantal and one for raring [16:11] as bjf says there will be a request in your bug there [16:11] StFS, if we do not get a verification, we will revert the commit [16:14] 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] 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] jsalisbury, for mainline, you can use it even there [16:16] apw, so any patches send upstream should also contain the BugLink line? [16:16] jsalisbury, that is ideal [16:16] jsalisbury, there is no harm indeed. then when we get the fixed via mianline or stable we find out [16:17] bjf, apw: ok awesome... I'll wait for that comment and verify as soon as it appears [16:17] rtg, apw, got it. I'll be sure to include it from now on [16:17] jsalisbury, for upstreaming i tend to include it in the s-o-b area so it tends to get left alone [16:18] apw, ack. [16:23] apw, https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/3967077 [16:33] looks good rtg [16:33] apw, I'm about uploading BenC's branch as well. [16:33] to the PPA I mean [16:33] I'm thinking* [16:33] can't freaking type today [16:34] rtg, as we might kill the PPA if its wrong, i'd wait till we see benc's builds [16:34] i'd hate to have to respec that PPA [16:34] apw, can't we just delete the packages ? [16:34] if the version are wrong and higher than we want, its just as irrevokable as the main archive, i am told [16:35] well, that doesn't provide much isolation [16:36] now i can't say as to having tested that of course [16:36] but that is what i am told. that the version cannot be lower bit still exists [16:36] you can zap a ppa and remake it, and for any other PPA that is easy, but that one, not so much [16:37] apw, if versioning carnage were possible then anyone could wreak havoc on the archive [16:38] rtg, i am not saying it breaks the archive, i am saying you could break the PPA itself [16:38] apw, hmm [16:50] rtg, they are very archive-esk in design [16:51] if davis wasn't broken i'd suggest building there [16:51] but with 4 flavours you are going to be in a world of pain either ways [16:52] apw, I thought infinity provisioned a new poerpc porter, or was that just a buildd ? [16:52] powerpc* [16:52] rtg, hmmm, a good point indeed [17:25] rtg: No, davis is the only porter. It's dead? [17:25] infinity, it was yesterday indeed [17:25] it looks to be back today [17:25] infinity, is it still the same sluggard it has always been? [17:26] It's not magically turned into something better than an Xserve. [17:26] apw: Also, yes, I dropped the dkms->headers dep. Is this having a sad somehow? [17:26] infinity, no there is a work item in your name for it, i'll close it [17:27] infinity, done [17:28] infinity, i also added that Suggests: link for raring for our first upload [17:29] 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] infinity, indeed, well it helps to have some old kernels with it, so i'll let it be [17:33] 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] rtg, apw: Is someone on top of fixing the raring kernel on ARM? [17:34] infinity, fixing ? [17:34] infinity, test building on non-virt PPA right now [17:34] rtg: Yay. [17:35] And if it weren't the for LP bug preventing me from seeing /builders, I'd know that. [17:36] infinity, its still grinding away in https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages [17:36] ahh its in, woopeedoo [17:38] Does this upload include the discussed -generic image for ARM, or will that happen later? [17:38] infinity, somewhat later (if at all). amitk was not very optimistic. [17:38] (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] 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] Oh, and I need to decouple powerpc from master. Ugh. [17:39] infinity, thats sound about right [17:39] Yay for creating more work in the name of reducing workload. :P [17:44] 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] apw, works for me. its pushed to the repo [17:45] 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] rtg, if that build works in the PPA i assume you'll just copy it out into -proposed ? [18:06] pgraner, USB_SERIAL=y in current nexus kernel. Is that ok for your testing lab? [18:07] apw, works for me [18:14] janimo, ack [18:35] * rtg -> lunch [18:39] * apw wanders off out for the evening ... shock horrot === edamato is now known as edu-afk [19:13] * henrix -> EOD === yofel_ is now known as yofel === henrix is now known as henrix_ [20:44] * ogasawara lunch [21:22] * rtg -> EOD === henrix_ is now known as henrix === henrix is now known as henrix_ === henrix_ is now known as henrix === henrix is now known as henrix_ === henrix_ is now known as henrix