[02:09] <imgbot> [03:09] <imgbot> [03:43] <Mirv> morning
[03:54] <imgbot> [03:54] <imgbot> [04:14] <imgbot> [04:14] <imgbot> [06:42] <Mirv> it's actually a good thing there's a limit to IRC line lengths... otherwise that ^ would have filled half of the screen
[07:18] <Saviq> morning all
[07:18] <Saviq> ogra_, we're looking at a potential delta image corruption of some sort - bug #1380133
[07:18] <Saviq> as per Victor's comment https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1380133/comments/4
[07:19] <Saviq> if he flashes a full image, all is fine, but if he OTAs from 96 things get wonky in a few places
[07:19] <Saviq> another victim: bug #1380120
[07:22] <ogra_> Saviq, with all the iage probs we had since friday that could well be
[07:22] <ogra_> *image
[07:22] <ogra_> Saviq, but that should be gone after OTA, no matter what
[07:23] <ogra_> 99 and upwards should be fine again
[07:23] <Saviq> ogra_, well, that's the thing, if you upgrade via deltas from 96 to 100
[07:23] <Saviq> ogra_, broken
[07:23] <Saviq> ogra_, if you flash full 100, it's fine
[07:24] <ogra_> weird, how could that be
[07:24] <Saviq> corrupted delta or corrupted delta application
[07:25] <Saviq> or another thing I was thinking deltas affect QML precomp somehow that full image doesn't, but that's a stretch
[07:25] <ogra_> well, that would be custom tarball application
[07:25] <Saviq> in any case, this is reproducible 100%, so we really need to get to the bottom of it
[07:25] <ogra_> well, ricmm wanted to add something that wiped the cache on upgrades
[07:25] <ogra_> *wipes
[07:26] <ogra_> Saviq, riht, best to talk to stgraber
[07:26] <ogra_> *right even
[07:26] <Saviq> yeah, but the weirdest thing is that the area that gets broken isn't touched between 96 and 100...
[07:26] <Saviq> so yeah... *weird*
[07:26] <ogra_> Saviq, we had a completeöy broken image build system for thu and fri
[07:27] <ogra_> i spent most of my weekend to fix a Mir dependency breakage after the image builder was not running out of space anymore
[07:27] <ogra_> i would think the thu/fri thing caused breakage
[07:28] <ogra_> but stephane fixed it ... perhaps he needs to re-generate some older deltas
[07:28] <ogra_> in any case it should be gone latest with the next custom tarball
[07:33] <Mirv> I wonder if automatic "compare delta patched images to full images" could be implemented and added as a gatekeeper to making images available?
[07:35] <Mirv> is it stgraber that should be pinged on adding such a to-do item?
[07:36] <ogra_> yes
[07:36] <Mirv> ok, pinging
[07:37] <ogra_> real life ping ? :)
[07:37] <ogra_> (are you at linuxcon ?)
[07:38] <Mirv> the old-fashioned email ping :)
[07:38] <ogra_> ah
[07:38] <Mirv> I wonder how feasible would be another gatekeeper job that would boot up the device, unlock screen, take screenshot and validate the screenshot, before making an image downloadable
[07:39] <Mirv> that would have prevented the mir thing from getting published for users
[07:39] <ogra_> proper failing when the wrong alternative is in place would have too :)
[07:40] <ogra_> (and that would have sent mail to the whole cdimage team)
[07:40] <Mirv> yeah, but that kind of automation would prevent a range of fails to boot issues, so it'd be nice to have in a lab or such
[07:41] <ogra_> sure ... just that you will need more devices for this
[07:42] <Mirv> and failing devices would prevent image from publishing
[07:42]  * ogra_ thinks we need at least 50 devices per arch in the future ... 
[07:43] <Saviq> ogra_, right, confirmed, removing the cached files fixes the issue
[07:43] <ogra_> Saviq, phew, so it isnt an image thing ... good
[07:43] <Saviq> phew indeed
[07:44] <ogra_> Saviq, i thinnk ricmm has something ready (or will have it ready today), that should only be 1-3 lines in the upgrader
[07:44] <ogra_> hmm
[07:44] <ogra_> even though
[07:44] <ogra_> that should probably not actually live in the upgrader ... we shouldnt touch user dirs from that
[07:45] <ogra_> (but instead use a upgrader boot hook )
[07:45] <ogra_> which actually makes landing a fix way easier
[07:49] <sil2100> How?
[07:49] <sil2100> Hi!
[07:49] <sil2100> o/
[07:53] <ogra_> sil2100, by not having to push it through the android package
[07:54] <Mirv> hi sil2100 o/
[07:58] <ogra_> Saviq, http://paste.ubuntu.com/8550912/
[07:58] <Saviq> ogra_, mhm
[07:59] <ogra_> somethin like that ... we sadly dont have such a mechanism for the session
[08:02] <Saviq> sil2100, hey, any idea why the log entries started coming in some wrong order https://ci-train.ubuntu.com/job/ubuntu-landing-013-1-build/44/console
[08:02] <Saviq> it's difficult to grok which MP conflicted :/
[08:03] <sil2100> Saviq: hmmm, it might be related to the refactoring Robert made some time ago, as he was changing our scripts to python modules - not sure what from that could cause this but we indeed noticed that this started happening recently
[08:03] <sil2100> I'll look into it
[08:04] <Saviq> thanks
[08:06] <ogra_> hmm, reminders kills the image tests since image 96
[08:08] <sil2100> ogra_: kills?
[08:08] <ogra_> it seems to die on trying to set up the account
[08:08] <ogra_> and then the device it runs on seems to hang
[08:09] <dbarth> hi good morning
[08:09] <dbarth> trainguards: silo rtm-002 can be published now; all branches approved
[08:22] <dbarth> Mirv: hi; are you one of those who can ack the packaging changes for silo 2? ^^
[08:24] <Mirv> dbarth: yep
[08:25] <popey> sil2100: I'm afk for an hour, need to take wife to doctors, ping me if you need anything core apps related as a result of the landing call..
[08:26]  * Mirv needs to skip the meeting :(
[08:40] <alan_g> cihelp - since end last week we've been seeing a lot "virtual memory exhausted: Cannot allocate memory" failures on https://jenkins.qa.ubuntu.com/job/mir-utopic-amd64-ci/ - AFAICS this isn't due code changes, has something changed in the server setup?
[08:49] <bzoltan> brendand:  hello, how is the UITK QA process going?
[08:50] <brendand> bzoltan, your silo is quite far back in the queue (we had 7 new silos come in at the weekend)
[08:51] <brendand> bzoltan, also there are new rules about landings - they can only fix rtm critical bugs now
[08:51] <brendand> bzoltan, silo 13 doesn't conform to that criteria right now
[08:52] <bzoltan> brendand: how do you estimate, when the UITK silo will be on your desk?
[08:53] <brendand> bzoltan, right now i'm really not sure because we have to triage each silo first
[08:55] <bzoltan> brendand: This silo has two Critical-RTM bug fixes
[08:56] <brendand> bzoltan, that's not the point - the rule now is it must contain *only* those fixes
[08:57] <bzoltan> brendand: when this new rule came in effect?
[08:57] <brendand> bzoltan, retroactively from friday
[08:57] <bzoltan> brendand:  does not sound fair with my case
[08:59] <seb128> sil2100, hey, can you get content-hub from utopic to rtm?
[08:59] <bzoltan> brendand:  where was this rule announced?
[09:04] <brendand> bzoltan, i was told by email
[09:08] <bzoltan> brendand:  Was it announced on any mailing lists? Who the mail came from?
[09:09] <brendand> bzoltan, i think it was olli or asac
[09:11] <bzoltan> brendand:  was it announced to the landers? I mean did I miss a mail?
[09:11] <brendand> bzoltan, that's what i was told
[09:11] <bzoltan> brendand:  but was I told that?
[09:12] <brendand> bzoltan, i was told that you were told (and all landers)
[09:13] <bzoltan> brendand: I do not find the mail about it. Could you help me? What was the subject, when it went  out to what ML?
[09:13] <Saviq> ogra_, the fix for qtmir packaging fiasco last week, that never got to qtmir trunk did it?
[09:14] <brendand> bzoltan, unfortunately i didn't receive the same mail but was told by another one
[09:14] <bzoltan> brendand:  I just wish to understand what the rules are
[09:15] <davmor2> Morning all
[09:15] <brendand> bzoltan, you definitely didn't get a mail from asac?
[09:15] <brendand> sil2100, did asac give you some exact rules about landings?
[09:22] <sil2100> seb128: sure!
[09:22] <ogra_> Saviq, there was only a seed change and two changes in the build system
[09:22] <sil2100> seb128: does it fix any rtm14 critical bugs?
[09:23] <Saviq> ogra_, ah ok so the version in https://launchpad.net/ubuntu-rtm/+source/qtmir
[09:23] <bzoltan> brendand:  I do not find it
[09:23] <sil2100> brendand: I got orders from him to gate only landings that target critical and rtm14 bugs
[09:23] <Saviq> ogra_, is the "unfortunate" landing of qtmir and things will get rectified by the next landing?
[09:23]  * Mirv back
[09:23] <seb128> sil2100, sort of I guess
[09:24] <Mirv> Saviq: the whole Mir 0.8.0 landing was "canceled" from CI Train point of view
[09:24] <seb128> sil2100, it makes content-hub translations be used, which I'm sure we want
[09:24] <seb128> sil2100, there isn't a bug open/tagged about the issue though, I just hit it and fixed it
[09:24] <Saviq> Mirv, yeah, but the qtmir rtm package seems to come from there, no?
[09:24] <Mirv> Saviq: yes, that's why it was "canceled", while it actually landed to both ubuntu and rtm
[09:24] <seb128> sil2100, non translatable UI in an important component like that is likely rc if you ask people who tag bugs
[09:24] <Mirv> sil2100: were there any open points left from the meeting?
[09:25] <ogra_> Saviq, that landing was missing a seed change that would had had to go alongside ... additionally these two packages were hardcoded in livecd-rootfs ... seed and an update for the hardcoding was dont by cjwatson ... i additionally added a forcing of the right alternative
[09:25] <sil2100> Mirv: let me get to you in a moment
[09:25] <sil2100> seb128: ok, I think this might be a candidate for ubuntu-rtm then
[09:25] <seb128> sil2100, great ;-)
[09:25] <ogra_> Saviq, all changes for this were dont outside of qtmir
[09:25] <Mirv> Saviq: actually, isn't https://code.launchpad.net/~mir-team/qtmir/trunk now up-to-date?
[09:26] <Saviq> Mirv, yeah, it is, landed Friday
[09:26] <Saviq> Mirv, but rtm isn't
[09:26] <Mirv> when I looked on Saturday, I did see some branches didn't seemingly match what got published (and the spreadsheet indicated 0.8.0 was reverted and then there's now a "retry" landing)
[09:26] <Saviq> Mirv, but as you can see there's no 1007 release
[09:26] <Saviq> Mirv, so I'm just after reconciling this
[09:26] <Saviq> but it will happen with the Mir 0.8 silo into rtm
[09:26] <Mirv> Saviq: ...
[09:26] <Mirv> Saviq: you're correct
[09:27] <Saviq> as rtm currently has 1007 for qtmir and 1006 for qtmir-gles
[09:27] <Saviq> no
[09:27] <Saviq> 1007 for qtmir-gles, too
[09:27] <ogra_> https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/000638.html
[09:27] <Saviq> just there's no such release in lp:qtmir is all
[09:27] <Mirv> Saviq: ah, right, so 1010 is the retry and that landed in utopic, and is waiting for QA sign-off
[09:27] <Saviq> Mirv, yup
[09:27] <bzoltan> brendand:  one changelog entry was not correct and I checkthe bugs this releases fixes -> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/landing-1010/+merge/237913
[09:28] <Mirv> Saviq: since this whole complexity came from that 1007 both landed and was canceled, I believe 1007 will not be merged to the packaging branch
[09:28] <Saviq> Mirv, yeah, that's fine
[09:28] <Saviq> Mirv, will it get through though, didn't we lock down rtm already?
[09:28] <ogra_> not for critical fixes
[09:29] <Saviq> yeah, well, what is critical about Mir 0.8? :)
[09:29] <cjwatson> Mirv: one landing was cancelled but then it was relanded ... right, I think you got there
[09:29] <Saviq> apart from the fact it's already there in rtm :)
[09:29] <Mirv> Saviq: what's the delta from 1007 to 1010, does it fix any critical fixes? that I failed to notice, since the image blowing up was not something that was fixed 1007 -> 1010, so there must have been soething else that triggered the original "let's cancel 1007, and retry"
[09:29] <ogra_> it critically ate a few peoples weekends :P
[09:29] <cjwatson> Mirv: the relanding on utopic had one extra branch for arm64; I advised not to bother with that for ubuntu-rtm (it could just go in a subsequent landing)
[09:29] <brendand> bzoltan, for example https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1378261 is included but not tagged with RTM
[09:30] <Mirv> cjwatson: ah, now it all starts to make sense!
[09:30] <cjwatson> Mirv: the cancelling was due to arm64 build failures and a series of miscommunications
[09:30] <Saviq> Mirv, since the silo *did* land
[09:30] <cjwatson> Mirv: it had nothing to do with the image failures
[09:30] <Saviq> Mirv, I don't think there's any delta
[09:30] <Mirv> Saviq: so if only Mir 0.8.0 change from 1007 to 1010 is that arm64 fix ^, there's no real need to get that landed
[09:30] <Saviq> yeah what I thought
[09:32] <Mirv> cjwatson: yes, it didn't have, and it's nice to know it was something as small as that arm64 issue
[09:33] <Mirv> I added a note to the landing line, it won't need to go in and consume QA resources
[09:33] <bzoltan> brendand:  that is a bit size fix of a very ugly UI bug... the header text and button were possible to overlap
[09:34] <Mirv> Saviq: it even seems just a rebuild http://pastebin.ubuntu.com/8551359/
[09:35] <Mirv> for example qtmir, mir probably has some small change
[09:35] <ogra_> Mirv, Saviq, cjwatson well, what if we need a quick fix of qtmir, wont the unmerged bit get in our way ?
[09:35] <Saviq> ogra_, we do, I'm preparing a cherry-pick silo
[09:35] <ogra_> k
[09:35] <Saviq> ogra_, but I don't think it will get in our way, no
[09:36] <Mirv> ogra_: very slightly, just a sync of changelog might be needed
[09:36] <Mirv> Saviq: it's possible some trickery be needed, or simply checking manually and forcing the CI train ignore the diffference between what's in rtm and what''s in changelog
[09:37] <ogra_> good then ... just want to make sure that we dont get bitten by it with that possible hotfix on wed. evening :)
[09:37] <Saviq> Mirv, mhm
[09:38] <Saviq> Mirv, while I have you here then, can I have a silo for line 86 please
[09:38] <Saviq> Mirv, there's a conflicting silo 13, but I should be able to land before ted wakes up
[09:39] <davmor2> ogra_: by the way thanks for fixing the mess Saturday you were the only person I got think of :)
[09:39] <ogra_> davmor2, heh, welcome
[09:40] <sil2100> brendand: so, regarding the landings principles that we have now regarding critical bugs, there was a follow-up e-mail from Olli about it and he mentioned that bugs that are not from the rtm14 milestone list need to be reviewed by our LT and by the product team if they can land
[09:40] <brendand> sil2100, yep but no-one from product is here yet
[09:42] <Mirv> Saviq: sure
[09:45] <bzoltan> sil2100: one practical question. Who are licensed to mark bugs with rtm14 tag? because I keep seeing from all different people marking my bugs with rtm14
[09:45] <sil2100> bzoltan: I do not know the specifics regarding that, but it should probably be someone from the product team
[09:46] <sil2100> Or at least after consultation with the product team
[09:46] <t1mp> sil2100: who is the product team? I see a lot of people tagging bugs with rtm14 for uitk
[09:47] <ogra_> t1mp, bzoltan, the tagging only counts if the bug is also critical
[09:47] <bzoltan> sil2100: yes, I see. I am in trouble with the ongoing UITK landing.. it does have super important and critical fixes .. including the organizer-eds and others.
[09:48] <cjwatson> ogra_: the unmerged bit was in mir, not qtmir
[09:48] <bzoltan> sil2100: ogra_: brendand: so what to do to see the silo13 landing?
[09:48] <sil2100> t1mp, bzoltan: I usually poke asac or Victor whenever I have questions
[09:49] <ogra_> (i mean .. the tagging surely counts for something ... but only if both conditions are true the bug is for pre-thu.)
[09:49] <sil2100> But we might need to wait a bit for some more people to log in
[09:49] <cjwatson> ogra_: and if so I would have thought that really we should just include the unmerged bit; it's clearly harmless
[09:49] <sil2100> For now, we're stalled
[09:49] <ogra_> cjwatson, ah
[09:49] <bzoltan> ogra_: sil2100: this new rule makes sense and sounds logical... only if I would have known about it before I started this landing.
[09:50] <ogra_> bzoltan, that rule exists since over a month
[09:51] <ogra_> it was just not enforced very consequently i think
[09:51] <sil2100> bzoltan: so, I was informed that most EM landers have been informed, but it seems the 'most' part was a bit overrated
[09:52] <sil2100> bzoltan: I got the info about this policy on Friday evening, so I didn't have time to send out that to everyone
[09:52] <bzoltan> ogra_: sil2100: I have been landing dozens of bitesize fixes in the UITK ...
[09:52] <sil2100> bzoltan: we might get those assessed and still accepted, so let's see what the product guys say
[09:53] <ogra_> yeah
[09:53] <bzoltan> sil2100: ogra_: since we are landing thru a staging branch it is not trivial to change
[09:53] <sil2100> I'll clear out some things with people and send an official announce
[09:54] <bzoltan> sil2100: ogra_: but obviously we do focus on RTM and critical bugs ... the actual landing has only important fixes... but hack, we do fix oneliner small bugs if they make the UITK more pretty and better.
[09:54] <bzoltan> sil2100: ogra_: but not from now, as I do understand the rules...
[09:54] <ogra_> bzoltan, you dont need to convince either of us, we didnt make the rule :)
[09:54] <sil2100> bzoltan: ok, btw. there has been an e-mail from olli to the ue-leads
[09:54] <sil2100> On Friday
[09:55] <sil2100> At least about the basic rules of that
[09:55] <Laney> Why to a private list?
[09:55] <ogra_> bzoltan, i'm all with you for one liners, i would do these myself
[09:55]  * ogra_ hides that last sentence from brendand 
[09:56] <bzoltan> sil2100:  local time 9:30 ... :) I hardly reached those mails yet
[09:57] <bzoltan> ogra_: sil2100: i am not against the rule... I have massive corporate history :) I am very good at respecting rules. My problem is that this rule came after I made the landing MR, run a 10h tests, logged all the results and requested a QA signoff
[09:58] <sil2100> hah, maybe this would be an additional argument for letting this through ;)
[09:59]  * ogra_ would definitely let it through if it gets QA signoff ... but i guess QA will check the rules before approving
[10:01] <pstolowski> Mirv, hey, re your comment in line #55, do I need to reconfigure or rebuild the silo after the other stuff you mentioned in the comment landed?
[10:03] <Mirv> pstolowski: let's see what I've commented :)
[10:04] <Mirv> pstolowski: since it landed first to utopic (both the previous landing and that one), the trunk is sufficiently up-to-date so the only thing that matters is that the first silo just gets QA signoffed published first
[10:08] <Mirv> pstolowski: aand the previous landing landed at https://lists.canonical.com/archives/rtm-14.09-changes/2014-October/000678.html so no worries. atdded a comment.
[10:08] <abeato> sil2100, hey, could I get a silo for line 85?
[10:08] <sil2100> abeato: let me take a look
[10:08] <abeato> ok, thanks
[10:09] <sil2100> abeato: is there a bug for that?
[10:09] <pstolowski> Mirv, thanks!
[10:09] <abeato> sil2100, https://bugs.launchpad.net/barajas/+bug/1356330
[10:10] <sil2100> abeato: excellent, thanks!
[10:11] <Mirv> mzanetti: from my understanding, with my new qtbase PPA build bug #1357321 would perhaps be really ready for testing
[10:12] <mzanetti> Mirv: ah right. yeah, it did improve the situation, there were some hickups still. I've told lorn about it.
[10:13] <Mirv> mzanetti: so that new build is from today and has the updated patch set from Lorn (unless you git updated qtbase yourself from his patched version). I do not know for sure if that new patchset fixes all those issues you reported or not.
[10:26] <Laney> Can someone share the configuration for uploading to RTM PPAs please?
[10:26] <Laney> Also what should Distribution: be?
[10:27] <sil2100> Laney: http://paste.ubuntu.com/8551599/
[10:29] <Laney> thought so
[10:30] <ogra_> erm
[10:30] <Laney> that's ubuntu-rtm itself but I infer the pattern
[10:30] <ogra_> you dont need *any* change
[10:30] <ogra_> just make sure to use ubuntu-rtm/ in the ppa url
[10:31] <ogra_> at least with the recent dput
[10:31] <brendand> pstolowski, need to talk about silo 14
[10:31] <ogra_> (which should be in trusty and utopic)
[10:32]  * Mirv uses http://pastebin.ubuntu.com/8551609/ for dput
[10:32] <Laney> It seems that you should be able to use ppa:ubuntu-rtm/ci-train-ppa-service/landing-foo
[10:32] <Laney> yes?
[10:32]  * Laney is using dput-ng
[10:33] <ogra_> Laney, wrong order
[10:33] <Laney> the other way around actually
[10:33] <Laney> it's user/distribution/ppa
[10:33] <ogra_> $user/$distro/$ppa
[10:33] <ogra_> *snap*
[10:33] <ogra_> :)
[10:33] <Laney> WCPGW
[10:33] <popey> Ship it!
[10:33] <ogra_> DONE!
[10:33] <pstolowski> brendand, hey, what's up?
[10:33] <Mirv> thanks everyone!
[10:34] <brendand> pstolowski, so there are some new rules now about landings only containing rtm+critical bug fixes
[10:34] <Mirv> the ship has sailed
[10:34] <brendand> pstolowski, we need to retroactively apply that criteria to silo 14
[10:34] <Mirv> a silo ship
[10:35] <ogra_> :)
[10:35] <brendand> pstolowski, the bugs for unity-scopes-api aren't tagged and i don't understand them enough to know if they are required to fix such bugs: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-014/+packages
[10:35] <brendand> pstolowski, and unity-scopes-shell has no bugs listed
[10:36] <pstolowski> brendand, 1 sec, i asked marcus to join
[10:38] <pstolowski> marcustomlinson, the backlog - http://pastebin.ubuntu.com/8551633/
[10:40] <pstolowski> brendand, when it comes to unity-scopes-shell - the change plays important role in fixing oauth issues (which are part of unity-scopes-api), but you're right, we forgot to link it to the bug
[10:41] <ogra_> popey, hmm, didnt you add an MP for the remider accounts deb removal ? i dont see anything on https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.utopic/+activereviews
[10:44] <Laney> ogra_: what's Distribution (in the changelog and _source.changes file) meant to be?
[10:45] <brendand> pstolowski, what about the untagged bugs?
[10:46] <brendand> pstolowski, actually sorry there is another problem - https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1377147
[10:46] <brendand> pstolowski, that is not wanted to land. https://launchpad.net/bugs/1350093 is though
[10:52] <popey> ogra_: gah, yes I did
[10:52] <pete-woods> cjwatson: hi, just wanted to check if merge https://code.launchpad.net/~unity-api-team/click/add-cmake-extras/+merge/235768 was still needed? or if you include the sdk-libs metapackage with click schroot now?
[10:53] <pstolowski> brendand, i'm a little confused ;), so, to summarize: https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1377147 is not wanted because it's high, not critical? and unity-scopes-shell changelog doesn't link to any bug?
[10:54] <popey> ogra_: done
[10:54] <Laney> abeato: wait, that silo is not rtm
[10:54] <brendand> pstolowski, yes that's pretty much it
[10:55] <brendand> pstolowski, also https://launchpad.net/bugs/1374206 is a bit unclear about the purpose
[10:55] <brendand> pstolowski, is it independent fix or needed for something else?
[10:57] <abeato> Laney, yes, do you want to land this only for RTM? the patch makes sense for utopic too
[10:57] <Laney> it already is
[10:57] <abeato> it already landed in utopic?
[10:57] <Laney> yes
[10:57] <ogra_> Laney, 14.09
[10:57] <Laney> I told you that last week
[10:58] <abeato> Laney, ok, I see, sil2100 we only need an RTM silo for gst-plugins
[10:58] <Laney> I can fix that
[10:58] <sil2100> ACK
[10:58]  * Laney super cow powers
[10:58] <sil2100> Ok, let me assign an RTM silo  then
[10:59] <pstolowski> brendand, independent, i think it has to do with saving battery (no need to poll infinitely)
[11:00] <pstolowski> brendand, i think all these bugs should have been critical. what do i need to do? get their priority raised?
[11:01] <Mirv> tvoss: I'm putting your location-service rtm landing to QA team's signoff list. does the sync only include fixes for critical bugs?
[11:02] <tvoss> Mirv, yup
[11:02] <tvoss> Mirv, let me find links
[11:03] <Mirv> tvoss: thanks!
[11:04] <Mirv> tvoss: do you know what' the status of line 78 "HERE wk41 update" custom tarball update. it's marked as "landed" for utopic, but empty for rtm?
[11:04] <tvoss> lool, ^
[11:04] <brendand> tvoss, please make sure that's clear and reflected in the changelog
[11:05] <brendand> tvoss, Mirv - Critical + rtm14
[11:06] <brendand> Wellark, silo 3 should be seen to today
[11:06] <Mirv> tvoss: brendand: to me it'd look like the changelog does not explicitly list the bug numbers https://launchpadlibrarian.net/187007357/location-service_2.1%2B14.10.20141008-0ubuntu1_2.1%2B14.10.20141010-0ubuntu1.diff.gz
[11:06] <Wellark> brendand: apn editor?
[11:06] <Mirv> (current rtm version is that 1008)
[11:06] <Wellark> what happened to that?
[11:07] <brendand> Wellark, indicator-network actually
[11:07] <brendand> Wellark, has a fix for a top crasher
[11:07] <tvoss> Mirv, I linked the respective branch to both bugs. Is that somehow queryable for you?
[11:07] <tvoss> brendand, ^
[11:07] <brendand> tvoss, if the bugs aren't in the changelog they should be mentioned in the description of the silo
[11:08] <Wellark> brendand: oh, ok.
[11:08] <Mirv> tvoss: brendand: I added the bug to the description of silo now. "Prefer /system/etc/gps.conf over /etc/gps.conf." change isn't accounted for yet, though
[11:08] <Wellark> trainguards: what happened to the apn editor?
[11:08] <Wellark> the utopic landing is on line 6 of the landing sheet
[11:09] <Wellark> but the RTM landing is moved to the archive
[11:09] <brendand> oooh, did it land?
[11:09] <Mirv> Wellark: seems rtm landed, utopic not tested by upstream?
[11:10] <Wellark> Mirv: I'm just trying to understand how the RTM was landed but not utopic
[11:11] <Wellark> the rtm is in archive tab on line 1796
[11:12] <Mirv> Wellark: upstream tested and gave it to QA signoff before testing it on utopic, ie went rtm first. they should have tested the utopic by now though.
[11:13] <Wellark> Mirv: ok. who should I bug to get the latest status of the signoff?
[11:13] <Mirv> Wellark: you mean, the status of the signoff for rtm silo? for utopic silo, no upstream signoff is needed, but upstream needs to test it.
[11:14] <Mirv> brendand: tvoss: ok, rtm-005 "sync over latest location service fixes to RTM" is clear now, and explained in the spreadsheet. I'll add a comment to the trello too.
[11:14] <tvoss> Mirv, thank you
[11:15] <Wellark> Mirv: oh, riight.. it's missing "Testing Pass"...
[11:16] <brendand> Wellark, APN editor landed? where is it supposed to be (in the ui)?
[11:16] <Wellark> brendand: it's claimed to have landed for the rtm images
[11:17] <Wellark> brendand: system-settings -> Cellular -> Choose Carrier -> APN
[11:18] <brendand> Wellark, perhaps it isn't in an image yet
[11:18] <Wellark> brendand: https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-settings#Edit_APN
[11:19] <ogra_> brendand, doesnt look like anything landed in rtm https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.utopic/+activereviews
[11:19] <ogra_> err
[11:19] <ogra_> sorry
[11:19] <ogra_> https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/thread.html
[11:19] <ogra_> wrong paste
[11:19] <ogra_> (livecd-rootfs was the weekendish fix )
[11:20] <Wellark> ogra_: https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/000652.html
[11:20] <Mirv> tvoss: I kind of assume line 7 location-service trust-store dbus-cpp ubuntu-location-provider-here landing is obsolete now and you'll have separate new landings if any?
[11:21] <tvoss> Mirv, is that ubuntu or rtm?
[11:21] <Mirv> tvoss: rtm
[11:21] <tvoss> Mirv, don't see it
[11:21] <Wellark> erm.. what
[11:21] <Wellark> https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/000653.html
[11:21] <Mirv> tvoss: "Location Service and HERE updates", line 7, a sync from utopic
[11:21] <ogra_> Wellark, hmm, well, that would have been image 95 ...
[11:21] <Wellark> ogra_: see above
[11:21] <ogra_> Wellark, i dont see such an option on 101 here
[11:21] <tvoss> lool, ^?
[11:22] <Mirv> tvoss: the whole description http://pastebin.ubuntu.com/8551862/
[11:22] <Wellark> ogra_: it got reverted
[11:22] <ogra_> ah
[11:22] <tvoss> Mirv, should be superseded
[11:22] <Mirv> tvoss: ok
[11:23] <Wellark> but it's in the archive
[11:23] <Wellark> *arvhived tab
[11:23] <ogra_> Wellark, right, seems that slangasek didnt change the spreadsheet back to "not landed" or some such
[11:23] <Mirv> tvoss: I think these multiple location-service landings accumulating is because trainguard_s tend to add the rtm sync silo automatically, and you've instead landed only to utopic and then you selectively add new lines for the rtm syncs
[11:23] <Mirv> tvoss: thanks again!
[11:23] <ogra_> (if we even have such a thing)
[11:24] <Wellark> trainguards: please restore "apn editor" for rtm from Archived to Pending
[11:24] <Mirv> Wellark: ok, in a minute
[11:24] <Wellark> as per https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/000653.html
[11:25] <Wellark> Mirv: the utopic landing is on line 6
[11:25] <Mirv> jhodapp: I've added that I'll remove the line 9 "Use highest resolution for front camera" utopic landing if there is no status update. you might want to get it synced from rtm if they are now not in sync.
[11:25] <tvoss> Mirv, yup, cool
[11:25] <alan_g> cihelp - since end last week we've been seeing a lot "virtual memory exhausted: Cannot allocate memory" failures on https://jenkins.qa.ubuntu.com/job/mir-utopic-amd64-ci/ - AFAICS this isn't due code changes, has something changed in the server setup?
[11:25] <ogra_> Wellark, well, was whatever blocked QA fixed inbetween ?
[11:26] <ogra_> just re-landing the same thing wont help i guess
[11:26] <Wellark> ogra_: haven't had any reports that qa even was involved
[11:26] <Wellark> AFAIK they have not tested it yet
[11:26] <ogra_> Wellark, but you read the changelog of the revert ?
[11:26] <sil2100> Mirv: ok, hm, let me read the backlog, but is this situation resolved?
[11:26] <ogra_>   * Revert to 0.3+14.10.20141007-0ubuntu1 as 0.3+14.10.20141007.2-
[11:26] <ogra_>     0ubuntu1 did not pass QA
[11:27] <Mirv> sil2100: depending on which of the situations you refer to :)
[11:27] <Wellark> ogra_: yes. it was landed without QA testing marked as "passed"
[11:27] <sil2100> Right, it was that landing that probably got published by accident by one of the trainguards
[11:27] <Wellark> hence the revert
[11:29] <ogra_> Wellark, ah, the changelog isnt clear on that "did not pass" doesnt sound like "was not tested at all"
[11:29] <Mirv> Wellark: ok it's back now and has a silo, but rtm-006 should probably go in first, then utopic APN silo should be rebuilt and then synced to rtm silo.
[11:29] <Mirv> ...which I wrote to the comment field
[11:29] <Wellark> Mirv: kenvandine promised to take care of the landing
[11:29] <Wellark> I will relay him the information when he gets online
[11:30] <Mirv> Wellark: ok, thanks!
[11:30] <Wellark> or at least tell him to /ping Mirv ;)
[11:30] <sil2100> Wellark: Ken probably won't be online today
[11:31] <Wellark> ...
[11:31] <ogra_> columbus day in the US
[11:33] <Mirv> damn columbus
[11:33] <Wellark> Mirv: you are aware that you now asked for not to have qa signoff for the rtm landing?
[11:33] <Mirv> in that case it'd flow naturally that QA will test rtm-006 first.
[11:33] <ogra_> yeah, crazy to celebrate that someone got lost
[11:33] <Wellark> Mirv: N/A (Mirv)
[11:33] <Mirv> Wellark: how so? the rtm is the topmost one, utopic the one I marked no QA signoff
[11:34] <Wellark> Mirv: oh sorry
[11:34] <Wellark> didn't realize you changed the ordering :)
[11:35] <lool> tvoss: sorry I dont get the context
[11:35] <tvoss> lool, cancel the ping :)
[11:35] <tvoss> lool, sorry for the confusion
[11:35] <lool> tvoss: np
[11:35] <sil2100> Mirv, Wellark: all under control I see?
[11:35] <lool> tvoss: just as a reminder, the updated HERE release is meant to land today in rtm (already in utopic)
[11:35] <tvoss> lool, ack
[11:35] <tvoss> Mirv, ^
[11:35] <Mirv> tvoss: lool: I think the custom tarball rtm landing line was still a question mark?
[11:36] <Wellark> sil2100: as long as I find someone to do the testing :)
[11:36] <sil2100> Wellark: ;)
[11:36] <Mirv> tvoss: lool: ...which lool just answered
[11:36] <Mirv> lool: so do I assign a silo for it?
[11:36] <lool> Mirv: no, no silo for custom tarball
[11:36] <lool> Mirv: I think that's noted on the line as a reminder
[11:36] <Mirv> lool: right, so I thought, I just wondered why the utopic landing seemed to have had one
[11:36] <lool> Mirv: cwayne is landing it; he merged the changes over the WE
[11:36] <lool> oh crap, forgot it's a US holiday
[11:36]  * sil2100 jumps out to lunch then
[11:36] <sil2100> lool: yeah...
[11:36] <lool> Mirv: it might only be tomorrow then
[11:36] <lool> too bad  :-(
[11:37] <Mirv> :(
[11:37] <Wellark> jgdx: any idea where ken left with the system-settings landings on Friday?
[11:37] <ogra_> lool, i think he planned to jump in shortly today for exactly that
[11:37] <ogra_> someone said so in the landing meeting
[11:37] <sil2100> Be back soon - mup me if anything urgent appears, but I should be online in like 45 minutes
[11:37] <ogra_> (i think it was sil2100 )
[11:38] <lool> ogra_: oh nice
[11:38] <lool> well, crossing fingers
[11:38] <ogra_> (and i think davmor2 is already testing)
[11:38] <sil2100> ogra_: I think john-mcaleely mentioned that the tarball is already pushed somewhere
[11:38] <lool> we'll have at least another custom tarball update later this week anyway (espoo fixes)
[11:38] <ogra_> (see the private channel)
[11:38] <lool> sil2100: wasn't it device tarball?
[11:38] <ogra_> sil2100, right, to the testing channel for custom stuff
[11:38] <sil2100> lool: device tarball as well, but john-mcaleely mentioned something about the custom tarball too
[11:38] <lool> sil2100: device tarball: typically pushed through by john-mcaleely AIUI, custom tarball: typically pushed through by cwayne -- AIUI
[11:38] <lool> ok
[11:38] <sil2100> brb
[11:39] <sil2100> o/
[11:39]  * Mirv archived landed landings
[11:39] <jgdx> Wellark, no
[11:40] <cjwatson> pete-woods: it's still needed
[11:40] <cjwatson> (for now)
[11:41] <john-mcaleely> custom tarball will be in ubuntu-touch/ubuntu-rtm/14.09-proposed-customized, lool sil2100
[11:41] <Mirv> pete-woods: is there a critical rtm14 bug to be linked to https://code.launchpad.net/~jamesh/unity-scope-mediascanner/click-support/+merge/237731 ?
[11:41] <pete-woods> Mirv: probably not, no
[11:42] <pete-woods> it just introduces click packaging for those scopes
[11:42] <Mirv> pete-woods: by default only critical rtm14 bug fixes go in now
[11:42] <pete-woods> yeah, I learned that after entering it
[11:43] <Mirv> and it probably doesn't make sense to land other fixes to utopic either
[11:43] <pete-woods> okay
[11:43] <Mirv> yeah, I guess this'll get clarified a bit more broadly later today. just a bit more control on which bugs are tackled.
[11:43] <lool> john-mcaleely: cool; happy to help QA when it's at that stage of testing
[11:48] <john-mcaleely> lool, I think it is now?
[11:48] <john-mcaleely> (I'm speaking for cwayne - I may be wrong)
[11:49] <lool> john-mcaleely: he merged my stuff in, but I dont know whether the custom tarball is up; I'd thought cwayne would be off today
[11:49] <lool> (columbus day)
[11:49] <jamesh> Mirv: it is preparatory work for our part of bug 1367332
[11:50] <john-mcaleely> he is off, but I think he built it last night lool
[11:50] <john-mcaleely> so I would expect it to be the latest image in that channel
[11:50] <pete-woods> sorry for the noise
[11:50] <pete-woods> just adding a bug to it, and tagging as rtm
[11:50] <Mirv> jamesh: pete-woods: if that's so, then I'll mention the bug number in the landing, assign a silo and add rtm silo line too
[11:50] <Mirv> pete-woods: ah ok, thanks
[11:51] <jamesh> Mirv: it doesn't actually switch the package over to a click build, so is low risk: it just adds a build option to do so
[11:52] <lool> john-mcaleely: I do see an update from today, not sure how I can tell what's in it
[11:52] <john-mcaleely> lool, ok hrm
[11:53] <Mirv> jamesh: pete-woods: both utopic silo and a rtm sync silo fir it assigned
[11:53] <lool> john-mcaleely: I've put line 44 as "QA: Required" now
[11:53] <lool> in landing spreadsheet
[11:53] <lool> john-mcaleely: seems to be the only one with cwayne, so I'm assuming it's the only update he's landing in the custom tarball
[11:53] <lool> checking bzr now
[11:54] <lool> john-mcaleely: hmm there are other updates in bzr; I would expect this to be captured somewhere in a landing, but I have no prior experience to these landings
[11:54] <lool> I just know how to land the other custom tarballs or how to promote from the proposed channel to the regular one
[11:54] <john-mcaleely> lool, hrm. Yes, I'm unfamiliar with the details too
[11:55] <john-mcaleely> so, I know cwanye asked davmor2 / sil200 for a QA pass on a tarball today
[11:55] <john-mcaleely> so, I think the right thing is for that custom tarball to be QA'd, and then promoted if it passes
[11:56] <john-mcaleely> whether it has the changes you need, i can't say
[11:56] <john-mcaleely> lool, ^
[11:57] <lool> john-mcaleely: yeah; I'm hoping that's underway now that I've marked this as QA: Required
[11:57] <lool> will check trello in a few
[11:57] <lool> the queue is rather long though
[12:00] <pete-woods> Mirv: thanks for the silo! :)
[12:04] <john-mcaleely> ogra_, brendand davmor2 new device tarball up
[12:04] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141013-0e11263.tar.xz
[12:04] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141013-0e11263.changes
[12:05] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20141013-0e11263.ods
[12:05] <john-mcaleely> Please do your usual QA signoff when you have some time davmor2 brendand ? ^
[12:05] <ogra_> cool
[12:12] <cjwatson> FWIW I'd like to try to at least start landing the fix for bug 1367332 today
[12:13] <cjwatson> running a test livefs build in https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/ubuntu-touch/+build/8947 now
[12:14] <Wellark> seb128: do you have a handle the pending system-settings landings?
[12:14] <seb128> Wellark, which ones? but yeah, I'm going to do landings while Ken is not there
[12:15] <Wellark> seb128: my only concern is the APN editor right now
[12:15] <Wellark> and I have no idea how far ken got with the landings on Friday
[12:16] <seb128> that's pending approval from qa afaik
[12:16] <seb128> that's why it got reverted
[12:16] <Wellark> seb128: well, they are missing Testing Pass
[12:16] <Wellark> which afaik ken was supposed to ACK
[12:16] <Wellark> once he gets the silos rebuild after each landing
[12:17] <ricmm> cjwatson: hi, could I get a reconfigure on silo 17 (rtm) ?
[12:17] <ricmm> I've changed a branch target
[12:19] <Saviq> trainguards, I can has reconfigure in silo 10 please, added the -gles sync
[12:20] <Wellark> seb128: so, QA can't do their testing without Testing Pass first
[12:20] <Wellark> and I don't know if ken just forgot to set it
[12:21] <cjwatson> ricmm: done
[12:21] <ricmm> cjwatson: thanks
[12:22] <seb128> Wellark, jgdx might be able to help testing, can you ping him about it?
[12:24] <Wellark> seb128: jgdx might be able to test, but we need to know the ordering, as if anything else lands in system-settings before the apn editor silo, then we have to test again after a rebuild
[12:24] <seb128> right
[12:24] <seb128> well if you get it tested we can land that first
[12:24] <seb128> but if doesn't get tested we are not going to block forever on it either
[12:25] <Wellark> seb128: ok. do you know if the silo is up to date?
[12:25] <Wellark> jgdx: can you help testing?
[12:25] <Saviq> cjwatson, could I also get a reconf on silo 10 please, added qtmir-gles to sync
[12:25] <Wellark> seb128: or we can just rebuild it for just in case
[12:25] <cjwatson> Saviq: already working on it
[12:25] <Saviq> cjwatson, ah thanks
[12:26] <cjwatson> (not that I'm on duty today or anything, but people seem to have decided I'm an active trainguard :-) )
[12:26] <cjwatson> ricmm: FWIW for that kind of change you can just use the thing in column L of the spreadsheet yourself; doesn't require a landing team member
[12:26] <ricmm> oh didnt know, thanks
[12:26] <cjwatson> that kind> just adding/removing/changing branches, rather than changing the set of components involved
[12:26] <Saviq> cjwatson, you just *are* active, everyone else seems to be lunching ;)
[12:27] <cjwatson> should clearly stop having lunch at my desk
[12:27] <Wellark> seb128: so, should I trigger the rebuild?
[12:28] <seb128> Wellark, I don't know, should be easy to check, I guess it is if Ken worked on it on friday
[12:28] <Mirv> Saviq: did you get it already?
[12:29] <Saviq> Mirv, cjwatson's working on it, thanks
[12:29] <cjwatson> Saviq: done.  I overrode conflicts with silos 13 and 15 since those were essentially pre-existing
[12:29] <Mirv> right
[12:29] <Saviq> cjwatson, yup
[12:29] <Mirv> thanks
[12:29] <Wellark> seb128: easy for you perhaps :)
[12:29] <Wellark> satoris, jgdx: test plan for the APN editor: https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-settings#Edit_APN
[12:29] <seb128> Wellark, shrug
[12:30] <Wellark> satoris, jgdx: utopic silo https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-020
[12:31] <seb128> Wellark, https://ci-train.ubuntu.com/job/ubuntu-landing-020-1-build/64/console
[12:31] <seb128> Wellark, it needs a rebuild, it was based on 20141009 and we got an update on the 10
[12:31] <Wellark> jgdx, satoris: rtm silo https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-002
[12:31] <Wellark> jgdx, seb128, satoris: kicking rebuilds now
[12:32] <seb128> k
[12:32] <seb128> I'm away for a bit
[12:32] <seb128> going to check on that when I'm back
[12:34] <sergiusens> brendand: davmor2 hey, how is the trello boad processed, bottom up or top down?
[12:34] <davmor2> sergiusens: top to bottom
[12:34] <ogra_> left to right
[12:34] <ogra_> :)
[12:36] <davmor2> ogra_: no I think the correct response will now always be bunnies to dragons and wonder off :)
[12:37] <ogra_> haha
[12:38] <bzoltan> Mirv:  could you give me a silo to push the bugfix what victorp needs?
[12:44] <Mirv> bzoltan: ok. and rtm sync silo too?
[12:45] <bzoltan> Mirv:  only RTM, no gles
[12:45] <bzoltan> Mirv:  preferable not even trunk merge :)
[12:45] <Mirv> bzoltan: if I saw correctly you had marked that as utopic silo, but now google docs claims there are too many users...
[12:45] <Mirv> ok, loaded, right, rtm
[12:46] <Mirv> bzoltan: silo rtm-015
[12:56] <Wellark> satoris, jgdx: rtm silo ready for testing
[12:59] <fginther> alan_g, hello. Looks like an example of this here: https://jenkins.qa.ubuntu.com/job/mir-utopic-amd64-ci/140/console
[13:00] <fginther> alan_g, the pbuilder slaves have been moved to cloud instances a few weeks ago, but it sounds like this problem just started in the past few days?
[13:08] <fginther> alan_g, I'm going to reduce the number of parallel build jobs from for 4 to 2 and see what impact that has on the problem. Though it's a bit surprising to see an out of virtual memory error.
[13:09] <fginther> alan_g, if that doesn't help, I can add some swap as well.
[13:10] <fginther> alan_g, strange that if it was due to the new instances that it didn't show up sooner. Makes me wonder if a possible compiler or similar update might also be in play
[13:12] <cjwatson> cihelp: https://jenkins.qa.ubuntu.com/job/click-devel-utopic-amd64-ci/100/console is failing because "bzr bd" is run outside the chroot without the build-dependencies necessarily being installed.  This is probably difficult to fix properly, but would it be possible to ensure that dh-systemd is always installed in this context?
[13:12] <cjwatson> mvo: ^- cc since that's on your branch
[13:13] <fginther> cjwatson, yes, that can be done
[13:13] <mvo> thanks cjwatson
[13:14] <fginther> cjwatson, mvo, I'll rerun the MP after the update is pushed through
[13:14] <cjwatson> ta
[13:40] <satoris> Wellark: running apn test seems to work, but for some reason system-image-cli -i says the build number is 0.
[13:41] <ogra_> it only dos that if you didnt do a proper install
[13:42] <ogra_> (with a proper ubuntu-device-flash system-image sets the number ... )
[13:43] <alan_g> fginther: thanks - I'll keep a watch
[13:44] <satoris> It's flashed with the same script I have been using for weeks. And looking at documentation the command it uses is exactly right.
[13:45] <ogra_> script ?
[13:45] <satoris> A shell script containing the flashing command.
[13:45] <satoris> So I don't have to copypaste it every time. :)
[13:45] <ogra_> it should just be ubuntu-devcie-flash --channel ... --bootstrap (and the device being in bootloader)
[13:45] <ogra_> (and indeed the right channel you want to test against)
[13:46] <ogra_> optionally use --developer-mode and --password
[13:46] <satoris> That's exactly what I use except for the bootstrap bit. I don't think I have ever used that. If I need to wipe, I use --wipe.
[13:46] <ogra_> (to get adb if you need)
[13:46] <ogra_> ugh
[13:47] <ogra_> you want to always use --bootstrap ... else it might leave cruft around
[13:47] <ogra_> (--bootstrap formats the partitions and makes sure you get the new kernel and recovery images first=
[13:47] <ogra_> )
[13:47] <satoris> I have never had that happen to me, but let's try that just to be sure.
[13:47] <ogra_> --wipe only removes stuff from the home dir
[13:48] <satoris> It also marks root non-readable.
[13:48] <ogra_> yes, if you need it writable you need to use phablet-config --writable-image
[13:49] <ogra_> after flashing
[13:49]  * ogra_ wonders if anyone ever reads the official testing documentation we have 
[13:49]  * satoris has because he knew that.
[13:50] <ogra_> in any case an image number of 0 means that system-image doesnt consider your install a system-image at all ... which means most likely something went wrong with yor installation
[14:05] <brendand> ogra_, everyone should know about https://wiki.ubuntu.com/Touch/Testing
[14:05] <brendand> not saying they do, just that they should
[14:14] <ogra_> brendand, yeah
[14:26] <Mirv> ricmm: you'll need qtmir-gles branch too that targets lp:qtmir/gles and which has content like this https://code.launchpad.net/~mir-team/qtmir/gles-sync-mir/+merge/236423 but new date (matching your qtmir build) and landing-017 instead
[14:26] <ricmm> yea
[14:26] <ricmm> working on that one
[14:26] <Mirv> okay
[14:27] <dbarth> hi trainguards: i have verified, both the rtm and utopic version of silo rtm 009; let me know when it can get tested by QA for signoff
[14:28] <Mirv> dbarth: utopic published, we don't know the QA signoff schedule but the queue can be seen here https://trello.com/b/AE3swczu/silo-testing-for-questions-ping-eu-jibel-us-jfunk-nz-thomi-or-ubuntu-qa-on-ubuntu-ci-eng
[14:29] <dbarth> Mirv: yup, i know; it's just that it was somehow a tthe top of the pile, but i think i was doubled by other silos
[14:30] <dbarth> ;)
[14:31] <Mirv> Wellark: ^ previous u-s-s being published
[14:31] <ricmm> Mirv: could you reconf 017 then
[14:32] <ricmm> I've added the MR now
[14:32] <ricmm> nvm I'll use column L, forgot
[14:32] <Mirv> ricmm: done
[14:32] <Mirv> ..already
[14:32] <ricmm> nevermind it needs a trainguard
[14:32] <ricmm> failed my run as its a new component
[14:33] <ricmm> I cant add just reconf existing :(
[14:33] <ricmm> apparently
[14:33] <brendand> Mirv, does http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-001 need sign-off?
[14:37] <Mirv> brendand: my understanding was that no, it's not going in as there's nothing signficant in there compared to what's already in rtm
[14:38] <Mirv> brendand: of course, it's useful to now also ping camako about that
[14:38] <brendand> Mirv, 'not going in' as in doesn't need to be landed?
[14:38] <john-mcaleely> brendand, davmor2 any news on the device tarball?
[14:39] <Mirv> camako: ...that mir 0.8.0 "retry" RTM apparently wouldn't need to go in, as it only contains arm64 fix that went to utopic and otherwise rtm is equal already with the previous 0.8.0 landing?
[14:39] <Mirv> brendand: yes, that's what I think.
[14:40] <ricmm> https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-017-1-build/29/console
[14:40] <ricmm> what does this mean?
[14:41] <Mirv> brendand: camako: my understanding is that the "retry" 0.8.0 silo has only this change, making it irrelevant to land that silo: http://pastebin.ubuntu.com/8552961/
[14:42] <Mirv> ricmm: a delta between https://code.launchpad.net/~mir-team/qtmir/rtm-14.09 and https://launchpad.net/ubuntu-rtm/+source/qtmir
[14:43] <Mirv> ricmm: ie not your fault..
[14:43] <brendand> camako, can you clear that up? if it doesn't need to land it's just blocking a silo
[14:43] <ricmm> oh, the branch is broken
[14:43] <ricmm> Saviq: ^
[14:43] <ricmm> https://launchpad.net/ubuntu-rtm/+source/qtmir/0.4.3+14.10.20141007-0ubuntu1 is not in the branch history
[14:44] <Mirv> Saviq: ricmm: manual diffing shows this http://pastebin.ubuntu.com/8552980/
[14:44] <brendand> tedg, hello
[14:44] <Mirv> so that apparently didn't land in the branch, that rebuild
[14:45] <brendand> tedg, need to check some things about silo 12
[14:45] <davmor2> john-mcaleely: sorry just finished the custom tarball looking at it now
[14:45] <ricmm> Mirv: looks like some fallout
[14:45] <ricmm> from the 0.8.0 fail-to-land ?
[14:45] <john-mcaleely> davmor2, no problem, just curious :-)
[14:45] <john-mcaleely> davmor2, thanks!
[14:51] <Mirv> ricmm: yes. I could push it to the trunk, but I'd really like someone from the Mir team to check up their branches and ensure they're all correct. it's already complex now with the mixups of 0.8.0 landings, and rtm deviating from utopic.
[14:51] <Mirv> they can just eg. apply that diff and bzr push, if they just know it's correct
[14:52] <cjwatson> Mirv: I think it's already in trunk
[14:52] <cjwatson> since I merged-and-cleaned the silo that ended up in utopic
[14:52] <Mirv> cjwatson: yes, but the rtm has a different branch now https://code.launchpad.net/~mir-team/qtmir/rtm-14.09
[14:52] <cjwatson> oh maybe not the rebuild, ok
[14:52] <Mirv> so utopic is up-to-date, rtm is not
[14:52] <cjwatson> the stuff that actually matters :P
[14:56] <ogra_> we could re-consider that ... we have still three days to go back to utopic and drop rtm :P
[14:56] <ricmm> so
[14:56] <ricmm> how do I build my silo
[14:56] <ricmm> :(
[14:56] <ogra_> (seems to be in fashion to have high level last minute decisions this week)
[14:56] <Mirv> ricmm: I guess I'll push the diff if no Mir guys around
[14:57] <ricmm> no dont rush it
[14:57] <ricmm> lets give them a bit
[14:57] <ricmm> camako: alan_g
[14:58] <Mirv> ricmm: I pushed, they can review it also after the silo build is done and can be tested. making the branch match what's in archives is not a wrong thing to do, I more like would them to just go over (if they haven't already) and check that both their utopic + rtm branches are what they want them to be, and same for what's in the archives
[14:58] <alan_g> ricmm: ?
[14:58] <Mirv> alan_g: I pushed #267 to https://code.launchpad.net/~mir-team/qtmir/rtm-14.09, syncing from archives. I'd just like someone from the Mir team to be on top of archive vs. branch delta in both utopic + 14.09, so that it's all under control
[14:59] <Mirv> alan_g: as the 0.8.0 landing had some rough edges and utopic != rtm now
[14:59] <ricmm> alan_g: I dont really know whats going on, but we needed some mir input bout the 0.8.0 landing
[14:59] <cjwatson> the rough edges have been smoothed over for the purposes of RTM now
[15:00] <ricmm> Mirv: thank you it seems to be moving along now
[15:00] <cjwatson> not ideally in some ways, but a further landing isn't going to make a difference if it doesn't rearrange the lib*-{mesa,android} bits again
[15:00] <Mirv> archive seems correct, the branches possibly not - for example there's no rtm packaging branch of Mir itself, only https://code.launchpad.net/~mir-team/mir/ubuntu
[15:00] <Mirv> but someone did make the rtm-14.09 branch of qtmir
[15:01] <cjwatson> they were meant to be in sync and only temporarily diverged due to the arm64 mini-branch
[15:01] <cjwatson> the mir team were quite clear to me that they did not want to fork
[15:01] <Mirv> alan_g: so, this is mostly much talk about small divergence, which may not matter at all whenever next Mir release is made and utopic + rtm go back in sync
[15:01] <alan_g> Mirv: AFAIKthere's no fork for rtm
[15:01] <Mirv> cjwatson: right, ok, then it's more like a mistake or a temporary solution that they have the qtmir rtm branch in the first place
[15:01] <cjwatson> there's no *intended* fork for rtm
[15:02] <cjwatson> the versions are not in sync right now, but I understand that to be temporary
[15:02] <Mirv> alan_g: thanks, that's probably all that was needed to know.
[15:02] <alan_g> I can't speack for qtmir
[15:02] <cjwatson> and that's more a matter of utopic being one branch ahead, than a fork
[15:02] <cjwatson> I'm talking about mir
[15:02] <alan_g> Just mir
[15:02] <cjwatson> I advise all product owners to know how to use rmadison to see the state of their packages
[15:02] <cjwatson> and the corresponding Launchpad UI
[15:06] <ricmm> Mirv: could you also push to the -gles trunk?
[15:06] <ricmm> that one is missing there as well, apparently
[15:13] <ricmm> Mirv: :D
[15:14] <Mirv> ricmm: the  lp:~mir-team/qtmir/rtm-14.09-gles-sync ? right, syncing from archives that too
[15:16] <Mirv> ricmm: done, you probably need to rebase
[15:17] <ricmm> yup, thanks
[15:23] <ricmm> jesus im totally fried
[15:24] <ricmm> 57th times the charm
[15:24] <ogra_> ricmm, looks like you have a conflict in your silo
[15:24]  * ogra_ hides behind something 
[15:25] <Mirv> tvoss: utopic 016
[15:25] <tvoss> Mirv, awesome, thank you
[15:26] <Mirv> trainguards: please take over guarding the train :)
[15:30] <sil2100> Internet \o/
[15:31] <sil2100> Mirv: in the meantime, while having no connection, I prepared a fix for the issue with m&c where it was succeeding on failure
[15:31] <ricmm> what the
[15:31] <ricmm> what now
[15:31] <ricmm> hate silo 17
[15:31] <sil2100> ricmm: that usually means something different
[15:31] <sil2100> ricmm: let's look at the logs
[15:31] <ricmm> ah shit
[15:32] <ricmm> need to push qtmir first
[15:32] <ricmm> then qtmir-gles
[15:32]  * ogra_ hands ricmm a bottle of valerian 
[15:32] <sil2100> Right, it seems to be missing qtmir from the silo
[15:32] <Mirv> sil2100: oh, you weren't here? :) ok
[15:33] <Mirv> ricmm: you need to build with "ignore missing twin package" the qtmir first, then qtmir-gles so that it finds qtmir's sources
[15:33] <sil2100> Mirv: I were here for varying periods of time
[15:33] <sil2100> Mirv: whenever WiFi was working and not ;)
[15:33] <Mirv> ricmm: or that's what I've understood, I've not build those myself
[15:33] <sil2100> So I assume some parts of the conversations I missed
[15:34] <Mirv> sil2100: http://irclogs.ubuntu.com/2014/10/13/%23ubuntu-ci-eng.html :)
[15:34] <Mirv> (updated hourly)
[15:35] <Mirv> Saviq: ricmm: which one of you is going to land qtmir first to rtm...
[15:35] <Mirv> re: utopic 010
[15:35] <Mirv> if that's synced to an rtm silo, then there are two with qtmir
[15:37] <Mirv> of course qtmir is relatively trivial and fast to rebuild in either case, you just need to co-operate on the landing
[15:37] <ricmm> Saviq: choose, but choose wisely ;)
[15:37] <ricmm> are you landing today?
[15:38] <Saviq> ricmm, yeah, was just about to land... but need to pull an MP and rebuild
[15:38] <Saviq> ricmm, but not to rtm
[15:38] <ricmm> go ahead and land then
[15:38] <ricmm> I still need a few hours of testing
[15:38] <ricmm> 2-3 maybe
[15:38] <ogra_> bah, but i want the fix in rtm !
[15:38] <ricmm> lol
[15:38] <ricmm> ogra_: you will test it in a few minutes
[15:39]  * ogra_ is annoyed by the dash constantly restarting and stealing focus
[15:39] <ricmm> oh that fix
[15:39] <sil2100> The QML caching fixes are high priority in my opinion
[15:39] <ogra_> yeah
[15:39] <ogra_> sil2100, your opinion only counts if it is onteh list
[15:39] <ogra_> :P
[15:40] <sil2100> ogra_: is that the bug you saw that everyone thought was 'the dash is crashing'? ;)
[15:40] <ogra_> (teh new buglist wejust got)
[15:40] <sil2100> The one from the Fwd?
[15:40] <ogra_> sil2100, yeah, Saviq has it in silo 010
[15:40] <sil2100> Yay
[15:41] <ogra_> sil2100, yup, that mmail
[15:41] <sil2100> Well, so, as always there's a lot of confusion going on
[15:41] <ogra_> yay
[15:42] <ogra_> sil2100, "Please note that the landing team will reject landings that are not on the list" sounds pretty clear to me though
[15:42] <sil2100> But anyway, I suppose the list has top-priority bugs, but if something else critical + rtm14 pops up it's still valid for considaration
[15:42] <sil2100> Yeah, which slightly cotradicts with the contents of the Fwd and what asac mentioned in his other e-mail ;p
[15:42] <sil2100> Just slightly
[15:43] <ogra_> sil2100, it says it needs escalation if you want to land it
[15:43] <ogra_> which i assume means approval by someone in the US ... who are all off today :P
[15:43] <sil2100> ogra_: remember, non-critical bugs need escalation! There's nothing mentioned about new critical bugs ;)
[15:43] <ogra_> lol
[15:43] <sil2100> ;p
[15:43]  * ogra_ marks everything critical
[15:43] <sil2100> hah, CHEATER
[15:44] <ogra_> nah, i play by the rules
[15:44] <ogra_> (your rules :P )
[15:44] <sil2100> My rules are easily bendable
[15:44] <sil2100> ...;)
[15:44] <ogra_> like an iphone ?
[15:44] <ogra_> :)
[15:47] <sil2100> Anyway, what do you guys say on calling off our evening meeting? I guess we can coordinate anything here on IRC since there's only the crew from morning
[15:48] <ogra_> ++
[15:48] <ogra_> good idea
[15:49] <sil2100> I'll continue my quest to patch up the train a little bit
[15:50] <sil2100> Still waiting for olli_ to be free to get some feedback for some of the formalities
[15:50] <sil2100> davmor2, brendand, ogra_, elopio: let's skip today's meeting then
[15:51] <ogra_> yep
[15:51] <elopio> ack.
[15:51] <Wellark> Mirv: what do you mean "previous"
[15:51] <Wellark> was there then in fact a pending merge that was not merged?
[15:51] <Wellark> so we have to start over again?
[15:55] <bzoltan1> trainguards: may I get a silo for bout 8-10 hours. I need to push a desktop only fix for the QtC plugin.
[15:56] <sil2100> bzoltan1: sure, which landing row?
[15:56] <bzoltan1> sil2100:  ahh.. I forget that one :) 59
[15:58] <sil2100> bzoltan1: it's a fix landing, right? i.e. no new features, just fixes for i18n?
[15:59] <sil2100> bzoltan1: asking because of FF ;)
[15:59] <popey> hmm, my devel-proposed phone (nexus 4) keeps offering me #279, i install, reboot and it still offers me #279
[15:59] <popey> its currently on #274 and I can't update it
[16:00] <Mirv> Wellark: no, no, no pending merges, it was just that it needed to land first
[16:00]  * cjwatson works on his third attempt today at test-building the livefs changes for moving click packages to /custom :-/
[16:01] <Wellark> Mirv: so, no rebuilds?
[16:01] <cjwatson> each test upwards of an hour
[16:01] <popey> no landing meeting?
[16:01] <Mirv> Wellark: yep, just "FYI" it went now in, next can be your u-s-s silo
[16:01] <jibel> popey, I had the same problem and couldn't upgrade to 278.
[16:01] <sil2100> popey: argh! Didn't poke you, see poke of davmor2, brendand etc.
[16:01] <jibel> popey, from 274
[16:02] <sil2100> popey: we called it off today since there's no US to hand-over work to
[16:02] <popey> k
[16:02] <Wellark> Mirv: argh.. seems satoris did not finish the testing then..
[16:02] <popey> jibel: what did you do in the end?
[16:02] <Wellark> jgdx: any luck on your side?
[16:03] <jibel> popey, upgraded with u-d-f
[16:03] <popey> ugh
[16:03] <Mirv> Wellark: ? this is the correct order, rtm-002 is built on top of the rtm-006 that now went in
[16:03] <popey> jibel: bug filed?
[16:03] <jibel> popey, I tried to delete/add my U1 account and it didn't change anything
[16:03] <Mirv> Wellark: but sure, 002 is not marked as tested..
[16:03] <popey> last update: 1970-01-05 12:53:25
[16:03] <popey> that looks wonky too
[16:03] <jibel> popey, no, sorry, I've been side tracked then forgot
[16:04] <Mirv> Wellark: that said, as US is off I'm not sure it there would be anyone from QA to sign it off either
[16:04] <bzoltan1> sil2100:  yes, fixing the templates and fixing the click-reviewers-tool part
[16:04] <brendand> this is true
[16:04] <ogra_> popey, jibel talk to stgraber ... we had various outages of the build server the last week ... due to out of diskspace issues ... probably there is a bad delta in utopic-proposed somewhere or so
[16:04] <popey> ok
[16:05] <Wellark> Mirv: OK. let's leave it for tomorrow then..
[16:05] <Wellark> I need something to eat anyway
[16:05] <sil2100> bzoltan1: assigned!
[16:05] <sil2100> Mirv: I guess elopio might be around just in case :)
[16:06] <bzoltan1> sil2100: thank you
[16:06] <Wellark> oh, well.. as it's going to need qa signoff anyway, I might just test by myself
[16:07] <davmor2> sil2100: you know that now I'm having to look at cats on youtube that you've lost me for the rest of the day, I rely on the meetings for my cat fix ;)
[16:08] <sil2100> hah ;)
[16:08] <sil2100> My girlfriend is pushing me hard on buying a cat too, sooner or later I might just join the cat-group
[16:12] <davmor2> sil2100: do it, do it already, you get more cats you have more speed on the interwebz honest ;)
[16:13] <sil2100> Still need to check if my landlords find cats acceptable here
[16:13] <ricmm> sil2100: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-017-1-build/35/console
[16:13] <ricmm> sil2100: I'm going to cry
[16:13] <sil2100> popey: what was that thing you once mentioned that makes the cat less allergy-troublesome?
[16:13] <sil2100> ricmm: let me look
[16:14] <ricmm> sil2100: sorry for the mess, today is a bad day
[16:14] <popey> sil2100: "Allerpet C"
[16:14] <sil2100> ricmm: no worries, I see silo 17 just hates you for no reason
[16:15] <sil2100> Let's see how we can hate it back
[16:15] <sil2100> popey: thanks!
[16:16] <popey> np
[16:16] <ricmm> sil2100: I stopped a previous build before accidentally, I'm guessing some files are stale
[16:17] <ricmm> in the workspace ?
[16:17] <ricmm> looks like its just being dump to get to a sane state
[16:17] <sil2100> Ah, ok, that might indeed be the case, CI Train cannot handle abortions when it's working in the middle somewhere
[16:17] <sil2100> Especially during package build
[16:17] <sil2100> Let me check that and clean it up then
[16:17] <sil2100> ricmm: thanks for the info :)
[16:18] <sil2100> ricmm: usually it's only safe to abort when the source packages are already pushed to the PPA
[16:18] <davmor2> sil2100, ogra_, john-mcaleely: I'm happy with the device tarball :)
[16:18] <ogra_> then land it already !!!
[16:18] <sil2100> Yeah, +1 on that
[16:18] <sil2100> john-mcaleely: ^ upload please!
[16:18] <davmor2> ogra_: I can't :P
[16:18] <ricmm> sil2100: it was literally a misclick, was trying to get to the build page
[16:20] <john-mcaleely> sil2100, ack. will do that now
[16:20] <ricmm> sil2100: please save my poor package from the depths of trainhell :)
[16:20] <ogra_> did you get under the train ?
[16:21] <ogra_> do not stand on the tracks !
[16:21] <ogra_> ... and mind the gap !!!
[16:21] <sil2100> ricmm: sure, looking at it now, I actually wonder why it didn't get uploaded to the PPA even ;)
[16:21] <john-mcaleely> ogra_, sil2100 pushed
[16:21] <sil2100> john-mcaleely, davmor2: yay, thanks guys!
[16:21] <ogra_> yippie
[16:21] <john-mcaleely> indeed, thank you davmor2 sil2100 !
[16:21] <ogra_> third OTA today ...
[16:22] <olli_> sil2100, was that me or ogra
[16:23] <sil2100> ricmm: it might take some minutes, I need to first check what exactly happened
[16:23] <ricmm> I'd say wipe the workspace :)
[16:23] <olli_> sil2100, ah, saw the ping in the other channel
[16:23] <ogra_> he usually says ogra if he means me :)
[16:23] <sil2100> olli_: hello! I'm waiting for you as well :)
[16:23] <ogra_> (only my GF calls me oli nowadays :) )
[16:24] <olli_> does she use tab expansion... that's the question ;)
[16:26] <lool> trainguards, would someone update status of line 44 as Landed? I believe the custom tarball landed (after looking at system-image json files  :-)
[16:26] <lool> I'm about to land the mako one though
[16:27] <sil2100> \o/
[16:27] <sil2100> lool: suar
[16:28] <lool> done
[16:28] <sil2100> ricmm: fixing it might be easy, just want to know why it happened, since the abort seemed to have happened in a moment that shouldn't break anything in theory
[16:30] <ricmm> sil2100: alrighty
[16:33] <ogra_> sil2100, ARGH !!!!!!!!!
[16:33] <sil2100> ogra_: ?!
[16:33] <sil2100> What now?!
[16:33] <ogra_> ogra@styx:~/Devel/branches/phablet-tools$ ./citrain device-upgrade 017 0000 ubuntu-rtm
[16:33] <ogra_> ...
[16:33] <ogra_> Get:1 http://ppa.launchpad.net/ci-train-ppa-service/landing-015/ubuntu-rtm/ 14.09/main qtdeclarative5-ubuntu-ui-toolkit-plugin armhf 1.1.1279.1+14.10.20141013-0ubuntu1 [353 kB]
[16:33] <ogra_> Get:2 http://ppa.launchpad.net/ci-train-ppa-service/landing-015/ubuntu-rtm/ 14.09/main ubuntu-ui-toolkit-theme armhf 1.1.1279.1+14.10.20141013-0ubuntu1 [199 kB]
[16:33] <ogra_> ...
[16:34] <sil2100> ?
[16:34] <ogra_> sil2100, note the "landing-015"
[16:34] <sil2100> Ahahha
[16:34] <ogra_> i sepcified 17
[16:34] <ogra_> *specified
[16:34]  * ogra_ curses
[16:34] <ogra_> that was my production device
[16:34] <ricmm> whats going on today
[16:34] <sil2100> ogra_: octal my friend ;)
[16:34] <ricmm> everything is going to hell
[16:34] <sil2100> Oh crap...
[16:35] <ogra_> and i definitely didnt mean to re-flash it before final :(
[16:35]  * ogra_ tries to get back to a sane stae and will manually install 017 
[16:35] <sil2100> ricmm: yeah, like I can't even understand why your silo is breaking up now even, since the build you aborted - that one even without the abortion behave strangely and didn't upload the source package which it created!
[16:36] <sil2100> ogra_: I guess we need to modify the citrain tool anyway to be more sane with this, as I'm sure many people had the same problem
[16:36] <ogra_> are you sure you are not rebuilding silo 15 all the time ?
[16:36] <ogra_> :P
[16:36] <sil2100> Or worse, who knows if some people didn't test other silos instead of their own!
[16:36] <sil2100> ogra_: ;p
[16:36] <ricmm> at this point
[16:37] <ricmm> everything is possible
[16:37] <sil2100> We're in the twighlight zone
[16:37] <ogra_> yeah, i was a bit surprised to get qtdeclarative5-ubuntu-ui-toolkit-plugin and ubuntu-ui-toolkit-theme from ricmm's silo
[16:37] <ogra_> but at least i can say the packages from silo 015 leave my device still booting :P
[16:38]  * ogra_ rolls back these two 
[16:40] <ogra_> sil2100, ARGH ... even worse ... citrain re-enables recommends !
[16:41] <ogra_> that means people using it for testing might get weird stuff installed they shouldnt get (if the recommended package is in the same silo)
[16:42] <ricmm> sil2100: boom
[16:42] <ricmm> ^ :D
[16:42] <ogra_> oh
[16:42] <sil2100> ricmm: yeah, wanted to get some debug info, but that's useless ;)
[16:42] <ogra_> and exception Exception
[16:43] <ogra_> :)
[16:43]  * sil2100 puts on his gogles and dives in
[16:43] <ogra_> is that like double negation ?
[16:43] <ogra_> two no make a yes :)
[16:45] <ricmm> I: unmounting /var/cache/pbuilder/ccache filesyste2014-10-13 16:41:38,380 INFO Check that the newly created source package has relevant diff
[16:45] <ricmm> 2014-10-13 16:41:38,640 ERROR Uncaught exception: Exception: dpkg-source command returned an error.
[16:46] <ogra_> oookay ... rebooting with 017 installed
[16:46] <ricmm> mmm
[16:46] <ricmm> Creating source with bzr bd -S -- -kB879A3E9 -d -v0.4.3+14.10.20141007-0ubuntu1 dpkg-buildpackage -rfakeroot -d -us -uc -v0.4.3+14.10.20141007-0ubuntu1 -S
[16:46] <ricmm> sil2100: that doesnt look right &
[16:46] <ogra_> still boots ... thats good for a start
[16:46] <sergiusens> sil2100: Mirv can I get a silo for line 60? in the list of bugs to be fixed by Wednesday
[16:47] <ogra_> ricmm, confirmed fixed, i see all scopes again ... nothing cut off
[16:48] <ogra_> sil2100, ^^
[16:48] <sil2100> ogra_: excellent
[16:48] <sil2100> sergiusens: sure
[16:48] <ricmm> ogra_: awesome
[16:49] <ricmm> ogra_: can you play with it, like mess up with source files for apps and so on
[16:49] <ricmm> and like maybe downgrade packages of address-book-app and messaging-app
[16:49] <ricmm> through far away versions
[16:50] <sil2100> sergiusens: just in case, can you write the bug number there as well?
[16:50] <ricmm> sil2100: fingers crossed
[16:50] <sergiusens> sil2100: it's linked in the MP as should be
[16:50] <sergiusens> but ok
[16:50] <sil2100> Ah
[16:51] <sil2100> sergiusens: ok, the nvm! Since I know the bug number, just want it to be visible to the QA guys just-in-case
[16:51] <ogra_> ricmm, "mess up with source files" ?
[16:51] <sil2100> GEH
[16:51] <sil2100> OK, but this might give me some ideas
[16:51] <ogra_> another exception exception
[16:52] <ogra_> it is like the bot is stuttering :)
[16:52] <sergiusens> sil2100: since I put in it doesn't need QA signoff as it's a 3 line fix to be reboust agains network errors, I bet they'll look into the mp ;-)
[17:02] <ricmm> sil2100: seems to be taking a different path than usual
[17:02] <ricmm> as it usually just picks the tarball from the silo
[17:02] <davmor2> oh god no who has been giving sli2100 ideas
[17:03] <ogra_> ricmm, i cant find any issues trying out random apps etc
[17:03] <davmor2> sil2100: even
[17:03] <ogra_> ricmm, i'd say lets hand it to QA and see if they can
[17:03] <ricmm> they wont find issues, im more interested in finding issues in upgrade paths
[17:03] <ricmm> how can we simulate some of these
[17:04] <ogra_> we cant really without having an image
[17:04] <ricmm> I could put my phne in image 96 + my debs and do a manual update of unity8/dash which is what caused the scopes issue
[17:04] <ricmm> thats the most similar thing
[17:04] <ogra_> right
[17:04] <ricmm> I'll do that
[17:04] <ogra_> but that doesnt really give you all the context anOTA would give you ...
[17:04] <ogra_> perhaps enough though
[17:04] <ricmm> well the issue is about packages themselves only updating the changed files
[17:04] <ricmm> that happens be it OTA or pure apt install
[17:05] <ogra_> right
[17:05] <ricmm> ok I'll wipe this beast
[17:06] <ricmm> sil2100: lets do a full manual wipe of the workspace
[17:07] <sil2100> ricmm: wait, since it's strange - I already did a partial wipe of the workspace and it didn't help, the strangest thing is that it's actually taking the tarball from the silo, using it but then doesn't want to recognize it as needed
[17:08] <ogra_> cjwatson, does an ubuntu-touch image build lately trigger an ubuntu-coure system image build ? somehow the failure mails i get seem to always match the touch build times (might indeed be coincidence but it somehow feels like)
[17:09] <sil2100> dpkg-buildpackage: source-only, diff-only upload (original source NOT included) <- I wonder
[17:09] <ricmm> seeing something interesting here
[17:09] <ricmm> sil2100: the version prior to mine, the one we had to manually commit
[17:09] <ricmm> so the 0.8.0 version
[17:09] <ricmm> has qtmir-gles (0.4.3+14.10.20141007-0ubuntu1) 14.09; urgency=medium
[17:09] <ricmm> instead of utopic
[17:09] <ricmm> would that hurt?
[17:10] <sil2100> hm!
[17:10] <ogra_> not in the 14.09 archive
[17:10] <ricmm> yea but then qtmir-gles (0.4.3+14.10.20141013-0ubuntu1) utopic; urgency=medium
[17:10] <ricmm> which is mine
[17:10] <ogra_> (which is what your PPA should build against for rtm)
[17:10] <ricmm> the 07 from qtmir base is not 14.09, that one says ubuntu
[17:11] <ricmm> err, utopic
[17:11] <ogra_> well, that shouldnt matter i think, but the different versions will surely do
[17:12] <ricmm> I'll make it 14.09 and see
[17:12] <ricmm> hitting it
[17:13] <ogra_> i guess it is rather 20141007 vs 20141013
[17:13] <ogra_> since these are different upstream versions
[17:13] <ricmm> the ppa's version of qtmir is 20141013
[17:14] <ogra_> for both ?
[17:15] <sil2100> ricmm: ok, let's try this... let's try changing in the M&R the qtmir-gles (0.4.3+14.10.20141007-0ubuntu1) 14.09 to utopic maybe?
[17:15] <sil2100> Since in theory it all should work, but you might be right here
[17:15] <ricmm> well I actually made the top version 14.09
[17:15] <ricmm> didnt work
[17:16] <ricmm> maybe I should try making them both utopic
[17:16] <ogra_> no, that wont have any impact
[17:16] <ricmm> lol
[17:16] <sil2100> Because dpkg-genchanges acts as if it was not treating the new version as differing from the previous one
[17:16] <ogra_> not at that level
[17:17] <sil2100> dpkg-genchanges will not include the source code trball in the upload in the default mode only when the upstream version number in the changelog does not differ from the previous entry
[17:17] <ricmm> so what do I do
[17:17] <ricmm> utopic it all?
[17:17] <sil2100> ricmm: yeah, change the semi-last to utopic and let's see how it goes
[17:17] <sil2100> Maybe that's some weird case here
[17:18] <sil2100> i.e. 0.4.3+14.10.20141007-0ubuntu1
[17:18] <sil2100> I want to see what it'll say to that, if it will be the same bullshit from dpkg-genchanges
[17:19] <ogra_> wont the PPA barf that it already has a newer version ?
[17:19] <sil2100> ogra_: the PPA has no version right now
[17:19] <sil2100> It didn't upload anything
[17:19] <ogra_> it built 20141013 once
[17:19] <ogra_> or not ?
[17:19] <sil2100> ogra_: no, only the source package
[17:19] <ricmm> no
[17:20] <sil2100> But no upload has been made since CI Train didn't see an .orig tarball
[17:20] <ricmm> pushedededededing it
[17:20] <sil2100> So it built it but didn't upload shit
[17:20] <sil2100> ;)
[17:20] <ogra_> boing
[17:20] <sil2100> Still not sure if this will help though, but anyway the cause of all troubles here is that it's not acknowleding the orig tarball
[17:20] <sil2100> (I suppose)
[17:21]  * sil2100 spies on the stupid build job
[17:23] <sil2100> Ah, wait
[17:23] <sil2100> ricmm: one moment
[17:23] <sil2100> It failed, but let me try again in a moment
[17:24] <ricmm> D:
[17:24] <ricmm> I'm about to just push a 13.1 base qtmir
[17:24] <ricmm> and upgrade this :)
[17:24] <ricmm> hmm
[17:24] <ogra_> that was what i would have suggested next :)
[17:24] <ricmm> ogra_: upgrading just unity8 did nothing
[17:24] <ricmm> to break the scopes from 96 to latest available
[17:25] <ogra_> 96 should be broken as i understood
[17:26] <ogra_> (without any changes)
[17:26] <ricmm> it should always work without any changes if coming from a clean cache
[17:26] <ricmm> the isue is when updating when you have a dirty cache from an older version
[17:26] <ricmm> and the change is extensive
[17:28] <sil2100> ricmm: ah ha!
[17:28] <ogra_> oh, roght
[17:28] <sil2100> ricmm: I think I've got it
[17:28] <ogra_> *right even
[17:28] <sil2100> CRAP
[17:28] <ricmm> :D
[17:28] <sil2100> Ok, now to think how to fix this
[17:28] <ricmm> rm -rf /
[17:28] <cjwatson> ogra_: no
[17:28] <ogra_> k, thanks
[17:29] <sil2100> AH
[17:29] <ogra_> kind of felt suspicious :)
[17:29] <sil2100> No!
[17:29] <sil2100> ricmm: eeek~!
[17:29] <sil2100> ricmm: ok, the fix is easy... change utopic to UNRELEASED in the last entry ._.
[17:29] <sil2100> ricmm: in the top-most one...
[17:29] <cjwatson> ogra_: they're just iterating a lot
[17:30] <ogra_> yeah
[17:30]  * sil2100 feels stupid for not seeing that 
[17:30] <sil2100> ricmm: so, because the last entry was released, what CI Train did it added a NEW changelog auto-generated entry with the same version number
[17:31] <cjwatson> ricmm: for the record, the only thing that should care about 14.09 vs. utopic in the changelog header is dpkg-genchanges filling in the Distribution field in .changes, which controls where Launchpad puts it in response to a direct upload to an archive
[17:31] <ogra_> lovely
[17:31] <cjwatson> (I see that sil2100 has found the problem, but it's worth understanding the model too)
[17:31] <sil2100> ricmm: so that's where dpkg-genchanges was going crazy
[17:31] <ricmm> alrighty
[17:31] <ricmm> thanks for finding it
[17:31] <ricmm> but lets wait for it to actually build ;)
[17:32] <sil2100> cjwatson: yeah, we though so too, just because something really crazy was happening I wanted to make sure it's not some crazy border case
[17:32] <sil2100> ricmm: 13.1 you mean? :)
[17:33] <ricmm> woo
[17:33] <ricmm> :D
[17:34] <sil2100> Phew, what a day!
[17:34] <ogra_> yeah
[17:36] <ogra_> sil2100, hmm ... seeing your mail ...
[17:37] <sil2100> ogra_: what's up?
[17:37] <ogra_> sil2100, do we leave utopic open as general playground ? (you dont mention how we treat utpoic silos)
[17:38] <ogra_> (and i could imagine community people wanting to play with certain fixes in there for tehir app development etc )
[17:38] <ogra_> i.e. i just saw a discussion about new evolution-data-server in #ubuntu-app-devel for example
[17:39] <sil2100> I think we all need to focus on the critical bugs - we could gate some landings for utopic, but I'm afraid that we might forget about syncing them to ubuntu-rtm if those pile up, and it might start causing trouble when some critical only fixes need landing
[17:39] <sil2100> Since most upstreams land first in utopic, then we would have to forcefully pull in those non-critical changes to ubuntu-rtm as well
[17:39] <sil2100> Risking additional regression potentials
[17:39] <ogra_> k
[17:39] <sil2100> :<
[17:40] <ogra_> (i would see that in the landers responsibility to make sure the right cherry picks go in)
[17:41] <ogra_> sil2100, my fear is simply that people will take utopic silos and let them sit to shelve their non critical fixes
[17:41] <ogra_> (and that we end up without free utopic silos)
[17:41] <sil2100> ogra_: we simply won't assign those if fixes aren't critical
[17:41] <ogra_> k
[17:41] <sil2100> ogra_: since as I mentioned, most upstreams first land in utopic anyway
[17:42] <sil2100> So the gating is in overall for the whole thing
[17:47] <ogra_> popey, hmm, so ... damn ... i guess i need a critical+rtm14 bug for your seed change :(
[17:48] <davmor2> Wellark: spreadsheet line 29 as above only above is a completely different package any chance of adding some details please
[17:50] <ogra_> davmor2, there are 28 other lines above ... just pick one
[17:50] <ogra_> :)
[17:51] <ogra_> well, perhaps not 1-3
[17:51] <davmor2> ogra_: I was wondering if it was all the tests for all the silos above man that would be a lot of testing ;)
[17:51] <ogra_> well, it is like a lottery
[17:52] <ogra_> just pick one ... if that doesnt pass line 29 failed :)
[17:57] <davmor2> ogra_: hahaha
[18:01] <slangasek> ogra_: "not landed"?
[18:02] <ogra_> slangasek, sorry, context ?
[18:02] <slangasek> ogra_: you highlighted me saying I didn't do something
[18:03] <ogra_> hmm, cant remember
[18:03] <slangasek> ok, then I will probably not do it again next time either ;)
[18:04] <ogra_> slangasek, ah, found it
[18:04] <ogra_> slangasek, you rolled back a landing because i was not QAed
[18:04] <ogra_> slangasek, but apart from the changelog there was no note about that anywhere (spreadsheet said "landed")
[18:04] <slangasek> ah
[18:05] <slangasek> I did not know I was expected to do that, no
[18:05] <ogra_> i'm not even sure we have any such state ... i was just mentioning that you hadnt noted it anywhere else
[18:05] <ogra_> and people were looking at the spreadsheet and wondering :)
[18:05] <ogra_> we might need such a switch somewhere
[18:06] <ogra_> as i said on the WE ... i think we sould have some planning meeting about easier and better rollback mechanisms at the sprint
[18:06] <ogra_> (for silos as well asfor images)
[18:07]  * slangasek nods
[18:13]  * ogra_ wonders why he doesnt get any notification for 103
[18:14] <ogra_> oh, wow
[18:14] <ogra_> because NM is totally lying at me about being on wlan
[18:17] <davmor2> ogra_: I blame that oliver bloke, bound to be his fault ;)
[18:17] <ogra_> haha
[18:18] <ogra_> yeah, i need to make sure to not put my finger on the antenna
[18:20] <fginther> cjwatson, mvo, builds for https://code.launchpad.net/~mvo/click/lp1379657-user-hook/+merge/238025 are now passing
[19:01] <cjwatson> fginther: thanks
[19:01] <fginther> cjwatson, np
[19:13] <cjwatson> ogra_,sil2100,robru,Mirv: I'm ready to start landing https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/split-custom-tarball/+merge/237905 .  Any objection if I aim to get steps 1 and 2 done for utopic tonight, while the US is mostly not trying to do anything significant?
[19:14] <sil2100> cjwatson: looking
[19:18] <cjwatson> The rootfs and custom tarball from my most recent test build look largely OK; I corrected two mistakes
[19:18] <cjwatson> Though I haven't actually tried on a device
[19:19] <cjwatson> If anything goes wrong we can back out livecd-rootfs straightforwardly enough and I can try harder in a PPA
[19:19] <cjwatson> But I've been at this most of the day and the test cycle is over an hour, so I didn't want to hang about too long
[19:21] <cjwatson> Step 3 may not actually be a thing since at least some of the product owners just want the apps in question removed entirely
[19:23] <cjwatson> And I guess the other question is would the world light up red if the ten apps in question disappeared from 14.09?  Because I understand that to be the plan
[19:25] <cjwatson> Oh, maybe we're installing some of them.  https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/split-custom-tarball/+merge/237905/comments/583719 suggests we'll still be installing amazon, ebay, gmail, reminders, twitter, and facebook
[19:25] <cjwatson> So step 3 will be a thing to make sure those are there
[19:33] <cjwatson> sil2100: any thoughts?
[19:34] <rsalveti> sil2100: cjwatson: quick question, do I need to change something in my dput conf in order to be able to push a package into a RTM silo?
[19:34] <cjwatson> rsalveti: make sure you have dput from trusty-updates or utopic
[19:34] <cjwatson> (or dput-ng, whichever)
[19:34] <cjwatson> rsalveti: then dput ppa:~OWNER/ubuntu-rtm/NAME
[19:35] <rsalveti> cjwatson: oh, great, thanks!
[19:35] <cjwatson> sorry without the ~
[19:35] <cjwatson> dput ppa:OWNER/ubuntu-rtm/NAME
[19:36] <cjwatson> rsalveti: you'd only have to change anything in your own configuration if you'd already redefined ppa
[19:36] <rsalveti> right, it's still the default, so it should be fine
[19:36] <Wellark> davmor2: I don' remember which one that was
[19:36] <Wellark> there use to be the utopic line above it
[19:37] <Wellark> davmor2: will check the changelog..
[19:39] <Wellark> davmor2: ok. added some info
[19:41] <rsalveti> cjwatson: worked fine, thanks!
[20:22] <jgdx> Wellark, first thing in the morning. Sorry for late reply.
[20:41] <Wellark> jgdx: np
[21:44] <sergiusens> ogra_: do all our packages have a FFe?
[22:06] <rsalveti> sergiusens: we have for some
[22:07] <rsalveti> yay, wizard crashed when creating the network connection =\
[22:07] <rsalveti> would need to find the bug though
[22:15] <rsalveti> argh, unity8 crashing when an alarm is triggered
[23:13] <cjwatson> landing livecd-rootfs 2.255 in utopic with https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/split-custom-tarball/+merge/237905; if this goes wrong the plan is to revert to 2.254
[23:28] <sergiusens> trainguards can I get a reconfig for line 12?
[23:31] <cjwatson> sergiusens: done
[23:31] <sergiusens> thanks