[00:59] <Wellark> has silo 19 landed yet?
[00:59] <robru> Wellark: no I'm still waiting on a core dev to ack the packaging.
[01:00] <robru> Wellark: not sure who else is around to do that
[01:00] <Wellark> the computer says.. no.
[01:00] <robru> infinity: can you ack silo 19? https://ci-train.ubuntu.com/job/ubuntu-landing-019-2-publish/1/
[01:09] <infinity> robru: Oh, right, let me look again.
[01:09] <infinity> Got distracted.
[01:10] <infinity> Wellark: What's with the removal of the copyright boilerplate from CMakeLists?
[01:13] <infinity> robru: Looks sane, assuming it all builds and installs right.
[01:13] <robru> infinity: yeah Wellark tested it
[01:13] <robru> infinity: also I installed it but didn't really test much. can confirm phone does not explode.
[01:14] <robru> infinity: thanks
[01:14] <robru> Saviq: kgunn: do not be afraid. I'm about to test a small change to citrain, and the bot will ping you with some phony info in a few minutes. it's all lies, I'm not touching anything in silo 16, there will be no interruption to the PPA, only the spreadsheet. Remember, the map is not the territory.
[01:14] <infinity> SHame about the really ugly newline mangling when creating changelogs. :/
[01:15] <robru> infinity: yeah that's been a sore point for citrain from the beginning.
[01:15] <robru> infinity: i literally have no idea where is the code that is causing that, otherwise I'd rip it out
[01:18] <robru> Saviq: kgunn I have completed the test and everything is back to normal. sorry for the noise
[01:19] <robru> (must have been too fast for queuebot to notice the change...)
[01:44] <Wellark> infinity: plain CMakeLists.txt files are not really copyrightable
[01:44] <Wellark> generic cmake modules are a different story
[01:45] <Wellark> I simply removed the few existing copyright notices from the couple of CMakeFiles.txt to be consistent inside the tree
[01:46] <Wellark> it's really the same thing as we don't have copyright notices in debian/control and friends
[01:47] <Wellark> they are just descriptions
[01:47] <cyphermox> hmm
[01:47] <cyphermox> robru: infinity: is there a freeze exception for the touch-only stuff or should I file a freeze exception bug?
[01:48] <Wellark> I'm pretty sure we have a catch-all for touch
[01:48] <Wellark> and if not we should
[01:48] <cyphermox> Wellark: the catch-all needs to catch all; not sure whether mtp was counted in, even if it really is touch only
[01:49] <Wellark> cyphermox: anyone using it right now except though packages?
[01:49] <Wellark> *touch
[01:49] <cyphermox> Wellark: please let me look into it
[01:50] <Wellark> cyphermox: and even if it would have some non-touch users it's a core piece of the touch platform and clearly has to have the same blanket exception as the rest of the stuff
[01:50] <cyphermox> Wellark: I don't assume
[01:50] <Wellark> what's the worst thing that could happen if you land without exception?
[01:50] <cyphermox> I agree, but I'd rather check that the bug does include mtp explicitly should it need to
[01:51] <cyphermox> Wellark: that's not the point, the processes are there for a reason :)
[01:51] <Wellark> sure, I understand your point
[01:51] <Wellark> just wondering :)
[01:51]  * Wellark imagines an angry mob armed with trouts
[01:57] <robru> Wellark: a trout-whalloping is nothing to shake a stick at.
[01:57] <robru> cyphermox: I'm not aware of any touch exception bug, just the one from last cycle.
[02:02] <infinity> cyphermox: To be fair, with RTM looming, we really should have a feature freeze (with review and acception criteria) for touch at this point too, not blanket wild west landing.
[02:03] <cyphermox> I agree
[02:04] <cyphermox> infinity: I'm not sure how you guys proceed to land stuff right now; and I'd like to land silo 007, it has MTP; but I also want to bring up the feature freeze thing. I'm sure others would be happy to just ignore that altogether and keep landing things
[02:04] <imgbot> [02:05] <infinity> cyphermox: utopic FF was only a few hours ago, if you already prepped a silo that breaks that, I'm happy to give you the verbal go-ahead with a release team hat on.
[02:06] <cyphermox> the silo was alredy in progress with some features, I didn't expect it would take so long to get ready
[02:08] <cyphermox> robru: so then I'll let you make the call when / whether to push the buttons on 007
[02:13] <cyphermox> Wellark: this indicator-network landing; is that fixes for the wifi device disappearing?
[02:15] <robru> cyphermox: will do
[02:19] <robru> cyphermox: done
[02:20] <cyphermox> thx
[02:20] <robru> cyphermox: you're welcome
[02:21] <cyphermox> now the only horrible horrible thing left is the bluetooth 2.0 pairing fubar.
[02:21] <Wellark> cyphermox: nope.
[02:22] <Wellark> which wifi dissapearence you are talking about?
[02:22] <Wellark> I have not received any reports of that happening anymore
[03:29] <imgbot> [03:29] <imgbot> [03:35] <alecu> yay 204!
[03:35]  * alecu updates
[03:39] <robru> Solo usage approaches an all time low...
[04:30]  * Mirv upgrades
[04:31] <Mirv> robru: is the silo 010 delayed on purpose, would it need a small QA signoff or something?
[04:31] <Mirv> I think I saw it tested already in the evening
[04:52] <robru> Mirv: oh you can release it. I was just waiting for the image build, then forgot about it
[04:53] <Mirv> robru: oh, ok
[04:56] <Mirv> rsalveti approved the powerd branch, but https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/7/artifact/packaging_changes_indicator-datetime_13.10.0+14.10.20140819-0ubuntu1.diff would still need core-dev approval
[04:56]  * rsalveti looks
[04:56] <Mirv> and he's awake! \o/
[04:57] <Mirv> the full branch in the silo together with the powerd was this https://code.launchpad.net/~charlesk/indicator-datetime/add-powerd-alarm-support/+merge/231303
[04:58] <rsalveti> this diff is weird
[04:58] <rsalveti> oh, it's not
[04:58] <rsalveti> sorry, that's for the indicator, not powerd
[04:58] <rsalveti> Mirv: yeah, +1
[04:59] <Mirv> rsalveti: hehe. yes, since you already approved the powerd directly in there.
[04:59] <Mirv> thanks.
[04:59] <rsalveti> yeah, thanks
[05:01] <Mirv> wow, I thought KDE was big in the amount of packages, but Colin has now landed Perl...
[05:01] <Mirv> it seems a popular language in the archive, that's for sure
[05:03] <robru> Mirv: http://xkcd.com/224/ perl holds the universe together ;-)
[05:09] <Mirv> ;)
[06:24] <mvo_> good morning - could someone from QA please re-test line 31 (landing 006) ? I updated debsig-verify in the archive to deal with the readonly $HOME and it works for me now
[06:25] <Wellark> what is this breanch?
[06:25] <Wellark> https://code.launchpad.net/~ps-jenkins/indicator-network/ubuntu-utopic-proposed
[06:25] <Wellark> jenkins just created that one
[06:26] <Wellark> I didn't ask for it
[06:40] <robru> Wellark: Jenkins makes those for all landings. You "asked for it" by publishing a silo. It's created in case there are merge conflicts meeting to trunk, eg, if somebody committed to trunk after the silo was built.
[06:53] <Wellark> robru: how do I get rid of it?
[06:54] <robru> Wellark: you don't? It's not owned by you, why do you want to delete it?
[06:54] <Wellark> dunno :)
[06:55] <Wellark> ok, I will just ignore it
[06:57] <robru> Wellark: yeah, all ci train projects have them, https://code.launchpad.net/~ps-jenkins
[07:00] <Mirv> :)
[07:32] <Mirv> someone has pasted in a wrong place... (A1)
[07:33] <Mirv> I moved it to line 34 because the spreadsheet was barely usable otherwise
[07:33] <Mirv> oh, ok, it's just erronous copy from line 13, removing
[07:36] <brendand> sil2100, should i look at reminders_app?
[07:37] <sil2100> brendand: yeah, now that the whole promotion run is over, please ;)
[08:04] <sil2100> hmmmm
[08:05] <sil2100> Is it only me, or dit someone for the first time implicitly call me a racist because I use the term 'whitelist'? o_O
[08:05] <ogra_> no, you are right
[08:06]  * ogra_ has been shaking his head for the last 30min about that mail
[08:07] <brendand> there's always one guy
[08:19] <brendand> hmm, my mako isn't detecting the update
[08:19] <sil2100> We already agreed yesterday that your mako is broken
[08:19] <sil2100> ;)
[08:19] <brendand> sil2100, we?
[08:19] <brendand> sil2100, you and davmor2 ?
[08:19] <sil2100> During the meeting!
[08:20] <brendand> sil2100, that's not *we*, that's you guys
[08:20] <brendand> sil2100, my mako is lovely and perfect thanks
[08:20]  * sil2100 is shocked
[08:20] <brendand> sil2100, you're a racist anyway :P
[08:21] <brendand> sil2100, so i don't have to listen to you
[08:24] <sil2100> :|
[08:25] <sil2100> I'm far from being racist dear brendand
[08:25] <Mirv> oh, my brain didn't understand that e-mail at all.
[08:25] <sil2100> And if I remember correctly, YOU used the term whitelist as well!
[08:26] <sil2100> Now CONFESS
[08:27] <Mirv> we're probably not in a business of studying etymology of colors, but I agree that black is cool, and especially black cats, so we should switch the blacklist being the cool list and whitelist being the annoying bug list
[08:28] <Mirv> so not the right forum but I can see how the world is annoyingly full of faults
[08:29] <Mirv> now if there'd be a bug tracker for World, we could forward this bug to upstream, but annoyingly I don't know who is controlling the World project
[08:29] <sil2100> ;)
[08:29] <sil2100> Who's upstream for World?!
[08:29] <Mirv> maybe it's X.org though, they've had 'make world'
[08:32] <mvo_> brendand, davmor2: is there a chance that someone from QA could retest my click update? in line #31, landing 006, I fixed a bug in debsig-verify (now 0.10ubuntu1) that fixes the verification when running in a RO rootfs
[08:32] <mvo_> (please :)
[09:27] <Saviq> sil2100, hey, looking at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+sourcepub/4365871/+listing-archive-extra
[09:27] <Saviq> sil2100, is the take-changelog-until-newline working?
[09:28] <brendand> ogra_, be in the krillin channel
[09:28] <ogra_> brendand, one moment ... once i moved devices ...
[09:29] <sil2100> Saviq: it was supposed to, let me take a look if it didn't get broken somewhere with the RTM changes
[09:30] <sil2100> Saviq: oh it seems it did get broken, let me try an fix that ;/
[09:31] <Saviq> sil2100, thanks
[09:35] <sil2100> Ok, found the problem, fix in a few minutes
[09:53] <brendand> davmor2, you need any help reproducing the bug
[09:53] <brendand> ?
[09:54] <davmor2> mvo_: I need to dig into a bug first.  But can take a look after that
[09:55] <brendand> mvo_, oh just saw that - might get a chance later this morning
[09:55] <davmor2> brendand: I'm going to reflash to 203 first and then see what happen if I ring the phone
[09:55] <mvo_> davmor2, brendand: thanks a bunch, alternatively I could ask om26er as he did the test yesterday, not sure what your policy is here :)
[09:56] <davmor2> mvo_: if om26er tested then it should be good unless you add new code
[09:56] <mvo_> davmor2: well, he tested it and it failed :)
[09:57] <mvo_> davmor2: and I added new code to make it stop doing this (sorry that I wasn't more clear in my original question)
[09:57] <davmor2> mvo_: ah so a retest is required.  If om26er has already tested and knows how to reproduce the failure then it might be easier for hime to continue testing it then
[09:58] <mvo_> om26er: hi, sorry for being a nuisance - would it be possible to re-test the click update with the latest image (#204) ? that should have debsig-verify 0.10ubuntu1 which fixes the click signature verification bug ?
[09:58] <mvo_> davmor2: thanks!
[09:59] <davmor2> om26er: thanks dude handing off to you as you know where it breaks, what to look out for etc :)
[10:03] <asac> curious, is there a new image that fixes the big unity/mir/whatever crashes that were in 202/203?
[10:03] <ogra_> asac, no
[10:03] <ogra_> asac, and it seems to be device specific anyway
[10:03] <asac> kk
[10:04] <asac> hope that gets fixed soon. kind of a miserable dog right now i am :)
[10:05] <ogra_> asac, well, once we find the cause .... my suspicion is we get mixed up sensor info from the device level ...
[10:06] <ogra_> i.e. you seem to be possible to crash it by moving the device at a point where only the proximity sensor should deliver data
[10:06] <ogra_> s/possible/able/
[10:06] <asac> ogra_: I assume we land the device parts in cowboy style there still?
[10:06] <asac> and the regression is from enablement level?
[10:06] <ogra_> gerrit reviews
[10:06] <asac> yeah, well. still :)
[10:06] <ogra_> thats the entry level check ...
[10:07] <ogra_> nothing beyond that though
[10:07] <asac> sure, thats like MP review
[10:07] <asac> but no silo testing properly
[10:07] <asac> we dont use an android package right?
[10:07] <asac> so just pure pump from gerrit into device tar
[10:07] <ogra_> and since we have no properly working s-i server yet it isnt even sure you get the right device parts
[10:07] <sil2100> asac: we're trying to bisect where it exactly started happening, but as it might be in the lower lever it's really hard to target
[10:07] <ogra_> asac, right
[10:07] <asac> sil2100: youc an try older device tarball with latest rootfs
[10:07] <asac> if its gone then its that
[10:08] <asac> i doubt we introduced incompatible changes there that require changing rootfs in parallel
[10:08] <ogra_> right ... i just try the other way round ...
[10:08] <sil2100> Saviq: deploying fix in a moment
[10:08] <ogra_> my device build id seems to be from the 14th with 203
[10:08] <ogra_> while others seem to have builds from the 19th
[10:08] <asac> ogra_: how can i install an individual combo of device and rootfs? is that easy?
[10:08] <ogra_> asac, thats documented somewhere on the internal wiki
[10:09] <asac> k
[10:09] <asac> well, as long as QA and LT knows how that would be good
[10:09] <asac> ogra_: so we didnt get a new device tarball update
[10:09] <Saviq> sil2100, great, thanks
[10:10] <ogra_> asac, *I* didnt ... i followed janis OTA instructions though ... seems davmor2 and brendand both had a newer tarball (we just checked in the meeting)
[10:10] <ogra_> they both flashed using u-d-f
[10:10] <ogra_> i'm just doing the same here
[10:11] <davmor2> ogra_: man don't wake me up like that ;)
[10:11] <ogra_> heh
[10:11] <ogra_> i didnt know you go to sleep after the meeting :P
[10:11] <sil2100> Saviq: could you retry to double check now?
[10:11] <davmor2> ogra_: yeah best way to dream up new ways to break the phone  ;)
[10:12] <ogra_> asac, can we make it mandatory for davmor2 to not sleep anymore ... we have enough bugs already :P
[10:12] <Saviq> sil2100, will do with a new silo soon
[10:12] <ogra_> davmor2, sleep -> post-rtm
[10:15] <davmor2> ogra_: it is post rtm that happened yesterday :P
[10:15] <ogra_> no no, rtm *started* yesterday :)
[10:15] <sil2100> It was just branching for RTM, that's different ;)
[10:18] <davmor2> hahahaha
[10:19] <om26er> mvo_, yes, sure
[10:41] <brendand> sil2100, hmmm i can't reproduce the music app failure
[10:41] <brendand> sil2100, though it seems very straightforward
[10:41] <brendand> sil2100, can we get a rerun?
[10:42] <sil2100> brendand: wait, on krillin?
[10:42] <ogra_> brendand, 204 just ran it
[10:42] <ogra_> failed the same way
[10:42] <sil2100> brendand: what image are you running?
[10:43] <sil2100> Yeah, it failed explicitly on my vanilla device
[10:43] <sil2100> So maybe your device has something I didn't have
[10:43] <sil2100> brendand: do you have music on your device? I don't remember if I had any mp3's when I was running myself
[10:44] <ogra_> wow the publisher flies today
[10:45] <ogra_> didnt take more than 15 for my dbus-property-service upload to send me the promoted to archive mail
[10:45] <brendand> sil2100, with the same error as in CI?
[10:45] <sil2100> brendand: basically yes
[10:46] <brendand> ok strange
[11:28] <bzoltan> sil2100:  I know pinging is evil :) and I risk a lot... but may I ask for a Silo?
[11:29] <ogra_> you evil pinger you !
[11:37] <Mirv> :D
[11:38] <Mirv> bzoltan: landing-009
[11:38] <sil2100> ;)
[11:40] <bzoltan> Mirv:  thanks... I windor which half is joke... the "sophisticated algorithm" or the "do not ping us"
[11:47] <Mirv> bzoltan: obviously "do not ping us", do not question our algorithm!
[11:47] <bzoltan> Mirv: :D
[12:03] <om26er> mvo_, Hey It fixes the issue I previously saw
[12:03] <om26er> i.e. I can install new apps now
[12:04] <mvo_> om26er: \o/
[12:04] <mvo_> om26er: thanks for confirming the fix
[12:04] <om26er> mvo_, it took me a while, I was having problems with upgrade (internet issues).
[12:09] <mvo_> np
[12:17] <popey> my mako screen never seems to go off
[12:26] <ogra_> sil2100, hmm, so i uplaoded dbus-property-service to utopic ... i assume i need to somehow push that into a silo now ? can the trainguards just sync that package from the archive or do i need a parallel upload ?
[12:27] <sil2100> ogra_: how did you upload it to utopic?
[12:27] <ogra_> dput ...
[12:32] <popey> Can anyone else confirm that the screen never goes off with mako #204 ?
[12:33] <sil2100> ogra_: and now you want the same in ubuntu-rtm, right?
[12:33] <ogra_> yeah
[12:35] <sil2100> ogra_: right, then you'll need to get this tested - fill in a landing with the dbus-property-service as source package and set target distribution to ubuntu-rtm/14.09
[12:35] <ogra_> k
[12:35] <sil2100> ogra_: just remember to change the series and versioning ;)
[12:35] <ogra_> sil2100, do there is no way to prevent me from the extra 2h of work then ?
[12:36] <sil2100> ogra_: well, to tell the truth you're a core dev, sooo! If you wish, you can basically anyway push directly to ubuntu-rtm straight away with dput
[12:36] <sil2100> As we have no power to stop you from doing so
[12:36] <dbarth> hi, can i get help on landing silo15?
[12:36] <sil2100> dbarth: what's up?
[12:36] <dbarth> hi
[12:37] <dbarth> i'v asked for qa signoff which i think i obtaind from om26er
[12:37] <sil2100> ogra_: the thing is, we need to be double-sure that it doesn't regress anything, and a silo makes life for QA testers in case it's something risky
[12:37] <dbarth> but now i see the silo has been touched by a build attempt or so
[12:37] <sil2100> dbarth: let me check the silo
[12:37] <sil2100> Oh?
[12:38] <ogra_> sil2100, well, that still means two source packages
[12:38] <ogra_> with different changelogs
[12:38] <ogra_> (well, at least different version lines)
[12:39] <ogra_> (beyond, well, i indeed want to be a good citizen)
[12:39] <sil2100> ogra_: for now yes, but I think we'll need to maybe still discuss this a bit, too bad cjwatson is not here
[12:39] <ogra_> sil2100, i think it would be really helpful if we could have one click imports when creating the silo or some such
[12:39] <sil2100> Sure
[12:39] <sil2100> I'll be working on that :)
[12:40] <ogra_> so it would just pull the source package from the distro automatically into the ppa without requiring extra uploading or extra source packages
[12:40] <Saviq> sil2100, ordering of prerequisites seems to have broken too https://ci-train.ubuntu.com/job/ubuntu-landing-017-1-build/21/console
[12:41] <mvo_> popey: seems to be working for me (with #204)
[12:41] <Saviq> sil2100, check those branches out and their prerequisites, the ordering is not good at all
[12:47] <popey> mvo_: ok, thanks
[12:48] <brendand> sil2100, if you can reproduce the music_app failure on krillin, can you paste me the error?
[12:49] <sil2100> brendand: sure, let me just hook up my device
[12:51] <ogra_> sil2100, hmmm ... another thing ... against what image do i test my rtm package now ?
[12:51] <ogra_> i dont have any rtm install for the device i'm testing on yet
[12:52] <bzoltan> sil2100: FYI the UITK landing is blocked by this -> https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.5/+bug/1360241
[12:53] <bzoltan> sil2100: I wonder why the llvm was again updated once it was reverted exactly because it messed up the UITK releases.
[12:54] <sil2100> bzoltan: ...great
[12:54] <sil2100> bzoltan: I remember seeing some llvm discussion somewhere, but can't remember now what it was about
[12:55] <Mirv> there is some complexity in that doko has been updating the llvm-toolchain itself, while mlankhorst has been updating Mesa to build either against LLVM 3.4 or 3.5
[12:56] <Mirv> so UITK hits the problem because mesa was now again put to use 3.5 https://launchpad.net/ubuntu/utopic/+source/mesa/+changelog
[12:57] <Mirv> bzoltan: pitti and tvoss just also raised it on #ubuntu-devel
[12:57] <Mirv> so apparently it affects others than UITK as well
[12:59] <Mirv> or maybe it was just Thomas supporting us and Martin having seen it before too
[13:05] <Saviq> sil2100, seems changelog generator is good again https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-017/+sourcepub/4368132/+listing-archive-extra
[13:13] <thostr_> can I get a silo for line 36 please?
[13:13] <bzoltan> sil2100: Mirv: it seems I can not reconfigure the silo9 after I added the -gles branch
[13:13] <sil2100> Saviq: yay \o/
[13:19] <sil2100> bzoltan: did you just add the branch now?
[13:19] <sil2100> bzoltan: or you mean you can no longer reconfigure at all?
[13:19] <bzoltan> sil2100:  yeps
[13:19] <sil2100> Ok, we need to reconf then, it's a new project
[13:20] <bzoltan> sil2100:  yes, it looks like it is UITK, but in fact it is not :)
[13:20] <sil2100> One moment, spreadsheet is breakish for me ;)
[13:22] <sil2100> bzoltan: done
[13:22] <bzoltan> sil2100:  thanks
[13:23] <dobey> sil2100, cjwatson: hi. i'm a little confused about the ubuntu-rtm thing. are we not going to be doing straight syncs from ubuntu -> ubuntu-rtm like we do for deb -> ubuntu?
[13:23] <ogra_> dobey, nope
[13:23] <dobey> :(
[13:24] <sil2100> dobey: not really, as everything needs to be double-tested before it lands for ubuntu-rtm
[13:24] <ogra_> sil2100, i think we can be lax wrt QA testing for landing in ubuntu though ...
[13:24] <ogra_> i.e. i guess it is emough iif you only get signoff and testing for rtm
[13:25] <ogra_> that might reduce the amount of extra work a bit
[13:25] <dobey> except that ubuntu is in feature freeze now
[13:26] <sil2100> bfiller: ok, it seems that silo 004 cannot be published since someone released telepathy-ofono in the meantime, so a rebuild is required...
[13:26] <sil2100> ogra_: right, true
[13:26] <bfiller> sil2100: ok, I rebuilt it last night
[13:26] <ogra_> you shoulld probably put that into a followup mail
[13:27] <bfiller> will do it again
[13:27] <dobey> and several projects have devel branches that get changes first, then those get proposed for landing into ubuntu, and then they'll have to be landed to ubuntu-rtm
[13:27] <ogra_> dobey, right
[13:27] <sil2100> dobey, ogra_: I might sound noobish here, but don't we have the standing FFe for touch apps again this cycle?
[13:28]  * sil2100 was so busy with the train that he might have missed it
[13:28] <ogra_> sil2100, i dont think so, thats why i asked about FF and FFes yesterday
[13:28] <ogra_> sil2100, i would suspect slangasek knows ... as a mmember of the release team
[13:29] <sil2100> Let's wait for him to get rid of all (some) of our doubts
[13:29] <sil2100> bfiller: strange situation, I wonder where that release came from...
[13:29] <dobey> and if landing to ubuntu and ubuntu-rtm get different version numbers generated, managing the MPs can be a bit annoying
[13:30] <bfiller> sil2100: it was in silo 9 I think and we were told to rebuild once that landed.. guess I didn't wait long enough
[13:30] <Saviq> trainguards, anything preventing silo 16 from publishing?
[13:30] <sil2100> Saviq: no no, moving on to that one now ;)
[13:31] <Saviq> sil2100, sorry, impatient ehre
[13:31] <sil2100> Saviq: sorry for taking so long!
[13:31] <Saviq> sil2100, so, is there a process for copying that to rtm yet?
[13:32] <Saviq> since I think unity8 falls under the "rtm-only" category
[13:32] <sil2100> Saviq: not yet, but I'll make the process much easier soon, and once cjwatson gets back I also have some even more 'rad' propositions
[13:33] <Saviq> sil2100, so I should really get this into a rtm silo after it lands? I assume it's ok to squash the MPs then?
[13:34] <sil2100> Saviq: yeah, so for now use new MPs, but just re-use the branches as they are
[13:34] <Saviq> sil2100, can't re-use branches can I? I'd need to retarget to rtm-14.09?
[13:35] <Saviq> sil2100, so file separate MPs for rtm
[13:35] <Saviq> sil2100, which is a significant task when I have 10 branches on average per landing
[13:35] <sil2100> Saviq: yes, new MPs, but I guess branches can stay the same?
[13:35] <Saviq> sil2100, yeah, that's not good for us, too many MPs
[13:35] <Saviq> with interdependencies and all, that will get fishy too soon
[13:35] <sil2100> Saviq: I'll make this automated soon, I mean, I'll try ;p
[13:36] <Saviq> sil2100, for now I'll go devel-style and use just one MP to land into rtm
[13:36] <Saviq> sil2100, I've an idea to talk to you about devel/staging branches, too, when you have time
[13:48] <bfiller> sil2100: so for silo 4 once we land it, then we have to make new MR's against rtm-14.09 brances and resubmit another request?
[13:49] <sil2100> bfiller: for now, yes, but this will be easier soon
[13:49] <mvo_> om26er: if you don't mind I will update line #31 that QA test now passed with image #204, is that ok?
[13:50] <om26er> mvo_, I think we are not in traincon-0 anymore so my ack doesn;t really matter. But yes its good I think
[13:51] <mvo_> om26er: aha, good to know, thanks
[13:59] <mvo_> sil2100: eh, I guess I should know this, but what does "Migration: One package at least is not available at the destination. click (0.4.31.1) is in no known space (and time).  (click)" mean exactly?
[14:00] <sil2100> mvo_: it meanst that it's not in release or -proposed yet - that's usually the case right after publishing
[14:00] <sil2100> mvo_: this means that the request has been copied to snakefruit and most probably copy2distro didn't yet run there to pick it up and push to the archive
[14:01] <sil2100> But it will switch to -proposed soon
[14:01] <mvo_> aha, ok. so nothing to worry about :)
[14:01] <mvo_> thanks!
[14:15] <dobey> are images not being built from ubuntu-rtm yet?
[14:16] <sil2100> They are
[14:16] <sil2100> cjwatson said there's a cron job building once per day
[14:17] <dbarth> sil2100: sorry, any update on silo 15?
[14:17] <kenvandine_> sergiusens, you have system-settings in silo 8, i'd like to get a landing today, what's the status of that one?
[14:18] <sergiusens> let me kill it
[14:18] <kenvandine_> thx
[14:18] <sergiusens> kenvandine_: was rejected
[14:18] <dobey> sil2100: hrmm. does one need to flash with a different channel now to get them?
[14:18] <dbarth> also if a trainguard is available silo 2 can be freed; we won't land that this week
[14:18] <sergiusens> Mirv: can you kill silo 9?
[14:18] <sergiusens> ooop
[14:18] <sergiusens> Mirv: silo 8!!!
[14:18] <sergiusens> off by one finger
[14:19] <sil2100> dobey: there's a ubuntu-touch/ubuntu-rtm/* channel set
[14:19] <dbarth> also you can clear line 12 of the spreadsheet, this landing went into another silo; the request is obsolete
[14:19] <sil2100> sergiusens: what do you need dead in that silo? The whole thing freed?
[14:19] <sergiusens> sil2100: yes
[14:19] <sergiusens> sil2100: cancel the landing
[14:19] <kenvandine_> sergiusens, thx
[14:19] <kenvandine_> haha
[14:19] <dobey> sigh :-/
[14:21] <dobey> sil2100: can landers just request syncs from ubuntu to ubuntu-rtm for landings?
[14:21] <ogra_> dobey, not yet
[14:22] <sil2100> dobey: not yet - and besides, you anyway have to double test it in a silo
[14:22] <ogra_> you need to do two landings currently
[14:22] <dobey> thostr_: ^^ :(
[14:23] <ogra_> dobey, as cjwatson said in his mail ... such cases like syncing will need more testing ... which people simply didnt help with over the llast two weeks
[14:24] <ogra_> it will come over time ...
[14:24] <sil2100> I'll have something working soon, but this will have to be +1'ed by cjwatson best
[14:24] <sergiusens> ogra_: in my defense, I asked and was told to do the branch dance
[14:25] <sergiusens> so wasn't interested
[14:25] <ogra_> sergiusens, well, you were one out of ... what ... five people ?
[14:25] <ogra_> :)
[14:25] <sil2100> ;)
[14:25] <sil2100> 5... good joke ;)
[14:25] <ogra_> if there had been 50 landings to test with instead of 5 ...
[14:25] <sergiusens> but I did present the use case ;-)
[14:25] <ogra_> yeah
[14:26] <ogra_> if only 30 oof the 50 testers had presented it too ...
[14:26] <sergiusens> ogra_: and I asked you what the process would be for only rtm too :)
[14:26] <ogra_> oh, wait ...
[14:26] <ogra_> there were only 5
[14:26] <ogra_> :P
[14:26] <sil2100> ;p
[14:26] <sergiusens> anyways, I thought the rtm archive was supposed to protect us from new syncs from debian or a new Qt; not an extra extra process for us
[14:27] <sergiusens> which is what I think most people thought of after malta
[14:28] <sil2100> I didn't invent the idea that things need to land in ubuntu first, but this makes sense in overall - and you need to remember that everything landing in ubuntu-rtm needs to be additionally tested by QA to make sure RTM is in best shape
[14:29] <sil2100> The idea was that ubuntu can have flaws and can have some regressions, but only the most-probably-regression-free landings are migrated to RTM
[14:30] <sil2100> Sync functionality will help out for sure, but even with it it will mean the sync will have to be restrictively tested before landing to ubuntu-rtm
[14:31] <ogra_> sergiusens, but it does that
[14:31] <ogra_> it protects us from QT landings and the like
[14:33] <sergiusens> the easiest way to solve these process issues is to have people making these process actually work with the process too
[14:34] <ogra_> and that will happen
[14:35] <sergiusens> ogra_: so lxc-android-config going to be MPed and siloed?
[14:35] <ogra_> android-tools you mean ?
[14:35] <ogra_> oh
[14:35] <ogra_> misread
[14:36] <sergiusens> ogra_: you rarely endure the pain ;-)
[14:36] <ogra_> sergiusens, why ?
[14:36] <sergiusens> so you see how painful it is :-)
[14:36] <ogra_> it will have to be siloed indeed
[14:38] <sil2100> It's best if you contact QA about that, since as I said - core-devs can anyway do what they want and upload what they want - I just want it to be made sure QA approves the given upload
[14:38] <ogra_> sil2100, btw, can i has rtm silo for line 35 ?
[14:42] <sil2100> ogra_: sure, done
[14:47] <dbarth> davmor2: hi, can i bother you with that silo15?
[14:47] <dbarth> i'm pinging everyone involved to see if i can just land that now that it's been tested
[14:47] <cyphermox> rsalveti: so anyway; there was a landing missing for mtp to rtm ^
[14:48] <cyphermox> this means it will pretty much be the time to upload NM too
[14:49] <davmor2> dbarth: we are out of traincon0 you should just be able to pass it as normal as far as I know unless you need it testing
[14:59] <Saviq> trainguards, I can has silo for line 38 please
[14:59] <Saviq> fginther, hey, got a moment?
[14:59] <fginther> Saviq, sure
[15:00] <Saviq> fginther, I wanted to chat with you about a certain special casing to autolanding jobs
[15:00] <Saviq> fginther, I came up with an idea to get a kind of hybrid between devel/staging branches and what CI train generally recommends
[15:01] <fginther> oh?
[15:01] <Saviq> fginther, it's probably interesting for airline, too, as the approach would nicely map there as well :)
[15:02] <fginther> Saviq, would a hangout work better then IRC?
[15:02] <Saviq> fginther, sure https://plus.google.com/hangouts/_/canonical.com/saviq
[15:13] <brendand> sil2100, are you there?
[15:13] <sil2100> brendand: yeah, just super busy
[15:13] <sil2100> AH CRAP
[15:13] <sil2100> Right, music ap!
[15:13] <sil2100> app even
[15:13] <brendand> sil2100, i pinged you
[15:19] <cyphermox> sil2100: can I haz silo for line 40?
[15:20] <cyphermox> a cheeseburger would be nice for lunch too; but it's a little early still
[15:22] <dbarth> davmor2: but there's a commnt i don't understand about app icons disappearing
[15:23] <davmor2> dbarth: sure 'ill have a look in a second then
[15:23] <dbarth> ok thanks
[15:28] <elopio> ping josepht, I need some help with https://code.launchpad.net/~ubuntu-testcase/ubuntu-autopilot-tests/ubuntu-experience-tests
[15:28] <elopio> it's autolanding the MPs. It should wait to go through the CI train to do the merges.
[15:29] <sil2100> cyphermox: suarz
[15:29] <cyphermox> suarz?
[15:29] <cyphermox> OH
[15:30] <cyphermox> ;)
[15:42] <josepht> elopio: looking
[15:46] <bzoltan> sil2100: ogra_: do you know if  the phablet-click-test-setup  have problems or is it just me? http://pastebin.ubuntu.com/8115187/
[15:46] <ogra_> bzoltan, i bet uitk was updated after your image was built
[15:47] <ogra_> and phablet-click-test-setup doesnt run apt-get update to make sure you stay on the same package versions
[15:47] <bzoltan> ogra_:  that 1.1.1208+14.10.20140822-0ubuntu1 UITK is not even released yet
[15:47] <ogra_> +archive/primary
[15:47] <ogra_> see the url
[15:47] <ogra_> seems to be thinking it is in the main archive
[15:48] <bzoltan> ogra_: that is bogus ... that version is what I have in the silo9 and it is far from being released
[15:48] <fginther> elopio, josepht, we can turn off autolanding now if this project is ready for ci-train
[15:50] <bzoltan> ogra_:  it is the 1.1.1188+14.10.20140813.4-0ubuntu1 what is the released UITK
[15:50] <elopio> fginther: that would be nice.
[15:50] <elopio> now, do you know what should I do with the main branch that has landed two branches that should go to the train? revert?
[15:51] <fginther> elopio, yeah those should be reverted to make sure the landing goes cleanly
[15:55] <ogra_> sil2100, seems hangouts are not very stable in europe today ... (just had a meeting and dropped out like 20 times ... other europeans too)
[15:55] <bzoltan> ogra_:  do you know who can tell what that phablet-click-test-setup does wrong? It is clearly a bug.
[15:55] <ogra_> bzoltan, well, i'm re-writing it anyway to use dbus calls instead of apt
[15:55] <ogra_> (for the developer mode)
[15:55] <bzoltan> \o/
[15:56] <ogra_> i might have to drop the feature to install packages from a local dir though ... and onyl allow PPAs and the archive
[15:56] <ogra_> i hope not to many people rely on that
[15:57] <sil2100> ogra_: worked fine for me, just finished another HO
[15:57] <ogra_> sil2100, well, last time you were the only european for whom it worked ... remember ?
[15:57] <ogra_> :)
[15:57] <sil2100> ogra_: we'll probably discuss some RTM things this meeting only
[15:57] <sil2100> Oh! :)
[15:57]  * ogra_ considers moving to poland
[15:57] <sil2100> Yeah, I've got some connections here and there, forgot about that
[15:58] <sergiusens> ogra_: only fginther relies on that
[15:59] <ogra_> sergiusens, well, he could dump a sudoers in place
[16:00] <sergiusens> ogra_: oh, I don't care about the solution; just make sure fginther knows or more than half the MPs will start to fail
[16:00] <fginther> ogra_, I hear you, we can do the local archive setup on the ci side if necessary
[16:01] <fginther> and already expect to be doing the sudoers setup
[16:01] <ogra_> cool
[16:02] <ogra_> yeah, sudoers should just give you everything you have today
[16:03] <brendand> sil2100, do you really need me in the landing meeting?
[16:03] <brendand> sil2100, i have a conflict
[16:03] <sil2100> brendand: no worries
[16:03] <sil2100> ;)
[16:03] <bzoltan> ogra_: do you have a suggestion how to get that tool back to life and convince it to download the existing UITK instead of the future version? It kind of blocks me from doing a silo validation...
[16:10] <tedg> sil2100, Could I get a silo for line 41 please?
[16:13] <bzoltan> ogra_:  the dpkg-query gives the correct version
[16:13] <ogra_> bzoltan, i dont think it is a version issue but an archive one
[16:14] <ogra_> it doesnt try to pull from the ppa
[16:14] <ogra_> where the package lives
[16:14] <robru> tedg: you got silo 10
[16:14] <tedg> robru, Thanks!
[16:14] <bzoltan> ogra_:  I am almost sure that it is bug related to how it figures out the version... that version does not exist anywhere else but in a silo9 and that tool has no idea about  that silo
[16:14] <charles> robru, thanks :-)
[16:15] <charles> s/robru/robru, ted/
[16:15] <bzoltan> ogra_:  it should not pull from a PPA, it should pull from the archive
[16:15] <ogra_> bzoltan, afaik it looks locally for the package version, then uses that version to look for the ap test package with the same version
[16:16] <ogra_> why would you want it to pull the last ap tests instead of the current ones ?
[16:16] <ogra_> the archive would only give you the old version
[16:17] <bzoltan> ogra_:  I do not .. I just want to run that command and see it doing whatever it used to do... it used to pull the archive version, always ... and the first thing I do is to wipe it off from the device
[16:17] <ogra_> well, the tool didnt change in months
[16:17] <bzoltan> ogra_:  I do not bother if it downloads the win95 install disks... as long the tool does not freak out and does not terminate
[16:18] <bzoltan> ogra_: I know it did not change ... but somehow it knows about a UITK version what does not exist... black magic?
[16:18]  * ogra_ notes down to take that into account when he does the re-write ... 
[16:18] <ogra_> ... "download win95 isos"
[16:19] <bzoltan> ogra_:  the phablet-click-test-setup I need only to pull the tests for the click apps... I have no idea why it downloads the UITK tests
[16:19] <bzoltan> :D
[16:19] <ogra_> bzoltan, it checks the installed version of UITK on your device
[16:19] <Wellark> hey, could somebody rip out the indicator-network branch from silo 007?
[16:20] <Wellark> oh, wait what..
[16:20] <ogra_> bzoltan, and tries to pull the package with AP tests for it ...
[16:21] <bzoltan> ogra_:  I see... I just flashed the device with --wipe ... but the UITK there is  from our staging PPA
[16:22] <ogra_> right
[16:22] <Wellark> ok, silo 7 fails to build
[16:22] <ogra_> so it tries to find that version
[16:22] <ogra_> but fails because it expects it to be in the main archive
[16:22] <Wellark> so, let's move the indicator-network branch from there to line 36
[16:22] <bzoltan> ogra_: okeeeey.. now the question is, what the staging UITK is doing on my device after a flash
[16:22] <Wellark> thostr_: why was the indicator-network branch put to an another silo?
[16:22] <ogra_> bzoltan, i bet it works if you use add-apt-archive to add the ppa and call apt-get update
[16:23] <ogra_> bzoltan, you installed it most likely
[16:23] <Wellark> I especially mentioned to Jussi that they all should go in together
[16:23] <robru> tedg: charles: you're welcome
[16:23] <bzoltan> ogra_: I did install it, but should not a flash clean up?
[16:23] <Wellark> is pitti around?
[16:24] <ogra_> bzoltan, --bootstrap fortmats the partitions ... --wipe just wipes user data
[16:24] <bzoltan> ogra_: uhhh...
[16:24] <ogra_> so without formatting you most likely had cruft left
[16:24] <thostr_> Wellark: the langpack one? that was already silo'ed by pitty
[16:24] <ogra_> just installing your new image on top
[16:27] <bzoltan> ogra_:  and the new image does not downgrade packages... I guess
[16:27] <rsalveti> ogra_: do you know if we have a changes ml for rtm?
[16:27] <brendand> sil2100, scenario - a silo lands in utopic buts fails on RTM (krillin)?
[16:27] <ogra_> rsalveti, i suspect LP must have something
[16:27]  * bzoltan does not know what flashing means in our dictionary 
[16:27] <rsalveti> https://lists.ubuntu.com/mailman/listinfo/Rtm-14.09-changes
[16:27] <rsalveti> it seems
[16:28] <rsalveti> the 09 here wasn't a good idea I think :-)
[16:28] <rsalveti> will for sure stay until 10
[16:28] <robru> tedg: charles erk wait
[16:28] <robru> ugh, nm
[16:28] <robru> not awake yet.
[16:28] <sil2100> brendand: then it gets rejected, the upstream needs to fix it and then land the fix to utopic and land the whole thing (base + fix) to RTM again
[16:28] <charles> :)
[16:29] <brendand> sil2100, will it mean a greater risk of running out of silos?
[16:30] <sil2100> brendand: sadly, yes... we might need to bump the silo number anyway, since even in the normal workflow with the new 'QA signs-off every landing' would really become a bottleneck
[16:31] <jdstrand> pmcgowan: do you know of any issues with online account creation on r203 of the emulator? I don't know what version of the phone image that is
[16:32] <pmcgowan> jdstrand, I do not know, emulator is a couple versions ahead
[16:32] <jdstrand> pmcgowan: ok, but have you heard anything about online account creation not working?
[16:33] <Wellark> ok.. pitti is away :(
[16:33] <Wellark> could we now just do the dance?
[16:33] <jdstrand> I go to Accounts in system settings and click on something, and nothing
[16:33] <Wellark> there is one krilling bug fixed also
[16:33] <pmcgowan> hmm dbarth^^
[16:33] <pmcgowan> jdstrand, sometime recently we refactored all of that, so OA was part of settings
[16:33] <pmcgowan> but working on the devices
[16:37] <Wellark> sil2100: you have the power, right? could you please move the indicator-network MP from silo 7 to line 36 on the landing sheet
[16:37] <jdstrand> alright, let me try a new image
[16:37] <robru> boiko: i tried assigning your row 42 but one of the URLs is not an MP, please fix
[16:37] <Wellark> there has been no activity on silo7 for 6h
[16:37] <Wellark> and it's blocking my landing
[16:38] <boiko> robru: let me see
[16:38] <Wellark> and pitti is afk
[16:39] <robru> Wellark: looking
[16:40] <boiko> robru: fixed
[16:40] <bzoltan> ogra_: I did bootsraped the device .. still all PPAs are there
[16:40] <ogra_> bzoltan, hmm sounds liek a bug with ubuntu-device-flash then
[16:40] <bzoltan> ogra_:  I clean up manually ... but that is not cool. The phablet-flash should flash the device and not shoulder patting it
[16:41] <ogra_> bzoltan, file a bug and let sergiusens know
[16:41] <ogra_> bzoltan, i assume thats mako ?
[16:41] <bzoltan> ogra_: yes
[16:42]  * jdstrand creates an r205 emulator to try the online accounts there
[16:42] <bzoltan> ogra_:  I never thought that the flash is _not_ flashing ... that sounds strange. I would expect a dd kind of fs dump
[16:43] <ogra_> well, --bootstrap or --wipe should clan the partitions up at least
[16:43] <ogra_> *clean
[16:43] <ogra_> werid that neither does it for you
[16:44] <Wellark> robru: thanks!
[16:46] <bzoltan> ogra_: given that problem I am not so happy to test the UITK landing silo with a bogus system...
[16:48] <ogra_> sil2100, hmm, so how do i get my dbus-property-service into the silo now, the PPA page definitely hs a wrong dput line
[16:48] <sil2100> hah, yeah, there's a bug for that I guess! ;)
[16:49] <ogra_> whats the workaround ?
[16:49] <sil2100> ogra_: I wonder if the current dput you have will let you upload actually! First of all check your /etc/dput.cf at the [ppa] section
[16:49] <ogra_> oh, i didnt think of that
[16:49] <ogra_> yeah
[16:50] <sil2100> ogra_: you need to make sure incoming is just ~%(ppa)s
[16:50] <sil2100> ogra_: then you can dput to ppa:bla-bla/ubuntu-rtm/blabla
[16:50] <bzoltan> ogra_:  the flash clearly did not flash the partition .. I have removed the UITK with --force, and after the flash the package was not there.
[16:50] <robru> Wellark: ok line 36 got silo 12 for you with indicator-network
[16:51] <robru> sorry that took so long
[16:51] <bzoltan> sergiusens:  what is the way to really flash my device.. like for real :)
[16:51] <Wellark> robru: np.
[16:51] <Wellark> robru: did you move the i-network branch from silo 7 to there as well?
[16:51] <Wellark> I would like to land it on the same go
[16:52] <Wellark> as it might bitrot if it is left unmerged
[16:52] <Wellark> and it's totally isolated change so there is no side effects from removing it from silo 7
[16:53] <bzoltan> sergiusens:  ogra_: I am flashing my device like 10 times a day .. could that be a problem?
[16:54] <ogra_> bzoltan, if it doesnt get cleaned up it could indeed
[16:54] <robru> Wellark: yeah pitti's thing is a very simple translation fix. can just slip in anywhere
[16:54] <bzoltan> ogra_: should I clean up manually?
[16:54] <dbarth> jdstrand: the refactored code landed in r199+
[16:54] <ogra_> bzoltan, until ubuntu-device-flash is fixed ...
[16:55] <ogra_> bzoltan, but make sure sergiusens knows about the issue
[16:55] <bzoltan> ogra_:  I did it lasttime with the transformers :) is there a function in recovery mode or in the bootloader?
[16:56] <dbarth> jdstrand: i have re-created facebook accounts all of this week with the new code
[16:56] <ogra_> no idea
[16:56] <Wellark> robru: please slip it to silo 12 then :)
[16:58] <jdstrand> dbarth: trying again with the latest emulator
[16:58] <ogra_> 	[~ci-train-ppa-service/ubuntu-rtm/landing-001/14.09] dbus-property-service 0.5 (Accepted)
[16:58] <ogra_> \o/
[16:59] <jdstrand> dbarth (and pmcgowan): ok, seems to be working with latest emulator image. thanks
[16:59] <robru> Wellark: oh I did that already ;-)
[17:01] <dbarth> jdstrand: cool
[17:01] <robru> tedg: charles: that was awful fast! did you really test silo 10?
[17:02] <davmor2> dbarth: could you have a look at something from that ppa please.  I just setup a fresh u1 account and the account was setup but I was back at the settings app not accounts app
[17:02] <charles> robru, yes, I was the one who tested it
[17:02] <robru> ok...
[17:02] <charles> robru, I wanted to make sure it goes through today, and also it's a very small patch :)
[17:03] <charles> basically you fake the power level on the bus and if the fix worked, the icon changes color
[17:03] <charles> so once you install the deb it's a 30 second test
[17:04] <robru> charles: haha, ok
[17:06] <charles> -Standards-Version: 3.9.2
[17:06] <charles> +Standards-Version: 3.9.5
[17:06] <charles> tedg, ^
[17:10] <sil2100> o/
[17:13] <Wellark> robru: thanks!
[17:14] <robru> Wellark: you're welcome!
[17:17] <cyphermox> robru: do you know how I would go about uploading mtp to an ubuntu-rtm ppa now?
[17:17] <ogra_> cyphermox, you need to hack your dput.cf
[17:18] <cyphermox> ogra_: ah, right
[17:18] <ogra_> cyphermox, http://paste.ubuntu.com/8115812/
[17:18] <ogra_> cyphermox, then i did:
[17:18] <ogra_> ogra@styx:~/Devel/packages/dbus-property-service-0.5$ dput ppa:ci-train-ppa-service/ubuntu-rtm/landing-001 ../dbus-property-service_0.5_source.changes
[17:19] <cyphermox> yeah, I figured you had to do something like that
[17:19] <cyphermox> I had the dput command already
[17:19] <ogra_> (note the ubuntu-rtm on the url)
[17:19] <cyphermox> didn't remember the fact that incoming for the PPAs was specifying ubuntu
[17:20] <cyphermox> ogra_: thanks
[17:20]  * ogra_ wonders if the bot wwill ever announce the successful build of dbus-property-service
[17:21] <ogra_> it is done since a while
[17:21] <cyphermox> ogra_: my dput.cf was already correct
[17:21] <ogra_> oh
[17:21] <ogra_> :)
[17:21] <cyphermox> I still get a message from LP saying that the distroseries can't be found
[17:21] <ogra_> what did you put in changelog ?
[17:22] <ogra_> shoudl be s/utopic/14.09/
[17:22] <cyphermox> AH
[17:22] <cyphermox> that would be it
[17:22] <ogra_> (i only found that out by weeding through the ubuntu-rtm changes ML )
[17:22] <cyphermox> couldn't it just have been the same as for utopic?
[17:23] <ogra_> utopic-rtm ? :)
[17:23] <ogra_> that what i had initially :)
[17:23] <ogra_> *that's
[17:23] <cyphermox> no, I meant, I think it could have been left as just "utopic"
[17:23] <davmor2> dbarth: so silo 15 is okay except for that u1 account that closes the account window after it complete creation there is no missing aps
[17:23] <cyphermox> but if it wasn't, it has to be because there was a good reason not to
[17:23] <ogra_> ah, yeah, perhaps ...
[17:23] <ogra_> well, colin could tell you
[17:24] <cyphermox> well, I kind of see why
[17:24] <cyphermox> a release won't necessarily be "utopic"
[17:25] <cyphermox> it's whenever the release happens really
[17:26] <davmor2> dbarth: hey dude did you get my last messages?
[17:26] <cyphermox> should I version in a special way?
[17:26] <ogra_> i didnt
[17:27] <cyphermox> ok
[17:27] <bzoltan> ogra_:  could it be a problem that afterthe flash I do not do the wizard, but override it with a phablet-config  welcome-wizard --disable?
[17:27] <cyphermox> infinity: around?
[17:28] <davmor2> ogra_: can you see this I'm concerned that the network I'm on is too flaky
[17:29] <cyphermox> ogra_: did your stuff first land into ubuntu and then you did a new upload to another silo for rtm or are you using a different process?
[17:30] <ogra_> cyphermox, i did a direct upload to ubuntu, added a spreadsheet line and did a silo upload
[17:30] <ogra_> (silo for rtm)
[17:31] <cyphermox> with the same changelog except for the distro?
[17:31] <ogra_> bzoltan, that shouldnt have any influence on th flashing process, no
[17:31] <ogra_> cyphermox, right
[17:31] <cyphermox> omg
[17:31] <bzoltan> ogra_:  OK
[17:32]  * cyphermox -> lunch
[17:48] <ogra_> err, what ?
[17:48]  * ogra_ checks what line 28 is
[17:50] <ogra_> robru, ^^ that sounds buggy ... line 28 is the just landing former line 35, seems the rows changed and the both takes that as a new landing request
[17:50] <ogra_> *bot
[17:54] <fginther> elopio, FYI, autolanding for ubuntu-experience-tests has been disabled, I did the job attempting to merge another MP and aborted it, it did leave the MP in a needs-review state
[17:54] <fginther> elopio, https://code.launchpad.net/~canonical-platform-qa/ubuntu-autopilot-tests/launcher/+merge/231473
[17:55] <elopio> ack, thanks fginther.
[17:57] <elopio> I think it's ready now.
[17:57] <robru> ogra_: yeah it's a bug, but it's not because the line changed. The bot indexes landings by the A column, not by the line number, because we knew line numbers would jump around anyway. The real issue is that sometimes landed requests don't get marked as landed but instead are left looking like new requests, and that is just some mysterious spreadsheet problem
[17:57] <robru> that i haven't been able to find. The bot has no way to discern "landed things that are incorrectly marked as new landings" from "actual new landings" and so dutifully reports the incorrect status to the channel.
[17:58] <ogra_> robru, ah, right ... well, the spreadsheet doesnt really recognize the related silo anymore for line 28
[17:59] <ogra_> shouldnt the status column still show it until i merge and clean ?
[18:00] <robru> ogra_: oh i merged it for you, so the landing is really done. Somehow the spreadsheet just loses the status though.
[18:00] <ogra_> robru, oh, thanks :)
[18:00] <robru> ogra_: you're welcome ;-)
[18:00] <ogra_> yay, my first rtm landing
[18:01] <robru> Yay!
[18:08] <ogra_> robru, hmm, do you know if we have an rmadison for ubuntu-rtm ?
[18:09] <robru> ogra_: I'm not aware of it... I'm also not aware of how to actually install rtm PPAs into a system...
[18:09] <ogra_> well, you need to have an rtm image installed for that
[18:09] <ogra_> then its not different to ubuntu
[18:10] <robru> Ahhhhhhhhhhhhhh, so the same ppa:foo yell scheme just works? Hmmmmmmm
[18:10] <robru> *url
[18:10] <ogra_> it should, yeah
[18:16] <bfiller> robru: silo 1 and 11 can be published again - I fixed the non-approved MR's
[18:17] <robru> bfiller: thanks
[18:48] <ralsina> robru: can you assign a silo for row 36? I need to test this before I EOD
[18:50] <robru> ralsina: yeah I tried to already but there's no MP in there. you need to fix the request before I can assign it
[18:50] <ralsina> oops
[18:51] <ralsina> robru: I pasted the testplan over the branch it seems. Fixed now, thanks!
[18:52] <robru> ralsina: ok you're in silo 1 now!
[18:56] <infinity> cyphermox: Am now, sort of.  Just got into Portland.
[18:58] <robru> infinity: ah so debconf is starting today? wasn't sure if it was today or monday.
[19:00] <sergiusens> bzoltan: ogra_ if "factory reset" doesn't work, it's not an ubuntu device flash problem but an system-image-upgrader script one
[19:01] <infinity> robru: The conference starts tomorrow morning, I believe, but I travelled today.
[19:02] <bzoltan> sergiusens:  how to do factory reset?
[19:02] <robru> infinity: makes sense, also explains why steve isn't around. have fun!
[19:02] <infinity> Yeah, Steve's going to be remarkably busy, I expect.
[19:04] <sergiusens> bzoltan: open system settings; look at the bottom
[19:05] <bzoltan> sergiusens: ahh, from the UI. Cool, thanks. I will try that. I wonder why the flasher did not tell that the job was not successful
[19:06] <sergiusens> bzoltan: because it's decoupled
[19:07] <brendand> robru, all rtm silos need QA signoff
[19:07] <sergiusens> bzoltan: once the ubuntu logo starts spinning; that's it; for krillin we are switching to fastboot only where we have a channel to get feedback
[19:07] <brendand> robru, is there any way to enforce that in the spreadsheet?
[19:08] <bzoltan> sergiusens: I would consider it a bug. I expect to have the 204 image after a successful bootstrapped flashing and in fact I have the 203.
[19:08] <brendand> robru, well not exactly enforce but make sure any silo targetted at RTM is set automatically to QA signoff required
[19:08] <sergiusens> bzoltan: I need full logs and a bug report
[19:08] <bzoltan> sergiusens:  what logs?
[19:08] <sergiusens> bzoltan: /cache/recovery logs and the output of the flash
[19:08] <robru> brendand: Ooooooooooh right i forgot, sorry for letting that one through
[19:09] <brendand> robru, have any landed without our signoff?
[19:09] <robru> brendand: just have to make sure the column says 'required'...
[19:09] <robru> brendand: just one, it was ogra_ s
[19:12] <ralsina> robru: can you reconfigure silo 1? sergiusens just piggybacked
[19:12] <brendand> robru, bad ogra :)
[19:12] <bzoltan> sergiusens:  Flash output i shere http://pastebin.ubuntu.com/8116521/ the recovery directory is ~400MB, where should I put it?
[19:12] <robru> brendand: well, bad me, I'm the one who got publish
[19:12] <sergiusens> bzoltan: I won't look at it now, sorry; need a bug
[19:13] <bzoltan> sergiusens:  I can make a bug, but it will not help much :) "flasher does not flash"
[19:15] <robru> ralsina: done
[19:16] <sergiusens> bzoltan: if your recovery is 400MB that's a problem; how did you do that?
[19:16] <sergiusens> bzoltan: I said the logs from there; not every damn file
[19:17] <bzoltan> sergiusens:  I do not anything... I falsh, I test, I flash I test... lots of it, like 10 times a day
[19:18] <cyphermox> infinity: this was about whether it was possible to copy a package from the archive to a silo to let it eventually get to ubuntu-rtm; and if it was something I could do myself, besides doing a new upload
[19:19] <infinity> cyphermox: Entirely possible, but only advisable if you're sure the dependencies will be satisfiable.
[19:19] <cyphermox> ok
[19:19] <infinity> cyphermox: Since part of the point of an archive fork it that libraries may get out of sync and recompiles will be necessary moving from A to B.
[19:19] <cyphermox> yes of course
[19:20] <infinity> cyphermox: As for being something you can do yourself, only if you have upload rights to the silo PPA, which not many do, IIRC.
[19:20] <infinity> copy == upload, same permissions.
[19:20] <ogra_> core devs all should have upload rights
[19:20] <infinity> ogra_: Is that true?  It certainly hasn't always been so.
[19:21] <cyphermox> infinity: ack. well, I already did a new upload for mtp so it's not an issue atm
[19:21]  * infinity looks at a random silo.
[19:21] <cyphermox> but I did upload it directly to silo 2
[19:21] <infinity> ogra_: Unless someone's pulled some magic, the only people who can upload are this tiny set: https://launchpad.net/~ci-train-ppa-service/+members
[19:22] <ogra_> infinity, hmm, i might be wrong
[19:22] <infinity> ogra_: Note, we're talking copy/upload to silos, not to ubuntu-rtm directly.
[19:22] <ogra_> but i thought that was the case ...
[19:22] <ogra_> yes
[19:23] <ogra_> for the normal silos core-dev should have upload rights
[19:23] <ogra_> not sure if for rtm thouh
[19:23] <infinity> I'm not sure I disagree with your "should", but I can tell you they can't. ;)
[19:24] <infinity> Even the PPA descriptions spell that out: "Only bots and admins have access".
[19:24] <ogra_> actually citrain-landers should have upload rights there ... how else would you get non MPed source ackages your build needs into the silo
[19:27] <infinity> cyphermox: Anyhow, you're one of the few in the magic group that can upload (as you've noted by uploading), so it's as simple as a copy-package (with binaries) to get something from ubuntu to a PPA.
[19:27] <ogra_> robru, so WRT that mail thread, does the "merge and clean" step behave if the same set was already merged in an utopic landing when i use the same MP for rtm ?
[19:27] <ogra_> robru, that was never clear to me in the whole discussion
[19:28] <robru> ogra_: no you can't use the same mp because it will have the wrong target. You need to have a new mp. As far as i know it should work just fine to have two MP's with the same source branch, CI train will merge it correctly to both targets as each silo is merged
[19:29] <ogra_> ah, k ... so a bit more paperwork then
[19:29] <ogra_> but less bad than it sounded in the beginning
[19:31] <ogra_> robru, well ... i meant the merging back of the code into the source branch ... if the ubuntu MP gets merged, the code is in the source branch ... if then the rtm MP gets merged, what does CI train do with the source branch ? does it notice the code is there already ?
[19:31] <robru> ogra_: what? Merging doesn't touch the source branches... Just targets.
[19:32]  * ogra_ doesnt get it ... 
[19:32] <ogra_> you said i can use the same source branch but two MPs
[19:32] <robru> ogra_: yes...
[19:32] <ogra_> these MPs need to get merged back somehow
[19:33] <ogra_> into their source branch
[19:33] <robru> ogra_: are we using the same terminology? Source branch is the new code, not the trunk
[19:33] <ogra_> (trunk)
[19:36] <ogra_> robru, so after all what you say i cant use trunk but need a trunk and an rtm branch ... completely separate ... this seems to not be what you just said on the ML
[19:36] <robru> ogra_: i don't understand in what context trunk is called source? You wrote some code, you pushed a branch. That is the source of your new work. You propose it both to trunk and also to rtm. Assign both to separate silos, build simultaneously. When merging, one merges to trunk, one merges to rtm
[19:37] <sergiusens> robru: on the next MP you will have an out of date unmergeable branch
[19:37] <sergiusens> it would only work for the first MPs
[19:37] <sergiusens> or it will break the changelog horribly
[19:37] <ogra_> right, how do you keep trunk and rtm in sync ?
[19:38] <sergiusens> why can't we do what I propose?
[19:38] <ogra_> sergiusens, yeah, i would like that far more ... only actual rtm MPs would need a branch then
[19:38] <sergiusens> target the MP to utopic; mark it as a forward por to rtm by grabbing the sourcepackage you build and dput it to the right silo wth the ammended packaging version
[19:39] <ogra_> dont even dput it ... that should be an automated copy based on a checkbox you can chek
[19:39] <sergiusens> ogra_: well cjwatson advised to change the packaging version if we rebuild the binary
[19:39] <ogra_> right, have a bot do that
[19:40] <sergiusens> ogra_: oh, I expect the bot to do the dputting and tagging
[19:40] <ogra_> mangle the version, re-sign ... done
[19:40] <sergiusens> never questioned that :-)
[19:40] <ogra_> ah
[19:40] <ogra_> then we are on the same page
[19:40] <sergiusens> ogra_: ci train does an actual dput today :-P
[19:40] <ogra_> well, that was actually how i expected it to work when i heard it first
[19:41] <ogra_> so that you only need speacial branches when you actually do something not for ubuntu
[19:41] <ogra_> with the current setup we need to duplicate all branches for no use
[19:41] <robru> ogra_: sergiusens... Guys, guys, guys. Why do you want to inconvenience the computers so much? Can't you just show them some respect and do the work for them? ;-)
[19:42] <ogra_> heh
[19:43] <sergiusens> robru: as long as it's not me I'm fine
[19:43] <sergiusens> :-)
[19:43] <robru> ogra_: yeah i agree the current arrangement is not well implemented, I'm not sure how we can make it better. CI train code is really difficult to modify, it hurts me even to read it.
[19:43] <robru> I mean i hear your proposal but i have no idea how to make the train actually do it
[19:44] <ogra_> robru, well, i belive we have the right bits and pieces in launchpadlib for shoveling stuff between PPAs ... all it would need would be the version mangling and re-signing part
[19:44] <robru> ogra_: yeah that sounds hard to me ;-)
[19:44] <ralsina> robru: reconfigure silo 1 again, sorry, one package is not ready to land today
[19:44] <robru> ralsina: OK one sec
[19:45] <sergiusens> robru: we all have that problem with the tasks we have :-P
[19:46]  * ogra_ doesnt ... my problem is that i cant look in the other direction for a second before new issues pop up nobody has brought up before 
[19:46] <ogra_> (talking about developer mode ... it seems ot breed issues like rabbits)
[19:49] <rsalveti> ogra_: one bad side effect of landing the same branch on ubuntu and rtm with mrs on different days is that the upstream version will be different though
[19:49] <ogra_> yeah
[19:49] <rsalveti> not an issue necessarily, just harder to check later on the differences between both distros
[19:49] <ogra_> i think the PPA copy would be a lot saner
[19:50] <rsalveti> yup
[19:50] <rsalveti> src package copy in a ppa, DONNE
[19:50] <rsalveti> DONE
[19:50] <rsalveti> if it fails, upload a new fix with ~rtm1/2/3/4
[19:50] <rsalveti> or similar
[19:50] <rsalveti> at least makes it way easier to understand what is the upstream version
[19:52] <sergiusens> rsalveti: the idea was to use something like a backport version
[19:52] <sergiusens> from yesterdays conversation
[19:52] <sergiusens> which I tried to summarize in the email I sent yesterday
[19:52] <rsalveti> right, but if you create 2 mrs, that's not going to be the case
[19:53] <sergiusens> rsalveti: nah, to MRs is a bad idea
[19:53] <rsalveti> unless you force to change the changelog
[19:53] <sergiusens> rsalveti: we can change the source package name too
[19:53] <sergiusens> :-)
[19:53] <rsalveti> right
[20:12] <brendand> robru, where is the rtm channel? rtm images?
[20:13] <brendand> robru, found it
[20:18] <robru> bfiller: got you silo 6
[20:20] <brendand> robru, do you know when krillin is becoming available on the main image server?
[20:21] <robru> brendand: I heard "not before monday", other than that, no idea
[20:21] <brendand> robru, ok we might be unblocked soon then
[20:21] <robru> brendand: just be aware that "not before monday" is different than "on monday" ;-)
[20:21] <brendand> robru, yes :)
[20:22] <brendand> robru, but everyone should be aware that QA are currently blocked on being able to test silos for RTM
[20:23] <robru> brendand: are we officially blocking on krillin then? surely for some silos testing on makos is good enough for today?
[20:24] <brendand> robru, the official line is yes - but if it's not available well...
[20:24] <brendand> robru, we might have to have a plan b
[20:26] <robru> brendand: hm, ok.
[20:27] <brendand> robru, i don't think anything will land in RTM today
[20:27] <robru> brendand: well, that's fine with *me*....
[20:28] <robru> brendand: some devs might be annoyed by that
[20:28] <robru> brendand: anyways, I gotta take lunch, brb
[21:53] <popey> rebooted my phone and it looks like this... http://popey.mooo.com/screenshots/device-2014-08-22-225321.png
[21:53] <popey> something amiss
[21:56] <robru> popey: ahhhhhhhhhhhhhh yeah, we ported Null Launcher to the phone. https://play.google.com/store/apps/details?id=com.notriddle.null_launcer&hl=en&referrer=utm_source%3Dgoogle%26utm_medium%3Dorganic%26utm_term%3Dnull+launcher&pcampaignid=APPU_Wrz3U8TUFMT2iwLD_oCgAw
[21:56] <popey> rebooted and now it's back
[21:56] <popey> I suspect network problem.
[22:36] <Saviq> fginther, if you're still around, I also had another proposal for citrain that could be interesting for you too
[22:36] <Saviq> bug #1359667
[22:38] <sergiusens> Saviq: ths is more MP related, instead of ci train, right?
[22:38] <Saviq> sergiusens, no, actually
[22:39] <Saviq> sergiusens, immediate use case is .pot generation during CI source package builds
[22:39] <Saviq> sergiusens, having them for every branch would just pollute the changelog
[22:39] <Saviq> s/changelog/commit/
[22:39] <sergiusens> Saviq: can't you just add that to debian/rules?
[22:40] <sergiusens> for the source package
[22:40] <Saviq> sergiusens, no, because then it doesn't end up in trunk
[22:40] <Saviq> sergiusens, so doesn't end up in translations.launchpad.net
[22:40] <sergiusens> Saviq: right, that was my followup :-)
[22:40] <sergiusens> Saviq: hooks for bzr would be ideal if it were like git and server side
[22:41] <sergiusens> bonus points for git :)
[22:41] <Saviq> sergiusens, well, still that's not something that should happen every push or something, only before release, which is what crain does / airline will
[22:41] <Saviq> do
[22:42] <sergiusens> Saviq: well updating the pot won't get the po's in time; but I see where you are trying to get to
[22:43] <Saviq> sergiusens, with us not pushing to trunk until release they never will
[22:43] <Saviq> sergiusens, but also with langpacks fortunately that's not a problem
[22:43] <sergiusens> right
[22:45] <Saviq> sergiusens, not a solution for clicks unfortunately, them + train + translations don't seem to mix well
[22:45] <Saviq> unless they do staging and translations for it
[22:46] <sergiusens> Saviq: I gave Ursinha a crash course on clicks; so it eventually will be airline material
[22:46] <Saviq> sergiusens, well yeah, but what I mean is that either we don't push to trunks until release or we get translations for trunks in time
[22:46] <sergiusens> but I don't want to pack train with responsibilities if it means delaying the airline
[22:47] <sergiusens> Saviq: I don't disagree; I just wish it were easier
[22:47] <sergiusens> :-)
[22:48] <Saviq> sergiusens, I had an idea I discussed today with fginther and sil about a kind of hybrid staging approach, which could actually allow for translations for non-langpacked projects to happen, too
[22:49] <Saviq> I'll write it down in a bug on Monday so that we can discuss it, but apparently it wasn't completely crazy
[22:49] <fginther> Saviq, I'm past eod, but I'll catch up on this later tonight. We can discuss further on Monday too
[22:49] <Saviq> fginther, no worries, not really pinging you
[22:50] <Saviq> fginther, have your weekend
[22:50] <fginther> Saviq, you too!