| veebers | balloons: fyi for your bug you filed, I've filed this against python3-xlib: https://bugs.launchpad.net/ubuntu/+source/python-xlib/+bug/1432889 | 00:04 |
|---|---|---|
| ubot5 | Ubuntu bug 1432889 in python-xlib (Ubuntu) "Creating Display() fails with "Xlib.error.DisplayConnectionError: Can't connect to display ":0": b'No protocol specified\n"" [Undecided,New] | 00:04 |
| veebers | ubuntu-qa: anyone know who to talk to re: looking at tha above bug? ^^ | 00:05 |
| ToyKeeper | Hmm, weird. Has been ages since I used pyxlib. | 00:11 |
| ToyKeeper | I think the last time was when I wrote something to type in my 2fa codes for me. | 00:12 |
| elopio | ping veebers. I need to go to the gym, and bbl. | 01:05 |
| elopio | but I made a quick hack to get started. | 01:06 |
| elopio | https://code.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/break_testbed/+merge/253137 | 01:06 |
| elopio | I think that changing the revert command is not the right way to do it, but so far I haven't found a different way to do it. | 01:07 |
| veebers | elopio: ack, I'll take a look in a little bit. Enjoy the gym, feel the burn :-) | 01:09 |
| veebers | elopio: you're not back are you? | 04:18 |
| elopio | veebers: I am. | 04:18 |
| veebers | elopio: nice, so I'm looking at your link for break_testbed. Trying to try some things out. Is there a way to nicely get adt-run to use the version of adb-reboot-to-recovery script? | 04:20 |
| veebers | i.e. I'm getting 'don't have the revert-full-system' capability etc. Just want to tinker a little bit | 04:20 |
| elopio | veebers: /home/elopio/workspace/canonical/autopkgtest/run-from-checkout -d -s -B --unbuilt-tree=. --output-dir /tmp/output --- ssh -s ./adb-reboot-to-recovery | 04:20 |
| veebers | elopio: ah of course | 04:20 |
| veebers | the -s arg just melded into the background for me :-) | 04:21 |
| elopio | that's what I'm using. You probably won't need the run-from-checkout, that's to use the unreleased adt-run version. | 04:21 |
| veebers | ack | 04:21 |
| veebers | elopio: thanks | 04:21 |
| elopio | veebers: np. I'm starting to give it a try here. | 04:21 |
| veebers | elopio: coolio, I wanted to try a couple of things out to get an understanding of the code and how adt-run works before making suggestions | 04:22 |
| elopio | veebers: that would be awesome. Without martin, I'm getting lost on the code. | 04:24 |
| elopio | veebers: is there something I can do in my morning tomorrow about the autopilot failures? | 04:25 |
| veebers | elopio: I'm about to fire off an email to the team, but I err we need to find out who to ping re: the bug that I filed. | 04:26 |
| veebers | elopio: this bug here: python3-xlib: https://bugs.launchpad.net/ubuntu/+source/python-xlib/+bug/1432889 | 04:26 |
| ubot5 | Ubuntu bug 1432889 in python-xlib (Ubuntu) "Creating Display() fails with "Xlib.error.DisplayConnectionError: Can't connect to display ":0": b'No protocol specified\n"" [Undecided,New] | 04:26 |
| elopio | veebers: I see the last people to touch that package were pitti and mdeslauries | 04:26 |
| veebers | elopio: right, I saw pitti but didn't dig deeper yet | 04:26 |
| veebers | elopio: re: the adt-run code it can be very easy to get lost in. | 04:26 |
| veebers | elopio: re: bug is this the same person? https://launchpad.net/~mdeslaur | 04:30 |
| elopio | veebers: yes, him. | 04:31 |
| elopio | I can ping him tomorrow morning to see if he has a clue of who can help us with that. | 04:31 |
| elopio | I read the python-xlib code and also got lost. | 04:31 |
| veebers | elopio: awesome thank you. I probably should have tried earlier this morning | 04:31 |
| elopio | veebers: you did a good bunch of things. I only retried the jenkins run :) | 04:32 |
| veebers | elopio: heh, I set a break point followed it down until it errored, did that a couple of times to pinpoint it | 04:32 |
| veebers | then I realise it's setting up a request to the x server and then it's not obvious from that point :-P Hence the bug | 04:32 |
| elopio | veebers: I've just pushed a new rev to my break_testbed branch, with a wait_booted that it wwas missing. | 04:32 |
| veebers | I don't know if the fix will be in that package as it doesn't look like python3-xlib has changed, more than likely something underneath it | 04:33 |
| veebers | elopio: ah cool, I'm not to sure if I triggered it properly. How do you get the stdout of the ssh script to come to screen? I only see the output of adt-run | 04:33 |
| elopio | veebers: I'm not sure what you are looking for. I'm running with: | 04:35 |
| elopio | /home/elopio/workspace/canonical/autopkgtest/run-from-checkout -d -s -B --unbuilt-tree=. --output-dir /tmp/output --- ssh -s ./adb-reboot-to-recovery | 04:35 |
| elopio | and I get a whole lot of stuff. | 04:35 |
| elopio | if you put a print in the adb-reboot-to-recovery, I think it should be printed. | 04:35 |
| veebers | do you get details from adb-reboot-to-recovery? I'll try again, but I see heaps of output, none from that script | 04:36 |
| elopio | I see things like this: | 04:36 |
| elopio | adt-run: DBG: sending command to testbed: revert | 04:36 |
| elopio | Performing factory reset, this will take a minute... | 04:36 |
| elopio | I think it's being executed also after the selftests, which is wrong. | 04:37 |
| veebers | hmm | 04:37 |
| veebers | elopio: Oh I have family dinner in a bit. If I don't get around to mentioning it I think that what you have suggested is fine for a first run (It might be all we can do) but I don't think we can rely on --revision=-1 as we may have changed how many revisions we're at | 04:38 |
| veebers | so I perhaps an envvar set by the wrapper script to inform what revision the device was flashed at initially | 04:39 |
| elopio | veebers: right, this was just a quick hack. | 04:39 |
| elopio | it sounded hard to get the current version from the phone and pass it to the adb script, so I just didn't do it this evening :) | 04:40 |
| veebers | ^_^ | 04:43 |
| veebers | elopio: if you wanted to query the device for the revision you would have to do it before any test was run as it would change to anything from that point onwards | 04:44 |
| veebers | also, current revno: adb shell system-image-cli -i | grep "current build number"| sed -e "s/.*:\ //" | tr -d '\r' | 04:46 |
| elopio | veebers: yes. And we can write that info to a file, like we do with the reboot target. | 04:49 |
| elopio | veebers: we'll also need the channel. | 04:50 |
| elopio | I think that's the downside to this approach. With your branch, we just need to reexecute the command that flased the phone initially. | 04:52 |
| elopio | I'm reading something interesting on the source code. If we pass a setup command, it is reexecuted before the revert. | 04:53 |
| veebers | true. Well, at least we have 2 possible work-arounds at this stage :-) | 04:53 |
| elopio | or that's what it seems. | 04:53 |
| veebers | oh? | 04:53 |
| veebers | heh | 04:53 |
| elopio | so if the setup command is ubuntu-device-flash, it might do what we want. | 04:54 |
| elopio | I'll give that a try tomorrow. | 04:54 |
| veebers | elopio: if that works that'll be really cool. We'll need a way to setup the setup command properly with, as you say, rev and channel | 04:55 |
| elopio | veebers: no, scratch that. The setup commands are run in the testbed. | 04:58 |
| veebers | ah, ugh. Worth a try though | 04:59 |
| veebers | elopio: right, I'm off for the night, have a good one :-) | 05:13 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === txspud is now known as txspud|ORS | ||
| === chihchun is now known as chihchun_afk | ||
| nuclearbob | elopio: where do I need the -B? the python3 -m command line, or adt-run, or somewhere else? | 13:41 |
| nuclearbob | ubuntu-qa: elopio suggested my build failure meant I need to add -B, but I'm not sure where. adt-run? python3 -m ubuntu_sanity_tests.command_line? | 13:51 |
| rhuddie | nuclearbob, I believe that would be to adt-run, e.g. adt-run -B --unbuilt-tree=. --- ssh -s adb | 13:52 |
| nuclearbob | rhuddie: thanks, I'll try that | 14:00 |
| elopio | good morning. | 14:15 |
| nuclearbob | ubuntu-qa: I want to run a test that involves rebooting a phone, performing some actions, disconnecting the phone, waiting a while, reconnecting, then doing the whole process again. Is there a way to express all of this as an adt test, or do I need to just use adt for the actions on the phone and use a wrapper for everything else? | 14:24 |
| === chihchun_afk is now known as chihchun | ||
| rhuddie | nuclearbob, adt-run tests run on the testbed, but it has --setup-commands option which may be useful to you | 14:34 |
| rhuddie | nuclearbob, you could also look at our sanity suite which is launched through a call to python, which does setup and cleanup actions, then calls adt-run itself: https://bazaar.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/trunk/view/head:/ubuntu_sanity_tests/command_line.py | 14:36 |
| rhuddie | nuclearbob, also, the reboot support for adt-run is at the bottom of this page: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst | 14:38 |
| nuclearbob | rhuddie: awesome, thanks. I was looking for a test in the sanity suite which includes a reboot, but my grep-fu is failing. Do you know of one I can look at? | 14:50 |
| rhuddie | nuclearbob, there aren't any in sanity that reboot, but ubuntu-ota-tests is using it. see http://bazaar.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/trunk/view/head:/debian/tests/ubuntu_ota_tests/hooks.py | 14:56 |
| nuclearbob | rhuddie: great, I'll look at that. Thanks! | 14:56 |
| nuclearbob | rhuddie: I think since I'm rebooting as part of actions that are external to adt, I don't need to use the adt reboot logic, and I can handle that in my python wrapping stuff. If you or someone else on ubuntu-qa disagrees, we can discuss it further, but I think this is all I need to implement what I'm working on. Thanks! | 15:01 |
| rhuddie | nuclearbob, no prob, sounds sensible to me | 15:02 |
| elopio | rhuddie: It's not clear if your last comment on apply-update was an approval. | 15:04 |
| rhuddie | elopio, there was one other comment about adding the timeout parameter for apply_update() method | 15:12 |
| rhuddie | fgimenez, what do you think about adding the timeout parameter to apply_update() ? | 15:12 |
| fgimenez | rhuddie, i'm not sure if we need it, if it's a noop it will be very fast, if it has to actually apply the upgrade, how much should the timeout be? | 15:14 |
| rhuddie | fgimenez, the default is 600 seconds, but I see it can be over-ridden using $SYSTEMIMAGE_REACTOR_TIMEOUT. This would just be another way to specify a custom timeout. | 15:18 |
| rhuddie | fgimenez, I did something similar with the download test here: http://bazaar.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/wait-for-download/view/head:/debian/tests/ubuntu_ota_tests/services.py#L164 | 15:21 |
| rhuddie | fgimenez, but I agree for this case it should complete quickly so not a big issue | 15:22 |
| fgimenez | rhuddie, anyway it doesn't hurt to have one, is 60 seconds enough as the timeout value for applying the update? | 15:24 |
| rhuddie | fgimenez, I would say that is fairly short for an update, perhaps 3 mins? At least by having it as a parameter to apply_update() it can be easily specified by the caller. | 15:26 |
| fgimenez | rhuddie, ok, done | 15:30 |
| rhuddie | fgimenez, thanks :) | 15:30 |
| fgimenez | rhuddie, ty! :) | 15:31 |
| elopio | fgimenez: I'm having a problem with the noop test: http://paste.ubuntu.com/10615956/ | 15:50 |
| elopio | running on the phone. | 15:50 |
| fgimenez | elopio, you have the latest source right? | 15:51 |
| fgimenez | i'm getting http://paste.ubuntu.com/10615969/ ... | 15:54 |
| fgimenez | elopio, that timeout exception may be raised because of the latest changes, does it take too long (~3min) when executing test_apply_update_noop? | 15:56 |
| rhuddie | fgimenez, that was the issue I had when running that test previously. It was timing out, but previously it was a 10 min timeout. | 16:26 |
| elopio | fgimenez: yes, it takes 3 minutes before failing. | 16:27 |
| elopio | I have an old revision, so can it be that the cancel is not working? | 16:27 |
| fgimenez | elopio maybe, i haven't been able to see it after reflashing, perhaps some of the status is being kept | 16:28 |
| elopio | fgimenez: can you try with an old version? | 16:29 |
| fgimenez | elopio, of the code you mean? | 16:30 |
| fgimenez | elopio, the only change in the code has been adding the timeout as a parameter, rhuddie was getting the error after the default timeout before this change | 16:32 |
| fgimenez | elopio, if you reflash all goes good, it seems that somehow the testbed reaches a state in which ApplyUpdate times out... | 16:34 |
| elopio | fgimenez: sorry, In a meeting. | 17:00 |
| elopio | it passed now: test_apply_update_noop (ubuntu_ota_tests.selftests.test_services.ServicesTestCase) ... ok | 17:00 |
| fgimenez | elopio, np, i'm trying to run it with an update already downloaded | 17:01 |
| fgimenez | elopio, in that case the update is applied, the selftest crashes with BrokenPipeError because of the reboot, but no timeout | 17:03 |
| fgimenez | elopio, another scenario could be calling ApplyUpdate while downloading, but CancelUpdate should do its work in that case | 17:05 |
| === chihchun is now known as chihchun_afk | ||
| elopio | barry: I'm almost sure I'm doing something stupid in here: https://code.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/dbus-upgrade/+merge/253265 | 19:24 |
| elopio | can you please take a look? | 19:24 |
| barry | elopio: do you still want me to look at your dbus-upgrade branch? | 20:06 |
| Letozaf_ | balloons, hi | 20:33 |
| balloons | Letozaf_, hello | 20:34 |
| Letozaf_ | balloons, have you got 2 min to take a look at a bug report on rssreader app, just to see if you have idea what the problem could be? | 20:35 |
| balloons | Letozaf_, link? | 20:36 |
| Letozaf_ | balloons, https://bugs.launchpad.net/ubuntu-rssreader-app/+bug/1431365 | 20:36 |
| ubot5 | Ubuntu bug 1431365 in Ubuntu RSS Feed Reader App "Tests fail at warning dialog "A topic with that name already exists"" [High,New] | 20:36 |
| Letozaf_ | balloons, maybe just a hint :) | 20:37 |
| balloons | Letozaf_, ohh.. it's creating a topic in a non-clean env | 20:37 |
| balloons | I think the workaround popey suggested is sufficent. Generate a unique random topic name (based on datetime; uuid, something) and you can avoid it | 20:38 |
| balloons | Though you will build up topics ;-) | 20:38 |
| balloons | so fixing the test should be as simple as making the topic non-hardcoded | 20:39 |
| Letozaf_ | balloons, ok thanks I will try, but the weired thing is that on my desktop the tests do not fail and also on Jenkins | 20:40 |
| Letozaf_ | balloons, shouldn't they fail also there ? | 20:40 |
| Letozaf_ | balloons, https://code.launchpad.net/~carla-sella/ubuntu-rssreader-app/just_for_test/+merge/253122 | 20:41 |
| balloons | Letozaf_, not neccassarily | 20:41 |
| Letozaf_ | balloons, ok | 20:41 |
| Letozaf_ | balloons, thanks :) | 20:42 |
| barry | veebers: you wanted to pair on refactoring the code into a native debian package? when is a good time for you? | 20:42 |
| balloons | Letozaf_, :-) It should still pass after you finish your mp, heh, but should work in CI then too :-) | 20:43 |
| Letozaf_ | :) | 20:44 |
| veebers | barry: When suits you? I can go make a coffee now and be free for an hour or two | 20:47 |
| barry | veebers: sure, let's connect on the hour. i have 1h until eod, but i think i can go longer today if needed | 20:48 |
| veebers | barry: sounds good | 20:49 |
| veebers | elopio: hey thanks for chasing up on that bug, much appreciated | 21:00 |
| elopio | barry: veebers: I think that we need the package to execute the reboot to recovery with dbus. | 21:01 |
| elopio | that might be the problem of my branch, ubuntu_ota_tests is not on the python path so systemimage can't find the hook. | 21:01 |
| elopio | please push the branch when you have something working, so I can give it a try. | 21:01 |
| elopio | veebers: all your gratitude should go to mdeslaur. It took only a couple of minutes of my life, he did the rest. | 21:02 |
| veebers | elopio: ack, will thank him for the fix | 21:02 |
| veebers | elopio: I don't understand your comment re: reboot with dbus, what's this in relation to? | 21:03 |
| elopio | veebers: look at l104 of the diff: | 21:04 |
| elopio | https://code.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/dbus-upgrade/+merge/253265 | 21:04 |
| barry | elopio: that makes sense | 21:05 |
| elopio | for systemimage to find ubuntu_ota_tests, it must be in the pythonpath. | 21:05 |
| elopio | barry: however, I'm not sure if that's the only problem. This is what I'm seeing: | 21:06 |
| elopio | http://paste.ubuntu.com/10617492/ | 21:06 |
| barry | and the best way for it to be on sys.path is to be installed as a python3 package :) | 21:06 |
| elopio | and the test times out after three minutes. | 21:06 |
| barry | elopio: i was just testing your branch on my device and i also see the timeouts | 21:06 |
| veebers | elopio: ah, that's clearer | 21:07 |
| elopio | anyway, I need to have lunch and take a break. | 21:08 |
| barry | cool. veebers, i'm ready when you are | 21:08 |
| elopio | if I'm lucky, you will have the package ready and that will magically fix the update :) | 21:08 |
| veebers | barry: sweet, should we hangout? | 21:12 |
| barry | veebers: sure | 21:12 |
| veebers | barry: lets reuse the standup | 21:12 |
| veebers | barry: one sec mic issues | 21:13 |
| barry | veebers: https://wiki.debian.org/Python/LibraryStyleGuide | 21:14 |
| barry | veebers: lp:~barry/ubuntu-ota-tests/packaging | 21:19 |
| veebers | wth, all of a sudden cats make a huge ruckus running about etc. I go through to the lounge and they're just sitting there on the couch like nothing has happened :-\ | 21:40 |
| barry | veebers: we have to rename the debian/tests scripts. see r13 | 21:41 |
| veebers | ack | 21:41 |
| barry | veebers: r14 is lintian source and binary happy | 21:43 |
| veebers | barry: nice. So the @ doesn't seem to be needed unless I'm missing something. I can update the selftest so that it will work (was making assumptions on location) and it runs | 21:55 |
| barry | veebers: nice | 21:55 |
| veebers | barry: actually if I do put the @ there it errors, can't find python3-ubuntu-ota-tests:armhf | 21:57 |
| barry | veebers: did adt-run build the package? | 21:58 |
| barry | it'll have to build it and install it on the device i think | 21:58 |
| veebers | yeah right, no it states that build not needed. Perhaps I'm passing the wrong args to adt-run | 21:59 |
| veebers | ah I think I am, one sec | 21:59 |
| veebers | barry: so I'm a little confused. So it appears to work without @ as I'm presume it copies the directory across. Using @ (and not using -B arg) it attempts to build the binaries, but fails when it 404s trying to satisfy deps for building. | 22:03 |
| veebers | so, do we need @ or are we ok with just whatever it's doing without it | 22:03 |
| barry | veebers: gosh, i'm not sure. can you push your branch so i can try it here? | 22:04 |
| veebers | barry: heh, well my branch consists of removing a bunch of stuff so that only one test will run, I'll push it anyway :-) | 22:05 |
| veebers | barry: branch here: lp:~veebers/+junk/running-adt-ota | 22:07 |
| * barry tries | 22:07 | |
| barry | veebers: what adt command are you using? | 22:08 |
| veebers | barry: ah sorry distracted, one mo | 22:08 |
| veebers | barry: this one triggers the build attempt: 'adt-run --unbuilt-tree=. --- ssh -s adb' adding -B doesn't: 'adt-run -B --unbuilt-tree=. --- ssh -s adb' | 22:09 |
| barry | veebers: cool, trying it | 22:10 |
| barry | veebers: so, with @ and no -B, i get ImportError complatining about ubuntu_ota_tests.selftests. is that what you get? | 22:15 |
| barry | *complaining | 22:15 |
| veebers | barry: no with @ and no -B I get.. wait, let me dbl check | 22:17 |
| === chihchun_afk is now known as chihchun | ||
| veebers | barry: It attempts to build then fails because apt is out of date. It might get further if I r/w and apt-update but I'm not sure we want to rely on that | 22:19 |
| barry | i thought maybe adding an explicit Depends on system-image-common would do the trick but it doesn't | 22:19 |
| barry | veebers: weird! | 22:19 |
| veebers | barry: I think this flash is a couple of days old so archive has moved on (I suspect) | 22:20 |
| * barry wishes unittest test's discovery wouldn't swallow the actual import error | 22:20 | |
| veebers | so hmm, perhaps it won't be such an issue if we're expecting people to flash just before use. Although we can see that error straight after a flash too | 22:20 |
| veebers | barry: so after an apt update I get further but it's building the package on the device itself, which is installing a bunch of stuff and taking a while. If we're going to use the wrapper script to call this once per test this will take all day | 22:27 |
| barry | veebers: i think adt has a way of using already built binary packages, which would be fine in this case because we're arch-independent. so you could build the debs once on the host and then just let adt copy those to the device | 22:28 |
| veebers | barry: that would be good. Any idea on how to get it to build on the host? I would have thought arch: any would be the key | 22:30 |
| barry | veebers: i don't think you get adt to build on the host. just build the binary package on the host like normal and then tell adt to use the built packages. the former is just `bzr bd -S && sbuild blah.dsc` but i forget the syntax for the latter | 22:31 |
| barry | veebers: it's dinner time here. i'm going to take a break, but will try to check back a little later. or we can rendezvous again tomorrow | 22:33 |
| veebers | barry: sounds good. Enjoy. I'll try start a little earlier so we can have more overlap time if needed. But don't feel you need to wait for me :-) | 22:34 |
| veebers | barry: thanks for the pairing | 22:34 |
| barry | veebers: sounds good! cheers | 22:34 |
| brendand | elopio, is there a reason you defined __all__ in ubuntu_ota_tests/__init__.py? | 22:59 |
| brendand | elopio, unless there's a reason there's not really any need to, it just causes all modules to be loaded when you import the top level one, which is a pain | 23:00 |
| veebers | brendand: I think it was me that did that due to believing it was best practice | 23:03 |
| veebers | the idea being that the package only exporting what wee define as public. It shouldn't be too much of an issue as the modules shouldn't really do anything when loaded | 23:05 |
| brendand | veebers, ok - for some reason i thought elopio. bzr blame would have been worth it :) | 23:05 |
| veebers | But I'm not against removing the __all__ there if it is causing grief | 23:05 |
| brendand | veebers, well all the imports will run as a minimum | 23:05 |
| veebers | heh, I almost let Leo take the blame for it :-) | 23:06 |
| brendand | veebers, it means you need to have e.g. python3-autopilot as a dependency even if your code doesn't use it | 23:06 |
| veebers | yeah right, but they shouldn't be running much or any code, just definitions | 23:06 |
| veebers | brendand: hmm, that's a really good point | 23:06 |
| brendand | veebers, so unless defining __all__ enables something, i would like to remove it | 23:06 |
| veebers | brendand: go nuts, I can't think of anything off the top of my head that means we need it. if we do need it we can put it back, but better | 23:07 |
| veebers | also, as you've shown it can be a pain | 23:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!