[00:20] <bryce> hey guys, today's my last day at canonical, so wanted to just thanks for being such a cool team to work with and share beers with!
[11:14] <apw> henrix, yo ... did you do the CVE work for CVE-2013-3076 ?  
[11:15] <apw> the matrix says that lucid is missing and wondering if it is in the pipeline, or got lost in application
[11:15] <apw> i have deleted all the emails of course so i cannot check
[11:55] <apw> oh god it is quiet ... help
[12:13]  * ppisati -> out for a late lunch
[12:53]  * cking takes an even later late lunch
[13:08] <mdeslaur> slightly interesting: http://jwboyer.livejournal.com/47022.html
[13:51] <apw> mdeslaur, slightly interesting indeed, mostly cause it says we are in sane line mostly
[13:51] <apw> mdeslaur, thanks for the pointer
[13:57] <apw> cking, do you have an up to date raring xen install?  i am getting failures creating new domains
[13:58] <apw> Unable to complete install: 'POST operation failed: xend_post: error from xen daemon: (xend.err "Error creating domain: kernel '/usr/lib/xen-default/boot/hvmloader' not found")'
[13:58] <cking> apw, I can find my Xen install and give it a go
[13:58] <apw> cking, do you even have one of those ?  if so what package is it in :)
[13:58] <apw> i was just trying to spin up some saucys
[14:00]  * cking can't get it to boot - gimme a mo while I find a spare monitro
[14:02] <apw> cking, that is so just the pain i went through
[14:05]  * cking starts to update it
[14:06] <apw> can you ask dpks where that comes from, in case it goes away
[14:06] <apw> dpkg -S /usr/lib/xen-default/boot/hvmloader
[14:08] <cking> just a sec, it's still booting 
[14:40] <apw> rtg, yo ... i have pushed a manta-apw branch to saucy so you can see how i think this should be fixed
[14:41] <apw> rtg, if you concur then i'll do the others
[14:41] <apw> see my email reply for reasoning
[14:41] <rtg> apw, just sent email on k-team list
[14:43] <apw> rtg, see it now, great i'll get that sorted out.
[14:44] <apw> rtg, do we have an hwe branch for saucy yet ?  as i need to test that one also if so.
[14:44] <apw> henrix, about ?
[14:44] <rtg> apw, if you get those changes into master-next, then I can take care of syncing manta
[14:44] <apw> rtg, works for me, i'll let you know
[14:45] <rtg> apw, I'll work on learning mutt in the meantime. I'm fed up with thunderbird.
[14:50] <zequence> rtg: If you don't mind proprietary, try the opera builtin mail client. It's the best gui client I've ever used for high mail traffic
[14:51] <zequence> That said, I'm in the process of transitioning to mutt myself, and using imapfilter to sort the mail
[14:53] <apw> mdeslaur, bizarrly you seem to have worked on an old bug against virt-manager wherein it triggers this error "Error creating domain: kernel '/usr/lib/xen-default/boot/hvmloader' not found" ... seems I have this right now in raring
[14:54] <mdeslaur> apw: hrm, I probably just added a fix that someone gave me...I've never personally used virt-manager with xen
[14:54] <mdeslaur> apw: does that file exist?
[14:55] <apw> mdeslaur, in fact you closed it for lack of feedback from the user
[14:55] <mdeslaur> oh, hehe
[14:55] <apw> mdeslaur, nope, in keeping with the bug, i have a xen-4.2 version
[14:55] <apw> but nothing xen-default
[14:56]  * apw pokes libvirt to see if this is in it
[14:56] <mdeslaur> hrm, looks like that changed at some point
[14:57] <apw> well cirtainly libvirt has a heap of xen-default paths in it
[14:57] <apw> oh it has a patch to fix this, but ... not sure it is applied
[14:58] <mdeslaur> does the xen package actually create a xen-default symlink to xen-4.2?
[14:58] <apw> i don't think it does, and i think libvirt in saucy is patched to remove those paths too
[14:58] <mdeslaur> oh, yeah, I see that now
[14:59] <apw> i see this was well tested in raring before release, sigh
[14:59] <mdeslaur> but then, something needs to put hvmloader in the path
[14:59] <mdeslaur> apw: I'd poke hallyn for libvirt
[15:00] <apw> mdeslaur, will do indeed, i think it is meant to be fixed in what i am running
[15:00] <apw> so i am going to reboot it harder to make sure i got the old version off the bottom of my shoe
[15:06] <hallyn_> apw: i don't touch the xen bits, but zul / smb should have answers
[15:07] <apw> hallyn_, it looks to be a libvirt issue to my eye
[15:09] <apw> hallyn_, which is odd as both ends of the relationship have the latest version, but they are still triggering paths with /xen-default/ in the middle
[15:10] <hallyn_> apw: right, ping zul
[15:13] <apw> ta
[15:19] <apw> rtg, ok if i see this right with your patch reverted, the bits needed to do the separated headers are in the main rules
[15:20] <apw> rtg, so if you sync debian from saucy into the branch, then you should be able to just fix the control file
[15:20] <rtg> apw, ack
[15:20] <apw> rtg, if you want to just sync the debian in there, i can do the rest if that is easier
[15:21] <apw> rtg, if you are doing it there are two places, the control.stub.in for the naming of the main package, and flavours.stub for the Depends on the flavour headers
[15:22] <rtg> apw, you gonna push your changes to master-next ?
[15:22] <apw> rtg, i am saying that what was there before your patch should be sufficient
[15:23] <rtg> apw, oh, ok.
[15:23] <apw> rtg, so there are no changes to add, it is in there
[15:23] <apw> the key components are the indeppkg and its use on link-headers, which is in there
[15:23] <apw> plus of cours your control changes, but htey are branch specific
[15:23] <rtg> apw, when I synced before there seemed to be a lot of differences, though a lot was whitespace.
[15:24] <apw> yeah those branches are on very very old base, i assume you just replaced it completly
[15:24] <apw> which ought to work
[15:24] <rtg> apw, I'm going to
[15:25] <apw> rtg, as you are doing manta, shall i do the same to mako
[15:25] <rtg> apw, ok, so I slammed HEAD on master-next in order to drop the platform names patch. I'll update manta accordingly
[15:25] <rtg> apw, yeah, go ahead and do mako
[15:29] <apw> rtg, lets see if a naive conversion just works
[15:34] <rtg> apw, a naive rsync clobbers debian/rules.d 'cause the indep headers package name changes aren't in master-next
[15:35] <apw> ?
[15:35] <rtg> UBUNTU: [Packaging] make the common headers SRCPKGNAME prefix
[15:35]  * apw waits on his build
[15:36] <apw> that is in there ?
[15:36]  * apw lets his test build complete
[15:37] <apw> the header link stage looked to have the right names at least
[15:37] <rtg> apw,  ok, those changes are _already_ in master-next. never mind.
[15:38] <apw> yeah, master next has them, but they do nothing cause the src package is called linux
[15:38] <rtg> apw, well, it JFDTRT
[15:39] <apw> i think it does indeed, waiting on the final bits with DI disabled
[15:39] <apw> some of our improvements to the debian/rules* have been worthwhile :)  even if kamal hates it
[15:50] <plars> cking: are you around perchance?
[15:50] <plars> or someone that can take a look at http://reports.qa.ubuntu.com/power/eventstat/image/14/machine/1/task_type/all/details/
[15:50] <cking> plars, yep, I'll peek at it
[15:50] <plars> we are seeing a *huge* increase in events from swapper
[15:51] <plars> we've had some issues in the automation that kept it from running the past few days, so it may not have just been today
[15:51] <apw> rtg, ok i have pushed my mako redux to saucy repo ... perhaps look it over
[15:51] <rtg> apw, ack
[15:51] <apw> rtg, shall i do the other one
[15:52] <rtg> apw, I'm working on manta
[15:52] <apw> grouper
[15:52] <rtg> apw, rock on
[15:55] <cking> plars, how do I access the raw logs on the tests?
[15:56] <rtg> apw, I think you lost the gcc-4.7 changes to mako in debian/rules.d/0*
[15:56] <apw> rtg, mako did it in Makefile not in the debian bits
[15:57] <rtg> ah
[15:57] <plars> cking: click on one of the tasks, then the build id, or just go here: https://jenkins.qa.ubuntu.com/job/eventstat-saucy-desktop-amd64-install-idle-vm/4/?
[15:57] <apw> rtg, which reminds me, if you do it where you do, you need to add $(CROSS_COMPILE) before gcc-4.7
[15:57] <apw> i had that on my manta-apw branch
[15:57] <cking> plars, ok - got it- thanks
[15:58] <rtg> apw, yeah, just forgot
[15:58] <apw> rtg, i'll switch my branches to match yours next
[15:58] <apw> though i think doko hinted it may not be needed any more
[15:58] <apw> i must check with him
[16:01] <cking> plars, I'm confused by the results that are 20120425,  I didn't know we had this running last year. is that a bug in the time stamp?
[16:02] <cking> also, it's kinda hard to see what changed in terms of kernel version being tested, it's kinda hard to find that info quickly
[16:03] <apw> rtg, oh, hmm, i think we should be overriding REAL_CC not CC in the 3.4 branches ...
[16:03] <plars> cking: those with the old dates are probably from the quantal/precise runs I did.. I didn't realize that the dashboard would show them in the same spot
[16:04] <plars> cking: I can take any feedback you have to the people working on the dashboard if you'd like
[16:04] <cking> plars, it would be useful to have the kernel version info there just to make life a little easier ;-)
[16:05] <plars> cking: we test the whole image, and we're looking at these events not just in kernel but apps too
[16:05] <plars> cking: it should be easier to derive versions of all these things from somewhere shouldn't it?
[16:05] <cking> plars, sure, it would be nice to figure out easily what's changed
[16:06] <rtg> apw, I think that is an android addition in your mako Makefile
[16:06] <rtg> its not in manta
[16:12] <cking> plars, the std.dev. looks very broken for some of the data, for exampe cupsd, the min/max is a very small  and the calculated std.dev is 300, I make it to be ~0.36
[16:15] <josepht> cking: that's std.dev % or std.dev/avg
[16:15] <cking> mind boggles
[16:18] <cking> josepht, is it a a population std.dev  in % then?
[16:19] <josepht> cking: yes, the population std.dev is in there too, one column to the left
[16:20] <cking> josepht, yep, that's good then ;-)
[16:21] <cking> bah, /me needs to use stdevp() in libreoffice next time
[16:24]  * ppisati goes out for a bit...
[16:25] <cking> plars, so what's the official procedure when issues like this get spotted? do bugs get filed and if so, who files them?
[16:32] <plars> cking: in theory, anyone could see it out there and open something on it
[16:32] <plars> cking: I try to check it regularly, but we have a LOT of these sort of things to check on
[16:33] <plars> cking: but today was the first time it came up for me since the job started going again, and I noticed something off there. After our talk last week I thought it best to bounce if off you first to make sure it was really a bug
[16:33] <plars> cking: now that the other results are on that dashboard, I do notice that the events for quantal and precise looked pretty high too, so maybe we got a lot better during raring?
[16:34] <cking> plars, I'm not sure, the rate coincides with the 250Hz tick interval, so I'm not sure yet
[16:35] <plars> cking: and I did file a bug for the comiz/gnome-screensaver issue you pointed out last week also
[16:35] <cking> plars, thanks ;-)
[16:36] <plars> cking: it's encouraging that the stddev was so low in quantal and precise, so once that's fixed we should see much more stable data for saucy
[16:44] <plars> cking: so should I just open a bug on this for you to look at? Can I assign it to you or should it go to the team?
[16:45] <cking> please open it, assign it to me, also, I'd like to see how it changes over time too
[16:54] <cking> plars, http://jenkins.qa.ubuntu.com/job/power-saucy-desktop-i386-power-test-1/1/artifact/qa-power-testing/results/raring-power-amd64-2013-05-07_14:52:25-power_consumption.json - this has the name "raring" but in fact it is a suacy test - that's a bit confusing 
[16:55] <plars> cking: I'll take a look
[16:55] <cking> ta
[16:56] <plars> cking: I think there's some environment variables that get set for that stuff
[16:56] <cking> utah-tastic
[16:57] <plars> cking: actually this is a variable that the kernel tests want set
[16:58] <cking> ah
[16:58] <cking> oh well, whatever
[16:58] <plars> cking: I'll change it for now, and try to remember to come back to it at some point and think about whether there's a better place I can inherit it from so that it picks it up automagically
[16:58] <cking> righteo
[16:58] <plars> cking: regardless of the name, it *is* running on saucy  though :)
[17:22] <apw> plars, how do i find the kernel version for these tests?
[17:24] <plars> apw: there is no way for you to find out the kernel version that was in a specific day's image?
[17:24] <plars> should be in the manifest I think
[17:25] <apw> and that is in your results, or i have to download 800M of image to find out
[17:25] <plars> apw: no, should be more like a 50k file on cdimage
[17:25] <plars> apw: but I agree it would be nice if it was easier to find, we'll see what we can do there in the future
[17:26] <apw> perhaps a link direct to the manifest for the image
[17:52] <rtg> apw, pushed and uploaded saucy manta. you could delete the manta-apw branch
[18:59] <apw> rtg, gon
[18:59] <apw> gone
[19:14] <infinity> apw: That same headers fix is needed for mako and grouper too.
[20:18] <apw> infinity, all true, and they are both done and pending for the next uploads
[20:18] <apw> infinity, i don't think there is any gain from uploading for just that though ... 
[20:26] <infinity> apw: Fair enough.