[05:16] <Mirv> renatu: still there? did you see questions from allan on silos 064 and 039?
[05:17] <Mirv> renatu: "Is a new calendar app required to see this fix? I'm finding that events (e.g. a breakfast appointment) no longer appear in day view to verify."
[07:16] <koza> trainguards, who could help in understanding/resolving a strange issue with silo 51?
[07:18] <robru> koza: what's the issue? Looks fine to me
[07:20] <koza> robru, it segfaults when installed on the device [latest image] however when compiled on device [using chroot] works fine. Could it be some kind of clash opf gcc versions [on chroot is gcc version 4.9.2 (Ubuntu/Linaro 4.9.2-10ubuntu13)] or mismatch in libs?
[07:21] <robru> koza: oh i have no idea about that. You should talk to the branch author or somebody who knows about the project in question. I just help if the ticket itself has an issue
[07:23] <koza> robru, I see, thanks
[07:23] <robru> You're welcome
[07:32] <Mirv> koza: also 4.9.2-10ubuntu13 was used for the PPA builds as seen in the build logs
[07:32] <Mirv> koza: vivid + stable-overlay don't have toolchain variations, so I can't think of too many things that could be different in PPA builders or on device
[07:33] <Mirv> koza: did you compile with for example 'debuild' on device or more like make / make install? using the packaging via debuild might bring some different compilation options compared to you running compilation manually
[07:34] <Mirv> koza: you can also install gdb and debug symbols on the device to try to get backtrace, although I'm not sure how qtubuntu-media/media-hub should be started in debug mode
[07:34] <koza> Mirv, so we have the same gcc version
[07:35] <koza> do not know how it was compiled on chroot as jhodapp did it however will check once he is online
[07:36] <Mirv> koza: yeah you'll probably need jhodapp to help in debugging that
[07:38] <koza> Mirv, thanks for extra info. we will take it from here and will see how it goes
[11:02] <om26er> popey, Hi!
[11:03] <om26er> popey, I need to land latest dekko, who can I request to create a silo ? I am volunteering to test it.
[11:12] <popey> om26er: it's already in a silo
[11:12] <popey> om26er: https://trello.com/c/3u8N2Xw8/3077-1280-dekko-popey
[11:13] <om26er> popey, great, one question though. how much effort/work will it be to land this change in that silo ? https://git.launchpad.net/~om26er/+git/dekko/commit/?id=81da994204079a620b04372c0be9e38697f17938
[11:13] <om26er> Just 4 lines and it will unblock me completely
[11:13] <popey> ask Dan
[11:13] <popey> testing has already started so it might have to wait for the next release
[11:14] <jibel> om26er, rvr is already testing it
[11:16] <om26er> jibel, popey, ok. this current silo has quite a few changes that I wanted for my tests. I will pursue another release once this lands then.
[12:00] <Saviq> trainguards, I just abandoned two silos and still can't assign any, says no silos available - that true?
[12:04] <Mirv> Saviq: does seem incorrect, there should be 19 free
[12:04] <Mirv> Saviq: might be a problem with the train then
[12:04] <Saviq> Mirv, https://ci-train.ubuntu.com/job/prepare-silo/
[12:04] <Mirv> Saviq: yeah I'm getting the same
[12:05] <Saviq> https://requests.ci-train.ubuntu.com/#/500
[12:05] <Mirv> unless sil2100 knows of any magic knobs we need to wait for robru. I remember in the past there was another situation like this, and back then even freeing up yet another silo did not help anything.
[12:05] <Saviq> oh well https://requests.ci-train.ubuntu.com/static/error.gif
[12:05] <Mirv> we can stare at that
[12:05]  * Saviq runs around waving frantically
[12:07]  * Saviq has a feeling robru is our SPOF 
[12:08] <jhodapp> koza, Mirv I compiled it on device with "cd build; qmake ..; make -j3" and then copied the resulting .so file into the appropriate place under /usr
[12:30] <sil2100> hmmm
[12:31]  * sil2100 takes a look at that
[12:32] <sil2100> This will take a bit as I'm no longer up-to-date with the train code
[12:34] <sil2100> I htink I see one possible issue
[12:44] <sil2100> uuuu, looks like latest change in bileto broke it
[12:47] <sil2100> Mirv, Saviq: it looks like the reason this does not work is because robru removed the 'distribution' dropdown from bileto
[12:47] <sil2100> Mirv, Saviq: so now it's not really possible to set the target distribution to 'ubuntu', it's left as '' by default
[12:47] <sil2100> Mirv, Saviq: which makes CI Train think there are no silos available for this dest, as it doesn't know silos for the '' distribution
[12:48] <sil2100> In other words:
[12:48] <sil2100> I'll try to work-around it somehow
[12:48] <Saviq> ack
[12:49] <sil2100> I say 'work-around' because I do not know what plans robru had with removing the distribution field
[12:56] <sil2100> Saviq: ok, so I assigned your silo by hacking around the javascript - let me now try to get that into production
[12:57] <Saviq> sil2100, ack, thanks
[13:02] <robru> sil2100: oh god I'm so sorry
[13:03] <sil2100> robru: I have a workaround (just re-adding the distribution field) but not sure if that's what you planned having ;)
[13:04] <sil2100> btw. wow, isn't it like, super still-dark-outside morning at your place?
[13:04] <robru> sil2100: up early instead of up late
[13:04] <robru> sil2100: you could have reverted the latest commit and rolled that out
[13:06] <sil2100> robru: yeah, well, I just made a 1 line diff for now, can I push it to lp:bileto or you prefer to fix it more properly? I wouldn't want you to work when you have a free day ;)
[13:06] <sil2100> (or a revert, if that's safe to do)
[13:07] <robru> sil2100: just push it to trunk, it's my fault, once I'm more awake (in some hours) I'll fix it better
[13:07] <robru> sil2100: glad you figured it out
[13:09] <sil2100> robru: ok! Yeah, the workaround should just work for now, go back to sleep or get some coffee ;)
[13:09] <robru> sil2100: once it's on trunk just get webops to run a configger as per the wiki, should be smooth sailing
[13:09] <robru> sil2100: thanks yeah, I'll go back to sleep ;-)
[13:20] <sil2100> robru, Mirv, Saviq: the 'fix' will be deployed by webops in the nearest moments
[13:36] <Mirv> sil2100: thanks a lot!
[13:42] <sil2100> Mirv, Saviq: fix deployed! Please be sure to edit your requests and set the distribution field
[13:44] <sil2100> I suppose CI Train should just default to 'ubuntu' if distribution is '', but yeah, robru will decide on the final fix
[13:53] <Saviq> ack
[15:18] <Saviq> robru, hey, I just realized... what are you using to push to lp:~ci-train-bot/ branches?
[15:19] <robru> Saviq: the train is self hosting but I often just push to trunk if it's a simple fix
[15:20] <Saviq> robru, I meant to the project branches
[15:20]  * Saviq has a feeling that leaves borked tags when it --overwrites
[15:21] <Saviq> because the train tagged the previous version, pushed that to LP and then overwrites when it gets rebuilt
[15:21] <Saviq> so the tags remain on the LP branch forever...
[15:21] <robru> Saviq: oh that's possible
[15:22] <Saviq> gotta love bzr
[15:22] <robru> Saviq: so what are you wanting? dangling tags to be cleared?
[15:23] <robru> Saviq: yeah it just tags the release commit and then 'bzr push lp:~ci-train-bot/project/.... --overwrite'
[15:23] <Saviq> robru, by now - not really, since everyone has them already ;)
[15:23]  * Saviq almost gave up on bzr tags
[15:24] <robru> Saviq: what are you trying to use tags for and how is it not working? eg if you're looking at version numbers in debian/changelog those should all correspond to bzr tags (at least in xenial, the vivid half of a dual silo wouldn't)
[15:24] <robru> Saviq: also it should be easy to ignore dangling tags eg if you're trying to parse the output of 'bzr tags' because it just lists the tag without any revid.
[15:25] <Saviq> robru, sure, /me just dies a little every time I see them :P
[15:25] <robru> Saviq: write a script to delete them yourself ;-)
[15:25] <Saviq> robru, http://people.canonical.com/~msawicz/unity8/
[15:25] <Saviq> check out the date :P
[15:26] <robru> Saviq: so this was a problem 1.5 years ago and you're only just telling me now? :-P
[15:26] <Saviq> robru, no, back then it was us inheriting lp:unity tags
[15:27] <Saviq> robru, because we were hosting at lp:unity/8.0
[15:27] <robru> ah
[15:27] <robru> Saviq: file a bug I guess but it'll be quite some time until I get around to it, I'm off for the rest of the month
[15:28] <Saviq> robru, and we *almost just* got rid of them, but every now and again someone pops up with an old checkout in an MP and EVERYTHING has them again
[15:28] <Saviq> robru, yeah, I don't care any more really... looking forward to git ;P
[15:28] <robru> Saviq: yeah me too, once the parallelization/ephemeral PPA work is done it should be easy to add git support.
[15:29] <Saviq> robru, any reason why you didn't just land inline gles bits? ;)
[15:29] <Saviq> can we just sneak them in under the train? managing any silo while those are not landed is just meh
[15:29] <robru> Saviq: what do you mean? you want me to push my branches to trunks?
[15:29] <Saviq> robru, yeah ;P
[15:30] <robru> Saviq: because it was the last couple days before OTA10 was released and I didn't want to invalidate any silos by having unbuilt trunk commits in case there was a silo already in QA or something.
[15:30] <robru> Saviq: are they not all landed yet? the branches should be in every silo
[15:30] <Saviq> robru, yeah, problem arises as soon as any of the branches touches debian/control
[15:30] <Saviq> then you have to rebase on that
[15:31] <Saviq> robru, </complaining>, I'll manage
[15:31] <robru> Saviq: right. so I made a silo with my own branches but it never landed...
[15:32] <robru> Saviq: this is the future you chose, you have to rebase the patch every time you touch control file anyway ;-)
[15:32] <Saviq> robru, that's fine when it's in trunk
[15:32] <Saviq> but until then it's meh
[15:33] <Saviq> robru, really, our fault, I'll manage
[15:33] <robru> Saviq: https://requests.ci-train.ubuntu.com/#/ticket/1221 buh I forgot to signoff after the most recent rebuild. want me to submit it for QA?
[15:34] <robru> Saviq: I hadn't anticipated that so many qtmir/qtubuntu silos would just sit around for so long, I assumed you guys were actually landing silos with some frequency.
[15:34] <Saviq> robru, we are, except when there's OTAs, Ubuntu freezes, *things*
[15:35] <Saviq> robru, no, we've got another silo with this already - you can abandon, really
[15:35] <robru> Saviq: ok will do
[17:27] <Saviq> robru, hmm, do you know what's with https://ci-train.ubuntu.com/job/ubuntu-landing-069-0-status/7179/console ? did the packages fail to upload, or do you think it's just waiting?
[17:29] <robru> Saviq: how long has it been since you ran the build?
[17:31] <Saviq> robru, https://ci-train.ubuntu.com/job/ubuntu-landing-069-1-build/32/ ½h
[17:31] <Saviq> and they're still not there
[17:32] <robru> Saviq: Hmmmmmmm yeah that's pushing it, they should appear in just a few minutes
[17:32] <Saviq> robru, ok, will get back to you if they don't
[17:32] <Saviq> or well, will try another build maybe
[17:33] <robru> Saviq: looks like you have one running already
[17:33] <Saviq> robru, different pkg
[17:33] <robru> Ah
[17:34] <robru> Saviq: yeah you should ping Colin if the packages aren't appearing in the PPA, he can dig up the logs
[17:34] <Saviq> robru, kk
[17:54] <salem_> jibel, hi, we have a fix for bug 1571094 on silo 55, but looks like it's marked is failed because of a problem with unity8 tests.
[17:54] <ubot5`> bug 1571094 in Canonical System Image "/usr/bin/phone-gsettings-migration.py:ValueError:/usr/bin/phone-gsettings-migration.py@27:__call__:call_blocking" [High,In progress] https://launchpad.net/bugs/1571094
[17:55] <salem_> jibel, I think we had this problem before and you added the silo to the qa queue anyway. Could you do that again?