[03:46] <elopio> ping veebers: I'm back. Can I help reviewing the tests?
[03:47] <veebers> elopio: ah they've finished now, 1000+ tests ran and it doesn't look like they timedout
[03:48] <veebers> elopio: lets split them somehow. I'm just in the process of trying to understand this autopilot proxy base/cpo stuff but will follow up the autopilot release soon
[03:49] <elopio> looks promising, 100 failures
[03:49] <elopio> veebers: I'll start reviewing, making notes in an etherpad.
[03:50] <veebers> elopio: ack. actually I'll hit this now too. I'll start from the bottom of the list
[03:50] <elopio> veebers: http://pad.ubuntu.com/autopilot-20150408
[03:51] <veebers> elopio: actually, it looks like the dashboard run for 165:20150408:20150210 is still running
[03:52] <elopio> veebers: would it be wrong to also use the results from 164?
[03:53] <elopio> last time I checked 3 old revisions for some unstable tests.
[03:54] <veebers> elopio: so you're suggesting check against 163:20150406:20150210? The failure amount seems about the same, yeah lets do that
[03:55] <elopio> veebers: right, 164 is already running. What I did was to start on the latest run. But if there were no results on that one, I started digging on older ones.
[03:57] <veebers> ah ok, I see
[03:57] <veebers> elopio: So I'll start from the bottom going up (camera-app, gallery, unity8 etc.)
[03:58] <veebers> ah awesome, they aren't alphabetically sorted. (so please note that I'm doing the gallery app tests :-))
[04:05] <elopio> veebers: your format is a lot more simple.
[04:07] <veebers> ^_^ I've done this a bunch of times, I have it down
[04:19] <elopio> veebers: I'm going to take messaging app.
[04:21] <veebers> elopio: that leaves reminders and music, I'll take them
[04:25] <veebers> done
[04:25] <elopio> veebers: done.
[04:28] <elopio> veebers: I'm not worried about any of this errors I couldn't match.
[04:32] <veebers> elopio: the unity8 ones concern me a little as there are 16 failures compared to 1. I think I'll re-run the gatekeeper with just the unity8 tests to run
[04:32] <elopio> veebers: ok. I can check the results tomorrow.
[04:35] <elopio> veebers: on image 156 we got 14 errors and on image 153 we got 19, so it's not likely this new version's fault. But a new run would be nice.
[04:38] <veebers> elopio: oh really? perhaps I didn't check well enough
[04:46] <veebers> elopio: do you mind checking the results tomorrow? There is a chance I can check them tonight as it's only one suite
[04:46] <elopio> veebers: I will check early tomorrow, np.
[04:52] <veebers> sweetbix xhwwea
[04:52] <veebers> lol, keyboard fail
[04:52] <veebers> sweetbix cheers*
[06:46] <elopio> ping pitti: could this be related to systemd? https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1441893
[06:47] <elopio> I've been having problems with the network close to when I upgraded my vivid. But I also changed some things on my network, and my other machine survived the upgrade, so I don't know.
[06:47] <pitti> elopio: by the looks of it no; systemd does a lot, but wifi connections are between kernel, NetworkManager, and wpa_supplicant
[06:48] <pitti> elopio: I have such an effect sometimes, particularly when I'm travelling
[06:48] <elopio> pitti: any idea who should I ping to get this triaged?
[06:48] <pitti> elopio: most often the driver became confused, and I rmmod iwlwifi iwldvm and modprobe them again
[06:48] <elopio> my laptop without wifi won't be too useful for the sprint. So I might need to downgrade if I can't find a solution.
[06:49] <elopio> pitti: thanks, I'll try that.
[06:49] <pitti> elopio: if that helps, it should be reassigned to linux
[06:49] <pitti> elopio: does that only happen sporadically, or does it even not connect after a cold boot?
[06:50] <elopio> pitti: a couple of weeks ago I wasn't able to reconnect, but when I rebooted it connected without problems. Now it never connects.
[06:51] <pitti> elopio: just to rule that out you could try and boot with upstart; a better bet is probably to grab the utopic kernel and boot with that
[06:52] <pitti> and/or downgrade linux-firmware (where the intel fw is)
[07:00] <elopio> pitti: does it makes sense for it to say that iwldvm is not loaded when I try to rmmod ?
[07:00] <pitti> elopio: ah, you might have a different driver then
[07:01] <pitti> elopio: but the rmmod/modprobe trick only really works if it generally does connect, but starts failing after a few hours/days
[07:01] <pitti> if it never connects, it's not going to help that either
[07:01] <elopio> I'm trying upstart. And tomorrow I can try a utopic kernel.
[07:11] <elopio> pitti: yes, fails with upstart too. That's good to know.
[07:12] <elopio> tomorrow I'll keep trying stuff. Thanks for your help.
[07:13] <pitti> elopio: no worries; sleep well!
[07:13] <pitti> elopio: you said you changed your network from N to G, that's another variable of course
[07:13] <pitti> elopio: but if it worked before, trying older kernels is your best bet I think
[07:14] <elopio> yes, trying the old N network is easy actually. Good pointers, I'll update the bug with my findings.
[07:40] <pitti> fgimenez: for bug 1441023, is it enough for your setup to have this in git, or do you need that in vivid ASAP?
[07:41] <pitti> fgimenez: CI has a setup to build autopkgtest debs straight out of latest git and use that, thanks to vila
[07:42] <fgimenez> pitti, thanks it's not urgent, we have already forked the ssh-setup/adb script as we did in OTA
[07:43] <vila> elopio, pitti : hmm, now that you mention it, my laptop seem to just lose wifi access sometimes. My workaround is just to disable/enable wifi from the nm indicator
[07:45] <pitti> fgimenez: ack, then I'll just commit that for now, so that we don't have to fork the script long-term
[07:45] <vila> fgimenez, pitti : my gut feeling is that it should be easier than forking the ssh-setup/adb script, this happened twice for QA and once for CI lately. We're approaching the Refactoring Triangulation Golden Threshold ;)
[07:46] <pitti> it's too early for such fancy buzzwords!
[07:46] <vila> ;-D
[07:46]  * pitti goes to recalibrate the plasma phase inverters
[11:02] <nerochiaro> pitti: i am packaging a library that we eventually want to get into ubuntu, and i am working on autopkgtest tests. is there a way for me to have adt-run use a PPA to get the package that needs to be tested ? (totally new to autopkgtest, so pardon the ignorance)
[11:05] <pitti> nerochiaro: there is, but it seems much easier to build the package locally, and tell adt-run to use the local debs?
[11:06] <pitti> nerochiaro: i. e. case 6 or 7 in https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html (aka /usr/share/doc/autopkgtest/README.running-tests.html)
[11:07] <nerochiaro> pitti: oh, that is the piece of docs i was missing. reading it now, thanks
[11:07] <pitti> nerochiaro: if you really want to test a ppa, you could use somethign like --setup-commands "add-apt-repository ppa:foo/bar; apt-get update"
[11:07] <nerochiaro> pitti: sounds much easier with local packages
[11:07] <pitti> or --setup-commands "add-apt-repository ppa:foo/bar" -U if you also want to dist-upgrade to that PPA
[11:07] <pitti> nerochiaro: it for sure is, also faster turnaround
[11:31] <pitti> jibel: so http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd has lots of "test in progress" again which have long finished
[11:32] <pitti> jibel: can I just remove the stamp files like ./work/vivid-proposed_amd64_bluez.20150408-161109.state or do I need to update something else too?
[11:32] <pitti> like results.history or the individual result files like ./vivid-proposed_amd64_bluez ?
[12:25] <nerochiaro> pitti: is any way to be able to run graphical tests using adt-run ?
[12:25]  * pitti removes the stamp files and sees what happens
[12:26] <pitti> nerochiaro: sure; most packages which do that use xvfb; the ubuntu touch packages require running on a testbed which has mir and unity8 running
[12:26] <pitti> nerochiaro: xvfb is certainly the most generic way as it avoids any particular assumption about the testbed you run it on
[12:26] <nerochiaro> pitti: does xvfb support GL ?
[12:27] <pitti> nerochiaro: kind of; it uses mesa's software renderer
[12:27] <nerochiaro> pitti: let me give it a shot then
[12:28] <pitti> nerochiaro: note that for GL to work you need 24 bit color depth, the default is only 8
[12:28] <pitti> nerochiaro: so xvfb-run -s '-screen 0 1024x768x24' yourprogram ...
[12:29] <pitti> nerochiaro: check: xvfb-run -s '-screen 0 1024x768x24' glxinfo
[12:30] <pitti> without the -s it will just say "libGL error: No matching fbConfigs or visuals found"
[12:33] <nerochiaro> pitti: GL seems to work, but xvfb seems to be missing the RANDR extension. I tried adding -s '+extension RANDR' but it still complains
[12:34] <pitti> nerochiaro: ah, that's a rather old bug indeed -- it seems http://lists.x.org/archives/xorg-devel/2013-January/035114.html never got applied upstream :/
[12:34] <pitti> nerochiaro: that can still be done if you need it, but it's a bit more complicated to set up
[12:34] <pitti> nerochiaro: you can use the normal xorg-xserver and create an xorg.conf which uses the "dummy" driver; that does support (some) xrandr
[12:34] <pitti> Section "Device"
[12:34] <pitti>  Identifier "test"
[12:34] <pitti>  Driver "dummy"
[12:34] <pitti> EndSection
[12:35] <pitti> then just start X in the background, wait until the /tmp/.X11-unix/X* socket is there (depends on the $DISPLAY number you start the server under), and it should work
[12:36] <nerochiaro> pitti: as an aside, if the tests fail, is there any way to open a shell into the testbed to inspect things and figure out what is wrong ?
[12:36] <pitti> nerochiaro: adt-run -s
[12:36] <pitti> see "debugging options:" in --help
[12:36] <pitti> (or manpage)
[12:38]  * pitti bbl
[13:34] <dobey> jfunk, elopio: api qa call?
[14:37] <nerochiaro> elopio: i am having problems running unit tests that use qmlscene in virtualized environments. I was told you might be able to help, or know someone who might.
[14:38] <elopio> nerochiaro: are you using xvfb ?
[14:38] <nerochiaro> elopio: yes
[14:53] <elopio> nerochiaro: sorry, I was in a meeting.
[14:53] <elopio> nerochiaro: you are talking about unit tests with qmltestrunner?
[14:54] <nerochiaro> elopio: essentially yes
[14:55] <nerochiaro> elopio: one goal is to be able to run them as part of the package build (dg_auto_test) and the other as part of debian autopkgtest
[14:55] <nerochiaro> er, dh_auto_test
[14:56] <elopio> nerochiaro: and this is in the camera, right?
[14:57] <nerochiaro> elopio: no, it is for a library that we wrote that we are going to use in the camera: lp:qt-halide
[14:57] <elopio> nerochiaro: ok, I will try to run them with bzr bd.
[14:57] <elopio> nerochiaro: should I take trunk or a branch?
[14:58] <nerochiaro> elopio: at the moment dh_auto_test is overriden to do nothing so you will need to put that back
[14:58] <nerochiaro> elopio: trunk is ok for this purpose
[14:58] <nerochiaro> elopio: just running debuild -uc -us -b should be more than enough to show the problem once you have fixed the dh_auto_test so that it runs the tests
[14:59] <nerochiaro> elopio: but i guess bzr bd does the same underneath
[14:59] <elopio> nerochiaro: where do I get halide-lang from?
[15:00] <nerochiaro> elopio: ppa:phablet-team/ppa
[15:48] <elopio> nerochiaro: ok. I think you should copy most of this: http://bazaar.launchpad.net/~phablet-team/address-book-app/trunk/view/head:/tests/qml/CMakeLists.txt
[15:48] <elopio> after building it, I'm not sure which is the build dir that we need to use to find the compile qthalide though, so I haven't been able to get a successful run.
[15:49] <nerochiaro> elopio: that does not help me much. the only piece of info in there is that I need to call  xvfb with options -a -s "-screen 0 1024x768x24"
[15:50] <nerochiaro> elopio: which i was already doing
[15:50] <nerochiaro> elopio: do you build in the tree or out of the tree ? or do you build the packages and install them ?
[15:50] <elopio> nerochiaro: this adds a make test task
[15:51] <elopio> then without overwrite the dh test rule, the tests will run.
[15:51] <elopio> oh, well, actually the make test task might be in a previous CMakeFile
[15:52] <elopio> nerochiaro: http://bazaar.launchpad.net/~phablet-team/address-book-app/trunk/view/head:/CMakeLists.txt
[15:53] <elopio> see there enable_testing, USE_XVFB
[15:53] <nerochiaro> elopio: make check does run the tests
[15:55] <elopio> pitti: I switched the network to G, and it works. So the problem seems to be my laptop not handling N networks.
[16:12] <elopio> nerochiaro: ok, I'm getting now QXcbConnection: Could not connect to display
[16:12] <elopio> Aborted (core dumped)
[16:12] <elopio> is that your problem?
[16:13] <nerochiaro> elopio: that was the problem before using xvfb. I thought i had changed that already, sorry
[16:14] <nerochiaro> elopio: in fact I just found out that the issue I am having is related to the fact that in xvfb openGL is handled through mesa and there seem to be some things we are doing in qt-halide that don't play well with that
[16:15] <nerochiaro> elopio: let me investigate a bit more in that direction, and if I can't find a solution there I might ask for some more help next week
[16:16] <elopio> nerochiaro: cool, let us know how it goes. Please remember to ping the vanguard.
[16:17] <nerochiaro> elopio: ok.will do
[16:17] <nerochiaro> elopio: thanks for the help so far
[16:17] <pitti> elopio: ah, it sounded like you were switching from N to G (i. e. the older/slower/easier one)
[16:17] <elopio> pitti: that was a typo on the bug. I corrected that.
[16:19] <elopio> nerochiaro: your welcome. Though I didn't do much :) One thing I would like is for all the projects from your team to follow the same cmake style. Maybe discuss with renato about which one is better?
[16:19] <nerochiaro> elopio: i was not aware they were using a differen one
[17:48] <elopio> nuclearbob: you are vanguard right now.
[17:48] <nuclearbob> elopio: yes. Do I need to update the topic?
[17:49] <elopio> nuclearbob: no, I just wanted to confirm that I can relax :)
[17:49] <nuclearbob> elopio: yep, take a break :)
[17:49] <elopio> soon. Thanks man.
[18:28] <elopio> hey veebers
[18:28] <elopio> I have reviewed only one unity test. Sorry, I was surprised by a morning full of meetings.
[18:30] <veebers> elopio: no worries :-)
[19:40] <elopio> veebers: I'm done checking the 10 unity failures.
[19:41] <elopio> veebers: they are not new errors for sure. I'm not sure what to do. It might be that this release make them appear more often, which would be bad. Or it might just be that this was an unlucky execution.
[19:51] <veebers> elopio: right, hmm, Unfortunately I would suggest we make a gatekee . . .wait a sec gotta check something
[19:53] <veebers> elopio: so, um, _totally_ on purpose that latest run didn't even use the silo ppa. So I'll fire off a run now so we can compare it
[19:53] <veebers> (which is what I was going to suggest, just in the reverse order :-P)
[20:03] <elopio> veebers: hah, good trick.
[20:04] <veebers> elopio: yeah, sorry about that :-P
[20:11] <Letozaf_> balloons, hi
[20:29] <balloons> Letozaf_, hello!
[20:29] <Letozaf_> balloons, howzit ?
[20:30] <balloons> trying to get back into the flow of things.. always crazy
[20:30] <balloons> yourself?
[20:30] <Letozaf_> balloons, fine, thanks.
[20:30] <Letozaf_> balloons, If you got time I have some mp for calendar app and rssreader
[20:31] <Letozaf_> balloons, just to let you know, I imagine you are probably busy
[20:31] <Letozaf_> :)
[20:31] <balloons> Letozaf_, sure send me some links
[20:32] <Letozaf_> balloons, https://code.launchpad.net/~carla-sella/ubuntu-calendar-app/dayview-test-default-view/+merge/253760
[20:32] <Letozaf_> https://code.launchpad.net/~carla-sella/ubuntu-calendar-app/weekview-testing-stubs-completed/+merge/254495
[20:32] <Letozaf_> https://code.launchpad.net/~carla-sella/ubuntu-rssreader-app/unique-random-topic/+merge/253281