=== a16g_ is now known as a16g === Traxer|on is now known as Traxer === lag` is now known as lag [08:48] apw: yo! my irc logs say you've tried to contact me in last few days [08:48] (i was off yesterday and friday) [08:48] henrix, heh yeah ...err [08:48] apw: do you still remember what you wanted from me? :) [08:49] Such a long time to remember. :-P [08:49] henrix, yeah i was wondring if it was you who did the fixes for CVE-2013-3076, and if lucid being missing was deliberate or an application error [08:50] (if you can remember :) [08:50] apw: give me a min to check... [08:50] no rush ... yawn [08:51] apw: ah, got it. yes, i prep'ed the patchs for that CVE but not for lucid because it doesn't seem to be affected [08:51] apw: i haven't updated the cvetracker file yet (its in my TODO) because you were messing with the CVE scripts at that time [08:52] henrix, ahh great, i am all done with them, so cool [08:52] apw: ok, i'll update the cvetracker today then [08:54] no rush as long as it is in hand i can forget about it === jk-- is now known as jk- [08:55] apw: yep, i'll take care of that. thanks [08:55] apw, There seems to be the unpleasant business of framebuffer replacement sticking to our heels. Or so I would read the latest comment on bug 1100386 [08:55] Launchpad bug 1100386 in linux (Ubuntu) "Raring server installations on VMs fail to reboot after the installations" [High,Confirmed] https://launchpad.net/bugs/1100386 [08:56] smb, sigh ... you had some sync patches for that didn't you ? [08:56] though i thought that they did some more upstart work to avoid that ... hmmm [08:57] apw, I had something long long time ago. But as you say I / were told that that would not be the place to do it. And I am not sure it really worked well then. [08:58] Remember vaguely that there is not much the kernel can do when plymouth hold its clutches to the buffer [08:58] i am pretty sure i saw some upstart work from slangasek to avoid the overlap [09:00] Yeah, guess we need some investigation. Might depend on certain hw (speed) too. Unfortunately I am using Xen most of the time and that does not "suffer" yet from a drm drivers support [09:02] smb, i cannot see these changes in upstart, but they could be somewhere else [09:03] apw, Probably best to try to get in touch with slangasek [09:03] smb, ok the work was from tjaalton and at least in part in plymouth [09:03] smb, it was also only in -updates [09:04] so it missed the release [09:04] apw, Ah. Doh! So probably have to ask for trying ssh in and updatign [09:05] hmm it was only on desktop, needed changes to both plymouth & lightdm [09:05] plymouth is in server (sadly imo) [09:05] but not lightdm [09:06] so it's not the same race [09:07] As far as we saw (and if I remember correctly) it is something with plymouth rendering that dotty screen while kernel modeset tries to replace the efi fb with cirrusfb [09:07] * cking reboots [09:12] bah ... it seems that one need to charge laptop batteries, go figure [09:36] * apw is getting issues with 'dig' showing format errors when everything else works with its results [09:36] apw@agent57:~$ dig www.google.com [09:36] ;; Got bad packet: FORMERR [09:36] 139 bytes [09:36] anyone else seen it? [09:37] i get a proper reply here [09:37] apw, works ok for me [09:38] always works the first time, and not the 'rest', so someone is caching it [09:40] i think it is my BT home hub ... hmmm [10:02] hi [10:02] bug 1178847 - does someone has it with other devices? [10:02] Launchpad bug 1178847 in gcc-4.8 (Ubuntu) "chromeos 3.8 kernel fails to boot when compiled with gcc-4.8" [Undecided,Confirmed] https://launchpad.net/bugs/1178847 [12:14] * henrix -> lunch === ev_ is now known as ev === josepht_ is now known as josepht === Guest61231 is now known as mfisch === mfisch is now known as Guest83719 [13:18] hello, bug 1179509 is impacting the daily smoke tests, would be helpful for some feedback on it. i.e. any more logs needed etc, [13:18] Launchpad bug 1179509 in linux (Ubuntu) "'unregister_netdevice: waiting for lo to become free. Usage count = 2' is reported and causing kernel hang when floodlight tests are run using utah" [Undecided,Confirmed] https://launchpad.net/bugs/1179509 === rsalveti_ is now known as rsalveti === hrww is now known as hrw === AlexB_ is now known as AlexB === ferai is now known as jefferai === dannf` is now known as dannf === yofel_ is now known as yofel [15:30] smb, apw: there have been no changes to plymouth regarding fb driver replacement races. I still think it's a kernel bug that something from userspace having the fb open can break the kernel's fb replacement [15:30] and I don't think we can ever reliably solve this from the userspace side [15:31] slangasek, there is a change in plymouth that adds a new event which i htink is specifically to allow us [15:31] slangasek, to ensure that we have let plymouth unsplash before X starts or something [15:32] that has nothing to do with the bug you're talking about [15:32] i thought that was to ensure we closed the DRM driver before we opened it again [15:33] I know about the new event in plymouth, I helped tjaalton implement it - that's entirely to do with a race where lightdm can start before plymouth has shown its splash screen, and is unrelated to the kernel drivers [15:33] that either is going to fix most of it, or maybe allow the fixes that smb was trying to do, to work [15:33] no [15:34] slangasek, sounds liek there is some confusion and i would like (when not in sessions) to get you, smb, and me together [15:34] as i think smb had a handle on the main issue, which is frambuffer rippage, but we needed plymouth to let go [15:34] slangasek, apw ack would be a bit to much to follow [15:34] and i think plymouth may be guanreteed to do so now or something [15:35] In my memory I had something that waited till the fb resource in the kernel would be free but that would not happen until userspace (plymouth) released (closed) it [15:37] smb, right ... i think it was not waiting, just doing it, but if you made it do it, then it just sticks [15:48] FYI: just came out of the X session, and got to know that there'll be an S omap4 desktop img, thus we need to keep the Q/omap4 kernel around (as we did in R) [15:48] rtg_: ^ [15:49] ppisati, is that just a pocket copy from Quantal ? [15:49] rtg_: right [15:49] ppisati, nm, just read for content === infinity1 is now known as infinity === Guest83719 is now known as mfisch === emma_ is now known as em === ayan_ is now known as ayan [17:28] * rtg_ -> lunch === kentb-out is now known as kentb [19:25] ogasawara, sorry, the lag was terrible, so our questions came like 5 minutes later :D [19:25] ogasawara, I asked about the 12.04.3 HWE stack, is that happening? [19:25] ppisati, rtg_, for completeness the omap4 will be so far behind, that X will be doing a h/w enablement stack of old bits for the omap install ... this will likely make it break more :) [19:25] there was some conversations about keeping the same stack as in 12.04.2 [19:26] ... [19:26] apw, I wonder why we are bothering with the omap4 desktop image ? [19:26] ara, yes [19:26] i think there was some new generation intel stuff which needed it at a minimumm [19:26] ara: yes, we will have a 12.04.3 enablement stack using the kernel from 13.04 [19:26] ara, 12.04.3 will have the raring kernel [19:26] perhaps you missed it in the foudnation channel but... [19:26] thanks [19:26] the lag was terrible :) [19:26] rtg_, cause it is our only arm desktop image [19:26] 21:14 < ppisati> AFA arm is concerned, 3.11 is way better if we want to ad exynos5 support to -generic [19:26] so our questions came in when the session had already finished [19:26] *add [19:27] ogasawara: ^ [19:27] ppisati, yeah, newer is pretty much always better for us [19:27] all round [19:27] ara: ah shoot, will have to remember the lag in the next meeting [19:27] in 3,10 we can have as a separate flavour, but there're a lot of bits missing [19:27] ppisati: ack, I'm in favor of 3.11 myself [19:27] just FYI [19:27] ogasawara, the lag is very very variable, i find if you reload anyhow, it gets pretty near instant [19:27] having done notes for a number of sessions i cirtainly wasn't more than seconds behind [19:28] it may of course depend on where the originator of the channel is physically [19:28] * ppisati gets some food [19:28] when cjwatson was doing them i had good lag, but then we are relativly proximate in the world [19:28] * cking pops his kids to bed [19:29] I have no intuition on what it depends on [19:30] I don't think it can be mainly bandwidth since I have ridiculously little of it [19:30] but I suppose there could be some kind of spiralling latency effect [19:34] yeah [20:09] * rtg_ -> EOD [20:15] jsalisbury, can we mark bug 1089818 Fix Released ? [20:15] Launchpad bug 1089818 in linux (Ubuntu) "kernel crash when mounting encrypted (device mapped) ext4 partition" [High,Fix committed] https://launchpad.net/bugs/1089818 [20:15] bjf, sure === JanC_test_ is now known as JanC_test === kentb is now known as kentb-out