[02:33] good morning [03:06] kalikiana: I hope the tests on your side are ready... the reference tests are aleady here -> http://people.canonical.com/~bzoltan/ap-2016-04-21-VIVID-SILO20-MAKO/ [03:06] kalikiana: the next is to copy together the two test sets and run the comparition function [03:07] kalikiana: what is ./uitk_test_plan.sh -d -p 20 -o ./ [03:07] kalikiana: that will create the file with the regressing cases and their backtraces [03:07] kalikiana: let's talk when you too wake up :) === chihchun_afk is now known as chihchun [08:16] davmor2, morning! any idea what's wrong with silo 71? clearly autopkg tests failed, but no regressions reported afaict [08:19] no idea at all I'll have a dig but there should be some kinda failure listed in there, I'll have a look in a bit for you and get back to you [08:21] thanks davmor2 [09:04] davmor2, pstolowski: I looked at this strange Failure and in opinion this is just some britney mix-up [09:05] The failure is caused by britney thinking there's a left-over old binary in the package, even though it's gone since a few releases already [09:11] robru, hey, do you remember the issue we had with scopes-api after your bileto-prerelase-hook was introduced? I think there was something wrong with the SERIES variable? could this explain the issue we currently see with silo 71 ^ ? [09:14] pstolowski: pre-release-hook affects how the packages are built. Look at the diffs, if they're not wrong then that's not the issue [09:14] robru, if - by any chance - SERIES variable is not set correctly, then we would be off-by-one with so versions [09:14] The generated binary packages are correct, so not sure what britney doesn't like there [09:14] No old binaries should be left-over [09:16] pstolowski: $SERIES is definitely being set correctly, you can verify in the ppa source package that it has correct soname. [09:17] robru, you're right. okay, thanks [09:18] sil2100: i think i saw this before, try deleting old builds from the ppa. [09:18] robru: hm, let me check that, would be a really funny coincidence! [09:18] pstolowski: you're welcome [09:19] pstolowski: did this silo bump the soname or perhaps rename a binary package? [09:20] uhhhh [09:20] robru: I suppose this might indeed be the case, I see very old unity-scopes-shell packages as superseeded there [09:20] Packages since 2016-03-04! [09:20] pstolowski: is this some very old silo? [09:21] Since the train would normally delete all packages from a silo if it was assigned [09:21] sil2100: yeah if you delete all the superceded packages then britney should settle down [09:21] sil2100: the ticket will have the creation date on it [09:21] sil2100, yeah, it's been rebuilt a couple of times, and is at least 2 months old afair [09:22] robru, pstolowski: hah, yes, so this was caused by this silo being very old and having the conflicting unity-scopes-shell version in it as superseeded... [09:22] This is really strange that the superseeded packages were still considered, but yeah [09:23] robru: thanks! Would take me ages to guess that britey would be confused by those [09:24] sil2100: yeah i dunno why it does that, please file a bug and I'll make the train auto-delete superceded packages or something [09:25] robru: ok, but now you go REST! [09:25] But not like REST API, just rest [09:27] awesome [09:28] sil2100, thanks for investigating! [09:43] rvr, oh craps, silo 13 ready now - they were late changes to the branches and I forgot to ACK after looking through them [09:43] Saviq: Ack [11:39] when can I have yakkety silos :D === chihchun is now known as chihchun_afk [13:35] sil2100: hey, do you need to do anything to ensure another package's translations end up in the langpacks for phone? [13:40] dobey: hey! Is that some new package? [13:46] sil2100: not a new package, but it has translations now and has the debian/ changes to enable langpacks [13:46] sil2100: pay-service === chihchun_afk is now known as chihchun [18:40] alesage: Hey, I saw your comments in https://bugs.launchpad.net/canonical-devices-system-image/+bug/1573266 . Looks like unity8/qtmir may be rejecting it for some unknown reason. Could you check ~/.cache/upstart/unity8.log and look for REJECTED? [18:40] Ubuntu bug 1573266 in Libertine "X apps not opening on frieza" [Undecided,Incomplete] [18:44] ChrisTownsend, sure a couple mins [18:44] alesage: Thanks [18:49] ChrisTownsend, grep -C10 REJE for those logs http://paste.ubuntu.com/15988762/ [18:50] ChrisTownsend, attaching that log to bug [18:50] alesage: Hmm, really seems like puritine is not there. Could you see what 'ls -la ~/.cache/libertine-container/puritine' gives and also 'ls -la ~/.local/share/libertine' gives? [18:52] ChrisTownsend, http://paste.ubuntu.com/15988851/ [18:53] alesage: Ah, there's the problem. The ContainersConfig.json is bad. I wonder if that's how it's in the image????? [18:54] alesage: I think the image may have been created incorrectly, but it's hard to tell. [18:54] ChrisTownsend, I assure you no manual editing by me :) [18:54] ChrisTownsend, how to test? === tedg_ is now known as tedg [18:54] alesage: Yeah, that's why I suspect the image itself:) [18:55] alesage: Remove ~/.local/share/libertine/ContainersConfig.json, then either reboot or run 'initctl --session start puritine-click' and then try it again. [18:55] ChrisTownsend, ack [18:57] ChrisTownsend, now getting an XChat launch [18:58] alesage: Yeah, image is messed up. [18:58] ChrisTownsend, ok, reassign bug? [18:58] alesage: Yeah, but not sure who. [18:59] ChrisTownsend, everyone? [18:59] or alphabetically [18:59] alesage: lol, have to start somewhere. [18:59] until it sticks [18:59] alesage: I'll make a comment about the bogus ContainersConfig.json being in the image. [19:01] ok maybe it does belong in the system-image project at least and we'll expect another triage [19:01] alesage: Ack