[11:18] <dileks> hi
[11:18] <dileks> that wubi tarball of q-beta1
[11:19] <dileks> I can unpack in windows?
[11:19] <dileks> or in a hdd partition?
[11:20] <dileks> or is it the version shipping wubi?
[11:25]  * henrix -> lunch
[12:54] <Kano> hi rtg , what did you change in the r kernel? pure rc4 boots but your tree stops after clocksource?
[12:56] <rtg> Kano, git log --pretty=oneline v3.6-rc4..HEAD
[12:57] <Kano> well i just got the snapshot
[12:57] <Kano> does it boot for you on a pure snb box?
[12:57] <rtg> Kano, dunno, I haven't tried it in awhile. busy with Quantal 3.5
[13:46] <smb> henrix, bjf, rmadison on gomeisa and tangerine should be working again
[13:47] <rtg> smb, firewall fix ?
[13:47] <smb> rtg, Yep, rt just got updated
[13:48] <rtg> smb, thanks for going after that. I was too lazy and depressed to fix all of the DC move regressions
[13:48] <smb> rtg, No problem. Well yeah, this took ages to fix as well.
[13:51] <henrix> smb: ack, thanks
[13:56] <rtg> smb, when you have a moment could you build and run Lucid master-next to make sure the KVM CVE patches don't regress ?
[13:56] <rtg> I'm a bit nervous about the IRQ level backporting.
[13:57] <smb> rtg, ack, will do
[13:58] <smb> rtg, Yeah, I think its ok now but better be sure...
[13:58] <rtg> smb, thanks
[14:04] <caribou> quick question : according to the last comment in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1022561
[14:04] <ubot2> Launchpad bug 1022561 in linux "Quantal : kexec kernel not triggered when kernel panics" [Medium,Fix released]
[14:05] <caribou> the fix for this should be in 3.5.0-12.12
[14:05] <caribou> I've been looking in recent builds to try to test and I can't find any reference to this in the changelog
[14:06] <caribou> smb: it's the kexec/kdump fix btw
[14:08] <smb> caribou, UBUNTU: SAUCE: (no-up) x86/mm: Fix 64bit size of mapping tables
[14:08] <caribou> smb: yes, that's the one
[14:08] <rtg> caribou, its in Ubuntu-3.5.0-12.12
[14:09] <smb> rtg, Hm describe sais -13.13...
[14:10] <caribou> rtg: I saw that, but when I look in the latest build I don't find any ref to it
[14:10] <rtg> smb, the changelog says 12.12 - '  * SAUCE: (no-up) x86/mm: Fix 64bit size of mapping tables
[14:10] <rtg>     - LP: #1022561'
[14:10] <caribou> rtg: at least not in linux-image-3.6.0-999-generic
[14:10] <smb> caribou, that is a upstream build
[14:10] <smb> note the SAUCE no-up
[14:10] <caribou> the changelog on packages.ubuntu.com doesn't reference it either and it's 13-13
[14:10] <smb> I am still trying to upstream it
[14:11] <rtg> caribou, we prolly haven't forward ported all of the Quantal patches yet
[14:11] <caribou> smb: I thought I'd get caught by something silly like this
[14:11] <caribou> rtg: that's fine then, just wanted to be sure I was looking in the right direction
[14:11] <caribou> rtg: and smb just confirmed that I was not :)
[14:14] <caribou> rtg: smb: thanks for your time, I'll keep an eye open
[14:15] <smb> rtg, Bah and naturally git describe is not very trustworthy on a (still) rebase tree
[14:15] <rtg> smb, nope, which is why I generally look in the changelog
[14:17]  * smb is working to much in non-rebase trees ...
[14:17] <rtg> smb, rebasing is evil :)
[14:45] <hggdh> bjf, henrix: there were some issues with both the testcode and the testbase, but the LTS HWE are going. Natty is finishing, and Oneiric should follow
[14:45] <henrix> hggdh: great, thanks for the update
[14:47]  * ogasawara back in 20
[14:49] <bjf> hggdh: can you expand on "issues with both the testcode and the testbase" ?
[14:52] <bjf> hggdh: is this the bug that you found the other day and i fixed already?
[14:54] <hggdh> bjf: no, not related to the bug. That bug did not inhibit test progression.
[14:56] <hggdh> bjf: the issues were: (1) the Jenkins jobs had a wrong selection for the LTS HWE; I corrected them for LTS natty, and will correct for LTS Oneiric now; (2) somehow one of our servers decided to reboot into a new install, we stopped it before data oblivion, and recovered;
[14:57] <hggdh> (3) Jenkins failed (in an yet-to-be-found way), and some of the Jenkins kernel SRU jobs got stuck in limbo -- they do not really start, but still are not dead
[14:58] <hggdh> bjf: additionally, this is what I found since getting back from holiday on Tue
[14:58] <bjf> hggdh: thanks for the explaination. from your initial comment above i wasn't sure if there were issues (other than the one i knew of) with the kernel teams test code
[14:59] <hggdh> bjf: oh, no, sorry. Again, the kteam test code issue was not a show-stopper
[15:00] <hggdh> bjf: (3) is actually the worst issue, it holds completion of some of the LTS Natty (3 of them) jobs. I am going ahead without these 3 results
[15:37] <hggdh> bjf: do you consider ecryptfs and xfstests failures critical? see http://10.189.74.2:8080/view/sru-kernel/view/Natty-lts-hwe/job/sru_kernel-natty_lts_hwe-generic_amd64-amd_64-mga_g200ew/6/
[15:38] <bjf> hggdh: looking
[15:39] <bjf> hggdh: the xfstests, no
[15:39] <bjf> cking: can you take a quick glance at the ecryptfs test failures at: http://10.189.74.2:8080/view/sru-kernel/view/Natty-lts-hwe/job/sru_kernel-natty_lts_hwe-generic_amd64-amd_64-mga_g200ew/6/testReport/
[15:40]  * cking looks
[15:40] <bjf> cking: this is for natty-backport kernel
[15:41] <cking> bjf, that test will never pass for natty, so it's a known failure
[15:42] <bjf> hggdh: ^ 
[15:42] <bjf> hggdh: i'll work to get that not run on natty
[15:42] <henrix> bjf: is it worth the trouble? this is the last natty kernel, so...
[15:42] <hggdh> bjf: thank you
[15:42] <bjf> henrix: ack
[16:11] <vanhoof> God^Wsforshee ping?
[16:16] <rtg> vanhoof, I think he's out for an appt
[16:16] <vanhoof> rtg: ah cool
[16:17] <vanhoof> rtg: was told of his super powers and wanted to say thank you sforshee :)
[16:17] <rtg> vanhoof, what did he do this time ? :)
[16:17] <sforshee> vanhoof, I'm still here
[16:18] <sforshee> vanhoof, happy to help :)
[16:18] <vanhoof> rtg: solved the global economic crisis :)
[16:18] <vanhoof> rtg: fun with cypress/alps
[16:18] <vanhoof> sforshee: :)
[16:20] <cking> i'm surprised the world economy is based purely on the success of a ALP driver.. but there we go
[16:20]  * kamal seconds that!  mega-thanks sforshee for diagnosing bug 1041594
[16:20] <sforshee> when people's touchpads work they can get things done ;)
[16:21] <ubot2> Launchpad bug 1041594 in linux "Edge scrolling on ALPS touchpad broken since the upgrade to 3.5.0-11" [Medium,In progress] https://launchpad.net/bugs/1041594
[16:21] <sforshee> oh wait, apparently they can't
[16:21] <vanhoof> lulz
[16:22] <kamal> henrix: will 3.2.0-30.49 not actually land in -proposed then?   -31.50 instead?
[16:23] <henrix> kamal: correct
[16:23] <kamal> henrix: ok, thanks very much for letting us squeeze that Cypress/ALPS fix in :-)
[16:24] <henrix> kamal: since we had already uploaded -31.49 into ppa, we had to bump the version
[16:24] <kamal> henrix: ack
[16:33] <smb> rtg, So I booted a Lucid host with the master-next kernel and ran a Lucid guest in a KVM session, installed the master-next kernel there and brought the guest up again (all 64bit). Not very deep testing but at least something
[16:34] <rtg> smb, that was core stuff, so it ought to be sufficient
[16:34] <rtg> thanks for the testing
[16:35] <smb> rtg, Cool.
[16:35] <rtg> smb, aren't you about on vacation ?
[16:35] <smb> rtg, I am about to run away
[16:37]  * smb speaks and obeys his own words...
[17:12]  * rtg thinks hardy is a major PITA to build
[17:12] <kamal> rtg: well, it isn't called "easyy", now is it?
[17:13] <rtg> :)
[17:14] <rtg> kamal, I didn't do all of the parallel build work on hardy like I did for other releases. it takes a really long time...
[17:23] <jjohansen> rtg: you moved  natty CVE-2012-2384 to Invalid but it contains the bad commit, was this a mistake or am I missing something
[17:23] <ubot2> jjohansen: Integer overflow in the i915_gem_do_execbuffer function in drivers/gpu/drm/i915/i915_gem_execbuffer.c in the Direct Rendering Manager (DRM) subsystem in the Linux kernel before 3.3.5 on 32-bit platforms allows local users to cause a denial of service (out-of-bounds write) or possibly have unspecified other impact via a crafted ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2384)
[17:24] <rtg> jjohansen, we're done with natty so I decided to just not fix it since it looked like a real PITA
[17:25] <rtg> or almost done.... bjf says to quit patching natty
[17:25] <jjohansen> rtg: works for me, thanks
[17:26]  * rtg -> lunch
[18:14]  * henrix -> EO[D|W]
[18:37]  * cking -> EOD
[19:16]  * ogasawara lunch
[19:48] <TJ-> Is there a reason that the mainline 3.6rc4 builds have no V4L2 support built-in or modules, whatsoever?
[19:56] <sforshee> TJ-, you need to install the linux-image-extra package for most modules to be installed
[19:56] <TJ-> sforshee: I know. I did. It doesn't contain the V4L2 stuff, and the kernel config is missing them entirely (not even the commented out lines). The default-configs.patch removes them all
[19:57] <sforshee> TJ-, hmm, okay. I have no idea why they'd be disabled in the mainline builds since they're enabled in the normal builds.
[19:59] <TJ-> sforshee: me neither! The changelog isn't clear either. Looks like an oversight whilst adapting from the v3.5 to me
[19:59] <TJ-> sforshee: Only realised today when I attempted fire up a webcam for testing its drivers
[20:03] <sforshee> TJ-, I suspect some changes in the dependencies have broken it. V4L2 depends on VIDEO_DEV, which has grown some new dependencies
[20:04] <TJ-> sforshee: My thoughts too. Wish there was a changelog annotation though... I hate guessing :p
[20:04] <TJ-> I'll build it locally
[20:32]  * rtg -> EOW
[22:17] <infinity> henrix_: You around?
[22:22] <infinity> henrix_: Curious what you wanted to do about the fact that you have new lts-backports kernels lined up despite the old ones still not having passed QA.
[22:23] <infinity> henrix_: Better to wait and promote the old ones first, or just copy in the new ones to "catch up" with the SRU cadence?
[22:23] <infinity> bjf: ^-- Or if you have opinions on the matter.
[22:24] <bjf> infinity: our "plan" was to just not do the pocket copy until the ones being tested moved to -updates
[22:25] <infinity> bjf: Mmkay.  I was leaning more to the "catch up with the cadence" option, but if the testing's nearly complete or something, your plan makes sense.
[22:25] <bjf> infinity: i've been assured that testing will complete today
[22:25] <infinity> Shiny.
[22:26] <infinity> In that case, I'll be releasing them on Monday, and all will be well.
[22:26] <bjf> infinity: yup
[22:27] <infinity> (Just doing the accept-and-override dance for everything else right now, hence noticing the state of affairs)
[22:27] <bjf> infinity: understand. and you see that we did a respin of precise
[22:27] <infinity> Speaking of.  Someone should mention to Ike that copying -meta-flavour with -flavour is generally a good idea. :P
[22:28] <infinity> bjf: I can do the precise copy tonight when armhf catches up, if you're happy with its state in the PPA otherwise.
[22:28] <bjf> infinity: wfm
[23:18] <infinity> bjf: Alright, precise should be taken care of.
[23:19] <bjf> infinity: sweet!