[06:24] <mgedmin> correct me if I'm wrong, but testdrive in ubuntu 14.04 is broken to the point of unusability and I should try to use bzr trunk, yes?
[07:08] <elfy> balloons: ftr - new image - still see bug 1370707
[07:08] <elfy> not had time to check in hardware though
[07:18] <mgedmin> so I was wrong and testdrive can be wrestled to submission in trusty
[13:41] <balloons> elfy, bug 1370707 is still in new image yes?
[15:04] <elfy> balloons: I'll double check - got to do a hardware test shortly
[15:10] <balloons> ack, ty ty
[15:11] <elfy> I think I might possibly have hit a key to early in vm this morning
[15:30] <elfy> balloons: I has plymouth \o/
[15:34] <balloons> elfy, :-)
[15:34] <elfy> rushing this morning I suspect
[16:22] <pitti> plars: good news! bug 1383878
[16:22] <pitti> plars: i. e. dpkg-source now works in "temp unpack" mode, test deb available (see bug)
[17:06] <wxl> we just had a world respin?
[17:06] <wxl> khave a link handy phillip ?
[17:07] <wxl> argh wrong channel :/
[17:07] <phillip> wxl: ?
[17:34] <balloons> wxl, yes world respin
[17:35] <knome> doesn't the world spin continuosly without stopping anyway?
[17:35] <balloons> knome, it's been suggested that indeed this is in the case
[17:35]  * balloons wonders how is it we don't fall off anyways?
[17:36] <wxl> balloons: full disk encryption or what's the deal?
[17:36] <knome> you just haven't been close enough to the edge
[17:36] <balloons> wxl, yes, that's been fixed. I'm mailing the list
[17:37] <wxl> balloons: ok, well release is tomorrow so get your rear in gear XD
[17:39] <balloons> wxl, lol, it's done my friend
[18:41] <wxl> we're rebuilding again balloons ???
[18:43] <wxl> :)
[18:43] <wxl> that's what i meant rafaellaguna
[18:43] <wxl> i was just so freaking mad
[18:43] <ianorlin> wrong channel
[18:43] <ianorlin> wxl
[18:44] <wxl> ianorlin: no
[18:44] <wxl> ianorlin: yes
[18:44] <wxl> why am i so good at this????
[18:44]  * wxl bashes head against keyboard
[19:06] <Letozaf_> balloons, hi
[19:07] <Letozaf_> balloons, I used pitti's autopkgtest to run also clock app click package and have the same error as yesterday, should I go on to report a bug or have you guys made other changes meantime ?
[19:10] <elfy> evening Letozaf_  :)
[19:10] <Letozaf_> elfy, hello :-)
[19:18] <pitti> Letozaf_: which "same error"?
[19:19] <Letozaf_> pitti, hello, well if I run :  adt-run ubuntu-clock-app/ --click com.ubuntu.clock_3.2.158_armhf.click --- ssh -s adb
[19:19] <pitti> Letozaf_: oh -- it seems you have a password other than 0000, so your test doesn't have root privs
[19:19] <Letozaf_> pitti, I get: Cannot install /tmp/adt-run.ixZeib/com.ubuntu.clock_3.2.158_armhf.click: Cannot acquire permission to write to /opt/click.ubuntu.com; either run as root with --user, or use "pkcon install-local" instead
[19:19] <Letozaf_> adt-run [21:18:00]: ERROR: unexpected error: click install failed with status 1
[19:19] <Letozaf_> pitti, oh! so my password should be 0000 :P
[19:19] <Letozaf_> pitti, ok I will change it :P
[19:19] <pitti> Letozaf_: so you need to specify it by appending "-- -p s3kr1t"
[19:20] <Letozaf_> pitti, oh I see thanks a lot
[19:20] <Letozaf_> pitti, I will try again
[19:20] <pitti> Letozaf_: but it's a good point, if we don't have root we shuldn't install the click for all users
[19:20] <pitti> Letozaf_: so bug report is appreciated for that case
[19:20] <pitti> Letozaf_: as for most other things we don't really need root privs
[19:21] <Letozaf_> pitti, ok so I will also report the bug
[19:21] <Letozaf_> pitti, thanks
[19:21] <pitti> Letozaf_: thanks! in the meantime -p should work
[19:21] <pitti> Letozaf_: TBH I'm mostly testing running tests for already installed clicks
[19:22] <Letozaf_> pitti, I don't as I have to test the tests that I am writing
[19:22] <pitti> Letozaf_: so thanks for being the guinea pig for testing local clicks :) (I do have automatic tests for that, but not for a r/o env aparently)
[19:22] <pitti> Letozaf_: yes, but the tests are in the source, not in the .click
[19:22] <Letozaf_> pitti, my pleasure, it's also kind of fun
[19:23] <pitti> Letozaf_: i. e. your command runs the tests from the local ./ubuntu-clock-app/
[19:23] <Letozaf_> pitti, oh! got it
[19:24] <pitti> Letozaf_: i. e. if you don't change the .click, just the test, you could do: adt-run ubuntu-clock-app/ --click com.ubuntu.clock --- ...
[19:24] <Letozaf_> pitti, now I understood
[19:24] <Letozaf_> pitti, thanks that's very useful
[19:24] <pitti> Letozaf_: I should still fix that bug, of course, as a developer usually wants to test a locally changed .click against the existing or locally changed tests
[19:26] <Letozaf_> pitti, yes right
[19:27] <pitti> Letozaf_: also, --click clock has a nice ring to it!
[19:28] <Letozaf_> pitti, :)
[19:38] <Letozaf_> pitti, fyi bug 1384417
[19:46] <Letozaf_> \o/ it's working :-P
[19:46] <Letozaf_> thanks pitti
[19:54] <pitti> Letozaf_: btw, if you test on an actual phone, can you make sure you are using autopkgtest 3.6git1 (utopic today) or http://people.canonical.com/~pitti/tmp/autopkgtest_3.6pitti2_all.deb ?
[19:54] <pitti> Letozaf_: 3.6 from utopic takes painfully long
[19:55] <pitti> plars: speaking of which, did you get my ping about this?
[19:55] <pitti> plars: (fixed the dpkg-source thingy)
[19:55] <plars> pitti: I saw, is there a new package I can grab?
[19:55] <plars> oh
[19:55] <plars> nm
[19:55] <plars> :)
[19:55] <pitti> plars: yeah, there's also a link in the bug
[19:55] <Letozaf_> pitti, balloons gave me that link yesterday and today I am using http://people.canonical.com/~pitti/tmp/autopkgtest_3.6pitti2_all.deb  :P
[19:55] <plars> pitti: I had seen the bug but not a link to the built package
[19:56] <plars> pitti: I'll try it shortly here. I did a bit of experimenting with creating a very minimal dep8 test in an unbuilt directory and running it, and it worked at least
[19:56] <plars> pitti: I need to sort out how to make it provide useful results is all
[20:00] <pitti> plars: i. e. test things like "my testbed is in a state that I expect"?
[20:01] <pitti> plars: the things that come to my mind is doing the d-bus call to check whether unity is unlocked, and some pidof system-settings-bla to check that the wizard isn't running, and that you have a default route?
[20:02] <pitti> plars: or better, drop the default route and add a test Depends: pmount or something; if that's available (in the tmp path), then network and package (fake) install obviously work
[20:02] <plars> pitti: I think so, I need to reinstall and start from scratch - I briefly saw that ssh error again earlier today but on the second run it passed (new cable too) so I was wondering if it's similar to the thing you saw that had to run twice
[20:03] <pitti> plars: no, for me that wasn't an ssh error, it looked like a genuine testfailure
[20:03] <pitti> plars: i. e. I saw calculator starting, stopping, starting etc., but no events in calculator
[20:03] <pitti> and thus test failures
[20:07] <pitti> Letozaf_: FTR, as far as I remember you still can't install a click even for one user only without root privs, so fixing that might be difficult
[20:08] <Letozaf_> pitti, ok
[20:11] <plars> pitti: for tests that require autopilot, if autopilot is not in the image already, istr you saying that it would still work somehow? does it pull it in as a test dependency without actually having to install autopilot-touch and dependencies?
[20:13] <pitti> plars: yes, that's the "unpack into /tmp" mode
[20:13] <plars> pitti: great!
[20:13] <pitti> plars: any test Depends: will be downloaded, unpacked into /tmp/, and then the test runs with $PATH, $LD_LIBRARY_PATH, $PYTHONPATH etc. set accordingly
[20:14] <pitti> plars: of course that's much less robust than actually installing them (for example I haven't yet covered udev rules)
[20:14] <plars> right
[20:14] <pitti> plars: but for python modules and the like it should be good enough
[20:14] <pitti> plars: it obviously fails for packages which are looking for plugins in /usr/lib/ etc.
[20:15] <pitti> but oh well, don't run them on a r/o image then :)
[20:19] <plars> pitti: well, libpng passed (build test is all it has of course), but unfortunately it looks like none of the packages have the dep8 tests in them (unity8, ubuntu-ui-toolkit, webbrowser-app, etc)
[20:19] <plars> so I can't test it easily with something autopilot-y
[20:19] <pitti> plars: yeah :/
[20:19] <plars> pitti: but we know libpng wasn't working yesterday, and it is now
[20:19] <pitti> plars: well, you can cheat a bit
[20:19] <plars> I should try a clean system too though, mine is installed rw at the moment
[20:20] <pitti> plars: oh? that's actually surprising; it should fail on gcc not finding libraries
[20:20] <pitti> plars: ah yes, then it actually ran apt-get install
[20:20] <thomi> yay! autopilot!
[20:20] <thomi> sorry
[20:20]  * pitti ^5s thomi
[20:21] <pitti> plars: so, you can create a local fake source package (with pretty much just debian/tests/) which depends: on e. g. unity8 and other test deps, and then put the autopilot call into Test-Command:
[20:21] <pitti> plars: while it's customary to put tests for binary package X into the source package of X this isn't a technical requirement :)
[20:21] <Letozaf_> hey guys anyone testing Ubuntu Desktop amd65 ISO on Virtualbox ? on my PC Virtualbox crashes
[20:22] <pitti> oh, where can I buy an amd65? :-)
[20:22] <Letozaf_> :(
[20:22] <Letozaf_> amd64
[20:22] <Letozaf_> wrong typing
[20:22] <Letozaf_> :P
[20:22] <pitti> Letozaf_: davmor2 says the same thing
[20:23] <plars> pitti: right, but that seemed to work before even - running out of an ubuilt tree
[20:23] <pitti> plars: yes, sure (that has always worked)
[20:23] <Letozaf_> pitti, oh fine, well not fine, but at least someone confirms my problem
[20:24] <pitti> works quite ok in kvm
[20:25] <Letozaf_> so it's Virbualbox
[20:26] <elfy> I'll check our's quickly now
[20:27] <pitti> you want "-vga vmware" with kvm, BTW (otherwise the background image is quite broken; it's not that important, but looks weird)
[20:31] <Letozaf_> my virtualbox crash has been uploaded automatically so I do not think thers is a bug to be reported, right ?
[21:16] <pitti> vila: des bonnes nouvelles ! http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=0dc5fe
[21:16] <pitti> vila: should I build a .deb for you, or do you run out of git?
[21:17] <vila> pitti: yeehaa !
[21:18] <vila> pitti: the tmux... funnily enough you *were* suspicious about it ...
[21:18] <pitti> vila: no, it's not tmux, it's ssh's connection sharing muxer
[21:18] <vila> ha, another one then, ack
[21:19] <vila> so, to get the fix, the process is to pull, recipe, etc, I'll do it right now
[21:19] <pitti> vila: ah right, your magic PPA
[21:19] <pitti> vila: I'm building a .deb, too
[21:20] <vila> pitti: s/magic/gating/ ;)
[21:27] <pitti> vila: (in case you need: http://people.canonical.com/~pitti/tmp/autopkgtest_3.6pitti3_all.deb)
[21:27] <vila> pitti: thanks
[21:32] <wxl> elfy: you around?
[21:33] <elfy> just about for a short while longer
[21:33] <wxl> can anyone not solely with ubuntu explain their reasoning not to use the desktop encryption testcase that k/ubuntu uses? http://iso.qa.ubuntu.com/qatracker/testcases/1451/info
[21:33] <wxl> elfy ^
[21:34] <elfy> well ...
[21:34] <elfy> the reason is just that we don't - never have afaik
[21:36] <wxl> figured as such, thanks :)
[21:36] <knome> afair there was a time when that option was dropped from the GUI
[21:36] <knome> so it was only available from the alternate installer for a while
[21:37] <elfy> given we have enough trouble getting test on what we already have I'd not be happy about adding anything
[21:39] <knome> practically any option that the ubiquity installer provides is tested if it's tested on one flavor
[21:40] <knome> that's a very b&w way to look at it, but there are hardly any reasons why some option would be broken in a flavor but not the other
[21:56] <vila> pitti: eeerk: https://launchpadlibrarian.net/187924725/buildlog_ubuntu-precise-i386.autopkgtest_3.7-0~966~ubuntu12.04.1_FAILEDTOBUILD.txt.gz
[21:56] <vila> pitti: from https://code.launchpad.net/~canonical-ci-engineering/+recipe/autopkgtest-phase-0
[21:56] <vila> pitti: only the precise one really matter though
[21:57] <vila> pitti: but I guess you don't want the trusty one to fail either ;)