[14:17] <brendand> elopio or rhuddie, want to review fgimenez's MP? https://code.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/current-version-number/+merge/251774
[14:17] <brendand> would be good to get it landed so we can begin to move forward with the ubuntu-ota-tests
[14:18] <rhuddie> brendand, I can take a look later on this afternoon
[14:56] <elopio> good morning.
[15:23] <balloons> elfy, saw and I'm curious so I asked for more detail :-)
[15:33] <elopio> ping jibel (or anybody from ops): do you tag the bugs found during silo testing?
[15:54] <elopio> ping barry: can we work on the upgrade today?
[15:55] <barry> elopio: yes.  i'm just testing a new branch for check_for_update based on previous comments.  will you be around for a little while (i'd like to get lunch after resubmitting the mp)
[15:55] <elopio> barry: I will be around for a long time, just getting started here.
[15:56] <barry> elopio: cool, i'll ping you after my lunch
[15:56] <elopio> great.
[15:59] <elopio> brendand: our stakeholders meeting is the day after our planning.
[15:59] <elopio> I think it should be the other way around.
[16:00] <brendand> elopio, the order doesn't matter since they are weekly anyway
[16:00] <brendand> elopio, oh wait
[16:00] <elopio> brendand: so, what we are missing are the weekly meetings.
[16:00] <brendand> elopio, you mean the stakeholders meeting on friday?
[16:00] <elopio> I only see one on the 20th.
[16:00] <elopio> brendand: yes.
[16:01] <brendand> elopio, at 4 UTC? i asked olli to delete that
[16:01] <brendand> elopio, the prioritization part of it is being moved to wednesdays
[16:02] <brendand> elopio, and the sign-off part is in the delivery meeting
[16:02] <elopio> brendand: I see. It would be good to put stakeholders on the name of that meeting.
[16:02] <elopio> the wednesday one, I mean.
[16:03] <elopio> brendand: I can delete the other one. Do you want me to do it?
[16:03] <brendand> elopio, i don't see why - the attendees is reflected in the, well attendees list
[16:03] <brendand> elopio, QA backlog prioritization. that's what it's about
[16:04] <elopio> brendand: because the UE calendar is packed full. So what I do is to look at it and see which meetings I should attend based on their name.
[16:04] <elopio> the name of that one sounds like a QA team only thing. Just a suggestion...
[16:35] <elfy> balloons: added some then
[16:50] <jibel> elopio, if it's a bug in the silo we usually don't file a bug because it is unreleased code.
[16:52] <dobey> elopio: so, the contents formerly of libautopilot-qt have been split out into more than just a qt4 package and a qt5 package, but at least a third qttestability package as well?
[16:54] <dobey> a bit icky, but ok
[16:55] <dobey> jibel: unless it's a bug that's as so far gone unnoticed, and isn't a new thing in the silo. a new bug introduced by the silo should just be a failed flag for the silo. right?
[16:56] <jibel> dobey, right, if it's a new bug introduced by the silo we fail it, add a comment on the card and ping the dev.
[17:14] <elopio> jibel: got it.
[17:14] <elopio> dobey: I was waiting for veebers to ask about an alternative to depend only on one package. Would it be a good idea to make a libautopilot-qt5?
[17:16] <dobey> elopio: probably not. having a third package just makes it a tiny big more annoying for packages that should maintain compatibility for building/installing on trusty
[17:16] <dobey> https://code.launchpad.net/~dobey/ubuntuone-credentials/fix-ap-deps/+merge/252336 <- like this :)
[17:18] <elopio> dobey: on the second line, shouldn't you use (>= 1.4) too?
[17:20] <dobey> elopio: it's not necessary to specify the version twice
[17:22] <dobey> elopio: if you manage to get autopilot-qt5 installed with a libautopilot-qt < 1.4, and without qttestability-autopilot installed, then the archive you're pulling from is seriously broken, or you broke your own system manually :)
[17:22] <elopio> makes sense.
[17:24] <elfy> balloons: did you know that there's no sync info against Mate images on the tracker? is that expected for some reason? http://iso.qa.ubuntu.com/qatracker/milestones/326/builds/90310/downloads
[17:27] <balloons> elfy, it needs to be curated
[17:27] <balloons> I think I only added the http info
[17:27] <elopio> jfunk: on my 360 review I have a pending action that says "close 360 review for self", and it takes me to an empty white page. Do I have to do something there?
[17:31] <jfunk> elopio: I am not sure, Brook might know
[17:31] <elopio> I'll ask.
[17:32] <elfy> balloons: ubuntu image is rebuilding - nothing new since Friday
[17:48] <balloons> elfy, ?
[17:48] <balloons> are new builds not selfpublishoing?
[17:49] <balloons> I see 20150309 for mate
[17:49] <elfy> no idea tbh - I actually only noticed that was all wrong for Ubuntu as I've got a fubar xubuntu and am checking other images
[17:50]  * balloons checks the logs
[17:50]  * balloons sees what elfy sees
[17:52] <balloons> elfy, yes the builds are failing
[17:53] <balloons> ahh this is pitti's breakage ;-)
[17:53] <balloons>  systemd-sysv : Conflicts: upstart but 1.13.2-0ubuntu9 is to be installed
[17:53] <balloons> https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1427654
[18:00] <barry> elopio: hi.  any time you're ready
[18:01] <elfy> balloons: so once more unto the breach ... Xubuntu images are fubar seemingly - no desktop in hardware, kvm or vbox
[18:04] <elopio> barry: let's hit it.
[18:04] <elopio> barry: first we need to finish the discussion about who reboots and who waits for the upgrade to be applied.
[18:04] <elopio> what I was trying now was to overwrite the apply hook to call /tmp/autopkg-reboot instead of /sbin/reboot
[18:05] <elopio> barry: that would leave the wait to adt-run. Why did you want to wait for the reboot on the host?
[18:07] <barry> elopio: i just thought that if the wait doesn't happen on the host, as soon as the device reboots, any wait there would just cease.  doesn't it have to be on the host?
[18:08] <elopio> barry: wait, right. I said it wrong.
[18:08] <elopio> I got the impression that you wanted to wait on the testbed, not on the host.
[18:08] <barry> elopio: ah, no.  my only point there was that not doing /sbin/reboot wouldn't be an exact test of what happens on the device.  but maybe that tiny difference won't really matter
[18:09] <elopio> both are possible. But waiting on the testbed would require to copy some of the things that adt-run is handling for us, like reenabling ssh.
[18:09] <elopio> barry: we can do /sbin/reboot, we just need to change the adb script a little following pitti's suggestions.
[18:09] <balloons> elopio, so presumably systemd yes?
[18:09] <balloons> elfy, ^^
[18:09] <elopio> ^^
[18:09] <balloons> aloha elopio :-)
[18:10] <elopio> barry: so, quickest solution for now is to do adb reboot recovery, but later we can easily change that to be adb shell /sbin/reboot -f recovery
[18:10] <barry> elopio: what do you think?  as long as the system gets rebooted through recovery *somehow*, that might be close enough for us
[18:10] <barry> elopio: that sounds good to me
[18:10] <barry> let's do the quickest solution now
[18:11] <elfy> balloons: bit confused as to what you're pointing me at - elopio and barry's conversation or the FFe
[18:11] <elopio> oka. barry, one question: if we call system-image-dbus -c, can we just overwrite the apply value and it will take the rest from the default?
[18:12] <barry> elopio: correct.  with si 3.0, .ini files with higher numeric prefixes override lower ones, and they only need to contain the override (section + variable)
[18:14] <elopio> good. So we just need to agree now in the python path for the apply object.
[18:14] <elopio> barry: could you review this one? https://code.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/current-version-number/+merge/251774 It conflicts with the branch proposed by veebers, so I'm not sure which one to use as a prereq.
[18:15] <barry> elopio: ubuntu_ota_tests/hooks.py?
[18:15] <elopio> in the mean time, I will change the branch to use your ppa so we can give it a try with dbus.
[18:16] <barry> elopio: also, maybe my branch: https://code.launchpad.net/~barry/ubuntu-ota-tests/check-for-update-2/+merge/252324
[18:16] <barry> elopio we just have to decide on one of yours, mine, or veebers to base things off of :)
[18:18] <barry> elopio: are you mocking dbus because you don't have si 3.0 yet?
[18:19] <elopio> barry: that's fgimenez branch.
[18:19] <barry> elopio: oh, whoops
[18:20] <elopio> and I think he's mocking it to not have it as a dependecy on the host.
[18:20] <elopio> barry: is 3.0 going to be on utopic?
[18:20] <barry> elopio: no, vivid, hopefully though
[18:20] <elopio> we are so close to the vivid release that I think it won't be a problem to make this tool request a vivid host.
[18:21] <elopio> but we need to check that with others, like jibel and CI.
[18:21] <elopio> you have a good point. I would prefer to use the real dbus service for those tests.
[18:22] <elopio> barry: and, lets use today's standup to agree where our ota package will be. We should have made that a card, instead of getting 3 different implementations :)
[18:22] <barry> elopio: yes, and yes :)
[18:24] <barry> elopio: oh, also, not sure who's in charge of the calendar (brendand perhaps?) but there's no meeting on the calendar for this week
[18:25] <elopio> barry: there are meetings, you are just not invited :)
[18:25] <elopio> I'll send you the invite.
[18:25] <barry> elopio: :)
[18:30] <barry> elopio: yay for daylight savings time
[18:33] <elopio> barry: I don't have those crazy rules. Here we just wake up with the chickens, as god wanted.
[18:33] <barry> elopio: i'm packing my bags then! :)
[18:35] <elopio> barry: you should. We have other cool things, like plenty of güayabas.
[18:36] <elopio> barry: for ci, they tell me that things will be easier if the hosts on the lab are trusty machines.
[18:36] <elopio> so, we either make a ppa for trusty, backport the things we need, or don't make a dependecy for system-image-dbus on the host.
[18:37] <barry> elopio: i have no idea what those are but it sounds intriguing :)
[18:37] <barry> backporting will probably be difficult
[18:37] <barry> well, maybe not
[18:37] <barry> not sure
[18:37] <barry> but i don't think it need be a dependency on the host
[18:37] <barry> since this is all running on the device.  once/if it lands in vivid, it'll be on the device and all will be good
[18:39] <elopio> barry: yes, it's just a little painful for the selftests. That is, the tests for the code in ubuntu_ota_tests package. They are a lot faster than the actual ota tests, so it would be nice to run them on the host for a quick feedback.
[18:39] <elopio> but if the other options are harder, we can run them on the testbed too. Not a big deal.
[18:40] <barry> elopio: ah, yes, i see what you mean.  the device tests *are* sloooooow
[18:40] <elopio> or, mock the dependencies that we don't have on trusty. One more item to discuss on the standup, I'll make a note.
[18:41] <barry> elopio: i'll do a test build on a trusty chroot now to see how painful a backport might be
[18:41] <elopio> great, thanks.
[19:09] <elopio> barry: have you been able to run this test? https://code.launchpad.net/~canonical-platform-qa/ubuntu-ota-tests/upgrade/+merge/251646
[20:05] <barry> elopio: does that test ^^ illustrate the problem?
[20:05] <elopio> barry: it needs one push, and to be called with a long command.
[20:05] <elopio> give me a second.
[20:05] <barry> k
[20:07] <elopio> barry: pushed.
[20:07] <elopio> and run with: adt-run -d -B --unbuilt-tree=. --output-dir /tmp/output --- ssh -s ./adb-reboot-to-recovery
[20:07]  * barry tries
[20:08] <elopio> what I've found out with debugging is that adt-run runs:
[20:08] <elopio> adt-run: DBG: testbed command ['apt-get', '--quiet', '--simulate', '--no-remove', '-o', 'Debug::pkgProblemResolver=true', '-o', 'Debug::NoLocking=true', '-o', 'APT::Install-Recommends=False', '-o', 'APT::Get::Show-User-Simulation-Note=False', 'install', 'system-image-dbus'], kind short, sout pipe, serr raw, env ['LANG=C.UTF-8']
[20:08] <elopio> that returns: Inst system-image-dbus [2.5-0ubuntu1] (3.0b3-0ubuntu2 system-image testing:15.04/vivid [all]) []
[20:08] <elopio> adt is not expecting the [2.5-0ubuntu1]
[20:09] <elopio> so instead of returning 3.0b3-0ubuntu2, it's returning 2.5-0ubuntu1].
[20:11] <barry> elopio: it looks like it's getting the vivid version of si
[20:11] <barry> but wants the ppa version
[20:12] <barry> elopio: yep, that's what's happening i think.  you need to add the ppa to adt-run i think.  problem is, the ppa is not being cooperative
[20:12] <elopio> barry: that's a different problem. I cut that part to make it easier for you to reproduce it. We can install the ppa with:
[20:12] <elopio> adt-run -d -B --unbuilt-tree=. --output-dir /tmp/output  --setup-commands "mount -o remount,rw /; apt-add-repository -y ppa:barry/systemimage; apt-get --no-list-cleanup update -o Dir::Etc::SourceList=/dev/null; sync; sleep 2; mount -o remount,ro /"--- ssh -s ./adb-reboot-to-recovery
[20:14] <barry> elopio: let me try that
[20:14] <elopio> barry: I missed a space before the ---
[20:14] <barry> elopio: yep, i fixed that :)
[20:28] <barry> elopio: weird, it wfm.  the test even passes
[20:29] <elopio> barry: how did you flash your phone?
[20:30] <barry> elopio: ah, heh.  i installed a local copy of si 3.0 ;)
[20:30] <barry> after flashing it
[20:30] <elopio> yes, that's cheating :)
[20:30] <elopio> but it should at least fail because the namespace I set for apply doesn't exist.
[20:31]  * barry grins sheepishly
[20:31] <barry> it doesn't fail
[20:31] <elopio> I might have done something wrong in there.
[20:31] <barry> and i'll stop cheating once i beat ppa into submission
[20:31]  * elopio tries.
[20:48] <elopio> barry: I'll just report a bug to autopkgtest. As the ppa is temporal, it doesn't matter how we install it.
[20:48] <elopio> now I'm getting: [systemimage] Mar 09 20:47:59 2015 (4075) Cannot get exclusive ownership of bus name.
[20:50] <barry> elopio: i saw that too.  my guess is that system-image-dbus is already running on the device (maybe some kind of system-settings background process).  si-dbus has a check to make sure there's only one instance running.  we probably have to call .Exit() first and catch the exception that will be raised if no si-dbus process is running
[20:51] <elopio> barry: ack. I'll get that from veebers' branch.
[20:51] <barry> +1
[20:51] <elopio> I'll also change this ugly ota_basic script to something in python.
[20:52] <barry> +1000
[20:52] <barry> :)
[20:52] <elopio> I was just giving it a try :)
[20:53] <elopio> I'm going to have lunch and bbl. barry: if you want me to change something else  from that branch, leave me a comment please.
[20:53] <barry> elopio: cool
[21:39] <elopio> barry: I pushed the py script. It now seems to be stuck at:
[21:39] <elopio> [systemimage] Mar 09 21:36:17 2015 (25953) Mediator created <Mediator at 0xb558e650 | State at 0xb558e730>
[21:40] <barry> elopio: might have to ramp up debugging to get more out of it
[21:41] <barry> man i loathe dbus
[21:46] <elopio> I get the same with phablet@ubuntu-phablet:~$ sudo system-image-dbus -v -C /tmp/
[21:46] <elopio> there's nothing useful in /tmp/
[21:47] <barry> elopio: try bumping loglevel up to debug
[22:04] <elopio> barry: I changed it in /etc/system-image/client.ini. It prints the same.
[22:07] <barry> elopio: si 3.0?  that doesn't use client.ini
[22:07] <elopio> barry: so where is the basic .ini to change it?
[22:08] <barry> elopio: for si 3.0, add a file to /etc/system-image/config.d that contains:
[22:08] <barry> [system]
[22:08] <barry> loglevel: debug
[22:08] <barry> (that's it)
[22:08] <barry> name that file something like: 99_debug.ini
[22:10] <elopio> barry: same output
[22:10] <barry> elopio: hmm...
[22:10] <barry> elopio: i'm at a loss.  it's almost as if no dbus method is coming in
[22:16] <barry> elopio.  i think you need to call iface.ApplyUpdate()
[23:05] <barry> elopio: i am eod, but i'm testing a branch that will hopefully make si 3.0 build more reliably in the ppa.  let's chat again tomorrow