[03:34] <elopio> veebers: how are you?
[03:36] <veebers> elopio: better than this morning. although at this point in time I'm looking forward to EOD-ing :-)
[03:36] <veebers> elopio: how are you?
[03:37] <elopio> veebers: yes, you should take some rest. I'm fine, thanks.
[03:37] <veebers> elopio: ack, will do, just clearing up a couple of things so that I feel like I've actually done something today :-)
[03:38] <elopio> veebers: we decided that we will use your branch as the base for the rest. And we also talked about selftests.
[03:38] <elopio> veebers: so if you don't mind, I will change your example test a little to make it a selftest.
[03:38] <veebers> elopio: while you're here do you mind taking a quick look at the updated autopilot MP
[03:38] <veebers> elopio: no worries, I've just updated that branch right now
[03:39] <veebers> I was just about to put in a comment in that I've made a change that pulls in autopilot as a depend, but I'm not sure we want that (esp. for the purpose that I'm using it)
[03:39] <veebers> I don't think the core test scripts should depend on autopilot
[03:40] <elopio> veebers: looking at it.
[03:40] <veebers> thanks
[03:41] <elopio> veebers: on the ota branch, is there a reason to define the __all__ ?
[03:44] <veebers> elopio: (I'm failing to find a link now but) I understand this is best practice where __init__ only provides access to public modules. using the __all__ we could have a private module _secret_stuff that's not exported by default by the package.
[03:45] <elopio> veebers: ok. I was just wondering as I never know when to use it and when not to.
[03:45] <elopio> veebers: the test in the autopilot branch is really cool
[03:45] <elopio> I'll kick jenkins again, because it has a weird error.
[03:45] <veebers> elopio: oh rats, I hadn't even checked up on that, cheers
[03:45] <elopio> veebers: and I don't mind about adding the autopilot dependency in there. Anyway we will have plenty of autopilot stuff in the branch.
[03:46] <veebers> elopio: the use of __all__ might be overkill here but it's easy enough to setup with no cost
[03:46] <elopio> it would be good to upstream the Eventually matcher to testtools though.
[03:46] <veebers> elopio: right, for the tests, but I'm not sure if we'll want autopilot stuff in the support scripts there. I'm sure that barry has mentioned in the past he would like to supply support scripts that help with the ota tests and the ota tests themselves can consume them
[03:47] <veebers> elopio: re: the autopilot test, it kind of sucks to make it a functional test, but we need to start the process as it's due to the import processing phase.
[03:48] <veebers> plus it was the easiest thing to do right away. I'll take some moments tomorrow to make sure we can't make it a unit test.
[03:48] <elopio> veebers: if it becomes a problem, we can copy the Eventually. I really don't mind about it.
[03:48] <elopio> veebers: and I really like it being functional. I think making a real test with a real skip with a real config value is nice.
[03:49] <veebers> elopio: ack, just adds time to running the test suite ;-)
[03:49] <veebers> elopio: also you'll see that I responded to your query on the taskbar intro doc
[03:50]  * veebers is reminded to update the standup journal before EOD
[03:50] <elopio> I'll check.
[03:50] <elopio> veebers: I'm going to eat, and then I'll come back to take a better look at your stuff. You should just go to bed. You are wasting a sick day :)
[03:52] <veebers> elopio: heh, I've fine :-) Thanks for the concern.
[05:47] <pitti> balloons, elopio: hm, I thought I fixed the seeds, where do you see this? today's images should be ok
[05:47] <elopio> pitti: sorry, I don't know what you are talking about.
[05:48] <pitti> elopio: that's why I meant to type "elfy", sorry
[05:48] <elopio> :)
[05:54] <elopio> pitti: I don't know how to make a pull request for autopkgtest with the reboot target and command. Should I send you the patch?
[05:54] <pitti> elopio: sure, sounds good (git format-patch origin..), perhaps attach it to a bug?
[05:55] <elopio> pitti: a bug reported in the debian bts?
[06:00] <pitti> elopio: as you with, but a Launchpad bug seems easier
[06:01] <pitti> elopio: curious package list parsing error, I've never seen that; thanks for the report
[06:01] <elopio> pitti: I'll do it tomorrow, I still find git a little confusing.
[06:02] <elopio> pitti: yes, it's weird. I don't get why it's returning the current version. It happens only for the common package.
[06:03] <elopio> pitti: that package will be in the image soon, so the bug is not blocking us.
[06:03] <pitti> elopio: right, when I run that apt-get command I don't get the extra [version] thingy
[06:03] <pitti> elopio: but anyway, as you included the output it's easy enough to fix for that case
[06:04] <elopio> pitti: maybe you need to try with barry's ppa: https://launchpad.net/~barry/+archive/ubuntu/systemimage
[06:06] <pitti> elopio: if you didn't commit anything, just send me the output of "git diff" (and perhaps new files), I'll piece it together
[06:35] <pitti> elopio: parser fixed in git
[06:36] <pitti> elopio: do you know that you can run it straight out of git by replacing "adt-run" with "check/out/dir/run-from-checkout"?
[06:36] <pitti> (much easier to test the latest version with that)
[07:05] <elfy> pitti: by today's images should be ok - do you mean 10th March ?
[07:14] <pitti> elfy: systemd was stuck in -proposed, so this morning's images would still have failed
[07:14] <pitti> I nudged them now, though, so the next ones should work again
[07:15] <elfy> ok - thanks
[14:08] <elfy> balloons pitti: manifest for xubuntu shows systemd 219-4ubuntu4 which afaik is the newest, still not getting a desktop here, so maybe a different issue
[14:12] <elopio> ping pitti: there's an error on your parsing fix. I've attaached the patch to the same bug:
[14:12] <elopio> https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1430017
[14:13] <elopio> tested with run-from-checkout, thanks for the tip :)
[14:14] <balloons> elopio, sounds like tomorrow should work
[14:14] <balloons> elfy, ^^
[14:14] <balloons> bah, did it again :-)
[14:17] <rhuddie> elopio, do you have some time to go over changing the proxy base class for the camera test? I've tried various things, but it seems more complicated as I am over-riding the MainWindow and Panel classes, which is leading to other issues.
[14:17] <elopio> rhuddie: I do.
[14:17] <elopio> rhuddie: do you want to hangout or push your changes?
[14:18] <rhuddie> elopio, excellent. I think h/o would be best. I've not submitted changes to branch
[14:19] <elopio> rhuddie: https://plus.google.com/hangouts/_/canonical.com/qa
[14:35] <pitti> elopio: thanks, applied and bug updated *blush*
[14:56] <elopio> pitti: no worries. I bet that was a trap to help me getting started contributing :)
[14:57] <elopio> now I know how to make a git patch.
[14:57] <pitti> elopio: darn, you unveilled my s3kr1t plan
[14:57] <pitti> elopio: nah, it was just me resorting to a quick fix because of time pressure argh
[15:16] <elopio> barry: yesterday you told me that I might be missing an ApplyUpdate. I'm not sure where to put it. Should I call that after the system-image-dbus call?
[15:19] <elopio> pitti: can we run only one of the tests defined in debian/tests/control ?
[15:19] <pitti> elopio: with latest autopkgtest, yes; adt-run --testname mytest -B testdir//
[15:19] <elopio> nice!
[15:19] <pitti> elopio: (just make sure to specify --testname *before* the thing you want to test, as it only applies to the next test)
[15:20] <elopio> pitti: and what if I use Test-command instead of test name?
[15:22] <pitti> elopio: it synthesizes test name "command%i" for those, e. g. --testname command2
[15:22] <elopio> :)
[15:22] <pitti> elopio: starting at 1
[15:34] <barry> elopio: yes, after s-i-dbus has been started, you should then connect to the service and call its ApplyUpdate().  but s-i-dbus will have to run in the background (usually it's dbus activated) and you'll have had to do a CheckForUpdate() first (see my branch)
[15:34] <elopio> barry: /me looks.
[15:35] <barry> pitti: has the systemd transition for desktop happened yet?
[15:36] <pitti> barry: yes, yesterday
[15:37] <barry> pitti: i was afraid of that ;)  dist-upgrade broke.  fortunately, it's on a vm with disk snapshotting, so i'm reverting and trying again
[15:37] <pitti> barry: oh? bug with upgrade log appreciated
[15:38] <barry> pitti: yep, if it reproduces
[15:38] <pitti> barry: that is, day-to-day vivid upgrade? or from trusty/utopic?
[15:38] <barry> pitti: day-to-day.  last upgrade was on 3/5
[15:41] <barry> pitti: if i need to file a bug, where's the best place to do it?  (i'm not positive it's systemd yet)
[15:41] <barry> but it seems a likely candidate
[15:41] <pitti> barry: on the first package that failed is usually the best place
[15:41] <pitti> barry: but I don't mind if you file it against systemd, I can still reassign if appropriate
[15:41] <barry> pitti: ack, thx
[15:41] <pitti> barry: thanks!
[15:57] <barry> pitti: well, this time it upgraded, but then LP: #1430412 upon reboot
[16:12] <pitti> barry: ok, that's someone else's problem then :)
[16:12] <pitti> barry: do you still happen to have the upgrade output somewhere?
[16:12] <pitti> (terminal scrollback or so)
[16:32] <elfy> balloons: yea - but "systemd was stuck in -proposed ... nudged them now, next ones should work" was 2 hours prior to image building, which does have the systemd that's out of proposed according to the manifest - hence me suspecting this is something else
[16:34] <balloons> for xubuntu.. well, let's see
[16:38] <balloons> I don't see any build failures for xubuntu specifically, unlike ubuntu
[16:39] <elfy> yea - which is why I think it's something else again :(
[16:55] <barry> pitti: not the one that failed unfortunately.  i trashed that disk snapshot
[17:01] <elopio> brendand: fgimenez: rhuddie: who is vanguard now? is it me?
[17:01] <fgimenez> elopio, i think brendand
[17:01] <rhuddie> elopio, according to ##qa it is brendand
[17:01] <fgimenez> elopio, see ##qa topic :)
[17:02] <elopio> got it.
[17:02] <brendand> elopio, when i go offline you are
[17:03] <brendand> elopio, are you happy with https://code.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/take_picture_with_rear_camera/+merge/251967 now?
[17:10] <elopio> brendand: I am happy. Did you run the tests with the latest revision?
[17:26] <brendand> elopio, oh yeah - it works
[17:27] <elopio> brendand: ok, I'll approve then.
[17:37] <elfy> balloons: so - with xubuntu images it seems none of the xfce stuff is running ...
[17:37] <elfy> I assume that you should be able to edit the boot line in a live image, and that init=/sbin/upstart should start it with upstart instead
[17:37] <elfy> that just hangs
[17:39] <balloons> elfy, ouch
[17:40] <elfy> it all looks like it's got the right systemd
[17:40] <elfy> at least it doesn't work in kvm too ;)
[17:56] <barry> is anybody else having lp problems?  this page just keeps timing out for me: https://code.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/check-for-running-service
[17:56] <barry> ^^ https://code.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/check-for-running-service/+merge/252057
[17:58] <gQuigs> 1st link loads, second never seems to
[17:58] <elfy> same
[17:59] <barry> gQuigs, elfy thanks for the confirmation.  i'll ping someone over in canonical is
[18:10] <barry> ok.  known problem, being worked on
[18:24] <elopio> barry: when I try to get the interface again while system-image-dbus is running I get:
[18:24] <elopio> [systemimage] Mar 10 18:20:34 2015 (3110) Cannot get exclusive ownership of bus name.
[18:24] <elopio> am I doing something stupid here?
[18:25] <barry> elopio: that means there's already a si-dbus process running.  so either the first one has to be killed or you have to watch for that and use the already running version
[18:25] <barry> iface.Exit() will exit it
[18:25] <barry> as will SIGTERM
[18:25] <elopio> barry: I assume we need it to be running, because that's the one who tells to use our modified .ini
[18:26] <elopio> is there a way to tell the service by dbus which config directory to use?
[18:27] <barry> elopio: there isn't.  we experimented with that for snappy but it was too tricky and racy to be reliable.  so, via dbus, you have to .Exit() and restart it (usually by dbus activate)
[19:36] <brendand> veebers, can you top-approve https://code.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/take_picture_with_rear_camera/+merge/251967 if you're okay with it? it's approved by everyone else
[19:43] <veebers> brendand: ack, I'll be able to do that after the meeting :-)
[20:10] <Letozaf_> balloons, hi
[20:12] <balloons> Letozaf_, hello hello
[20:12] <Letozaf_> balloons, :)
[20:12] <Letozaf_> balloons, I was wondering if you had 2 min. for this: https://code.launchpad.net/~carla-sella/ubuntu-filemanager-app/fixed-test-cut-directory/+merge/252205
[20:16] <balloons> Letozaf_, ahh nice and easy. So that change isn't going to fix the issue, although it's good to have cleanup and you have the right idea. You need to either remove the directory before making the new one or better simply creating only if it doesn't exit
[20:16] <balloons> something like if not os.path.exists(directory), os.makedirs(directory)
[20:17]  * balloons googles and sees python3 has a cool flag now to help with this
[20:17] <Letozaf_> balloons, oh, thanks I will do as you say
[20:17] <balloons> Letozaf_, check out https://docs.python.org/3/library/os.html#os.makedirs
[20:18] <balloons> you can use exist_ok=True :-)
[20:18] <balloons> no need for a conditional check
[20:18] <Letozaf_> balloons, thanks
[20:20] <balloons> but yea, +1 with that. That should solve the issue. Does file manager not just cleanup the temp directory it does all it's operations in? It might be worth a singular check at the beginning
[20:21] <balloons> I'm asking because your fix would be better applied I think at the root directory filemanager uses; so no test has this issue
[20:21] <Letozaf_> balloons, ok I will check this too
[22:42] <elopio> ugh, I got my krillin stuck in the white screen.
[22:44] <elopio> nuclearbob: can you access the board now?
[22:44] <elopio> https://trello.com/b/8dD0UPNl/qa-stakeholders-backlog-scroll-right-for-stakeholder-specific-backlogs
[22:45] <nuclearbob> elopio: yes, thank you
[22:45] <elopio> np.
[22:49] <elfy> balloons: so once again we got sorted by the awesome people in release, we should be off and running again tomorrow
[22:50] <elfy> and btw - ubuntu image still apppears to be rebuilding since the 6th