[07:16] <DanChapman> good morning :-)
[07:23] <pitti> Good morning
[07:36] <DanChapman> morning pitti o/
[07:37] <pitti> hey DanChapman, how are you?
[07:37] <jibel> Good morning
[07:37] <elfy> morning all
[07:46] <DanChapman> pitti, i'm good thanks, and yourself?
[07:47] <pitti> DanChapman: quite well, thanks! a bit tired, we went to bowling and some drinks last night, to celebrate my wife's last day at her current company
[07:50] <DanChapman> pitti, very nice. Hope it was good fun :-)
[07:50] <pitti> oh yes, it was
[07:50] <DanChapman> :-)
[08:04] <pitti> jibel: I'd like to temporarily disable all adt nodes except aldebaran (as that's the node where py3.3 failed), and re-run py3.3 with haveged installed; ok with you?
[08:04] <pitti> jibel: or perhaps with a /dev/random -> /dev/urandom symlink; it seems to me that the py* tests regularly run out of entropy
[08:04] <pitti> jibel: or at least, that's my current theory of why the uuid test fails so often
[08:06] <pitti> jibel: i. e. I'd call prepare-testbed with locally modifying the cloud-init to install haveged
[08:07] <pitti> or locally modify run-adt-test to do the urandom symlink (and then see whether that suffices)
[08:08] <jibel> pitti, I confirm I made the same observation. Agreed to try with haveged
[08:09] <pitti> jibel: I guess I wouldn't actually have to disable the nodes in jenkins, just run-adt-test manually on aldebaran
[08:14] <DanChapman> jibel, pitti it seems that ubiquity bug is still kicking about :-( All the stacktraces are identical it seems that the killer point is when refresh_state is called. on the progressbar.fraction property. The test  polls on progressbar.fraction waiting for bar to reach 100%. It seems to be a very unique bug
[08:15] <elfy> DanChapman: woohoo got some green lights for xubuntu :)
[08:15] <jibel> DanChapman, it has not been merged, I'll ping the CI team
[08:15] <pitti> DanChapman: yes, autopilot-gtk hasn't autolanded yet; I'll ask didrocks
[08:15] <pitti> ok, jibel beat me to it
[08:16] <pitti> jibel: it's in trunk (merged), just not autolanded
[08:16] <DanChapman> elfy :-) and the custom_install tests are passing aswell they just have non-fatal errors. so Installation wise you have all green UI bug wise you have 1 failing if that makes sense :-)
[08:16] <DanChapman> jibel, pitti ahh I see I thought it would have landed by now :-) thanks
[08:17] <pitti> yeah, so did I -- especially now that "daily" is supposed to mean "every 4 hours"
[08:18] <DanChapman> :-)
[08:19] <elfy> DanChapman: yep that makes sense
[08:23] <jibel> pitti, DanChapman, didrocks added it to the "Landing ask spreadsheet". Yay for powerful manual processes :)
[08:30] <pitti> DanChapman: ok, didrocks is caring about it, should land today
[11:11] <davmor2> Morning all
[11:50] <slickymaster> morning all
[13:03] <DanChapman> pitti, i must say your print_tree() addition is a rather handy little feature :-)
[13:10] <pitti> DanChapman: glad that you like it
[13:21] <pitti> DanChapman, jibel: fixed ap-gtk just landed in trusty
[13:26] <DanChapman> pitti, great! thanks
[13:47] <jibel> pitti, excellent, more green tomorrow
[15:22] <jibel> pitti, we'd need something like http://paste.ubuntu.com/6494460/ I guess to run unit tests for qt...-src packages. I tried with qtxmlpatterns and qtsystems but some tests fails because they need a specific setup.
[15:23] <jibel> (without the hardcoded path of course)
[15:26] <pitti> jibel: oh, qmake isn't in $PATH? how weird
[15:29] <pitti> jibel: ah, /usr/bin/qmake is an alias for qtchooser; doesn't that pick the right one?
[15:46] <jibel> pitti, it does but I've been lazy and copy/pasted the line generated to run make check :) My point was that on 2 packages both testsuite failed and it will require a good amount of time to either fix or identify unit tests that must be skipped.
[15:46] <jibel> and I haven't tried qtbase or qtwebkit
[15:47] <pitti> jibel: ah, I understand; thanks