[07:21] <Saviq> soo if I want something landed in utopic, do I need to rebuild/retest?
[07:35] <sil2100> I... I'm not sure yet ;p But you need to rebuild for sure, not sure if the infra is switched already
[07:36] <didrocks> sil2100: maybe try to dput something just for test in a silo for utopic?
[07:36] <didrocks> and see if it builds
[07:36] <didrocks> but on the infra you need to free the silo
[07:36] <didrocks> and reassign
[07:36] <didrocks> settings series to utopic
[07:37] <mardy> asac: hi! Did you hold that famous meeting yet? :-)
[07:37] <sil2100> didrocks: ok, let me test it myself then ;)
[07:46] <sil2100> didrocks: yeah, all seems to work ok in this regard - should we poke upstreams to fork their trunks to trusty branches?
[07:46] <sil2100> didrocks: or should we wait for the SRU-ones to land in trunks first?
[07:51] <didrocks> sil2100: for stuff that are in SRU mode, let's have them proceeded into -updates first I would say
[07:51] <didrocks> sil2100: otherwise, trunk == utopic for now I would say
[07:51] <didrocks> sil2100: want me to change the spreadsheet to use utopic by default?
[07:52] <Mirv> I think utopic by default would make sense, SRU:s are a separate thing
[07:52] <sil2100> didrocks: yes, I think that makes sense
[07:53] <didrocks> ok, changing, one sec
[07:53] <sil2100> And yeah, the good thing about CITrain is also that actually dividing where 'trusty' commits ended and where 'utopic' started is easily doable
[07:53] <sil2100> ;)
[07:54] <didrocks> done
[07:54] <didrocks> if you need a SRU, ensure that you change the series to "trusty"
[07:54] <didrocks> when assigning a silo
[07:55] <didrocks> remember that the block is per release/component
[07:55] <didrocks> (not only by component)
[07:55] <didrocks> so, we have a way to exit if upstream which are blocked in a SRU wants to land something else :)
[08:00] <Saviq> sil2100, didrocks, so I should rebuild the silo to land in U? or do you need to reconfigure first?
[08:00] <sil2100> didrocks: indeed :) But what about merge targets? Since if someone that's blocked on an SRU landing wants something else landed in U, it's troublesome as the both the SRU and the U landing would target the same trunk branch
[08:00] <didrocks> Saviq: we will remove and reassign a silo for you
[08:00] <sil2100> Saviq: I'll reconfigure your silo and will ask for a rebuild
[08:01] <Saviq> sil2100, thanks
[08:01] <didrocks> sil2100: you have to remove and reassign, I protect, on purpose on series change IIRC
[08:01] <didrocks> hum, maybe not with the prepare job
[08:01] <didrocks> sil2100: you can try the prepare job, (but not in reconfiguration mode)
[08:02] <didrocks> let me knows if this work
[08:16] <Saviq> didrocks, no worky https://ci-train.ubuntu.com/job/landing-007-1-build/26/console
[08:18] <Saviq> didrocks, and CI-SNCF didn't ping me about the failed job, that expected?
[08:18] <sil2100> huh
[08:18] <sil2100> What the heck is that
[08:19] <Saviq> something doesn't know about utopic
[08:19] <didrocks> Saviq: fixed, please retry
[08:20] <didrocks> let me see why the bot didn't ping, maybe it's just the double rsync latency
[08:20] <didrocks> Saviq: ah no, it's just that the status isn't updated, all issues with jenkins
[08:20] <Saviq> didrocks, kk
[08:20] <didrocks> Saviq: like, if there is a crash, I'll need to hook something up telling "infra issue"
[08:21] <didrocks> Saviq: anyone, just retry now :)
[08:21] <didrocks> anyway*
[08:21] <Saviq> already done
[08:23] <Saviq> didrocks, https://ci-train.ubuntu.com/job/landing-007-1-build/27/console
[08:24] <didrocks> ah, we need the debootstrap
[08:24] <didrocks> hum
[08:24] <didrocks> we don't have a job for that though and don't have ssh access to the machine
[08:24] <didrocks> sil2100: interested in doing that? let's chat during the meeting
[08:25] <didrocks> Saviq: mind waiting a little bit so that we can do it properly?
[08:25] <Saviq> didrocks, sure, let me know when you need a guinea pig
[08:25] <didrocks> yeah ;)
[08:27] <sil2100> Let's chat on the meeting :)
[09:27] <sil2100> Saviq: so, I think you'll still have to wait a bit :)
[09:53] <dbarth> Mirv: ping? hi, this is about line 37
[09:53] <dbarth> wondering how to land that
[09:56] <Mirv> dbarth: you could land it to utopic series now that it's open. maybe check with bzoltan1 on how trusty SDK updates are supposed to be done - SRU:s or PPA
[09:56] <bzoltan1> Mirv:  PPA
[09:57] <Mirv> dbarth: ok, so then just to a normal landing as soon as normal landings are possible to utopic, and a trusty version can be done via https://launchpad.net/~ubuntu-sdk-team/+archive/ppa
[09:59] <dbarth> Mirv: ok
[09:59] <dbarth> Mirv: are there silos available right now?
[10:00] <bzoltan1> Mirv:  how to proceed with the Silo9 now? It is tested and good to go
[10:11] <Mirv> dbarth: silos are really full right now, so for utopic update I'd wait a little bit until we know we can release something there
[10:12] <Mirv> bzoltan1: it states it requires a QA sign off, and then the bugs would need to be SRUfied. but if you're targeting utopic, it needs reconfiguration against utopic series and a rebuild.
[10:12] <Mirv> since as seen at https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/+packages the package is built for trusty (since utopic wasn't open back then)
[10:13] <bzoltan1> Mirv:  absolutely targeting U
[10:13] <bzoltan1> Mirv:  for obvious reasons I will not test again the reconfigured/rebuilt packages
[10:16] <Mirv> bzoltan1: alright. so, I just added a note for now since we've not yet landed anything to utopic, but at least utopic is out there now.
[10:16] <bzoltan1> Mirv:  OK... i just would like to back on the normal track as quick as possible
[10:17] <Mirv> prepare-silo told me that it's preferred to free the silo and reassign it when changing series, and aborted, so that's why only a note so that maybe all similar cases can be handled at the same time
[10:19] <bzoltan1> Mirv:  I reconfigured and started the build again... we can start the whole hustle from scratch if you wish so
[10:21] <Mirv> bzoltan1: it rebuilds against trusty still there, so it's not better. let's restart when we have everything needed for utopic landings.
[10:22] <bzoltan1> Mirv:  so you can not assign a U Silo to the landings?
[10:39] <sil2100> Saviq: I re-ran the build in your silo, it *should* work now, let's see how it works
[10:39] <Saviq> sil2100, thanks!
[10:40] <Mirv> bzoltan1: I can, but I'd rather see one complete utopic landing done first. so, slightly later.
[10:41] <bzoltan1> Mirv: :) we could be that one utopic landing :)
[10:49] <Mirv> bzoltan1: yep, let's see. I'll handle the reconfiguring anyhow in a bit.
[11:13] <bzoltan1> Mirv:  super, please ping me when I should start to be excited :)
[11:17] <didrocks> sil2100: Mirv: Saviq: bzoltan1: for the record, we won't publish them though. We'll need a rebuild once the toolchain is updated
[11:18] <didrocks> so, it's only exploratory :)
[11:18] <Saviq> :|
[11:18] <Saviq> do we know ETA?
[11:19] <sil2100> :|
[11:19] <didrocks> Saviq: something you should ask on #ubuntu-release. Seems like EOW from what I read
[11:19] <sil2100> |:
[11:21] <ogra_> i wouldnt count on EOW ... rather monday/tuesday
[11:22] <Mirv> didrocks: right. I expected there are toolchain changes upcoming still, but good to know for sure.
[11:22] <Mirv> only binutils updated so far in practice
[11:22] <Mirv> and some boost libs
[11:22] <ogra_> yep
[11:22] <ogra_> and skype
[11:22] <ogra_> :)
[11:29] <xnox> Mirv: there ain't much toolchain changes this time around. we are not going with 4.9 =(
[11:29] <xnox> so that's actually it - ruby, boost, binutils.
[11:31] <Mirv> xnox: oh, no gcc 4.9? it's already two days old! :)
[11:32] <Mirv> ok so after binutils has migrated to release pocket maybe then it's good
[11:32] <Mirv> ogra_: I did make a note of the same thing you mentioned on #release :)
[11:33] <ogra_> skype you mean ?
[11:33] <ogra_> yeah, its awfuk to have it as the very first upload of a new series
[11:34] <ogra_> *awful
[11:34] <Mirv> yeah, being the first :)
[11:34] <ogra_> but i guess adam had a reason
[11:34] <ogra_> (traditionally we opened with a vim upload in teh past)
[11:34] <xnox> ogra_: it wasn't an upload, but a copy.
[11:35] <ogra_> xnox, yet it is the first package to show up on changes :)
[11:36] <cjwatson> Probably a quirk of list moderation actually
[11:36] <cjwatson> Oh, no, it has an earlier Date.  Whatever
[11:37] <cjwatson> But yeah, I think Adam was just walking down the checklist and initialising partner (with a copy, as xnox says)
[11:43]  * didrocks goes for a run
[11:52] <sil2100> brb
[12:01] <sil2100> Ok, I'm going for some lunch and to the pharmacy
[12:23] <Mirv> bzoltan: landing-009 is now totally utopic (and already built), but as discussed above we'll need an ack that the toolchain is DONE and then one more rebuild.
[12:23] <bzoltan> Mirv: Ultracoool
[13:39] <fginther> didrocks, will the 14.04 maintenance branches be handled by ci-train or daily-release or something else?
[13:40] <didrocks> fginther: all riding the train!
[13:42] <sil2100> ;)
[13:42] <fginther> didrocks, thanks. I'll be updating the lp:cupstream2distro-config stack files to transition to utopic and adding the 14.04 branches. I assume that this has no impact on the ci-train, right?
[13:43] <didrocks> fginther: no, the branch is now all yours! :)
[13:43] <fginther> \o/
[13:43] <fginther> :)
[13:56] <bfiller> sil2100: line 25 can be published and bug is setup for SRU. We'd like to get this one into SRU
[14:15] <sil2100> bfiller: looking o/
[14:29] <sil2100> Choo chooo
[14:35] <didrocks> ;)
[14:35] <alecu> the trainbot sounds great!
[14:36] <alecu> didrocks: would it make sense to include the traincon level in the topic?
[14:36] <didrocks> alecu: hum, nice idea, mind opening a feature request against cupstream2distro so that I don't forget about it?
[14:36] <alecu> sure
[14:37] <didrocks> thanks!
[14:37]  * ogra_ would really love if we could redefine "traincon" to something you dont have to look up all the time
[14:37] <ogra_> i.e. self explaining
[14:39] <alecu> https://bugs.launchpad.net/cupstream2distro-config/+bug/1312211
[14:39] <didrocks> alecu: thanks! assigning it to me
[14:41] <sil2100> ogra_: what do you mean? Traincon is self-explanatory...
[14:42] <sil2100> Everyone knows it's a synonim for phonecon
[14:43] <ogra_> sil2100, i would it like to have something like TRAINCON-GOOD instead of TAINCON-0 ... so you dont need to look up the number scheme of what means what
[14:43] <ogra_> (which i can never recall)
[14:43] <ogra_> or -RED vs -GREEN
[14:44] <alecu> ogra_: that's not very descriptive for colorblind people! ;-)
[14:44] <ogra_> lol
[14:44] <ogra_> especially males with red/green weakness ... right :)
[14:45] <didrocks> sil2100: I hope you liked the photo btw!
[14:46] <sil2100> didrocks: yes! It was awesome ;)
[14:46] <didrocks> sil2100: it's the train I'm competing against every day :)
[14:47] <sil2100> didrocks: uh, I hope it's faster than it looks ;p
[14:47] <didrocks> (there is an island in the park I'm running, and on this island, there is this train ;))
[14:47] <didrocks> it's not
[14:47] <didrocks> I can surely do 2 loops when it's doing one :p
[14:47] <sil2100> Oh my god, didrocks is fast like Flash! He can overrun a TRAIN
[14:47] <sil2100> :O
[14:48] <didrocks> \o/
[14:48] <didrocks> then, don't show the photo in that case :p
[14:48] <ogra_> flash gordon ?
[14:48] <ogra_> then i want a photo of him in the right outfit please :)
[14:49] <ogra_> (red tights and all) :)
[14:51] <didrocks> ogra_: sure sure, remember as well that I'm borrowing my shampoo now for the bike ride back in case it's raining :p
[14:52] <ogra_> didrocks, you should run ubuntu kylin ... then you can stop at the kylin software store and wont get wet http://people.canonical.com/~xnox/kylin-store.png
[14:53] <didrocks> ahah :)
[15:01] <alecu> ogra_: is that image real? !!!
[15:01] <ogra_> alecu, apparently
[15:02]  * alecu downloads the iso
[15:26] <fginther> didrocks, does ci-train maintain a list of project branches that is allowed to merge to?
[15:26] <didrocks> fginther: no, we are not preventing anything on purpose
[15:28] <fginther> doanac, hmm... so you could release something to the archive based on lp:unity8 in one ticket and something based on lp:unity8/utopic in the next?
[15:28] <fginther> s/ticket/landing/
[15:28] <sil2100> didrocks: hm, I've been wondering - I have published qtorganizer5-eds for SRU some time ago, and I don't see it anywhere right now - it's not in the UNAPPROVED queue, it's not in -proposed, it's as the description - in some unknown time and space o_O
[15:29] <fginther> err, doanac sorry misfire
[15:29] <fginther> didrocks, hmm... so you could release something to the archive based on lp:unity8 in one landing and something based on lp:unity8/utopic in the next?
[15:29] <didrocks> sil2100: maybe it's linked to the outage and was never treated?
[15:29] <didrocks> fginther: yeah, on purpose
[15:29] <didrocks> fginther: however, all MPs should be targetting the same destination
[15:30] <fginther> didrocks, that makes sense
[15:30] <didrocks> sil2100: let me see at least if the sync req was proceeded
[15:30] <didrocks> sil2100: I don't see anything from today
[15:30] <didrocks> hum, a stale process…
[15:30] <sil2100> huh
[15:31] <didrocks> weird that rsync timeout didn't work
[15:31] <didrocks> I think it's due to the outage, probably
[15:31] <Chipaca> sil2100: so, the push bugs got a (possibly automated) comment from raof about testing them. Should I do that, or should I get somebody else to? Feels a little bit dishonest for me to do it unless everybody knows that that's what's going on :)
[15:31] <didrocks> sil2100: killed then, next run should get it in unapproved
[15:31] <sil2100> didrocks: oh, so no action needed from my side?
[15:32] <didrocks> sil2100: watching is enough! :)
[15:32] <sil2100> Chipaca: hmm, usually someone else needs to do it ;) Maybe you could poke someone from your team?
[15:32] <Chipaca> I'll rope somebody in :)
[15:34] <josharenson> fginther, http://s-jenkins.ubuntu-ci:8080/job/mir-performance-tests-trusty-touch/ failed. I'm looking in to why, but I see a typo in the name of the ppa that the job adds
[15:35] <fginther> josharenson, ah yes, thanks for pinging me... I was able to get the mako job to run and pass - s-jenkins.ubuntu-ci:8080/job/mir-performance-tests-runner-mako/3/
[15:35] <josharenson> fginther, cool.
[15:35] <fginther> josharenson, it is missing the log file
[15:36] <fginther> or json results file
[15:36] <josharenson> fginther, that was my next question... The file _should_ be saved on the device in the directory where the test is run.
[15:37] <fginther> josharenson, what's the file name?
[15:38] <fginther> josharenson, or can it be specifed as an option to mir_performance_tests?
[15:40] <josharenson> fginther, its currently glmark2_fullscreen_default.json
[15:45] <slangasek> didrocks: I'm very glad you implemented an SNCF bot rather than a RENFE bot
[15:45] <didrocks> slangasek: indeed, we are all about security. Maybe not full speed, but we value safety :)
[15:49] <slangasek> didrocks: well, I was thinking more about RENFE's website being a java-exception-throwing monstrosity ;)
[15:51] <sergiusens> didrocks: can I show you something on the choo choo thing?
[15:51] <didrocks> slangasek: oh really? never had to dealt with it (fortunately it seems)
[15:51] <didrocks> sergiusens: sure
[15:51] <sergiusens> ty
[15:52] <sergiusens> didrocks: meh; when I did it last time I got a bunch of (12:49:12) CI-SNCF: Couldn't find anything matching this status request:
[15:52] <didrocks> oh?
[15:52] <didrocks> let me try in PM, but that worked
[15:53] <sergiusens> didrocks: pastebin would of been easier :-P http://paste.ubuntu.com/7323252/
[15:53] <slangasek> didrocks: well, it might only throw java exceptions when you try to unsubscribe from their spam, not sure
[15:53] <didrocks> sergiusens: ahah, I know!
[15:54] <didrocks> slangasek: that's how you ensure fidelity, right? :)
[15:54] <didrocks> sergiusens: there is "status" in the line, and so then it treats itself
[15:54] <sergiusens> didrocks: lol
[15:54] <didrocks> actually, can be fun, if you set "inspect <line>" in the description, you can recursively DDOS it
[15:54] <didrocks> ok, I need to ignore what CI Train is telling on the channel I guess :p
[15:55] <sergiusens> didrocks: also, why is it called landing-xxx instead of silo-xxx?
[15:55] <didrocks> which is again another patch on the upstream IRC library, I don't know why say what :)
[15:55] <didrocks> sergiusens: it's been always called like that (ppa name)
[15:55] <didrocks> blame asac for the ppa name choice :)
[15:56] <sergiusens> didrocks: heh; wow; I always read silo-xxx :-P
[15:56] <sergiusens> thanks
[15:56] <sergiusens> looks good
[15:56] <didrocks> sergiusens: striking news of the day! :)
[15:57] <didrocks> sergiusens: I'll look at your issue, but normally, it should ignore itself what it's telling already, maybe a race somewhere…
[16:02] <didrocks> ogra_: you can join, not sure there is much for you though
[16:02] <didrocks> plars: same ^
[16:02] <didrocks> robru: cyphermox: coming?
[16:02]  * ogra_ expects your will sit there saying "choo choo" all the time anyway
[16:03] <ogra_> but i'll come :P
[16:03] <plars> I can't make it right at this moment. Sorry
[16:28] <davmor2> didrocks: so your idea of a train is more like sl -al :D
[16:29] <didrocks> :)
[16:42] <bregma> mmmm, I like this ci-bot choo choo
[16:49] <ogra_> bregma, http://37.media.tumblr.com/tumblr_lvv9lsZLab1r4vmplo1_500.gif
[17:37] <Chipaca> sil2100: question for you sah
[17:38] <Chipaca> sil2100: we're having a bit of trouble reproducing the issue behind one of the bugs on other-people's-in-my-team's phones
[17:39] <Chipaca> sil2100: ideas?
[17:39] <Chipaca> sil2100: (all but one of the bugs are already 'verification-done' by my team)
[17:40] <Chipaca> sil2100: (the issue is a race between push and network devices coming online)
[17:58] <fginther> josharenson, can you check http://s-jenkins.ubuntu-ci:8080/job/mir-performance-tests-runner-mako/5/console? the json data file is being created empty and it looks like glmark probably isn't even running.
[17:59] <josharenson> fginther, sure. if the executable isn't run, an empty file is created as a method of failing gracefully (since we cant check for the exe at compile time)
[18:00] <josharenson> fginther, ah I see
[18:00] <josharenson> fginther, does the jenkins job start a mir server?
[18:02] <fginther> josharenson, it looks like all it does is install packages, reboot phone, stop unity8 and lightdm, then run the test
[18:02] <josharenson> fginther, ah, the benchmark isnt running because there is no mir server running
[18:03] <josharenson> fginther, let me look at some of the other tests and see how they handle this.. unless you know of an easier way
[18:04] <fginther> josharenson, I don't know of any other mir testing like this, so I don't have any experience here
[18:05] <josharenson> fginther, the solution is easy, it just needs to run an executable before the test starts.. reliably determining the location of the exe and handling failures may be harder
[19:05] <fginther> josharenson, do you have a device to test with?
[19:05] <josharenson> fginther, yes
[19:06] <fginther> josharenson, ok, so are working on "reliably determining the location of the exe and handling failures"
[19:06] <fginther> ?
[19:06] <josharenson> fginther, that is my next step.. working head down in something else atm
[19:07] <fginther> josharenson, ok, that's fine. I just didn't want this to fall through the cracks if I had assumed the wrong thing
[19:07] <josharenson> fginther, haha it won't, thanks for checking
[20:10] <kgunn> fginther: hiya...i'm kinda antsy for this one to merge...is 2 hrs too impatient ?
[20:10] <kgunn> https://code.launchpad.net/~vanvugt/mir/fix-1308941/+merge/217021
[20:10] <kgunn> i guess i can manual merge if needed....
[20:13] <fginther> kgunn, looking
[20:14] <fginther> kgunn, looks like it's almost done, another 10-15 minutes