[01:11] <AlbertA> barry: utopic landing-006 is ready to publish
[01:22] <AlbertA> trainguards: utopic landing-006 is ready to publish
[01:23] <barry> AlbertA: you just caught me, i will publish for you
[01:23] <AlbertA> barry: cool thanks!
[01:26] <barry> AlbertA: ^^ the packaging changes need review.   can you look?  (i will too)
[01:27] <barry> AlbertA: https://launchpadlibrarian.net/186938422/trust-store_1.1.0%2B14.10.20141008.1-0ubuntu1_1.1.0%2B14.10.20141009-0ubuntu1.diff.gz
[01:28] <AlbertA> barry: yeah looks ok to me
[01:28] <barry> AlbertA: i will ack the pack
[01:29] <barry> AlbertA: good night!
[01:29] <AlbertA> barry: thanks!
[01:29] <AlbertA> barry: good night
[01:49] <slangasek> cjwatson: where is "http://archive-team.internal/click_packages" and how is it maintained?
[01:57] <slangasek> oh, snakefruit
[02:09] <imgbot> [02:45] <tedg> trainguards, can you please assign a silo for line 48 ?
[02:50] <tedg> barry, Are you still up by chance? ^
[03:09] <imgbot> [04:13] <Mirv> tedg: sure
[04:13] <Mirv> and morning
[04:14] <Mirv> tedg: there are other indicator-landings still in rtm, but it's not completely problematic since they've landed in utopic so the trunks are up-to-date.
[04:19] <Mirv> tedg: right, the rtm-008 is not your silo actually, but sergiusens' - that has indicator-transfer and needs to go in before this new sync silo.
[04:34] <Mirv> tedg: you'll need to reland https://code.launchpad.net/~ted/indicator-sound/silent-mode/+merge/236971 since you landed "Revert notifications on volume change." in-between.
[04:35] <Mirv> oh, actually, it was rebuilt but just not picked by the CI Train. interestingly complex case here.
[04:43] <Mirv> ~200 clicks later, still clicking...
[04:47] <Mirv> phew, finally
[04:48] <Mirv> tedg: ok, ignore all above and be happy you don't need to operate the Train :) 017 has landed towards utopic, and rtm-012 is a sync of it.
[07:14] <abeato> morning
[07:14] <abeato> would it be possible to get permissions for the spreadsheet?
[07:34] <abeato> sil2100, morning, would it be possible to get permissions for the spreadsheet?
[07:35] <sil2100> abeato: sure!
[07:35] <sil2100> abeato: one moment
[07:36] <abeato> sil2100, thanks
[07:43] <Mirv> bzoltan: so. you maybe want to forget about line 20 (01.10. landing) and go straight to the line 31 to sync the rtm uitk, test that on utopic and publish.
[07:43] <Mirv> bzoltan: tell me if you want to arrange like that.
[07:44] <bzoltan> Mirv: I started to lend the next round to the RTM. We havbe two critical bug fixes there.
[07:44] <bzoltan> Mirv:  I am not sure if it has any value to run my 6-8 hours tests on Utopic.
[07:45] <bzoltan> Mirv:  I would just simple release the line 31 as it is exactly as good as it was for RTM
[07:45] <Mirv> bzoltan: sil2100: shall we start waiting for v-series for UITK?
[07:45] <Mirv> bzoltan: right, that's another option, one more release since that was already built, and then focus on rtm for a moment.
[07:45] <Mirv> final freeze is anyway next Thu
[07:46] <sil2100> hmm
[07:46] <Mirv> bzoltan: oh right 31, so sync that, then publish. maybe you'd need to smoke-test it anyhow, but 6-8h maybe overkill.
[07:46] <bzoltan> Mirv:  let's do a real and big Utopic/RTM landing with this round...
[07:48] <Mirv> bzoltan: so, your next landing with critical fixes? include the gles, and when it lands to rtm also sync to utopic. but abandon these two landings from utopic?
[07:51] <sil2100> So you want to skip a release for utopic? I think the archive admins won't like that...
[07:52] <Mirv> sil2100: so there is already a second UITK landed in rtm that has not landed in utopic. so the question is whether to land the first one (line 20, built, not tested), the second one (line 31, not built/synced, not tested) or the next one (upcoming rtm release with critical fixes)
[07:52] <sil2100> grrr
[07:52] <sil2100> hmm
[07:52] <Mirv> if "no skipping" is the method, then line 20 should see testing and publishing, then line 31, then the newest one
[07:53] <sil2100> Mirv, bzoltan: so, I would at least only test line 31 and just drop 20, since 31 has both versions anyway
[07:53] <sil2100> We don't require exhaustive testing for utopic so this should be fine, but I wouldn't want to delay it landing to utopic any longer
[07:54] <ogra_> seems the image builder ran out of space once again
[07:54] <ogra_> (i killed the hanging import process and cleaned /tmp ... import-images is re-running now)
[07:55] <sil2100> ogra_: I wonder why earlier this was not a problem, since I'm pretty sure UTF8 characters were present in files we were removing from the images for sure
[07:55] <bzoltan> Mirv:  yes, that is the plan
[07:55] <Mirv> bzoltan: read the whole thread :) https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-019 will have the "current RTM versions" in about 20 minutes published. you could smoke test those and mark line 31 ready for landing.
[07:55] <ogra_> sil2100, there were still a few tmp dirs left around from last time ... and i think we got new custom channels
[07:56] <Mirv> bzoltan: but I'll anyway remove line 20, since it's older
[07:56] <Mirv> (if ok)
[07:57] <ogra_> ARGH !
[07:57] <ogra_>   File "/srv/system-image.ubuntu.com/bin/../lib/systemimage/diff.py", line 199, in generate_diff_tarball
[07:57] <ogra_>     removed_files = "%s\n" % removed_files.encode('utf-8')
[07:57] <ogra_> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 27881: ordinal not in range(128)
[07:57] <ogra_> damn !
[07:58] <bzoltan> Mirv:  yes, it is OK
[08:00] <Saviq> trainguards, hey, for some reason row 43 doesn't get marked for QA signoff
[08:00] <sil2100> Saviq: let me loook
[08:00] <sil2100> Saviq: fixed! Spreadsheet ate a formula
[08:00] <sil2100> ;p
[08:01] <Saviq> sil2100, thanks
[08:02] <Mirv> Saviq: I even restorted the formula once today already
[08:02] <Saviq> Mirv, hmpf
[08:03] <Saviq> who do I bribe to put my rtm silo on top of the queue? ;P
[08:04] <Mirv> Saviq: probably brendand :)
[08:04] <Mirv> but I believe that HERE landing is important too
[08:04] <Saviq> I'm not asking what's important TO YOU ;P
[08:04] <Mirv> Saviq: ;)
[08:05] <Saviq> this'll be the last sync silo for unity8 I imagine
[08:10] <brendand> Saviq, let me here your offer
[08:11] <brendand> s/here/hear/
[08:11] <Saviq> brendand, you're selling, you set the price ;)
[08:11] <ogra_> "mapping" error :)
[08:11] <brendand> ogra_, yeah what an appropriate typo
[08:12] <brendand> Saviq, it's going to get looked at soon anyway, so don't worry
[08:13] <pstolowski> brendand, hey, is rtm/landing-010 (line #30) on your radar? can you add it to your queue?
[08:13] <Saviq> brendand, sure, j/k ;)
[08:13] <Saviq> brendand, it would've been up for testing since last night... but spreadsheet was hungry :|
[08:14] <brendand> pstolowski, it will be when it's built and tested
[08:17] <pstolowski> brendand, it was built, and i marked it as tested
[08:19] <sil2100> pstolowski: ok, the same thing - spreadsheet ate a formula from your landing
[08:19] <sil2100> So the status wasn't visible
[08:20] <sil2100> Now it's all ok
[08:20] <davmor2> Morningall
[08:20] <sil2100> Morning
[08:20] <brendand> pstolowski, there you go - in our queue now
[08:22] <pstolowski> brendand, thanks
[08:30] <sil2100> Mirv, bzoltan: before assigning the silo for the new landing of UITK, I would really like to see all the previous releases landing in utopic now
[08:31] <sil2100> Since the assumption of allowing landing first in RTM before utopic is that it gets *instantly* synced up to utopic
[08:31] <Mirv> bzoltan: ^ so, land line 31
[08:32] <sil2100> Not in batches, as then the main principle of RTM will be broken
[08:32] <sil2100> i.e. that everything in RTM needs to be in utopic
[08:32] <Mirv> sil2100: ah, so first 20, then 31. ok. bzoltan <- both 20 and 31 are built.
[08:33] <sil2100> Mirv: well, if bzoltan tests only 31, it includes 20 already, right?
[08:34] <Mirv> sil2100: yes, it includes, but I thought if you mean that both need to land to have the same publishing history.
[08:34] <sil2100> Mirv, bzoltan: since my only requirement here is that we have ubuntu and ubuntu-rtm in sync
[08:34] <Mirv> sil2100: ok
[08:34] <sil2100> Mirv: well, in theory the second landing shouldn't land without landing the first one in utopic, so it's anyway bad now ;p
[08:35] <Mirv> bzoltan: sil2100: therefore only landing 019 / line 31
[08:35] <Mirv> sil2100: FYI CI Train has just allocated a silo that was already allocated :S
[08:35] <sil2100> WTH?!
[08:35] <Mirv> abeato: I need to kill your ofono and reassign a silo
[08:35] <sil2100> o_O
[08:35] <Mirv> sil2100: that 019 where uitk synced to.. it's now allocated to ofono somehow
[08:35] <abeato> Mirv, ok, I was trying to reconfigure but it did not seem to work :/
[08:36] <abeato> the uitk packets were in the silo and I did not find a way to remove them
[08:36] <bzoltan> Mirv:  sil2100: just tell me what should I do :) Do I start testing the  line 31 or line 20 or what?
[08:36] <sil2100> bzoltan: line 31 please! :) As 31 already has 20 in it, we can trash 20 and just land 31 (which has 2 releases in it)
[08:37] <abeato> Mirv, great, thanks
[08:38] <Mirv> bzoltan: final decision! :) test landing-019 utopic (line 31). it's ready already, don't mind the messages that flow here currently.
[08:38] <bzoltan> Mirv: OK
[08:39]  * bzoltan goes away to his test cave
[08:39] <imgbot> [08:39] <imgbot> [08:39] <imgbot> [08:40] <imgbot> [08:40] <sil2100> davmor2: ping
[08:40] <abeato> Mirv, so now I need to wait for another silo?
[08:41] <Mirv> abeato: yeah, sorry about that. CI Train did something really funny and combined yours and zoltan's silos.
[08:41] <abeato> Mirv, ok, hmm, weird...
[08:41] <Mirv> "Trying to reach google.com..."...
[08:52] <Mirv> abeato: sorry, also in hangout at the same time :) building now at https://ci-train.ubuntu.com/job/ubuntu-landing-021-1-build/13/console
[08:53] <abeato> Mirv, no worries, thanks
[08:57] <bzoltan> sil2100: Mirv: what image should be my testing baseline?
[08:57] <sil2100> bzoltan: latest utopic I suppose!
[08:58] <Mirv> bzoltan: latest utopic yes
[09:01] <bzoltan> Mirv: sil2100: Sorry, but i am lost -> http://ci.ubuntu.com/smokeng/utopic/
[09:03] <Mirv> bzoltan: yeah I understand. touch_stable is actually rtm. http://ci.ubuntu.com/smokeng/utopic/touch/ has the utopic builds.
[09:03] <Mirv> so 275 is latest
[09:03] <Mirv> oh, the results are quite crappy. 271 has the latest full results.
[09:04] <bzoltan> Mirv:  271 it is.. thanks
[09:05] <popey> ogra_: https://code.launchpad.net/~popey/ubuntu-seeds/ubuntu-touch.utopic-remove-evernote can that merge asap pls?
[09:10]  * ogra_ installs 95
[09:13] <ogra_> seems ok
[09:28] <Saviq> ogra_, you had the sshebang to list OOM scores somewhere?
[09:28] <Saviq> found it
[09:30] <Saviq> ogra_, davmor2, could you guys please try the dash oom-killed with the .debs from https://code.launchpad.net/~unity-team/qtmir/dash-killed-less-likely/+merge/237915/comments/583630
[09:30] <Saviq> not qtmir-desktop, of course
[09:31]  * Saviq can't play videos in the BBC app
[09:31] <davmor2> Saviq: maybe
[09:32] <ogra_> Saviq, try tagesschau.de ... i think thiat works in poland
[09:32] <ogra_> or any other news site that has videos
[09:37] <ogra_> hmm, i cant get it to crash now
[09:37] <ogra_> (s/crash/restart/)
[09:39]  * ogra_ starts moar apps
[09:39] <sil2100> THat's good, right..?
[09:39] <ogra_> no
[09:40] <ogra_> ah, finally it restarted
[09:40] <ogra_> ok, now lets try the new packages
[09:46] <abeato> Mirv, question, is any action required on my side to get the silo for rtm?
[09:49] <Mirv> abeato: currently yes, there's the second line I added for you beneath your line, for rtm. once you've tested the utopic landing, a trainguard will assign you an rtm silo and sync the utopic landing to there. then you need to test the rtm silo again.
[09:49] <Mirv> more automated dual landings are however coming really soon now, possibly today
[09:51] <abeato> Mirv, so I test, then mark Test pass in spreadsheet, and I ping some trainguard?
[09:51] <Saviq> ogra_, seems to be working, couldn't get the dash to get killed
[09:51] <ogra_> Saviq, yep, same here
[09:52] <ogra_> the score never goes above 502 too
[09:52] <ogra_> err 505
[09:52] <Mirv> abeato: yes, for example. the utopic one will be published, and rtm silo synced from there.
[09:52] <ogra_> vs 802 for everything else thats backgrounded
[09:52] <sil2100> abeato: yes, once you switch it to tested done, we will publish it for you
[09:52] <abeato> sil2100, Mirv , awesome, thanks
[09:52] <ogra_> Saviq, i'd say land it :)
[09:53] <Saviq> ogra_, now I need to make greyback approve it is all
[09:53] <Saviq> ogra_, and then camako needs to deal with the mir landing...
[09:53]  * greyback takes the hint
[10:01] <davmor2> Saviq: doesn't crash here
[10:02] <john-mcaleely> trainguards - I have a device tarball to go with ubuntu/landing-003
[10:02] <sil2100> john-mcaleely: hm, we'll need to get this silo to ubuntu-rtm then
[10:03] <Saviq> davmor2, awesomes
[10:03] <john-mcaleely> sil2100, so, the device tarball can land after the silo safely
[10:03] <Saviq> davmor2, BUT IT WASN'T CRASHING!!! :P
[10:03] <ogra_> sil2100, john-mcaleely the image builder is broken though ... that will need a bit of manual massaging
[10:03] <john-mcaleely> heh
[10:03] <davmor2> Saviq: restarting then :P  It felt like a crash and that is what people would of thought it was :P
[10:03] <john-mcaleely> sil2100, ogra_ I'll get a set of formal test results for the device tarball, and then we can go from there
[10:04] <sil2100> john-mcaleely: ok, thanks!
[10:04] <ogra_> john-mcaleely, ok
[10:05] <cjwatson> ogra_: if you mean system-image, Stéphane is on the case now
[10:05] <sil2100> hmmm
[10:05] <sil2100> tvoss: ping
[10:05] <tvoss> sil2100, pong
[10:05] <tvoss> sil2100, how can I help?
[10:06] <sil2100> tvoss: so, I have a question - since there is silo ubuntu/landing-003 with location-service that's required for the device tarball bits, so I wanted to fill in a sync silo for it to ubuntu-rtm
[10:06] <sil2100> tvoss: but I see there's ubuntu-rtm/landing-001 already
[10:06] <sil2100> tvoss: which has dbus-cpp and location-service
[10:06] <tvoss> sil2100, I think that's lool's and superseded by rtm 5
[10:06] <tvoss> lool, ^?
[10:07] <ogra_> cjwatson, yay ... i had to run it once with py2 til it fails and then re-run it with py3 to make it publish ... it had filled up /tmp again over night
[10:17] <sil2100> ogra_: https://code.launchpad.net/~sil2100/phablet-tools/citrain_custom_distro/+merge/237935 <- that's a quickie, but do you think this would manage?
[10:18] <ogra_> sil2100, yeah, looks ok
[10:18] <sil2100> ogra_: I tested both cases and it doesn't seem to break anything
[10:19] <ogra_> approved
[10:19] <sil2100> Thanks! We need this released now through the train, right? You use MPs?
[10:20] <sil2100> tvoss: I would need to know, since as you see there are at least 2 silos with location-service, while in utopic there's a new one ready for release that's needed by the device tarball
[10:21] <tvoss> sil2100, the device tarball does not need the silo
[10:21] <tvoss> lool, ping
[10:34] <popey> when was the last promoted utopic image?
[10:34] <popey> was it really 243?
[10:36] <sil2100> It's been a long time...
[10:36] <sil2100> We don't have the resources for that right now
[10:37] <popey> also http://paste.ubuntu.com/8532116/
[10:37] <sil2100> ogra_: do you normally release phablet-tools through MPs?
[10:37] <popey> emulator seems broken.
[10:37] <ogra_> sil2100, yes, but only to utopic (and once it hits the archive it needs to be copied to the PPA for trusty and precise)
[10:37] <sil2100> ogra_: ACK
[10:38] <john-mcaleely> sil2100, ogra_ new device tarball
[10:38] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141009-ba11639.tar.xz
[10:38] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141009-ba11639.changes
[10:38] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20141009-ba11639.ods
[10:38] <john-mcaleely> (plus results in other places)
[10:38] <sil2100> john-mcaleely: is it safe to land without that silo 003?
[10:39] <john-mcaleely> this is the *exact* tarball tvoss used to test silo 003
[10:39] <john-mcaleely> and it is safe to land before or after
[10:39] <ogra_> john-mcaleely, cool, after cjwatson said above that stgraber is on the case i'm not sure i should fiddle manually with the image builder though
[10:39] <john-mcaleely> sil2100, ogra_ ^
[10:39] <john-mcaleely> I'm in no hurry for it to be published. so long as it's in a queue :-)
[10:39] <sil2100> john-mcaleely: how did he test it if silo 003 is an utopic silo? I thought he was testing things on ubuntu-rtm?
[10:39] <ogra_> (so it might take a bit ... not sure where we stand atm)
[10:40] <john-mcaleely> sil2100, device tarballs work with either
[10:40] <lool> tvoss: pong
[10:40] <lool> sil2100: hey
[10:40] <lool> sil2100: device tarball is landed by hand
[10:41] <lool> sil2100: yes, I think you can dispose rtm silo 1 with dbus-cpp and location-service; superseded by the other one
[10:41] <bzoltan> sil2100: Mirv:  the silo19 gave full OK  results for UITK, browser and address book app tests. It looks good too. So I would flip that tested switch.
[10:41] <sil2100> bzoltan: \o/
[10:41] <lool> sil2100: I'm ready to land the updated custom tarballs for rtm; I did it a couple of times before; just waiting for the qa go ahead and yours
[10:41] <sil2100> bzoltan: excellent, please switch it and we publish!
[10:42] <davmor2> ogra_: I said at the beginning all this image builder stuff was all your fault ;)
[10:42] <ogra_> davmor2, definitely
[10:42] <bzoltan> sil2100:  done
[10:42] <bzoltan> sil2100:  I store the AP logs to the same place
[10:43] <Wellark> hey, did the new pin unlock dialog got to utopic yet?
[10:44] <dbarth> trainguards: hi; for note, silo rtm-002 is ready for qa signoff, but i noted that it needs to be reconfig'ed before landing, just in case
[10:44] <Wellark> seems from a report from abeato that it's at least not on mako image 274
[10:44] <Wellark> Mirv: ^
[10:44] <dbarth> let me know if that needs to happen before qa or after
[10:44] <popey> sil2100: when was the last promoted rtm image?
[10:44] <sil2100> popey: 3 days ago I think?
[10:45] <popey> found it
[10:45] <popey> ta
[10:47] <davmor2> Saviq: not sure I like the dots
[10:48] <Saviq> davmor2, I'm sure I don't
[10:48] <Saviq> davmor2, they're ugly as hell, and communicate not a gram more of what they mean
[10:49] <Saviq> davmor2, they'll go away completely when we only have favourite (and poking) apps on the launcher
[10:49] <popey> sil2100: where is the mako equivalent of http://people.canonical.com/~ogra/touch-image-stats/rtm/ ? (I assume that's krillin?)
[10:49] <davmor2> Saviq: well I guess it is meant to be a pin head for when you pin stuff
[10:49] <Saviq> davmor2, yeah, but that only works when you know what it means
[10:49] <Mirv> Wellark: dual sim? yes.
[10:50] <davmor2> Saviq: indeed, not liking it,  I wonder if I block on it being ugly if design will change their mind ;)
[10:50] <Saviq> davmor2, !!!
[10:51] <sil2100> popey: we don't have those... :|
[10:51] <abeato> sil2100, silo 21 tested (line 66), could you assign an rtm silo?
[10:51] <davmor2> Saviq: Don't worry I'll use your They're ugly as hell quote in the bug :D
[10:51] <popey> sil2100: ugh. so I can't tell whether a package is in a particular image or not ☹
[10:52] <sil2100> popey: we generate those scripts through ogra_'s script, which only is set up for two cases ;<
[10:52] <ogra_> it doesnt matter for which device it generates ... the rootfs is the same for all of them
[10:52] <Saviq> davmor2, it's a case of "we don't care" I'm afraid
[10:52] <davmor2> popey: just blame ogra_ ;)
[10:53] <ogra_> popey, you can ... you "just" need to map it to the right rootfs
[10:53] <ogra_> popey, by comparing http://system-image.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09-proposed/krillin/index.json with http://system-image.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09-proposed/mako/index.json
[10:54] <sil2100> abeato: can you make sure https://code.launchpad.net/~phablet-team/ofono/rtm-bug-fix-update-2/+merge/237879 is approved now?
[10:54] <sil2100> abeato: we can't release without approved branches :)
[10:54] <abeato> sil2100, sure
[10:54] <abeato> done
[10:55] <popey> ogra_: hah! yeah, no thanks ☻
[10:56] <abeato> sil2100, the MP is now approved, could you try again the publish step?
[10:57] <sil2100> abeato: sure!
[10:57] <abeato> sil2100, thanks lot :)
[10:58] <sil2100> abeato: done! Thanks - sync silo assigned and packages building btw.
[10:58] <sil2100> abeato: as you saw from queuebot it's silo 006 for rtm
[10:58] <abeato> sil2100, yup, thanks
[10:58] <sil2100> Mirv: ok, soooo... I'll merge this strange branch in a moment - for now don't assign any dual silos, just check if it's releasing normal silos correctly ;)
[10:59] <sil2100> Mirv: I'll jump out for lunch soon, so in case you notice that all is broken and dying in agony, then we have a nifty thing in deploy-citrain
[11:00] <Mirv> sil2100: ok :)
[11:02] <abeato> sil2100, hey, sorry, the MP still had a pending "Approval" tick, could you try again to publish?
[11:02] <Mirv> dbarth: can probably happen after, but I'm not sure what's it about if cjwatson needs to be pinged?
[11:03] <sil2100> Mirv: so, after I merge this, deploy-citrain in jenkins has an option to revert to a given revision (DEPLOY_PROD_REVISION)
[11:03] <Mirv> cjwatson: so that rtm-002 silo has a comment "IMPORTANT: ping cjwatson to put silo back in canonical form", I don't know what it's about
[11:04] <sil2100> Mirv: so just write -2 there (or the exact revision number of before my change)
[11:04] <Mirv> sil2100: ok, if everything explodes and something really important would need to be landed right now
[11:04] <Mirv> otherwise any problem can wait for your return
[11:06] <ogra_> popey, http://paste.ubuntu.com/8532237/
[11:06]  * popey hugs ogra_ 
[11:06] <ogra_> :)
[11:07] <cjwatson> Mirv: is that silo ready to land then?
[11:07] <Mirv> cjwatson: it's ready for QA signoff, david wasn't sure if it can be done now or only when it's going to be published
[11:08] <Mirv> cjwatson: so, in other words, contact you when about to publish?
[11:08] <cjwatson> Mirv: I used +edit-dependencies to make it not build against -proposed, to avoid the mir build currently there; need to set it back to -proposed before anything else uses that silo
[11:08] <cjwatson> Mirv: contact me when about to merge+clean
[11:08] <cjwatson> Mirv: or sometime between publish and merge+clean
[11:08] <Mirv> cjwatson: ok, clear, I'll make the comment slightly more understandable
[11:11] <Mirv> tvoss: I'm going to remove line 21 with https://code.launchpad.net/~thomas-voss/location-service/fix-1373281/+merge/236822 to utopic since it seems it was part of the trunk 115 commit
[11:12] <Mirv> or well, I'll mark it as Landed manually
[11:13] <sil2100> geh, pep8 compliance...
[11:14] <Mirv> sil2100: it seems we've a bunch of landings in the spreadsheet that say "Gave up this landing" while they actually landed.
[11:14] <Mirv> they seem to be in trunks, but once again it seems a bit scary
[11:15] <sil2100> Mirv: it might be some aftermaths after moving parts of the functionality to the dashboard... Probably some strange race, but we would need Robert for that best
[11:16] <Mirv> sil2100: I don't see Mir 0.8.0 release anywhere though...
[11:17] <sil2100> WTH
[11:18] <cjwatson> mir was given up as a consequence of the arm64 failure
[11:18] <cjwatson> it should be relanded with the fix for that
[11:18] <Mirv> cjwatson: it landed in rtm though
[11:18] <cjwatson> yes
[11:18] <Mirv> and none of the trunks have the code
[11:18] <cjwatson> it's in -proposed
[11:18] <sil2100> Mirv: it's in -proposed
[11:18] <cjwatson> the silo should not have been given up, that was somebody misdriving the train
[11:18] <cjwatson> but it doesn't hugely matter ...
[11:18] <sil2100> Ah, right
[11:19] <sil2100> It's the yesterday's issue
[11:19] <Mirv> right, so I will leave Mir 0.8.0 lines alone, with again just more clarifying comments, and they will reland
[11:19] <cjwatson> because it'll all end up being landed separately on utopic with one extra branch, AIUI, and can be merged from there
[11:19] <tvoss> Mirv, yup
[11:19] <cjwatson> but needs the mir folks to be around to do that
[11:19] <Mirv> hard to otherwise notice from the other "Cleaned silo, actually landed" cases
[11:22] <Mirv> alecu: I assigned silo for your "Add support for multiple currencies" sync to utopic
[11:22] <Mirv> jhodapp: rsalveti: line 9 + 10 there's a question for utopic landings on whether those lines are relevant or can be deleted, please answer at some point
[11:23] <dbarth> Mirv: ok; and i see you have the full answer now ;)
[11:23]  * sil2100 watches as his change is merging
[11:23] <sil2100> Soon all this confusion will be gone, ha hahhahahah!
[11:24] <Mirv> tvoss: is "Land Network Manager WiFi timestamp/scan results fix from tvoss to rtm" line still relevant? the last landing to rtm was https://lists.canonical.com/archives/rtm-14.09-changes/2014-September/000549.html
[11:25] <tvoss> Mirv, ah no, that should have landed
[11:25] <Mirv> tvoss: thanks, I wasn't sure based on the wording of the landed version
[11:29] <ogra_> popey, LOL
[11:29] <ogra_> http://www.golem.de/news/html5-videostreaming-netflix-bietet-volle-linux-unterstuetzung-1410-109765.html ... "this is reported by different sources such as the Canonical development boss Alan Pope."
[11:30]  * ogra_ will call you "the boss" from now on 
[11:30] <Mirv> tvoss: one more line, I'll mark line 47 with no target distro specified, "Fix #1373281 & #1367244", as Landed manually, as it has landed in utopic and I assume you'll have the big sync to rtm with all the fixes. please tell if that's wrong and it should be another rtm location-service sync silo.
[11:31]  * Mirv once again feels spreadsheet is an almost adequate state, until the next day
[11:31] <popey> sweeeeeet!
[11:32] <Mirv> popey: du bist Entwicklungschef!
[11:32] <sil2100> Mirv: thank you! :)
[11:32] <popey> That's me!
[11:32] <sil2100> The spreadhseet would die without Mirv around :<
[11:33] <Mirv> it's a zombie anyhow
[11:33] <ogra_> as long as it keep walking ... whi cares if it smells
[11:33] <ogra_> *who
[11:33] <tvoss> Mirv, yup, I'm planning another rtm sync soonish anyway
[11:34] <Mirv> tvoss: thanks
[11:35] <Wellark> any ETA on new images for utopic proposed and rtm-proposed?
[11:36] <ogra_> Wellark, every night :)
[11:39] <Wellark> ogra_: not good enough!
[11:39] <Wellark> ;)
[11:39] <Wellark> just make it run in constant loop :P
[11:39] <ogra_> Wellark, well, we also get new ones if new custom or device traballs land, but they go with unmodified rootfs
[11:40] <ogra_> and indeed we *do* build some on demand ... but not regulary
[11:40] <ogra_> (every time there  is a risky enough landing we build an image specifically for this)
[11:41] <ogra_> and yes ... i agree it should be a constant stream ... the prob is that the smoke tests take several hours to run
[11:41] <cjwatson> speaking of custom, https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/split-custom-tarball/+merge/237905 has a proposed landing procedure for moving a bunch of apps out of rootfs into custom
[11:42] <Wellark> ogra_: I though we have indefinite computing power ;)
[11:42] <ogra_> cjwatson, hmm, does that make us a seconf custom tarball ? (or do i read that wrong)
[11:42] <ogra_> *second
[11:42] <cjwatson> ogra_: it'll replace the current one for utopic{,-proposed}
[11:43] <cjwatson> cf. https://bugs.launchpad.net/barajas/+bug/1367332
[11:43] <Wellark> has anyone tested how fast you could build main using armhf crosscompilation on amazon cloud? :)
[11:43] <ogra_> i thought the current one gets applied at system-image level
[11:43] <cjwatson> yes it does
[11:43] <Wellark> would be a fun exercise
[11:43] <cjwatson> I have modified system-image to be able to deal with this
[11:43] <ogra_> then i dont get it
[11:43] <cjwatson> Wellark: about 35% of main cross-compiled cleanly last I checked
[11:43] <ogra_> so s-i stops pulling that tarball and only pulls the one from live-build ?
[11:43] <cjwatson> correct
[11:44] <ogra_> ah
[11:44] <ogra_> ok
[11:44] <cjwatson> that's the configuration change I refer to
[11:44] <ogra_> but that also means we need a full image build now when a new custom tarball should land
[11:44] <cjwatson> the necessary support code is deployed already
[11:44] <cjwatson> ogra_: that's right, custom tarball building will now be in sync with regular builds
[11:44] <Wellark> cjwatson: ugh.. that's depressingly low percentage
[11:44] <ogra_> cjwatson, cool
[11:45] <cjwatson> Wellark: depends on your viewpoint of course, it's quite a step up from where it used to be :)
[11:45] <Wellark> sure :)
[11:45] <Wellark> I bet
[11:45] <ogra_> (more time consuming though ... but i guess thats ignorable )
[11:45] <Wellark> ogra_: that's where the cloud comes in
[11:45] <cwayne> ogra_: cjwatson: wait, so we will still be able to do the second custom tarball on jenkins though, right?
[11:45] <cjwatson> cwayne: for images that contain non-free elements, yes
[11:46] <ogra_> cwayne, as i understand nothing changed for your side
[11:46] <cjwatson> or customer-specific things
[11:46] <cjwatson> cwayne: you'd need to ensure to include any of the packages being removed from the rootfs that you want to have
[11:46] <ogra_> on our side we need to actually trigger an image build to have it picked up
[11:47] <cjwatson> right any image that still has a custom tarball configured to download with an http method remains as before
[11:47] <cwayne> ogra_: well you'd have to trigger an image if you wanted a new set of clicks before anyway
[11:47] <cjwatson> but this lets us make the default community Ubuntu images have the rootfs/custom split we want
[11:47] <ogra_> cwayne, well, click updates  are also deployed out of the rootfs, but yeah
[11:47] <cjwatson> Steve argues the case in comment #31 on that bug
[11:48] <cjwatson> Wellark: I'd love to spend more time improving this, and have made the case for that a couple of times, but it kind of got sidelined by the rush to phone
[11:49] <cjwatson> Wellark: I think the next step is to make it possible to configure selected PPAs to use cross-building, so that the auto-cross-builder is less painful to maintain
[11:49]  * ogra_ is sure the next cycle will be a bit less stressful regarding the phone 
[11:49] <cjwatson> I do hope so
[11:49] <ogra_> as we now have something to base oon
[11:50] <ogra_> these constant architectural changes everywhere (from phone UI to infrastructure) were what was biting us
[11:52] <Wellark> cjwatson: yep.
[11:53] <Wellark> and once we would hit the 100% crossbuild state we would never run out of "armhf" builders
[11:53] <Wellark> which are slowing us down conciderably
[11:54] <cjwatson> Wellark: I expect we'll have better hardware well before then
[11:54] <ogra_> yeah
[11:54] <cjwatson> due to get midway-class at some point ...
[11:54] <Wellark> cjwatson: were have been counting for "better hardware" for a decade already
[11:54] <Wellark> I'm not expecting it arriving soon
[11:54] <ogra_> cross building the archive would just be waste of manpower ... thats good for home-rebuilds or some such
[11:54] <cjwatson> Wellark: and we have got better hardware at many points during that decade, significantly improving our throughput at each step
[11:55] <Wellark> cjwatson: until the next new architecture arrives
[11:55] <cjwatson> the point where armhf virtualisation is possible is fairly close and will be a major phase change
[11:55] <Wellark> and then it will the new bottleneck
[11:55] <cjwatson> I think your pessimism is because you are looking backward and forgetting how far we have come
[11:55] <ogra_> pessimist :P
[11:56] <cjwatson> the grass is always greener on the other side, and all that
[11:56] <lool> trainguards, cwayne, I'd like to start the process of landing rtm silo 5 which needs to land with an updated custom tarball; this involves stopping system-image, landing the packages and custom tarball, building a new image, enabling s-i again
[11:56] <lool> any objection? may I start this now?
[11:56] <ogra_> we started the arm work with 5 NSLU2's !!
[11:56] <Wellark> cjwatson: well, history has a habit of repeating it self :)
[11:57] <cjwatson> Wellark: jenkins may run out of armhf builders sometimes, but Launchpad essentially never does now
[11:57] <Wellark> sure, we are in a great shape with armhf right now compared to the past
[11:57] <ogra_> within the next 5 years armhf will be dead anyway i suppose ...
[11:57] <ogra_> even the cheap phones will be arm64
[11:58] <Wellark> but I'm trying to make a point that being able to crosscompile would give us more confidence for the future architectures
[11:58] <cjwatson> I generally agree that improving cross-building support will be very helpful, but it's not a panacea
[11:58] <Wellark> and how many arm64 builders do we have?
[11:58] <Wellark> ot ppc64
[11:58] <ogra_> more than other distros :)
[11:58] <cjwatson> by the time we're building phones on them we'll have plenty
[11:58] <Wellark> or when mips64 makes a breakthrough ? :)
[11:58] <cjwatson> hardware recently became commercially available
[11:59] <cjwatson> your pessimism is draining, going to do something else
[12:04] <lool> trainguards, landing rtm silo 5 now; disabling image cron
[12:07] <Mirv> lool: oh, I already did, since I wanted to see if train is ok with the new code deployment
[12:08] <lool> Mirv: you did what part?
[12:08] <Mirv> lool: publishing
[12:08] <Mirv> what trainguards do. trainguards don't disable image cron :)
[12:09] <lool> Mirv: is this where I'd get attention of the touch release team, or should I use #ubuntu-release?
[12:09] <lool> Mirv: hmm your action must have been really close to mine as I see my uploads went through in the minute where I pushed publish
[12:09] <Mirv> lool: mine was #32, yours were #33 and #34 (but they didn't do anything) https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-005-2-publish/
[12:10] <Mirv> over 2 mins later! :)
[12:10] <lool> Mirv: indeed!
[12:10] <lool> that's why the log was so short
[12:10] <Mirv> lool: so did you need something extra still?
[12:11] <Mirv> I wasn't sure what you referred to with contacting release team
[12:11] <lool> Mirv: no, I'll keep an eye on them now until they migrate and get published, then kick an image build and update teh custom tarballs
[12:11] <Mirv> great!
[12:11] <lool> Mirv: well I'd like to broadcast to the right folks that I've disabled the image builds and will be building an image
[12:11] <lool> I've noted that alongside the cron entry, should be clear enough I guess
[12:13] <Mirv> lool: from my understanding touch images -> notify ogra_, but I might miss something :)
[12:13] <lool> ogra_: ^ poke
[12:13]  * ogra_ reads
[12:14] <ogra_> lool, poke agaiin if rmadison says its there ? :)
[12:15] <lool> ogra_: sure; it the path is still relatively long
[12:16] <ogra_> yeah
[12:20] <alecu> Mirv: hi! I think there's something wrong with the spreadsheet, because row 23 should read "Landed" by now
[12:21] <alecu> Mirv: so, I think the silo ubuntu/landing-016 should be freed
[12:21] <Mirv> alecu: thanks, fixed.
[12:21] <Mirv> alecu: hmm
[12:21] <Mirv> alecu: right, so it has both landed (the cell was missing the formula to show it) but it also has a new silo that's not really needed
[12:22] <Mirv> alecu: and that silo was assigned since that cell was empty so it didn't show the landing.. now that being fixed too
[12:22] <alecu> ah, that's why it was not showing.
[12:22] <alecu> thanks!
[12:22] <Mirv> alecu: thanks to you!
[12:47] <tedg> Saviq, What does your "landing day" look like?
[12:47] <tedg> Saviq, After this indicator misc silo merges I'd like to look at greeter.
[12:47] <tedg> Saviq, Would that conflict with you?
[12:50] <Mirv> sil2100: FYI publish rtm-005 went just fine
[12:52] <Mirv> satoris: fixed silo 010 for you, ie removed the gallery-app in there.
[12:53] <Mirv> some train accident, that was
[12:57] <barry> choo choo
[12:57] <satoris> Mirv: is that for line 38 in the spreadsheet?
[12:59] <Mirv> satoris: yes, now it doesn't show an error anymore
[12:59] <Mirv> barry: choo choo! I'll jump off the train and let you run it.
[13:00] <barry> Mirv: tuck and roll! :)
[13:00] <Mirv> :)
[13:00] <satoris> Mirv: you might want to read the updated comments on that line (and 39 as well). ;-)
[13:00] <abeato> sil2100, hi, testing done for RTM silo 6, do I need QA sign off taking into account that is 2 bug fixes?
[13:01] <Mirv> satoris: oh, they were in reverse chronological order!
[13:01] <Mirv> satoris: thanks, I'll clean that up
[13:01] <satoris> Np. Thanks.
[13:05] <abeato> brendand, hi, testing done for RTM silo 6, do I need QA sign off taking into account that is 2 bug fixes?
[13:07] <brendand> abeato, i think with ofono we should test to be safe - unless you can explain why it's low impact?
[13:08] <abeato> brendand, well, essentially it is a fix for https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1375945
[13:09] <abeato> the other bug is in fact not happening with normal ofono usage from GUI
[13:09] <abeato> brendand, not big modifications but if we should do QA sign-off, it's fine anyway
[13:09] <sil2100> abeato: a valid choice! We really appreciate when someone pings us or QA whenever they think a QA sign-off might be skipped :)
[13:10] <sil2100> Thanks!
[13:10] <sil2100> brendand: what do you think? ^
[13:10] <abeato> sil2100, :)
[13:11] <sil2100> Mirv: we might have been lucky ;p
[13:11] <brendand> abeato, if you don't mind i think we should sign it off still
[13:11] <abeato> brendand, sure, no problem
[13:12] <brendand> abeato, it's next in the queue so should be picked up soon
[13:12] <abeato> brendand, cool, thanks
[13:12] <sil2100> Mirv: but I guess it does seem to work indeed!
[13:14] <tedg> sil2100, Do we have someone who is helping us with UNAPPROVED queue stuff? That's blocking me right now.
[13:14] <ogra_> what help do you need ?
[13:14] <tedg> ogra_, http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-017
[13:14] <sil2100> tedg: which package is causing trouble? We usually poke slangasek or cjwatson when archive admins are required
[13:14] <ogra_> if it is in utopic you have to talk to the ubuntu release team
[13:15] <sil2100> Ok, let's poke slangasek then maybe, or anyone else on -release
[13:15] <ogra_> (and if your package is in desktop you might need an FFe)
[13:15] <sil2100> ogra_: I think we checked these ones already
[13:15] <ogra_> k
[13:15] <ogra_> i didnt look at the silo :)
[13:15] <sil2100> ogra_: they have only changes that affect touch, so I would suppose no FFe needed
[13:15] <tedg> Okay, I was more asking if someone was assigned, to ensure I ping the person who's job it is :-)
[13:16] <tedg> Yeah, I think we're good on that one. There's a couple bug fixes.
[13:16] <tedg> But nothing FFe
[13:16] <sil2100> tedg: sorry ;) We have no officially assigned archive admins to our CI Train team right now
[13:17] <cjwatson> I can do a review pass
[13:17] <tedg> Cool, thanks cjwatson!
[13:17] <lool> ogra_: kicking image build
[13:17] <ogra_> lool, if you kick utopic, please do it via the UI
[13:17] <lool> ogra_: no, it's rtm
[13:17] <sil2100> hmmm, so far so good
[13:17] <ogra_> RTM only works via nusakan cmdline currently
[13:17] <lool> ogra_: wher'es the UI?
[13:18] <lool> ogra_: I've launched it on nusakan; DIST=ubuntu-rtm/14.09 for-project ubuntu-touch cron.daily-preinstalled --live
[13:18] <ogra_> lool, thats fine then
[13:18] <ogra_> lool, UI is at http://iso.qa.ubuntu.com/ ... you need to log in and should be able to click the "request rebuild" for the specific product
[13:19] <lool> I've disabled the s-i cron too now -- so that it doesn't pick up the new image
[13:19] <lool> now publishing custom tarballs
[13:19] <ogra_> err, why ?
[13:19] <lool> ogra_: when the image build completes, it would get published on system-image automatically, right?
[13:19] <lool> automatically => by the 5mn cron
[13:19] <ogra_> right, and i'm not sure s-i is happy if you replace all at once
[13:19] <ogra_> just let it do its job
[13:20] <lool> ogra_: 1) did it in the past  2) the whole point is that I'm trying to get the two things to land together
[13:20] <lool> or I wouldn't have to fiddle with anything
[13:20] <ogra_> we usually just make sure the rootfs is done first ...
[13:20] <ogra_> then the custom tarball triggers an immediate rebuild on s-i
[13:21] <ogra_> (or the device tarball)
[13:21] <ogra_> its just a matter of coordinating things a bit
[13:22] <ogra_> (but if you did it in the past and people still get all the backwards diffs and can upgrade fine it should be ok)
[13:24] <imgbot> [13:26] <cjwatson> tedg: all cleared
[13:29] <tedg> cjwatson, Awesome, thank you!
[13:35] <sil2100> cjwatson: thanks :)
[13:37] <bzoltan> sil2100: Mirv: may I ask for a reconfig of the rtm-silo13
[13:37] <bzoltan> ?
[13:38] <sil2100> bzoltan: sure
[13:39] <sil2100> bzoltan: done
[13:39] <bzoltan> sil2100:  danke
[13:49] <camako> trainguards, can I get a silo for row #70 please.
[13:49] <sil2100> Saviq: no worries about the message there ^ It's all ok
[13:49] <sil2100> camako: looking!
[13:49] <Saviq> sil2100, :)
[13:50] <Saviq> sil2100, I don't get pung by queuebot anyway ;)
[13:51] <sil2100> camako: hmmm
[13:51] <barry> camako: you have silo conflicts, please confirm the override: https://ci-train.ubuntu.com/job/prepare-silo/2728/console
[13:51]  * sil2100 wonders if he's feeling risky
[13:51] <sil2100> Maybe we'll wait
[13:52] <Saviq> davmor2, really? like no comment at all for silo 17? cool beanz :D
[13:52] <sil2100> camako: anyway, silo assigned :)
[13:52] <camako> sil2100, maan.. silo-15 has everything and their dogs!
[13:53] <camako> sil2100, anyways, it says "ignore all conflicts" on that silo..
[13:53] <davmor2> Saviq: the fixes fixed stuff, the broken bits were listed, now you need to fix them :P is that comment enough?
[13:53] <camako> sil2100 thanks
[13:54] <Saviq> davmor2, yes! :)
[13:56] <sil2100> camako: hah ;)
[13:56] <sil2100> camako: silo 003 for you
[13:56] <bfiller> sil2100: if I reconfigure a silo while a build is running what happens?
[13:56] <camako> sil2100, excellent.. thanks sir!
[13:57] <sil2100> bfiller: in what phase of building is it right now? If the silo already copied packages to the PPA then nothing should happen, but if it's still preparing packages than I wouldn't recommend that
[13:57] <sil2100> As it might be a bit racy then
[13:57] <bfiller> sil2100: ok, I think I'll wait till it completes then reconfigure
[14:06] <brendand> Mirv, hey - the 'easy command' didn't work for me just now - it pulled a bunch of other things too
[14:06] <brendand> Mirv, http://paste.ubuntu.com/8533114/
[14:07] <brendand> Mirv, oh could it be because i used apt for update and apt-get for dist-upgrade??
[14:07] <davmor2> brendand: indeed it seems to grab everyhting in the ppa for me on the mir landing :)
[14:08] <sergiusens> brendand: I forgot to tell you, adding the main repo as suggested in that bug report is not the right thing to do, as main has updates too
[14:08] <sergiusens> brendand: if a new dep is added to a silo, it has to be installed prior to running 'citrain'
[14:08] <brendand> sergiusens, ok - we tested it before though and it seemed to work correctly
[14:09] <sergiusens> brendand: well, if nothing changed in main, it would seem to work correctly
[14:09] <sergiusens> brendand: but if that were the case, just use all the sources.list
[14:09] <sergiusens> brendand: our stuff is split out between main and universe, so the solution would only work half of the times
[14:10] <ogra_> we just need to do a complete archive snapshot each time we build an image ...
[14:10] <ogra_> :P
[14:11] <sergiusens> right
[14:11] <sergiusens> ogra_: copy it to the ppa :-)
[14:11] <ogra_> haha, yeah
[14:13] <brendand> sergiusens, the bottom line is that we need consistent instructions for installing a silo - if citrain is not enough then that has to be written down
[14:14] <brendand> sergiusens, making citrain work correctly in more cases would be best though
[14:14] <sergiusens> brendand: fine, I wrote it down in my silos fwiw
[14:14] <sergiusens> brendand: it will never work entirely correct
[14:14] <sergiusens> it's a hack
[14:14] <ogra_> brendand, citrain is only not enough if people add/remove deps
[14:14] <sergiusens> ogra_: remove deps is fine
[14:14] <sergiusens> ogra_: adding is the problem
[14:15] <ogra_> brendand, for which i wrote a mail long ago asking people to clearly describe dep changes in their changelogs/commit messages
[14:15] <sergiusens> brendand: look at D14 in the spreadsheet as an example
[14:15] <ogra_> if that would be somehoe a standard it would be easy to handle
[14:15] <lool> ogra_: re-enabled crons; next s-i run will pick things up
[14:15] <brendand> sergiusens, that's perfect
[14:15] <ogra_> lool, great, thanks
[14:16] <brendand> sergiusens, personally i'd put it in the Test plans section though
[14:16] <sergiusens> brendand: but it's only valid for this silo
[14:16] <ogra_> brendand, well, added or removed deps arent a tester only thing
[14:16] <ogra_> that info is essential in other areas too
[14:16] <sergiusens> brendand: once this silo is in the archive, it will be "part of the image"
[14:16] <brendand> sergiusens, i mean the Test plans field on the spreadsheet
[14:16] <brendand> sergiusens, not the wiki page
[14:16] <sergiusens> oh
[14:16] <sergiusens> ah
[14:16] <sergiusens> eh
[14:16] <sergiusens> better
[14:17]  * sergiusens wanted to use vowels and the letter h
[14:17] <ogra_> you missed one or two
[14:17] <ogra_> ;)
[14:17] <brendand> sergiusens, you forgot ih
[14:17] <cwayne> sometimes yh
[14:17] <brendand> sergiusens, and uh
[14:17] <sergiusens> ogra_: 2 in English 7 in russian
[14:17] <ogra_> yeah,, probably 50 in japanese :)
[14:18]  * ogra_ doesnt know japanese though
[14:18] <sergiusens> not even sure the use vowel for kanji, might be for hiragana and katagana
[14:18] <sergiusens> ogra_: I can coun't to 10 and call out some aikido techniques :-P
[14:18] <sergiusens> but that's about it
[14:18] <ogra_> heh
[14:19] <brendand> sergiusens, can you comment on: https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1378245
[14:19] <cjwatson> ichi *punch* ni *punch* san *punch* shi *punch* go *punch*
[14:20] <ogra_> lol
[14:20] <cjwatson> sounds like we have a similar origin of knowledge ...
[14:20]  * ogra_ has a picture in his heard of lamont and cjwatson standing in front of google in mountainview :) 
[14:20] <ogra_> *head
[14:22] <ogra_> i remember you practicing on the lawn at the front door :)
[14:22] <cjwatson> yeah, kinda rusty now though
[14:23] <davmor2> cjwatson: I'm never ceased to be surprised by how many people do martial arts in this company
[14:25] <brendand> davmor2, did mpris break?
[14:25] <sergiusens> brendand: done, I also added a potential solution for full automation
[14:25] <brendand> davmor2, i.e. controls for media-playback?
[14:25] <sergiusens> brendand: but it involves getting rid of dist-upgrade
[14:25] <sergiusens> brendand: and parsing each dependency list for every package in the silo
[14:26] <brendand> sergiusens, yeah i figured we might have to do that
[14:26] <brendand> sergiusens, i already have some code that gets the binaries
[14:26] <brendand> sergiusens, it's a bit more complicated but it sounds like the best solution
[14:26] <bfiller> sil2100: would you mind reconfiguring rtm silo 13, as we added a new package that was not previously there
[14:27] <davmor2> brendand: eh
[14:28] <sergiusens> brendand: launchpadlib I think, remotely thing, can handle this without downloading all the debs; maybe Ursinha can help on this one
[14:28] <Ursinha> me
[14:29] <cjwatson> you don't need launchpadlib to figure out dependencies; just grab Packages
[14:30] <brendand> sergiusens, http://bazaar.launchpad.net/~brendan-donegan/+junk/silo_tools/view/head:/silo_binaries
[14:30] <sergiusens> cjwatson: right, thanks
[14:30] <brendand> cjwatson, no launchpadlib to establish which binaries the ppa provides (although i think we can do that with apt-too)
[14:30] <brendand> (no hyphen)
[14:31] <sergiusens> brendand: you can just grab packages
[14:31] <cjwatson> brendand: Packages tells you that
[14:31] <sergiusens> brendand: and use the rfc paragraph parsing
[14:32] <cjwatson> and the Python debian.deb822 module can parse it for you
[14:32] <sergiusens> right
[14:32] <cjwatson> launchpadlib basically involves you duplicating the work of the publisher really slowly ...
[14:32] <sergiusens> and it avoids launchpadlib all together
[14:32] <brendand> cjwatson, apologies - i can't map 'grab Packages' to a commad
[14:32] <brendand> command
[14:32] <cjwatson> brendand: Packages is an index file provided in every aptable archive
[14:33] <ogra_> or you could use wget and grep-dctrl ... that prevents launchpadlib too :P
[14:33] <cjwatson> (sometimes several, one per component/architecture etc.)
[14:33] <brendand> so many options!
[14:33] <Ursinha> ogra_: but the machine you are has to be same series you are interested on
[14:33] <brendand> cjwatson, so grab Packages for the ppa i guess - but what command does that?
[14:33] <Ursinha> ah, no wget no
[14:33] <ogra_> :)
[14:33] <cjwatson> brendand: er you can just fetch it
[14:33] <cjwatson> http://ppa.launchpad.net/ci-train-ppa-service/landing-002/ubuntu/dists/utopic/main/binary-armhf/Packages for instance
[14:34] <cjwatson> though I'm sure you can get python(3)-apt to do it for you
[14:34] <cjwatson> this is the canonical way to access archives
[14:34] <ogra_> rome .... so many ways to it
[14:35] <cjwatson> I don't think this is a many-ways-to-do-it thing
[14:35] <cjwatson> sure there are various ways to implement the canonical protocol
[14:35] <cjwatson> all I'm saying is that recalculating the set of published binaries using launchpadlib is not one of those ways
[14:35] <brendand> overloaded term is overloaded
[14:36] <brendand> 'the canonical way'
[14:36] <cjwatson> that's deliberate overloading :)
[14:36] <ogra_> heh
[14:36] <sergiusens> lol
[14:36] <cjwatson> there's a reason the company is called Canonical
[14:36] <brendand> cjwatson, oh yeah? we aren't very good at living up to our name then :P
[14:36] <cjwatson> using python(3)-apt is probably best for this, since that should be able to give you signature checking and such too
[14:37] <cjwatson> otherwise you'll have to reimplement all that and that's no fun
[14:37] <brendand> ooh and then i get to re-implement citrain in python - goody, goody, goody
[14:38] <cjwatson> or have a helper
[14:38] <brendand> it could probably do with being python anyway
[14:38] <brendand> although we might be killing it? sergiusens ?
[14:39] <sergiusens> brendand: kill license comes with airline though
[14:39] <brendand> sergiusens, why? because per silo images?
[14:39] <sergiusens> brendand: if we had roadmaps for these, we could weigh it in
[14:39] <sergiusens> yes
[14:40] <brendand> sergiusens, yes that would be the silver bullet for a lot of things
[14:40] <ogra_> s/would/will/
[14:40] <ogra_> just a matter of time
[14:40] <sergiusens> right, but without roadmaps, it's hard to plan for anything
[14:40] <brendand> ogra_, do *you* have a roadmap?
[14:40] <ogra_> i just use HERE :P
[14:40] <sergiusens> ev: would be nice to have the roadmap for the airline published somewhere so we can assert where to put our efforts
[14:41] <brendand> sergiusens, yeah if i rewrite it now and it takes a day or two and airline comes next month then maybe it's not worth it
[14:41] <brendand> sergiusens, but if it's a 'next cycle' thing then i think it would be
[14:41] <ogra_> i assume for the per silo images we simply miss a lot HW resources still
[14:41] <Ursinha> brendand: "airline comes next month" what does that mean? :)
[14:41] <brendand> Ursinha, i guess this airline doesn't have a good on-time record? :)
[14:42] <Ursinha> brendand: :) trying to understand what are the expectations here
[14:42] <Ursinha> brendand: by next month we'll have the spreadsheet replaced, hopefully
[14:55] <bzoltan> sil2100:  May I ask for a reconf of the rtm-silo13? bfiller just added the eds MR what need to land together with the UITK
[14:57] <tedg> kenvandine, silo 8, is it landing?
[14:57] <tedg> kenvandine, Like to start getting greeter to land and I've got a system-settings branch.
[14:58] <robru> brendand: what's wrong with the existing citrain tool that you're considering replacing it with python? Surely a small patch can resolve whatever issue you're seeing with less effort?
[14:59] <kenvandine> tedg, probably not
[14:59] <tedg> kenvandine, So can I land before you then?
[14:59] <kenvandine> tedg, i guess :)
[14:59] <brendand> robru, we're discussing a way to make it deal with added dependencies - python-apt and debian.deb822 came up as the correct way of doing so
[14:59] <bzoltan> robru: May I ask for a reconf of the rtm-silo13? bfiller just added the eds MR what need to land together with the UITK
[14:59] <kenvandine> tedg, is it ready to land?
[15:00] <brendand> robru, writing some wrappers for those is one option of course - whatever is least complicated
[15:00] <robru> bzoltan: I'm on holiday, sorry, try barry or sil2100
[15:01] <robru> brendand: what kind of added dependencies? Why aren't they just in the silo?
[15:01] <bzoltan> robru: enjoy :)
[15:01] <kenvandine> tedg, and does the test plan need any updating?
[15:02] <robru> Thx
[15:02] <tedg> kenvandine, I need to wait for other indicators to merge/clean before I can rebuild it. But yes.
[15:02] <tedg> kenvandine, Which test plan?
[15:02] <brendand> robru, not all of a silos dependencies will be in the silo - maybe they should be - but it's certainly the case now that they might not be
[15:02] <brendand> robru, there was a specific case recently i'm trying to remember
[15:04] <imgbot> [15:04] <imgbot> [15:05] <ogra_> lool, ^^^^
[15:05] <kenvandine> tedg, https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-settings
[15:05] <brendand> ogra_, do you recall what happened with that silo that wouldn't install with citrain?
[15:06] <brendand> it was a qtmir one
[15:06] <ogra_> brendand, iirc you needed to install deps from the archive beforehand
[15:06] <tedg> kenvandine, No, don't think so. We're just showing a single value.
[15:06] <ogra_> or update deps rather
[15:06] <tedg> kenvandine, it gets covered by the sound/messages test plan.
[15:06] <brendand> ogra_, it added a new dependency but robru is wondering why the new dep wasn't in the silo?
[15:06] <brendand> ogra_, i'm not sure how the silo contents are established
[15:07] <brendand> ogra_, are they just chosen by the lander?
[15:07] <ogra_> no, you upload a source package effectively (be it a branch or an actual deb)+
[15:08] <ogra_> if you need additional deps *in* the PPA you have to manually dput them or copy package them
[15:08] <bzoltan> trainguards: would you please reconfigure the rtm silo 13?
[15:08] <brendand> ogra_, right so it can be done but people just forget
[15:08] <barry> bzoltan: can do
[15:08] <ogra_> you shouldnt do it though ... how do you know the version you pushed there is stil the tight one if the tester comes around for testing
[15:08] <ogra_> *still the right one
[15:09] <brendand> ogra_, yeah if it's not being updated for your landing it shouldn't be there
[15:09] <brendand> robru, ^
[15:12] <dbarth> brendand: hey
[15:12] <dbarth> brendand: so i have now re-verified silo rtm-002, and updated the test plan with instructions
[15:13] <brendand> dbarth, isn't vrruiz looking at that?
[15:13] <dbarth> let me know when it gets back as an active task
[15:13] <dbarth> ah, ok i will check with him; sorry
[15:15] <cjwatson> I don't think it's reasonable to say that all a silo's dependencies must be in a silo.  If you're using some new tool or other, maybe it's perfectly stable, but you still need to add a dependency on it.  Copying it into the silo might well just be busywork
[15:16] <cjwatson> I'm concerned that being excessively strict about this will discourage people from declaring accurate dependencies
[15:16] <lool> ogra_: ack thanks
[15:16] <ogra_> well, and you never can be sure whatever you have in the silo doesnt change underneath you meanwhile
[15:17] <ogra_> there can be a day or two til a silo gets tested
[15:20] <alecu> hey all, image rtm-proposed-80 on mako is crashing *a lot* while swiping around in the dash
[15:20] <alecu> is this known?
[15:21] <alecu> the display remains with a fixed screen, and at one point the power button was no longer working
[15:21] <alecu> weird thing is that phablet-shell did work, and top showed everything normal.
[15:22] <ogra_> alecu, bug 1379296 ?
[15:22] <alecu> ogra_: ah, that sounds likely.
[15:22] <ogra_> (though that wouldnt cause a hard-lock, just have the dash restart regulary)
[15:22] <alecu> weird thing is that power button did not work, the display never turned off
[15:22] <alecu> it remained with a fixed screen
[15:30] <AlbertA> alecu: you still have phone freezed like that?
[15:33] <alecu> AlbertA: not right now, sorry. I rebooted it.
[15:33] <alecu> AlbertA: should I remain on image #80 and let you know when I reproduce that?
[15:33] <alecu> I was about to upgrade to #81
[15:34] <AlbertA> alecu: it's up to you, was just curious to get a gdb backtrace dump of unity-system-compositor since power key was not responding
[15:39] <alecu> AlbertA: if I manage to reproduce I'll ping you for details on how to do it
[15:42] <AlbertA> alecu: sure
[15:54] <tvoss> trainguards, can I get an RTM silo for line 74?
[15:56] <barry> tvoss: sure
[15:56] <tvoss> barry, thanks
[15:57] <barry> tvoss: whoops.  you need a sync: entry in column G
[15:57] <tvoss> barry, fixed
[15:58] <barry> tvoss: um, i think you need to specify what you want to sync.  see https://wiki.ubuntu.com/citrain/NewbieGuide
[15:58] <barry> (scroll down for syncing)
[16:00] <tvoss> barry, hopefully done:)
[16:00] <barry> tvoss: let's give it a try :)
[16:02] <barry> tvoss: https://ci-train.ubuntu.com/job/prepare-silo/2736/console
[16:02] <barry> tvoss: location-service is duplicated in another landing.
[16:02] <tvoss> lool, silo 1 is obsolete, isn'it?
[16:03] <tvoss> barry, that silo is obsolete
[16:03] <barry> tvoss: i will override
[16:03] <tvoss> barry thank you
[16:04] <lool> tvoss, barry: Yup, I confirmed yesterday I think
[16:05] <barry> lool, tvoss should we just abandon rtm/001?
[16:05] <barry> tvoss: anyway ^^
[16:05] <lool> barry: yes
[16:06] <tvoss> barry, yes
[16:06] <barry> lool: okay. i will try to do that before i disembark for lunch
[16:06] <plars> balloons: do you know if a fix for the filemanager failures went in yet?
[16:08] <balloons> plars, it did, but it didn't work
[16:08] <plars> mterry: any updates on https://code.launchpad.net/~mterry/unity8/dbus-race-fix/+merge/237594?
[16:08] <plars> mterry: wondering if that could be the reason for some strange failures we still see
[16:08] <mterry> plars, waiting for a review is all
[16:09] <mterry> plars, just re-requested a review to put it back on queue for any team member to take
[16:09] <plars> mterry: thanks!
[16:18] <lool> trainguards, I've added line 76 to land HERE update in utopic; it's custom tarball only, so no silo needed; not setting the "ready for silo flag"
[16:29] <john-mcaleely> davmor2, http://people.canonical.com/~jhm/barajas/device_krillin-20141009-ba11639.tar.xz
[16:29] <john-mcaleely> davmor2, http://people.canonical.com/~jhm/barajas/device_krillin-20141009-ba11639.changes
[16:29] <davmor2> thanks john-mcaleely
[16:29] <john-mcaleely> yw
[16:32] <sil2100> ogra_: meeting finished?
[16:32] <ogra_> sil2100, yep
[16:33] <ogra_> sil2100, music, calculator and filemanager are being looked at ...
[16:33] <sil2100> Was able to still catch brendand in the hangout though
[16:33] <ogra_> sil2100, a new device tarball is in QA
[16:33] <sil2100> By baloons?
[16:33] <sil2100> balloons I mean
[16:33] <ogra_> partially by baloons, yes
[16:34] <ogra_> sil2100, we need to get the overall numbers greener til thu. though
[16:34] <balloons> I'm keen to see a run with the new version of calculator that was pushed last night
[16:34] <ogra_> yeah, thats only in 96
[16:35] <ogra_> whcih only just started testing
[16:35] <ogra_> lool, so we just discussed in the landing meeting, who did QA and sign off the custom tarball you landed in your image build ?
[16:35] <lool> ogra_: brendand
[16:36] <lool> ogra_: plus all the dev testing prior to that
[16:36] <ogra_> oh
[16:36] <ogra_> lool, he claimes he only did a silo test
[16:36] <ogra_> *claimed
[16:36] <ogra_> but not a tarball
[16:36] <lool> he had to use a specific channel for krillin
[16:37] <ogra_> ah
[16:37] <lool> as indicated in the landing
[16:37] <ogra_> k
[16:37] <ogra_> (then i assume he did so :) )
[16:37] <sil2100> barry, Mirv: anyone of you noticed any problems with publishing packages?
[16:37] <sil2100> Or all is ok?
[16:38] <sil2100> ogra_: yeah, most certainly, I'm re-poking about dialer now
[16:38] <barry> sil2100: i have not noticed anything
[16:38] <sil2100> barry: that's music to my ears
[16:42] <lool> I'm autolanding the updated HERE custom tarball in utopic from line 76 now
[16:42] <ogra_> davmor2, ^^
[16:43] <lool> trainguards, would someone please mark this as Landed?
[16:43] <lool> I'll open a similar line for rtm once I'm ready
[16:43] <ogra_> lool, dont forget rtm needs QA signoff :)
[16:44] <sil2100> lool: hey! Ok, so you just land it directly, right?
[16:44] <davmor2> nice thanks
[16:44] <ogra_> well, it should go throough the regular process
[16:44] <lool> sil2100: yes, in utopic
[16:44] <ogra_> not sure where cwayne usually puts it
[16:44] <lool> ogra_: I'm painfully aware of that, yeah
[16:45] <ogra_> heh
[16:45] <lool> ogra_: cwayne publishes it to a specific channel
[16:45] <lool> 14.09-proposed-customized
[16:45] <cwayne> for krillin
[16:45] <ogra_> lool, no, for being picked up by the normal channel i mean
[16:46] <ogra_> cwayne, does that just get copied into rtm then or how is the process ?
[16:46] <lool> ogra_: once QA has acked, he has a special job he runs (I can run it too now, ran it for the first time today)
[16:46] <lool> ogra_: for mako+rtm, I am doing the update
[16:46] <ogra_> ok
[16:46] <lool> symlink on lillypilly
[16:47] <cwayne> ogra_: yeah what lool said, i have a separate job that wgets it once it's been acked, and s-i looks there
[16:47] <lool> under ~platform
[16:47] <ogra_> perfect
[16:57] <lool> trainguards, a heads up that I've put line 77 as the landing for the custom tarball for HERE update in RTM; doesn't need a silo; I've tested it but I'm not sending it to QA until we have an updated custom tarball for krillin up for testing
[16:58] <lool> probably monday
[16:59] <bfiller> sil2100: we should hold off on promoting any mako image until the sim lock issue gets resolved. just sent a mail to the phone-list about it
[17:00]  * ogra_ doubts we planned to promote anything anyway
[17:02] <sil2100> bfiller: ACK, will remember that - as what ogra_ mentioned we do not have any plans for that because ubuntu-rtm is enough worries for now anyway ;)
[17:02] <bfiller> sil2100: ok good
[17:02] <sil2100> And, we don't have enough free hands for additional dogfooding utopic too
[17:02] <ogra_> or even tablets on rtm :P
[17:05] <sil2100> pfff ;p
[17:05] <renato___> sil2100, hey, I am getting a strange error on this build: https://launchpadlibrarian.net/187008538/buildlog_ubuntu-rtm-14.09-i386.address-book-app_0.2%2B14.10.20141010.1~rtm-0ubuntu1_FAILEDTOBUILD.txt.gz
[17:06] <renato___> it only happen in the 1386 build and on the silo build
[17:06] <renato___> works nice on jenkins
[17:06] <renato___> the message I am getting during the tests is:
[17:06] <renato___> The schema com.canonical.Unity.Thumbnailer is missing
[17:06] <renato___> QIODevice::read: Called with maxSize < 0
[17:06] <renato___> Segmentation fault
[17:06] <davmor2> john-mcaleely: flashing dev tarball now
[17:06] <renato___> but I am not using the Thumbnailer library
[17:07] <renato___> and its only happen on i386
[17:09] <john-mcaleely> davmor2, o/
[17:11] <ogra_> renato___, wasnt there a mail thread about thumbnailer changes ?
[17:12] <renato___> ogra_, but I am not using thumbnailer
[17:35] <cwayne> davmor2: can I reserve some of your time next wednesday morning to make sure we land a custom tar then?
[17:35] <cwayne> sil2100: ^
[17:53] <barry> cjwatson, Mirv: apparently i am supposed to ping you before publishing rtm/002
[18:04] <davmor2> cwayne: you can but be aware next thursday and Friday I'm on Holiday \o/
[18:04] <cwayne> davmor2: no worries, it *has* to be wednesday :)
[18:04] <davmor2> cwayne: hahaha
[18:10] <sil2100> davmor2: HOLIDAY?! Isn't that too 'last year'?
[18:17] <davmor2> sil2100, john-mcaleely: I think the tarball is safe I don't see any glaring issues :)
[18:18] <john-mcaleely> davmor2, \o/
[18:18] <john-mcaleely> thanks
[18:18] <john-mcaleely> sil2100, ogra_ when's a good time to push to s-i.u.c?
[18:21] <camako> sil2100, mir testing on ubuntu silo 3 was successfully completed. Can we please publish ASAP  to unblock qtmir and u-s-c?
[18:22] <camako> kgunn, Saviq, AlbertA ^^
[18:22] <camako> trainguards ^^
[18:23] <barry> camako: looking
[18:24] <sil2100> john-mcaleely: I think ogra_ will know best about the situation right now
[18:24] <john-mcaleely> sil2100, ack. I'll await ogra_ 's good word
[18:24] <barry> camako: please ack the packaging changes
[18:25] <camako> barry, ACK for the packaging changes.
[18:26] <sil2100> camako: thanks!
[18:26] <camako> barry, sil2100, I dunno what happens now to the previously release mir which is stuck in RTM proposed
[18:27] <barry> camako: i think once you set up a sync silo, it'll get overridden, as long as the new version number is higher
[18:27] <camako> barry, great thanks.. I'll be doing that after lunch
[18:28] <sil2100> Yes, all we need is doing a sync silo and re-releasing that - after it passes testin once again that is
[18:29] <camako> barry, sil2100, thanks again.. and when does the sync silo assignment happen? After migration to dest?
[18:29] <sil2100> camako: we can assign one right now
[18:30] <camako> sil2100, that'd be great
[18:30] <sil2100> camako: ok, syncing packages!
[18:30] <sil2100> Silo 001
[18:31] <davmor2> sil2100: witness the qa queue
[18:32] <dobey> sergiusens: hey. how long until the u-d-m changes geets landed?
[18:32] <camako> sil2100.. ok thanks ... that's a nice lucky #... I was expecting #13 on a Friday.. my luck is finally changing :-)
[18:32] <sil2100> davmor2: ooh! Only one silo left?
[18:32] <sil2100> camako: hah ;)
[18:33] <davmor2> sil2100: I can't get hold of the landers there is a note on the spreadsheet that it needs rebuilding I don't know if this is the rebuild
[18:34] <davmor2> sil2100: so here it stays till Monday
[18:36] <sil2100> Good work everyone!
[18:45] <sergiusens> dobey: heh; good question, we are now crashing unity8
[18:46] <dobey> sergiusens: so "several days perhaps" ?
[18:49] <sergiusens> dobey: well, I think the d day for all landings into rtm ight be monday or tuesday; os if doesn't land then; it might not land until ota-1
[18:49] <sergiusens> even if it is critical
[18:49] <sergiusens> dobey: are you landing today?
[18:50] <sergiusens> if it goes through I can always resync/rebuild
[18:50] <sergiusens> dobey: all I did was a rebuild thanks to abi
[18:50] <dobey> sergiusens: yeah, would like to land this today
[18:50] <dobey> as it is a critical
[19:13] <alecu> sil2100: hi! just read your mail, and the timing was perfect because with dobey and sergiusens we are having a conflict with the order of landings
[19:13] <sil2100> alecu: hey! Yeah, I want to do this list so that for instance it is decided and that *everyone* knows where to aim first when doing a landing
[19:14] <alecu> sil2100: we've been landing click scope first to -rtm for the past few weeks. But now there's a joint landing with other scope libraries (row 40) and it's being done -ubuntu first
[19:14] <sil2100> I don't want anyone to change their default approach, but I want to at least know who is doing what
[19:14] <sil2100> hm, ok, so it's as I was afraid
[19:14] <sergiusens> the problems arise when teams land in different order
[19:14] <alecu> sil2100: so, the problem seems to be when landing multiple components that are usually landed to different places
[19:14] <sil2100> Right...
[19:15] <alecu> eg: click-scope lands to -rtm, but scopes-shell lands to -ubuntu
[19:15] <sil2100> It would be best if we could find one specific landing approach
[19:15] <alecu> right
[19:15] <sil2100> In case of such a conflict right now though:
[19:15] <sergiusens> it really doesnt matter
[19:16] <sil2100> Well, first of all alecu please make sure that everything that you have landed to -rtm already has been synced up to utopic
[19:16] <alecu> sure
[19:16] <sil2100> Then you can just land that one silo first to utopic
[19:16] <sergiusens> since you finally got rid of the ~rtm in the changelog, the versions match across the board
[19:17] <alecu> sil2100: great. And we will make sure that the landing to utopic gets synced to rtm before we do further landings to rtm
[19:18] <alecu> sil2100: thanks for the pointers, and thanks for spotting this issue.
[19:18] <dobey> ok so can we have a reconfig on ubuntu/landing-014 silo? :)
[19:18] <dobey> and we cna move forward with the landing :)
[19:18] <alecu> dobey: I'll do that
[19:19] <dobey> alecu: ok
[19:19] <sil2100> alecu: thanks for adding your component :) !
[19:20] <alecu> ah, I'm not able to reconfigure when the component list has changed...
[19:20] <alecu> trainguards, may I ask you to reconfigure ubuntu/landing-014
[19:20] <alecu> ?
[19:21] <sil2100> alecu: sure!
[19:22] <sil2100> alecu: reconfigured o/
[19:22] <alecu> thanks
[19:29] <barry> choo choo
[19:30] <sil2100> ;)
[19:31] <sil2100> barry: I think when doing CI Train duty, each of us should change their nicknames to something more monkeyish
[19:31] <sil2100> Let's propose that for the next cycle
[19:31] <sil2100> !
[19:32] <barry> sil2100: great idea!  unless of course, we retire the trainspotting monkeys for airhopping apes
[19:33] <sil2100> hah! Evolution, what a wondrous thing!
[19:36] <sil2100> balloons: hey!
[19:36] <balloons> sil2100, howdy
[19:37] <sil2100> balloons: how's the calculator, music and filemanager situation looking so far?
[19:37] <sil2100> Were you able to find what's wrong?
[19:38] <balloons> still waiting for http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/96:20141010.1:20141008-8ea26ef/552/ubuntu_calculator_app/ :-(
[19:38] <balloons> sil2100, on file manager I think I know how to solve. It's music that has me worried. Calc should be fixed, I just want to see it
[19:39] <sil2100> balloons: excellent! Wasn't there a crash seen during music-app tests?
[19:39] <sil2100> A qmlscene crash?
[19:40] <Wellark> trainguards: did the i-network packages from yesterday land to utopic and rtm?
[19:40] <balloons> sil2100, for music it's quite odd. The logs show basically nothing and the screenshot shows the dash. It's like it never started. I believe the cause to be the mocking hackery that keeps breaking. That said, it works on my device
[19:41] <Wellark> as LP bugs have not been automatically set to Fix Released...
[19:41] <balloons> sil2100, so I planned to do the same thing for music as what I did for calculator; remove all mocking. However, music does require some setup and interacts with mediascanner, so it's not as straightforward
[19:41] <barry> Wellark: do you know which silos there were in?
[19:42] <Wellark> barry: umm.. there were so many..
[19:42] <ogra_> john-mcaleely, just put it in place, it should all be fine
[19:42] <barry> Wellark: hmm, ubuntu/001 is "ready to build", so no not that one
[19:42] <Wellark> let me check if they are still in dashboard
[19:43] <barry> Wellark: same with rtm/003
[19:43] <barry> Wellark: i can monkeypush the builds
[19:44] <Wellark> barry: umm.. that landing had a different silo yesterday
[19:44] <Wellark> it should have gone in
[19:44] <Wellark> or did it..
[19:44] <Wellark> anyway
[19:45] <Wellark> I'm more concerned about the pin unlock landing
[19:45] <Wellark> barry: https://code.launchpad.net/~indicator-applet-developers/indicator-network/trunk.14.10
[19:45] <Wellark> commit 437
[19:46] <barry> Wellark: i don't know anything more than what i see in the dashboard
[19:46] <Wellark> merged by jenkins
[19:47] <Wellark> barry: this is the "master" bug
[19:47] <Wellark> https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1361074
[19:48] <Wellark> no "Fix Released" on any of the "affects"
[19:48] <sil2100> camako: thanks for adding your project!
[19:48] <camako> sil2100, np
[19:49] <barry> Wellark: check out row 29 of the spreadsheet.  it says landed
[19:51] <barry> Wellark: i don't see any silo assigned, so if it's row 29, perhaps it's just a leftover row?
[19:51] <Wellark> barry: ok, so I will update the bugs manually to fix released for both utopic and rtm
[19:51] <Wellark> barry: thanks!
[19:51] <barry> Wellark: ok!
[20:18] <cjwatson> barry: no, the message managed to get garbled again
[20:19] <cjwatson> barry: what I said was that I needed to be told between publishing and merge-and-clean of that silo, so that I can set it back to its normal configuration
[20:19] <Wellark> barry: I added an additional MP to line 51
[20:19] <Wellark> do I need reconfigure?
[20:20]  * cjwatson clarifies the spreadsheet comment
[20:21] <cjwatson> ah good I see that mir was mostly published
[20:21] <cjwatson> reviewing the remaining bit in the queue now
[20:25] <camako> barry, is everything ok with mir silo #3... It 's been awaiting migration for a while..
[20:25] <cjwatson> camako: I literally just poked it, scroll up :)
[20:25] <camako> cjwatson, ah ok
[20:26]  * barry -> meeting, be back rsn
[20:28] <barry> cjwatson: cool.  i will publish rtm/002 then and ping you when it's ready to merge+clean, though it may be late for you
[20:28] <camako> cjwatson, thanks for testing the branch BTW, on the arm64 hw..
[20:28] <barry> oh, well, that's not happy: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-002-2-publish/34/console
[20:28] <cjwatson> barry: I'll probably hang around for a bit to make sure all this mir stuff gets finished off properly
[20:28] <cjwatson> camako: np
[20:29] <barry> camako: looking at line 51
[20:30] <cjwatson> I don't understand the workflow that leads people not to approve merges ... I would've thought you'd approve before putting it in for landing
[20:30] <camako> barry, sorry, line 51 where?
[20:30] <barry> camako: sorry, that was for Wellark
[20:30] <barry> Wellark: line 51 reconfiged
[20:30] <camako> ah ok
[20:30] <Wellark> barry: thanks"
[20:31] <barry> hmm, no dbarth
[20:32] <barry> camako: ubuntu/003 not sure what's going on with that
[20:32] <camako> barry, it says "mir (0.8.0+14.10.20141010-0ubuntu1) is in the UNAPPROVED queue"
[20:33] <camako> barry, not sure what that is
[20:33] <barry> camako: me neither.  let me see if there's a mention about this state in the docs
[20:33] <cjwatson> I already dealt with it
[20:33] <cjwatson> 21:21 <cjwatson> ah good I see that mir was mostly published
[20:33] <cjwatson> 21:21 <cjwatson> reviewing the remaining bit in the queue now
[20:33] <cjwatson> 21:25 <cjwatson> camako: I literally just poked it, scroll up :)
[20:34] <barry> cjwatson: ah, thanks
[20:34] <camako> cjwatson, Ah ok, I was looking at an old page then
[20:34] <cjwatson> yeah it says it's in proposed now
[20:34] <cjwatson> should migrate soonish
[20:34] <camako> yep just saw... thanks again..
[20:34] <camako> AlbertA ^^
[20:35] <barry> cjwatson: so, dbarth's rtm/002 has unapproved mp's and he's not around.  i'll look and see if they make sense (may just be missing toggle flip)
[20:35] <cjwatson> yup
[20:37] <barry> cjwatson: it's this one, but i do not have perms to flip it: https://code.launchpad.net/~online-accounts/ubuntu-system-settings-online-accounts/master/+merge/237369
[20:37] <barry> jenkins marked it as needs fixing too
[20:38] <cjwatson> nor do I
[20:39] <barry> oh well then ;)
[20:39] <cjwatson> and would probably prefer somebody domain-knowledgeable to override jenkins anyway ...
[20:39] <barry> cjwatson: yep
[20:39] <barry> cjwatson: guess that'll sit over the weekend
[20:39] <cjwatson> mir waiting for autopkgtests now
[20:40] <cjwatson> I just misread the thing at the bottom of d-jenkins as "Help us abolish this page" rather than "Help us localize this page" and had a brief flash of hope, since cheated
[20:45] <john-mcaleely> ogra_, done - published :-)
[21:08] <dobey> robru: around?
[21:10] <cjwatson> ok and now we need to update ubuntu-touch-meta, so I will take care of that
[21:12] <cjwatson> (for mir 0.8.0)
[21:29] <cjwatson> ubuntu-touch-meta uploaded
[21:34] <sergiusens> barry: you want to rerun that jenkins job for online account ss?
[21:38] <barry> sergiusens: rtm/002?  did you approve the mps?
[21:38] <sergiusens> barry: huh, no way; not my domain :-)
[21:38] <barry> sergiusens: :)
[21:39] <barry> sergiusens: i'm sure dbarth will get to it on monday
[21:39] <sergiusens> barry: thought you were talking about a rerun for the mp :-)
[21:47] <robru> cjwatson: The point of testing things in silos is to confirm the branch really works before publishing. To expect people to approve branches as a precondition for getting silos is effectively to expect people to approve untested branches just because they look good. In my mind, we want people to build their branches in order to test them in order to confirm
[21:47] <robru> the changes are valid before approving
[21:47] <cjwatson> ok that entirely doesn't jibe with how I do things
[21:47] <robru> dobey: nope, try barry
[21:48] <robru> cjwatson: so what, you want people to build things locally, manually, before even getting a silo?
[21:48] <cjwatson> jenkins runs tests on mps before approving
[21:49] <cjwatson> if you say other people do things differently then fair enough; for me top-approve = all review necessary on this MP has happened and it is ready to go through landing
[21:49] <robru> cjwatson: not on all of them. In fact there's not much overlap between the train and the ones where Jenkins auto runs tests
[21:49] <cjwatson> FWIW that's the way that the Launchpad project themselves does things, and they invented MPs
[21:49] <sergiusens> cjwatson: I agree with you
[21:49] <sergiusens> and our dictator does too
[21:50] <cjwatson> so I picked things up from them
[21:50] <sergiusens> top approve means, code review + proper testing by submitter and reviewer
[21:50] <robru> cjwatson: i... Yeah, i totally agree! "All review necessary has happened" means "we built on a silo and installed the packages and confirm they work"
[21:50] <Wellark> utopic silo 1 ready to land \o/
[21:50] <cjwatson> robru: I see we're unlikely to come to agreement, so that's fine :)
[21:51] <tedg> cjwatson, The problem is when you need multiple MRs from different projects to implement a feature.
[21:51] <cjwatson> I was just curious since it seemed weird
[21:51] <tedg> For instance, LP doesn't have that problem.
[21:52] <cjwatson> does too
[21:52] <robru> cjwatson: i guess you don't appreciate the testing value of the silo? Surely top approving a branch before you've installed the package and confirmed it working is premature
[21:52] <cjwatson> robru: I appreciate it, I just don't encode its output in top-approval
[21:53] <Wellark> why to build locally and risk human error and also waste developer time when we have machines to do the builds?
[21:53] <cjwatson> tedg: I speak from experience implementing the livefs work, for instance, which involved quite a few different projects and lots of incremental staging
[21:54] <tedg> cjwatson, Does that not mean that you need more than a single "Approve" though? You can coordinate yourself, but the tooling isn't helping at that point.
[21:54] <robru> cjwatson: anyway, i totally agree with you one hundred percent. We don't top approve branches before all necessary review and testing has occurred. That is the perfect description
[21:55] <cjwatson> I'm not enjoying this debating tactic
[21:55] <cjwatson> tedg: sure
[21:55] <robru> cjwatson: i know, it feels weird to totally agree with you so completely ;-)
[21:55] <cjwatson> robru: I'm trying to gracefully exit this argument, please don't do this
[21:56] <Wellark> well, our team has a different process
[21:57] <Wellark> you don't set "Testing Done" on the spreadsheet before "all necessary review and testing has occured"
[21:57] <Wellark> MP's are just code reviews
[21:58] <cjwatson> it's clearly not necessary for us to agree here (and please stop saying we agree when we don't).  as I say I was just curious because the alternate (from my point of view) workflow was unfamiliar
[21:58] <cjwatson> I'm not trying to make people do it my way
[21:59] <sergiusens> for the sake of history; MPs couldn't be siloed until they were top approved
[21:59] <sergiusens> someone changed that along the way
[22:00] <camako> cjwatson, Mir silo is still in proposed... Should I be concerned?
[22:01] <barry> Wellark: fwiw, that's always been the way I've operated: top-approve is for code reviews.  testing flag in spreadsheet is flipped when all necessary q/a is done.  in any case, things won't get published until both things happen
[22:02] <Wellark> barry: indeed
[22:02] <barry> but then again, i do system-image releases "weirdly" compared to all other touch packages ;).  i do them much more like real upstreams
[22:04] <Wellark> and if we at somepoint get back to the "has to be top-approved" before silo or all testing done to get a silo then I would propose that we have a set of staging silos for getting the testers and reviewers a reliable and consistent source of test packages
[22:04] <Wellark> for whatever architecture they need
[22:05] <Wellark> they are just ppa's
[22:06] <cjwatson> camako: I uploaded ubuntu-touch-meta and it's waiting for autopkgtests
[22:06] <cjwatson> camako: I'm shepherding this
[22:06] <camako> cjwatson, thanks... EoW is closing in... but seems like you've got things under control.. Have a good weekend
[22:07] <cjwatson> Wellark: I do hope that in the not too distant future we can erase the distinction between virtualised and non-virtualised PPAs; at that point this will all be much easier
[22:07] <cjwatson> because you won't need special "silos" any more, they can just be ordinary PPAs
[22:07] <Wellark> cjwatson: I don't even know there is such distinction
[22:07] <barry> cjwatson: +1
[22:07] <cjwatson> Wellark: that's the only reason silos are a special thing; they have to be non-virtualised (i.e. built on real hardware, like the distro) and enabled for all architectures
[22:07] <Wellark> I'm just a simple developer who wants to get his stuff done :)
[22:08] <cjwatson> Wellark: this is basically a hack around us not having reliable virtualisation quite everywhere yet
[22:08] <Wellark> ok. but we will get there :)
[22:08] <cjwatson> the endgame is definitely to do everything virtualised
[22:09] <cjwatson> (well, ok, silos also have a build priority bump, but that's less and less necessary nowadays ...)
[22:11] <cjwatson> camako: looks good now, should migrate to utopic next run I think
[22:12] <cjwatson> hmm, that could still be a while, let me kick one manually
[22:12] <camako> cjwatson, ok thanks... if you need me for any reason, please leave a msg here... I'll check throughout the night..
[22:13] <cjwatson> hopefully not, but let's see
[22:14] <alecu> hi trainguards! who can I ask for the packaging review of ubuntu/landing-014?
[22:15] <cjwatson> ah good
[22:15] <cjwatson>  final: mir,platform-api,qtmir,qtmir-gles,ubuntu-touch-meta,unity-system-compositor
[22:16] <cjwatson> so copying that ubuntu-touch-meta to rtm now too
[22:21] <cjwatson> whee
[22:21] <cjwatson> camako: all sorted bar waiting for publishers to run and such
[22:23] <dobey> hmm
[22:24] <dobey> barry: you have manual package change ACK perms for CI train?
[22:24] <barry> dobey: i do
[22:25] <dobey> barry: can you do the one for ubuntu/landing-014? it's a trivial build-dep version bump
[22:26] <barry> dobey: sure thing
[22:26] <dobey> barry: great, thanks
[22:27] <cjwatson> camako: so you have the separate ubuntu-rtm/landing-001 silo; as I understand it the only thing that adds over what had already been published to ubuntu-rtm/14.09-proposed is the arm64 fix?
[22:27] <cjwatson> camako: if so, maybe it isn't worth spending time on that now; just include it in the next RTM sync
[22:35] <camako> cjwatson, having the exact code would be good, but if it's causing you grief, I'm fine with that.
[22:36] <cjwatson> camako: well it's just not clear what you gain from going through another QA cycle just to sync an arm64 change into ubuntu-rtm which doesn't affect that distribution
[22:36] <cjwatson> camako: it's not that it causes me grief, but QA time is very heavily contended right now so it seems worth saving it
[22:37] <cjwatson> unless there's some other important change in one of the components other than mir that I missed ...
[22:37] <camako> cjwatson, there isn't... And QA doesn't need to test this. They can just signoff
[22:37] <cjwatson> true, if you want to discuss that with them that's fine
[22:38] <camako> cjwatson, meaning they have tested it already
[22:38] <cjwatson> was just a suggestion :)
[22:38] <camako> cjwatson, I'll put a comment in trello... thanks and have a good weekend
[22:38] <cjwatson>  mir | 0.8.0+14.10.20141005-0ubuntu1   | ubuntu-rtm/14.09 | source
[22:39] <cjwatson> camako: you too
[22:41] <cjwatson> barry: I've set ubuntu-rtm/landing-002 back to its standard configuration; now that mir has migrated there's no reason not to
[22:41] <cjwatson> barry: and removed that comment from the spreadsheet
[22:42] <barry> cjwatson: thanks
[22:42] <barry> okay folks - any last minute requests?  i am ready to eow
[22:43] <barry> going once
[22:43] <barry> going twice
[22:44] <alecu> barry: a silo for row ...
[22:44] <alecu> row 41 ?
[22:44] <barry> alecu: you win last call
[22:44] <alecu> (it's a sync, so it's waiting on row 40 to finish migrating packages)
[22:45] <barry> alecu: line 41 also has a silo conflict: https://ci-train.ubuntu.com/job/prepare-silo/2746/console
[22:46] <barry> alecu: is that the wait on 40 perhaps?
[22:46] <cjwatson> that's a different one, row 14
[22:46] <cjwatson> owned by sergiusens
[22:46] <barry> okay
[22:47] <alecu> right, row 14 needs to wait on 40 & 41
[22:48] <barry> alecu: so i can ignore the conflict then?
[22:48] <sergiusens> barry: cjwatson if this is unity-click-scope; already pre agreed with alecu; his silo has preference
[22:48] <alecu> barry: yes, please
[22:48] <alecu> sergiusens: thanks
[22:49] <barry> alecu: done.  and with that, i bid you all a good weekend!
[22:49] <alecu> barry: thanks a bunch. Enjoy yours!