[00:20] 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! === amitk is now known as amitk-afk === zequence_ is now known as zequence === Daviey_ is now known as Daviey === henrix_ is now known as henrix === amitk-afk is now known as amitk === ivoks_ is now known as ivoks [11:14] henrix, yo ... did you do the CVE work for CVE-2013-3076 ? [11:15] the matrix says that lucid is missing and wondering if it is in the pipeline, or got lost in application [11:15] i have deleted all the emails of course so i cannot check [11:55] 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] slightly interesting: http://jwboyer.livejournal.com/47022.html [13:51] mdeslaur, slightly interesting indeed, mostly cause it says we are in sane line mostly [13:51] mdeslaur, thanks for the pointer === kentb-out is now known as kentb [13:57] cking, do you have an up to date raring xen install? i am getting failures creating new domains [13:58] 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] apw, I can find my Xen install and give it a go [13:58] cking, do you even have one of those ? if so what package is it in :) [13:58] 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] cking, that is so just the pain i went through [14:05] * cking starts to update it [14:06] can you ask dpks where that comes from, in case it goes away [14:06] dpkg -S /usr/lib/xen-default/boot/hvmloader [14:08] just a sec, it's still booting [14:40] rtg, yo ... i have pushed a manta-apw branch to saucy so you can see how i think this should be fixed [14:41] rtg, if you concur then i'll do the others [14:41] see my email reply for reasoning [14:41] apw, just sent email on k-team list [14:43] rtg, see it now, great i'll get that sorted out. [14:44] rtg, do we have an hwe branch for saucy yet ? as i need to test that one also if so. [14:44] henrix, about ? [14:44] apw, if you get those changes into master-next, then I can take care of syncing manta [14:44] rtg, works for me, i'll let you know [14:45] apw, I'll work on learning mutt in the meantime. I'm fed up with thunderbird. [14:50] 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] That said, I'm in the process of transitioning to mutt myself, and using imapfilter to sort the mail [14:53] 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] apw: hrm, I probably just added a fix that someone gave me...I've never personally used virt-manager with xen [14:54] apw: does that file exist? [14:55] mdeslaur, in fact you closed it for lack of feedback from the user [14:55] oh, hehe [14:55] mdeslaur, nope, in keeping with the bug, i have a xen-4.2 version [14:55] but nothing xen-default [14:56] * apw pokes libvirt to see if this is in it [14:56] hrm, looks like that changed at some point [14:57] well cirtainly libvirt has a heap of xen-default paths in it [14:57] oh it has a patch to fix this, but ... not sure it is applied [14:58] does the xen package actually create a xen-default symlink to xen-4.2? [14:58] i don't think it does, and i think libvirt in saucy is patched to remove those paths too [14:58] oh, yeah, I see that now [14:59] i see this was well tested in raring before release, sigh [14:59] but then, something needs to put hvmloader in the path [14:59] apw: I'd poke hallyn for libvirt [15:00] mdeslaur, will do indeed, i think it is meant to be fixed in what i am running [15:00] so i am going to reboot it harder to make sure i got the old version off the bottom of my shoe [15:06] apw: i don't touch the xen bits, but zul / smb should have answers [15:07] hallyn_, it looks to be a libvirt issue to my eye [15:09] 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] apw: right, ping zul [15:13] ta [15:19] 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] rtg, so if you sync debian from saucy into the branch, then you should be able to just fix the control file [15:20] apw, ack [15:20] rtg, if you want to just sync the debian in there, i can do the rest if that is easier [15:21] 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] apw, you gonna push your changes to master-next ? [15:22] rtg, i am saying that what was there before your patch should be sufficient [15:23] apw, oh, ok. [15:23] rtg, so there are no changes to add, it is in there [15:23] the key components are the indeppkg and its use on link-headers, which is in there [15:23] plus of cours your control changes, but htey are branch specific [15:23] apw, when I synced before there seemed to be a lot of differences, though a lot was whitespace. [15:24] yeah those branches are on very very old base, i assume you just replaced it completly [15:24] which ought to work [15:24] apw, I'm going to [15:25] rtg, as you are doing manta, shall i do the same to mako [15:25] apw, ok, so I slammed HEAD on master-next in order to drop the platform names patch. I'll update manta accordingly [15:25] apw, yeah, go ahead and do mako [15:29] rtg, lets see if a naive conversion just works [15:34] apw, a naive rsync clobbers debian/rules.d 'cause the indep headers package name changes aren't in master-next [15:35] ? [15:35] UBUNTU: [Packaging] make the common headers SRCPKGNAME prefix [15:35] * apw waits on his build [15:36] that is in there ? [15:36] * apw lets his test build complete [15:37] the header link stage looked to have the right names at least [15:37] apw, ok, those changes are _already_ in master-next. never mind. [15:38] yeah, master next has them, but they do nothing cause the src package is called linux [15:38] apw, well, it JFDTRT [15:39] i think it does indeed, waiting on the final bits with DI disabled [15:39] some of our improvements to the debian/rules* have been worthwhile :) even if kamal hates it [15:50] cking: are you around perchance? [15:50] 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] plars, yep, I'll peek at it [15:50] we are seeing a *huge* increase in events from swapper [15:51] 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] rtg, ok i have pushed my mako redux to saucy repo ... perhaps look it over [15:51] apw, ack [15:51] rtg, shall i do the other one [15:52] apw, I'm working on manta [15:52] grouper [15:52] apw, rock on [15:55] plars, how do I access the raw logs on the tests? [15:56] apw, I think you lost the gcc-4.7 changes to mako in debian/rules.d/0* [15:56] rtg, mako did it in Makefile not in the debian bits [15:57] ah [15:57] 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] rtg, which reminds me, if you do it where you do, you need to add $(CROSS_COMPILE) before gcc-4.7 [15:57] i had that on my manta-apw branch [15:57] plars, ok - got it- thanks [15:58] apw, yeah, just forgot [15:58] rtg, i'll switch my branches to match yours next [15:58] though i think doko hinted it may not be needed any more [15:58] i must check with him [16:01] 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] 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] rtg, oh, hmm, i think we should be overriding REAL_CC not CC in the 3.4 branches ... [16:03] 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] cking: I can take any feedback you have to the people working on the dashboard if you'd like [16:04] plars, it would be useful to have the kernel version info there just to make life a little easier ;-) [16:05] cking: we test the whole image, and we're looking at these events not just in kernel but apps too [16:05] cking: it should be easier to derive versions of all these things from somewhere shouldn't it? [16:05] plars, sure, it would be nice to figure out easily what's changed [16:06] apw, I think that is an android addition in your mako Makefile [16:06] its not in manta [16:12] 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] cking: that's std.dev % or std.dev/avg [16:15] mind boggles [16:18] josepht, is it a a population std.dev in % then? [16:19] cking: yes, the population std.dev is in there too, one column to the left [16:20] josepht, yep, that's good then ;-) [16:21] bah, /me needs to use stdevp() in libreoffice next time [16:24] * ppisati goes out for a bit... [16:25] plars, so what's the official procedure when issues like this get spotted? do bugs get filed and if so, who files them? === masACC is now known as maswan [16:32] cking: in theory, anyone could see it out there and open something on it [16:32] cking: I try to check it regularly, but we have a LOT of these sort of things to check on [16:33] 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] 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] plars, I'm not sure, the rate coincides with the 250Hz tick interval, so I'm not sure yet [16:35] cking: and I did file a bug for the comiz/gnome-screensaver issue you pointed out last week also [16:35] plars, thanks ;-) [16:36] 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] 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] please open it, assign it to me, also, I'd like to see how it changes over time too [16:54] 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] cking: I'll take a look [16:55] ta [16:56] cking: I think there's some environment variables that get set for that stuff [16:56] utah-tastic [16:57] cking: actually this is a variable that the kernel tests want set [16:58] ah [16:58] oh well, whatever [16:58] 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] righteo [16:58] cking: regardless of the name, it *is* running on saucy though :) [17:22] plars, how do i find the kernel version for these tests? [17:24] apw: there is no way for you to find out the kernel version that was in a specific day's image? [17:24] should be in the manifest I think [17:25] and that is in your results, or i have to download 800M of image to find out [17:25] apw: no, should be more like a 50k file on cdimage [17:25] 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] perhaps a link direct to the manifest for the image [17:52] apw, pushed and uploaded saucy manta. you could delete the manta-apw branch [18:59] rtg, gon [18:59] gone === lool- is now known as lool [19:14] apw: That same headers fix is needed for mako and grouper too. [20:18] infinity, all true, and they are both done and pending for the next uploads [20:18] infinity, i don't think there is any gain from uploading for just that though ... [20:26] apw: Fair enough. === nightwish is now known as wrayan === kentb is now known as kentb-out