[01:42] <bfiller> cihelp
[01:42] <bfiller> anyone around who could create some silos for me?
[01:43] <josepht> bfiller: you need to ping trainguards for silos
[01:43] <bfiller> trainguards ping
[02:09] <imgbot> [03:09] <imgbot> [03:54] <imgbot> [03:55] <imgbot> [04:10] <Mirv> bfiller: pong
[04:10]  * Mirv assigns some bfiller silos
[04:14] <imgbot> [04:14] <imgbot> [05:03] <cyphermox> Mirv: morning
[05:04] <cyphermox> Mirv: thanks for publishing the silos ;)
[05:04] <cyphermox> awe: ^
[05:04] <awe> sw33t
[05:04] <cyphermox> Mirv: and goodnight ;)
[05:06] <Mirv> cyphermox: goodnight :)
[06:30] <anpok> oh I dont get hilighted on notice messages
[06:31] <anpok> what does that mean: telepathy-ofono (0.2+14.10.20141007-0ubuntu1) is in no known spacetime.?
[06:43] <Mirv> anpok: usually it just means you need to wait
[06:44] <Mirv> also in this case
[07:19] <brendand> rsalveti, we're currently a bit backed up with silos, those two are 6th and 7th in our queue, so i'm estimating sometime tomorrow (maybe early tomorrow) before they're signed off. you can watch our trello board to see what's going on: https://trello.com/b/AE3swczu
[07:19] <brendand> rsalveti, and if any of them are urgent to sign off let me know
[07:20] <rsalveti> brendand: not urgent, so it should be fine
[08:11] <Saviq> cihelp, hey, can anyone please look at the job config here http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/1513/console
[08:11] <Saviq> it fails due to a missing hook that was added yesterday evening
[08:13] <davmor2> Morning all
[08:23] <davmor2> Yay photos show up correctly in the scope this morning the magic fairies were out last night obviously :D
[08:24] <brendand> Mirv, i'm just in the middle of signing off silo 7 now
[08:24] <Mirv> brendand: \o/
[08:25] <brendand> who moved the indicators around?
[08:25] <seb128> design
[08:25] <seb128> &ted
[08:25] <seb128> &charles
[08:25] <ogra_> ted did
[08:25] <sil2100> \o/
[08:25] <ogra_> oh, snap :)
[08:25] <seb128> ;-)
[08:25] <ogra_> hmm, we have a slight problem today ...
[08:25] <sil2100> davmor2: you mean, on the image we promoted?
[08:26] <sil2100> ogra_: ?
[08:26] <brendand> oh, because that's what was wrong with the whole thing... got it
[08:26] <davmor2> sil2100: no on this mornings image
[08:26] <sil2100> davmor2: meh :<
[08:26] <Mirv> there was an interesting case where network landed (and was signed off) separately and already included the move commit, but I then removed the network fro the bigger moving around landing and released the rest to match
[08:26] <ogra_> sil2100, sorry, not awake yet ... urfkill landed and we need a device tarball ... (but my brain just told me "custom" ... ) all good
[08:27] <ogra_> ('m literally only awake 10min)
[08:27] <Mirv> sil2100: btw, the qtmir landed only after the promoted image, I belive it would be very nice if we could promote again this week :) I mean, that landing finally fixes scopes scrolling performance to be good enough.
[08:27] <davmor2> ogra_: but it's like 10:30 there ;)
[08:27] <brendand> Mirv, and ogras oom_score fix too
[08:27] <ogra_> davmor2, it is ... i got to bed at 3am
[08:27] <brendand> Mirv, i think we should try and promote again before we get bitten
[08:27] <Mirv> I'm slightly irritated that this cafe doesn't have power outlet, but I guess I'll manage through the call before relocating
[08:28] <Mirv> brendand: exactly
[08:28] <ogra_> brendand, we'll bite back !!
[08:28] <davmor2> ogra_: dirty stop up ;)
[08:28] <sil2100> Mirv: I think we might ask poor davmor2 for some promotion dogfooding again today, as it seems another small issue got fixed as well
[08:28] <sil2100> ogra_: ;)
[08:28] <brendand> ogra_, you germans like to play dirty is it?
[08:28] <sil2100> Too bad our AP situation didn't get much better...
[08:28] <Mirv> if we would have a big "revert everything!" button that would be really quick and would make it easy to revert whole images, people would _feel_ our bite!
[08:28] <ogra_> lol
[08:29] <davmor2> sil2100: no not today tomorrow we need the device tarball to land for urfkill today that will need testing and then there is silo 19 too that we want to get landed tomorrow will be better for promotion as I can hit the morning image and run with it :)
[08:30] <sil2100> So the device tarball won't be ready today?
[08:30] <sil2100> Wait, silo 19?
[08:30] <sil2100> Damn, that's a risky silo man
[08:31] <sil2100> A good one, but very high risk
[08:31] <ogra_> sil2100, the device tarball is ready to go
[08:31] <ogra_> (afaik)
[08:36] <brendand> ogra_, the -r remote password option was added to phablet-config writable-image only, not the top level command, so e.g. phablet-config autopilot can't accept that argument
[08:37] <ogra_> brendand, it should just ignore it ... (since it doesnt seed it)
[08:37] <brendand> sil2100, i tested silo 19 personally
[08:37] <ogra_> *need
[08:37] <brendand> ogra_, it seems to hang though
[08:37] <brendand> ogra_, maybe that's not because of the password
[08:37] <ogra_> brendand, it re-profiles ...
[08:37] <ogra_> brendand, it takes as long as a boot without precompiled profiles
[08:37] <ogra_> 5-6min or so
[08:38] <brendand> ogra_, ok. it's been a while since i ran it
[08:38] <Laney> will CI train add an LP bug closure to d/changelog if the MP edits it?
[08:38] <ogra_> file a bug to remind me to add a message
[08:38] <ogra_> (the wiki tells you it can take long btw)
[09:04] <john-mcaleely> ogra_, so will you ping me when the rootfs image is ready?
[09:04] <john-mcaleely> ogra_, or should I poll s-i.u.c ?
[09:05] <ogra_> john-mcaleely, just watch imgbot
[09:05] <ogra_> imgbot, stunt
[09:05]  * imgbot rolls on its back and purrs
[09:05] <john-mcaleely> ogra_, aha. of course :-)
[09:05] <ogra_> john-mcaleely, it will tell you
[09:06] <ogra_> image triggered ... (bot should announce within the next 10min)
[09:14] <imgbot> [09:16] <asac> hmm. the music-hub looping all the imte; is that fixed in latest image?
[09:16]  * asac reboots to try
[09:17] <oSoMoN> trainguards: silo 14 has landed and is being cleaned as I type, when it’s done can I get a silo for line 87 please?
[09:18] <Mirv> oSoMoN: sure
[09:18] <oSoMoN> thanks!
[09:20] <sil2100> Damn, Mirv is FAST
[09:21] <Mirv> :)
[09:28] <Wellark> Mirv: hey, what's the status of urfkill+i-network landing?
[09:29] <Wellark> landing sheet row 6
[09:30] <brendand> sil2100, have a look: https://wiki.ubuntu.com/citrain/LandingProcess#preview
[09:31] <Wellark> sil2100: --^
[09:31] <sil2100> brendand: looks promising so far!
[09:31] <Mirv> Wellark: done, but needs some tarball updates
[09:31] <popey> sil2100: leo reported bug 1378639
[09:31] <popey> but this looks like an ubuntu-app-launch issue, not clock?
[09:31] <Mirv> Wellark: I mean, done for rtm, in queue for utopic
[09:32] <Mirv> I just archived all the "Landed" ones so the rtm disappeared. you can see https://lists.canonical.com/archives/rtm-14.09-changes/2014-October/thread.html for what has landed
[09:32] <Wellark> Mirv: ok, so row 56 after a rebuild?
[09:32] <Mirv> Wellark: we would need to merge & clean the utopic landing..
[09:33] <Mirv> Wellark: we could do that even prematurely if we're in a hurry
[09:33] <Mirv> since that landing will stay in utopic queue probably for a whie
[09:33] <Mirv> Wellark: ie. the trunk is not yet up-to-date
[09:33] <Wellark> Mirv: well, we are in a bit of a hurry, but how much time would it take to just "wait" for things to resolve?
[09:34] <pstolowski> Mirv, hey, any reason why line #28 is still around, while respective rtm package already landed (#1705 in Archived)
[09:36] <Mirv> Wellark: depends on our archive admins. you know, utopic is going to be released soon ;)
[09:36] <Mirv> Wellark: we'd just need to mentally note there's a landing to utopic that is still ongoing
[09:36] <Mirv> Wellark: I'll m&c now
[09:37] <Mirv> sil2100: ^ note utopic 011 being m&c:d while it's still in queue
[09:38] <Mirv> Wellark: trunk is updated now, you can rebuild.
[09:39] <Wellark> Mirv: Thanks!
[09:45] <sil2100> Mirv: ACK!
[09:47] <sil2100> popey: hmm, we didn't land a new u-a-l to ubuntu-rtm
[09:47] <brendand> pstolowski, silo 23 is 7th in our queue. eta sometime tomorrow
[09:47] <sil2100> popey: I wonder what's that about
[09:47] <brendand> pstolowski, you can have a look at the trello board to see how it's going: https://trello.com/b/AE3swczu
[09:52] <pstolowski> brendand, my question was about line #28 in the sheet, which landed already in rtm and  utopic, but it has been sitting in the 'cleaning silo' state for a few days alredy
[10:01] <ogra_> the rootfs for rtm is done, starting an utopic build now
[10:05] <sil2100> \o/
[10:05] <sil2100> pstolowski: oh, which silo is that?
[10:05] <sil2100> pstolowski: there is a stupid race in LP that causes that to hang in some cases
[10:07] <pstolowski> sil2100, i think it *was* silo 24; it's empty now
[10:07] <sil2100> pstolowski: yeah, so it seems the spreadsheet just didn't register that
[10:07] <sil2100> Let me fix it
[10:09] <imgbot> [10:10] <pstolowski> sil2100, thanks
[10:16] <Mirv> sil2100: do we have a plan on what to do when utopic goes to final freeze and v is not open?
[10:18] <popey> Mirv: when you have a moment, please upload to the store http://s-jenkins.ubuntu-ci:8080/job/filemanager-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.filemanager_0.3.297_armhf.click
[10:21] <Mirv> popey: ehum. some new problem encountered. Authorization Required.
[10:21] <popey> uh
[10:22] <seb128> hum
[10:22] <seb128> it looks like updating click from settings->update stopped working
[10:22] <Mirv> lp:click-toolbelt hasn't been updated
[10:22] <popey> seb128: i have one sat at 0% here...
[10:22] <seb128> popey, yeah
[10:22] <seb128> I wonder if that's a server issue
[10:23] <seb128> or a service one
[10:23] <seb128> or a setting one
[10:23] <Mirv> I wonder if both of these problems could be related to the same server issue?
[10:23] <Mirv> seb128: note that I've uploads broken at the moment
[10:23] <seb128> Mirv, what uploads?
[10:23] <Mirv> seb128: uploads to the store.
[10:23] <seb128> oh ok
[10:24] <seb128> so yeah, maybe server side
[10:24] <seb128> did anyone try to ping somebody from #is or online-services?
[10:24] <Mirv> who's the contact?
[10:24] <popey> not yet, only just discovered it.
[10:25] <popey> well, i have another device which just updated an app fine
[10:25] <seb128> not sure, maybe mandel can help there?
[10:25] <Mirv> seb128: now done on #is
[10:25] <Mirv> mandel not online
[10:25] <seb128> Mirv, thanks
[10:28] <popey> i cant update on my trusty channel devices, but can on my rtm device
[10:28] <popey> so not sure it is backend
[10:29] <imgbot> [10:29] <imgbot> [10:30] <john-mcaleely> \o/
[10:32] <ogra_> john-mcaleely, go for it :)
[10:33] <Mirv> popey: so, I assume sergiusens knows something I don't about how to get a new token for this particular use case, but until then I can't do uploads
[10:33] <popey> ok, thanks Mirv
[10:44] <thostr_> Mirv: can we get a silo for line 52?
[10:45] <Mirv> thostr_: done, integration only still I believe? (conflicts with unity8 in 016)
[10:45] <Mirv> oh, sorry, that's integration silo too.
[10:45] <Mirv> so no conflicts
[10:46] <thostr_> Mirv: yes, we should be good
[10:46] <thostr_> thanks
[10:46] <sil2100> davmor2, brendand, john-mcaleely: the device tarball has been signed off by QA already? :)
[10:46] <john-mcaleely> sil2100, er, no
[10:46] <davmor2> sil2100: no
[10:47] <Mirv> psivaa: if you can dig up upstart.mediascanner-2.0.log.txt from somewhere to https://bugs.launchpad.net/ubuntu/+source/mediascanner2/+bug/1376219 , it might help satoris to debug the bug
[10:47] <john-mcaleely> I'm doing my testing now
[10:47] <davmor2> sil2100: we needed the other image to land first
[10:47] <brendand> sil2100, if it only contains that one change then essentially it has. if not then no
[10:48] <sil2100> Yeah, as I though, I just saw ogra_ saying 'go for it' and thought I missed something
[10:48] <john-mcaleely> brendand, sil2100 it has lots of changes
[10:48] <john-mcaleely> I think ogra_ meant start my testing :-)
[10:48] <ogra_> sil2100, i meant his testing :)
[10:48] <psivaa> Mirv: let me look
[10:48] <brendand> ogra_, can i hire you for that mind reader job?
[10:48] <cwayne> davmor2: sil2100: btw there's going to be another custom tar needing testing too, since a new apparmor was pushed we needed to update our precompiled cache
[10:49] <sil2100> Ah ;)
[10:49] <cwayne> the only difference is that + a fb scope fix
[10:49] <ogra_> brendand, lol
[10:49] <ogra_> brendand, i thought popey qualified himself yesterday already
[10:49] <popey> hm?
[10:49] <sil2100> cwayne: oh, hm, today seems a bit packed with different landings - can we tackle that later or tomorrow?
[10:50] <ogra_> popey, for the open "mind reader" position in QA
[10:50] <cwayne> if you're okay with 5 minute boot times in the meantime...
[10:50] <popey> ☻
[10:50] <sil2100> Damn
[10:50] <popey> just updated to #90 and my krillin is sat on the splash screen
[10:50] <cwayne> yep
[10:50] <popey> shows as "offline" in adb
[10:50] <cwayne> cause the pre-shipped cache was invalidated by a new apparmor
[10:50] <ogra_> whats five minutes in the light of eternity
[10:50] <popey> no
[10:51] <popey> i can't get in, if it was apparmor i can usually adb in and run top
[10:51] <cwayne> ah
[10:51] <ogra_> popey, not since like 20 images anymore
[10:51] <popey> oh okay
[10:51]  * popey waits
[10:51] <ogra_> popey, adbd needs to start after lightdm
[10:51] <popey> coffee time
[10:51] <ogra_> since it will soon query the lock state of the screen for letting you in
[10:51] <davmor2> popey: I'm in took about 6 minutes
[10:55] <popey> it's alive!
[10:55] <brendand> davmor2, we still didn't fix the one word response bug?
[11:05] <john-mcaleely> davmor2, brendand location seems to be busted. is that a known issue in #90 ?
[11:07] <ogra_> there is no change that should be able to cause this
[11:08] <ogra_> (well, there is indicator-location, but that only chnages the panel order)
[11:08] <davmor2> john-mcaleely: looking now
[11:08] <ogra_> check syslog for apparmor denialy
[11:08] <ogra_> *denials
[11:09] <ogra_> looking at http://people.canonical.com/~ogra/touch-image-stats/rtm/90.changes ...
[11:10] <davmor2> phablet@ubuntu-phablet:~$ grep DEN /var/log/syslog | grep here
[11:10] <davmor2> Oct  8 06:50:40 ubuntu-phablet kernel: [35946.625197] (0)[8321:QThread]type=1400 audit(1412751040.670:146): apparmor="DENIED" operation="open" profile="com.nokia.heremaps_here_1.0.1" name="/dev/tty" pid=8321 comm="QThread" requested_mask="wr" denied_mask="wr" fsuid=32011 ouid=0
[11:10] <oSoMoN> trainguards: can utopic silo 10 be published, please?
[11:10] <ogra_> aha
[11:11] <davmor2> ogra_: I'm assuming this is why we need the custom tarball again
[11:11] <ogra_> davmor2, might be
[11:11] <sil2100> ogra_: looking!
[11:11] <sil2100> I mean
[11:11] <sil2100> oSoMoN: looking!
[11:11] <ogra_> heh
[11:11] <sil2100> ogra_: nvm my ping ;p
[11:11] <davmor2> ogra_: the denial log is huge
[11:12] <sil2100> (stupid tab)
[11:12] <ogra_> davmor2, well, you could try if adding the custom tarball helps indeed
[11:12] <ogra_> but apparmor should have re-built the rules anyway
[11:12] <davmor2> ogra_: you don't add it, it is a separate branch
[11:16] <john-mcaleely> davmor2, weird, I don't see those denials
[11:17] <ogra_> john-mcaleely, before or after applying the tarball ?
[11:17] <john-mcaleely> davmor2, however, I see the same 'no location' behaviour on vanilla #90 and + device tarball #90
[11:17] <john-mcaleely> ogra_, both
[11:18] <john-mcaleely> davmor2, also, the timestamps on your logs. really 06:50 for a device flashed in the last 30 mins?
[11:19] <davmor2> john-mcaleely: yeah I'm going to do a fresh flash
[11:19] <john-mcaleely> davmor2, I see all the scope denials
[11:19] <john-mcaleely> (on my devices)
[11:19] <cwayne> the /run/user/32011/leaf-net ones?
[11:21] <sil2100> davmor2, brendand: how many people from QA do we have available today for QA sign-off and landing team stuff? Is that only you two or is there someone else as well?
[11:22] <john-mcaleely> davmor2, ogra_ I'm flashing a fresh 89 to see how that looked
[11:22] <sil2100> Since I remember we had Victor as well?
[11:22] <davmor2> sil2100: there are others that are called in too.  Everyone is on alert
[11:24] <Mirv> cjwatson: just in case you're not busy at some point, I've been wondering for a long while while sometimes the package setting up phase on builders takes ages, and sometimes not. sometimes amd64, sometimes i386, sometimes both are fast.
[11:25] <Mirv> cjwatson: for example this amd64 build https://launchpad.net/~canonical-qt5-edgers/+archive/ubuntu/qt5-daily/+build/6444039 took 9 minutes until it started the actual build, until then installing and setting up packages
[11:25] <Mirv> at the same time https://launchpad.net/~canonical-qt5-edgers/+archive/ubuntu/qt5-daily/+build/6444041 was building in around 1 minute
[11:25] <brendand> sil2100, no there is nobody else today
[11:25] <brendand> sil2100, until the evening
[11:26] <sil2100> hm, this might be troublesome then, since we have a lot of silos requring QA sign-off + all these tarballs etc. to test
[11:26] <sil2100> Is there no possibility of bringing someone in?
[11:40] <cjwatson> Mirv: lamiak's one of the machines that's due to get a RAID controller to improve its I/O performance: https://rt.admin.canonical.com/Ticket/Display.html?id=72785
[11:40] <cjwatson> that's probably it
[11:43] <Mirv> cjwatson: oh, great then. maybe that'll be fixed for good with that.
[11:43] <cjwatson> should be I think, yeah
[11:44] <cjwatson> though the wheels of hardware acquisition grind slowly, yet they grind exceeding small
[11:53]  * sil2100 lunch
[11:59] <imgbot> [11:59] <imgbot> [12:04] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141008-8ea26ef.tar.xz
[12:05] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141008-8ea26ef.changes
[12:05] <john-mcaleely> sil2100, ogra_ davmor2 brendand ^ the device tarball we discussed this morning, now ready for QA signoff
[12:05] <ogra_> awesome
[12:05] <john-mcaleely> test results in all the usual places
[12:06] <john-mcaleely> it seems that #90 has an issue with location, fixed by a future custom tarball update. the device tarball seems not to impact that...
[12:06] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20141008-8ea26ef.ods
[12:07] <john-mcaleely> test results ^
[12:10] <brendand> sil2100, we really don't have anyone else
[12:10] <brendand> sil2100, and i'm actually tied to silo 19
[12:11] <brendand> sil2100, so you need to decide what you want davmor2 to do
[12:11] <ogra_> yes, please stay with silo 19 :)
[12:13]  * nik90 is excited about silo 19 :D
[12:14] <ogra_> ++
[12:14] <ogra_> makes everything so much better
[12:14] <nik90> yup, finally everybody who said app launch is slow can shut up :)
[12:29] <davmor2> brendand: I'm testing device and custom together cause I'm awesome and a little weird but they both need to land to fix everything that broke :(
[12:29] <ogra_> ++
[12:30] <sergiusens> Mirv: I hope you got your email
[12:30] <brendand> nik90, tbh it's not *that* amazing
[12:30] <brendand> but it does help quite a bit in some cases
[12:31]  * ogra_ finds it *that* amazing :P
[12:31] <nik90> brendand: I saw ToyKeeper's results..in many cases, the startup time is reduced by half..that's awesome tbh..
[12:31] <nik90> the rest is up to app devs to reduce it further
[12:31] <ogra_> there are some webapps where i even think they would be better off without a splash ... since they start so fast
[12:33] <Mirv> sergiusens: thanks, gotten, seems to work.
[12:33] <Mirv> popey: filemanger uploaded
[12:33] <Mirv> sergiusens: ^ the "seems to work" part
[12:34] <Mirv> with a bit of sedding to get to the normal click-toolbelt.cfg format
[12:34] <davmor2> nik90: app launch is slow :P
[12:35] <ogra_> davmor2, only the first time
[12:35] <ogra_> (with silo 19)
[12:35] <davmor2> ogra_: the silo hasn't landed yet so it is slow :)
[12:35] <ogra_> heh, yeah
[12:35] <nik90> lol
[12:43] <davmor2> ogra_: is there a way to land both custom and device tarballs?
[12:44] <davmor2> ogra_: or is it a case of landing one then the other in quick succession
[13:00] <Wellark> Mirv: please land 21
[13:01] <Mirv> Wellark: 21?
[13:01] <Mirv> utopic 21 is something for testing only, rtm 21 is empty
[13:02] <Wellark> Mirv: line 51 in the sread sheet
[13:02] <Wellark> Mirv: gah
[13:02] <Mirv> Wellark: " this is just an integration silo and not blocking anything!"
[13:02] <Wellark> mzanetti, thostr_: could you guys update the image numbers to line 51 of the landing sheet
[13:02] <Mirv> Wellark: it's also not marked as tested
[13:02] <Wellark> as you tested the feature
[13:02] <Mirv> and update the comments too..
[13:04] <mzanetti> Wellark: no, I didn't test the silo yet... always self compiled so far...
[13:04] <mzanetti> I can test it though and then add my name there. gimme 20 mins
[13:06] <Wellark> Satoris also tested on mako
[13:06] <asac> sil2100: was the thumbnailer backout after r88?
[13:08] <brendand> asac, yes thumbnailer is 'fixed' now
[13:08] <ted> brendand, Can we bump up the priority of QA review on rtm/9 ? It fixes the shell, which is confusing some of the other QA reviews.
[13:09] <brendand> ted, ok it's next
[13:09] <ted> brendand, Thanks!
[13:09] <fginther> Saviq, hey, the ':native' dependency issue should now be solved for unity8 builds. I'm working on enabling it for all projects
[13:14] <sil2100> asac: yes
[13:14] <sil2100> davmor2: how's the device tarball?
[13:15] <pstolowski> brendand, ping
[13:15] <asac> sil2100: so it was in 88?
[13:15] <asac> i saw weird media-hub behavioru on 88
[13:15] <asac> thats why i wonder if that was thumnailer bugginess still
[13:15] <sil2100> asac: yeah, those should be fixed but davmor2 reported that there were still some leftover small issues with the scope previews
[13:15] <brendand> pstolowski, yep
[13:16] <sil2100> asac: those seem to be gone now with todays image though
[13:16] <psivaa> Mirv: i missed a window to copy the upstart.mediascanner-2.0.log log for the qmlscene crash bug. sorry, the devices are now flashed with 274, i'll copy them once this set completes
[13:16] <asac> sil2100: yes, i see that the media-hub spinning on CPU 197%
[13:16] <asac> is gone today
[13:17] <asac> wonder if this is something i need to worry bout
[13:17] <asac> hence was hoping for an explain
[13:17] <asac> so you say scope previews were constantly hitting media-hub?
[13:17] <asac> that would make me happy enough as an explain :)
[13:17] <pstolowski> brendand, hey, re your testing of ubuntu-rtm/landing-023 (unity-scopes-api), we're currently preparing a set of MPs that re critical to land asap, because they're important for some other project; would it make sense land them in utopic, then resync 023 so that you can test all that in one go?
[13:19] <brendand> pstolowski, if that's what you want to do it's fine by me
[13:19] <davmor2> asac, sil2100: that is gone on latest I think let me take some photos in a second and double check,  custom tarball may of broke photo's scope other than that both look good
[13:19] <fginther> Saviq, but I see it's still broken, will work on fixing that
[13:19] <pstolowski> brendand, yeah, i'd like to avoid these new set of fixes to be blocked waiting on 023
[13:20] <pstolowski> brendand, i'm not sure if there's any other option?
[13:20] <brendand> pstolowski, you only need those to land in utopic?
[13:20] <brendand> pstolowski, i mean, urgently that is
[13:20] <pstolowski> brendand, no; rtm
[13:21] <brendand> pstolowski, the MPs that are critical to land asap, where is it critical for them to land?
[13:21] <brendand> pstolowski, in rtm or utopic?
[13:21] <pstolowski> brendand, in rtm
[13:28] <brendand> pstolowski, well whatever you need us to do just let me know
[13:29] <pstolowski> brendand, ok, thanks, i'll let you know.
[13:38] <davmor2> john-mcaleely, sil2100 : right so there was a small breakage in the FB scope that kinda screwed up the photo scope so they are backing that out, however I see no issues with the device tarball if you want to land that now
[13:40] <barry> dbarth: please ack conflicts: https://ci-train.ubuntu.com/job/prepare-silo/2621/console
[13:40] <john-mcaleely> davmor2, \o/
[13:41] <john-mcaleely> sil2100, ogra_ is now a good time to push the device tarball then?
[13:42] <sil2100> Yes, a +1 for me then
[13:42] <john-mcaleely> sil2100, ogra_ pushing
[13:42] <sil2100> After that's done, we can stop landings for a while, build a new image, publish silo 19 (if it passes QA) and build a new image again
[13:43] <davmor2> sil2100: we'll stil need to land the updated custom tarball so that location is fixed but that is special for after.  I'm moving over to silo019 for a bit till it is ready for testing again
[13:44] <john-mcaleely> sil2100, ogra_ published
[13:44] <john-mcaleely> pushed, even
[13:44] <ogra_> cool !
[13:44] <sil2100> Yeah, +1 on that - I would prefer we contentrate on our earlier plan, i.e. silo 19 and then the custom tarball
[13:45] <ogra_> sil2100, well, we should land the custom one today too if davmor2 wants to have the promotion image ready today
[13:46] <sil2100> Sure, but one thing after another
[13:46] <sil2100> We only have 2 QA people right now so we need to manage the limited resources ;)
[13:47] <ogra_> still ?
[13:47] <ogra_> shouldnt the US slowly get up ?
[13:48] <brendand> ogra_, elopio is in CR and ToyKeeper is in Colorado and works odd hours anyway
[13:48] <brendand> ogra_, so it will be after the landing meeting before we really have more resources
[13:48] <brendand> ogra_, by which time i'll be done...
[13:48] <ogra_> we really need to talk to your boss about some cloning
[13:49] <brendand> ogra_, on the brightside, we can get started with landing silo 19 now!
[13:50] <bfiller> sil2100: I need a silo for line 67 please
[13:50] <ogra_> brendand, yay
[13:50] <sil2100> bfiller: aye!
[13:50] <ogra_> brendand, we should perhapy wait til the device tarball image is done
[13:51]  * ogra_ hasnt checked where system-image stands with that
[13:51] <sil2100> bfiller: btw. why does this have a camera-app test plan attached? ;)
[13:51] <bfiller> sil2100: copy/paste error :) will fix
[13:51] <sil2100> Thanks, assigning anyway ;)
[14:02] <ogra_> john-mcaleely, did you push yet ?
[14:02] <ogra_> (i dont see anything happening on the server)
[14:02] <brendand> ogra_, do you think rtm silo 009 is low risk?
[14:03] <brendand> ogra_, 'Export XDG vars to adb shell'
[14:03] <brendand> ogra_, from tedg
[14:03] <Wellark> mzanetti: are you close on adding the Yes (#number krillin mzanetti) on line 50 on the landing sheet?
[14:03] <ogra_> brendand, well, its ugly and a totally broken implementation ... but not high risk
[14:04] <mzanetti> Wellark: yep
[14:04] <ogra_> brendand, i wouldnt have approved it
[14:04] <ogra_> brendand, but it wont do harm to land it
[14:04] <john-mcaleely> ogra_, hm, I think I did
[14:04] <brendand> ogra_, i just love it when people use the words 'totally broken' to describe something that works but not in the way they want :)
[14:04] <ogra_> brendand, https://code.launchpad.net/~ted/ubuntu-touch-session/xdg-to-profiles/+merge/237476 see my comment there
[14:05] <brendand> ogra_, so it's not high risk and won't do any harm, but is also totally broken :)
[14:05] <ogra_> it wont break anything though ... and is functionally safe
[14:05] <john-mcaleely> ogra_, the two files I change look correctly changed
[14:05] <sil2100> bfiller: love that term as well, Robert is a big fan of using that
[14:05] <sil2100> I mean, brendand
[14:05] <sil2100> What's wrong with irssi's tab completion todayC!
[14:05] <brendand> sil2100, i know a lot of people who throw that around
[14:05] <sil2100> bfiller: nvm
[14:05] <ogra_> john-mcaleely, now it starts importing
[14:06] <john-mcaleely> ogra_, yay. just slow then
[14:06] <sil2100> brendand: for me 'totally broken' means that nothing works and that it's a disaster, that a change that got introduced just breaks the whole thing and it's unusable
[14:06] <brendand> ogra_, i think the hyperbole free term you're looking for is 'sub-optimal' :)
[14:06] <dbarth> trainguards: ack about the conflict between silos with ussoa (rtm 07 & 17)
[14:06] <ted> ogra_, I agree, but I didn't want to build that for this patch. I think that change should be a different MR.
[14:06] <brendand> but i suppose it just doesn't have the same impact
[14:07] <ogra_> sil2100, the implementation above *is* a disaster specifically since i discussed exactly that with ted before
[14:07] <ogra_> ted, right, we can change it later ...
[14:07] <brendand> ogra_, totally broken should mean it doesn't do what it's meant to do or breaks other things
[14:07] <ted> ogra_, I think it should all move to profile.d scripts that are then called by the session script.
[14:07] <brendand> anyway... semantics
[14:07] <ogra_> ted, the point is that only HW related bits go into profile today since we cant change that later ... HW wont change, but the values for your vars might
[14:08] <brendand> i'll just check it does what it says and sign it off
[14:08] <ted> ogra_, Don't export the variables, but run the same logic in both cases.
[14:08] <ogra_> thats fine too
[14:08] <ogra_> brendand, no reason to block on my ranting :)
[14:09] <brendand> ogra_, you may be surprised to hear i wasn't planning on it!
[14:09] <ogra_> lol
[14:09] <ogra_> brendand, so why do you say you want to hire a mind reader then ? seems to work already with a little training ;)
[14:10] <brendand> ogra_, i'm a sub-optimal mind-reader
[14:10] <ted> sil2100, Can I get a silo for line 59 please?
[14:10] <ted> (rtm silo)
[14:10] <ogra_> its all a matter of practice
[14:11] <brendand> ted, ok - signed off. much to my surprise it was not, in fact, totally broken :)
[14:13] <ted> brendand, Thanks!
[14:13] <ogra_> brendand, well, lets talk again once we get some additional custom path being added to one of the vars
[14:13] <ogra_> :P
[14:13] <mzanetti> Wellark: added myself to the spreadsheet
[14:14] <Wellark> mzanetti: thanks
[14:14] <mzanetti> Wellark: found this one: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1378848
[14:14] <mzanetti> but it's UI, I'll fix
[14:14] <ogra_> brendand, with that change they are hardcoded forever :)
[14:14] <brendand> ogra_, ah so 'totally broken' means 'at some point in the future this will be totally broken if x happens'. gotcha
[14:15] <ogra_> right
[14:15] <ogra_> it helpps for the momment
[14:15] <ogra_> but i'll jump on it to have it fixed properly before release ... else we'll run into bad trouble later
[14:15] <ogra_> sigh ...
[14:16] <ogra_> so i see image 91 on the server when being logged in
[14:16] <ogra_> but i dont see it via http
[14:17]  * ogra_ wonders whats going on 
[14:17] <ogra_> hmm, in fact it sits there since over 30min
[14:17] <ogra_> cjwatson, do you know if there are any issues with sync-mirrors on nusakan ?
[14:19] <Wellark> Mirv: could you now land line 50, please? ;)
[14:19] <Wellark> Mirv: thanks!
[14:20] <ogra_> sil2100, so to make sure we get that dedicated image i would say we should block all publishing *now*
[14:20] <ogra_> sil2100, and publish silo 19 asap
[14:20] <ogra_> it will take 1h or so to get out of proposed
[14:22] <thostr_> can we get a silo for line 74
[14:22] <Wellark> ogra_: what dedicated image?
[14:22] <ogra_> Wellark, for silo 19 ...
[14:23] <ogra_> (rtm)
[14:23] <ted> It'd be nice to get 9 in so that the clock tests all pass before 19.
[14:24] <ogra_> ted, five people only worked towards getting 19 ready and have a dedicated image the whole day ... cant that wait for 3 more hours ?
[14:24] <Wellark> ogra_: but landings continue after 19 is out?
[14:24] <ogra_> Wellark, once we have an image built, yes
[14:24] <ted> ogra_, Sure, but there'll be clock failures on the results.
[14:24] <Wellark> ogra_: and that would take how much time?
[14:24] <ogra_> Wellark, it is just that the landing team decided we want to have a dedicated image for that high impact change
[14:25] <sil2100> Mirv, barry: hey guys, let's block landings for now
[14:25] <ogra_> ted, there were no clock failures in rtm in weeks
[14:25] <sil2100> ogra_: did anything land between us doing the device tarball and now?
[14:25] <barry> sil2100: okay.  does that mean something specific, or just not hitting publish?
[14:25] <ogra_> sil2100, you tell me :P
[14:25] <ogra_> i dont publish silos :)
[14:26] <sil2100> ogra_: I didn't publish anything, but maybe Mirv did, hmm
[14:26] <sil2100> ogra_: anyway, if anything landed then we'll have to build another image before publishing 19
[14:26] <ogra_> barry, just the lattter
[14:26] <sil2100> This way it will be completely isolated
[14:26] <sil2100> barry: just no publish button pressing ;)
[14:26] <ogra_> sil2100, but lose another 2h
[14:26] <sil2100> barry: btw. did you push any publish buttons already?
[14:26] <barry> sil2100, ogra_ i will cage that monkey buttonpusher
[14:27] <ogra_> :)
[14:27] <ogra_> ted, just to clearify we never had clock issues in rtm ... that was only in utopic anyway
[14:28] <sil2100> ogra_: yeah, but if something else that is not ignorable landed, I gues we would have to wait those ~2h - I mean, 19 can be tested in the meantime and even published after the rootfs gets built
[14:28] <sil2100> But anyway, let me check if there's a need for that
[14:28] <ogra_> sil2100, 19 is teasted and ready since 30min
[14:29] <sil2100> Oh, didn't see any message about that
[14:29] <ogra_> sil2100, bah, but there was a ton of indicators
[14:29] <Wellark> sil2100, ogra_, Mirv: just saying that line 50 (utopic, 51 rtm) fixes 8 criticals tagged for rtm14
[14:30] <Wellark> but that can probably wait for couple of hours
[14:30] <ogra_> Wellark, thats great for line 50/51 :)
[14:30] <Wellark> thostr_: ^
[14:30] <sil2100> Wellark: \o/ excellent - we just want to get 19 isolated first before that
[14:30]  * sil2100 checks what landed
[14:30] <ogra_> sil2100, ok, i see the indicators landed in 90
[14:30]  * ogra_ compares rtm-changes with the changelogs
[14:30]  * sil2100 greps his logs
[14:31] <ogra_> sil2100, seems https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/000626.html didnt land
[14:31] <ogra_> so that one would sneak in
[14:31] <sil2100> Yeah, I was worried about that one, but hm, it feels safeish enough
[14:32] <ogra_> i dont think it is worth to have an extra image just to keep it out
[14:32] <sil2100> Right
[14:32] <sil2100> Oooook
[14:32] <ogra_> sil2100, so lets get 019 in then
[14:32]  * sil2100 readies his finger
[14:32] <ogra_> i'll watch rmadison and trigger a build ...
[14:33] <ogra_> and will notify once we can land again
[14:33] <sil2100> Publishing!
[14:33] <ogra_> yay
[14:33] <ogra_> ricmm, ^^^
[14:34] <sil2100> But nice, this image will have only Qt5 changes, heh
[14:34] <sil2100> Mirv, barry: please note the topic - once we unblock landings I will change the topic as well ^
[14:35] <ricmm> ogra_: thanks
[14:38] <cwayne> ogra_: any idea why system-image isn't picking up my latest custom for 14.09-proposed-customized?
[14:38] <ogra_> cwayne, sommething is wrong ... i pinged stgraber already in #ubuntu-release
[14:39] <Wellark> sil2100, Mirv: block only affects RTM?
[14:39] <bzoltan> brendand: I am confident that the UITK from silo25 is safe to enter the QA queue. Would you please take that on your list?
[14:39] <ogra_> cwayne, i see newer images on the server directly ... but thy dont seem to get mirrored to the http space
[14:39] <cwayne> davmor2: ^
[14:39] <Wellark> not utopic?
[14:39] <ogra_> Wellark, yes
[14:39] <sil2100> Wellark: essentially yes
[14:39] <brendand> bzoltan, yep - but there is a big queue
[14:40] <davmor2> son of a....
[14:40] <Wellark> Mirv, sil2100: so line 50 can be landed for utopic?
[14:40] <bzoltan> brendand: I have seen ... what is your estimation?
[14:40] <ogra_> Wellark, anything can land in utopic :)
[14:40] <Wellark> ogra_: please land then :)
[14:40] <sil2100> Wellark: sure thing, one moment! :)
[14:41] <brendand> bzoltan, tomorrow perhaps
[14:41] <bzoltan> brendand: all right
[14:41] <Wellark> sil2100: thanks!
[14:41] <bzoltan> brendand: is there anything I could help you?
[14:42] <ted> sil2100, Can I get an rtm silo for line 59 please?
[14:42] <ogra_> (added an "RTM")
[14:43] <brendand> bzoltan, no just be sure your silo has all the info to start testing
[14:43] <sil2100> Wellark: damn... hmmm, so it seems that there has been a release of indicator-network in-between
[14:43] <sil2100> Wellark: you will have to rebuild your package ;/
[14:43] <Wellark> sil2100: what!?
[14:43] <Wellark> which landing?
[14:43] <sil2100> Wellark: since indicator-network 0.5.1+14.10.20141007.2-0ubuntu1 is in the -proposed pocket from what I see
[14:43] <sil2100> Wellark: it's https://launchpad.net/ubuntu/+source/indicator-network/0.5.1+14.10.20141007.2-0ubuntu1
[14:43] <sil2100> (so it's yours as well)
[14:44] <Wellark> sil2100: I triggered a rebuild after that
[14:44] <Wellark> Mirv said that the urfkill i-network was merged and cleaned manually
[14:44] <bzoltan> brendand:  of course. Please not that I will do push the -gles package tomorrow. That has no effect on your tests as it is an x86 package made from the armhf package. So do not freak out of you see reconfiguration or build process in that silo.
[14:44] <sil2100> hm, it seems it didn't get picked up, but let me check - maybe the rebuild was too fast and it still wasn't visible to the archive
[14:44] <jgdx> can one change the order of which debs are built on ci runs?
[14:44] <Wellark> and I triggered the rebuild after that
[14:45] <Wellark> I need a break.
[14:45] <sil2100> I'll check what's up
[14:45] <sil2100> Wellark: maybe it's just some glitch somewhere
[14:45] <sil2100> hah
[14:45] <sil2100> Yeah
[14:46] <sil2100> Wellark: ok, no worries! I see it's just CI Train that seems to be missing the info because it was done too fast
[14:46] <sil2100> Wellark: so I can publish it as it is without consequences
[14:46] <sil2100> ted: let me just finish this and I'll get back to you :)
[14:46] <ted> sil2100, Cool, np
[14:46] <ted> sil2100, Not like it can publish anyway :-)
[14:47] <sil2100> ;)
[14:47] <brendand> bzoltan, make sure to note that somewhere in case it's not me who looks at it
[14:48] <sil2100> ted: assigned and syncing
[14:50] <ted> sil2100, Great, thanks!
[14:50] <ted> sil2100, Can you publish ubuntu/17 as well please?
[14:51] <sil2100> ogra_, slangasek: damn, I just learned that I need to drive my girlfriend to the doctor next town for an appointement at 18:00, so I'll miss the meeting most probably ;/
[14:51] <sil2100> ted: on my radar ;)
[14:51] <ogra_> sil2100, well, i think we know what to do for today ... (waiting for silo 19 and building images, then unleash the dogs)
[14:52] <ogra_> i just hope the system-image server will function agaiin by then :(
[14:52] <sil2100> Yeah, anyway slangasek will probably be on the meeting and he'll maybe try discussing the move to LP bugs a little bit
[14:52] <sil2100> uh
[14:52] <sil2100> ;/
[14:52] <ogra_> yeah
[14:52]  * ted searches YouTube for "who let the dogs out"
[14:52] <ogra_> i even pinged in the #is channel
[14:52] <sil2100> Woof wooof
[14:52] <ogra_> but there seems to be nobody around
[14:53] <ogra_> and stgraber doesnt seem to be in #ubuntu-release either
[14:53] <sil2100> davmor2: btw.! On the  trello board you're still dogfooding the krillin #88 image!
[14:53] <sil2100> davmor2: please update it properly!
[14:53] <sil2100> ogra_: I think Stephane is on holidays this week
[14:53] <ogra_> sil2100, aha, got answer
[14:53] <sil2100> !!!
[14:53] <ogra_> seems there is a diskspace issue on the build server (nusakan)
[14:53] <sil2100> ogra_: did you confirm the same with rmadison ^ ?
[14:54] <sil2100> (since CI Train uses LP API, so it can be off by some minutes)
[14:54] <sil2100> Crap
[14:54] <ogra_> sil2100, not yet
[14:54] <ogra_> i'll watch it,, no worries
[14:55] <ogra_> aaand
[14:55] <ogra_> there is #91
[14:55] <sil2100> hm, I'm actually thinking not to modify CI Train to use madison instead
[14:55] <ogra_> finally
[14:55] <sil2100> ogra_: the one with the device tarball?
[14:55] <sil2100> yaay
[14:55] <ogra_> yeah
[14:55] <ogra_> thats all the urfkill stuff
[14:56] <ogra_> awe_, ^^ finally all landed
[14:58] <awe_> ogra_, are we going to kick off a new image build?
[14:58] <Mirv> yeah I thought the indicator-network went correctly, too
[14:59] <awe_> if, so I believe #90 would have all the bit, including the dev tarball changes
[14:59] <awe_> s/bit/bits/
[14:59] <Mirv> sil2100: that was the note about m&c earlier today
[14:59] <barry> sil2100: ack
[15:00] <sil2100> Mirv: right, but I didn't expect CI Train to not notice it - but it seems CI Train fetches the info to the backend config from LP
[15:00] <Mirv> sil2100: right
[15:01] <sil2100> Mirv: so it seemed to get confused, which I think is not a big deal as it's a rather rare case ;)
[15:01] <Mirv> sil2100: the need for early m&c may become a hot topic during the final freeze..
[15:02] <ogra_> awe_, nope, 91
[15:02] <Mirv> or alternatively all should be rtm-first
[15:02] <Saviq> robru, hey, could the silo dashboard linkify #123456 in descriptions?
[15:02]  * sil2100 feels worried about that already
[15:03] <sil2100> Saviq: as mentioned, robru is on holidays this week - best poking him after he's back :)
[15:03] <Saviq> sil2100, ah, didn't see it mentioned, he should turn his IRC off ;P
[15:03] <sil2100> hah ;)
[15:03] <sil2100> It was in my landing e-mail from Monday!
[15:03]  * sil2100 looks at Saviq with an evil eye
[15:04] <Mirv> sil2100: isn't utopic landings alright still? it's all about rtm & qtdeclarative?
[15:04] <Saviq> sil2100, need I remind you I got > 5k unread emails throughout my folders on Monday ;P
[15:04] <sil2100> Mirv: yeah, didn't mention it because I didn't want anyone of us pressing an ubuntu-rtm silo publish by mistake
[15:05] <sil2100> Saviq: ah, right ;)
[15:05] <Saviq> sil2100, if something is in the UNAPPROVED queue, should we worry?
[15:05]  * ogra_ twiddles tumbs watching qtdeclarative-opensource-src sit in -proposed
[15:07] <sil2100> Saviq: usually it means it is not handled by an FFe - what got into UNAPPROVED?
[15:07] <sil2100> In utopic I imagine?
[15:07] <Saviq> sil2100, indicator-network
[15:07] <Saviq> from silo 21
[15:07] <sil2100> Yeah, not a problem - we just need to poke some archive admin to +1 it from the queue since it's a bugfix only release
[15:08] <sil2100> Although, hmmm
[15:09] <ogra_> sil2100, image triggered
[15:09] <sil2100> ogra_: yaaay \o/
[15:09] <ogra_> rootfs build will take about 45min i think
[15:09] <sil2100> Mirv, barry: let's still wait for the rootfs to fetch all the packages
[15:09] <ogra_> so we should be able to open the gates even faster again
[15:09] <sil2100> Saviq: strange thing, since actually I see indicator-network in the standing FFe!
[15:10] <Mirv> sure, better to be safe
[15:11] <Mirv> zbenjamin: bzoltan: not approved, can't publish https://code.launchpad.net/~zeller-benjamin/qtcreator-plugin-ubuntu/devicespage2/+merge/237568
[15:12] <sil2100> Mirv: also, regarding silo 17 - one of the reasons why I didn't publish that one yet is that this seems like an user interface change
[15:12] <sil2100> Mirv: we need to check if it's only touch specific, or if it needs an UIFE
[15:12] <zbenjamin> Mirv: ok , this is a new MP from today , so its probably not tested completely
[15:13] <Mirv> sil2100: ahum..
[15:13] <Mirv> zbenjamin: so why is the landing marked as tested? :)
[15:13] <zbenjamin> Mirv: that can only bzoltan answer
[15:14] <imgbot> [15:14] <Mirv> sil2100: looking throught the diff:s, luckily it's touch only
[15:15] <sil2100> Mirv: oh, you published :) Well, nothing bad happened as basically those indicator- packages that are shared will be anyway landing in UNAPPROVED anyway
[15:15] <sil2100> Mirv: ok, good :)
[15:15] <sil2100> Mirv: then we'll poke the release team about those once they migrate to unapproved
[15:16] <Mirv> sil2100: yes.
[15:16] <Mirv> is there some sort of indicator all-nighter-all-week? huge amount of indicator landings all the time :)
[15:18] <sil2100> hah ;)
[15:19] <ted> sil2100, Mirv, the changes are only visible on phone
[15:20] <ted> The title strings aren't used in Unity7's design.
[15:20] <Mirv> ted: yep, that's good
[15:21] <davmor2> brendand, sil2100, cwayne: confirming no breakage in silo 019 every default app opened and ran as expected and also custom tarball is better now release the hounds when you are ready
[15:21] <sil2100> davmor2: good news!
[15:22] <sil2100> davmor2: the new image with silo 19 in it is now building, so we'll be able to experience it first hand soon
[15:22] <cwayne> davmor2: cool, so sil2100 i can press the magic button?
[15:22] <ted> Mirv, No, it seems my schedule is now: work 2 weeks, land 1 week. Trying the list off approved MRs down: https://code.launchpad.net/ubuntu-menu-bar/+activereviews
[15:22] <sil2100> cwayne: not yet!
[15:22] <ted> Hopefully by EOW that'll be back down to reasonable.
[15:22] <davmor2> cwayne: no you need to wait till 92 is built
[15:23] <sil2100> cwayne: let's wait for the current image to finish building first
[15:23] <Mirv> hopefully
[15:23] <cwayne> ack
[15:23] <pstolowski> Mirv, i've fixed the wrong MP in  #77
[15:24] <davmor2> sil2100: with all that done tomorrow we should in theory have a working image that can be promoted again. Now I'm gonna jump on silo testing and help out brendand for the rest of today
[15:25] <Mirv> pstolowski: thanks
[15:25] <cwayne> davmor2: thanks for testing today man, I know it wasn't ideal :)
[15:25] <davmor2> cwayne: less ideal when you broke it :P
[15:25] <ogra_> cwayne, it was a little more work *today* which means it will be perfect *tomorrow* :)
[15:26] <davmor2> cwayne: no worries though dude needed it :)
[15:26] <ogra_> but yeah, davmor2 deserves a medal
[15:27] <sil2100> davmor2: thanks!
[15:27] <davmor2> ogra_: no medal needs to go to brendand image testing is relatively harmless in comparison to silo testing, I'm effectively saying yes congratulations the hard testing you did works :)
[15:28] <ogra_> heh
[15:28] <sil2100> Yeah, I'll just jump out for some minutes to that doctor and be back soon to finish up that landing document for brendand
[15:28] <ogra_> then a medal for brendand too indeed :)
[15:28] <brendand> medals all round!
[15:28] <davmor2> brendand: woohoo
[15:36] <charles> camako, any chance we could throw https://code.launchpad.net/~charlesk/unity-system-compositor/lp-1365557-decrement-display-on-requests-correctly into silo 8?
[15:36]  * camako looks
[15:38] <camako> charles, this is supposed to be a sync silo.. I don't think it's a good idea.
[15:39] <camako> charles, besides rtm silo 20 landing hasn't happened yet..
[15:39] <charles> camako, ack
[15:40] <charles> makes sense, I didn't realize it was a sync for rtm 20
[15:51] <ogra_> ted, bah, who decided to have the message indicator at the most unreachable place on my display !
[15:51] <Wellark> ogra_: design.
[15:51] <ogra_> do they all have extremely long thumbs ?
[15:52] <ted> ogra_, You know what they say about designers… long thumbs ;-)
[15:52] <ted> ogra_, I think it is to raise its perceived importance.
[15:53] <ted> ogra_, It's now "first"
[15:53] <ogra_> ted, yeah, and "least reachable" too
[15:54] <ted> ogra_, Do you typically use your phone holding it in your right hand?
[15:54] <ogra_> ted, yes
[15:54] <Wellark> ted: I do as well
[15:54] <ogra_> i tried left when the back butzton moved
[15:54] <ogra_> but i cant get along with it
[15:55] <ted> Interesting, not the case for me. Wonder with "average" is there.
[15:56] <seb128> kenvandine, is there any reason to not include the wizard update in that landing?
[15:56] <Wellark> I only switch the phone to my left hand when I actually have to type something with OSK
[15:56] <kenvandine> seb128, i wanted to keep the landings a little smaller, easier for qa verification
[15:56] <kenvandine> seb128, i'll do the wizard one next
[15:57] <seb128> ted, it's first and it's also "easier to get to" (if you have long enough fingers"
[15:57] <seb128> ted, in the sense that can you pull down anywhere in the empty space on its left
[15:57] <seb128> kenvandine, k
[15:57] <slangasek> ogra_: so if sil2100 isn't around, I'd rather postpone our discussion until tomorrow - I think he should be there for it
[15:57] <ogra_> slangasek, "our discussion" ?
[15:57] <slangasek> ogra_: the "using bugs" discussion sil2100 alluded to
[15:57] <ted> seb128, Yeah, it is for me too. But apparently not everyone.
[15:57]  * ogra_ wonders what he forgot
[15:57] <slangasek> ogra_: i.e., I'm not actually coming to the landing team meeting
[15:58] <ogra_> slangasek, ah
[15:58] <ogra_> that
[15:58] <ogra_> yeah, its his baby
[16:00] <Wellark> sil2100: did you figure out the problem with line 50?
[16:01] <Wellark> still says "package not available at the destination)
[16:05] <balloons> fginther, just to confirm, everything should be running with autopilot timeout set to long yes?
[16:06] <balloons> fginther, I'm wondering in response to: http://91.189.93.70:8080/job/generic-mediumtests-utopic-python3/731/artifact/calendar_app.tests.test_new_event.NewEventTestCase.test_edit_event_with_default_values.ogv. It seems like it's timing out after 10 seconds
[16:06] <fginther> balloons, yes, using "--timeout-profile=long"
[16:08] <balloons> davmor2, I found something cool on r91. Apps that fail to launch still stay in the carousel view
[16:08] <cjwatson> ogra_: sync-mirrors> if there were a problem with cdimage's sync-mirrors it'd show up in the image build log; also system-image.u.c has its own mirror syncing thing which isn't something I know about
[16:08] <balloons> davmor2, is this a known thing?
[16:09] <ogra_> cjwatson, all solved already, nusakan was out of disk
[16:09] <cjwatson> ah, enospc, I see
[16:11] <sil2100> Wellark: no worries about that one, I poked the archive admins about that 30 minutes ago
[16:11] <sil2100> So it should be good now
[16:11] <sil2100> ogra_: did the rootfs finish building?
[16:11]  * sil2100 is back
[16:11] <ogra_> sil2100, rootfs is ... but system-image isnt yet
[16:12] <sil2100> But you think it should be fine to publish packages normally, right?
[16:12] <thostr_> fixed MPs in line 74, could we get a silo?
[16:12] <sil2100> thostr_: o/
[16:12] <ogra_> sil2100, got anything to bring up in the meeting ?
[16:12] <ogra_> (else we'll close)
[16:12] <sil2100> ogra_: I don't think so, nothing that can't wait for tomorrow :)
[16:13] <sil2100> Just a big 'kudos' for everyone for the swift publishing, testing and planning action
[16:13] <sil2100> ;)
[16:13] <cjwatson> ogra_: do you know who cleaned up what?
[16:13] <ogra_> cjwatson, i pinged in #is on the other server
[16:13] <ogra_> (got the backlo on another machine, gimme 5min)
[16:13] <sil2100> With such coordination we can really conquer the world! (tm)
[16:14] <cwayne> sil2100: so im waiting til the rootfs is on s-i before pushing custom, yes?
[16:14] <cjwatson> ogra_: no need, that's enough, thanks
[16:14] <ogra_> sil2100, you mean after we cleared the few days of backlog that generated ?
[16:14] <ogra_> :)
[16:14] <tvoss> Mirv, silo 1 tested again
[16:14] <cjwatson> ah, / not /srv
[16:14] <ogra_> "conquering postponed"
[16:14] <ogra_> cjwatson, yeah
[16:15] <fginther> balloons, the console log shows the parameter being passed and autopilot shows that it's the most recent utopic version: http://91.189.93.70:8080/job/generic-mediumtests-utopic-python3/731/consoleText
[16:15] <fginther> balloons, Is it possible the argument itself is wrong? it didn't generate an error that I can see
[16:15] <sil2100> cwayne: yes, let's best wait for the current one to completely finish building
[16:16] <sil2100> davmor2: you tested the custom tarball, right ^ ?
[16:16] <sil2100> thostr_: gallery-app is already allocated in silo 16 - can you contact bfiller about that?
[16:17] <thostr_> sil2100: as I wrote in comment, this is for testing for now, so we are fine
[16:17] <davmor2> sil2100: yeap
[16:17] <thostr_> sil2100: and actually it's exactly to help bill testing
[16:17] <ogra_> cwayne, yes, silos can land again, but s-i stuff still has to wait
[16:18] <balloons> fginther, ahh right, the log, I didn't look. Umm, yes it is confusing as to what is happening here
[16:18] <sil2100> thostr_: good, assigning!
[16:18] <sil2100> ogra_: ok, so I guess it's safe to bring down the lock on landings
[16:19] <ogra_> sil2100, yeah, as long as cwayne still holds his feet still :)
[16:22] <seb128> why do you guys lock landings?
[16:22] <ogra_> seb128, for some dedicated image builds with only a specific change set inside
[16:23] <ogra_> seb128, embargo is lifted now though
[16:23] <seb128> the qml compilation thing?
[16:23] <sil2100> seb128: we had an important landing happening today and we wanted to have it isolated in an image
[16:23] <sil2100> Yeah
[16:23] <seb128> is that in 91?
[16:23] <ogra_> seb128, first the urfkill fix (which needed multiple bits in device and rootfs tarballs) and now the QML precompilation
[16:23] <ogra_> seb128, 92
[16:23] <ogra_> shoulld be done in 20-30mmin latest
[16:23] <seb128> k
[16:23] <seb128> there is no http://people.canonical.com/~ogra/touch-image-stats/rtm/91.changes
[16:23] <seb128> ogra_, stop lagging behind!
[16:23] <ogra_> haha
[16:24] <thostr_> sil2100: have you assigned?
[16:24] <ogra_> well, the image isnt done yet :)
[16:24] <thostr_> sil2100: ah, now it appeared
[16:24] <seb128> ogra_, 91? sure is, I've it installed on my device
[16:24] <ogra_> seb128, 91 only has the urfkill fixes
[16:24] <ogra_> 92 has the QMl bits
[16:24] <seb128> k
[16:24] <seb128> but you are still lagging behind
[16:24] <sil2100> thostr_: yeah, best to use the CI Train Dashboard - that one tends to be faster
[16:25] <seb128> I had to ask here because the .changes was not there :p
[16:25] <Wellark> sil2100: thanks!
[16:25] <ogra_> seb128, oh, device tarballs dont create rootfs changes ... so the changelog is identical to 90
[16:25] <sil2100> seb128: we resumed landings since the rootfs for the important image finished building so we can push new packages to the archive ;)
[16:25] <ogra_> seb128, same goes for custom tarballs
[16:25] <sil2100> Wellark: yw!
[16:26] <seb128> ogra_, right, but still those .changes seem to come with a delay, not the first time I've to wait to see what is in the update I just installed
[16:27] <ogra_> seb128, the changes are generated the moment the bot announces here that the image is done
[16:27] <ogra_> i.e. as soon as it shows up on system-image.u.c
[16:40] <ogra_> cwayne, go wild (i see 92 on the server)
[16:41] <cwayne> ogra_: thanks! done
[16:41] <ogra_> cool
[16:43] <sil2100> \o/
[16:43] <barry> sil2100: i'm afk for a bit for acupuncture
[16:44] <sil2100> barry: no worries, I'll still be around for a while as always :)
[16:44] <sil2100> EOD is sooo last year
[16:44] <barry> :)  thanks
[16:49] <ogra_> sil2100, hmm, seems that the system-image server still has issues :/
[16:50] <ogra_> i see 92 and 93 on the server filesystem ... but they dont get synced
[16:50] <ogra_> (to the public http space)
[16:54] <ogra_> argh
[16:55] <sil2100> grrr
[16:55] <ogra_> http://paste.ubuntu.com/8521920/
[16:55] <ogra_> thats what i get if i run the system-image import command manually
[16:56] <ogra_> cjwatson, any idea ? that looks like the python setup on nusakan changed
[16:57] <ogra_> (the former two images worked just fine)
[16:58] <cjwatson> a changed python setup seems highly unlikely and is far beyond what would be required to exhibit that symptom ...
[16:58] <cjwatson> but I don't have time to investigate this right now, as it's almost dinnertime
[16:58] <ogra_> yeah, i'm lost though
[16:59] <cjwatson> perhaps it requires a UTF-8 locale
[16:59] <cjwatson> though I would only expect that to be an issue here if there are some file names containing non-ASCII characters
[16:59] <cjwatson> which is an optimistic thing to do
[16:59] <ogra_> right
[17:00] <cjwatson> I would suggest scanning the images for such things
[17:00] <cjwatson> the import might work with LANG=C.UTF-8 but I'm hesitant to suggest actually doing that without understanding it better
[17:00] <ogra_> image 92 definitely doesnt have any changes that have added such things
[17:01] <ogra_> i could imagine image 93 to have file names in spanish or some such
[17:01] <ogra_> but even then ... these file names have been there before
[17:01] <ogra_> and it all worked before the out of disk issue ...
[17:02] <ogra_> i suspect there is rather something with the nusakan installation after the out of disk thing
[17:02] <cjwatson> I think you should investigate directly (e.g. pdb) rather than making wild guesses about system configuration
[17:03] <cjwatson> it will be a more useful line of enquiry anyway
[17:03] <ogra_> well, it worked with this mornings image ... and for the two images we had after the diskspace issue
[17:03] <cjwatson> even if there is some system-level problem you would want to track it down via pdb
[17:03] <cjwatson> because saying "there is some problem with the system" does not actually help
[17:04] <cjwatson> I cannot help further for some hours now though
[17:04] <ogra_> well, there is some problem we didnt have before the system hadd a problem ... but yeah
[17:04] <pstolowski> trainguards, https://ci-train.ubuntu.com/job/ubuntu-landing-014-1-build/73/consoleFull seems to be stuck; can you check/interrupt and rebuild unity-scopes-shell?
[17:05] <cjwatson> ogra_: and as I say that does not actually help.  we can't go to IS and say "something seems to be wrong", we need concrete analysis
[17:06] <cjwatson> I can investigate with pdb in maybe four or five hours, but I would suggest you want somebody to do it before that :)
[17:06] <ogra_> well, i have an appointment in ~1h but i'll see if i can find anything
[17:10] <sil2100> pstolowski: looking
[17:11] <sil2100> pstolowski: hm, doesn't look stuck to me
[17:11] <sil2100> pstolowski: it seems the armhf build just now started
[17:13] <ogra_> cjwatson, for later: http://paste.ubuntu.com/8522014/ ... run under pdb ... doesnt reveal much more either
[17:13] <pstolowski> sil2100, hmm, you may be right...
[17:15] <seb128> ogra_, can you try to print removed_files?
[17:15] <ogra_> just "print removed_files" at the pdb prompt ?
[17:15] <seb128> yes
[17:16] <ogra_> bah, crap
[17:16] <pstolowski> sil2100, thanks
[17:16] <ogra_> that exceeds my terminal scrollback
[17:16] <seb128> check if something in there has encoding weirdness
[17:23] <ogra_> man ... my browser has a hard time pushing that to the pastebin
[17:23] <ogra_> http://paste.ubuntu.com/8522041/
[17:23] <ogra_> there we go
[17:23] <ogra_> only 40000 lines :P
[17:23] <ogra_> sigh
[17:28] <seb128> ogra_, print type(removed_files)
[17:28] <ogra_> cjwatson, FYI ... import-images causes nusakan to run out of space in /tmp (same issue as before)
[17:28] <ogra_> seb128, i just got info in #is
[17:28] <Ursinha> ogra_: you can use pastebinit :)
[17:28] <seb128> ogra_, what info?
[17:28] <ogra_> seb128, that /tmp runs out of space while the system-image importer script gets processed
[17:28] <seb128> k
[17:29] <seb128> that might create issues
[17:29] <ogra_> which likely causes corrupt content of the var or so
[17:29] <ogra_> so the error is just fallout
[17:33] <sil2100> barry: btw.!
[17:33] <sil2100> barry: so, maybe you could help us out once you're back with a strange issue we're seeing during smoketesting
[17:33] <sil2100> barry: you might know your way around these bits
[17:34] <sil2100> barry: the issue is that sometimes during AP smoketesting autopilot is unable to find all tests to run and fails in the following way:
[17:34] <sil2100> barry: http://pastebin.ubuntu.com/8519568/
[17:35] <sil2100> barry: as you can see the last error seems to be something encoding related - we were thinking if maybe something low level in python maybe got changed and caused this issue?
[17:48] <asac> sil2100: app startup landed and has image?
[17:48] <asac> r90?
[17:48] <ogra_> Ursinha, so at the sprint, over a beer ... you will teach me how to redirect to pastebinit from within pdb
[17:49] <asac> ogra_: can you confirm?
[17:49] <ogra_> asac, no, nusakan is broken (or system-image is )
[17:49] <ogra_> asac, see #is channel
[17:49] <asac> ohhhh
[17:52] <sil2100> Yeah...
[17:52] <ogra_> yeah :(
[17:52] <sil2100> asac: but it's built, just not available in public...
[17:52] <ogra_> and it looks like it is seriously broken
[17:55] <sil2100> ogra_: does anyone know what's up?
[17:55] <ogra_> sil2100, not really ... we are all pretty clueless ... as it seems to be broken in the s-i code ...
[17:56] <ogra_> the breakage causes /tmp to never being cleaned up
[17:56] <ogra_> which at some point kills the image build server
[17:56] <ogra_> sil2100, what i have is: http://paste.ubuntu.com/8522014/ ...
[17:57] <ogra_> and the content of that variable (careful thats megabytes big) http://paste.ubuntu.com/8522041/
[17:57] <seb128> ogra_, did you try to print type(removed_files)?
[17:57] <ogra_> seb128, yes, the second paste
[17:58] <seb128> ogra_, type()
[17:58] <seb128> ?
[17:58] <seb128> ogra_, the second paste was the long list no?
[17:58] <ogra_> yeah
[17:58] <seb128> what's the type() of the variable?
[17:58] <ogra_> 40000 lines of filenames
[17:58] <seb128> right
[17:58] <seb128> give me the type :p
[17:58] <ogra_> i would need to re-run it again i guess
[17:58] <seb128> so I can give you another command to try
[18:04] <asac> what is the current image number?
[18:04] <asac> on krillin rtm?
[18:04] <seb128> 91 published
[18:05] <seb128> 92&93 are built but failing copy to the server due to the issues described ^
[18:05] <ogra_> asac, 92 has all urfkill fixes, 93 has the QML precompilation
[18:05] <ogra_> both are stuck on nusakan
[18:05] <asac> ogra_: any reason why i wouldnt see an update in system settings?
[18:05] <asac> e.g. is the server down completely?
[18:05] <ogra_> asac, because the images cant be published
[18:05] <ogra_> no
[18:06] <asac> i am on 89
[18:06] <asac> no update avail
[18:06] <ogra_> the public facing server is up and i got my update to 91
[18:06] <ogra_> including the notification
[18:07] <seb128> I've 91 as well
[18:17] <sil2100> I get 91 notification as well, upgrading in progress
[18:20] <davmor2> I blame ogra_ completely for this mess bound to be his fault ;)
[18:21] <davmor2> didn't want you feeling left out of being blamed now that Saviq is back :)
[18:37] <AlbertA> trainguards: can I get a silo for line 84?
[18:41] <barry> sil2100: hi i'm back now
[18:44] <ted> barry, welcome back :-)
[18:44] <ted> barry, Can I get a silo for line 88 please?
[18:44] <ted> barry, And we can kill silo rtm/11 that'll never land.
[18:46] <barry> ted: k
[18:48] <barry> ted: for line 88, can you please ack the dupes: https://ci-train.ubuntu.com/job/prepare-silo/2639/console
[18:49] <sil2100> barry: o/
[18:51] <ted> barry, ack
[18:55] <barry> ted: let me see if i can figure out how to kill rtm/11
[18:56] <ted> barry, Shotgun, you don't want zombie silos
[19:03] <ted> I've got two unapproved packages. Are those release team pings?
[19:04] <barry> ted: rtm/11 ^^
[19:04] <ted> barry, Cool, thanks! Should have an i-sound coming through that can land.
[19:05] <barry> ted: cool, just ping me
[19:05] <dbarth> barry: hey, i sent a ack for the silo conflict earlier; can i get a silo for line 76 please?
[19:05] <barry> dbarth: yeppers
[19:06] <AlbertA> barry: can I get a silo for line 84?
[19:07] <barry> AlbertA: sure thing
[19:07] <barry> AlbertA: please review and ack the dupes: https://ci-train.ubuntu.com/job/prepare-silo/2642/console
[19:12] <robru> barry: you should have checked ONLY_FREE_SILO on the merge clean job. Lucky there were no merges or they would have been merged.
[19:14] <barry> robru: lovely
[19:15] <robru> barry: it should be in the newbie guide, freeing silos is a common task ;-)
[19:16] <AlbertA> barry: yes please ignore rtm/landing-001 I'm coordinating with tvoss
[19:16] <barry> AlbertA: ok
[19:17] <barry> robru: ack
[19:17] <barry> AlbertA: ack
[19:22] <kenvandine> seb128, any idea why uss is FTBFS in silo 24?  says unmet build dep gdb:any
[19:23] <kenvandine> but gdb did get installed
[19:23] <kenvandine> gdb:any should match...
[19:25] <kgunn> davmor2: you still at that mir release in rtm silo20
[19:25] <kgunn> ?
[19:25] <kgunn> is there anything wrong ?
[19:26] <davmor2> kgunn: I am now I got it installed without the mesa bits :(
[19:26] <kgunn> oh man...what happened ?
[19:26] <cjwatson> kenvandine: because gdb in utopic-proposed (not utopic) has dropped the Multi-Arch: allowed field, and :any is disallowed in that case
[19:26] <kgunn> davmor2: anything we need to look at on our end ?
[19:27] <cjwatson> kenvandine: it's not clear whether that was deliberate, as it doesn't appear to be mentioned in the changelog
[19:27] <cjwatson> kenvandine: I'd suggest asking doko, as it might have been a merge accident
[19:27] <davmor2> kgunn: not unless you want to fix citrain tool so it doesn't install the mesa bits and force me to reflash my phone ;) not yet so far so good should be too long
[19:28] <cjwatson> kenvandine: https://wiki.ubuntu.com/MultiarchCross#Build_Dependencies is my reference for :any being disallowed without Multi-Arch: allowed, BTW
[19:28] <kgunn> ta
[19:29] <kenvandine> cjwatson, ah... i thought :any would still work
[19:29] <kenvandine> cjwatson, thanks, i'll check with doko
[19:30] <cjwatson> the qualifiers are generally special snowflakes in various ways :)
[19:31] <ted> barry, Can I get a silo for line 89 please?
[19:31] <ted> barry, And you can publish 88
[19:31] <dbarth> thanks!
[19:31] <ted> barry, Or ubuntu/1
[19:32] <barry> ted: you got it
[19:33] <ted> barry, Awesome
[19:33] <ted> barry, Oh, and looking at the dashboard, can you publish rtm/28 as well please?
[19:33] <barry> ted: sure thing
[19:34] <barry> ted: hmm. https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-028-2-publish/1/console
[19:34] <ted> Huh
[19:35] <ted> barry, Do you know what it's tracking there? It's a sync, so was the version it's expecting to be the pervious the one when it was created?
[19:36] <ted> I'm not certain what a "rebuild" would do.
[19:36] <barry> ted: i don't :(  maybe sil2100 or robru ?
[19:37] <barry> ted: is this comment relevant: Mirv/20141002: can't land before rtm-005 lands,
[19:39] <ted> barry, Yeah, that would have been when it was created, but it was built in utopic that already had the code in rtm/5 landed. So the package itself is correct.
[19:39] <ted> barry, I think the silo is confused, but I'm not sure how to fix it.
[19:40] <barry> ted: neither do i unfortunately.  let me see if there's something in the faq or newbie guide
[19:42] <barry> ted: take a look at the bottom of https://wiki.ubuntu.com/citrain/FAQ - could this be what's going on?
[19:42] <robru> barry: ted: error seems pretty clear to me. Make sure the latest version in rtm matches the latest version in d/changelog in trunk. Possibly there was a manual distro upload or the last release didn't merge & clean properly
[19:43] <tvoss> trainguards, can I get a silo assigned for line 90?
[19:44] <barry> tvoss: please set the target distribution column and re-ping
[19:45] <tvoss> barry, cancel my ping actually :)
[19:45] <barry> tvoss: okie dokie :)
[19:50] <ted> robru, barry, okay, this is confusing.
[19:50] <ted> Seems the utopic silo built UAL, but generated the diff from the version that was marked for June 1st.
[19:50] <ted> There's been 6 releases since then.
[19:50] <ted> Most recent on 9/25
[19:51] <barry> ted: weird
[19:51] <ted> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-018/+packages
[19:51] <ted> The diff there is huge
[19:52] <robru> ted: not sure. Was the silo prepared before those 6 releases? Anyway, just make sure trunk matches distro, then reprepare, then rebuild and it should be fine
[19:52] <ted> Yeah, so I guess rebuild that, then we can build the sync.
[19:52] <ted> No, new silo.
[19:53] <robru> ted: did you maybe do 6 releases to utopic and this is the first time in a while you're doing an rtm sync?
[19:54] <ted> robru, No, the six jump is on utopic too.
[19:55] <ted> Let's see what the rebuild does.
[19:56] <robru> ted: oh that one version number from the publish log indicated there was a revert (version was like foo.is.bar). So maybe whoever did that revert reverted 6 versions?
[19:57] <ted> robru, Well, that's also odd, the revert was 2 revisions back. It's odd the rtm silo is at a different point.
[19:58] <robru> ted: maybe qa NACKed your most recent landing. Dunno.
[20:00]  * ted is going to have to increase his qa bribes
[20:01] <cjwatson> six jump> oh you don't mean https://launchpad.net/ubuntu/+source/six do you
[20:01] <cjwatson> worried for a moment
[20:04] <barry> cjwatson: nope :)
[20:06] <cjwatson> Launchpad's diff selection for packages can sometimes be a bit odd, but it's only informational, it wouldn't have affected landing in any way ...
[20:09] <cjwatson> ted: the version it diffed against was the previous version in that PPA, which Launchpad prioritises
[20:09] <cjwatson> it's clearer if you look at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-018/+packages?field.name_filter=ubuntu-app-launch&field.status_filter=&field.series_filter=
[20:09] <cjwatson> it just so happened that that previous version got the same silo
[20:10] <cjwatson> but as I say, purely informational
[20:11] <ted> Ah, I see now.
[20:11] <cjwatson> consequence of model abuse by silos :)
[20:26] <ted> barry, I resync'd and such. For some reason it got an error again, but the PPA looks good. Perhaps republish?
[20:26] <ted> barry, rtm/28
[20:27] <barry> ted: i saw that.  i can certainly try that
[20:28] <barry> ted: hmm. https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-028-2-publish/2/console
[20:28] <ted> barry, I think you need IGNORE_STEP
[20:28] <barry> ted: so maybe ignore-step?  the error makes me a bit oncomfortable
[20:28] <barry> *un
[20:28] <barry> yeah
[20:29] <barry> ted: success this time
[20:29] <ted> \o/
[20:29] <barry> let's see what actually happens ;)
[20:29] <ted> Heh
[20:32] <ted> barry, Makes sense to me here, so I think that's all that matters: https://launchpad.net/ubuntu-rtm/+source/ubuntu-app-launch
[20:38] <barry> ted: ^^ :)
[20:39] <barry> ted: ubuntu/18 says i can publish it.  just wanted to verify that one's good to go (because it is UAL)
[20:39] <ted> barry, I think it's in unapproved still. But I'm happy merging and cleaning…
[20:40] <ted> barry, I think otherwise things'll get more confused.
[20:40] <barry> ted: so just abandon that one?
[20:55] <ted> barry, It needs to merge/clean, but I think we can abandon the publish.
[20:55] <ted> barry, Can I just do that?
[20:56] <barry> ted: go for it
[21:04] <bfiller> barry: are you the silo allocation man :)? if so, need one for line 82 on the sheet
[21:05] <barry> bfiller: i am the monkey pushing buttons
[21:05] <bfiller> barry: lucky you!
[21:22] <davmor2> camako, barry: silo rtm 020 is good for some reason the google doc is taking for ever to update
[21:22] <davmor2> and there it goes in fact
[21:23] <camako> davmor2, awesome.. thank you.
[21:26] <camako> barry, can we publish rtm silo 20 please? I think kgunn is blocked on that.
[21:28] <kgunn> ta
[21:30] <tvoss> hmmm, the publisher seems to need some love: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-009/+packages
[21:32] <camako> tvoss, hmm indeed
[21:35] <barry> camako: sure thing
[21:36] <barry> camako: ^^
[21:37] <camako> barry, hmm how do I do that?
[21:37] <barry> camako: you need to go to the ppa and view the diff for each of the packages, confirming (here) that the changes to packaging (i.e. debian/) are valid.  i'm looking at them too, but you have more direct knowledge of the changes
[21:38] <camako> barry ack
[21:40] <barry> camako: looks okay to me, but please verify
[21:40] <camako> barry, lemme skim through them..
[21:42] <camako> barry, the mir diff file only shows diff between the latest and prev build
[21:42] <camako> I'm looking at this : https://launchpadlibrarian.net/186558264/mir_0.8.0%2B14.10.20141002.2-0ubuntu1_0.8.0%2B14.10.20141005-0ubuntu1.diff.gz
[21:46] <camako> barry, but you can see the actual changes here : https://code.launchpad.net/~mir-team/mir/development-branch/+merge/236424
[21:46] <camako> barry, so I hereby acknowledge that the debian changes are valid :-)
[21:51] <camako> barry, ... and the qtmir-gles diff is not correct, either
[21:52] <barry> camako: sorry, i was on the phone.  i can ack the pack and publish
[21:52] <camako> barry, thanks.. I have to leave. If there is any problems, can you please work with kgunn?
[21:53] <camako> kgunn ^^ (may wanna read the last several lines) ^^
[21:54] <kgunn> kk
[21:57] <barry> camako, kgunn sure thing, but ^^ looks like all is good