[00:42] <robru> rsalveti, jenkins is down for maintenance, should be back soon though
[02:04] <imgbot> [03:17] <robru> rsalveti, sorry about that, had an absurdly long phone call. you're in silo 18 now
[03:29] <imgbot> [03:30] <imgbot> [08:00] <sil2100> ricmm: hi! I see your silo has some problems building certain archs
[08:01] <sil2100> ricmm: is that on your radar?
[08:34] <ricmm> sil2100: sure, but that was last night
[08:34] <ricmm> sil2100: if you see again, you'll see they rebuilt 9 hours ago
[08:35] <ricmm> the remaining failing arches are not published in the archive for any of the pkgs
[08:43] <ogra_> sil2100, looks like to dropped
[08:44] <sil2100> Ugh
[08:44] <sil2100> Wifi died for a moment :o
[08:47] <sil2100> Ok guys, this wifi madness is making me unable to hear any of you
[08:47] <sil2100> So I drop off from hangouts
[08:48] <ogra_> sil2100, well, you know where to look for the changelog :)
[08:48] <davmor2> ogra_: http://paste.ubuntu.com/7622470/
[08:55] <popey> congratulations sil2100
[08:55] <popey> https://twitter.com/ubuntudev/status/476286376485593089
[08:56] <sil2100> Thank you!
[08:56] <sil2100> Damn, sucks that I don't have tweeter ;p
[08:57]  * sil2100 is like a caveman from the stone age
[09:00] <ogra_> OOOOHH !
[09:00] <ogra_> congrats !!!
[09:07] <Mirv> sil2100: congrats!
[09:07] <sil2100> Thanks guys ;)
[09:10] <mandel> ogra_, what partitions are mounted in recovery mode?
[09:15] <sil2100> Holy crap, just went to my balcony for a moment and it's hot like hell outside
[09:16] <dbarth> Mirv: ping?
[09:16] <ogra_> mandel, just / and /cache by default iirc
[09:17] <mandel> ogra_, so I can do a adb push of resize2fs (static one) to /cache or / correct?
[09:17] <dbarth> Mirv: the new qtwebkit seems fine for old webapps overall
[09:17] <mandel> ogra_, I want to resize the system partition :)
[09:17] <dbarth> Mirv: do you have a timeline for landing it?
[09:17] <ogra_> mandel, that should be preinstalled
[09:22] <Mirv> dbarth: I'm at QtCS this week, but I can do the publish from here if needed. I maybe just don't have the complete picture of what would still be tested, like did you test HTML5 apps? I did start some cordova tutorial created app and it seemed to work.
[09:23] <popey> sil2100 went to the balcony to announce to his followers that he's now a #motu, right?
[09:23] <cjwatson> <followers class="adoring">
[09:23] <sil2100> popey: right! Although there was only one guy with a dog listetning...
[09:24] <popey> heh
[09:25] <popey> "He's not a MOTU, he's a very naughty boy!"
[09:25] <brendand> do we reboot devices between autopilot suites?
[09:26] <Mirv> dbarth: I also tried Cordova Mobile Spec app that was installable, but I'm not sure which all of those should work to which extent etc, but surely it was navigable
[09:39] <dbarth> Mirv: ok, i'll get back to you re: more html5 apps testing
[10:19] <davmor2> sil2100: network disconnecting over night issue https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1328478
[10:33] <Mirv> sil2100: building is broken https://ci-train.ubuntu.com/job/landing-005-1-build/82/console
[10:33] <Mirv> (second try already)
[10:36] <Mirv> ...as seb128 also just found out
[10:37] <seb128> yeah
[10:37] <seb128> same on https://ci-train.ubuntu.com/job/landing-012-1-build/40/
[10:44] <sil2100> hmmm
[10:44] <sil2100> It might be related to that jenkins switch that happened last night
[10:44]  * sil2100 looks into that
[10:45] <sil2100> Ah shiiit
[10:46] <seb128> rsalveti, ricmm: when is platform api v2 going to land?
[10:46] <sil2100> So the worst-case scenario happened
[10:46] <seb128> rsalveti, ricmm: it's blocking unity8-desktop-session bugfixes to land
[10:46] <seb128> the desktop-next iso is useless until that happens...
[10:46] <Laney> why does it need to block that?
[10:47] <seb128> if the api stuff is not ready to land, could we get the bugfixes in and then go back to yours?
[10:47] <seb128> Laney, because you can't have the same projects in multiple silos
[10:47] <sil2100> seb128: I was asking that yesterday, it was supposed to be landed ASAP
[10:47] <seb128> sil2100, ok, thanks
[10:47]  * popey notes that desktop-current iso is currently useless ☻
[10:47] <seb128> popey, how so?
[10:47] <sil2100> We didn't want to override again as geh, papi is already waiting for weeks
[10:47] <popey> ubiquity is broken, it doesn't start at all.
[10:47] <seb128> urg
[10:48] <Laney> I don't even know for sure that this will fix it
[10:48] <seb128> popey, bug number?
[10:48] <popey> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1326707
[10:48] <seb128> Laney, well, I want to see that landing before I spend time debugging
[10:48] <popey> \o/ fixed 9 hours ago!
[10:48] <seb128> popey, ;-)
[10:48] <Laney> seb128: indeed
[10:48] <popey> I love sleeping. Things get fixed when I sleep.
[10:48] <Laney> I just mean that it's hard to test until things get in
[10:49] <Laney> the slow pipeline makes this difficult
[10:49] <seb128> right
[10:51] <xnox> popey: it's fixed, but there ain't yet an iso with a fixed ubiquity =)
[10:52] <popey> good enough ☻
[10:52] <popey> thank you!
[10:52] <xnox> popey: thus can't actually verify it's "fixed fixed"
[10:52] <dbarth> sil2100: o/ hi, i have a quick branch to pass, for an extra HTML5 binding
[10:52] <dbarth> sil2100: would be handy for a UOS session later this week
[10:53] <sil2100> Hey!
[10:53] <sil2100> dbarth: sure, we're having problems with jenkins right now though
[10:53] <dbarth> ok, nw; just to know if i can be that last silo that remains ;)
[10:55] <davmor2> Mirv: how's the conference?
[11:00] <Mirv> davmor2: interesting, a lot of Qt interested folks from different companies + Digia. I'm showing my Qt 5.3 running U-Phone to interested people.
[11:01] <Mirv> runtime OpenGL vs ES switching still being planned, which is good
[11:01] <davmor2> Mirv: sounds fun then :)
[11:01] <Mirv> indeed. now -> lunch
[11:08] <davmor2> popey: did you ever write a bug for video stalling on playback?
[11:09] <sil2100> NOTICE! There will be a jenkins outage in a moment!
[11:10] <popey> davmor2: no, i thought there already was one.
[11:10] <sil2100> (by jenkins outage I mean citrain jenkins)
[11:26] <popey> xnox: tested your fixed ubiquity on a live cd, it is fixed ☻
[11:28] <davmor2> popey: be pretty daft calling it a fixed ubiquity if it wasn't ;)
[11:28] <popey> Penfold, shush.
[11:28] <xnox> davmor2: well, i claim it's a python3 regression.
[11:29] <xnox> popey: did you read the comment next to the one-liner fix?! =)
[11:29] <popey> nope
[11:29] <xnox> popey: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6188
[11:30] <xnox> in retrospect, it's not that funny.
[11:30] <popey> wow
[11:36] <cjwatson> xnox: I'm not convinced printing was ever guaranteed to flush.
[11:36] <cjwatson> xnox: I don't agree that's a regression.
[11:36] <cjwatson> xnox: Leaving aside the flush=True keyword arg, test_debconf.stdin.flush() was available.
[11:37] <cjwatson> xnox: Maybe the default buffering changed or something; some equivalent of setvbuf might be worth looking into, rather than manually flushing all over the place, though.
[11:38] <cjwatson> I think we were wrong to make any particular assumptions about the default buffering on pipes.
[11:38] <xnox> cjwatson: experimentally, changing try: except:, feeding stdin & closing stdin/stdout. is all looks clunky.
[11:38] <xnox> when:
[11:39] <xnox> stdou, stderr = test_debconf.communicate ("VERSION 2.0")
[11:39] <xnox> is all that's needed.
[11:39] <xnox> (with try/except IOError)
[11:39] <xnox> so i was going to propose that as a longer term fix.
[11:40] <cjwatson> That seems wrong.  .communicate is defined to "read data from stdout and stderr, until end-of-file is reached".
[11:40] <cjwatson> Now as it happens you probably get EOF because it's run out of stuff in the pipe, but it doesn't seem conceptually right to me.
[11:40] <cjwatson> .communicate is really meant for "and I don't want to do anything else with this process later".
[11:41] <cjwatson> I think you should figure out how to make test_debconf.stdin line-buffered instead.
[11:41]  * cjwatson goes out for a bit before UOS starts
[11:45] <xnox> buffering=1
[11:46] <sil2100> ogra_: I guess we'll have to cancel the evening meetings for the next 3 days I guess
[11:47] <seb128> sil2100, what's the status on the infrastructure issues? can I retry the build that failed earlier?
[11:47] <sil2100> seb128: not yet - it's almost fixed, we're still having some permission issues and webops are looking into that
[11:47]  * sil2100 is using seb128's job for that
[11:48] <sil2100> I'm using your job for testing ;)
[11:48] <ogra_> sil2100, yeah, makes sense
[11:48] <seb128> sil2100, great, thanks
[12:29]  * sil2100 goes preparing lunch in the meantime
[13:00] <tedg> sil2100, silo 14 has some deps that need to be sorted, can you deallocate it?
[13:03] <sil2100> tedg: you want the silo freed?
[13:04] <sil2100> Ok :)
[13:04] <sil2100> I like the idea as we're low on silos
[13:04] <seb128> sil2100, did you fix the build environments?
[13:04] <tedg> sil2100, Yeah, it's going to take a while to fix the deps. No reason to hold it.
[13:05] <sil2100> seb128: not yet... webops are working on it as I have no access ;/
[13:05] <sil2100> seb128: I'm trying to help out as much as I can, but it's lunch time for the vanguard as well
[13:06] <seb128> k
[13:24] <brendand> sil2100, i'm looking for some info on how the smoke tests are run. is there a jenkins job i could look at?
[13:26] <ogra_> brendand, bzr branch lp:ubuntu-test-cases
[13:26] <ogra_> IIRC
[13:26] <ogra_> it is run as part of UTAH
[13:27] <brendand> ogra_, not much in that branch
[13:29] <davmor2> popey: for the bulk of the default app (Note not core apps) if you long press them do you get a description you would expect?
[13:30] <davmor2> popey: ie compare calendar/clock with amazon/dialer etc
[13:31] <popey> davmor2: probably not for the ones installed via debs
[13:33] <popey> davmor2: the ones that have descriptions are coming from the store, until all of the apps are clicks, the debs will have missing descriptions I guess
[13:34] <davmor2> popey: ah okay that explains it ta
[13:34] <sil2100> brendand: yeah, one moment:)
[13:35] <sil2100> brendand: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/274/console
[13:35] <sil2100> brendand: here for instance you have the run that had filemanager in it (and some others)
[13:35] <dobey> davmor2: eh?
[13:36] <popey> uh, did we break ubuntu-bug?
[13:36] <popey> phablet@ubuntu-phablet:~$ ubuntu-bug unity8
[13:36] <popey> usage: whoopsie-upload-all [-h] [-t TIMEOUT]
[13:36] <popey> whoopsie-upload-all: error: unrecognized arguments: unity8
[13:36] <dobey> popey: the apps installed from debs will only have missing descriptions if the .desktop doesn't have a "Comment=" field. however, the ones that do have it seem to have pretty awful descriptions :-/
[13:36] <popey> ok
[13:37] <dobey> many of the click packaged apps also have pretty horrible descriptions
[13:37] <davmor2> dobey: why the eh?
[13:37] <dobey> davmor2: i'm trying to understand what you're asking about
[13:38] <dobey> davmor2: you are seeing apps with blank descriptions?
[13:38] <davmor2> dobey: not blank just not descriptive compare clock app to dialer
[13:39] <davmor2> dobey: or clock app and friends
[13:39] <dobey> davmor2: yeah, many apps have very poor "descriptions"
[13:39] <popey> yes, clock = click, dialer isnt a click
[13:39] <dobey> and the store has this "tag line" thing when you upload an app, which it munges into the description, and actually gives us as the first line of the description text
[13:40] <dobey> popey: whether it's a click or not is irrelevant i think
[13:40] <dobey> popey: the description for twitter and most of the default web apps are pretty awful too :)
[13:40] <popey> file a bug
[13:41] <davmor2> I only just noticed as I flicked through them testing the platform api for any breakages :)
[13:41] <dobey> i did file one against friends already
[13:44] <brendand> sil2100, so we are rebooting the devices between test suites
[13:45] <dobey> oh, well i filed a bug about friends-app.desktop not being translated, but i guess i didn't mention the bad description in it
[13:45] <popey> bug 1328535
[13:48] <sil2100> brendand: yes, as I remember correctly we do
[13:49] <popey> davmor2: can you confirm bug 1328536 pls?
[13:49] <brendand> sil2100, ok. i'm trying to figure out why it's so difficult to reproduce these failures locally
[13:49] <brendand> sil2100, is there a single script that runs the smoke test from start to finish?
[13:50] <davmor2> popey: I use apport- bug I didn't even know ubuntu-bug was installed :)
[13:50] <popey> well thats broken too
[13:51] <sil2100> brendand: uh, I remember doing something like this once, but I can't remember the exact steps and if that didn't change... so I guess the safest way is poking plars-away or reading up the logs
[14:18] <sil2100> ogra_: any news on the failing security tests?
[14:19] <ogra_> sil2100, yes, i pinged jdstrand in -touch earlier, he is looking into it
[14:19] <sil2100> Awesome :)
[14:19] <sil2100> Thanks!
[14:22] <jdstrand> it should be fixed now. bad test. sorry
[14:23] <sil2100> jdstrand: thanks o/
[14:40] <bfiller> sil2100: getting failures trying to build silo-003: https://ci-train.ubuntu.com/job/landing-003-1-build/72/console
[14:40] <bfiller> sil2100: is it a jenkins problem?
[14:40] <sil2100> bfiller: ah... yes, let me update the header on the spreadsheet
[14:40] <sil2100> bfiller: we're currently fixing jenkins ;/
[14:45] <balloons> ping fginther
[14:45] <fginther> balloons, yo
[14:47] <balloons> fginther, hey :-) So, I wanted to let you know about the discussion we had on running tests on trusty during merge proposals. Basically, given all the issues surrounding it and lack of support, we decided to just remove the trusty builds.
[14:47] <balloons> can you tweak all the core apps at some point to go ahead and stop running trusty?
[14:47] <fginther> balloons, that's easy enough to do
[14:48] <balloons> awesome.. and hopefully we won't have another friday like the last one :-)
[15:03] <rsalveti> seb128: you might be able to help us on that :-)
[15:03] <rsalveti> we wanted to land it today, but there's a bunch of packaging renaming happening in the platform-api mr
[15:03] <rsalveti> and that will require someone to approve them from NEW
[15:03] <seb128> rsalveti, I can do the NEW side, sure
[15:04] <rsalveti> we're just finishing the testing side of it as we speak
[15:04] <rsalveti> seb128: in case you already want to take a look at the renaming: https://code.launchpad.net/~ricmm/platform-api/v2-dynamic-refactor/+merge/220721
[15:06] <ricmm> seb128: we iterated a few times over it, but there might still be something amiss that you will catch
[15:09] <seb128> ricmm, rsalveti: k, looking in a bit, thanks
[15:31] <sil2100> seb128, bfiller: issues resolved (most probably)
[15:31] <sil2100> seb128: your silo is running build right now
[15:31] <seb128> sil2100, great!
[15:31] <seb128> thanks
[15:31] <sil2100> seb128, bfiller: it seems that *somehow* the debootstrap chroot got broken during the migration, which is strange
[15:36]  * Mirv builds too, Qt 5.3 PPA shoud be again functional pretty soon after that (currently webbrowser is lagging behind archive version)
[15:37] <Mirv> bfiller: could you look through the open Qt 5.3 issues and do some bugs assigning when you know who to assign to? http://is.gd/gZFEqm is the best link (filters out fixed-in-PPA ones)
[15:39] <sil2100> bfiller: I'll run the build job for you
[15:40] <bfiller> Mirv: will do
[15:40] <bfiller> sil2100: ty
[15:44] <sil2100> robru, davmor2, ogra_, slangasek, plars-away, popey: ok, so as discussed, let's skip the US TZ meetings during UOS
[15:44] <sil2100> There's a session I want to listen into even
[15:44] <ogra_> ++
[15:45] <robru> most excellent
[15:45] <sil2100> davmor2, popey: as you guys have the power of the calendar for the US TZ event, can you maybe cancel the 3 meetings?
[15:45] <robru> sil2100, which session interests you presently?
[15:45] <Mirv> bfiller: thank you
[15:46] <davmor2> I'd forgot this was even on
[15:46] <sil2100> robru: Unity8 Desktop Preview Image
[15:48] <sil2100> Anyway, as a track lead I need to be available for all the platform tracks
[15:49] <popey> sil2100: yes, i can
[15:49] <sil2100> popey: thank you!
[15:49] <popey> sil2100: done
[15:49] <popey> np
[15:49]  * sil2100 is a master of the universe but not a master of the google calendar it seems
[15:51] <davmor2> popey: damn you I'd just figured out how to do that too :)
[15:51] <davmor2> popey: I don't mind really though as long as it is done :)
[15:54] <Mirv> elopio: hey! could you run the gatekeeper job with ci-train-ppa-service/landing-005 again? since Friday we've gotten working media player and camera, so it'd be interesting to have results for those plug in general have another autopilot run. music app still crashes, though.
[15:54] <Mirv> elopio: oh, with the caveat that about 30 minutes from now, when https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+build/6087001 is safely published (finished building >20mins ago)
[15:59] <elopio> Mirv: yes, I can. I'll see if autopilot is using the job.
[16:00] <elopio> ping Ursinha: can we get this one triaged please? https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1275012
[16:00] <elopio> I would like to know if we will have it in the near future.
[16:01] <Mirv> elopio: thanks. the Friday's run was fine (although I'm not sure if all AP:s from the image dashboard were again included or not)
[16:01] <elopio> Mirv: do you have a link to that run?
[16:01] <Ursinha> elopio: I'll have a look/hand over to the next vanguard person
[16:01] <elopio> thanks
[16:02] <robru> hmmm i'm not getting the video feed on the uos page...
[16:02] <Mirv> elopio: http://q-jenkins:8080/job/autopilot-release-gatekeeper/151/? - robotfuel mentioned something about that the "ALL" description for tests might be outdated and in theory it should be really ~all. I'm just wondering why there weren't camera AP failures reported since camera was still broken on Friday
[16:05] <robru> sil2100, can you get me a link for the unity8 video stream? it's not showing up on the summit page for me
[16:06] <elopio> Mirv: camera app was not run there.
[16:06] <sil2100> robru: still waiting for it to be setup
[16:06] <robru> hm
[16:06] <elopio> oh, wait, actually it was
[16:07] <elopio> Mirv: http://q-jenkins:8080/job/autopilot-release-gatekeeper/151/label=daily-mako/testReport/camera_app.tests.test_capture/TestCapture/
[16:07] <elopio> I don't know the camera tests, so I'm not sure what they are doing.
[16:08] <Mirv> elopio: it should take a picture, but the taking a picture button was disabled still on Friday. but there's only three tests there, while http://ci.ubuntu.com/smokeng/utopic/touch/mako/76:20140610:20140530/8503/camera_app/ has 11
[16:08] <Mirv> well, we can also just simply see how it's this time that it's not disabled/broken
[16:09] <ricmm> anyone here familiar with u8 autopilot ?
[16:09] <elopio> Mirv: there are 11 tests, http://q-jenkins:8080/job/autopilot-release-gatekeeper/151/label=daily-mako/testReport/
[16:09] <elopio> all passed.
[16:10] <davmor2> ricmm: so I had 3 fails on unity8 addressbook running now
[16:10] <elopio> ricmm: I am familiar, but I tried to run them yesterday after a couple of weeks and I'm still trying to recover my machine.
[16:10] <fginther> elopio, can I discuss the qt smoke test runner job with you later today?
[16:10] <elopio> it crashed badly.
[16:10] <ricmm> davmor2: address book ran OK in all tests for me
[16:11] <ricmm> but I'm having issues with unity8, after a while it reboots
[16:11] <ricmm> ?
[16:12] <elopio> ricmm: are you on desktop or phone?
[16:12] <davmor2> ricmm: so it ran fine for me bar the 3 failures
[16:12] <ricmm> phone
[16:12] <ricmm> davmor2: mako? I ran them on flo
[16:12] <davmor2> ricmm: yeah mako
[16:13] <ricmm> oh you had 3 fails on unity8
[16:13] <ricmm> I misunderstood that
[16:13] <elopio> ricmm: on desktop, unity7 was restarted here. I can try on the phone as soon as I recover my desktop.
[16:13] <ricmm> elopio: what tests are you talking about?
[16:13] <ricmm> I'm talking about silo 7, what davmor is trying out
[16:14] <elopio> ricmm: unity8 autopilot tests.
[16:14] <ricmm> davmor2: how did you run it exactly? it's literally dying after a few runs for me, with an actual reboot
[16:14] <ricmm> davmor2: also, do you have the error output?
[16:14] <elopio> re: <ricmm> anyone here familiar with u8 autopilot ?
[16:15] <davmor2> ricmm: I'm going to go back and dig into stuff I just want to get things running and compare it to the current run tests
[16:15] <ricmm> davmor2: ok awesome, thank you for that
[16:15] <ricmm> I just want to understand what the failure on my device is
[16:15] <ricmm> if I run it without -v then a bunch of them pass until it reboots randomly, if I run it with -v none of them pass
[16:16] <davmor2> ricmm: it hates you, hate it back it worked for me :)
[16:16] <ricmm> I will
[16:30] <davmor2> ricmm: cordova 1 failure
[16:43] <sil2100> ogra_: do we have a bug for the indicator-network crash?
[16:46] <ogra_> sil2100, nope, since Wellark said the whole week in malta he would fix it i dont think anyone filed one
[16:46]  * sil2100 sighs
[16:46] <sil2100> Right
[16:46] <sil2100> ;)
[16:46] <sil2100> Ok, I'll fill it in then once I have a time window for that
[16:46] <sil2100> For now I'll simply add it to our list bugless
[16:47] <balloons> ogra_, would you happen to know where I can get old manifest files from? older than what's on cdimage atm.. seems to keep about a week's worth, I need a bit more than that
[16:47] <sil2100> Wellark: we're putting pressure on you!
[16:48] <ogra_> balloons, i think they are gone ... unless cjwatson has a secret place where he stores backups or some such
[16:48] <ogra_> balloons, my manifest diff files have the added/removed packages though
[16:48] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/
[16:48] <cjwatson> I don't
[16:48] <cjwatson> I already referred balloons to the build logs though
[16:48] <balloons> yea, he pointed out some nice build logs..
[16:49] <cjwatson> Which we do keep indefinitely
[16:49] <sil2100> ogra_: regarding that, let's have a chat tomorrow about moving our bots and scripts to canonistack
[16:49] <balloons> means some tool tweaking.. ok, I may rebase to use your diffs instead of the manifests
[16:49] <balloons> ty ogra_
[16:50] <ogra_> sil2100, ++
[17:01] <sil2100> davmor2: did you get any update from tedg or design on some of the greeter-related issues?
[17:02] <davmor2> sil2100: yes thanks but I'm not telling you :P
[17:03] <sil2100> Heeey
[17:03] <sil2100> That's mean!
[17:03] <sil2100> ;)
[17:03] <davmor2> sil2100: So the biggest one being redesigned is messaging, the others have tweaks no news on when those will land.  The stuff the needs fixing is in the master bug and will be worked on at some point I still need to add links to those
[17:05] <davmor2> sil2100: does that help any?
[17:06] <sil2100> davmor2: yeah, at least something, thanks :)
[17:11] <elopio> Mirv: I'm starting the jenkins job again.
[17:21] <sil2100> ogra_: https://plus.google.com/109159869108744115904/posts/9YuCXibF2CS
[17:22]  * ogra_ hugs sil2100 
[17:22] <ogra_> yay \o/
[17:22] <ogra_> now google has you !!
[17:22] <sil2100> Is that ok? ;p
[17:22] <ogra_> totally
[17:22] <sil2100> Since I'm a bit noob with this...
[17:23] <ogra_> it is perfect
[17:24] <sil2100> \o/
[17:31] <elopio> fginther: sure
[17:31] <elopio> sorry, I found your message too late :)
[18:22] <asac> ricmm: how is the platform-api landing going?
[18:23] <asac> i see we need Prerequisite: lp:~thomas-voss/platform-api/hw-alarms-api
[18:23] <asac> to fix my avenger bug :)
[18:23] <ricmm> that landed a long while ago
[18:23] <ricmm> hw-alarms-api that is
[18:23] <ogra_> asac, we're missing the indicator changes that use it properly now
[18:24] <asac> ricmm: ok thats in the image?
[18:24] <asac> that prereq?
[18:24] <ogra_> i was told it landed a week before malta or so
[18:29] <asac> so charles tells me he also needs the /dev/alarms being read-only fixed for his branch to land
[18:30] <asac> ricmm: ogra_: who is doing that? you know?
[18:30] <ogra_> asac, charles i think
[18:30] <asac> charles: ?
[18:30] <charles> no
[18:30] <asac> see :P
[18:30] <charles> I just spoke to tvoss about it a few minutes ago, iiuc he's doing it
[18:30] <asac> ok, but we dont know how?
[18:31] <ogra_> magic !
[18:31] <ogra_> he will swing his wand
[18:31] <charles> looks like he's not idling here, I'll ping him to join
[18:31] <asac> lol
[18:31] <asac> i pinged him already
[18:32] <charles> no reply yet, we'll see
[18:32] <ricmm> it is 8:30pm
[18:32] <asac> charles: are your reviews etc. done already?
[18:32]  * cjwatson gets frustrated waiting for the PPA publisher and considers spending half a day optimising it
[18:32] <asac> e.g. could you start landing if this would be avail?
[18:33] <charles> asac, if we want to wait for review signoff, ted is looking at it
[18:33] <charles> asac, if push came to shove IMO we could start landing it
[18:34] <asac> charles: in general we want MPs to get eyeball review first to avoid wasting silo/landing overhead
[18:34] <asac> tedg: ^^
[18:34] <asac> tedg: are you happy with charles branches :)?
[18:34] <ricmm> asac: in general we want more than eyeball
[18:34] <asac> yeah
[18:34] <asac> eyeball and pre-testing etc.
[18:34] <asac> every compnent should have a check list that should be followed
[18:35] <asac> ricmm: any idea how tvoss might plan to fix /dev/alarm read-only?
[18:35] <asac> and which component he will touch
[18:35] <charles> probably ought to add wakeup tests to the indicator-datetime walkthrough plan
[18:35] <asac> yep
[18:35] <asac> please update testplan :)
[18:35] <charles> hyep
[18:35] <ricmm> asac: ogra_ this is probably an android item
[18:35] <asac> once this is fixed i will put my life in the hands of our devel images
[18:36] <ricmm> we should be able to fix those nodes permissions without much issue
[18:36] <asac> so better not regress :)
[18:36] <ricmm> ogra_: am I right?
[18:36] <asac> udev :)
[18:36] <asac> tvoss_: \o/
[18:36] <tvoss_> here we go
[18:36] <tvoss_> asac, what's up?
[18:36] <asac> 20:34 < asac> ricmm: any idea how tvoss might plan to fix /dev/alarm read-only?
[18:36] <charles> :)
[18:36] <sil2100> ricmm: how's the papi landing proceeding?
[18:36] <ricmm> sil2100: very well, there is a special unity8 AP test that misbehaves with it
[18:36] <ricmm> because the test is launching unity8 directly and not using upstart
[18:36] <sil2100> Ouch
[18:37] <ricmm> so its not inheriting environment
[18:37] <ricmm> mterry is reviewing my patch for it
[18:37] <tvoss_> asac, we have to fix /dev/alarm permissions to whatever the indicator requires
[18:37] <tvoss_> rsalveti, around?
[18:37] <asac> tvoss_: yeah, but charles said you said you will do it :)
[18:37] <asac> so wonder what you wanted to do:
[18:37] <asac> 1. find someone else to do :)
[18:37] <asac> 2. have a plan :)
[18:37] <sil2100> ricmm: thanks :)
[18:37] <charles> tvoss_: tell him ogra_'s working on it
[18:37] <tvoss_> asac, ogra_'s working on it :)
[18:38] <asac> ogra_: i assume thats news to you, so ignoring that how do we fix it :)?
[18:38] <asac> udev rule?
[18:38] <tvoss_> asac, I would think so, much like we set the permission for the haptic feedback devices
[18:38] <ogra_> i am ?
[18:39] <tvoss_> ogra_, we need to adjust permissions on /dev/alarm
[18:39]  * sil2100 EODs
[18:39] <sil2100> Or maybe not...
[18:39] <tvoss_> charles, eds would be setting the alarm?
[18:39] <ogra_> tvoss_, ah, trivial
[18:39] <charles> ogra_, just completing the blame circle from you -> me -> tvoss
[18:39] <asac> ogra_: what needs landing for that? can you do the patch so we can get that into the silo for charles fix?
[18:39] <ogra_> can someone file a bug and assign to me so i dont forget over UOS
[18:39] <charles> tvoss_, not sure I understand the question? indicator-datetime-service will be the process that calls platform-api's hardware API & sets the wakeup alarm
[18:39] <asac> ogra_: hmm. i can ping you every 30 minutes :)
[18:40] <charles> tvoss_, EDS doesn't do wakeups per se
[18:40] <ogra_> asac, ok do that then :P
[18:40]  * ogra_ wants to see how long you persist :P 
[18:40] <tvoss_> charles, okay, that runs under which user? phablet?
[18:40] <asac> ogra_: ok, whats the status on /dev/alarm permissions?
[18:40] <tvoss_> lol
[18:40] <ogra_> asac, nearly done ... 29min to go
[18:40]  * asac points out it would be better to remember if the alarms would work on ubuntu phone :)
[18:40] <asac> lol
[18:40] <ogra_> haha
[18:40] <asac> ogra_: ok, please ping me in 28 minutes so i can remember you
[18:41]  * asac thinks thats a smart solution
[18:41] <asac> hehe
[18:41] <charles> tvoss_, will check owner as soon as I can shell in
[18:41] <tvoss_> charles, ack
[18:41] <asac> ogra_: anyway, would really be cool if we could have that patch when charles and tedg are doner eviewing their patches
[18:41] <tvoss_> ogra_, I would think a group permission for writing would do it
[18:42] <asac> think that should happen in 1-2 hours earliest
[18:42] <charles> phablet runs the primary, lightdm runs its own
[18:42] <ogra_> tvoss_, ACTION=="add", KERNEL=="alarm", OWNER="system", GROUP="system", MODE="0664"
[18:42] <ogra_> seems to be 0664 already
[18:42] <asac> but where do we ship that line in?
[18:42] <asac> whats the package?
[18:42] <ogra_> asac, lxc-android-config
[18:42] <asac> in indicator-datetime directly?
[18:42] <ogra_> lib/udev/rules.d/65-android.rules
[18:42] <asac> hmm. i hate that package. caused so many regressionms :)
[18:42] <ogra_> pfft
[18:43] <tvoss_> charles, is the indicator in group system?
[18:43] <tvoss_> charles, or better: the indicator user?
[18:43] <tedg> We don't have any special permissions for the indicators today.
[18:43]  * tedg is back
[18:43] <asac> hey tedg :)
[18:44] <charles> tvoss_, ^ what tedg said wrt permissions
[18:44] <asac> we need your pedantic review and testing role for charls alarm MPs :)
[18:44] <asac> tedg: ^^
[18:44] <asac> :)
[18:44] <charles> he knows, I've been pestering him in PM
[18:45] <asac> you never know :)
[18:45] <tedg> Heh, yeah. I figured it was a DoS attack on my IM client at first ;-)
[18:45] <rsalveti> tvoss_: what's up?
[18:46] <rsalveti> Mirv: are you also testing qt 5.3 on the x86 emulator?
[18:46] <asac> hope rsalveti is also here for the alarm topic :)
[18:46] <tvoss_> charles, tedg so yeah, the user under which the indicator runs should be in group system
[18:46] <ogra_> yeah, alarms on 5.3 in the emulator
[18:46] <asac> can the emulator deep sleep?
[18:47] <ogra_> the more important qurestion is "does it dream ?"
[18:48] <asac> dunno, i know that i am dreaming far too much because of the broken alarm :P
[18:48] <tedg> tvoss_, I've got no one in that group...
[18:48] <ricmm> so many words
[18:48] <ricmm> all we need is to either put phablet in system, which wont happen
[18:48] <ricmm> or make /dev/alarm 666
[18:48] <ricmm> and go to hell
[18:48] <ogra_> lol
[18:48] <ogra_> and have jdstrand show up at your home at 3am in the morning
[18:48] <tedg> Why isn't logind doing the permission here like with audio?
[18:48] <asac> is /dev/alarm confined so apps cannot access? if so 666 sounds okayish :)
[18:49] <ogra_> tedg, its handled by udev at creation time ...
[18:49] <ogra_> you could surely stack something else on top
[18:49] <tedg> Hmm, wait. If multiple users are logged in, do we want both their alarms to go off?
[18:49] <tvoss_> tedg, let's fix that post rtm
[18:50] <tvoss_> tedg, it would require global knowledge
[18:50] <asac> doesnt feel thats something that should be solved through permissions :)
[18:50] <rsalveti> ogra_: we should ideally have group to access alarm
[18:50] <ogra_> rsalveti, no prob with that
[18:50] <rsalveti> not sure we want everyone to have access to it
[18:50] <rsalveti> but yeah, let's just open it up for now
[18:50] <asac> awesome ... so 666 it is?
[18:51] <ogra_> yeah, we'll give jamie your address
[18:51] <charles> to be replaced with group later, yes?
[18:52] <rsalveti> the group won't fix the multiple user issue
[18:52] <tedg> We could make indicator-datetime sguid
[18:52] <ogra_> right
[18:52] <rsalveti> we need to think further to get that fix properly
[18:52] <ogra_> you will need a service on top
[18:52] <asac> i am not sure... if 666 is good enough for RTM and it wont fix multiuser, we probably dont need to do the group
[18:52] <tvoss_> rsalveti, right, but it will get us moving if we open up now
[18:52] <asac> ack, what rsalveti says basicall
[18:52] <ogra_> managed by logind
[18:53] <rsalveti> ogra_: something along that line
[18:53] <rsalveti> yeah, change to 666 for now
[18:53] <ogra_> ugh
[18:53] <asac> feels like something we can do when we land multiuser
[18:53] <rsalveti> so we can unblock this already
[18:53] <asac> good
[18:53] <asac> who is owning multiuser topic?
[18:53] <rsalveti> confined apps won't be able to access it anyway
[18:54] <asac> whoever that is, we should enusre he knows that we should include alarm support in this plan
[18:54] <ogra_> probably mterry
[18:54] <ogra_> as he owns the greeter
[18:54] <asac> mterry: you have a multiuser plan already? can you inject the alarm for multiuser topic if it isnt in there?
[18:54] <asac> so we wont forget?
[18:55] <mterry> asac, I have some ideas for multiuser, sure.  Didn't realize I owned it, but I suppose that makes sense.  :)
[18:55] <mterry> asac, will make a note
[18:57] <cjwatson> I'm a bit worried about the approach of "open up permissions for now, we can fix it when we do multiuser"
[18:57] <cjwatson> Not that I have a better suggestion, but it'd be pretty easy for this to bite us down the line
[18:58] <tvoss_> cjwatson, we could take the somewhat cleaner approach and add phablet to group "system"
[18:58] <cjwatson> That's an android-compat group, isn't it?
[18:58] <ogra_> cjwatson, we could just add an alarm group and add the user to it
[18:58] <ogra_> (and change the udev rule accordingly)
[18:58] <charles> that's sane...
[18:59] <ogra_> a bit more work but i agree its worth it
[18:59] <cjwatson> Possibly, yeah, though extra groups are annoying to manage if we need to remove them later
[18:59] <cjwatson> Is there no other reasonably-fine-grained existing group that would work?
[19:00] <cjwatson> How about "audio?
[19:00] <ogra_> phablet adm tty dialout cdrom sudo dip video plugdev autopilot nopasswdlogin radio bluetooth android_graphics android_input audio sdcard_rw gps android_net3 android_net android_net2
[19:00] <ogra_> thats what phablet is in atm
[19:00] <cjwatson> So tell me why audio isn't appropriate
[19:00] <ogra_> audio might work
[19:01] <asac> jdstrand: what do you suggest?
[19:01] <ogra_> not sure there are android bits on the ubuntu side of the fence that need it as systme gropup though
[19:01] <mterry> cjwatson, ogra_: does the greeter need access to this dev
[19:01] <mterry> ?
[19:01] <asac> jdstrand: making /dev/alarm 666 is too evil to do?
[19:01] <asac> :)
[19:01] <charles> hardware wakeups don't necessarily need audio
[19:01] <charles> and audio doesn't necessarily need hardware wakeups
[19:01] <charles> it's just that indicator-datetime needs both
[19:01] <ogra_> mterry, well, can the greeter contolr volume (read is it in the audio group)
[19:02] <asac> cjwatson: is it hard(er) to add a new group? or why try to reuse an existing one?
[19:02] <ogra_> asac, it is hard to remove it on installed systems
[19:02] <asac> oh session started
[19:03] <cjwatson> asac: It's annoying to manage more of them, requires changes in more places, we don't have good ways to sunset them
[19:03] <asac> k
[19:03] <cjwatson> It's certainly not impossible if that really is the right answer, but my experience is that it's worth thinking about it first
[19:04] <mterry> ogra_, it sets volume via AccountsService right now and user session that happens to be open sets it via hw
[19:04] <mterry> ogra_, but sound in the greeter is a wider problem right now
[19:04] <jdstrand> so, the phablet user is in too many groups as it is
[19:04] <asac> :P
[19:04] <mterry> ogra_, like in future, there may not be an open session
[19:04] <jdstrand> the phonedations team has todo items to clean that up
[19:05] <jdstrand> seems like we would want to avoid using a group they plan to clean
[19:05] <jdstrand> I'm not keen on 666
[19:05] <cjwatson> the set of groups that we currently add desktop users to should be fine though
[19:05] <cjwatson> the first desktop user at least
[19:07] <jdstrand> I'd like mdeslaur to comment actually, because he and mterry have talked about pk, the greeter and seat management quite a bit
[19:07] <jdstrand> is is in a session atm
[19:08] <mterry> ogra_, actually yeah, greeter can control volume because logind gives it access as the active session
[19:08] <jdstrand> mdeslaur: when you get a chance, please comment on /dev/alarm ownership. apparently indicator-datetime needs access to /dev/alarm. some have suggested 666 for /dev/alarm (yuck), others to add a group and other to use 660 with an existing group (eg, 'audio')
[19:08] <mterry> I guess this would be similar issue
[19:09] <ogra_> yeah
[19:12] <jdstrand> mdeslaur: also note that the phablet user is in too many groups atm and that phonedations is hoping to clean that up for rtm (ie, adding a group or reusing an android group may not be the best choice if we are just going to remove it later)
[19:15] <ogra_> jdstrand, there are groups we need because the android bits need to be able to use them with the right UID ... android is all about groups, no other proper device control mechanism there
[19:16] <ogra_> so if we change them things start to break
[19:17] <rsalveti> audio group doesn't seems right though
[19:17] <rsalveti> the main feature here is being able to wake up the system by triggering alarms
[19:17] <rsalveti> has nothing to do with audio itself
[19:19] <ogra_> well, i dont see another group that would fit better in the list
[19:19] <ogra_> android_input ?
[19:19] <rsalveti> well, we could just use any group then :-)
[19:19] <ogra_> right
[19:19] <ogra_> audio is as good as any other
[19:20] <rsalveti> right
[19:20] <rsalveti> cdrom
[19:20] <rsalveti> hahah
[19:20] <rsalveti> just noticed phablet is part of that
[19:20] <ogra_> lol, right, thats a spare one
[19:20] <rsalveti> maybe phablet group?
[19:21] <rsalveti> as this will be single user only anyway
[19:21] <ogra_> yeah
[19:21] <ogra_> works too
[19:21] <ogra_> can we make it 0660 ?
[19:21] <rsalveti> at least not 666
[19:21] <rsalveti> yup
[19:22] <ogra_> or do you think the 4 is needed in the end
[19:22] <rsalveti> 0660 system:phablet
[19:22] <rsalveti> right
[19:22] <rsalveti> don't think reading is bad
[19:22] <rsalveti> but won't help in anyway
[19:22] <rsalveti> so just put 0660
[19:22] <rsalveti> easier to open up than close it down later
[19:23] <ogra_> yeah
[19:24] <mterry> Again, consider greeter
[19:24] <mterry> Or multi-user in general
[19:26] <ogra_> http://paste.ubuntu.com/7625093/
[19:28] <rsalveti> ogra_: looks fine
[19:28] <rsalveti> mterry: in which terms?
[19:29] <rsalveti> who will be reading the alarm device file?
[19:29] <rsalveti> charles: ^
[19:29] <rsalveti> as which user?
[19:29] <mterry> rsalveti, I guess i'm not 100% clear on the use case we're talking about.  But if greeter needs the same permissions, phablet group won't cut it.  Nor I imagine will that work great for multi-user devices?
[19:29] <rsalveti> in the greeter use case
[19:29] <mterry> rsalveti, the user for greeter is lightdm:lightdm
[19:29] <rsalveti> mterry: we're not trying to solve the multi-user case atm
[19:29] <charles> rsalveti, the phablet user runs the main indicator-datetime service
[19:30] <charles> rsalveti, lightdm also runs one
[19:30] <rsalveti> right
[19:30] <rsalveti> charles: what is the service started by lightdm?
[19:30] <mterry> rsalveti, charles: in not-too-distant future, consider the possibility of an encrypted home dir where the greeter is running but user session isn't
[19:30] <rsalveti> mterry: sure, in that case the alarm shouldn't even be enabled
[19:30] <mterry> Probably not RTM
[19:30] <rsalveti> I'd imagine
[19:31] <charles> rsalveti, for both users it's indicator-datetime-service
[19:31] <rsalveti> how to trigger a user alarm if the user session is not even up
[19:31] <ogra_> it is up
[19:31] <ogra_> (currently at least)
[19:31] <mterry> rsalveti, well we have an external location for some information (AccountsService) -- conceivably, the alarms could be stored there.  Depends if design wants alarms to work in that case
[19:31] <ogra_> we have constantly two sessions running now
[19:31] <rsalveti> in case the user session is not up, on a multi-user use case
[19:32] <mterry> ogra_, rsalveti: right.  I was just listing future scenarios where this current plan is insufficient
[19:32] <rsalveti> right
[19:32] <rsalveti> for sure, we're not trying to solve that right now
[19:32] <rsalveti> all we want is a working solution for a single user and not cause any more damage later on, once we implement the multi-user use case
[19:32] <charles> +1
[19:33] <ogra_> mterry, for that we will need a service sitting on the alarm device anyway ... and then drop all the gruop hackery
[19:34] <rsalveti> right, ideally we want to have someone controlling the hw access
[19:34] <mterry> Sure, I'm not trying to be stop energy.  Just better to know future plans when doing something shorter term
[19:34] <mterry> Well that's probably logind, which controls access to all sorts of devices already
[19:35] <mterry> For example, the fact that phablet is in audio group is a hack around that, back when logind wasn't configured correctly
[19:35] <mterry> But this current group plan is fine for now
[19:35] <mterry> Logind needs more smarts anyway to do the right thing
[19:35] <rsalveti> right
[19:36] <ricmm> robru: hey, are you alive?
[19:36] <robru> ricmm, barely
[19:36] <robru> what's up?
[19:36] <ricmm> robru: ;)
[19:36] <ricmm> robru: is it possible to remove an MR from a silo, and thus drop the already-built pkg from it?
[19:37] <ricmm> is the only way a full reconf/rebuil? or is there a shortcut
[19:37] <robru> ricmm, yep I can take care of that.
[19:37] <robru> oh hmm
[19:37] <robru> ricmm, reconf is definitely necessary, it *should* be possible to avoid a full rebuilt by doing a WATCH_ONLY build but that's been buggy lately
[19:38] <robru> ricmm, did you take the MP out of the spreadsheet yet?
[19:38] <ricmm> no, not yet
[19:38] <ricmm> its a possibility with a fix im working on
[19:38] <robru> ricmm, ok just let me know, I'll have to delete the package from the PPA manually
[19:38] <ricmm> alright
[19:59]  * mdeslaur reads backscroll
[20:00] <robru> ricmm, just a heads up, we're about to publish telephony-service, so that'll at least need a rebuild in your silo soon
[20:00] <sil2100> o/
[20:01] <ricmm> robru: how long until it hits trunk?
[20:02] <mdeslaur> ogra_, jdstrand, mterry: so that does /dev/alarm do exactly?
[20:02] <asac> did we reach agreement on what to do with the 666?
[20:02] <asac> :)
[20:03] <asac> charles: ?
[20:03] <asac> sorry was focussed on session
[20:05] <mdeslaur> ogra_, jdstrand, mterry: ah, so it wakes up the device...in a multiuser scenario, in theory some sort of system power daemon would manage that, and the user would use a dbus call to set it which would use policykit and would make sure the user owns the current session
[20:05] <bfiller> robru: can I have a silo from line 39 please?
[20:12] <robru> bfiller, sure
[20:12] <robru> barry, ^ wanna do it? ;-)
[20:12] <barry> monkey wakes up
[20:12] <robru> ricmm, oh sorry, missed you message. probably a couple horus
[20:13] <barry> bfiller: silo 12
[20:14] <bfiller> barry: thanks
[20:16] <robru> barry, so, eg if you look at https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&rm=full&pli=1#gid=30, the spreadsheet for the silo page, the button there is called "merge & clean", that's why the bot says "click merge & clean". my dashboard page is newer than both of those things though
[20:16] <barry> robru: ah
[20:17] <robru> barry, alright, I'm going to pop off for lunch, back soon!
[20:17] <barry> sounds good
[20:21] <asac> rsalveti: did we agree on 666?
[20:21] <rsalveti> asac: we decided to use 0660 and system:phablet for now
[20:21] <asac> cool
[20:21] <asac> rsalveti: who is landing what?
[20:21] <rsalveti> ogra_ did the debdiff, not sure if he already uploaded it
[20:22] <asac> we probably want that to go into the same silo that charles will use?
[20:22] <ricmm> robru: well, lets see, maybe im there first ;D
[20:23] <ricmm> robru: I'll make sure to rebuild otherwise
[20:23] <rsalveti> could land separately, but won't hurt to make it as part of that sile
[20:23] <rsalveti> *silo
[20:23] <asac> yeah, lets put it in there
[20:23] <asac> so we test the real thing together
[20:23] <rsalveti> sure
[20:23] <rsalveti> ogra_: ^
[20:23] <asac> do we need to do something so that indicator runs as the right user/group too?
[20:23] <asac> charles: do you already need/have a silo?
[20:23] <asac> tedg: how do the reviews look like? :)
[20:24] <tedg> asac, I think that jenkins tripped over itself :-/
[20:24] <asac> tedg: how about the code review by your eyeballs? does that look good?
[20:24] <tedg> asac, yes, that looks good.
[20:25] <asac> tedg: did you test it locally too?
[20:25] <tedg> asac, Not for a code review, will for the silo landing.
[20:25] <asac> k
[20:26] <asac> tedg: what is missing from here: https://wiki.ubuntu.com/Process/Merges/Checklists/indicator-datetime ?
[20:27] <asac> just jenkins? :)
[20:27] <tedg> Yup, though that gets updated a bit in the MR.
[20:27] <asac> guess the unit tests would be run in the ppa too?
[20:28]  * asac thinks that jenkins build and unit tests would be happening in the silo ppa anyway, so is kind of fine to fastpath if we are confident that both will work
[20:28] <tedg> Yes
[20:28] <asac> but your guys call (its your checklist etc.)
[20:29] <tedg> Uhm, yeah, in general though I try to avoid using silos until we're sure it builds somewhere in infrastructure.
[20:29] <tedg> They're usually in demand.
[20:29] <asac> ack
[20:29] <asac> tedg: can you try build locally?
[20:29] <asac> :)
[20:29] <asac> not sure what is going on wiht the CI bot jenkins, maybe its just a retry
[20:29] <tedg> I did and it works. But my machine is way easier to build things on than Jenkins :-)
[20:29] <asac> check with vanguard i guess
[20:30] <asac> tedg: your x86 machine? or your phone/arm?
[20:31] <tedg> I didn't build it on the phone, but that is easier to build on than Jenkins as well.
[20:31] <tedg> It has a bunch of dev stuff on it.
[20:31] <asac> k
[20:31] <asac> well, you guys know how to do things right
[20:31] <asac> robru: how manu silos are free?
[20:32] <tedg> Spreadsheet says 2
[20:32] <tedg> G1
[20:32] <asac> heh
[20:35] <asac> hmm. had bip problems
[20:38]  * asac reboots bip machine after sec update - maybe ttyl :)
[20:43] <ricmm> thomi: hey, are you awake? :)
[20:45] <asac> tedg: so did you convince yourself that building and testing on your phone might help us to move forward :)?
[20:45] <balloons> fginther, just checking to confirm / deny trusty has been removed from core apps builds.. specifically I need it gone from reminders atm :-)
[20:45] <asac> tedg: would be cool to really follow rule book
[20:46] <asac> tedg: you need that phone wiped for testing the silo anyway, so the earlier to say good bye to thwat is on it the less likely you will try to dodge that step :)
[20:47] <tedg> asac, Not sure why building on the phone is "following the rule book" ?
[20:47] <tedg> AFAICT the rules state that Jenkins needs to be happy, which is exactly what I'm doing.
[20:47] <tedg> You're suggesting skirting around the rule book.
[20:48] <tedg> And, none the less, testing on the phone isn't all that's required for an indicator. I would hope that people don't think that's adequate.
[20:48] <fginther> balloons, sorry about that, updating the jobs right now (the currently running jobs will need to finish before it's done-done)
[20:49] <balloons> fginther, lol.. you can cancel them all then
[20:49] <ricmm> tedg: did you test on the phone or not?
[20:49] <asac> tedg: point taken, what i sensed though by you saying that you dont want to kill your phone setup is that you wont test the silo :)
[20:49] <asac> point about rul book
[20:49] <asac> not the rest :L)
[20:49] <balloons> fginther, I top approved several pending merges under the assumption, then thought I should ask
[20:49] <ricmm> just wondering about phone testing before we go into proper silo testing and deployment
[20:49] <ricmm> so pre-siloing
[20:49] <tedg> I'll test the silo, but testing isn't a code review
[20:49] <balloons> fginther, I can can them
[20:49] <ricmm> consiering this is a phone HW alarms related task, its worth checking on the phone
[20:50] <thomi> ricmm: yup
[20:50] <ricmm> and by the phone I mean the phone an a tablet, as their sleep behaviours are different
[20:50] <fginther> balloons, thanx
[20:50] <ricmm> thomi: \o/ good morning
[20:50] <ricmm> thomi: can I tell autopilot to run tests in the order I want?
[20:50] <ricmm> I want to run three tests from the unity8 suite
[20:50] <ricmm> but autopilot seems to be deciding what order to run them on, or phablet-test-run, whatever does it
[20:51] <ricmm> I dont have greater knowlege of these tools, so wondering if you can shed some light
[20:51] <thomi> ricmm: yup, you can list the test ids explicitly, one after the other on the command line
[20:51] <fginther> balloons, reminders is now updated, it's ok to approve again
[20:51] <ricmm> I did, but its rearranging the order
[20:51] <ricmm> :(
[20:51] <thomi> 'autopilot run test.id.one test.id.two ...'
[20:51] <balloons> fginther, awesome thanks
[20:51] <ricmm> to whatever it pleases
[20:51] <thomi> ricmm: hmmmm. so veebers is now looking after autopilot - you should talk to him :)
[20:51] <ricmm> but do you know?
[20:52] <ricmm> consiering its your brainchild
[20:52] <ricmm> veebers: or you :)
[20:52] <thomi> ricmm: I suspect it's a bug, no onen has reported it yet
[20:52] <veebers> ricmm: hey, just checking something one mo :-)
[20:52] <ricmm> thank you!
[20:53] <veebers> ricmm: hey, no way currently to set the order specifically (you can randomise so it's different each run though ;-) )
[20:53] <veebers> ricmm: a workaround right now, which is a pain I know, is go: autopilot run test.id1; autopilot run test.id2  . . .
[20:54] <veebers> I haven't came across anyone needed to run suites in a specific order as of yet
[20:56] <robru> ricmm, sorry about that, was on lunch. yeah, silo 19 is merged now, you'll have to rebuild telephony-service
[20:56] <ricmm> robru: alright, im on it
[20:56] <ricmm> will wait for my other branches to rebuild tho
[20:57] <robru> ricmm, no rush, just needs to be done before you can publish
[20:57] <rsalveti> crap, disconnected
[20:57] <ricmm> veebers: how can I randomise?
[20:57] <ricmm> I only have two tests, I'm sure ill hit the right order eventually ;)
[20:57] <veebers> ricmm: heh :-) argument to run: "-ro, --random-order " (i.e. from autopilot run --help)
[20:58] <veebers> ricmm: why is the order important?
[21:03] <ricmm> can I pass that to phablet-test-run somehow?
[21:03] <ricmm> veebers: well I have an odd feeling that one test isnt reverting some stuff in the teardown as it should
[21:03] <ricmm> and the order might be impacting
[21:04] <veebers> ricmm: ah I see, um I'm not sure about phablet-test-run. I think either 1 of fginther, doanac or something might be able to answer that question (or point you at who can)
[21:05] <ricmm> veebers: ok
[21:05] <ricmm> veebers: to confirm, each test kills the previous running instance of autopilot and brings up a new one?
[21:05] <ricmm> or does it all run in the same "env"
[21:05] <veebers> ricmm: the autopilot process is the same across a whole run
[21:06] <fginther> ricmm, you can try using the '-x' option to phablet-test-run to run whatever cmd line you need to give it
[21:06] <veebers> ricmm: if any environment variables are altered within the test using the correct mechanism (i.e fixtures.EnvironmentVariable or deprecated patch_environment) they are reset after the test ends
[21:07] <fginther> ricmm, but you can't otherwise change the options passed to autopilot by default
[21:08] <ricmm> I want to run all three tests, in one autopilot run, in the order I want
[21:09] <ricmm> can I achieve that with any of the cmd line runners?
[21:09] <thomi> ricmm: how about 'phablet-test-run -x "autopilot run test_one; autopilot run test_two; autopilot run test_three"' ?
[21:10] <ricmm> veebers: its using patch_environment() but I'm still weary of it
[21:13] <veebers> ricmm: do you know what it may or may not be modifying (i.e. is it an env var)? Perhaps you could modify the test to log out the contents of envat the start and end of the tests
[21:14] <ricmm> I guess I can try that
[21:14] <ricmm> but then I need to run the full suite again, heh
[21:14] <ricmm> oh wait nevermind, im being dumb
[21:14] <ricmm> maybe because its late
[21:14] <veebers> heh :-)
[21:14] <ricmm> I think I can get rid of that env patching
[21:17] <ricmm> robru: ok, I've pushed a build req for telephony-service plus my two packages
[21:18] <ricmm> in the end we wont need to remove one of them
[21:18] <ricmm> just rebuil
[21:18] <robru> ricmm, cool
[21:22] <tedg> robru, So for the android change, I've not had an "extra package" before. Is that something that I need to upload?
[21:22] <tedg> robru, Or does it happen automagically?
[21:22] <rsalveti> tedg: I already did
[21:23] <tedg> rsalveti, ? to the PPA?
[21:23] <rsalveti> tedg: yup
[21:23]  * tedg refreshes
[21:23] <tedg> Ah, okay.
[21:23] <rsalveti> needs someone with enough permission to upload it directly to the ppa
[21:23] <tedg> rsalveti, Thanks! Is that something I should have done had I known? :-)
[21:23] <tedg> Oh, okay.
[21:27] <robru> yeah, nothing magical about CI Train
[21:37] <bfiller> robru: we need a silo for line 33 (telephony-service) - not sure if this was waiting on anything to be cleared in other silos first
[21:37] <bfiller> is that the ricmm stuff?
[21:37] <robru> bfiller, ricmm has a silo with telephony-service yeah
[21:37] <rsalveti> there's plat v2 from ricmm
[21:37] <robru> ricmm, are you close to landing?
[21:37] <bfiller> ok
[21:38] <robru> bfiller, the funny thing is, ricmm *just* started a rebuild on telephony-service because we just published a conflicting one a couple hours ago.
[21:38] <robru> bfiller, so if ricmm isn't ready to land today I'd say we can do yours, but I don't want to step on his toes if he's just moments away from publishing...
[21:38] <bfiller> robru: no rush, we'll just wait for his to land
[21:38] <robru> bfiller, ok great
[21:39] <rsalveti> ricmm: what else is needed besides the packaging review by seb?
[22:02] <charles> rsalveti, I'm getting an error installing lxc-android-config from silo 14
[22:03] <charles> rsalveti, http://paste.ubuntu.com/7625734/
[22:08] <rsalveti> oh, indeed, that needs special instructions, to be done from recovery
[22:08] <rsalveti> let me find it
[22:16] <rsalveti> charles: http://paste.ubuntu.com/7625773/
[22:16] <charles> rsalveti, ty
[22:27] <ricmm> robru: im working on it
[22:27] <ricmm> robru: some things just finished building
[22:28] <ricmm> I need to run some clean tests with the current silo state and DONE
[22:28] <robru> ricmm, sweet, i can publish, just say the word
[22:29] <ricmm> it will need seb to look at it in the morning, he said he would today but it didnt happen in the end
[22:29] <ricmm> as he needs to ack some NEWs
[22:30] <ricmm> rsalveti: still alive?
[22:44] <rsalveti> ricmm: yes
[22:44] <rsalveti> looking for dinner, but around
[23:04] <tedg> rsalveti, Got an error when upgrading lxc-android-config, should I be concerned about it?
[23:15] <tedg> rsalveti, unping, charles set me straight
[23:16] <tedg> Looking for a tablet, neither myself nor charles has one to test silo 14.
[23:16] <tedg> If someone has a tablet and can test it that'd be great, else we can ask folks in the morning.