[00:57] <Chipaca> if I change one of the MPs I'm wanting to land, do I need to do anything for the silo to pick i tup?
[00:58]  * Chipaca is rebuilding but it picked up the old MP
[01:09] <Chipaca> looks like 'reconfigure' is what i wanted
[01:56] <Chipaca> hrm. that didn't work.
[02:04] <Chipaca> ok, so reconfigure definitely does pick up the right branch
[02:04] <imgbot> [02:27]  * Chipaca tests
[03:08] <bzoltan> psivaa: I still got a build failure for the same reason - http://s-jenkins.ubuntu-ci:8080/job/ubuntu-sdk-team-ubuntu-ui-toolkit-staging-utopic-amd64-ci/607/console or was it started before the fix landed?
[03:29] <bzoltan> is anybody around who could cihelp?
[03:30] <fginther> bzoltan, hello
[03:30] <fginther> bzoltan, looking
[03:32] <bzoltan> fginther: there was a gcovr fix/update on utopic to solve that problem. I do not know what time exactly and I do not know what timezone Jenkins  is in.
[03:32] <fginther> bzoltan, the gcovr fix was introduced in 3.1-1ubuntu1, which first appears in build 608
[03:32] <slangasek> the full build log should always show you the version of all packages used
[03:32] <bzoltan> fginther:  but looking at the  http://s-jenkins.ubuntu-ci:8080/job/ubuntu-sdk-team-ubuntu-ui-toolkit-staging-ci/ it seems that #773 still has that problem
[03:34] <bzoltan> slangasek: ohh.. that is true, thanks
[03:34] <fginther> bzoltan, correct, the build numbers don't necessarily sync up. The 608 I referred to was specifically for http://s-jenkins.ubuntu-ci:8080/job/ubuntu-sdk-team-ubuntu-ui-toolkit-staging-utopic-amd64-ci/608/
[03:34] <bzoltan> fginther: but this is just one isse... the other issue is why UITK builds take 5-6 hours?
[03:36] <slangasek> the build times seem to have spiked sometime around build 734, what changed then?
[03:36] <fginther> bzoltan, there has been an excessively high load on jenkins today. Part due to the gcovr issue
[03:36] <bzoltan> fginther:  and the third question is, why so few MRs are picked to be build? During the last ~10 hours only few were picked
[03:36] <fginther> bzoltan, load is still a problem: http://s-jenkins.ubuntu-ci:8080/computer/(master)/load-statistics?type=min
[03:36] <fginther> lots of jobs are in the queue still
[03:37] <slangasek> fginther: but the build time is the actual time the job is running, no?
[03:37] <slangasek> i.e., queue times are bad but should be unrelated to http://s-jenkins.ubuntu-ci:8080/job/ubuntu-sdk-team-ubuntu-ui-toolkit-staging-ci/buildTimeTrend
[03:37] <bzoltan> fginther: I understand, but we could not get a single UITK build in the last 4-5 days. Not a single one...
[03:37] <fginther> bzoltan, ok, that is bad
[03:38] <bzoltan> fginther:  it is very very bad.. because we can not respond to real failures and our MRs are just piling up and so we risk of new conflicts and new problems
[03:38] <fginther> slangasek, ubuntu-sdk-team-ubuntu-ui-toolkit-staging-ci is a 'parent' job. It triggers a number of jobs, some of which are stuck on the build queue
[03:39] <slangasek> ah, ok
[03:39] <bzoltan> slangasek: fginther: i sthere anything I should/could do? I am considering to skip using Jenkins.
[03:39] <fginther> bzoltan, are these missing MRs related to lp:~ubuntu-sdk-team/ubuntu-ui-toolkit/staging ?
[03:39] <imgbot> [03:39] <imgbot> [03:40] <fginther> bzoltan, or a different branch?
[03:40] <bzoltan> fginther:  al our MRs are targeting the staging
[03:40] <bzoltan> fginther:  that is the branch we stage our development and I release that staging to the archive and back to the trunk occasionally ... like once a week.
[03:45] <bzoltan> slangasek: fginther: But I conducted the last big landing already with manual merging to this staging branch. Jenkins landed less then 20 MRs in the last 15 days... I have 25 active MRs in my queue. It is horror... with the present trend I expect 2-3 weeks just to land on our staging. This is a serious problem for us.
[03:51] <fginther> bzoltan, I'm looking through a few jobs to better understand what's going on here. The gcovr issue impacted lots of MRs, but it's not the only 'oddity'. One thing we can try to do is scale back a bit, like remove coverage from the staging builds
[03:51] <slangasek> bzoltan: I don't understand what this job is or what the success criteria are; are you expecting all of these subtests to pass?
[03:52] <fginther> slangasek, 'all pass' is the expectation
[03:52] <slangasek> hmm
[03:52] <slangasek> seems to be quite far from that currently
[03:52] <bzoltan> slangasek: fginther: scaling down sounds good to me...
[03:53] <slangasek> oh, I was reading things wrong (upstream projects vs. downstream projects)
[03:53] <slangasek> ok
[03:54] <bzoltan> slangasek: fginther: I am ranting pretty much without any success that oversecuring quality with super heavy builds ended up so much wasted time, that if we add up the lost time we could fix dozens of regressions. 5-6 hours for a UITK build what takes few minutes? 10 MRs and we lost a week of an engineers. Sounds expensive to me.
[03:55] <slangasek> bzoltan: well, er, who is responsible for this job configuration, if not you and your team?  I don't know anything about this setup, I don't think ranting at me will be any more successful :)
[03:56] <fginther> bzoltan, there's no reason not to explore options. The coverage build for a staging build is not all that useful (when it also takes place elsewhere)
[03:56] <bzoltan> slangasek: Sorry, mate :) it s certainly not you who should do anything :) with this.
[03:57] <bzoltan> slangasek: these configurations were extended by time... I have not added any extra crap on them ever.
[03:57] <slangasek> right... but who owns them?
[03:57] <bzoltan> fginther: can we switch off the coverage builds?
[03:57] <slangasek> http://s-jenkins.ubuntu-ci:8080/job/generic-mediumtests-builder-utopic-armhf/4612/console fun
[03:57] <Mirv> morning
[03:58] <bzoltan> slangasek: "somebody" (tm) in some otherteam
[03:58] <fginther> bzoltan, yes. I can get to that before going to bed
[03:58] <slangasek> that seems suboptimal ;)
[03:58] <bzoltan> fginther: thanks a lot!
[03:59] <fginther> slangasek, bzoltan, ownership was a lot simpler when CI and QA were the same team
[03:59] <fginther> now it's a very gray area
[03:59] <slangasek> this one doesn't appear to have anything to do with gcovr. http://s-jenkins.ubuntu-ci:8080/job/ubuntu-sdk-team-ubuntu-ui-toolkit-staging-utopic-armhf-ci/611/console
[04:00] <slangasek> fginther: is it?  I would have assumed that QA + the upstream team are responsible for defining what tests should be run
[04:00] <bzoltan> slangasek: that is an API test failure. The SDK team is to blame for that.
[04:01] <fginther> slangasek, that is the basic idea, although it is constrained by what CI is capable of doing
[04:01] <slangasek> bzoltan: ok - so you've seen it and understood it, fine, I'll leave it in your hands then :)
[04:01] <bzoltan> slangasek:  the optimal would be to have a full time integrator for the bigger and more critical assets.
[04:03] <bzoltan> slangasek: the UITK is responsible for many failures, but hen the turnaround is 1-2 days for a new MR then responding to failures is difficult.
[04:03] <slangasek> sure
[04:03] <bzoltan> slangasek: sometimes feels like 80's ... you take your code cards to the univ and go back next week to check the results :)
[04:04] <fginther> slangasek, big thanks for pointing out that mkdirs failure. That's a corrupted node
[04:05] <slangasek> so http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-utopic-touch/buildTimeTrend seems to be the job that's the limiting factor here?
[04:05] <slangasek> or is that just a wrapper around http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-mako/ + http://s-jenkins.ubuntu-ci:8080/job/generic-mediumtests-builder-utopic-armhf/ ?
[04:09] <fginther> slangasek, yep, it's essentially a wrapper
[04:10] <slangasek> http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-mako/3290/console takes a while, but it's not obvious from the log where it's spending its time... the only bits with timestamps are all within a couple minutes of each other
[04:11] <veebers> fginther, slangasek, bzoltan: Hey guys, looking at the convo, it looks like the autopilot runs are taking longer than expected?
[04:12] <slangasek> veebers: I don't have enough info to draw that conclusion
[04:13] <slangasek> could also be setup/teardown stuff taking long
[04:13] <slangasek> http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-mako/3290/console seems to show 10 minutes before autopilot is ever called
[04:14] <veebers> slangasek: ok, is there anything I can do to help currently? I'm interested if it is autopilot itself.
[04:14] <veebers> for instance, is there a point in time where these job times go up? I would  like to see if it matches the most recent release of AP
[04:14] <slangasek> and only 2 minutes from the start of the autopilot run to the last output from that job, AFAICT
[04:15] <slangasek> so I don't think autopilot itself was the bottleneck here; 2 minutes of tests, 38 minutes of setup/teardown?
[04:15] <veebers> ugh, chromium keeps crashing in that tab
[04:17] <fginther> slangasek, ahh, that one is due to the prior job taking a long time (due to long tests). Jenkins can't complete build N+1 until build N is complete
[04:17] <slangasek> um
[04:18] <slangasek> well, that seems entirely unhelpful on jenkins' part :P
[04:18] <veebers> slangasek: I see what you mean by lack of timestamps. Thanks for confirming that
[04:21] <slangasek> right, so http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-mako/3289/, the teardown is only 2 minutes, the autopilot run is 30 minutes, and the setup is 9 minutes
[04:22] <slangasek> those numbers make more sense, at least
[04:22] <slangasek> though confusingly, the first output at the top of the console log appears to be 10 minutes after the job was launched
[04:36] <fginther> bzoltan, I've deployed job updates to remove the coverage build for that branch
[04:37] <bzoltan> fginther: super! Should I expect that Jenkins will start to pick up the failed builds or should I rebuild the failing ones?
[04:38] <fginther> bzoltan, someone will need to restart the failed -ci builds. jenkins will pick up the jobs that failed -autolanding if the MPs are top-approved again
[04:42] <Mirv> thanks fginther! an exploding bzoltan would be dangerous, and I live only 1 mile from him!
[04:42] <bzoltan> Mirv: :D
[05:03] <Mirv> tvoss: when you're around, https://code.launchpad.net/~thomas-voss/platform-api/fix-1348334/+merge/229816 + https://code.launchpad.net/~charlesk/indicator-location/lp-1348334-ualc-status/+merge/230004 need to be approved
[05:03] <Mirv> for silo 014
[07:04] <bzoltan> Mirv: would you assign a silo for the line 30?
[07:08] <Mirv> sure
[07:59] <bzoltan> Mirv:  I would need a reconfig for the silo2, i forget an MR to include
[08:03]  * ogra_ wonders why he cant reach launchpad
[08:05] <sil2100> ogra_: works fine here
[08:06] <ogra_> hrm
[08:06] <Saviq> cihelp hey, I just discovered that http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/? still doesn't load all our test results, it seems to only look at test*.xml files, where some of our files are actually *test.xml...
[08:07] <psivaa> Saviq: i'll take a look at it in a bit. need to reboot
[08:08] <Saviq> which is something of a problem that we need to resolve (basically redo our CMake around tests...), but in the mean time it'd be nice if it'd actually pick up all our results
[08:08] <Saviq> psivaa, thanks
[08:08] <bzoltan> sil2100: I would need a reconfig for the silo2, i forget an MR to include. Would you be kind and please reconfigure the silo2?
[08:08] <Saviq> psivaa, fginther said he updated the job like a week and a half ago, but that doesn't seem to have really happened
[08:08]  * ogra_ reboots his router
[08:09] <Saviq> bzoltan, you can reconfigure yourself if you're not adding any new projects
[08:09] <tvoss> ogra_, problems connecting to canonical's irc?
[08:09] <Saviq> bzoltan, https://ci-train.ubuntu.com/job/landing-002-0-reconfigure/build?delay=0sec
[08:09] <bzoltan> Saviq: ahh, is that so? Is it a new feature?
[08:10] <sil2100> bzoltan: was that a new project added or just a new merge?
[08:10] <Saviq> bzoltan, no, been there since the beginning almost
[08:10] <bzoltan> sil2100:  just a new MR
[08:10] <sil2100> Right, a reconfigure from our side is only needed when you add a completely new project to the list, since this needs to be approved by the landing team (as it might conflict) :)
[08:12] <oSoMoN> sil2100, good morning, can I have a silo for line 31 ?
[08:12] <brendand> sil2100, ogra_ - no meeting this morning i guess
[08:12] <sil2100> brendand: what's wrong?
[08:12] <bzoltan> sil2100:  I have never land mixed projects... it is either the UITK or the QtC plugin. I remember being rejected after I added a new MR
[08:12] <brendand> sil2100, can *you* access .canonical. or .ubuntu. sites?
[08:13] <sil2100> brendand: launchpad works fine for me :)
[08:13] <sil2100> brendand: the IRC as well
[08:13] <brendand> sil2100, launchpad hmm. that might be a different matter
[08:13] <sil2100> bzoltan: you have to reconfigure then through the 'reconfigure' button
[08:13] <sil2100> oSoMoN: sure
[08:13] <bzoltan> sil2100:  I know that ... just wondering
[08:13] <brendand> sil2100, that's weird
[08:13] <Mirv> funnily I also have network issues
[08:14] <Mirv> bzoltan: I would, if I could reach the ci-train
[08:14] <bzoltan> Mirv:  no need, I could do that
[08:14] <Mirv> bzoltan: oh, ok
[08:14] <oSoMoN> sil2100, thanks
[08:14] <sil2100> ogra_, Mirv, brendand: so, if you guys would still have problems, I guess we'll skip the meeting
[08:14] <sil2100> No need to have a hangout with just myself in it ;)
[08:15] <Mirv> :) hangout seems to start alright, it's just a bit like half of the Internets would be broken
[08:15] <Mirv> including LP + our VPN
[08:15] <Mirv> but me and ogra_ shouldn't be sharing a router or connection :)
[08:16] <ogra_> lol
[08:16] <brendand> sil2100, so odd you can access - there are even other people in poland who can't
[08:16] <brendand> sil2100, do you have some magic fingers?
[08:17] <sil2100> hah! I've got some connection in teh goverments
[08:17] <sil2100> Special red-line internet
[08:17] <sil2100> ;)
[08:17] <ogra_> a tracepath to ci.ubuntu.com ends after 8 hops with "no reply" messages for me
[08:17] <tvoss> ogra_, I cannot even access canonical.com
[08:18] <ogra_> right
[08:18] <tvoss> ogra_, ends with "No Data Received"
[08:18] <brendand> ogra_, you should ask on #is in canonical internal... no wait
[08:18] <brendand> :(
[08:19] <Chipaca> I seem to reach the internal network ok
[08:19] <seb128> they are discussing the issue on #canonical-sysadmin on this IRC
[08:20] <tvoss> hmmm, even my phone cannot reach the app store
[08:20] <ogra_> indeed, why would that be different
[08:20] <brendand> tvoss, yeah i don't see updates
[08:21] <Mirv> the meeting would be pretty pointless anyhow without access to any of our sites, even if hangouts would be working
[08:21] <ogra_> heh ... topic in #canonical-sysadmin: "Known issues: Connectivity issues from some parts of Europe" :)
[08:21] <ogra_> "some parts"
[08:21] <Mirv> ogra_: yeah, just checked the same :)
[08:22] <Mirv> "everywhere but sil21000's house"
[08:22] <ogra_> i guess that should be "No connectivity issues from *some* parts of Europe"
[08:23] <tvoss> pete-woods, around?
[08:23] <pete-woods> tvoss: yep
[08:24] <tvoss> pete-woods, mind having a look over: https://code.launchpad.net/~thomas-voss/platform-api/fix-1348334/+merge/229816
[08:24] <tvoss> pete-woods, you haven't looked at it before, but I would like to the MP in and I addressed charles' comments
[08:25] <ogra_> sil2100, so since we cant even see the dashboard (or changes) i guess we can skip
[08:26] <pete-woods> tvoss: I don't understand how you addressed charles' comments. there are no changes / comments following his.
[08:26] <tvoss> pete-woods, yeah, sorry, just checked ... cannot push to launchpad
[08:28] <sil2100> ogra_: ok, let's just discuss things on IRC then
[08:28] <sil2100> ogra_: ...once you get your internet access back
[08:29] <ogra_> lol, my internet is fine
[08:29] <Mirv> or maybe sil2100 will quickly setup a server through which we all can route
[08:30] <pete-woods> tvoss: give me a shout when you manage to push your changes :)
[08:32] <popey> landing call?
[08:32] <popey> just me and psivaa on it, or are you all in another mirror called?
[08:32] <davmor2> popey: where at
[08:32] <ogra_> popey, we decided to skip
[08:32] <popey> https://plus.google.com/hangouts/_/canonical.com/landing-meeting
[08:32] <popey> oh
[08:33] <davmor2> popey: I can't get on it
[08:33] <ogra_> popey, due to the datacenter outage for most of us
[08:33] <popey> ok
[08:33] <ogra_> davmor2, indeed, your SSO account works via the datacenter :)
[08:33] <brendand> popey, don't tell me you can access stuff?
[08:33] <popey> Ok, I won't.
[08:33] <ogra_> lol
[08:34] <brendand> popey, O_o
[08:34] <popey> (I can't)
[08:35] <popey> thanks for skipping though, means I can eat my breakfast boiled egg in peace ☻
[08:35] <ogra_> finally a day for coding quietly in a corner \o/
[08:35] <popey> ☻
[08:36] <brendand> ogra_, just don't try to push anything
[08:36] <popey> oh, is this why i cant get #185 ?
[08:36] <ogra_> indeed
[08:36] <brendand> popey, bingo
[08:36] <ogra_> no new shiny for you til this is fixed
[08:36] <popey> bummer
[08:37] <ogra_> yeah, mean ... i'm still on 182 and see all these videos :(
[08:38] <popey> heh, i saw a post from victor while I was in bed
[08:38] <popey> thought .oO( I should update my phone )
[08:38] <ogra_> popey, damn ... stop mailing bug links around ... people click on them, yknow ?
[08:38] <popey> hah
[08:38] <davmor2> popey: already updated mine phew
[08:40]  * sil2100 cannot code in quiet as he has access to canonical servers :<
[08:41] <davmor2> right back in a bit I'm going to finish my coffee while I wait for the data center to come back so I can find out if I'm meant to be doing something via email and bug reports
[08:42] <ogra_> well, if it takes longer we should all consider visiting sil2100
[08:42] <ogra_> "wanna land something ? go to poland"
[08:44] <bzoltan> ogra_: that is not that far from here
[08:44] <ogra_> :)
[08:46] <bzoltan> Mirv:  I am good with the silo2
[08:48] <bzoltan> Mirv: should we move jenkins to Poland too? http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-utopic/2143/console
[08:50] <ogra_> wouldnt that then be "s-kamerdyner.ubuntu-ci.pl:8080" ?
[08:57] <sil2100> hahah
[09:17] <Mirv> bzoltan: not approved https://code.launchpad.net/~zeller-benjamin/qtcreator-plugin-ubuntu/kitcreate/+merge/230286
[09:19] <tvoss> pete-woods, should be up to date
[09:22] <Chipaca> sil2100: hiya. How's silo 1 looking for landing?
[09:22] <Chipaca> (if the answer is "already done", whee :) )
[09:23] <sil2100> ;p
[09:23]  * Chipaca can't reach people.c.c
[09:23] <Chipaca> hm, maybe i can reach it from my french server
[09:24]  * jgdx can't connect to cilabs vpn
[09:25] <Chipaca> so, I can get in via france
[09:25]  * Chipaca starts selling ssh access
[09:25] <ogra_> for me everything is back up
[09:25] <Chipaca> oh! it's just come back, here
[09:25] <Chipaca> woo
[09:26]  * Chipaca closes his shop
[09:26] <sil2100> Saviq: hey!
[09:26] <sil2100> Saviq: would you like to volunteer landing your recent unity8 landing for ubuntu-rtm? ;)
[09:36] <bzoltan> Mirv: approved
[09:44] <tvoss> Mirv, both missing approves are in
[09:48] <Saviq> sil2100, sure
[09:49] <Saviq> sil2100, what's the process then?
[09:49] <Saviq> sil2100, shall I branch lp:unity8/14.09?
[09:50] <Saviq> (with whatever's in ubuntu-rtm at the moment)?
[09:52] <sil2100> Saviq: yeah, I guess it would be good to create a branch there with 8.00+14.10.20140808-0ubuntu1 on top
[09:52] <Mirv> bzoltan: tvoss: both done
[09:52] <Saviq> sil2100, yup, doing
[09:53] <Saviq> sil2100, do we have a convention yet on the series name? just 14.09?
[09:53] <bzoltan> Mirv: thanks
[09:53] <sil2100> Saviq: from what I know it will be just 14.09, as the name is already solid in the archives
[09:53] <Saviq> sil2100, ok, will have to do the same for the scopes which landed in the same silo
[09:54] <sil2100> Saviq: ACK, thanks for volunteering! It might be a rough ride btw.
[09:54] <Saviq> sil2100, /me likes a rough ride
[09:54] <sil2100> Saviq: I'll use the preprod silo for now not to break the workflow of others
[09:54] <Saviq> oops
[09:54] <Saviq> did I just share too much?
[09:54] <sil2100> uh oh! TOO MUCH INFO
[09:54] <sil2100> ;)
[09:55] <sil2100> hm, in the meantime I think I need to make a *real* debootstrap for 14.09
[09:55] <popey> davmor2: bug 1355700
[09:55] <cjwatson> Saviq: 14.09 or rtm-14.09 for the branch name, I guess; you get to establish a convention :)
[09:55] <cjwatson> sil2100: You'll probably need ubuntu-keyring from ubuntu-rtm/14.09
[09:56] <cjwatson> I've been trying to decide whether it's the right thing to do to add that to mainline ubuntu-keyring ...
[09:56] <cjwatson> Saviq: You can get the version to branch off from my recent mails to ubuntu-phone@, or just from https://launchpad.net/ubuntu-rtm/+source/<source package name>
[09:57] <Saviq> cjwatson, yup
[09:57]  * Saviq goes for rtm-14.09 to be clear that this is re: ubuntu-rtm
[09:58] <cjwatson> Saviq: I guess you're setting up a productseries in LP as well with the new branch set as its focus?
[09:58] <cjwatson> Bit of a palaver but seems like the right thnig
[09:58] <cjwatson> *thing
[09:58] <Saviq> cjwatson, yupps
[10:01] <davmor2> popey: yeap confirmed, what was your one from last night
[10:05] <popey> uh
[10:06] <popey> bug 1355422
[10:07] <davmor2> popey: ah that's the one thanks just tracked it down in my irssi emails
[10:16] <Mirv> ^ it's in main, so a core-dev ack on the symbol adding at https://ci-train.ubuntu.com/job/landing-003-2-publish/66/artifact/packaging_changes_thumbnailer_1.1+14.10.20140811-0ubuntu1.diff would be useful for publishing
[10:17] <sil2100> davmor2: hey! Could you perform promotion-wise dogfooding on our latest image? ;) #185 that is
[10:19] <davmor2> sil2100: I can first I want to see if a bug I hit yesterday on my fresh flash is reproducible.  I think the notification on mako for there is no storage is blocking the guide so you just get a black screen when you swipe the welcome screen away.
[10:20] <sil2100> davmor2: oh, so that would mean that the issue that ToyKeeper also reported might be actually affecting someone, hm
[10:21] <sil2100> cjwatson: is having the ubuntu-keyring from 14.09 safe for non-rtm purposes as well?
[10:21] <davmor2> sil2100: yeah I was too busy trying to see about the no-sim issue which looks like it might be fixable
[10:21] <cjwatson> sil2100: Yes
[10:21] <sil2100> Excellent
[10:22] <davmor2> sil2100: I'll see if I can reproduce this and then carry on with a dogfood.  the way to fix it is just to reboot
[10:29] <Saviq> sil2100, hmm do we know what's gonna happen with translation updates?
[10:29] <sil2100> Not sure yet...
[10:30] <Saviq> sil2100, what I mean is that between https://launchpad.net/unity-scope-mediascanner/rtm-14.09 and the upcoming landing, there's a bunch of translation updates
[10:30] <Saviq> sil2100, we probably need to register the series for translation, too
[10:30] <Mirv> dpm: ^ any idea on translations wrt rtm?
[10:30] <sil2100> cjwatson: hm, so, I tried creating a cowbuilder for 14.09 locally as a test run and it seems to be sad that 14.09 has no aptitude - do you know why we don't have it there?
[10:30] <sil2100> https://launchpad.net/ubuntu-rtm/14.09/+source/aptitude <- as per here
[10:31] <cjwatson> sil2100: Nothing caused it to be included.  Why not use sbuild?
[10:31] <cjwatson> We only copied a selection of packages.
[10:31] <cjwatson> Is aptitude going to be a problem for CI?
[10:31] <sil2100> cjwatson: well, that's how CI Train does it, not sure if me changing this now is a good idea
[10:31] <Mirv> Saviq: I just wonder how the touch langpacks would be built - separate packages + versions for rtm and non-rtm I guess, with at least selectively choosing 14.09 branches for rtm packages or something like that
[10:32] <sil2100> cjwatson: I just know that I need a cowbuilder chroot now for building the source packages and without it in 14.09 I can't create it with --create
[10:32] <cjwatson> sil2100: Do you have a top-level list of the packages it attempts to use (no need to expand out dependencies, in fact I'd rather you didn't)?
[10:32] <dpm> Mirv, Saviq, sil2100, last time I spoke to wgrant about it, I understood that translations could be done on the derived distro, and that message sharing would work between Ubuntu and the derived RTM version
[10:32] <sil2100> cjwatson: hmmm... let me try digging into that and getting that list
[10:32] <dpm> cjwatson, any idea on this? ^
[10:32] <Saviq> dpm, right, so we need to register the rtm-14.09 series for translations
[10:32] <cjwatson> dpm: I don't really understand LP translations
[10:33] <cjwatson> dpm: That sounds about right for what I remember the plan being, but I'm by no means authoritative
[10:33] <wgrant> dpm: Translations aren't enabled for the RTM distro yet.
[10:33] <wgrant> I need to adjust a script to do a partial copy first.
[10:34] <dpm> ok, thanks wgrant, cjwatson
[10:34] <wgrant> I currently intend to just copy all the templates for the sources that we included in the copy.
[10:34] <Saviq> wgrant, I'm registering the first rtm-14.09 series for unity8, unity-scope-{click,mediascanner,scopes}, please let me know what should I do to get translations going there
[10:34] <Saviq> *serie?
[10:34] <cjwatson> series
[10:34] <cjwatson> sing. series, pl. series
[10:35] <wgrant> I use serieses as the plural when it's ambiguous :/
[10:35] <wgrant> eg. variable names
[10:35] <cjwatson> wgrant: Hopefully for all the sources currently in ubuntu-rtm/14.09, as that'll change from the initial copy (e.g. the aptitude stuff above; possible gnutls26 removal after the next sync)
[10:35] <cjwatson> I rephrase when it's ambiguous :)
[10:35] <wgrant> Right, all the sources that exist in the target.
[10:36] <wgrant> (which also conveniently fixes the issue we have today where removed sources' templates persist forever)
[10:36] <dpm> Saviq, in principle you won't need to do much. The source package will have translations enabled for the rtm distro, and for the upstream series, we'll need to mark it for sharing translations with that source package and enable automatic imports/exports
[10:36] <cjwatson> Wiktionary does list a "serie" word in English but tags it as obsolete.  It looks wrong to me as a native speaker.
[10:36] <wgrant> Right. ubuntu-rtm's upstream links are copied from Ubuntu, but can diverge without a problem.
[10:37] <wgrant> Sharing should just work AFAIK, but let me know if there are any oddities.
[10:37] <wgrant> I hope to enable translations by Friday.
[10:38] <dpm> thanks wgrant
[10:38] <Mirv> good to know
[10:39] <davmor2> sil2100: okay so the guide does appear and on first swipe I get this http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-08-12-113801.png  /me shakes his fist at Saviq I bet it's all his fault ;)
[10:40] <Saviq> dpm, well, yeah, but for them to get synced to the series branch unless we set those up for translation (assuming that we want them to be synced to those branches)
[10:40] <sil2100> pffff
[10:40] <Saviq> davmor2, ouch, how do you get that?
[10:40] <davmor2> Saviq: do a boot strap flash on mako, first swipe of the guide
[10:41] <Saviq> davmor2, can you check ~/.cache/upstart/unity8-dash.log?
[10:41] <Saviq> davmor2, unity8-dash is most probably not running at all
[10:42] <Saviq> davmor2, anything in /var/crash?
[10:43] <davmor2> Saviq: I'm wondering if it is the ciborium no storage announcement some how playing up the guide.  I'm going to dig into the logs now though
[10:43] <nik90> davmor2: have you had an issue where Unity8 dash just froze? I am able to use the launcher but the unity8 dash and welcome screen just freezes and doesn't accept input at all
[10:44] <davmor2> Saviq: unity8-dash.log looks to be filled with this UbuntuClientIntegration: connection to Mir server failed. Check that a Mir server is
[10:44] <davmor2> running, and the correct socket is being used and is accessible. The shell may have
[10:45] <davmor2> rejected the incoming connection, so check its log file
[10:45] <Saviq> davmor2, ssooo, that looks like what people reported on flo
[10:45] <Saviq> davmor2, that dash doesn't work on first boot
[10:46] <Saviq> ogra_, was it you that reported ↑? do you have a bug#?
[10:46] <davmor2> Saviq: _usr_bin_maliit-server.32011.crash
[10:46] <davmor2> _usr_bin_unity8-dash.32011.crash
[10:46] <davmor2> _usr_lib_arm-linux-gnueabihf_url-dispatcher_update-directory.32011.crash
[10:46] <davmor2> _usr_lib_arm-linux-gnueabihf_url-dispatcher_update-directory.32011.upload
[10:46] <davmor2> Saviq: I'll try and trigger a report on the unity8-dash crash
[10:46] <Saviq> davmor2, initctl list-env -g | grep MIR please?
[10:47] <ogra_> Saviq, davmor2, zyga reported one, i didnt get that because i dont wipe
[10:47] <ogra_> bug 1355726
[10:47] <davmor2> Saviq: root@ubuntu-phablet:/var/crash# initctl list-env -g | grep MIR
[10:47] <davmor2> root@ubuntu-phablet:/var/crash#
[10:47] <Saviq> davmor2, not as root please
[10:48] <davmor2> phablet@ubuntu-phablet:~$ initctl list-env -g | grep MIR
[10:48] <davmor2> MIR_SERVER_NAME=session-0
[10:48] <davmor2> MIR_SERVER_PROMPT_FILE=1
[10:48] <davmor2> MIR_SOCKET=/run/user/32011/mir_socket
[10:48] <davmor2> UNITY_MIR_SOCKET=/run/mir_socket
[10:48] <davmor2> WIZARD_ORIG_MIR_SOCKET=/run/mir_socket
[10:48] <Saviq> ah hmm
[10:49] <Saviq> the WIZARD_ thing shouldn't be there I think
[10:50] <Saviq> davmor2, initctl list-env unity8-dash | grep MIR please?
[10:50] <davmor2> Saviq: is the Wizard the welcome screen to the guide.  If it is the guide that is where it died.  If it is the welcome wizard then no I guess it should of ended
[10:50] <Saviq> davmor2, it's unrelated to the edge guide at all
[10:50] <Saviq> davmor2, it's just that the dash didn't run after the wizard
[10:51] <davmor2> Saviq: http://paste.ubuntu.com/8025664/ decided to stop spamming the channel :)
[10:53] <Saviq> davmor2, and does unity8.log even mention an incoming connection?
[10:55] <davmor2> Saviq: http://paste.ubuntu.com/8025693/
[10:55] <Saviq> davmor2, hmm ok, and then:
[10:55] <Saviq> davmor2, initctl list-env unity8 | grep MIR please
[10:56] <Saviq> davmor2, and does /run/user/32011/mir_socket exist at all?
[10:57] <davmor2> Saviq: seems to http://paste.ubuntu.com/8025698/
[10:57] <sil2100> cjwatson: ok, so it seems to be a bit hard to get an exact list, but right now the builder fails while fetching this list of packages (it's the last step for the create operation): aptitude-common libboost-iostreams1.55.0 libcwidget3 libept1.4.12 libsigc++-2.0-0c2a libsqlite3-0 libxapian22
[10:57] <cjwatson> sil2100: Can you show me a log file, or point at the code for what it's doing?
[10:57] <Saviq> davmor2, oh
[10:58] <Saviq> davmor2, no, it's all the same here where it works :|
[10:58]  * Saviq no get it
[10:58] <Saviq> davmor2, `stop unity8-dash` and start unity8-dash`?
[10:59] <sil2100> cjwatson: it's a binary, so I don't see what's happening exactly, but looking at the logs of utopic successful cowbuilder create operations, you can see what's installed when: https://ci-train.ubuntu.com/job/prepare-dist-debootstrap/11/console
[10:59] <sil2100> cjwatson: you can see the currently affected step by moving to: "I: Obtaining the cached apt archive contents" in this log
[10:59] <cjwatson> sil2100: I was hoping for the code for the prepare-dist-debootstrap job, I think - I can look into cowbuilder independently
[11:00] <davmor2> Saviq: http://paste.ubuntu.com/8025730/  I see blackness still no change
[11:01] <Saviq> davmor2, ok, we'll have to dig more locally
[11:01] <Saviq> davmor2, please reboot and see if you can spot a difference between the different commands when the dash ran fine
[11:01]  * sil2100 is not entirely informed of the steps cowbuilder and debootstrap perform
[11:03] <cjwatson> sil2100: I can figure that out.  What I need to know is what the Jenkins stuff is running
[11:04] <cjwatson> The layer that's calling cowbuilder
[11:04] <sil2100> cjwatson: sure, basically for ubuntu-rtm what is run is this:
[11:04] <sil2100> DIST="14.09" HOME=~/citrain/chroot-tools/ sudo -E cowbuilder --create --debootstrapopts --variant=buildd --mirror=http://derived.archive.canonical.com/ubuntu-rtm/
[11:04] <cjwatson> Jenkins is upsettingly opaque for this, but I presume it's in a bzr branch somewhere or something
[11:04] <cjwatson> Aha, thanks
[11:05] <cjwatson> I will chase down cowbuilder
[11:05] <sil2100> It's just a job in jenkins.. we have no access to the instance below jenkins so we have a few jobs here and there deployed to do stuff for us ;)
[11:05] <cjwatson> We should eventually really make it use the current Launchpad chroots for the series/architecture in question and then use sbuild on top of that, launchpad-buildd style
[11:06] <cjwatson> But I agree, not right now
[11:09] <davmor2> Saviq: after reboot I get the guide, I get unity8-dash and I see no Wizzard http://paste.ubuntu.com/8025782/
[11:09] <Saviq> davmor2, yup, expected
[11:09] <Saviq> davmor2, can you remove ~/.config/ubuntu-system-settings/wizard-has-run
[11:10] <Saviq> davmor2, and reboot again, let's see if it's really first boot or wizard
[11:10] <cjwatson> sil2100: Where's the next step here?  There's definitely more, because I see "pbuilder execute --buildplace /var/cache/pbuilder/build//cow.1439 --no-targz --internal-chrootexec chroot /var/cache/pbuilder/build//cow.1439 cow-shell /usr/bin/apt-get install eatmydata bzr-builddeb software-properties-common -yq --force-yes" being called and that doesn't come from cowbuilder --create AFAICS
[11:11] <sil2100> Yes, after creating this we run one more command as well
[11:11] <ogra_> Saviq, davmor2, i had issues in the past where the wizard didnt create ~/.pam_environment and the whole session went weird then
[11:11] <sil2100> DIST=$DISTRIBUTION HOME=~/citrain/chroot-tools/ sudo -E cowbuilder --save --execute -- /usr/bin/apt-get install eatmydata bzr-builddeb software-properties-common -yq --force-yes
[11:11] <ogra_> davmor2, check if that file exsists and has content
[11:11] <cjwatson> OK
[11:11]  * cjwatson runs derive-distribution to copy "build-essential aptitude cowdancer eatmydata bzr-builddeb software-properties-common" then
[11:11] <sil2100> (but of course I didn't run this yet as the main --create fails)
[11:11] <popey> davmor2: where's this bottom edge thing people talk about in the dash
[11:11] <cjwatson> (build-essential is probably already there, but)
[11:12] <davmor2> popey: pissy little arrow at the bottom of the scope on proposed
[11:12] <Saviq> popey, dash overview ;)
[11:13] <davmor2> popey: hovering over ebay for me
[11:13] <popey> i see no arrow
[11:13] <davmor2> Saviq: so that worked for me this time
[11:14] <ogra_> popey, and if you swipr from the bottom on the app scope ?
[11:14] <popey> nothing happens
[11:14] <popey> it scrolls
[11:14] <ogra_> heh, interesting
[11:14] <ogra_> you are running 185 ?
[11:14] <davmor2> popey: are you not on 184 still?
[11:14] <davmor2> popey: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-08-12-121355.png
[11:14] <popey> oh
[11:14] <popey> it lied about updating
[11:15] <popey> and says i have no updates
[11:15] <popey> phablet@ubuntu-phablet:~$ system-image-cli -n
[11:15] <popey> phablet@ubuntu-phablet:~$
[11:15] <Saviq> davmor2, so yeah, it does really like like a first-boot issue, not something the wizard causes
[11:15] <sil2100> cjwatson: thanks!
[11:15] <Saviq> davmor2, thanks for digging, please comment on the bug and we'll take it from there
[11:15] <davmor2> Saviq: so I'm going to do a reflash and check ogras file and see if that might be to blame
[11:16] <davmor2> Saviq: sure which bug? I think you said some one posted one already right?
[11:17] <cjwatson> build-essential, eatmydata, software-properties-common were already there
[11:17] <cjwatson> http://paste.ubuntu.com/8025842/ executing
[11:18] <davmor2> Saviq: nevermind it was ogra_ that linked to the bug which is why I couldn't find it on your nick :)
[11:18] <ogra_> yeah, blame me
[11:19] <sil2100> #blameogra
[11:22] <davmor2> okay it's all ogra_ 's fault
[11:25] <popey> my phone flat out refuses to update from #184
[11:26] <popey> i suspect it is caching state from when the DC was unreachable
[11:31] <popey> is there some way to clear that cache?
[11:35] <ogra_> popey, tried rebooting ?
[11:36] <popey> yes
[11:36] <popey> this feels like a bug
[11:36] <ogra_> definitely
[11:42] <davmor2> popey: there is no feel, bug it is or is not, no feel </yoda_impression>
[11:44] <cjwatson> sil2100: That should all be in place for you now.  Try again
[11:44] <davmor2> jdstrand: should we still have unconfined apps/scopes?  The weather channel scope pops up the location service provider as an uncofined app wants to access your location.
[11:45] <Saviq> sil2100, ok, row 32 is ready for a rtm silo
[11:48] <popey> filed bug 1355760
[11:48] <davmor2> Saviq, ogra_: oh that is odd, this time I got unity8-dash,  I'm now wondering if it is just that I beat the setup process trying to confirm
[11:57]  * popey forages for food
[11:57] <davmor2> Saviq, ogra_: no that's not it it looks like it might be a race condition actually creating the user maybe :(  That could be very bad :'(
[12:00] <sil2100> cjwatson: oh, it seems to need ccache as well
[12:01] <cjwatson> Did I miss that somehow?  Whoops
[12:03] <ogra_> davmor2, the user is created at image build time
[12:04] <ogra_> see what i wrote earlier ;)
 Saviq, davmor2, i had issues in the past where the wizard didnt create ~/.pam_environment and the whole session went weird then
[12:06] <davmor2> ogra_: yeah sorry that is what I meant.  I just don't seem to be able to get it back to the broken state to see if the file exists
[12:13] <sil2100> Saviq: thanks! I'll try that after lunch
[12:13] <sil2100> :)
[12:17] <sil2100> davmor2: so, is that some promotion blocker?
[12:22] <ogra_> sil2100, not being able to do the initial setup ? ...
[12:23] <sil2100> ogra_: is that reproducible for everyone?
[12:23] <ogra_> seems for everyone who installs with --wipe
[12:31] <cjwatson> sil2100: try again
[12:36] <jdstrand> davmor2: hey, there should be very, very few unconfined click apps (terminal, filemanager and music-app are the only three I know of)
[12:37] <jdstrand> davmor2: scopes can be different and there is only confinement for network only scopes
[12:37] <tvoss> jdstrand, the dash queries the location, and the dash is an app now
[12:38] <jdstrand> davmor2: I'm not sure why the weather channel scope would not be a network scope
[12:38] <jdstrand> davmor2: ^
[12:39] <jdstrand> tvoss: I guess unconfined is another nice example for precaching :)
[12:39] <tvoss> jdstrand, yup, working on that
[12:39] <oSoMoN> sil2100, Mirv: hey, can silo 6 be published?
[12:40] <sil2100> oSoMoN: sure!
[12:56] <Mirv> oSoMoN: sure, as said :)
[12:57] <Mirv> I didn't btw get packaging ack for silo-003, so it's stuck
[12:57] <Mirv> (https://ci-train.ubuntu.com/job/landing-003-2-publish/lastSuccessfulBuild/artifact/packaging_changes_thumbnailer_1.1+14.10.20140811-0ubuntu1.diff)
[12:58] <sil2100> o/
[12:58] <sil2100> Mirv: let me take a look at that
[12:59] <sil2100> ...or maybe not
[12:59] <sil2100> Just noticed it's a main package :|
[12:59]  * sil2100 is powerless against it
[13:02] <davmor2> tvoss, jdstrand: okay so it is the dash as an app that is making the request and the dash is the unconfined app, that would make more sense.  As for the Weather app it is networked and it does an auto search for location to give you your local forecast.
[13:03] <camako> robru, trainguards: just giving a heads up that we'll be done with Mir 0.6.0 testing in a couple of hours. So we are close to landing silo 7...
[13:03] <camako> sil2100 ^
[13:10] <Mirv> sil2100: indeed, main
[13:10] <jdstrand> davmor2: it sounds like the weather app probably shouldn't be unconfined, but Canonical apps don't strictly have to be (even though they should be if possible)
[13:16] <cjwatson> sil2100: Looks like the pbuilder setup worked?
[13:16] <cjwatson> https://ci-train.ubuntu.com/job/prepare-dist-debootstrap/12/console
[13:17] <sil2100> cjwatson: yes :)
[13:18] <balloons> fginther, just wondering if you'd had a chance to swap clock to python3 yet
[13:18] <fginther> balloons, not yet, should get to it today
[13:19] <balloons> thanks.. just let me know when
[13:21] <thostr_> Mirv: anything I need to do for silo 3?
[13:22] <sil2100> Saviq: I assigned a silo for the RTM landing, but please wait a moment for me to create some jobs for you :)
[13:23] <Saviq> sil2100, sures
[13:26] <cjwatson> I assume there're going to be spreadsheet entries and dashboard setup and such for RTM?
[13:26] <cjwatson> Shouldn't really need me, but ...
[13:27] <sil2100> cjwatson: sure, we did some preparations for that already, but not in production yet - for now for testing we'll be driving the landing through jenkins
[13:27] <cjwatson> ack
[13:28] <sil2100> Saviq: so, can you test it by https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-000-1-build/ ?
[13:28] <sil2100> (it might fail miserably, just so you know)
[13:28] <sil2100> ;)
[13:29] <Saviq> sil2100, IT'S ALIVE
[13:30] <sil2100> IMPOSSIBLE
[13:30] <Saviq> sil2100, dead
[13:30] <Saviq> https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-000-1-build/1/console
[13:30] <sil2100> Yessss
[13:30] <sil2100> Ok, let me check that
[13:31] <sil2100> AH
[13:31] <sil2100> Ok hmmm
[13:31] <sil2100> Give me some moments to contemplate on it
[13:36] <cjwatson> Oh, that's exciting
[13:36] <cjwatson> +14.10+14.09? ;-)
[13:36] <sil2100> ;p
[13:37] <cjwatson> Semi-serious
[13:37] <sil2100> Yeah, I forgot that I worked-around that during landing, pff
[13:37]  * sil2100 bumped the project version number then
[13:37] <sil2100> It's just a matter of finding a naming scheme
[13:37] <cjwatson> Technically we can copy versions into ubuntu-rtm from an ubuntu-rtm PPA that are less than what's currently in ubuntu-rtm, but I don't think it's a good idea
[13:37] <sil2100> Good thing that it came up now though
[13:37] <sil2100> Indeed
[13:37] <cjwatson> Nor is having to bump the project version number for everything a good idea
[13:38] <cjwatson> Maybe +14.10rtm14.09?
[13:38] <cjwatson> It's going to be fairly ugly whatever you do I think
[13:48] <jibel> davmor2, popey do you know the bug # for shell not starting on first boot after a --wipe?
[13:48] <popey> jibel: not seen that
[13:48] <davmor2> jibel: yes
[13:48] <davmor2> jibel: https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1355726
[13:48] <jibel> davmor2, thanks
[13:52] <Mirv> thostr_: it's our job to find a core-dev to look at the packaging diff, so nothing to do at the moment
[13:55] <brendand> sil2100, looks like there was a slip up with the camera-app 'fix'. plars helped me realise i might have accidently allowed the location request when trying to implement the fix
[13:55] <brendand> sil2100, so the fix i didn't really work
[13:55] <brendand> sil2100, boo me
[13:55] <brendand> sil2100, good news is that now we know and can get a proper fix
[14:14] <charles> pete-woods|away, thanks for picking up that review for tvoss 'overnight'
[14:14] <tvoss> charles, :)
[14:22] <ralsina> Can I get a silo for row 33 please?
[14:23] <sil2100> cjwatson: what do you think about 0.1+rtm+14.09.20140812-0ubuntu1 ?
[14:23] <sil2100> brendand: oh... hm, so it seems that it doesn't properly set the enviromnent variable at all, right?
[14:25] <brendand> sil2100, it sets it but probably in the wrong way/place
[14:25] <brendand> sil2100, so perhaps camera-app doesn't see it
[14:27] <brendand> tvoss, how can i clean the permissions granted to an app?
[14:29] <tvoss> brendand, right now: rm -rf ~/.local/share/UbuntuLocationService, mp under review to wire it up system settings
[14:29] <popey> oops, did ci die?
[14:29] <popey> http://ci.ubuntu.com/smokeng/utopic/touch/ gives me Something broke while generating the page. Please try again in a few minutes, and if the problem persists file a bug or contact customer support. Please quote OOPS-ID OOPS-3fcee4b4a6e845f599f08ce143b5de99
[14:30] <brendand> tvoss, i deleted that and camera app still doesn't request permissions
[14:31] <brendand> tvoss, i declined it once, but need to get back to the old state to test this fix
[14:32] <tvoss> brendand, otp, hang on
[14:33] <brendand> tvoss, ok - note that i don't have that directory now
[14:36] <sil2100> Saviq: I re-ran the build job with the version fixed
[14:37] <Saviq> sil2100, kk
[14:39] <Saviq> sil2100, looks better
[14:46] <sil2100> uh oh
[14:47] <sil2100> Aaaargh
[14:48] <sil2100> Saviq: ok, need to abort the job, it seems there's a leftover from my debugging somewhere...
[14:48] <sil2100> And it uploaded the package to the dogfood server :|
[14:54] <sil2100> Saviq: ok, it's running now
[14:58] <Saviq> sil2100, kk
[14:59] <tvoss> brendand, okay, here we go. Are you sure that the testing env var is not set?
[15:00] <brendand> tvoss, i'll double check, but it wasn't working even when i thought i'd set it, so i don't think so
[15:00] <tvoss> brendand, okay
[15:00] <brendand> tvoss, anyway i reflashed the device so i'll see where i get
[15:01] <tvoss> brendand, great,thank you
[15:05] <bfiller> cjwatson: any ideas what is causing this failure building gallery click package on jenkins? looks related to libexiv2 stuff: https://jenkins.qa.ubuntu.com/job/generic-click-builder-utopic-armhf/401/console
[15:06] <sil2100> bfiller: hi! Is the decision to remove notes-app final? Can we remove it from our smoketesting infra and from the image seed?
[15:06] <brendand> tvoss, launch camera, permissions requested, 'Allow', delete .loca/share/UbuntuLocationService/trust.db, relaunch camera, permissions not requested
[15:06] <bfiller> sil2100: yes
[15:09] <tvoss> brendand, let me try
[15:09] <tvoss> brendand, did you reboot?
[15:10] <brendand> tvoss, ah no - good point
[15:11] <sil2100> plars: since it's final, could you maybe remove notes-app from smoketesting? :)
[15:12] <brendand> tvoss, ok cheers - got to remember to reboot. thanks
[15:13] <tvoss> brendand, cool, thank you
[15:16] <jibel> brendand, davmor2  would you have time to verify silo 15? it's bug 1342351
[15:17] <davmor2> yeap sure
[15:17] <jibel> brendand, davmor2 I see no improvement with it but we would like to eliminate the cause of broken mp3
[15:18] <brendand> davmor2, mind if i leave it to you? just trying to fix a ci failure
[15:18] <davmor2> brendand: yeap no worries
[15:19] <sil2100> ogra_: so it seems I won't be able to be on todays meeting, just like previous Tuesday ;/
[15:19] <ogra_> sil2100, hmm, and i dont know what to discuss ... apart from looking over results
[15:21] <sil2100> ogra_: I guess test results, and just ask davmor2 to maybe compose a list of current blockers that he found :)
[15:23] <sil2100> cjwatson: hm, do you have access to the silo PPA e-mails? Since I'm wondering if the uploads got rejected
[15:24] <ogra_> sil2100, yeah
[15:25] <ogra_> sil2100, fine then. i'll do it as usual :)
[15:26] <Saviq> sil2100, still not good https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-000-1-build/3/console
[15:26] <sil2100> Saviq: yeah, I poked cjwatson just now... it seems it uploaded to LP this time, but the packages didn't appear
[15:26] <Saviq> sil2100, it could also log the command it used to upload to the PPA
[15:30] <plars> sil2100: will do
[15:31] <plars> sil2100: is it getting replaced with something else by any chance?
[15:31] <sil2100> Saviq: I'm pretty sure the right command was used, but it simply got somehow rejected it seems
[15:31] <sil2100> plars: reminders - and we have that in the tests already
[15:32] <camako> robru, trainguards, silo landing-7 (Mir 0.6.0) is now fully tested and ready to be published...
[15:34] <brendand> tvoss, TRUST_STORE_PERMISSION_MANAGER_IS_RUNNING_UNDER_TESTING doesn't seem to work. unless i'm not defining it in the right place
[15:34] <Saviq> sil2100, sure, printing it won't make it worse
[15:35] <tvoss> brendand, where do you define it? I thought you reported it working before?
[15:35] <sil2100> Saviq: I'm trying to dput an upload locally from my machine
[15:35] <brendand> tvoss, that was a case of being hasty - i didn't realise that i'd already granted the permission (or denied it, either way)
[15:35] <sil2100> camako: thanks! We'll publish it soon :)
[15:36] <brendand> tvoss, so my test wasn't really legit
[15:36] <camako> sil2100, thanks!
[15:36] <brendand> tvoss, which sucks, but now i need to figure out the correct place to define it
[15:36] <brendand> tvoss, or if it even works at all
[15:36] <sil2100> robru: since I will be away for the meeting, could you publish silo 007 (mir) and kick a new image once that lands in the archive?
[15:36] <tvoss> brendand, so it needs to be defined in the env of the location service
[15:37] <sil2100> cjwatson, Saviq: found the problem... ;/
[15:37] <brendand> tvoss, ahhhh
[15:37] <brendand> tvoss, so my code was never going to work
[15:37] <sil2100> cjwatson, Saviq: so it seems the default dput.cf is just broken for ubuntu-rtm (non ubuntu) ppa uploads
[15:37] <brendand> tvoss, well then the test would have to restart the location service i guess
[15:37] <tvoss> brendand, yup ... or look into the location service override
[15:38] <tvoss> brendand, we have an override upstart job
[15:38] <brendand> tvoss, how to do that?
[15:39] <tvoss> brendand, I think ogra_ can help here. ogra_, where is the override upstart job for the location service defined?
[15:39] <sil2100> cjwatson, Saviq: I'll fix that once I'm back...
[15:39] <tvoss> brendand, in the end, you end up setting an android property
[15:39] <ogra_> brendand, in lxc-android-config
[15:40] <brendand> ogra_, what's that?
[15:40] <brendand> ogra_, a package, i see
[15:41] <ogra_> brendand, yeah
[15:41] <brendand> ogra_, how do you use the .override file?
[15:41] <ogra_> brendand, not CIed (for various reasons) if you have changes i'll happily upload them for you
[15:42] <ogra_> brendand, it overrides the default job ... by incrementally adding if stuff isnt in the original or by replacing if stuff exists
[16:17] <cjwatson> sil2100: That sounds unappealing.  Whatever we pick should sort nicely with respect to the 14.10 stuff, surely
[16:18] <cjwatson> bfiller: I'm afraid I'm about to go on vacation, but it looks like adding -ldl somewhere would help.
[16:18] <cjwatson> sil2100: There's a dput in trusty-proposed which makes this better.
[16:19] <bfiller> cjwatson: ok, just curious why the deb build works fine but the click build has this error
[16:23] <cjwatson> bfiller: The click build is the only one that does the static linking of exiv thing
[16:23] <cjwatson> bfiller: It worked when I tested it, but dunno; sticking -ldl inside the -Wl,-Bstatic or whatever it is layer ought to fix it anyway
[16:24] <bfiller> cjwatson: ok
[16:25] <robru> cjwatson, infinity: need packaging reviews in silos 7 and 8 ^^
[16:25] <robru> silo 8 has a new binary package, silo 7 has some big changes to the mir stack
[16:25] <cjwatson> robru: Out of time before my vacation, sorry
[16:25] <brendand> ogra_, the file looks like this - http://paste.ubuntu.com/8027813/
[16:26] <robru> cjwatson, no worries, have fun!
[16:26] <cjwatson> I have like an hour left and need to finish reviewing https://code.launchpad.net/~mvo/click/debsigs-verify/+merge/226652 in that
[16:26] <brendand> ogra_, except the wep-key and id values are fake obviously
[16:26] <cjwatson> Thanks :)
[16:28] <brendand> ogra_, in return how do i use those override files? is it something i need to specify to initctl?
[16:28] <pmcgowan_> kenvandine, silo 6 merge conflict
[16:29] <kenvandine> already handled :)
[16:29] <pmcgowan_> of course!
[16:30] <kenvandine> mostly... i removed the 2 language branches until attente fixes
[16:30] <kenvandine> and jgdx fixed his
[16:35] <bzoltan> fginther: do you know why this one is UNSTABLE? http://s-jenkins.ubuntu-ci:8080/job/generic-mediumtests-utopic/2662/console
[16:35] <bfiller> robru: any silos available for line 34?
[16:36] <robru> bfiller, yep, you got 3 ;-)
[16:37] <bfiller> robru: cheers
[16:39] <davmor2> popey: open messaging app, swipe up to write a new message,  start to type in a name from your contacts, when you see it tap it.  Do the first 2 letters disappear of to the left of the contact section
[16:45] <popey> davmor2: whole first name disappears
[16:46] <popey> davmor2: http://imgur.com/8gHpRu9
[16:46] <davmor2> popey: so for me only the frist 2 letters go but that is a good enough confirmation I'll write up a bug
[16:53] <davmor2> jibel, jhodapp: silo 15 is better but I wouldn't say it was fixed, let me run another couple of tests and run a timer on the gap between tracks and get back to you though
[16:54] <jhodapp> davmor2, right...there's some mp3s (or combo of) that it's still not fixed for
[16:56] <jhodapp> davmor2, is that what you're seeing? It most of the time advances for you while unplugged but not always?
[16:57] <davmor2> jhodapp: no it always advances but there is a delay of about 20-30seconds
[16:57] <jhodapp> davmor2, ok...for me it almost always advances but there's a song or two where it doesn't until after 20-30 seconds
[16:58] <jhodapp> davmor2, did you upgrade media hub from the silo and reboot?
[16:58] <davmor2> jhodapp: I did a citrain device-upgrade 15
[16:59] <davmor2> it takes care of everything else
[16:59] <ahayzen> jhodapp, i was seeing the same but a longer delay of a few minutes (note i was using flacs, which maybe worth testing if they emphasize the issue) but i have yet to try your silo to see if it fixes the issue
[16:59] <jhodapp> davmor2, it rebooted your device?
[16:59] <davmor2> jhodapp: yeap
[16:59] <jhodapp> ahayzen, cool, would appreciate that
[17:00] <ahayzen> jhodapp, i'll hopefully have a look tonight, where is best to comment? in the merge proposal ?
[17:00] <davmor2> jhodapp: of course now it is calling me a liar and just playing it :)
[17:00] <jhodapp> ahayzen, in the bug associated with the MR
[17:01] <ahayzen> jhodapp, cool
[17:01] <jhodapp> davmor2, ha!
[17:06] <robru> camako, https://ci-train.ubuntu.com/job/landing-007-2-publish/36/artifact/packaging_changes_qtmir-gles_0.4.1+14.10.20140811.1-0ubuntu1.diff is this intentional? why are you dropping mircommon-dev but not adding libmircommon-dev?
[17:09] <davmor2> jhodapp: so it looks like first run after the fix had issues but after that everything played as expected.  Hope that makes sense.  I'll try another album after tea
[17:10] <jhodapp> davmor2, so a second run as in you never restarted media-hub but paused playback and then started again from music-app?
[17:18] <camako> robru, yes it's intentional. It's not a simple name change - we inspected and reorg'ed some of the mir packages ... Some libraries that used to be part of mircommon-dev are now part of other mir packages. In this case (you don't see  it in the diff), libmirserver-dev, and libmirclient-dev cover all the needs for qtmir-gles
[17:19] <robru> camako, ok thanks. got some pushback from doko on this release, I'm just putting together some small packaging fixes
[17:19] <camako> robru, ok let me know if I can help..
[17:20] <fginther> bzoltan, there was 1 test failure in the child job: http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-utopic/2153/testReport/
[17:20] <robru> camako, yeah, so basically I was told that the new packages are missing Replaces: info for the old packages they replace, just trying to sort it out now
[17:21] <robru> camako, why does libmirplatform1 no longer Replaces: libmirserver0?
[17:21] <camako> robru, lemme check
[17:21] <robru> camako, it got dropped in the diff
[17:21] <robru> camako, https://ci-train.ubuntu.com/job/landing-007-2-publish/36/artifact/packaging_changes_mir_0.6.0+14.10.20140811-0ubuntu1.diff
[17:28] <jibel> jhodapp, I did another test, play song1 until it stops, wake up the device, songs 2 will start, then don't exit music-app and restart from song 1 and let it play. This time it won't stop and advance to next song with screen blank
[17:30] <jhodapp> jibel, ok, so that's basically what davmor2 just found too
[17:31] <jhodapp> jibel, so once you start playback the first time, it always hangs while trying to advance to the second song?
[17:31] <jibel> jhodapp, yes
[17:31] <camako> robru, honestly, libmirserver0 should have been removed a long time ago... When some content from libmirserver was factored out and put into libmirplatform, it was introduced. We are already on libmirserver24 now, and if anything still depends on libmirserver0, then a "replaces" line is not gonna make it work. :-)
[17:31] <jibel> jhodapp, I'll reboot and try again to confirm
[17:31] <robru> camako, haha, good point. ok
[17:31] <jhodapp> jibel, interesting...it never hangs after the first song for me but instead after the second
[17:32] <robru> camako, ok, so libmircommon1 isn't a rename of anything, it's actually a new thing, right?
[17:32] <jhodapp> jibel, I'm going to try your music now...I can't get it to hang anymore
[17:32] <camako> robru, correct
[17:33] <jibel> hm, my mako hung on the greeter :/
[17:35] <cjwatson> So it's true that Replaces: libmirserver0 is safe to drop since trusty had libmirserver18; just to be clear though, Replaces (without Conflicts) doesn't mean that a package is a rename of another, it means that some files moved from the replaced package to the replacing package
[17:35] <cjwatson> (Conflicts+Replaces has separate semantics and is for package renames)
[17:45] <jibel> jhodapp, bug reproduced after a reboot.
[17:46] <jhodapp> jibel, yeah and I figured out why I'm not seeing it as often as you do...there are wakelocks hanging around that aren't getting cleared
[18:00] <bfiller> fginther: ping
[18:00] <fginther> bfiller, howdy
[18:01] <bfiller> fginther: can you help figure out what's going wrong with this. it builds the deb fine but not the click: https://code.launchpad.net/~artmello/gallery-app/gallery-app-fix_dependencies/+merge/230374
[18:02] <bfiller> fginther: and the same branch builds fine if I use http://s-jenkins.ubuntu-ci:8080/view/click/job/gallery-app-click-from-branch/build
[18:02] <bfiller> fginther: that is, the click builds when using click-from-branch url
[18:05] <davmor2> jhodapp: so new album playing no issue I'll try a reboot and see if I can confirm what jibel is seeing
[18:07] <fginther> bfiller, I'm not sure if it's related, but the gallery-app-click-from-branch job is using trusty chroot, while generic-click-builder-utopic-armhf is using a utopic chroot.
[18:08] <bfiller> fginther: most likely is related, they are using different versions of libexiv
[18:08] <bfiller> fginther: I think that is the problem
[18:08] <fginther> bfiller, should these be using utopic?
[18:08] <bfiller> fginther: shouldn't click-from-branch be using utopic as well? this is where we build clicks that get uploaded to the store
[18:08] <bfiller> fginther: yes..
[18:09] <fginther> bfiller, that would be my expectation. The lack of an update to utopic was missed during the transition
[18:10] <fginther> bfiller, I will get the other builder updated to utopic
[18:10] <bfiller> fginther: ok thanks
[18:10] <jhodapp> davmor2, k...I know what's going on and what to tweak
[18:12] <davmor2> jhodapp: still no harm in a confirmation though :)
[18:12] <jhodapp> indeed, thanks
[18:15] <davmor2> jhodapp: plus I was enjoying the Album before I was rudely interrupted by testing coming to an end ;)
[18:15] <jhodapp> davmor2, ha! that means things are working pretty nicely ;)
[18:18] <davmor2> jhodapp: until you reboot and then back to 20-30 second gap so confirming what jibel is seeing
[18:18] <jhodapp> davmor2, yeah, that's because the multiple system wakelocks registered with powerd get cleared with reboot :)
[18:43] <camako> robru, any other questions I can help you with regarding silo 7?
[18:50] <sil2100> cjwatson: hmm, the citrain machine is precise, but I might ask webops to just install the trusty-proposed version
[18:56] <sil2100> I guess there shouldn't be any dependencies problems
[18:56] <Saviq> sil2100, I think we should consider only getting the first line of commit messages to the changelog, it's useful to have verbose commit messages in history, less so in the changelog
[18:57] <Saviq> sil2100, changelog could potentially mention at which revision it was merged for easier reference
[18:58] <sil2100> Saviq: hm, it would be hard to follow for all projects, but we might modify this a bit - we might take the commit message till an empty line instead, not just till the newline
[18:58] <Saviq> sil2100, yeah, or that
[18:58] <sil2100> So if you have a commit message that consists of 3 lines, where the 2 is just a newline, then it would take only the first one
[18:58] <Saviq> sil2100, brief + newline seems to be a convention
[18:59] <Saviq> sil2100, want me to file a bug?
[18:59] <sil2100> Ok, good idea then, but I need to think about the revision in the changelog itself
[18:59] <sil2100> Yes please :)
[18:59] <Saviq> sil2100, cu2d?
[18:59] <sil2100> It would be useful, but I'm afraid it might make the changelog look a bit bzr-specific
[18:59] <sil2100> Saviq: I guess that would be easiest to find
[19:02] <Saviq> sil2100, right, good point on the bzr-specific, and then it can easily get out of sync
[19:02] <sil2100> cjwatson: or maybe I'll just apply a safe workaround
[19:03] <Saviq> sil2100, bug #1355999
[19:03] <Saviq> oh oh I want the next bug no
[19:03] <Saviq> quick, think!
[19:17] <sil2100> ;)
[19:25] <nik90> sil2100: quick question when is the plan to promote an image? Just want to make sure I get some thing in before that happens
[19:30] <sil2100> nik90: so, I wasn't around for the meeting when the discussions were being made, but it seems we have some minor blockers
[19:30] <sil2100> davmor2: you still around?
[19:30] <davmor2> sil2100: no
[19:30] <sil2100> davmor2: ah, then nevermind... wait, what?!
[19:30] <sil2100> :O
[19:31] <davmor2> sil2100: no one here but us rabbits
[19:31] <davmor2> sil2100: whats up chap
[19:32] <sil2100> davmor2: uh oh, then, rabbits, could you tell us if there are any promotion blockers currently? Is the SD-card message thing serious?
[19:32] <davmor2> sil2100: check your inbox
[19:32] <davmor2> sil2100: name your looking for is bug list
[19:33] <sil2100> OH!
[19:33] <nik90> I suppose that is bad
[19:33] <davmor2> nik90: not that bad
[19:34] <sil2100> davmor2: thanks ;)
[19:34] <davmor2> I think there are only 7 to consider 3 potential blockers
[19:34] <davmor2> sil2100: no unity8-dash on initial boot is a definite blocker
[19:34] <davmor2> sil2100: turns out it was nothing to do with the sdcard notification
[19:35] <sil2100> k
[19:48] <bfiller> robru: need a silo for line 31 please
[19:55] <robru> bfiller, ok you got 8
[19:58] <bfiller> robru: thanks
[19:59] <robru> bfiller, you're welcome!
[19:59] <davmor2> night all
[20:00] <cjwatson> sil2100: It's easy to tweak in ~/.dput.cf if you prefer that
[20:03] <sil2100> cjwatson: that's the workaround I did ;)
[20:04] <sil2100> cjwatson: and the packages are building fine
[20:04] <cjwatson> sil2100: I guess I'm safe to go on vacation then
[20:05] <cjwatson> sil2100: Adam/Steve/Stéphane should be able to figure out my proposed-migration lash-up, at a pinch, or William if there are problems on the LP side
[20:48] <sil2100> Saviq: ok, so the packages got build (so says the build job at least)
[20:48] <Saviq> sil2100, coolz
[20:48] <sil2100> Saviq: hm, I guess normally we would need to test those, like on some ubuntu-rtm based images
[20:49] <Saviq> sil2100, yeah, was about to ask if those exist yet :)
[20:50] <sil2100> I remember them being mentioned
[20:50] <sil2100> Saviq: hah! I see a channel called ubuntu-touch/ubuntu-rtm/14.09
[20:51] <Saviq> sil2100, let's see!
[20:53] <Saviq> sil2100, there's even a -proposed ;)
[20:57] <jhodapp> davmor2, a new fix with the wakelock logic should finish building in a few mins
[20:57] <jhodapp> davmor2, it'll be ready for another go at testing music/video playback
[20:58] <sil2100> Saviq: ok, so ;p The spreadsheet is still not compeltely ready, so once you test the silo set row 26 to Testing done
[21:00] <sil2100> Saviq: it doesn't seem assigned, but yeah, I'll look at it
[21:02] <jhodapp> davmor2, it's ready
[21:02] <Saviq> robru, citrain needs to get updated to support rtm silos :)
[21:03] <robru> Saviq, yeah, sil2100 and I are working on that...
[21:04] <robru> sil2100, you're up quite late... did you get my email from yesterday about the jenkins jobs & json filenames?
[21:04] <sil2100> robru: I'll most probably switch to the ubuntu-rtm-* in the jenkins jobs indeed, although I've been thinking if we could maybe leave the names as they were for ubuntu- cases (as a special case)
[21:05] <robru> sil2100, yeah, I want to avoid special cases as much as possible.
[21:05] <Saviq> sil2100, btw looks like LP isn't too smart, says ppa should be ppa:ci-train-ppa-service/landing-000
[21:05] <robru> sil2100, if we make the existing jenkins jobs ubuntu-* I can update the links in the dashboard trivially and the code will be much simpler.
[21:05] <sil2100> Saviq: yeah ;) I think we need to report that to cjwatson or wgrant
[21:05] <Saviq> sil2100, and add-apt-repository isn't too smarter either
[21:06] <robru> turns out, derived distributes are kind of an unsupported pain ;-)
[21:07] <cjwatson> Saviq: those are known problems
[21:07] <cjwatson> tracked in asana
[21:07] <Saviq> cjwatson, right, if only we had a common task tracking system across at least a division in the company... :|
[21:07] <cjwatson> robru: they're supported now, just not complete :)
[21:08] <robru> cjwatson, this is an interesting vacation you're on...
[21:08] <cjwatson> haven't quite started yet
[21:08] <cjwatson> still packing.  but as of tomorrow I'll be nowhere near a computer
[21:09] <cjwatson> sil2100: I'm not sure whether image building will work from iso.qa; if it doesn't, get somebody with access (~ubuntu-cdimage intersect ~canonical, roughly) to run "DIST=ubuntu-rtm/14.09 for-project ubuntu-touch cron.daily-preinstalled --live" as cdimage@nusakan
[21:09] <robru> cjwatson, considering it's 10PM in england, you should have shut down your computer 4 hours ago ;-)
[21:09] <cjwatson> I don't shut down my computers, normally
[21:09] <robru> cjwatson, neither do I, but I do the night before I leave on vacation ;-)
[21:09] <cjwatson> impedes the nightly backups running :)
[21:10] <Saviq> sil2100, looks good!
[21:10] <robru> cjwatson, ah, well I don't run services on my local laptops.
[21:10] <Saviq> (a short sanity check since this has been tested properly already)
[21:10] <cjwatson> anyway, I'm only sat down for a few minutes while locating the bits that go with my kilt, so quit yer complaining ;-)
[21:10] <robru> that's what the cloud is for ;-)
[21:10] <robru> hehe
[21:10] <cjwatson> robru: nor do I, but I like my laptop contents to be backed up, and that requires it to be switched on while the backups are running :)
[21:11] <Saviq> cjwatson, have a good time!
[21:11] <robru> cjwatson, but but... if you're on vacation, there's nothing new to back up? I have an hourly backup that runs on my main laptop but it doesn't need to run when I'm not around making new files...
[21:11] <cjwatson> new stuff to back up from today!
[21:12] <robru> cjwatson, see, that just brings us back to the original point... ;-)
[21:12] <cjwatson> I was working today ..
[21:13] <robru> cjwatson, ok ok
[21:17] <sil2100> Saviq: so, can I publish? ;)
[21:17] <Saviq> sil2100, you can, dear sir
[21:17] <sil2100> Saviq: or was that for something else?
[21:17] <sil2100> o/
[21:17] <sil2100> Let's 'break the world' (tm)
[21:28] <sil2100> Oh!
[21:28] <sil2100> Almost forgot about something
[21:28] <sil2100> slangasek: are you around?
[21:29] <slangasek> sil2100: on my way out the door
[21:29] <sil2100> slangasek: oh noes
[21:29] <slangasek> so if you can be quick... :)
[21:29] <sil2100> slangasek: would you manage to do a bzr pull on snakefruit for the cu2d directory? ;)
[21:29] <sil2100> slangasek: since I suppose it still uses the cu2d-rtm branch
[21:30] <sil2100> I would need a new copy2distro there
[21:30] <sil2100> (so that we won't use dogfood anymore)
[21:31] <slangasek> sil2100: http://bazaar.launchpad.net/~sil2100/cupstream2distro/cu2d-rtm/ ?
[21:31] <sil2100> slangasek: yes :) But I guess that's what's deployed, so a bzr pull there might be enough
[21:32] <slangasek> sil2100: yes, I was double checking that was what you wanted
[21:32] <slangasek> sil2100: done
[21:32] <sil2100> Thanks \o/
[21:32] <robru> sil2100, i hope you're only breaking rtm and not utopic because i'm still waiting for silo 7 to publish before kicking an image build
[21:34] <slangasek> I hope no one's breaking anything, but instead continuing to be rockstars doing solid engineering work ;)
[21:34] <sil2100> robru, slangasek: that's my hope as well!
[21:35] <robru> ;-)
[21:42] <Saviq> sil2100, need to ack packaging?
[21:42] <sil2100> Saviq: no no, it's ACKed, I'm just finishing something else
[21:42] <sil2100> Since I need to be around when I press the button to see the destruction that's happening
[21:42] <Saviq> sil2100, we should probably EOD ya know? ;)
[21:42] <sil2100> Saviq: ;(
[21:43] <sil2100> ;)
[21:43] <sil2100> Ok, pressing!
[21:45] <sil2100> So, the rsync file looks ok, but let's see if the copy2distro I made is working
[21:45] <sil2100> (since removing workarounds has high risk of breaking)
[21:45] <sil2100> robru: so, in case
[21:47] <sil2100> robru: let's say that because of some really unbelievable typo or something suddenly you notice that packages are not getting uploaded to the archive when you press 'publish', please ask someone with access to snakefruit (archive admins) to branch lp:cupstream2distro to the cu2d directory there
[21:47] <Saviq> sil2100, it's in proposed :)
[21:47] <sil2100> Saviq: like, in ubuntu-rtm proposed?!
[21:47] <Saviq> sil2100, https://launchpad.net/ubuntu-rtm/+source/unity8
[21:47] <sil2100> No wai
[21:47] <robru> sil2100, ok, thanks for the heads up
[21:47] <sil2100> NO WAI
[21:47] <sil2100> Does... does it mean we can go... sleep?!
[21:48] <Saviq> sil2100, no we can't, migration checker doesn't look at rtm silos :D
[21:48] <sil2100> Saviq: baah, I'll deal with that tomorrow ;p Along with some other 'visual' stuff!
[21:48] <sil2100> We can try pressing merge & clean tomorrow in the morning as well!
[21:48] <Saviq> sil2100, have a good one :)
[21:50] <sil2100> Saviq: same for you ;)
[21:50] <cjwatson> sil2100,robru: fwiw there's already a cupstream2distro.bak directory (or similar) with the right checkout, so they just need to be pivoted
[21:51] <cjwatson> I left that there last time
[21:51] <sil2100> cjwatson: ok :)
[21:51] <robru> sil2100, good night
[21:51] <sil2100> Right, I think when Stephane was doing the initial testing, he made a copy just in case
[21:51] <sil2100> (a wise move)
[21:51] <sil2100> Goodnight everyone!
[21:51] <cjwatson> not sure he did, but whatever, I know I did :)
[21:52] <sil2100> Oh ;)
[21:52] <sil2100> cjwatson: have a nice holiday!
[21:52] <cjwatson> thanks :)
[22:36] <ralsina> robru: is there anything I should do about silo 2?
[22:36] <ralsina> it's a new package, I tested it and it works, so not sure how things go from here :-)
[22:38] <robru> ralsina, yeah, I'm just waiting for silo 7 to land so I can kick an image before I land anything else
[22:38] <robru> ralsina, didn't realize it was new though, in that case I can publish and it'll go for NEW review
[22:38] <robru> (which takes longer)
[22:39] <ralsina> robru: cool then, I'll just EOD and see what happened in the morning :-)
[22:39] <robru> ralsina, did any core devs look at the packaging yet?
[22:39] <ralsina> don't think so, unless kalikiana is one
[22:39] <ralsina> and sergiusens checked it, too
[22:39] <sergiusens> i'm not a cre dev though
[22:40] <sergiusens> not even core
[22:41] <robru> eh, it looks reasonable to me, I'll submit for NEW
[22:41] <ralsina> cool, thx
[22:42] <robru> ralsina, good night!
[23:55] <robru> infinity, can you investigate why mir hasn't migrated yet? I have no idea what's going on, and don't understand update_output.txt