[12:38] <knome> balloons, hullo... do you use the stylish extension?
[12:42] <knome> balloons, wakey wakey! :P
[14:43] <elopio> brendand: replied back to you in my serial branch. Please take a look and give me your opinion.
[14:53] <dobey> pitti: hey. any idea why line 18 in this log happens, given the command used on line 1? http://pastebin.ubuntu.com/9902391/
[14:55] <brendand> elopio, yeah i suppose that would be ok
[14:56] <brendand> elopio, approved it
[14:57] <elopio> ping jibel: if there is only one device connected, would you like the sanity script to use it without asking for the serial?
[15:02] <jibel> elopio, ideally yes
[15:05] <jibel> elopio, like adb or the ssh/adb backend of autopkgtest
[15:08] <elopio> jibel: do you want that as part of the card "run sanity while more than one device is connected", or for that card it's ok to always ask the serial, and we should add a different story for the case when only one device is connected?
[15:09] <jibel> elopio, do you need a card for every option?
[15:10] <jibel> elopio, that's part of the "multiple devices support" story. Add a line in the description of this card.
[15:11] <elopio> jibel: we don't need a card for every option. We just need to define better the acceptance criteria, so we write only the minimum amount of code to meet it.
[15:11] <elopio> that case of only  one device connected is something we didn't discuss. We'll make it as part of this card.
[15:20] <pitti> dobey: sorry, was in a meeting
[15:20] <pitti> dobey: not immediately; I mostly tested the session setup script in LXC, although it shouldn't make too much difference (at least with the vivid version of autopkgtest)
[15:21] <pitti> dobey: but /dev/uinput not being available would also totally break it
[15:22] <pitti> dobey: so, bug report appreciated (this needs some more time to investigate, and probably the ubuntu-touch-session script needs to be updated to the current reality)
[15:23] <dobey> pitti: ok
[15:24] <dobey> pitti: also, does anyone actually use the feature of running multiple tests for multiple things with the same command line? i'm pretty sure jenkins doesn't, and i don't know why anyone would do so locally
[15:26] <pitti> dobey: I don't know really; we don't in CI; it's just an ancient CLI which I wouldn't like to break without a good reason
[15:28] <dobey> pitti: well, "nobody uses it and it makes using adt-run, and its code, that much more complex" is a pretty good reason to me :)
[15:28] <pitti> dobey: heh, yes :)
[15:28] <pitti> dobey: when I saw it the first time I was quite stumped, too
[15:29] <dobey> pitti: i don't know if this is a good enough bug report, but here you go: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1415514
[15:30] <dobey> pitti: honestly, since i've started trying to add autopilot tests to autopkgtest configs, i've had nothing but problems with both :-/
[15:31] <pitti> dobey: so, one of these days I'd like to create a new CLI called "autopkgtest" which replaces adt-run, and thus get rid of that weird name too :)
[15:32] <dobey> pitti: oh, and btw, https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html mentions "apt-ro" as a setup-command several times, but in reality it's actually "ro-apt" :)
[15:32] <pitti> dobey: yeah, most people just run AP tests on real iron or the emulator; the setup script was quite a hack and doesn't get used/maintained a lot; there is bug 1376423 to put that into a proper place and fix up to be closer to what happens in reality
[15:33] <balloons> ohh.. heh, this floats back to that lovely bug
[15:33] <dobey> ah
[15:33] <pitti> dobey: oh, several? I just see it once (thanks for pointing out, fixing!)
[15:34] <brendand> elopio, none of the existing config tests create a fake config?
[15:34] <balloons> dobey, you should also mention the need to pass args in order, although as I said I believe there is a reason
[15:34] <dobey> pitti: oh, i thought i saw it several times. maybe it's just the once then :)
[15:34] <pitti> dobey: committed
[15:34] <dobey> balloons: yes i already complained about that above :)
[15:34] <dobey> balloons: the reason is "an old feature nobody actually uses" :)
[15:36] <dobey> i'm hoping we can get rid of all the autopilot tests in the click scope at least, now that there is a test harness for scopes api
[15:40] <balloons> dobey, I'm glad you and pitti finally synced up :-)
[15:40] <pitti> dobey: bug good enough> sounds easy enough to reproduce, so should be fine; thanks
[15:41] <dobey> ok, cool
[15:58] <elopio> brendand: fake config contents, yes. Take a look in my branch.
[16:20] <elopio> alesage: brendand: how would you prefer the serial handling? Ask for a serial if more than one device is connected, or ignore the number of devices connected, if the user doesn't provide a serial, assume there's only one.
[16:21] <brendand> elopio, i think it only needs to be as smart as existing tools
[16:21] <alesage> elopio, maybe the first seems better but what do you think?
[16:22] <alesage> elopio, for the second design, which would you run the tests on?
[16:32]  * alesage is not sure if he picked the right answer
[16:37] <elopio> first seems better, maybe too smart as brendand says.
[16:37] <elopio> alesage: I don't get your second question.
[16:37] <brendand> elopio, it's indeed 'better', but do we really need to be smarter than the tools we wrap?
[16:38] <alesage> elopio, I'm going to table my second question
[16:38] <elopio> brendand: not if it is not required by the customer.
[16:38] <brendand> elopio, i say:
[16:38] <brendand> - if one device is attached, use it
[16:39] <brendand> - if more than one is attached, use the specified serial
[16:39] <brendand> - if no serial is specified, exit with an error
[16:40] <alesage> endif
[16:40] <elopio> brendand: I don't like your first bullet, because I might have connected the wrong device. I specify the serial, and I want to run the tests there. If that serial mismatches the connected one, IMO it should exit with an error.
[16:40] <brendand> elopio, i almost typed that - yeah if it's not too hard we could check for that too
[16:41] <elopio> it's actually harder to check for what you want.
[16:41] <elopio> so, specifying no serial should succeed only if there's only one device connected.
[16:41] <alesage> that's fair
[16:41] <alesage> yes that was my q: on which would your run int hat case?
[16:42] <brendand> elopio, do you know about this failure in the wizard test: http://paste.ubuntu.com/9919877/ ?
[16:42] <elopio> brendand: can you get a screenshot out of it?
[16:42] <elopio> I'd say, the pin keyboard did not appear.
[16:43] <brendand> elopio, how do i hack it to just run one test?
[16:45] <brendand> elopio, ah i can modify __all__
[16:45] <elopio> brendand: yup.
[16:46] <brendand> elopio, so to list the tests can't we just print __all__?
[16:46] <brendand> elopio, i suppose there are the imported tests as well
[16:46] <elopio> brendand: no, because there are other tests defined in debian/tests
[16:47] <brendand> elopio, and is it hard to list those?
[16:47] <elopio> brendand: no, just weird.
[16:47] <elopio> we have some tests in our branch, and some other come from the packaging of our branch.
[16:48] <elopio> maybe, we should move the list of external tests out of debian/tests. From there just call a method: get me the tests.
[16:48] <brendand> elopio, i think so
[16:49] <brendand> elopio, there should be one method of finding all the tests to run
[16:49] <elopio> brendand: I think it would be good, also to keep the code in debian/tests as small as possible.
[16:52] <elopio> jibel: there are some cards about checking images and their thumbnails. How would you like to see the checks for those? Simple like checking that the source is an image file and that it's not all black, or some smarter check that the displayed image matches the source with accuracy?
[16:53] <jibel> elopio, check that the thumbnail is not only one color, we don't really care about accuracy, since it's a thumbnail it'll lose information anyway.
[16:54] <elopio> jibel: ack. What about the images opened in the gallery?
[16:56] <jibel> elopio, check it is not black or a single color. That's usually the result when there is a bug in a codec.
[16:56] <jibel> or the thumbnailer
[16:56] <elopio> jibel: ok.
[19:18] <elfy> balloons: so then ... assuming that bug 1325801 sits at triaged till this time next week - what do we regarding info pre the globla jam
[19:18] <elfy> currently we point people at a tool that sometimes works still :)
[19:30] <balloons> elfy, I discovered disks fails in vivid btw
[19:30] <balloons> made a bad image for me.. I used dd
[19:47] <elfy> mmm
[19:48] <elfy> so basically - use a windows tool ...
[19:49] <elfy> balloons: what fail was it - something other than one we've already seen?
[19:51] <balloons> wouldn't go past the boot. I still have it, need to reboot and collect the error
[19:52] <elfy> k
[19:53] <elfy> I've used disks a few times since then in vivid - worked with ubuntu/kubuntu/xubuntu 2 or 3 times and even manjaro
[19:53] <balloons> but yes, I thought we said we would writeup something for disks as the alternative
[19:55] <elfy> perhaps include dd as well - what command to recommend though
[19:58] <elfy> balloons: does it need to be actually on wiki? or would a pad do - what do you think ?
[19:58] <elfy> hopefully it's just a temporary situation
[21:27] <balloons> elfy, it doesn't HAVE to be on the wiki, though I don't see why it can't be