[00:08] <robru> rsalveti: you around to kick an image? rtm1 landed some time ago
[00:19] <sil2100> robru: I'll kick it then
[00:19] <sil2100> Just didn't know if rsalveti didn't do it already ;)
[00:19] <robru> sil2100: ah i forgot you can do it
[00:23] <sil2100> Image build running
[00:25] <imgbot> [00:28]  * sil2100 goes to sleep o/
[00:28] <robru> sil2100: goodnight!
[00:28] <sil2100> Goodnight!
[00:41] <ToyKeeper> Ah, good...  the image is building after all.  I forgot to check back on it.
[00:41] <robru> ToyKeeper: heh, only 3 hours after the silo published ;-)
[01:08] <kenvandine> robru, thanks!
[01:08] <robru> kenvandine: you're welcome!
[01:40] <imgbot> [01:40] <imgbot> [02:02] <rsalveti> great, was going to build one after dinner, but you guys did that already
[02:15] <imgbot> [03:40] <imgbot> [03:40] <imgbot> [05:56] <Mirv> morning
[05:58] <bzoltan_> hello Mirv, I see that QA has an exceptional long queue... UITK is waiting for to be checked since Tuesday
[05:59] <Mirv> bzoltan_: yes, and they also simply have other work too like full image testing for the milestone
[05:59] <bzoltan_> Mirv: yes, I do not dare to complain... I have seen in the trello, that there are 7 days old silos in front of the UITK. I wonder how could we help the A process.
[06:01] <Mirv> bzoltan_: more QA people :) I don't think there's much else - they do know the queue, and they make decisions on how to allocate the people every day
[06:02] <Mirv> bzoltan_: anyway, it'd be nice to get the uitk silo "out of the way" since I'll need to rebuild it then for Qt silo.
[06:03] <bzoltan_> Mirv: We would need to check with the QA folks, because if the silo validation will take a day more then I would push there fixes long waited by bfiller. In that case of course I would re-run the test plan. But that is only 12 hours :)
[08:37] <ogra_> sil2100, didnt we disable cron builds ?
[08:37] <ogra_> oh, they are disabled
[08:40] <sil2100> ogra_: yeah, but I built one image manually yesterday
[08:41]  * sil2100 seems to have issues with thunderbird today
[08:42] <sil2100> Crap, need to reboot
[08:46] <sil2100> heh, I wonder what happened, my home directory didn't get decrypted last boot
[08:47] <seb128> it didn't or something unmounted it later on?
[08:47] <ogra_> must be the NSA patch :)
[08:50] <seb128> sil2100, could be bug #1430557
[08:51] <sil2100> Not sure, I ended up in a session with my home directory encrypted after logging in, but syslog doesn't seem to have any mention of anything
[08:51]  * sil2100 checks the logs for what's in the bug
[08:54] <ogra_> Mirv, i'D like to merge https://code.launchpad.net/~bzoltan/ubuntu-seeds/add_QtWebSocket/+merge/252303 are there any technical objections ?
[09:08] <Mirv> ogra_: no, it's meant for apps since some dev(s) requested it, and it's supported by upstream
[09:08] <Mirv> I mean, no objections
[09:09] <Mirv> I think it first was released as part of qt 5.3
[09:09] <ogra_> some devs <--
[09:09] <ogra_> ;)
[09:10] <bzoltan_> jibel: I see you have a massive QA backlog. I wonder if you could estimate when the QA team will pick up the silo13? I am asking because if you think that it is longer than 15-16 hours then I would push few more bugfixes to the silo and spin an other Test plan execution before you take it.
[09:11] <sil2100> bzoltan_: QA is really busy with OTA-2 promotion testing right now
[09:11] <sil2100> The schedule is tight
[09:12] <jibel> bzoltan_, Hey, yeah we're on the OTA this week, so the earliest would be tomorrow afternoon, but more likely Monday
[09:12] <jibel> bzoltan_, so more than 15h
[09:12] <bzoltan_> jibel:  cool, thanks. In this case I spin this silo again with few more fixes. Thank you
[09:13] <jibel> yw
[10:03] <popey> Mirv: updated my nexus 7 to latest vivid, seems fine
[10:33] <Mirv> popey: thanks. there seems to be a problem on mako after qml cache clean (including image upgrade), but at least this issue is then not a regression in the qt patches
[12:16] <Mirv> sil2100: there are/were two issues. the first issue (black background/hang) is there on normal vivid too and there was even a bug about it. but the 2. issue is that it happens more often with the 5.4.1 PPA, and that's most likely because of the other last minute patch that was put in yesterday to fix deadlock (it seems it actually introduces more of it). a revert armhf build should be ready in eg. 2h, after which unity8 folks will revalidate it.
[12:17] <Mirv> sil2100: the good news is that I also ran AP:s yesterday already before the last patches and they were ok then, so it's mostly down to retesting unity8.
[12:18] <Saviq> psivaa_, hey, any progress on adding the strip native hook to unity-api-ci?
[12:18] <Mirv> I'll keep you updated
[12:19] <psivaa_> Saviq: that was added, let me check if the update was applied to the configs
[12:22] <psivaa_> Saviq: the the change has been deployed too, do you have any link to the job that it was supposed to run on?
[12:22] <sil2100> Mirv: good news then
[12:23] <sil2100> Mirv: well, better not risk it, I guess 5.4.1 upstream code should be relatively safe in most cases
[12:23] <Saviq> psivaa_, here's the public instance https://jenkins.qa.ubuntu.com/job/unity-api-ci/?
[12:23] <Saviq> psivaa_, this job just ran today https://jenkins.qa.ubuntu.com/job/unity-api-ci/289/parameters/?
[12:24] <psivaa_> Saviq: let me check
[12:29] <Mirv> sil2100: yes, and this patch in question actually made it already to 5.4 branch in upstream so it needs to be reverted there too since it actually did not fix the problem but actually cause (somewhat) more of the same problem..
[12:30] <sil2100> Ouch
[12:35] <Mirv> sil2100: I will no longer agree to try address non-5.4.1 bugs in the PPA, which I still yesterday thought is a good idea :)
[12:36] <Mirv> so we'll try to confirm this yesterday's version was indeed ok, and then to fix the already-on-vivid bug we can experiment in another silo
[12:36] <psivaa_> Saviq: do you have the MP that is triggering this. i just deployed the changes again and want to try that
[12:37] <Saviq> psivaa_, I'll trigger it, thanks
[12:38] <psivaa_> Saviq: this time i can confirm that the changes are in effect, so that should be picked up
[12:38] <Saviq> psivaa_, will report back if it's not good yet
[12:38] <ralsina> Hello trainguard, can I get a reconfigure in silo 16? tsdgeos gave me a simple packaging fix and I'd like to land it together with what was there
[12:38] <psivaa_> sorry i should have deployed it once I made the change
[12:38] <sil2100> ralsina: o/
[12:38] <sil2100> On it
[12:38] <ralsina> thanks sil2100!
[12:41] <sil2100> ralsina: should be reconfigured
[12:41] <ralsina> sil2100: cool, thx
[12:45]  * sil2100 lunch
[14:22] <jhodapp> sil2100, hey what's going on here? https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-002-1-build/158/console
[14:23] <jhodapp> sil2100, nm, I see it
[14:49] <bregma> cihelp, we aren't seeing any CI bots build-testing our MPs any more, at least for Unity 7, is there a bot bug?
[14:49] <Ursinha> hi bregma, I'll have a look -- do you have an example link?
[14:51] <bregma> Ursinha, https://code.launchpad.net/unity/+activereviews shows about a dozen MPs sumbitted over the last 20 hours, none of which have had attention from the CI bot (usually the magic happens within a few hours)
[14:51] <bregma> I see nothing queued on s-jenkins
[14:51] <Saviq> jfunk, hey, who do I talk to about silo validation?
[14:53] <sil2100> Saviq: I guess jibel is the main person for QA ops
[14:53] <sil2100> But everyone is really busy with OTA-2
[14:53] <Saviq> sil2100, yeah, I just really wanna ask whether I should just abandon a unity8 that's up for testing since Monday and overwrite it with a bigger one I'm blocked on...
[14:54]  * Saviq got 20 MPs ready to land for unity8 alone
[14:56] <sil2100> Saviq: from what I know the soonest QA can resume silo sign-off would be tomorrow
[14:56] <Saviq> ok... sounds like reconfigure time
[14:57]  * Saviq didn't want that huge silo, but can't wait any more, is stoopid
[15:00] <sil2100> jibel, davmor2, popey, robru, rvr: anything you'd like to discuss during the evening meeting?
[15:01] <robru> sil2100: nope
[15:04] <bregma> Ursinha, MPs not getting CI love are all on a branch (as opposed to trunk), looks like CI has never been running on that branch -- not a CI Bot bug
[15:04] <bregma> Ursinha, but that said, can we get CI running on that branch?
[15:05] <Ursinha> hmm, bregma thanks for the information
[15:10] <sil2100> jibel, robru, davmor2, popey, rvr: if there are no objections, I'll cancel todays meeting again - let's meet tomorrow once all testing is done and we can talk through what to do next week
[15:10] <popey> ok
[15:11] <rvr> sil2100: Ack
[15:12] <rvr> Saviq: Yeah, we are right now quite busy testing OTA-2. Hope that silo comes with lots of automated tests ;P
[15:12] <Saviq> rvr, they always do :P
[15:13] <rvr> Saviq: What changes are coming in that one?
[15:14] <Saviq> rvr, I'm merging http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-020 into http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-006 (and then some)
[15:14] <davmor2> I don't know you give sil2100 power over a calendar and he cancels all the meetings ;)
[15:14] <jfunk> Saviq: you can ping ops-team in #ubuntu-quality
[15:15] <Saviq> tx
[15:15] <rvr> davmor2: Don't mess with sil2100, he's practicing and can kick you in the *ss
[15:15] <sil2100> hah ;)
[15:16] <sil2100> I only have practice sessions on Tuesdays
[15:16] <sil2100> I'm just effectively working on getting rid of the twice-daily meetings!
[15:16] <rvr> davmor2: Thanks god is Thursday
[15:18] <davmor2> rvr: he doesn't scare me that's for defence it says so in the rule book, I just don't have to strike him first \o/
[16:19] <robru> sil2100: hey, can you think of any packages we land with the train that use epochs in their version numbers?
[16:20] <robru> sil2100: actually any package at all that uses it... need to test something ;-)
[16:34] <sil2100> hm, through the train? Do you mean like MP-based one? Or a source package one is enough?
[16:39] <cjwatson> robru: compiz
[16:40] <robru> cjwatson: ah thanks
[16:41] <robru> sil2100: any will do, I'm just touching the code that downloads source packages, need to make sure it can find the dsc file, which doesn't have the epoch in it
[16:44] <dobey> ToyKeeper: pay-ui CI build config has been fixed, and i've put the new click package URL in the spreadsheet and in a comment on trello. sorry about that, and thanks for testing. :)
[16:45] <robru> jhodapp: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-005-1-build/lastFailedBuild/console did you mean to click on ubuntu 5 instead of rtm 5? ;-)
[16:45] <jhodapp> robru, no, I meant to click on 2 :)
[16:45] <robru> ah
[19:54] <elopio> ping cihelp
[19:55] <elopio> Kaleo has here a qml test that fails with createPlatformOpenGLContext
[19:55] <Ursinha> elopio: hi
[19:55] <elopio> https://launchpadlibrarian.net/200047799/buildlog_ubuntu-vivid-armhf.camera-app_3.0.0%2B15.04.20150312-0ubuntu1_BUILDING.txt.gz
[19:55] <elopio> what are our options here? can we get rendering capabilities on the machine that builds the packages?
[19:55] <elopio> hello Ursinha
[19:57] <elopio> would it work to call the qml tests in an xvfb ?
[19:57] <Ursinha> elopio: it's building in launchpad, right?
[19:59] <elopio> Ursinha: right.
[20:00] <Ursinha> elopio: okay, I have to check what the possibilities are
[20:00] <Ursinha> do you mind if I get back to you tomorrow on that?
[20:01] <elopio> Kaleo: can you give it a try with xvfb in the meantime?
[20:01] <elopio> the address book has a cmake file that sets it up.
[20:02] <Kaleo> elopio, ok, good idea
[20:03] <elopio> Ursinha: I'm not in a hurry, ever. I'm not sure Kaleo.
[20:03] <Ursinha> it seems you have a workaround for now, but I'm taking notes in a card I created for this
[20:05] <elopio> Ursinha: yes. I think what we need to know is if everytime we need a display during build time we will have to use xvfb.
[20:06]  * Ursinha takes notes
[20:58] <dobey> hmm
[20:59] <dobey> elopio: yeah, until there is a mirvfb, any time you need a display during build for tests to do stuff in, you're going to have to use xvfb
[21:48] <Kaleo> elopio, dobey, Ursinha: we really probably shouldn't have to manually launch xvfb or mirvfb in every package's tests
[23:39] <Ursinha> bregma: just a heads up: I'll work on enabling CI for lp:unity/7.2 first thing in the morning