[05:16] <pitti> Good morning
[07:36] <pitti> jibel: so ATM we only need the run-adt-test bits for the dkms tests? or for something else, too?
[07:36] <pitti> I suppose we could move the trusty tests to adt-virt-qemu at some point
[07:38] <jibel> pitti, we only need the VMs created by auto-package-testing for dkms. I'll port it to use the same VMs than autopkgtest then we can drop auto-package-testing.
[07:38] <jibel> pitti, I think we can already move trusty tests to adt-virt-qemu
[07:39] <pitti> jibel: I suppose the dkms tests actually do modprobe-y stuff, so they really need QEMU?
[07:39] <pitti> jibel: right, want me to do that? (trusty autopkgtest)
[07:40] <jibel> pitti, yes, they must run in qemu to load the kernel under test
[07:40] <pitti> so for trusty, we need to update the trusty-setup-testbed job
[07:40] <pitti> but if jobs usually reconfigure themselves from the latest template in lp:a-p-t, what does currently keep them from doing that and using adt-virt-qemu?
[07:41] <pitti> oh, no britney I figure
[07:42] <pitti> things like http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-deja-dup/160/ were triggered manually
[07:42] <pitti> so we'd need to find a way to reconfigure all the trusty jobs
[07:43] <pitti> or use your "synthetic request" trick to poke (and run) them all
[07:44] <jibel> pitti, 2 options: resubmit everything or reconfigure with a script
[07:44] <pitti> jibel: but oh well, let's not rush this; if everything goes well, the jenkins-free solution will be around in a few months, and then this becomes obsolete
[07:47] <jibel> pitti, I updated trusty-setup-testbed to provision new style VMs
[07:47] <pitti> jibel: we still need the old-style ones as well for trusty-DKMS, right?
[07:47] <pitti> I suppose again on just one worker
[07:47] <jibel> pitti, yes on wanz only
[07:48] <pitti> how often do we run the ones on trusty?
[07:48] <pitti> I guess once a week or so would suffice for stables?
[07:48] <jibel> pitti, when there is a new image ie every day
[08:29] <davmor2> Morning all
[10:29] <jibel> pitti, I found one of the problem with the reconciliation. It's because not all the binaries built from a source package are installed so not all the requested dependencies listed in the state file are listed in *-packages files
[10:29] <jibel> For example one of the binary built from matplotlib is python-matplotlib-doc which depends on libjs-jquery. So libjs-jquery is in the list of dependencies of the state file.
[10:29] <jibel> But -doc is not installed during the test, this dependency is not pulled and doesn't appear in any -package file.
[10:29] <jibel> Previously we generated the list of candidates for all the binaries of the package under test even if they were not installed.
[10:30] <pitti> jibel: ah, so in the scenario above this essentially means that we don't have a test for python-matplotlib-doc
[10:30] <jibel> pitti, yes
[10:31] <pitti> jibel: should we build this package/version thing as a separate output list in autopkgtest then, or can we interpret the result above as "no test for libjs-jquery reverse deps"?
[10:35] <jibel> pitti, if we interpret as 'no test for libjs-jquery' it'd mean that the result is undefined and we cannot decide whether to promote the package or not. OTOH if we build this pkg/vers as a separate output but the package is not really installed we'll promote the reverse deps without any test of this dep.
[10:35] <pitti> jibel: but it seems so far we also just did the latter case, i. e. record the version of all binaries although they haven't actually been tested?
[10:36] <jibel> pitti, exactly.
[10:36] <pitti> why undefined? it's result shouldn't have any effect on the overall result, i. e. either "PASS" or more clearly "SKIP" or "N/A"
[10:37] <pitti> jibel: so using testpkg-version isn't enough for this as sometimes binaries are lagging behind or even have a different version than the source, right?
[10:38] <jibel> pitti, undefined because the reverse dep might be uninstallable for example or not working with this particular dependency
[10:38] <jibel> right
[10:40] <pitti> jibel: so how did we catch this in the old system? (we didn't, right?)
[10:40] <jibel> pitti, we didn't, the new way of doing things is just revealing a problem that always existed
[10:42] <jibel> pitti, we can probably report the result as 'N/A' when the dependency is not installed and add it to the list of valid states for promotion
[10:43] <pitti> jibel: ok, so I understood that right; so it would have the same effect as calling it "PASS", just more clearly
[10:43] <jibel> this way we won't block promotion if not all the binaries are tested and it will be visible in excuses and won't put it under the carpet
[10:43] <pitti> sounds great
[10:46] <jibel> in summary, an upload of libjs-jquery will trigger a test of matplotlib, libjs-jquery won't be in any *-package and test marked as 'N/A', and in excuses we'll see libjs-jquery/matplotlib/N-A/Valid Candidate
[10:47] <pitti> *nod*; and in the past we had python-matplotlib-doc's version in matplotlib's .result file and thus considered that as PASS
[10:47] <pitti> (or FAIL if it actually failed)
[10:49]  * pitti kicks back more tests which failed due to qemu crashes
[10:49] <pitti> I can see these poor worker and their HDDs nodes sweat like mad :)
[10:49] <pitti> err, "worker nodes and their HDDs"
[11:14] <pitti> *nnng* hash sum mismatch
[14:38] <elopio> rhuddie or alesage: I need a review here, please:
[14:38] <elopio> https://code.launchpad.net/~elopio/ubuntu-autopilot-tests/initctl_env_from_toolkit/+merge/219384
[14:40] <rhuddie> elopio, I'll take a look
[14:42] <elopio> thanks.
[15:39] <elopio> davmor2: mi camera is not working. I touch the capture button and nothing happens.
[15:39] <elopio> have you seen that?
[15:39] <davmor2> elopio: nope works fine here
[15:40] <elopio> :(
[15:40] <elopio> I'll report a bug and ask on the mailing list.
[16:50] <elfy> balloons: what testing gets done by ubuntu for assistive tech? we've got a hanging chad in our settings testcase to test it for some reason - but I'd like to know if it get's a test anywhere at all - eg autopilot
[16:50] <balloons> elfy, assistive tech afaik is manual test only
[16:54] <elfy> balloons: mmk - can't see it on any of the ubuntu tests
[16:55] <balloons> elfy, we have a screen reader install test. Beyond that, what are you asking about?
[16:55] <balloons> I did that test this last cycle as well, it's a bit better than before :-)
[16:55] <elfy> sticky keys - that type of thing
[16:55] <elfy> balloons: I've still got that image testcase bug in my head - not forgotten it
[16:56] <elfy> I've just got to make sure all our manual tests are ok first
[17:21] <elopio> robotfuel: are you helping renato with update of the tests to the new design?
[17:24] <robotfuel> elopio: he was still using the page object pattern the last time I looked. he accidently overwrote his ContactListPage.
[17:24] <elopio> robotfuel: I'm just wondering if I should offer him my help, or you were already working with him.
[17:24] <elopio> robotfuel: we are talking about a hacking session on malta where we update the tests with the devs.
[17:25] <elopio> it seems renato is the only one that started earlier.
[17:25] <robotfuel> He was all set the last time I checked, but I should follow up.
[17:28] <elopio> robotfuel: ok. Tell me if you are already too busy, I might be able to spare some time.
[17:34] <robotfuel> elopio: yes I am working on the address-book-app flakyness if you want to follow up that would be good.
[17:34] <robotfuel> elopio: was he still asking for help?
[17:34] <elopio> robotfuel: no, I haven't talked to him.
[17:34] <elopio> this was a discussion with bfiller where he said renato has already started.
[17:38] <renato> hi bfiller
[17:38] <bfiller> renato: had a discussion with elopio and QA today about making sure we use the new SDK emulators when reworking our address book tests
[17:39] <bfiller> renato: I know you've made progress here, thought we could work on it with QA next week
[17:39] <renato> bfiller, yes I am using the new emulators, for the headers
[17:40] <bfiller> renato: ok good
[17:40] <bfiller> that's what I thought
[17:41] <bfiller> renato: are we using any other custom emulators or is everything from sdk enulatores?
[17:41] <elopio> renato: yes, just wanted to tell you that if you need help, robotfuel and I can give a hand.
[17:41] <renato> elopio, robotfuel, this is my MR https://code.launchpad.net/~renatofilho/address-book-app/new-header/+merge/218437
[17:42] <renato> elopio, robotfuel, the only problem now is that jenkins is not upgrading the SDK package before run the tests
[17:42] <renato> but fginther is trying to fix that
[17:43] <renato> bfiller, we have some specific emulators for address-book-app
[18:11] <elopio> I need to renew my driving license.
[18:12]  * elopio will be back.
[18:15] <elopio> I changed my mind.
[18:15]  * elopio stays.