[01:37] <teward> there's no way to increase the Y-axis scale on errors.u.c is there?
[01:42] <xnox> teward: it's all "javascript" so if you can use js-debug console in your browser i think you can tweak/control the graph as you want.
[01:42] <xnox> teward: no controls are exposed by default as far as i can tell.
[01:43] <teward> assuming that i know the javascript commands to do it
[01:43] <teward> and if the js-debug console exists in chrome
[01:43] <teward> which it might not
[01:52] <teward> xnox, it would help if the graph auto-adjusted the y-axis max, for when we have spikes going off the page
[01:53] <teward> on errors.u.c
[01:53] <teward> personal opinion but still
[01:53] <xnox> teward: chrome developed the js-console -> Ctrl+Shift+C -> console
[01:54] <xnox> teward: one should not adjust the axis because of the spikes, as the spikes are artificial data -> on release day the amount of machines submitting errors increases by a few magnitudes, yet it takes time for graph to settle and normalise.
[01:54] <teward> ehhh i have to relearn javascript >.>
[01:54] <teward> ahh okay
[01:55] <xnox> teward: the graph does not know total number of machines running a given release, thus it does moving averange which is susceptible to spikes.
[01:56] <xnox> moving average of unique machines submitting an error in the past 90 days.
[01:56] <xnox> or some such.
[06:03] <pitti> Good morning
[06:42] <elfy> morning peeps
[06:46] <elfy> pitti: so when will your systemd ppa have unicorn ? current one seems to be working fine with xubuntu btw :)
[06:46] <pitti> elfy: never -- I uploaded everything to utopic :)
[06:47] <pitti> elfy: most stuff is in, just systemd itself is stuck in -proposed on some reverse dep autopkgtest failures (unrelated, though)
[06:47] <pitti> elfy: I'm working on autopkgtest maintenance today and see that it can propagate soon
[06:47] <elfy> oh awesome
[06:47] <pitti> elfy: nice to know!
[06:47] <pitti> elfy: I'll do an annoucement if it's ready to be tested
[06:48] <elfy> yep - I find it as useful to know when something is working as when it's not :)
[06:48] <elfy> ok - shall watch for that then :)
[06:48] <pitti> elfy: I ran into some trouble which developers will encounter -- e. g. schroot goes totally wonky due to systemd changing the beaviour for unshared mounts
[06:48] <pitti> elfy: yes, absolutely
[06:48] <pitti> elfy: if you run into stuff, please file as bug with "systemd-boot" tag
[06:48] <pitti> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=systemd-boot
[06:48] <elfy> yea - I saw that request for bugs
[06:50] <elfy> when I start the calls for us to test - I'll do an 'if anyone is interested you can try systemd too' one as well - some of our testers like to play
[06:51] <pitti> elfy: I want to wait with the announcement until it's at least good enough for myself to run permanently -- ATM, the blockers are schroot, and to a lesser degree, LXC for me
[06:51] <pitti> lightdm, NM and the other bits seem to work fairly well
[06:51] <elfy> yep - I understand that :)
[07:16] <stema> hi all
[07:47] <jibel> pitti, I'll be working on britney this week, there is a problem with the reconciliation between the request and the result with the new autopkgtest.
[07:48] <pitti> jibel: I'll handhold the autopkgtests
[07:48] <pitti> jibel: I fixed a few last night, will continue today
[07:49] <pitti> jibel: I just stumbled over the vmalloc=512 hack, added to adt-buildvm now and rolled out (succeeded now)
[07:49] <jibel> pitti, I'll also have a look at this case: http://paste.ubuntu.com/7350811/
[07:49] <pitti> jibel: oh, the eternal RUNNING?
[07:49] <pitti> jibel: btw, I re-enabled notifications for x86 in bzr, I think it's time
[07:49] <jibel> pitti, not the running, the 2 lists should identical
[07:49] <pitti> jibel: mind rolling that out?
[07:50] <pitti> jibel: oh, right; is that the same as eating lots of PASSes?
[07:50] <jibel> pitti, the part at the bottom are the states collected by britney and the top is what is reported in update_excuses
[07:50] <jibel> pitti, in that case systemd was not even in that list
[07:52] <jibel> pitti, pulled r348
[07:53] <jibel> I guess I'll use the full index of main to try to reproduce, I couldn't find a simple test case with the current testsuite
[07:53] <pitti> jibel: I saw the r347 sorting fix, thanks for that
[07:53] <pitti> jibel: that is, the britney tests in my branch?
[07:54] <pitti> or does adt-britney have one, too?
[07:54] <jibel> pitti, the britney tests in your branch, adt-britney has one too
[07:54] <jibel> pitti, but in the example I pasted above, it's only britney
[07:55] <jibel> because the list of 'RUNNING' is the output of adt-britney and it is correct
[10:02] <davmor2> Morning all
[12:15] <jibel> pitti, would it be possible to generate testpkg-version right after the .dsc is downloaded otherwise when there is a build failure or unsatisfy deps the file is missing and there is no way to know what package we were testing
[12:16] <jibel> for example in http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-u1db/ARCH=amd64,label=adt/4/ there is only a log file
[12:30] <pitti> jibel: hey
[12:31] <pitti> jibel: I thought I did already; yes, it should certainly do that
[12:31]  * pitti looks
[12:39] <pitti> jibel: hm, that's a bit odd; it does that here (testpkg-version and testbed-packages), before it even starts installing the per-test deps
[12:40] <pitti> oh sorry, this is for needs-build
[12:41] <pitti> jibel: yep, reproduced
[12:45] <pitti> jibel: hm, this is actually way more tricky than I thought, but I'll think about it
[12:49] <jibel> pitti, thanks
[12:49] <pitti> testbed-packages is the simple part, done
[13:18] <jibel> pitti, I increased the ram size of the VMs to 2G this morning, did you notice any "cannot allocated memory" in recent tests?
[13:20] <pitti> jibel: yes, I did; upstart/amd64 failed until this morning, now it succeeds
[14:01] <pitti> jibel: testpkg-version is now generated right after unpacking the source, i. e. as early as possible
[14:02] <pitti> jibel: doing another test (unrelated) still, then will roll this out
[14:02]  * pitti ♥ running adt-run from git, so much faster deployment
[14:10] <pitti> jibel: deployed
[14:11] <pitti> jibel: FYI, I added a jenkins/update-canonical-servers which calls jenkins/update-servers with all four
[14:11] <pitti> since I do this like twice a day these days
[14:47] <jibel> pitti, woohoo, finally I reproduced the problem with the missing results from excuses. I used the full archive and result history. Now it is just a matter of finding the right case.
[15:02] <pitti> jibel: oh, awesome work! it doesn't reduce to some small case?
[15:02] <pitti> jibel: eek, weird adt failures galore, looking
[15:17] <jibel> pitti, it probably does. I'm on it
[15:30] <elopio> congratulations davmor2!
[15:33] <davmor2> elopio: thanks
[15:46] <rvr> elopio: Ok, so you are using __all__ to filter more modules, not only the ones with underscores, right?
[15:48] <elopio> rvr: I'm using __all__ to hide one directory
[15:49] <rvr> elopio: Aha
[15:49] <elopio> so the namespace is as if you had all the helpers in one big .py file, but they are really in many smaller ones.
[15:49] <rvr> Ahhh
[15:49] <rvr> Ok, understood
[16:28] <rbasak> pitti or jibel: can we run lxc and/or qemu dep8 tests in our infrastructure now?
[16:28] <rbasak> I have a dep8 test for something that fails only in qemu - not in lxc.
[16:29] <rbasak> Given that the behaviour is different, I'd like to arrange to test both.
[16:29] <jibel> pitti, I may have found the problem, in britney.py autopkgtest_excuses is populated _before_ the collect, then we iterate over autopkgtest_excuses to populate excuses.html
[16:29] <rbasak> I'm thinking of two tests, isolation-container and isolation-machine, that symlink to the same test or something.
[16:30] <rbasak> Is this supported in our infrastructure now?
[16:30] <jibel> which means that new versions of a package with test won't appear in update_excuses
[17:18] <pitti> rbasak: isolation-container only means "at least LXC", not "only LXC"
[17:18] <pitti> rbasak: we don't have the infrastructure for that yet; x86 is qemu only, armhf/ppc64el is lxc only
[17:18] <pitti> rbasak: in the future we'll be able to be more flexible though
[17:19] <rbasak> pitti: OK, thanks. By qemu only, do you mean adt-virt-qemu, or adt-virt-null still?
[17:19] <pitti> rbasak: we run adt-virt-qemu now
[17:19] <pitti> -null is history \o/
[17:19] <rbasak> Ah, great! I have some multiple breaks-testbed tests to enable then :)
[17:19] <pitti> rbasak: go!
[17:40] <balloons> nice recap elfy, knome http://xubuntu.org/news/xubuntu-14-04-qa-recap/ ;-)
[17:40] <elfy> balloons: glad you liked it :)
[17:41]  * knome directs all credit to elfy
[17:41] <elfy> I was pleased with what my lot got done last cycle - did it show :p
[17:42] <balloons> it did.. xubuntu was very active.. you guys did a lot of nice work, and it benefited everyone :-)
[17:43] <elfy> nice to hear that :)
[17:43] <balloons> It was nice to see the work going on the tracker in particular..
[17:44] <elfy> yep
[17:44]  * elfy will be wanting the package one soon :)
[20:17] <elfy> balloons: you got any idea when the package tracker will be up for Unicorn?
[20:51] <phillw> balloons: can you get a script person to look at bug 1308853 I'm not sure if it is a change in commands, or the command line will no longer work (P.S. ... I guess it is not worth asking as it if "Until hexr comes on-line, we use a work-around - which pulls the system specifications from your computer. The work-around does NOT report personal data from your computer. This means that your passwords and other sensitive information remain safe
[21:50] <balloons> phillw, I assume off the top hardinfo changed there arguments.. but we'll have to look
[21:53] <phillw> balloons: possibly, I'm still battling with a really bad cold that keeps coming back for me and my family I'm battling with the non-pae lubuntu, so If you could have a look into what is causing the fails on that; it would be apreciated.