=== chihchun_afk is now known as chihchun
=== marcusto_ is now known as marcustomlinson
=== dbarth__ is now known as dbarth
=== oSoMoN_ is now known as oSoMoN
[08:39] <popey> where is everyone?
[08:46] <ogra_> popey, sil is sick, jibel is on vacation and davmor2 probably drowns in mgmt work :)
[08:47] <seb128> popey, you don't like quiet monday mornings?!
[08:47]  * ogra_ guesses he doesnt liek to get up for non-cancelled meetings
[08:48] <davmor2> ogra_: not yet and I have a plan, I have a ps3 gun and I'm not affraid to use it ;)
[08:48]  * ogra_ puts up the laser shield around the house
[08:48] <davmor2> ogra_: I was at the meeting
[08:48] <ogra_> oh
[08:49] <davmor2> ogra_: timo was too and was the only one there who knew sil was sick :(
[08:49] <ogra_> i did too :)
[08:50] <ogra_> (because they didnt kick me out of the foundations ML )
[08:50] <davmor2> ogra_: shhhh or they might
[08:56] <popey> seb128: Good point!
[09:02] <Laney> To: foundations Subject: ogra_ - why does he have that underscore? ARGH!
[09:02] <ogra_> Laney, thats my ponytail !
[09:12]  * Laney snip snip
[09:48] <morphis> Mirv: can you do me a favor and upload a package to a silo?
[09:51] <davmor2> Laney: don't snip his ponytail that's his external memory storage, you cut that off and forget most of the stuff that makes landing happen then you have to do it by hand
[09:52] <Laney> davmor2: maybe you could sell the hairs on the black market for a very good price
[09:52] <Laney> then we could do some cloning ...
[10:05] <Mirv> morphis: certainly, give me the url as usual
[10:33]  * Mirv notices he gets 45Mbps 4G upload speed at his lunch place - perfect for uploading 300MB android sources :)
[10:33] <Mirv> also, a reason to not migrate to Bq since I do need that 4G at times like this
[10:34] <Mirv> so I need to get a Meizu at some point and leave Bq to be more a toy device
[10:34] <Mirv> although, I've fallen in love with dual SIM of Bq...
[10:38] <Mirv> morphis: that was quick to fail to build, complaining about depmod command not found
[10:39] <morphis> Mirv: it's still running, don't it? https://ci-train.ubuntu.com/job/ubuntu-landing-032-1-build/11/console
[10:42] <Mirv> morphis: not according to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-032/+packages
[10:43] <Mirv> the build job got updated too now
[10:43] <morphis> hm, that is interesting
[10:45] <morphis> Mirv: we can't just sync that package from wily, right?
[10:50] <Mirv> morphis: I don't think there's a problem with recompiling the wily version - if you mean that it'd be a problem because it's a manual upload source. that said, I haven't tried the new requests page yet for syncs but happy to try :9
[10:51] <morphis> hm
[10:51] <morphis> that would make things a bit easier
[10:51] <morphis> Mirv: are the gates for wily opened again?
[10:52] <Mirv> morphis: I'd be cautious to say they are since the GCC5 transition to release pocket is still not complete, but sil2100's last landing e-mail actually says they are open :) but he's now online too.
[10:53] <morphis> ah ok
[10:53] <Mirv> morphis: certainly silos can be built etc, we might need to do some double checking before publishing
[10:53] <morphis> so maybe better go this way which would leave the package setup cleaner than maintaining two variants for each release
[10:54] <Mirv> morphis: certainly whenever it's feasible to build from the same sources for both releases, it's better not to maintain two variants
[10:54] <Mirv> feasible as in "ready to ship in the next OTA"
[10:54] <morphis> yeah
[10:57] <sil2100> Yes, landings are open as gcc-5 is in -proposed and we build agianst proposed
[10:57] <sil2100> We just need to make sure that every possibly-affected wily silo is rebuilt after the release on Friday
[10:59] <morphis> sil2100: ok, then let me abandon my vivid silo and request a wily one
[10:59] <sil2100> Abandon vivid?
[11:01] <morphis> sil2100: yeah did a first attempt which was meant to be an update of the vivid package for android which is already out-of-sync with the wily one
[11:02] <morphis> but the better way should be to just sync the up-to-date wily on back to vivid
[11:02] <sil2100> Ok
[11:02] <sil2100> Indeed, could make sense
[11:16] <marcustomlinson> trainguards: could I please have permissions for operating the CI Train
[11:18] <Mirv> marcustomlinson: you should already have according to https://launchpad.net/~ci-train-users/+members/
[11:19] <marcustomlinson> Mirv: ah strange, was getting an error page before, seems to be working now
[11:19] <Mirv> marcustomlinson: great!
[11:29] <popey> Mirv: saw this and thought of you http://imgur.com/gallery/xmdYnGo
[11:37] <Mirv> popey: nice! the first part never happens to my cats though, second part at times yes.
[11:37] <Mirv> heh
[11:39] <popey> :)
[11:44] <cjwatson> popey: one of ours used to set ambushes for the others
[11:47] <morphis> sil2100, Mirv: could this also be an opportunity for a dual landing?
[11:47] <sil2100> morphis: for the android package?
[11:48] <morphis> yeah
[11:48] <sil2100> morphis: not sure if that can dual land, since we only support that for CI Train versioned packages
[11:49] <morphis> ok
[11:58] <popey> cjwatson: yeah, ours do that. Wish I could get it on film sometimes.
=== alan_g is now known as alan_g|lunch
[12:10] <Mirv> morphis: right so two silos are then needed, even if practically same source
[12:17] <morphis> Mirv: first silo with manual upload and second silo a sync silo?
[12:18] <Mirv> morphis: that should work AFAIK, although then if it doesn't we'll handle it manually.
=== psivaa is now known as psivaa-lunch
[12:31] <pstolowski> robru, ping
=== chihchun is now known as chihchun_afk
[12:56] <kgunn> trainguards ok, so https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-035
[12:56] <kgunn> what would be your suggestion, the packages got copied to vivid+o
[12:56] <kgunn> it was a dual landing
[12:57] <kgunn> but caught in transition
[12:57] <kgunn> of gcc5
[12:57] <kgunn> so we need to rebuild unity8/unity-api against wily, to release into wily
[12:57] <kgunn> how should we handle ?
[12:57] <pstolowski> kgunn, this silo broke builds of unity8 in vivid
[12:57] <kgunn> e.g. do you guys do a manual silo? do i need to set up a seperate silo ?
[12:58] <kgunn> pstolowski: so did it get reverted ?
[13:01] <pstolowski> kgunn, i don't think anything got reverted; changes from this silo (at least for unity-api) were landed manually and are not reflected in trunk; it's not possible to built unity8 trunk against unity-api that's currently in vivid overlay
[13:03] <kgunn> pstolowski: ok, i see... trainguards ^ shouldn't those branches have been merged back if we landed them into vivid+o ?
[13:03] <kgunn> and then we can do a no commit rebuild into wily ?
[13:04] <kgunn> pstolowski: and yeah...that all appear to be approved but not merged branches
[13:06] <Mirv> kgunn: seems correct, they are in vivid overlay. I can try to manually run the clean job to merge those, after which yes you could do a no commit rebuild to wily.
[13:06] <pstolowski> kgunn, also, i'd like to understand why it was pushed manually... looks like asking for trouble (which it caused btw)
[13:06] <Mirv> right, the publish job was never run
[13:08] <kgunn> pstolowski: b/c we went through all the QA testing and it was approved and i _thot_ they would be merged
[13:08] <Mirv> kgunn: ok, that worked, so the trunks are now up-to-date althought missing the GCC5 rebuild changelog entries
[13:08] <kgunn> at which point it would have only been borked for wily
[13:09] <kgunn> Mirv: ok, will pull, do chlog statement of no change, rebuild for gcc5
[13:09] <kgunn> one moment
[13:09] <Mirv> kgunn: right
[13:14] <pstolowski> kgunn, okay
[13:26] <kgunn> pstolowski: tsdgeos if one of you would...just approve
[13:26] <kgunn> https://code.launchpad.net/~unity-team/unity8/unity8-rebuild-for-gcc5/+merge/266713
[13:26] <kgunn> https://code.launchpad.net/~unity-team/unity-api/unity-api-rebuild-for-gcc5/+merge/266714
[13:26] <rvr> boiko: Approving silo 40
[13:26] <tsdgeos> kgunn: done
[13:26] <boiko> rvr: nice! I will just have to rebuild it for the gcc5 transition :/
[13:26] <boiko> rvr: but no code changes
[13:55] <kgunn> trainguards is dashboard having an issue ? i see "empty silos"
[14:05] <kenvandine> cihelp: is anyone looking into the boottest failures that's holding up package migration?
[14:05] <kenvandine> looks like it fails to provision the device
[14:06] <fginther> kenvandine, yes. Found a confused device and have taken it offline. Reruns have started.
=== chihchun_afk is now known as chihchun
[14:14] <kenvandine> fginther, thx
[14:17] <bzoltan_> cihelp: How can I turn the silo ready for QA?
[14:18] <bzoltan_> other than save it as "ready for QA" ? :)
[14:18] <josepht> trainguards: can you help bzoltan_ please? ^
[14:19] <Mirv> kgunn_: seems normal to me. if there's a long id and no description, then that's a leftover from the spreadsheet and should be migrated by the lander
[14:19] <Mirv> josepht: I think bzoltan_ did the right thing
[14:20] <kgunn_> Mirv: weird....it seems fine to me now
[14:22] <Mirv> kgunn_: the client side javascript pulls all the data so any network problem could cause it
[14:22] <Mirv> but ok, good
[14:36] <dbarth_> o/ trainguards, can i get help to clean silo 031? and I need a new silo for OA, but I didn't find the interface in the new web interface
[14:45] <dbarth_> Mirv maybe ? ^^
[14:50] <popey> balloons: is there something wrong with jenkins you know of? https://code.launchpad.net/~nik90/ubuntu-clock-app/fix-qtcreator-builability/+merge/266647 & https://code.launchpad.net/~nik90/ubuntu-clock-app/merge-changelog/+merge/266645
[14:50] <popey> neither of those have been picked up
[14:51] <balloons> oO
[14:51] <balloons> oO
[14:51] <rvr> boiko: Approving silo 15
[14:56] <balloons> popey, nothing appears broken at first glance, but the last runs were 2 days ago. Trying to build something now manually doesn't trigger a new run either
[14:56] <balloons> we need cihelp to have a look at core apps jenkins and figure it out
[14:56] <popey> yeah, nik90 said it was broken all weekend
[14:56] <popey> these are minor merges, but they should have been picked up
=== psivaa-lunch is now known as psivaa
[14:59] <balloons> it may have ran out of space
[14:59] <balloons> ohh look, it indeed it did
[14:59] <popey> hah
[15:01] <balloons> var/lib/jenkins/ is full
[15:06] <boiko> rvr: great! thanks
[15:07] <balloons> so, I guess cihelp, can you look into fixing core apps jenkins? It seems the disk is full
[15:08] <psivaa> balloons: let me take a look
[15:11] <rvr> robru: Hey, one question. I have some silos that contain code for gcc 5, do we have to wait until a "gcc 5" is available, or can they be tested with the current devel image?
[15:29] <pete-woods> trainguards: hi guys, I think I need my silo #49 clearing. I stopped depending on a branch that bumped the package version to 0.5.2, but the silo is still producing builds with that version..
[15:29] <pete-woods> I would expect version 0.5.1
[15:29] <pete-woods> (see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-049/+packages)
[15:30] <popey> psivaa: thanks
[15:56] <Mirv> dbarth__: hey, sil is a bit sick today so there's a small gap in trainguarding, robert should be here soon. you didn't specify if you want to force clean 031 or merge it. for new silo, make sure you've the team memberships checked when you log in via SSO, then at the top should be all the fields.
[15:57] <Mirv> pete-woods: hmm, interesting, I deleted the packages now, wait 15 min and try rebuilding
[15:58] <psivaa> balloons: I'm curious why you'd say that the disc is full in core-apps jenkins
[15:58] <balloons> psivaa, looking at master: http://91.189.93.70:8080/job/trigger-autolanding-job/62328/console
[15:59] <pete-woods> Mirv: oh, ah I already tried to abandon the silo (and requested another one)
[15:59] <pete-woods> but it looks like the abandon button doesn't work
[15:59] <pete-woods> perhaps due to it being originally from the spreadsheet
[15:59] <Mirv> pete-woods: right, there's no that silo in the requests https://requests.ci-train.ubuntu.com/
[15:59] <psivaa> balloons: ahhh, i have been looking at http://core-apps-jenkins.staging.ubuntu.com:8080/
[15:59] <balloons> psivaa, ohh, sorry
=== chihchun is now known as chihchun_afk
[15:59] <psivaa> balloons: np, just a sec
[15:59] <Mirv> pete-woods: can you request a new line with the MP:s?
[16:00] <pete-woods> Mirv: I already have done, and it's request 87, silo 53
[16:00] <pete-woods> and building now
[16:00] <pete-woods> the old one is marked as abaondoned
[16:00] <pete-woods> but still showing in the dashboard
[16:00] <Mirv> pete-woods: ok :) then I'll just free up the silo and find later on if that should have happened automatically...
[16:01] <kgunn_> trainguards hey, so on the new bileto, how do i say i tested something on wily and it's good to go ?
[16:01] <Mirv> pete-woods: I'm just back so not exactly super familiar with the new system, but cleaning the silo manually this time
[16:01] <pete-woods> Mirv: okay, cool. whatever the reason I'm sure it can be figured out :)
[16:01] <Mirv> kgunn_: you edit it and put the status to "Publish without QA"
[16:02] <kgunn_> ta
[16:02] <kgunn_> easy peasy
[16:14] <robru> pete-woods: what happens when you click abandon? It's supposed to just hide the request, it's not supposed to free the silo.
[16:14] <pete-woods> robru: that's pretty much what it did
[16:14] <pete-woods> although it's not hidden
[16:15] <pete-woods> it's hidden in the dash view (as expected)
[16:15] <robru> pete-woods: dash view?
[16:15] <pete-woods> https://requests.ci-train.ubuntu.com/static/dashboard.html
[16:15] <pete-woods> that page
[16:15] <cwayne> davmor2: yo
[16:15] <pete-woods> but not hidden on the requests view
[16:15] <robru> pete-woods: "abandon" button should have no impact on the dashboard at all
[16:16] <davmor2> cwayne: whats up
[16:16] <pete-woods> yeah, I guess it's hidden there because Mirv cleaned it
[16:16] <pete-woods> the idea is then that abaondoned landings get manually inspected by you guys then?
[16:16] <cwayne> davmor2: got a instagram click update ready to go to the store, it just fixes not being able to add an instagram account
[16:16] <cwayne> davmor2: got a sec to test so i can push to the store?
[16:17] <davmor2> cwayne: nope
[16:17] <pete-woods> anyway, this doesn't really matter right now, as I have the effect I wanted, which is my old silo removed :)
[16:17] <davmor2> rvr, alesage: ^ can you help cwayne with this please?
[16:17] <robru> pete-woods: the idea is that the abandon button marks a request as abandoned, which is the closest we get to deleting it. It doesn't impact the silo, which you should free separately
[16:18] <robru> pete-woods: what request id is it?
[16:18] <pete-woods> robru: 59
[16:18] <rvr> cwayne: Sure
[16:19] <cwayne> rvr: should be suuper quick to test, its a one-line change in the provider file :)
[16:19] <cwayne> ill email it over
[16:19] <rvr> cwayne: Ack
[16:19] <alesage> rvr thanks
[16:21] <robru> pete-woods: Hmmmmmmm, 56 marked landed, should not be displayed on front page, agree you saying it's visible?
[16:22] <pete-woods> robru: okay, so it seems abandoned / landed only appear when you search
[16:22] <pete-woods> I have a search for pete-woods in the box
[16:22] <pete-woods> which I use as my "normal view" of it
[16:22] <rvr> cwayne: Received
[16:22] <robru> pete-woods: oh, yeah.
[16:22] <pete-woods> robru: I guess my list of stuff will keep on growing as I land more
[16:23] <pete-woods> it might be useful to have a "my requests" tab
[16:23] <pete-woods> or change the search behaviour to only search current requests
[16:23] <pete-woods> something like that, anyway
[16:23] <robru> pete-woods: yep. I'll implement pagination soon so the list doesn't just grow to infinity. In staging I've discovered the page gets really sluggish above 100 or so requests per page.
[16:23] <pete-woods> robru: I guess I'm saying I don't really want to see them at all
[16:24] <pete-woods> the same way that LP hides MRs with merged status by default
[16:24] <pete-woods> I guess this isn't super important, though..
[16:24] <robru> pete-woods: not sure how to handle that, since the search is specifically for finding landings that have been hidden from the front page
[16:24] <pete-woods> robru: well that's why my first suggestion was a new page for "my landings"
[16:25] <pete-woods> just showing requests for the current user
[16:25] <robru> pete-woods: OK can you for a bug against lp:bileto? Sounds like a good idea
[16:25] <pete-woods> robru: will do :)
[16:25] <robru> pete-woods: thanks
[16:28] <pete-woods> robru: https://bugs.launchpad.net/bileto/+bug/1481001 FYI
[16:28] <ubot5> Ubuntu bug 1481001 in Bileto "Add a "my requests" page, showing my active landing requests" [Undecided,New]
[16:28] <robru> great
[16:38] <davmor2> rvr: thanks dude
[16:48] <rvr> cwayne: I logged into Instagram
[16:48] <psivaa> balloons: jenkins has been cleared, http://91.189.93.70:8080/job/trigger-autolanding-job/ is running
[16:48] <rvr> cwayne: In the Photos scope, Instagram is not shown. But in its own scope, photos appear correctly.
[16:49] <fginther> kenvandine, ubuntu-system-settings is hitting a error I've not seen before. I'm running a test locally to see if it's actually failing the reboot
[16:49] <rvr> cwayne: I only see My photos, Facebook (request to log in) and Flickr explore.
[16:49] <kenvandine> fginther, thx...
[16:50] <balloons> psivaa, thank you
[16:50] <balloons> popey, mp's should be flowing
[16:50] <cwayne> rvr, hmm, let me check with kyle, photos scope may have changed
[16:50] <cwayne> but that means what was changed in instagram fixed its login issue at least
[16:51] <kenvandine> fginther, the error i saw this morning look the same as what i saw in another one of the packages that failed too
[16:51] <kenvandine> maybe udm
[16:51] <kenvandine> i don't recall
[16:52] <fginther> kenvandine, I'll check that as well
[16:52] <kenvandine> fginther, oh... maybe it had been failing earlier before
[16:54] <fginther> kenvandine, ugh, I just realized that a bunch of packages are getting removed during the test...
[16:54] <kenvandine> ah!
[16:54] <fginther> kenvandine, including unity8
[16:54] <kenvandine> that would do it :)
[16:55] <kenvandine> something in -proposed probably needs a rebuild ?
[16:55] <kenvandine> i noticed mir is in there
[16:56] <kenvandine> fginther, maybe trust-store is the culprit?
[16:57] <fginther> kenvandine, this is probably related to the gcc update that was started friday.
[16:58] <kenvandine> fginther, there's a transition from libtrust-store1 to libtrust-store2
[16:59] <kenvandine> libubuntu-location-service2 has a depends on libtrust-store1
[16:59] <kenvandine> and unity-plugin-scopes depends on that
[17:00] <fginther> kenvandine, so that means we need a new trust-store with updated depends?
[17:00] <kenvandine> no
[17:00] <kenvandine> i suspect just location service needs a rebuild
[17:01] <kenvandine> i don't have wily-proposed handy to verify those rdepends though
[17:02] <kenvandine> fginther, but based on what's being removed, that's what i suspect
=== alan_g|lunch is now known as alan_g|EOD
[17:02] <fginther> kenvandine, ack
[17:02] <kenvandine> so maybe location-service was built before trust-store
[17:12] <popey> thanks balloons psivaa
[17:12] <kenvandine> fginther, indeed the location-service package was published over an hour before trust-store
[17:13] <kenvandine> so it built against the old trust-store
[17:13] <kenvandine> fginther, i can do a no change rebuild upload to wily-proposed
[17:13] <kenvandine> or i guess that one is better as part of a silo
[17:17] <kenvandine> grr... the latest location-service hasn't been merged back to trunk yet
[17:17] <kenvandine> that'll make a silo harder
[17:22] <dobey> trainguards: are landings to wily blocked on packages from the gcc5 "silo" being migrated through to release first?
[17:23] <charles> trainguards, is there another manual step for landing after testing a silo and marking (in this case, silo 8) "publish without qa"?
[17:23] <charles> ah dobey beat me to the question :)
[17:23] <robru> dobey: it seems so, yeah
[17:23] <dobey> ok :-/
[17:26] <dobey> meh, so wily landings are busted until all these dependency issues in the migration get fixed :-/
[17:34] <cwayne> rvr, ok so, there's a bug in the photos agg with regards to instagram
[17:34] <robru> dobey: check with doko, I don't know much about this transition unfortunately
[17:34] <cwayne> rvr, so it's not related to this fix.  kyle is aware of it and working on fixing it, so i'd say in the meantime, i'd like to push the instagram fix as it as least fixes the child scope
[17:36] <kenvandine> fginther, i'll uploaded another no change rebuild for location-service to wily-proposed
[17:36] <kenvandine> hopefully that'll unclog the pipes :)
[17:36] <dobey> robru: i've been checking the excuses page every now and then. seems some more dependency issues are cropping up in autopkgtests, which weren't exposed via the PPA builds (which don't run the dep-8 tests)
[17:37] <kenvandine> dobey, hopefully my upload of location-service might fix some of them
[17:40] <dobey> kenvandine: it seems there's also some issues with the boottest hardware provisioning? i don't think more uploads will fix that :-/
[17:40] <kenvandine> dobey, that's the problem
[17:40] <kenvandine> it's removing unity8 :)
[17:41] <kenvandine> i think the location-service rebuild will fix that
[17:42] <dobey> ubuntu-touch-meta has broken -dev dependencies still too though
[17:42] <kenvandine> :/
[17:42] <kenvandine> what a mess
[17:42] <dobey> indeed
[17:43] <kenvandine> i think this will fix the boottest though
[17:45] <dobey> maybe
[17:47] <dobey> there are plenty of other issues on top of that though
[17:49] <dobey> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5 <- the great wall of gcc5 test failures
[17:54] <jhodapp> robru, hey, is there a way we can re-target silo 38 to land in vivid+overlay instead of wily? It was a silo originally created from the spreadsheet
[17:55] <robru> jhodapp: depends
[17:56] <robru> jhodapp: you can't just reassign a wily silo to vivid if that project has released to wily in the past
[17:56] <robru> jhodapp: you need to branch for vivid in that case
[17:56] <robru> jhodapp: generally I would recommend the dual silo but I guess gcc5 threw a wrench in those gears
[17:56] <jhodapp> robru, ok, yeah that's why it's not clear to me
[17:57] <jhodapp> and that's also why I'm retargetting now
[17:57] <cwayne> rvr, hm, i seem to have lost my irc connection, is it okay for me to push instagram to the store, given that the issue is with the photos agg itself
[17:57] <jhodapp> robru, alright, I'll just request a new silo then
[17:57] <robru> jhodapp: it's not about getting a new silo, you need to branch your trunk for vivid
[17:57] <robru> jhodapp: if you get new branches it's trivial to reconfigure the silo
[17:57] <jhodapp> robru, right, I'm also doing that
[17:58] <jhodapp> robru, oh I guess we could take that route yeah
[17:58] <jhodapp> robru, how about for source package uploads?
[17:59] <robru> jhodapp: what about them? they're handled manually so as long as you prepare the sources by hand then you can do whatever you want
[18:00] <jhodapp> robru, makes sense
[18:00] <jhodapp> thanks
[18:03] <rvr> cwayne: I'm ok too
[18:10] <boiko> robru: quick question: I have two silos marked as QA granted, do I need to do anything else in the requests page, or should I just wait?
[18:10] <robru> boiko: which ones?
[18:11] <boiko> robru: 15 and 40
[18:11] <robru> boiko: are any of these C++?
[18:12] <boiko> robru: 40 is for sure, tone-generator, I don't know, but both of them have been rebuilt after the gcc5 landing
[18:13] <robru> boiko: ok thing is gcc5 is really just in proposed, it didn't really "land" yet. It's not really clear to me what the implications are.
[18:13] <boiko> robru: ah ok, in that case, I can wait, and rebuild once gcc5 is in the final destination
[18:13] <robru> boiko: tone-generator seems to just be C, so I'll publish that one at least
[18:14] <boiko> robru: nice! thanks!
[18:14] <robru> boiko: for the other one, I don't really know what's going on, you should check with doko to figure out how to manage the gcc5 transition
[18:15] <boiko> robru: ok
[18:16] <robru> boiko: although generally speaking this is a bug in the dashboard, it doesn't highlight silos ready to publish like it used to, I'll work on that today.
[18:16] <boiko> robru: no worries, I was just wondering if missed something
[18:17] <robru> boiko: nope, looks like everything's correct
[18:53] <dobey> kenvandine: any luck?
[18:56] <jhodapp> robru, so I have 4 new MRs that all target vivid...so now I can simply reconfigure silo 38 with these new MRs and change it to dual or vivid+overlay?
[18:56] <robru> jhodapp: what did you do to make them "target vivid"? if they target vivid then dual isn't an option.
[18:57] <kenvandine> dobey, not sure yet, waiting for a boottest to run that pulls in the rebuild of location-service
[18:57] <jhodapp> robru, well they are set to merge in the stable branch of each project...I guess I don't understand how a dual landing works at all
[18:59] <robru> jhodapp: a dual landing is a wily landing that just happens to duplicate the silo contents, s/15.10/15.04/ in the version number and then upload that to vivid in the same PPA.
[19:00] <jhodapp> robru, ah right, so I don't care about wily anymore so I do in fact just want a straight vivid+overlay landing
[19:00] <robru> jhodapp: to "target vivid" you need to make sure that your most recent changelog entry doesn't have a wily version number otherwise the train will explode, having a new changelog version that's lesser than a previous changelog version is illegal.
[19:01] <jhodapp> robru, so a wily version number is what exactly?
[19:01] <robru> jhodapp: it's one that contains "15.10.YYYYMMDD"
[19:02] <jhodapp> robru, so what if it's already been released with a 15.10.* version number?
[19:02] <jhodapp> robru, I'm trying to sync trunk to vivid
[19:03] <robru> jhodapp: yes, you need to change the changelog to have a vivid version number, because making a 15.04 release after a 15.10 release is illegal.
[19:03] <jhodapp> robru, change all of the previous ones that were for wily you mean?
[19:05] <robru> jhodapp: I think it works if you just change the most recent one.
[19:06] <jhodapp> robru, ok great
[19:07] <jhodapp> robru, so is it legal to just change 15.10 to 15.04, and wily to vivid, and leave the rest the same?
[19:09] <robru> jhodapp: well, it'll fool the train into working. Having changelog entries that don't correspond to actual releases is probably frowned upon
[19:10] <jhodapp> robru, sure, but what else would it be? this is a sync...
[19:10] <robru> jhodapp: yeah it's fine
[19:10] <jhodapp> ok :)
[19:11] <jhodapp> robru, just trying to learn in general, I'm not a core-dev so this is all new to me
[19:13] <robru> jhodapp: yeah don't let the train rot your brain too much
[19:13] <jhodapp> haha
[19:36] <jhodapp> robru, how do you reconfigure after editing in the new silo request tool? Does it automatically do that after pressing save?
[19:37] <robru> jhodapp: no you need to click 'Assign', it reconfigures if it's already assigned.
[19:38] <jhodapp> robru, ok that was my guess but wasn't sure
[19:38] <pmcgowan> robru, how long are we blocked with the gcc5 stuff any idea?
[19:38] <jhodapp> robru, can that button change with context, assign if new, reconfigure if editing?
[19:38] <robru> jhodapp: the silos are managed by jenkins, if you didn't run a jenkins job then nothing happened in the silo.
[19:39] <robru> jhodapp: I'd rather not have buttons that change names despite doing the same thing. If you can think of one word that encapsulates 'Assign' and 'Reconfigure' I'm open to it though... maybe 'Inject' or something.
[19:39] <robru> pmcgowan: I'm not really up on it. apparently kenvandine had some fixes
[19:39] <jhodapp> robru, "Make it so #1"? :)
[19:39] <robru> jhodapp: lol, yeah
[19:39] <kenvandine> at least location-service needed a rebuild in wily-proposed
[19:40] <kenvandine> i did a quick upload to handle that, and i think it fixed it
[19:40] <kenvandine> pmcgowan, dobey said there's also some problems with some -dev packages, but i don't know much about that issue
[19:40] <jhodapp> robru, how about "Commit change"
[19:40] <jhodapp> robru, or just "Commit"
[19:40] <robru> jhodapp: but it's not doing a bzr commit ;-)
[19:40] <jhodapp> silly english
[19:41] <jhodapp> too much overloading
[19:41] <robru> jhodapp: we have a lot of overloaded terms between the train and debian jargon
[19:41] <jhodapp> indeed
[19:41] <robru> jhodapp: even jenkins is bad, having to click 'Build' on a job that doesn't build packages.
[19:41] <pmcgowan> robru, kenvandine I guess my real question is how long do we allow ourselves to be blocked with dual landings rather than continuing with vivid only
[19:42] <jhodapp> pmcgowan, exactly why I'm just doing a vivid-only landing for background playlist stuff
[19:42] <robru> pmcgowan: well my understanding is that people need to branch for vivid anyway
[19:42] <kenvandine> pmcgowan, it's rather frustrating... not sure what the threshold should be
[19:43] <kenvandine> robru, i haven't heard that
[19:43] <dobey> hmm
[19:44] <robru> kenvandine: I heard from dobey that if you use C++, it's not possible to package something that works with both gc4.9 and gcc5 so you need to branch
[19:44] <pmcgowan> robru, I am told only for libraries
[19:44] <pmcgowan> some projects should work
[19:45] <dobey> well, i guess dual landings will be ok, since they are cheating
[19:45] <robru> pmcgowan: hm. well I know very little about C++ unfortunately
[19:45] <dobey> but things will certainly get nasty because of binary incompat issues between things on gcc5 and gcc 4.9
[20:01] <robru> jhodapp: that's what I was talking about with the train not letting you downgrade the version number ^
[20:02] <jhodapp> robru, right, I have some other issues that are my fault...just about got it figured out
[20:05] <jhodapp> robru, ok I got the version stuff figured out, it's building now
[22:02] <kgunn_> trainguards just checkin on the migration of the unity8/unity-api rebuild for gcc5....seems stuck on
[22:02] <kgunn_> autopkgtest for qtcreator-plugin-ubuntu 3.1.1+15.10.20150720-0ubuntu1
[22:02] <kgunn_> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8
[22:02] <kgunn_> seems...lots of stuff stuck on that?
[22:02] <kgunn_> is this known or ?
[22:02] <robru> kgunn_: gcc is known to be stuck
[22:03] <kgunn_> robru: so just bury head for a little bit more time ?
[22:03] <robru> kgunn_: I don't know about qtcreator though. you should probably reach out to people who know things
[22:03] <kgunn_> :)
[22:03] <kgunn_> that's a Mirv thing afaik ^
[22:03] <robru> kgunn_: I thought bzoltan_?
[22:03] <kgunn_> or him as well...true
[22:04] <kgunn_> or instead