=== Traxer548 is now known as Traxer|on === psino_ is now known as psino === Traxer|on is now known as Traxer === jussi01 is now known as jussi [07:58] hello [07:59] anyone ever seen these with ipv6 traffic over a gre tunnel? http://i.imgur.com/Tx5DFIH.jpg http://i.imgur.com/HXDJybV.jpg [08:27] Hi, I was wondering if anyone is planning on maintaining the LTT-ng userspace packages in Ubuntu? We're probably going to take a dependency on them for Mir, so will have to do a MIR. Want to check if someone else is planning on doing that [08:31] robert_ancell: (Note that rtg probably won't be around for a few hours, at least, and he was the one who was keen enough on lttng to include the kernel module in the saucy kernel) [08:31] infinity, ok, I'll resort to email :) [08:51] infinity: hello [08:53] psivaa: Hey, I've long since forgotten why I pinged you. Was probably about helping to test the emergency SRU kernels, but the security team ended up smoketesting the lot for me. [08:56] infinity: ok, i saw raring regression testing for -21.32 already done. thanking them :) [09:18] infinity: btw, you could also ping plars for any urgent regression testing, one of us will pick them up depending on the timing [09:20] psivaa: Sure. In this case, it was literally a 3-char patch and the effect of it was fairly obvious, so we just did some ghetto boot smoketesting of all the images, and verified the exploit no longer worked. [09:21] infinity: ack === ivoks_ is now known as ivoks [11:23] infinity, psivaa: I looked yesterday at all the ones that were marked ready for us yesterday afternoon, did a lucid sru one but that's the only one I saw at the time... was this something that came in since I guess? [11:29] plars: yea QA regression testing tasks were not marked confirmed for those raring and lts kernels but the kernels were in -proposed === soren_ is now known as soren [12:12] what a thoroughly misserable morning i am having [12:12] it has taken me about 3/4 of a hour to fix my network ... [12:13] as long as your coffee machine isnt network depending thats still ok i'd say [12:14] ogra_, thankfully not! [12:16] apw: i can hear you, can you hear me? [12:41] At what point will saucy switch from 3.9 to 3.10 ? [12:44] diwic, probably not for a couple of -rc releases. [12:44] rtg_, so around rc4 - rc6 somewhere? I don't have an immediate need, just curious. [12:45] who cares anyway ... the important 13.10 arches are stuck at 3.2 or 3.5 :P [12:45] diwic, whenever it seems stable enough that it doesn't kill any kittens [12:46] ogra_, heh, I have quite a few "fix committed" bugs I want to close as "fix released" which I can do when we go to 3.10, so that's the reason :-) [12:46] :) [12:47] rtg_, can't we sandbox the kittens? They like pooping there. [12:47] or in our garden, sigh [12:47] * diwic has no idea where this analogy will lead. [12:48] I've created an unstable branch in the saucy repo so you can see what I'm doing. [12:48] rtg_, ack [13:06] bjf: psivaa is working with the saucy jobs and getting a kernel mismatch between what's on the netboot iso and the kernel version, psivaa: can you give him the exact error? [13:06] he told cobbler to update right before, but maybe just bad timing? [13:08] plars: bjf: 'No kernel modules were found. This is probably due to a mismatch between the kernel version used by this version of the installer and the kernel version available in the archive' is the message [13:09] this i used to get in iso installation when a new kernel version being updated [13:10] Hi, is the kernel -22 arriving on proposed today? [13:16] psivaa, when i got that before i bugged retoaded to re-sync the cobbler isos [13:17] tyrog, that's the plan though they may not actually reach -proposed until tomorrow depending on how quickly everything builds [13:18] bjf: good, thanks [13:24] bjf: ok, I updated the cobbler iso's though. I'll ping retoaded about it, thanks [13:28] bjf: it comes with the fix for hdmi audio right? [13:28] tyrog, correct === timchen1` is now known as timchen119 === rbasak-test is now known as rbasak [14:08] New but reports out for the SRUs, ABI bumbs, but no new ones for lowlatency. Since lowlatency SRU bug reports aren't versioned, I'm thinking I can just use the ones that exist, even if they were based on the previous version [14:09] bjf, ^^ ? [14:11] apw: rtg_: so, tested the manta kernel and it didn't work =\ [14:12] 2 issues, one is that our config, even when used with the default android kernel as part of the android build system, breaks adb [14:12] rsalveti, do you know what config is breaking adb ? [14:12] and the second one is that building the exactly the same kernel without any extra patch, with the original config, is already enough to get a broken system, don't know why [14:12] rtg_: not yet, the diff is quite big [14:12] rtg_, is manta building with v4.8 ? [14:13] 4.7 I think [14:13] I was cross building with 4.7 here [14:13] not that then [14:14] but it seems we got a compiler or something related with that, because even when I build the original tree with the original config but with our gcc it's already enough to have a broken kernel [14:14] it keeps rebooting after loading the shell [14:14] rsalveti, what compiler does android use ? [14:14] the weird part is that there's no module at all [14:14] so not sure if there's a binary complaining about something [14:14] pre-built 4.6 [14:15] arm/arm-eabi-4.6/bin/arm-eabi- [14:16] zequence, we generated new bugs for the master kernels, the bot will generate new bugs for the derivitives as well at what it determines the appropriate time. you may choose to use the old bugs or the new ones, it's your call. [14:17] rsalveti, when you say original tree, are you referring to the stock cyanogenmod repo ? [14:18] bjf: ok, thanks [14:19] rtg_: yeah, the one we were using before available at phablet.u.c, which you guys used as base [14:20] rsalveti, and that clearly works with gcc-4.6, but not gcc-4.7 or higher ? [14:22] did you try with the 4.6-armhf cross compiler too ? [14:22] rtg_: just tested with 4.7, I'm now cross building it with our gcc-4.6 to see [14:22] ah [14:22] :) [14:22] right :-) [14:24] need to reboot first, going back to 3.8 as 3.9 is kind of broken regarding my iwlwifi driver [14:24] http://paste.ubuntu.com/5670944/ [14:24] not sure if it's the firmware though [14:24] brb [14:25] G+ seems to be full of poeple having issues with 3.9 and wlan [14:25] (on saucy) [14:25] ogra_, iwlwifi, or wlan in general ? [14:26] dunno, i just noticed several peole moaning about broken wifi [14:26] since a day or two [14:53] yeah, 3.8 is way more stable regarding wifi =\ [14:53] it was kind of locking my kernel at every firmware flush === chrisccoulson is now known as firefox-is-aweso === firefox-is-aweso is now known as chrisccoulson === danjared_ is now known as danjared [16:43] I'm running a set of Lucid boxes with the linux-lts-backport-oneiric kernels (linux-image-3.0.0-32-server) installed and running. The recent local root CVE seems like it should impact that kernel. I was wondering 1) If it's vulnerable (I think yes?) and if so, 2) Is a security updat scheduled for it. [16:44] bjf, ^^ [16:45] Thanks :) [16:45] jjohansen, ^ ? [16:47] JayF: Oneiric is end of life and no updates are coming [16:48] Then can you pull the vulnerable kernel from the Lucid repo to prevent people from getting compromised via it? [16:48] JayF: I don't believe oneiric is vulnerable, the git log shows us skipping b0a873ebb [16:48] jjohansen, should have caught that [16:48] jjohansen: I'm explicitly running https://launchpad.net/ubuntu/lucid/+package/linux-image-3.0.0-32-server -- the backported lucid version [16:48] so if it's not vulnerable, that's great! [16:49] JayF, as jjohansen pointed out, we are no longer supporting oneiric nor lts-backport-oneiric. you might consider upgrading. [16:49] JayF: hrmm, actually I am wrong it looks like it is vulnerable [16:49] I miss read the log [16:51] Thanks for the update. I'll either have to roll my own kernel now or package a couple of drivers for the standard lucid kernel. Shouldn't be too rough. Thanks for the info. [16:53] apw: who do i have to pay a beer in order to have the 3.8.y-queue/review branches being built daily, as we do for the 3.5 branches? [17:05] JayF: we don't generally pull eol packages from the archive, there are only a few exceptional cases where we do that [17:09] jjohansen: Just worrisome to know there's a vulnerable kernel image-type (i.e., the lts-backport-oneiric will be dead forever) in the main repos for a still-supported LTS :/. I worry about people getting locally rooted over it, but you guys do all the work and thereby get to make decisions about it ;) [17:09] ty for the help [17:11] jjohansen, is there a way to emit an motd in Lucid if you're running an obsolete kernel ? we should be messaging this kind of loudly. ogasawara has suggested that we're gonna do that for precise when 14.01.1 is released. [17:11] JayF: yes it is a problem, and we have it with several other desktop applications still in the lucid archive. The options where weighed and a choice made (not my choice) [17:12] 14.04.1 (doh!) [17:12] rtg_: it is possible, our current planning requires some changes [17:12] jjohansen, perhaps lucid would be good practice [17:13] I will discuss it with jdstrand [17:14] That sounds pretty awesome. #ubuntu-kernel++ [17:19] * rtg_ -> lunch === Edgan_ is now known as Edgan [17:27] henrix, heh ... i'll have a look, i always need more beer [17:27] apw: :) [17:27] apw: thanks. i'm not sure if you set it up for the 3.5 or herton did [17:28] henrix, i think i did some of it at least :) [17:35] henrix, ok, seems to be pretty easy ... initial review branch building now [17:35] apw: cool, thanks. [19:26] jjohansen: would you guys accept a patch to add the security fix to that backported kernel? I'm going to do it in my env anyway, and I'm more than willing to contribute it back if it would make it to the repo. [19:30] JayF: generally speaking once its eol we don't accept new patches for a package [19:31] JayF: it should be possible for you to set up a ppa and build/publish your kernel in there [19:44] Thanks. I'll look into doing that. [19:58] Any i915 experts in the house? I've tried the intel-gfx list, but have never had any luck getting any response to any of my questions [20:16] * rtg_ -> EOD === yofel_ is now known as yofel [21:59] bjf: jjohansen: Unless I'm reading the kernel source wrong, it looks like linux-lts-backport-oneiric latest is *not* vulnerable. [22:00] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8176cced706b5e5d15887584150764894e94e02f should be the fixing commit, and the offending line is already updated in the source [22:01] JayF: the oneiric kernel contain commit b0a873ebbf87bf38bf70b5e39a7cadc96099fa13 which is the commit fingered as introducing the bug [22:01] jjohansen: my comment was that it appears to also have the commit fixing the bug [22:02] hah, so it does [22:02] I didn't even bother looking for that [22:03] Cool. Glad to have confirmation :). [22:03] JayF: wait, it shows up when I do git show on my tree but not in the log [22:04] jjohansen: I just unpacked the kernel source tarball I got from http://packages.ubuntu.com/source/lucid/linux-lts-backport-oneiric went to the function in question, and checked [22:04] and it's showing the u64 vs the int [22:05] line 5433 in kernel/event/core.c in that copy vs line 5331 in the kernel git log... but the line and function are idential and appears to be nonvulnerable [22:06] JayF: I'll take your word for it, its possible my copy of the tree didn't get the last update. and the repo has been removed [22:07] that is the oneirc repo [22:07] the lucid repo has the backport kernel but is log just shows which oneiric kernel is backported [22:08] Cool. Well I'll let at least my twitter followers know :) === kentb is now known as kentb-out