[08:48] <henrix> apw: yo! my irc logs say you've tried to contact me in last few days
[08:48] <henrix> (i was off yesterday and friday)
[08:48] <apw> henrix, heh yeah ...err
[08:48] <henrix> apw: do you still remember what you wanted from me? :)
[08:49] <smb> Such a long time to remember. :-P
[08:49] <apw> 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] <apw> (if you can remember :)
[08:50] <henrix> apw: give me a min to check...
[08:50] <apw> no rush ... yawn
[08:51] <henrix> 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] <henrix> 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] <apw> henrix, ahh great, i am all done with them, so cool
[08:52] <henrix> apw: ok, i'll update the cvetracker today then
[08:54] <apw> no rush as long as it is in hand i can forget about it
[08:55] <henrix> apw: yep, i'll take care of that. thanks
[08:55] <smb> 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] <ubot2> 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] <apw> smb, sigh ... you had some sync patches for that didn't you ?
[08:56] <apw> though i thought that they did some more upstart work to avoid that ... hmmm
[08:57] <smb> 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] <smb> Remember vaguely that there is not much the kernel can do when plymouth hold its clutches to the buffer
[08:58] <apw> i am pretty sure i saw some upstart work from slangasek to avoid the overlap
[09:00] <smb> 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] <apw> smb, i cannot see these changes in upstart, but they could be somewhere else
[09:03] <smb> apw, Probably best to try to get in touch with slangasek 
[09:03] <apw> smb, ok the work was from tjaalton and at least in part in plymouth
[09:03] <apw> smb, it was also only in -updates
[09:04] <apw> so it missed the release
[09:04] <smb> apw, Ah. Doh! So probably have to ask for trying ssh in and updatign
[09:05] <tjaalton> hmm it was only on desktop, needed changes to both plymouth & lightdm
[09:05] <smb> plymouth is in server (sadly imo)
[09:05] <smb> but not lightdm
[09:06] <tjaalton> so it's not the same race
[09:07] <smb> 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] <apw> 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> apw@agent57:~$ dig www.google.com
[09:36] <apw> ;; Got bad packet: FORMERR
[09:36] <apw> 139 bytes
[09:36] <apw> anyone else seen it?
[09:37] <ogra_> i get a proper reply here
[09:37] <cking> apw, works ok for me
[09:38] <apw> always works the first time, and not the 'rest', so someone is caching it
[09:40] <apw> i think it is my BT home hub ... hmmm
[10:02] <hrw> hi
[10:02] <hrw> bug 1178847 - does someone has it with other devices?
[10:02] <ubot2> 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
[13:18] <psivaa> 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] <ubot2> 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
[15:30] <slangasek> 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] <slangasek> and I don't think we can ever reliably solve this from the userspace side
[15:31] <apw> slangasek, there is a change in plymouth that adds a new event which i htink is specifically to allow us
[15:31] <apw> slangasek, to ensure that we have let plymouth unsplash before X starts or something
[15:32] <slangasek> that has nothing to do with the bug you're talking about
[15:32] <apw> i thought that was to ensure we closed the DRM driver before we opened it again
[15:33] <slangasek> 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] <apw> that either is going to fix most of it, or maybe allow the fixes that smb was trying to do, to work
[15:33] <slangasek> no
[15:34] <apw> slangasek, sounds liek there is some confusion and i would like (when not in sessions) to get you, smb, and me together
[15:34] <apw> as i think smb had a handle on the main issue, which is frambuffer rippage, but we needed plymouth to let go
[15:34] <smb> slangasek, apw ack would be a bit to much to follow
[15:34] <apw> and i think plymouth may be guanreteed to do so now or something
[15:35] <smb> 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] <apw> smb, right ... i think it was not waiting, just doing it, but if you made it do it, then it just sticks
[15:48] <ppisati> 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] <ppisati> rtg_: ^
[15:49] <rtg_> ppisati, is that just a pocket copy from Quantal ?
[15:49] <ppisati> rtg_: right
[15:49] <rtg_> ppisati, nm, just read for content
[17:28]  * rtg_ -> lunch
[19:25] <ara> ogasawara, sorry, the lag was terrible, so our questions came like 5 minutes later :D
[19:25] <ara> ogasawara, I asked about the 12.04.3 HWE stack, is that happening?
[19:25] <apw> 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] <ara> there was some conversations about keeping the same stack as in 12.04.2
[19:26] <ppisati> ...
[19:26] <rtg_> apw, I wonder why we are bothering with the omap4 desktop image ?
[19:26] <bjf> ara, yes
[19:26] <apw> i think there was some new generation intel stuff which needed it at a minimumm
[19:26] <ogasawara> ara: yes, we will have a 12.04.3 enablement stack using the kernel from 13.04
[19:26] <bjf> ara, 12.04.3 will have the raring kernel
[19:26] <ppisati> perhaps you missed it in the foudnation channel but...
[19:26] <ara> thanks
[19:26] <ara> the lag was terrible :)
[19:26] <apw> rtg_, cause it is our only arm desktop image
[19:26] <ppisati> 21:14 < ppisati> AFA arm is concerned, 3.11 is way better if we want to ad exynos5 support to -generic
[19:26] <ara> so our questions came in when the session had already finished
[19:26] <ppisati> *add
[19:27] <ppisati> ogasawara: ^
[19:27] <apw> ppisati, yeah, newer is pretty much always better for us
[19:27] <apw> all round
[19:27] <ogasawara> ara: ah shoot, will have to remember the lag in the next meeting
[19:27] <ppisati> in 3,10 we can have as a separate flavour, but there're a lot of bits missing
[19:27] <ogasawara> ppisati: ack, I'm in favor of 3.11 myself
[19:27] <ppisati> just FYI
[19:27] <apw> ogasawara, the lag is very very variable, i find if you reload anyhow, it gets pretty near instant
[19:27] <apw> having done notes for a number of sessions i cirtainly wasn't more than seconds behind
[19:28] <apw> it may of course depend on where the originator of the channel is physically 
[19:28]  * ppisati gets some food
[19:28] <apw> 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] <cjwatson> I have no intuition on what it depends on
[19:30] <cjwatson> I don't think it can be mainly bandwidth since I have ridiculously little of it
[19:30] <cjwatson> but I suppose there could be some kind of spiralling latency effect
[19:34] <apw> yeah
[20:09]  * rtg_ -> EOD
[20:15] <bjf> jsalisbury, can we mark bug 1089818 Fix Released ?
[20:15] <ubot2> 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] <jsalisbury> bjf, sure