=== gerald is now known as Guest65758
=== mwhudson is now known as zz_mwhudson
[06:49] <smb> morning
=== zz_mwhudson is now known as mwhudson
[07:38] <ppisati> moin
[07:50] <smb> ppisati, Hah! One time beat you to it. :)
[08:01] <ppisati> smb: my bad, these days i'm really slacking... :)
[08:02] <smb> ppisati, Meh, I really had to work hard to not do the same. :)
=== mwhudson is now known as zz_mwhudson
=== zz_mwhudson is now known as mwhudson
=== mwhudson is now known as zz_mwhudson
=== zz_mwhudson is now known as mwhudson
[09:12] <apw> xnox, most peoples don't ...
[09:12] <xnox> apw: hipsters =)
[09:13] <xnox> apw: in other news, why is my intel graphics / uefi boot is so flickerfull ?! also is the grub generating a "malevich black square" with "aubergine frame" for you?
[09:14] <apw> xnox, i don't think my efi boxes do that, though i can check after i have updated
[09:15] <xnox> apw: hm.... i'll do photographs then, or maybe video cause the boot is fast.
[09:16] <apw> it cirtainly isn't intentional
=== mwhudson is now known as zz_mwhudson
=== lool- is now known as lool
=== zz_mwhudson is now known as mwhudson
=== mwhudson is now known as zz_mwhudson
=== yofel_ is now known as yofel
[10:49] <xnox> argh! kernel patch spam! =)
[10:51] <henrix> heh
[10:52] <henrix> xnox: just use the 'X-Extended-Stable:' header to solve that spam prob :)
[10:54] <xnox> henrix: if only gmail had custom header support. and i seem to fail configuring imapfilter to filter stuff inside labels =(
[10:56] <henrix> xnox: i haven't been using imapfilter for a while, but i'm pretty sure it supported that.  regarding gmail... never used ;)
[11:20] <apw> xnox, i use imapfilter against gmail labels no problem
[11:26] <apw> xnox, and i think smb uses it exclusivly
[11:26] <smb> apw, huh?
[11:27]  * smb is not on gmail
[11:32] <apw> oh never mind then, my mixup
[12:08] <apw> smb, https://bugs.launchpad.net/ubuntu/+source/protobuf/+bug/1276531
[12:08] <ubot2`> Launchpad bug 1276531 in protobuf (Ubuntu) "ABI regression" [Critical,Fix committed]
[12:08] <smb> apw, Thanks
[12:19] <smb> apw, Ok, I also got a desktop back. Though I had to restart lightdm once to get a version which accepts keys... Might be random fluke though. 
[12:19]  * smb reboots that laptop again
[12:21] <smb> Hm, again
[12:22] <smb> Just this time something seems to have unwedged it without restarting
[12:24] <smb> apw, Do you get something liek that?
[12:25] <smb> Seems initially not accepting keystrokes in the pw dialog box.
[12:25] <smb> But when I open and close the reboot menu with the mouse, then the password box accepts keys suddenly (with a bit of an initial lag)
[12:39] <seb128> hey
[12:41] <seb128> is there a known issue with linux-image-3.13.0-7 i386 in trusty? my laptop wlan0 (dell laptop, i5) stop being listed after today's update 
[12:54] <smb> seb128, Did you manually upgrade libprotobuf8? 
[12:54] <seb128> smb, no, I stayed away from that abi change
[12:54] <seb128> it makes compiz not start
[12:54] <seb128> smb, booting kernel -6 makes my wifi work
[12:54] <smb> Yeah, we went through that
[12:55] <smb> Hm, not that I know of some wifi issue. What type of wifi hw?
[12:56] <seb128> it's a dell latitude e6410 with intel card, where can I see the exact model for it?
[12:56] <seb128> [    9.465536] iwlwifi 0000:02:00.0: Detected Intel(R) Centrino(R) Advanced-N 6200 AGN, REV=0x74
[12:56] <seb128> smb, ^?
[12:56] <smb> lspci
[12:57] <smb> But I think the numbers posted should be enough
[12:57] <seb128> 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6200 (rev 35)
[13:00] <smb> seb128, Is that from the -6 kernel? If so does it show up in dmesg with -7, too or not
[13:03] <seb128> smb, http://people.canonical.com/~seb128/kern.log
[13:04] <seb128> smb, the Feb  5 12:32 boot is with -7
[13:04] <seb128> the 12:35 one with -6
[13:05] <seb128> smb, I'm at a sprint but I can find an eth cable and reboot on -7 to debug more if needed
[13:06] <smb> seb128, Ok, let me read through this. 
[13:10] <seb128> smb, thanks
[13:12] <seb128> smb, seems like I'm missing linux-image-extra-3.13.0-7-generic if that makes a difference (did some partial upgrade to avoid the new libprotobuf)
[13:14] <smb> seb128, Ah, so you should really install that
[13:15] <seb128> smb, sorry for the noise, I'm going to upgrade after lunch (new protobuf should be in) and reboot and see how it goes
[13:15] <smb> seb128, ok
[14:14] <rtg> apw, do we have a bug for the CVE patch you applied ? 'x86, x32: Correct invalid use of user timespec in the kernel'
[14:15] <rtg> hmm, bug #1274754
[14:15] <ubot2`> Launchpad bug 1274349 in linux (Ubuntu Trusty) "duplicate for #1274754 Fix-compat_sys_recvmmsg-on-x32-archs" [Critical,Confirmed] https://launchpad.net/bugs/1274349
[14:16] <henrix> rtg: i believe what you're looking for is bug #1274349
[14:16] <ubot2`> henrix: Error: Could not gather data from Launchpad for bug #1274349 (https://launchpad.net/bugs/1274349). The error has been logged
[14:16] <rtg> henrix, ack
[14:16] <apw> bug #1274349    
[14:16] <rtg> apw, I'm fixing up the commit log for trusty
[14:16] <apw> a pox on you launchpad
[14:17] <apw> rtg, to get that one to close ?
[14:17] <rtg> yep
[14:18] <apw> not necessary, it is a CVE bug, the tracker will close it
[14:18] <rtg> apw, is it in the correct format ? it does not look like it to me
[14:18] <apw> if the cherrypicked from XXX is there it will be handled
[14:19] <rtg> ah, ok
[14:19] <apw> the cve-autotriager will see the commit sha1 and move the tracker to 'pending' and 'released <XXX>'
[14:19] <apw> and that is picked up by the kees scripting which jjohansen1 runs and that closes the bugs
[14:20] <apw> not that putting it in there as a BugLink: is an issue, it will work just fine
[14:20] <rtg> apw, I'll push it anyways so it is easier to find the bug from the commit log
[14:22] <rtg> sforshee, can you give https://bugs.launchpad.net/intel/+bug/1265436/comments/9 a quick test ?
[14:22] <ubot2`> Launchpad bug 1265436 in intel "Saucy SRU: update firmware for 7260 / 3160 devices (Wilkins Peak) " [Undecided,New]
[14:23] <sforshee> rtg: sure, let me wrap something up then I'll try it out
[14:23] <rtg> no rush
[14:24] <apw> rtg, 3.13.2 is looking like a monster
[14:24] <rtg> oh, I'm sure. 100+ ?
[14:24] <apw> 140 already
[14:26] <rtg> apw, thanks for fixing my upload FTBTS by the way. I just ran out of time to figure it out.
[14:27] <apw> rtg, np, typical orig tarball carnage
[14:28] <rtg> ah, that is why my test builds succeeded
[14:30] <henrix> apw: and it doesn't include all the stable patches from -rc1 ;)
[14:30] <apw> rtg, yeah, the empty kbuilds i made get lost, i've fixed it in a better way in the tip
[15:10] <sforshee> rtg: that linux-firmware update was essentially a noop. The 22.1.7.0 files were unchanged, and the new files aren't used by saucy's kernel.
[15:11] <rtg> sforshee, hmm, I thought it used the .8 API  - perhaps I misremembered
[15:12] <sforshee> rtg: .8 is only 3.13+
[15:12] <rtg> ok
[15:12] <rtg> sforshee, didn't a stable update enable the .8 API ?
[15:12] <sforshee> rtg: the verification-done tag was already on the bug though, so I'm not sure if I need to do anything so the sru team will know it's been verified
[16:32] <infinity> apw: Hrm.  Now that lowlatency is in master, would it be a reasonable thing to suggest that maybe we should produce a linux-signed-image-$(ABI)-lowlatency from linux-signed?
[16:33] <infinity> apw: (And obviously push the required bits to the EFI tarball to make that possible)
[17:21] <jsalisbury> henrix, Is there a script that builds the kernels at http://kernel.ubuntu.com/~kernel-ppa/mainline/linux-3.11.y.z-queue/ ?  Or do you do it manually?
[17:21] <henrix> jsalisbury: that's the same build scripts used to build mainline kernels
[17:21] <henrix> jsalisbury: they are built automagically
[17:22] <jsalisbury> henrix, Do you know the name of it off hand?  I'm wondering how it handles the case of a patch not applying?  Does it just skip it, and then you have to go back and backport or skip it manually?
[17:23] <henrix> jsalisbury: i believe they are in kteam-tools, in mainline-build
[17:23] <henrix> jsalisbury: but they use the git tree directly, the scripts don't apply the patches 
[17:24] <henrix> jsalisbury: they use git://kernel.ubuntu.com/ubuntu/linux.git
[17:24] <henrix> jsalisbury: (and the corresponding -queue and -review branches)
[17:25] <jsalisbury> henrix, ack.
[17:26] <jsalisbury> henrix, Is there a script that updates the linux-3.11.y.z-queue branch?
[17:27] <henrix> jsalisbury: that branch is updated manually, i.e., that's where i push the patches for the next stable release
[17:27] <henrix> jsalisbury: this means that the 3.11.10.4 will be what's in that branch ;)
[17:28] <henrix> jsalisbury: everything from v3.11.10.3 the HEAD in that branch will be included in the next release
[17:28] <jsalisbury> henrix, Ahh, ok.  So that's where the heavy lifting is done ;-)  So you follow the stable mailing list and apply anything that comes in with the stable cc.
[17:28] <henrix> yep, correct :)
[17:29] <henrix> that branch already contains everything you're looking for
[17:29] <jsalisbury> henrix, cool, now I understand.  Thanks.
[17:29] <henrix> no prob
[17:31] <jsalisbury> henrix, so do you actually compile a list of the patches from the stable mailing list, or do you pull in what lands in the stable-queue repo?
[17:32] <henrix> jsalisbury: i pick patches from linus tree that are tagged for stable (i.e., that contain the 'Cc: stable' on the SOB section)
[17:32] <henrix> jsalisbury: and additionally, i pick patches from the stable mailing list
[17:32] <henrix> jsalisbury: let me get you an url...
[17:33] <jsalisbury> henrix, Ok, so the stable-queue repo(git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git) is just GKH's repo for his kernels?
[17:33] <henrix> jsalisbury: yep, those the the official stable kernels
[17:34] <jsalisbury> henrix, ok, got it.
[17:34] <henrix> jsalisbury: here's a detailed description of the process we follow for stable maintenance (in case you're bored and want to find out more :) )
[17:34] <henrix> jsalisbury: https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable/Maintenance
[17:34] <jsalisbury> henrix, awesome, thanks again!
[17:35] <henrix> jsalisbury: no prob
[17:36] <henrix> jsalisbury: anyway, if you want to create saucy kernel with the 3.11.10.4 patches, you just need to get them from our stable git tree (with e.g. git format-patch), and apply them on top of the latest ubuntu saucy tree
[17:36] <henrix> jsalisbury: and this is where some of them may fail to apply (e.g., they have already been included)
[17:38] <jsalisbury> henrix, Ok, thanks for the info.  Just wanted to understand the way we do upstream stable maintenance.  The wiki you pointed to has all the details :-)
[17:38] <henrix> jsalisbury: yeah, i guess its all in there
[17:43] <apw> bjf, how would i figure our which kernel the current 2.6.32 kernel when 12.04.3 was released 
[17:44] <bjf> apw, mainifest file? don't know if that has the version #
[17:44] <apw> bjf, it seems that edubuntu doesn't use the hwe kernel
[17:44] <bjf> huh
[17:45] <rtg> apw, was that a mistake or a conscious decision ?
[17:45] <apw> they chose it deliberatly as they have a lot of h/w which is non-pae
[17:46] <bjf> apw, i'll see if i can tell
[17:47] <apw> the manifest has 3.8 (raring lts) cause it is the master not the slave arrrgle
[17:48] <bjf> apw, so you'd have to install the .3 release of edubuntu to know what they used?
[17:48] <apw> maybe, or someone is confused what it contains
[17:49] <bjf> i'd think stgraber would be able to tell us
[17:50] <apw> bjf, sorry yes, and he is over on #ubuntu-release 
[17:50] <bjf> apw, http://cdimage.ubuntu.com/edubuntu/releases/12.04.3/release/edubuntu-12.04.3-dvd-amd64.manifest says it was raring
[17:53] <apw> yeah seems the ltps bit is shipped as a damn squashfs so you cannot tell without extracting it, win
[17:58] <ogasawara> apw: how much to you know about apt?
[17:59] <apw> some, whatsup
[17:59] <ogasawara> apw: I've got a question coming from one of our support dudes, which I'm not sure I know the answer
[17:59] <ogasawara> so....
[17:59] <apw> forward it over
[17:59] <ogasawara> apw: ack, thanks
[18:02] <ogasawara> apw: sent
[18:10] <apw> ogasawara, got it, thanks
[18:43] <seb128> smb, I just rebooted, wifi works, so it was my fault for partial upgrading, thanks!
[18:45] <jsalisbury> apw, I see there is a linux-image-extra package for 3.13.0-6, but I don't see one with "lowlatency" in the name.  Does the lowlatency kernel not need the linux-image-extra package, or does it just use the same one as the -generic kernel?
[18:47] <rtg> jsalisbury, there is no extras package for lowlatency. 
[18:47] <jsalisbury> rtg, ok, thanks
[18:48] <rtg> jsalisbury, the extras package is for the virt server. 
[18:48] <jsalisbury> rtg, cool. 
[18:54] <Prf_Jakob> Hey
[18:54] <Prf_Jakob> We (VMware) would like to backport some hw enablement code to the 14.04 kernel.
[18:56] <rtg> Prf_Jakob, is this code already in Linus' upstream kernel ?
[18:56] <Prf_Jakob> rtg: yeah
[18:56] <Prf_Jakob> I think the wrong version tho
[18:56] <bjf> Prf_Jakob, are you looking to get it in before the 14.04 release?
[18:57] <Prf_Jakob> you are going to use 3.13 right?
[18:57] <rtg> how about sending the list of commits to the kernel team mailing list ?
[18:57] <Prf_Jakob> That would be nice
[18:57] <rtg> yep, 3.12
[18:57] <rtg> 3.13*
[18:57] <Prf_Jakob> Kay
[18:57] <Prf_Jakob> Good to know
[18:57] <Prf_Jakob> I'll let Thomas know
[18:58] <Prf_Jakob> Where is that list btw?
[18:59] <rtg> kernel-team@lists.ubuntu.com
[18:59] <Prf_Jakob> thanks
=== lag` is now known as lag
[19:38] <bjf> rtg, http://pastebin.ubuntu.com/6880938/ is a kern.log from a CI system that is running apparmor tests on a Trusty kernel
[19:39] <jjohansen> bjf: which kernel?
[19:40] <bjf> jjohansen, 3.13.0-7.25
[19:40] <bjf> jjohansen, the latest
[19:41] <jjohansen> bjf: okay, I believe I might have the patch for that one
[19:42] <rtg> jjohansen, 2 occurrences of apparmor="KILLED" have a stack dump right afterwards
[19:42] <bjf> jjohansen, i'm seeing errors when i run the test but not the same panic that CI is seeing   http://kernel.ubuntu.com/testing/test-results/rizzo__3.13.0-7.25__2014-02-04_22-48-00/ubuntu_qrt_apparmor/results/ubuntu_qrt_apparmor.test-apparmor.py/debug/ubuntu_qrt_apparmor.test-apparmor.py.DEBUG.html
[19:43] <bjf> psivaa, ^
[19:43] <jjohansen> bjf: yep, this looks like bug 1268727
[19:43] <ubot2`> Launchpad bug 1268727 in linux (Ubuntu Trusty) "AppArmor changehat regression in 3.13.0-2.17-generic" [High,Confirmed] https://launchpad.net/bugs/1268727
[19:43] <psivaa> bjf: thanks
[19:44] <jjohansen> bjf: patch incoming, its only had light testing
[19:45] <bjf> jjohansen, it's not my kernel yet :-)
[19:46] <jjohansen> hehe
[19:48] <apw> smb, just a heads up stgraber has identified his issue as being 'test bed' related, which kinda hints at a KVM networking issue ... which sounds ominious
[19:57] <apw> rtg, if you are gonna flip that config over for the lts-backport-raring, there is some machinary we use in lowlatency for that
[19:58] <apw> smb, heads down, stgraber has found his issue a local MTU issue on his kvm host
[20:00] <rtg> apw, what are you talking about ? that config option was for trusty
[20:00] <rtg> the AA config option, I assume
[20:01] <apw> rtg, i assume it becoming an option so you can turn it on on trusty and off on lts-trusty
[20:01] <rtg> apw, yep, already done
[20:27] <rtg> apw, I am gonna upload trusty to fix an AA oops in CI testing. no ABI bump this time.
[20:29] <apw> rtg, ack
[20:29] <apw> rtg, these config updates you are doing CONFIG_FOO=n ought to not work, it ought to be putting in # CONFIG_FOO is not set
[20:30] <rtg> apw, which one in particular ?
[20:30] <apw> rtg, all of the ones in the rebase script for lts-raring
[20:30] <apw> lts-TRUSTY
[20:30] <rtg> apw, no, which config ?
[20:31] <apw> in the scripty bit where you switch them from y to n, you just make =y into =n, but the format is # XXX is not set for =n
[20:31] <apw> sed -i 's/CONFIG_SECURITY_APPARMOR_AA3_SEMANTICS=y/CONFIG_SECURITY_APPARMOR_AA3_SEMANTICS=n/' ${DEBIAN_TARGET}/config/config.* ${DEBIAN_TARGET}/config/*/config.*
[20:31] <apw> and the similar ones above
[20:32] <rtg> apw, doh! - you're right. I wouldn't have noticed that until this next rebase.
[20:32] <rtg> apw, actually, that will work when going from =y to =n 'cause updateconfigs is run right after that
[20:33] <apw> well only if there is a default and it don't then ask, as your =n ought to do nothing, ie be invisible
[20:33] <apw> i wish =n did work, it would make most of my scripting simpler
[20:33] <rtg> updateconfigs always rewrites it as '# CONFIG_FOO is not set'
[20:39] <apw> rtg, i am not sure it does make =n -> not set, i believe it makes as if you have no setting at all
[20:39] <apw> rtg, which may mean it defaults to n or not
[20:40] <rtg> apw, I'll check for sure
[21:23] <infinity> zequence: Will you have a chance to do a quick lowlatency/saucy rebase to pick up the latest changes there?
[21:35] <zequence> infinity: Sure. I'll look at it first thing tomorrow
[21:36] <infinity> zequence: Cool, thanks.
=== DarkPlayer_ is now known as DarkPlayer
=== FreezingAlt is now known as FreezingCold