=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:16] renatu: still there? did you see questions from allan on silos 064 and 039? [05:17] 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." === chihchun_afk is now known as chihchun [07:16] trainguards, who could help in understanding/resolving a strange issue with silo 51? [07:18] koza: what's the issue? Looks fine to me [07:20] 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] 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] robru, I see, thanks [07:23] You're welcome [07:32] koza: also 4.9.2-10ubuntu13 was used for the PPA builds as seen in the build logs [07:32] 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] 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] 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] Mirv, so we have the same gcc version [07:35] do not know how it was compiled on chroot as jhodapp did it however will check once he is online [07:36] koza: yeah you'll probably need jhodapp to help in debugging that [07:38] Mirv, thanks for extra info. we will take it from here and will see how it goes [11:02] popey, Hi! [11:03] popey, I need to land latest dekko, who can I request to create a silo ? I am volunteering to test it. [11:12] om26er: it's already in a silo [11:12] om26er: https://trello.com/c/3u8N2Xw8/3077-1280-dekko-popey [11:13] 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] Just 4 lines and it will unblock me completely [11:13] ask Dan [11:13] testing has already started so it might have to wait for the next release [11:14] om26er, rvr is already testing it [11:16] 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] trainguards, I just abandoned two silos and still can't assign any, says no silos available - that true? [12:04] Saviq: does seem incorrect, there should be 19 free [12:04] Saviq: might be a problem with the train then [12:04] Mirv, https://ci-train.ubuntu.com/job/prepare-silo/ [12:04] Saviq: yeah I'm getting the same [12:05] https://requests.ci-train.ubuntu.com/#/500 [12:05] 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] oh well https://requests.ci-train.ubuntu.com/static/error.gif [12:05] we can stare at that [12:05] * Saviq runs around waving frantically [12:07] * Saviq has a feeling robru is our SPOF [12:08] 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] hmmm [12:31] * sil2100 takes a look at that [12:32] This will take a bit as I'm no longer up-to-date with the train code [12:34] I htink I see one possible issue [12:44] uuuu, looks like latest change in bileto broke it [12:47] Mirv, Saviq: it looks like the reason this does not work is because robru removed the 'distribution' dropdown from bileto === _salem is now known as salem_ [12:47] Mirv, Saviq: so now it's not really possible to set the target distribution to 'ubuntu', it's left as '' by default [12:47] 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] In other words: === sil2100 changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? Use JenkaaS: http://bit.ly/jenkins-docs | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known issues: silo assignment currently broken [12:48] I'll try to work-around it somehow [12:48] ack [12:49] I say 'work-around' because I do not know what plans robru had with removing the distribution field [12:56] Saviq: ok, so I assigned your silo by hacking around the javascript - let me now try to get that into production [12:57] sil2100, ack, thanks [13:02] sil2100: oh god I'm so sorry [13:03] robru: I have a workaround (just re-adding the distribution field) but not sure if that's what you planned having ;) [13:04] btw. wow, isn't it like, super still-dark-outside morning at your place? [13:04] sil2100: up early instead of up late [13:04] sil2100: you could have reverted the latest commit and rolled that out [13:06] 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] (or a revert, if that's safe to do) [13:07] 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] sil2100: glad you figured it out [13:09] robru: ok! Yeah, the workaround should just work for now, go back to sleep or get some coffee ;) [13:09] sil2100: once it's on trunk just get webops to run a configger as per the wiki, should be smooth sailing [13:09] sil2100: thanks yeah, I'll go back to sleep ;-) [13:20] robru, Mirv, Saviq: the 'fix' will be deployed by webops in the nearest moments [13:36] sil2100: thanks a lot! === fginther` is now known as fginther [13:42] Mirv, Saviq: fix deployed! Please be sure to edit your requests and set the distribution field === sil2100 changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? Use JenkaaS: http://bit.ly/jenkins-docs | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known issues: if you have issues assigning silos, edit request and re-set the distribution field [13:44] I suppose CI Train should just default to 'ubuntu' if distribution is '', but yeah, robru will decide on the final fix [13:53] ack [15:18] robru, hey, I just realized... what are you using to push to lp:~ci-train-bot/ branches? [15:19] Saviq: the train is self hosting but I often just push to trunk if it's a simple fix [15:20] robru, I meant to the project branches [15:20] * Saviq has a feeling that leaves borked tags when it --overwrites [15:21] because the train tagged the previous version, pushed that to LP and then overwrites when it gets rebuilt [15:21] so the tags remain on the LP branch forever... [15:21] Saviq: oh that's possible [15:22] gotta love bzr [15:22] Saviq: so what are you wanting? dangling tags to be cleared? [15:23] Saviq: yeah it just tags the release commit and then 'bzr push lp:~ci-train-bot/project/.... --overwrite' [15:23] robru, by now - not really, since everyone has them already ;) [15:23] * Saviq almost gave up on bzr tags [15:24] 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] 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] robru, sure, /me just dies a little every time I see them :P [15:25] Saviq: write a script to delete them yourself ;-) [15:25] robru, http://people.canonical.com/~msawicz/unity8/ [15:25] check out the date :P [15:26] Saviq: so this was a problem 1.5 years ago and you're only just telling me now? :-P [15:26] robru, no, back then it was us inheriting lp:unity tags [15:27] robru, because we were hosting at lp:unity/8.0 [15:27] ah [15:27] 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] 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] robru, yeah, I don't care any more really... looking forward to git ;P [15:28] Saviq: yeah me too, once the parallelization/ephemeral PPA work is done it should be easy to add git support. [15:29] robru, any reason why you didn't just land inline gles bits? ;) [15:29] can we just sneak them in under the train? managing any silo while those are not landed is just meh [15:29] Saviq: what do you mean? you want me to push my branches to trunks? [15:29] robru, yeah ;P [15:30] 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] Saviq: are they not all landed yet? the branches should be in every silo [15:30] robru, yeah, problem arises as soon as any of the branches touches debian/control [15:30] then you have to rebase on that [15:31] robru, , I'll manage [15:31] Saviq: right. so I made a silo with my own branches but it never landed... [15:32] Saviq: this is the future you chose, you have to rebase the patch every time you touch control file anyway ;-) [15:32] robru, that's fine when it's in trunk [15:32] but until then it's meh [15:33] robru, really, our fault, I'll manage [15:33] 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] 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] robru, we are, except when there's OTAs, Ubuntu freezes, *things* [15:35] robru, no, we've got another silo with this already - you can abandon, really [15:35] Saviq: ok will do === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [17:27] 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] Saviq: how long has it been since you ran the build? [17:31] robru, https://ci-train.ubuntu.com/job/ubuntu-landing-069-1-build/32/ ½h [17:31] and they're still not there [17:32] Saviq: Hmmmmmmm yeah that's pushing it, they should appear in just a few minutes [17:32] robru, ok, will get back to you if they don't [17:32] or well, will try another build maybe [17:33] Saviq: looks like you have one running already [17:33] robru, different pkg [17:33] Ah [17:34] Saviq: yeah you should ping Colin if the packages aren't appearing in the PPA, he can dig up the logs [17:34] robru, kk === chihchun is now known as chihchun_afk [17:54] 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] 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] jibel, I think we had this problem before and you added the silo to the qa queue anyway. Could you do that again? === dpm is now known as dpm-mostly-afk === blr_ is now known as blr === salem_ is now known as _salem