[00:22] <veebers> alesage: sorry missed the ping
[00:23] <veebers> alesage: "move it over"? As in take it out of the debian/tests folder and make it another module?
[00:25] <alesage> veebers, isn't that something we desire?  i.e. to live under ubuntu_sanity_tests?
[00:25] <alesage> facilitates testing at the least
[00:26] <veebers> alesage: yes it is, just wanted to confirm what your intentions are
[00:26] <alesage> veebers, MP forthcoming :)
[00:33] <veebers> elopio: you still around?
[00:34] <alesage> veebers, https://code.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/move-sanity/+merge/248325 <= elopio
[00:35] <veebers> alesage: which card does this correspond to :-)?
[00:52] <alesage> veebers, to one I'll create right now
[00:55] <alesage> veebers, I see you have reviews for me but I'm EOD, will take up tomw if they remain :)
[00:55] <veebers> alesage: ack, that would be appreciated (as I'm currently at my WIP limit ;-))
[00:56] <alesage> veebers, and with only one non-veebers card available for review ;)
[00:57] <veebers> alesage: heh, ack looking now
[03:58] <elopio> veebers: I got a ping earlier. Do you still need me?
[04:02] <veebers> elopio: hey, just had a question re: the blocked card and to ask if you could review the cards I hve in to-review
[04:03] <elopio> veebers: :)
[04:03] <elopio> for your pending reviews, I think I'm just missing to give them a run.
[04:03] <veebers> elopio: aight sounds good. I'm just about to head off to Code Craft. Probably won't be back on tonight
[04:04] <elopio> I dist-upgraded earlier and now phablet-network doesn't work. Let me workaround that, and I'll get your cards approved before my EOD.
[04:04] <elopio> veebers: ok, see you tomorrow.
[04:04] <veebers> let me know if you have any other issues with those branches to fix. And I'll hit it in my morning
[04:04] <veebers> o/ night
[06:28] <fgimenez> hi thomi
[08:32] <thomi> hi fgimenez - I accidentally left my IRC client on
[12:50] <doug5> balloons, hey, you there?
[13:03] <elfy> doug5: usually a bit later - Pacific time or something I think
[13:13] <doug5> elfy, shit, right
[14:39] <elopio> alesage: brendand_: a reminder that we are missing a review here: https://code.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/webbrowser-test-using-system-helpers/+merge/248080
[14:39] <elopio> it would be nice if one of you can get to it so we have it merged before veebers arrives anad he can get a new card.
[14:43] <brendand_> elopio, approved and top-approved
[14:44] <elopio> brendand_: thank you!
[14:44] <elopio> I will get to yours in a moment.
[14:48] <rhuddie> elopio, hey. did the sanity tests ever get run on emulator?
[14:49] <elopio> rhuddie: my emulator breaks my machine. I have to rseiub every time I try to run it.
[14:49] <elopio> so, unknown. I haven't been able to give it a try.
[14:51] <rhuddie> elopio, ok thanks. I am getting 'evdev.uinput.UInputError: "/dev/uinput" cannot be opened for writing'
[14:52] <elopio> rhuddie: hum, can you please leave that as a comment on the leankit card about running in an emulator?
[14:53] <rhuddie> elopio, sure. I am not totally sure my environment is correct, but everything esle seems to be working. I'll add the comment to the card.
[14:54] <elopio> rhuddie: and if you have some time, ask rsalvetti or sergiusens about it. We might need a new input type for autopilot, or they need to fix evdev on their side.
[14:54] <elopio> rhuddie: if you don't have time, don't worry. We'll do it as part of that card when jibel puts it in the top.
[14:55] <rhuddie> elopio, sure. I'm investigating running the automated sanity tests as part of silo landing process (emulator was easiest target to start with)
[14:56] <elopio> rhuddie: and that means writable image too, right?
[14:56] <rhuddie> elopio, for that I also raised a bug about being able to specify additional external tests more easily: https://bugs.launchpad.net/ubuntu-sanity-tests/+bug/1417556
[14:56] <rhuddie> elopio, yes, it would do.
[14:57] <elopio> rhuddie: the writable part needs a new card on the board, or a bug for sure. Please add one with all the info you can find.
[14:58] <rhuddie> elopio, I will do that
[14:58] <elopio> rhuddie: for that bug, what we can give you on friday is to first run the full sanity, and then run additional tests.
[14:59] <rhuddie> elopio, the purpose of the bug was to add a new method which could easily be called from a silo script, where you specify some additional tests that you want to run for a specific silo
[14:59] <rhuddie> elopio, as you need to specify the dependencies as well as the test ids in 2 different files
[15:00] <elopio> rhuddie: the dependencies bit sounds harder, but nice to have. And being able to run the internal and external tests + extra, with a single command is something I have no idea how to do. Maybe adding an argument --extra-tests.
[15:01] <elopio> rhuddie: if you need any of these requests by friday the 20th, please make sure to discuss about them with jibel. Today we will meet to define the top priorities for next sprint.
[15:02] <elopio> rhuddie: and thanks for all this, it's really useful to have somebody giving it a try.
[15:02] <rhuddie> elopio, ok. I don't have idea on time scale right now. just trying to find out what work is needed. I'll discuss.
[15:02] <rhuddie> elopio, yeah, its quite interesting to be using it as an end-user :)
[15:03] <rsalveti> I know I tested autopilot before on the emulator and it worked fine
[15:03] <rsalveti> not sure if there is any new specific thing we need to do now
[15:04] <rhuddie> rsalveti, good to know thank you. I'll keep investigating what is going on.
[15:17] <rhuddie> elopio, I was thinking that for adding new external tests and dependencies, a new "add_external_test()" method would be called first and would directly modify the testsuite_list and control file before running the tests as normal? that way no new command options needed.
[15:32] <dobey> pitti: can we *PLEASE* break the multiple tests feature of adt-run that nobody actually uses? the positional arguments thing is really annoying
[15:34] <pitti> dobey: I'm certainly open to that, but I can't know whether anyone is using that; this should at least get some discussion on the ML, perhaps CC'ing debian-devel@
[15:34] <pitti> (plus, it's quite some work, so it ceratinly won't happen overnight)
[15:36] <dobey> pitti: i just spent way too much time switching between utopic and vivid images with proposed enabled or not, only to discover that all the 404 issues were because the update and proposed were not actually being used, because i put the -U and --apt-pocket arguments after --setup-commands
[15:36] <dobey> :-/
[15:36] <pitti> dobey: well, -U and --apt-pocket are both setup-commands, so these will always stay order dependant
[15:37] <dobey> that makes no sense
[15:38] <dobey> and the documentation clearly doesn't specify that they must appear *before* the --setup-commands argument
[15:41] <elopio> rhuddie: I don't know about modifying the control field. That sounds like something we shouldn't do.
[15:41] <pitti> dobey: well, they don't :) they will be executed in the order you give them
[15:42] <pitti> dobey: so if your setup commands depend on having -proposed, you need apt-pocket and -U before; if enabling dist-upgrade depends on your setup-commands, you have -U after; etc.
[15:42] <rhuddie> elopio, I agree it seems a bit dubious... :)
[15:43] <elopio> rhuddie: I'm not quite sure the right way to do it is with a single adt-run call. Maybe one adt-run call, + one phablet-test-run will make things a little less messy.
[15:43] <elopio> rhuddie: but anyway, put all your ideas and input in the card. When it's time to write it, we'll research and discuss about it.
[15:44] <dobey> pitti: that is even more crazy :)
[15:45] <dobey> pitti: and i don't see why ubuntu-touch-session would depend on those being before
[15:45] <dobey> or why it would affect the argument parsing
[15:47] <rhuddie> elopio, yes. I was just thinking whether it should all need to be done in the sanity suite, or kept separate. In terms of reporting it would be easier to have it all as one suite, but as you say, phablet-test-run would also be a good option.
[15:48] <elopio> rhuddie: the tests for the silo should be specified in their debian/tests
[15:48] <pitti> dobey: well, it's the same as specifying --setup-commands twice -- these are for sure ordering dependant
[15:48] <elopio> rhuddie: so it's not like a random list of tests that you would like to run. We have a way to discover them and their dependencies.
[15:48] <elopio> of course, that's not happening now. But should.
[15:49] <dobey> pitti: but then surely -U must come after --apt-pocket (though that requirement doesn't exist)
[15:49] <pitti> dobey: right
[15:49] <dobey> though honestly, i don't see how this could ever really be usable without -U
[15:49] <dobey> even without --setup-commands or --apt-pocket
[15:50] <elopio> rhuddie: that might be easier. Receive a list of additional autopkgtests to run.
[15:50] <pitti> dobey: indeed I think --apt-pocket should do an apt-get update automatically
[15:50] <pitti> dobey: so that you can use it withoutu -U
[15:51] <dobey> pitti: right, but the only time not doing "apt-get update" is going to work, is if all the dependencies are already installed
[15:51] <dobey> which is basically never the case with qemu
[15:52] <pitti> dobey: oh, I pretty much always use it without -U locally, as it takes effing long and isn't needed when my VM is fresh :)
[15:52] <rhuddie> elopio, only problem with running all of them might be time constraints? it might be that we want to run a couple of high priority tests, instead of entire suites. But that's not clear right now.
[15:53] <pitti> dobey: it is true that currently just using --apt-pocket by itself doesn't make much sense without also running apt-get update (that's the issue I mentioned above)
[15:53] <dobey> pitti: well, if you're using lxc/chroot, then it's easy enough to have stuff already installed
[15:54] <pitti> dobey: I'm not entirely sure whether enabling -proposed (and apt-get update) *without* apt-get dist-upgrade makes a lot of sense; probably very little
[15:54] <pitti> dobey: so I'm ok with disallowing that use case, and make --apt-pocket imply -U
[15:54] <dobey> pitti: but even so, the ordering of such arguments as pased to adt-run should not be order-dependent. the execution of such things inside the VM may be though
[15:57] <dobey> pitti: so, i think any apt-related args (-U and --apt-pocket) should always be executed prior to any --setup-commands arguments, in the VM, regardless of where they appear in the arguments list to adt-run, and any shell scripts passed with --setup-commands should probably be executed in the order passed (because they are arbitrary scripts and requiring adt-run to know what they are doing would be excessive)
[15:57] <pitti> dobey: that means you could never use --setup-commands to enable e. g. a PPA or other third-party source
[15:57] <pitti> but we need that
[15:58] <pitti> or you couldn't use -U and had to spell it out
[15:58] <pitti> and that actually is current behaviour that people do use and depend on
[15:59] <dobey> pitti: it does. but it means your setup-commands should be doing an update as well, if they are touching apt stuff
[15:59] <pitti> right, which is precisely -U; -U is just a pre-defined --setup-commands
[15:59] <dobey> pitti: if you have a setup-commands script which adds an apt repository, but doesn't do apt-get update, then you're doing it wrong
[16:00] <pitti> well, it's --setup-commands "add-apt-repository foo" -U
[16:00] <dobey> pitti: that is an implementation detail though. exposing such an implementation detail via argument ordering, is bad :)
[16:00] <pitti> sure you could argue that we take away the -U shortcut for this case, but as I said that's something people do use
[16:08] <dobey> pitti: well, i'd say make it superfluous i guess, and deprecate it, telling people to do "add-apt-repository foo && apt-get update" instead. but as it is right now, i am finding it incredibly painful to use. :-/
[16:09] <pitti> dobey: add-apt-repository foo && (apt-get --quiet update || (sleep 15; apt-get update)) 2>&1'
[16:09] <pitti> very convenient to type :)
[16:09] <pitti> well, probably not necessary that often for a local run, but very important for CI
[16:10] <pitti> (all hail the dreaded apt hash sum mismatches..)
[16:12] <jderose> pitti: as something changed that's causing the hash mismatch to happen for frequently?
[16:13] <jderose> er, can't type
[16:13] <pitti> jderose: they've been a problem for years really
[16:13] <pitti> jderose: the above (or more clever variations thereof) has been copied into our buildds, Launchpad, and other places
[16:13] <jderose> maybe i'm just doing more automated stuff that get's hung up by it. happens a lot using the internal tools system76 uses for updating our images
[16:14] <pitti> we've had tons of spurious autopkgtest CI runs before I added that
[16:16] <jderose> pitti: gotcha, thanks
[16:19] <dobey> pitti: well, put it in a shell-script "smart-add-repository foo" :)
[16:32] <dobey> anyway, need to get lunh. bbiab
[17:37] <brendand_> elopio, i followed up on that MP
[18:19]  * alesage is doing some reviews
[18:20] <slickymasterWork> elfy, FYI http://cdimage.ubuntu.com/ is up now
[18:21] <elfy> not here
[18:22] <balloons> it's no longer up for me, but was yesterday. I snagged an image then :-)
[18:22] <balloons> elfy beat me too mentioning those issues on the list; thanks!
[18:24] <slickymasterWork> there's still a huge delay loading it, but it's up
[18:26] <balloons> I tried to clean up the milestones on the tracker.. wow was it a big list
[19:00] <alesage> elopio I too get the webbrowser failure, investigating, evidently not the same as the bug though
[19:01] <elopio> thanks alesage.
[19:07] <alesage> elopio, I stand corrected, same err as reported in bug for moi for webbrowser test
[19:07] <elopio> alesage: which bug are you talking about?
[19:08] <alesage> elopio, https://bugs.launchpad.net/ubuntu-sanity-tests/+bug/1408723
[19:08] <elopio> alesage: yup, same here.
[19:08] <elopio> reproduced in trunk, so nothing to do with brendan's branch.
[19:28] <elopio> brendand_: you need to resubmit your branch, to trunk.
[19:30] <brendand_> elopio, ! oh wth happened there. no wonder the jenkins tests didn't run
[19:36] <brendand_> elopio, alesage - you need to redo your approvals: https://code.launchpad.net/~brendan-donegan/ubuntu-sanity-tests/wizard_remove_connection/+merge/248440
[19:36] <brendand_> elopio, alesage - and a top approve
[19:51] <elfy> balloons: seems that sometimes you can actually download via the http links - try and do anything useful like zsync and it has a hissy fit
[23:14] <wxl> in lieu of my developers being awake, is it possible this could be fixed with a rebuild? sure is strange that it's only affecting one particular image and has no consistency across type of image or arch https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1417784
[23:46] <alesage> elopio, veebers another review pretty please https://code.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/move-sanity/+merge/248325
[23:51] <veebers> alesage: can do shortly