| === salem_ is now known as _salem | ||
| === chihchun_afk is now known as chihchun | ||
| pitti | Good morning | 05:16 |
|---|---|---|
| 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:36 |
| 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:38 |
| 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:39 |
| 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:40 |
| pitti | oh, no britney I figure | 07:41 |
| 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:42 |
| pitti | or use your "synthetic request" trick to poke (and run) them all | 07:43 |
| 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:44 |
| 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:47 |
| 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 | 07:48 |
| davmor2 | Morning all | 08: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:29 |
| 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:30 |
| 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:31 |
| 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:35 |
| 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:36 |
| 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:37 |
| jibel | pitti, undefined because the reverse dep might be uninstallable for example or not working with this particular dependency | 10:38 |
| jibel | right | 10:38 |
| 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:40 |
| 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:42 |
| 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:43 |
| 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:46 |
| 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:47 |
| * 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" | 10:49 |
| pitti | *nnng* hash sum mismatch | 11:14 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === _salem is now known as salem_ | ||
| 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:38 |
| rhuddie | elopio, I'll take a look | 14:40 |
| elopio | thanks. | 14:42 |
| === roadmr is now known as roadmr_afk | ||
| === DanChapman_ is now known as DanChapman | ||
| === qwebirc591238 is now known as slickymasterWork | ||
| === salem_ is now known as _salem | ||
| 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:39 |
| elopio | :( | 15:40 |
| elopio | I'll report a bug and ask on the mailing list. | 15:40 |
| === roadmr_afk is now known as roadmr | ||
| 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:50 |
| elfy | balloons: mmk - can't see it on any of the ubuntu tests | 16:54 |
| 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:55 |
| elfy | I've just got to make sure all our manual tests are ok first | 16:56 |
| === _salem is now known as salem_ | ||
| elopio | robotfuel: are you helping renato with update of the tests to the new design? | 17:21 |
| 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:24 |
| 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:25 |
| elopio | robotfuel: ok. Tell me if you are already too busy, I might be able to spare some time. | 17:28 |
| 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:34 |
| 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:38 |
| 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:39 |
| bfiller | renato: ok good | 17:40 |
| bfiller | that's what I thought | 17:40 |
| 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:41 |
| 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:42 |
| renato | bfiller, we have some specific emulators for address-book-app | 17:43 |
| elopio | I need to renew my driving license. | 18:11 |
| * elopio will be back. | 18:12 | |
| elopio | I changed my mind. | 18:15 |
| * elopio stays. | 18:15 | |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!