[01:26] <jamesh> kenvandine: hi
[01:27] <jamesh> kenvandine: just looking back through scrollback, I thought I'd checked the rdepends when putting the silo together, but looks like I missed qtubuntu-media (it wasn't a dep last time we made such a change)
[03:11] <kenvandine> jamesh, yeah, but slangasek was also questioning if we need the different sonames for the gcc5 transition
[03:11] <kenvandine> jamesh, also qtubuntu-media isn't dual landing, so harder to get fixed
[03:11] <kenvandine> i think we just need that depends dropped from qtubuntu-media and rely on shlibs to properly depend on it
[03:11] <jamesh> kenvandine: the existing packaging was a problem, since it used the same package name for vivid and wily
[03:12] <kenvandine> jamesh, yeah, he was questioning if we really needed that
[03:12] <jamesh> kenvandine: from my reading of the migration docs, it should have had "v5" appended to the end of the package name to make upgrades go smoothly
[03:13] <jamesh> kenvandine: given that it is an ABI break, it seemed worth doing now rather than later.
[03:13] <kenvandine> anyway, if we can get the depends dropped from qtubuntu-media it could unblock the packages in proposed
[03:13] <kenvandine> assuming it properly picks up the depends without the hard coded depends
[03:13] <jamesh> kenvandine: shouldn't it just require a rebuild?
[03:14] <jamesh> none of the -dev packages have changed
[03:14] <kenvandine> qtubuntu-media has a depends on libmediascanner-2.0-3
[03:14] <kenvandine> specifically
[03:14] <kenvandine> jamesh, see bug 1500859
[03:14] <ubot5`> bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Confirmed] https://launchpad.net/bugs/1500859
[03:15] <jamesh> that is surprising
[03:15] <kenvandine> but we can't build that in the same silo because qtubuntu-media can't handle dual landings right now
[03:15] <kenvandine> yeah, i don't think it should need that depends
[03:16] <jamesh> so neither of the .so files in qtubuntu-media link to the library
[03:16]  * jamesh looks
[03:16] <kenvandine> oh joy
[03:17] <kenvandine> so it really shouldn't depend on it
[03:17] <jamesh> unless they are doing something particularly cunning
[03:17] <jamesh> (I hope not)
[03:17] <kenvandine> indeed
[03:20] <jamesh> it looks like it is used from some source code that may not be linked into the plugin?
[03:20] <kenvandine> dunno, we should get jhodapp too look at it more closely
[03:20] <jamesh> it is explicitly linking to mediascanner, but the requirement is likely being removed because the .so doesn't actually use any symbols from the library
[03:21] <jamesh> I'll add some notes to the bug report.
[03:21] <kenvandine> jamesh, thanks!
[03:31] <jamesh> kenvandine: here's what I've added: https://bugs.launchpad.net/ubuntu/+source/qtubuntu-media/+bug/1500859/comments/3
[03:31] <ubot5`> Ubuntu bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Confirmed]
[05:08] <Mirv> mornings
[05:11] <slangasek> jamesh: if it needed v5 appended to the package name, it would have been done already as part of the g++5 rebuilds; you don't need to make an soname change *now* for the g++5 abi transition
[05:11] <jamesh> slangasek: it definitely had cxx11 tagged symbols, and definitely didn't have the package name changed as part of the transition
[05:12] <slangasek> jamesh: right; so as I understand it, someone already made the determination that a library rename wasn't needed for this case
[05:13] <jamesh> slangasek: then they made the determination wrongly.  The library compiled with gcc 5 has a different ABI (it uses std::string, and is compiled with C++11), so the package name needs to be different
[05:14] <slangasek> std::string is part of the API that it exports?
[05:14] <jamesh> slangasek: yes.  Here is the debdiff of the update doko pushed: http://launchpadlibrarian.net/213231546/mediascanner2_0.105%2B15.10.20150721-0ubuntu1_0.105%2B15.10.20150721-0ubuntu2~ppa1.diff.gz
[05:14] <jamesh> you can see many symbols file changes and no binary package name change
[05:15] <slangasek> hmm, ok
[05:17] <slangasek> jamesh: looking at that diff I agree with you, so I don't know why it was done without a package name change
[05:17] <kenvandine> so we just need to sort out the depends in qtubuntu-media to unclog wily
[05:18] <slangasek> jamesh: still, the package from this silo doesn't appear to change the package name in a predictable way (appending v5), but instead has incremented the soname... what happens if there's an ABI change to the package in vivid?
[05:18] <slangasek> or maybe this is part of the SDK so that should never happen :)
[05:18] <slangasek> kenvandine: yes, I think so
[05:18] <jamesh> slangasek: if there is an ABI change, both sonames would need to change
[05:19] <slangasek> jamesh: alright, as long as that's understood :)
[05:19]  * kenvandine heads off to get some sleep, thanks for looking into it
[05:19] <jamesh> slangasek: I added some notes about the qtubuntu-media problem to the bug report: https://bugs.launchpad.net/ubuntu/+source/qtubuntu-media/+bug/1500859
[05:19] <ubot5`> Ubuntu bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Confirmed]
[05:19] <jamesh> slangasek: it looks like there is no code in the binary package that actually uses libmediascanner
[05:20]  * slangasek nods
[08:17] <greyback_> cihelp: hey, we're getting "virtual memory exhausted" errors for amd64 builds: https://jenkins.qa.ubuntu.com/job/qtmir-vivid-amd64-ci/148/console
[09:16] <Saviq> sil2100, we got a silo lined up with a few high prio fixes for qtmir, but we've also planned to land proper mouse pointer/cursor for pocket desktop in that same silo, with OTA7 freeze in effect, shall we pull the mouse bits out?
[09:18] <Saviq> sil2100, in theory they don't touch phone until you connect a mouse up
[09:18] <sil2100> Saviq: that's a tricky one
[09:19] <sil2100> Saviq: so normally I would say: 'just pull it out', but I know we have some pressure on PD recently - I wouldn't include it without Pat's approval though, as he has the exception decisive power
[09:20] <sil2100> Saviq: maybe for now pull it out so that it doesn't slow you down and you can try re-landing it a bit later, after we get Pat's input here
[09:20] <Saviq> sil2100, yeah, that's probably best, OTOH means double QA effort
[09:21] <sil2100> Saviq: true, but I know QA said they even prefer signing off smaller silos instead of big ones - bigger chances of missing stuff
[09:22] <sil2100> We even had that idea of only limiting to a few bug fixes per silo ;p
[09:22] <Saviq> sil2100, ack, /me pulls mouse
[09:22] <sil2100> (which didn't stick)
[09:22] <Saviq> sil2100, btw, is wily+overlay a thing yet?
[09:22] <sil2100> Saviq: not yet, but we'll want to have it later today/tomorrow
[09:22] <sil2100> We have a green light for it though
[09:23] <Saviq> k
[09:24] <Saviq> sil2100, my ticket does say overlay as the destination PPA (it didn't before), that expected?
[09:25] <sil2100> Saviq: let me check, maybe something happened during the night
[09:25] <Saviq> sil2100, basically, my q is, is https://requests.ci-train.ubuntu.com/#/ticket/420 set up correctly?
[09:25] <rvr> abeato: I failed the silo. The pause/play button in the indicator doesn't synchronize with the music-app.
[09:26] <abeato> rvr, thanks, I saw that, music-app still needs some work to get this finally working
[09:28] <sil2100> Saviq: so, I need to look into the backend, but most probably you assigned the silo when it was still possible to target dual landings for an explicit destination
[09:29] <Saviq> sil2100, it was like Monday evening or something
[09:29] <Saviq> actually req says last Thursday, even
[09:30] <Saviq> sil2100, https://ci-train.ubuntu.com/job/prepare-silo/6246/
[09:32] <sil2100> Saviq: so, I think it's ok, the destination field should be left empty as for dual silos it's not taken into consideration right now
[09:32] <sil2100> As we hard code the dest there
[09:32] <sil2100> For a moment it was switched to be configurable for dual silos, but as per slangasek's recommendations it was switched back to hard-coded
[09:32] <sil2100> As we don't want people landing things in wrong places by mistake
[09:33] <sil2100> I'll hard-switch it to the overlay later
[09:40] <Saviq> sil2100, ack
[09:58] <alf_> cihelp: Hi! http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-runner-mako/ jobs have a long backlog because of "pending - Waiting for next available executor on mako-mir"
[09:59] <alf_> cihelp: Any idea what's going on there? It seems that only two mako-mir executors are online...
[10:00] <alf_> cihelp: This is making CI builds take extremely long (e.g. one job is already "building" for more than 9,5 hours)
[10:05] <greyback> trainguards: could someone delete the "unity-api" packages from silo15 plz
[10:05] <sil2100> greyback: on it
[10:06] <greyback> sil2100: thanks
[10:06] <sil2100> Done
[11:09] <jgdx> rvr, thx
[11:09] <sil2100> dbarth_: if you don't mind I'll play around with landing 005 for a bit
[11:09] <sil2100> dbarth_: (add some merges, rebuild etc.)
[11:10] <sil2100> dbarth_: it's the papi landing
[12:48] <kgunn> sil2100: are we doing dual landing into overlay for wily yet ? or just keep our dual landing silo as is...
[12:50] <oSoMoN> trainguards: can the failed builds in silo 59 be retried, please?
[12:56] <dbarth_> sil2100: oh sure, go ahead; it'd be awesome to land that one!
[13:01] <Mirv> oSoMoN: on it
[13:01] <oSoMoN> thanks
[13:18] <sil2100> kgunn: just keep them as is, the transition will be transparent ;)
[13:21] <sil2100> tvoss, dbarth_: the papi in silo 15 has built successfully \o/
[13:29] <kgunn> ooo i love it
[13:31] <dbarth_> sil2100: super !
[13:39] <tvoss> sil2100, great,thank you
[13:43] <Mirv> oSoMoN: ^
[13:43] <Mirv> (built)
[13:45] <oSoMoN> Mirv, thanks!
[14:07] <alf_> cihelp: Hi! Any updates about all but one mako-mir builders being offline (see ping earlier today and http://s-jenkins.ubuntu-ci:8080/label/mako-mir/?). This is really hurting our CI/autolanding times.
[14:36] <rvr> barry: Silo 8 merge proposal needs review and approval
[14:38] <barry> rvr: yes.  i am currently working through the test plan.  it will need release team approval too (it's targeted at wily)
[14:49] <fginther> alf_, hello. Sorry for the delay. One of the devices failed and it's coming back up now. I'm also trying to work in some replacements for some devices that are now unusable
[14:49] <Saviq> fginther, hey, I've seen failures like that in multiple jobs these past few days https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-wily/416/console
[14:54] <fginther> Saviq, ugh! I'll add that to the list, but I'm not sure that one isn't caused by a test process that doesn't exit properly
[14:54] <Saviq> fginther, thanks
[14:54] <jibel> dbarth_, is silo 2 for ota7?  it seems a bit huge to land so late without risk, it doesn't bring features from the features list and no critical bug fixes?
[14:55] <fginther> I've seen it before, but the solution is escaping me. Will see if I can find some notes on it.
[15:11] <dbarth_> jibel: not really for ota-7, we should put it aside for now
[15:12] <dbarth_> jibel: is there a parking lot for silos like these, or i should abandon temporarily to free up silos?
[15:15] <seb128> jibel, pete-woods, we (desktop) need/want to land unity7 theme fixes (which are in silo 24 as well) to wily, should we just upload to wily (and let you sort out the silo then) or do you plan to QA review/land silo 24 today or tomorrow?
[15:16] <pete-woods> seb128: I would like to run the silo through QA as fast as possible
[15:16] <pete-woods> it's been reviewed now
[15:16] <pete-woods> I was just ill for a couple of days
[15:16] <pete-woods> can mark as ready
[15:17] <seb128> pete-woods, that would be nice, I added a bugfix for eog while you were not there, should be a noop for the phone
[15:18] <pete-woods> seb128: ah yeah
[15:18] <pete-woods> seb128: does it need rebuilding?
[15:18] <barry> sil2100: question about landing policy, if you have a few minutes
[15:18] <sil2100> barry: hey! What's up?
[15:18] <pete-woods> looks like you already built :)
[15:18] <seb128> pete-woods, I did rebuild
[15:18] <seb128> right
[15:19] <seb128> Laney, did you have one more branch to add to that?
[15:19] <barry> sil2100: hi!  so silo 8 has s-i 3.0.2.  it's built and i've done qa.  i think it's ready to land, but of course wily is in final beta.  i'd like to get this bug fix into wily.  what do i do next?
[15:19] <seb128> Laney, or did you just ask about https://code.launchpad.net/~larsu/ubuntu-themes/eog-overlay-buttons ?
[15:19] <Laney> just that one
[15:19] <seb128> good
[15:20] <jibel> dbarth_, we should take a snapshot of the overlay soon to unblock landings like yours
[15:21] <sil2100> barry: I suppose you can still publish it to wily and poke the release team to review the new upload and move it out from the UNAPPROVED queue
[15:21] <sil2100> barry: since system-image isn't seeded in any desktop image (besides -next)
[15:21] <barry> sil2100: okay cool thanks.  i wasn't sure if there was some train station i needed to stop at first
[15:22] <Laney> You shouldn't poke unless it is taking a long time
[15:22] <sil2100> barry: no, for wily it's rather just a button press and then poking the release team
[15:22] <sil2100> barry: ok, so no poking!
[15:22] <sil2100> As per Laney's response
[15:22] <Laney> there's a queue that people regularly look at
[15:22] <Laney> https://launchpad.net/ubuntu/wily/+queue?queue_state=1
[15:22] <barry> Laney, sil2100 okay, will do thanks!
[15:22] <Laney> cool
[15:23] <dbarth_> jibel: ok, that'd be great; feel free to put the silo aside for ota-7 qa already, and we can get back to that when the new overlay opens
[15:31] <barry> yay! the abyss was not a terrible movie
[15:45] <jhodapp> kenvandine, slangasek I removed the mediascanner dependencies from qtubuntu-media and it's building in silo 47 now
[15:46] <kenvandine> jhodapp, thx
[15:46] <jhodapp> np
[19:32] <kgunn> ev: fginther not sure who to ping, but mir project ci has kind of ground to a halt...i understand all but 2 makos are down
[19:32] <kgunn> you guys aware ?
[19:37] <fginther> kgunn, yes, ev is the right person for this. He should be able to give you an update on where we are with replacing the makos that have died recently
[19:39] <kgunn> thanks
[19:40] <kgunn> ev: please let us know, we might need to prioritize some mp's....rate is about 6/7hrs now due to traffic jam
[19:52] <fginther> kgunn, ev is still in a meeting, but he shot me a quick message to re-allocate some resources to help here. He'll try to follow-up with you a little later
[19:53] <kgunn> thanks!
[20:12] <fginther> kgunn, I've added a couple of krillin to the pool of devices. The job name is still "mir-mediumtests-runner-mako" but please note that it could be either a mako or krillin. I'll get the name fixed once the backlog is down
[20:12] <kgunn> fginther: thanks, hope that works
[21:01] <robru> to anybody that might be around: I just rolled out a Bileto update, if you get broken links it's because your page is stale, just reload the page and it should work again.
[23:23] <robru> am I the only one who can't connect to irc.canonical?
[23:24] <thomi> robru: I'm connected...
[23:24] <robru> bah