[02:33] <bzoltan_> good morning
[03:06] <bzoltan_> 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] <bzoltan_> kalikiana:  the next is to copy together the two test sets and run the comparition function
[03:07] <bzoltan_> kalikiana:  what is ./uitk_test_plan.sh -d -p 20 -o ./
[03:07] <bzoltan_> kalikiana: that will create the file with the regressing cases and their backtraces
[03:07] <bzoltan_> kalikiana:  let's talk when you too wake up :)
[08:16] <pstolowski> davmor2, morning! any idea what's wrong with silo 71? clearly autopkg tests failed, but no regressions reported afaict
[08:19] <davmor2> 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] <pstolowski> thanks davmor2
[09:04] <sil2100> davmor2, pstolowski: I looked at this strange Failure and in opinion this is just some britney mix-up
[09:05] <sil2100> 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] <pstolowski> 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] <robru> 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] <pstolowski> robru, if - by any chance - SERIES variable is not set correctly, then we would be off-by-one with so versions
[09:14] <sil2100> The generated binary packages are correct, so not sure what britney doesn't like there
[09:14] <sil2100> No old binaries should be left-over
[09:16] <robru> pstolowski: $SERIES is definitely being set correctly, you can verify in the ppa source package that it has correct soname.
[09:17] <pstolowski> robru, you're right. okay, thanks
[09:18] <robru> sil2100: i think i saw this before, try deleting old builds from the ppa.
[09:18] <sil2100> robru: hm, let me check that, would be a really funny coincidence!
[09:18] <robru> pstolowski: you're welcome
[09:19] <robru> pstolowski: did this silo bump the soname or perhaps rename a binary package?
[09:20] <sil2100> uhhhh
[09:20] <sil2100> robru: I suppose this might indeed be the case, I see very old unity-scopes-shell packages as superseeded there
[09:20] <sil2100> Packages since 2016-03-04!
[09:20] <sil2100> pstolowski: is this some very old silo?
[09:21] <sil2100> Since the train would normally delete all packages from a silo if it was assigned
[09:21] <robru> sil2100: yeah if you delete all the superceded packages then britney should settle down
[09:21] <robru> sil2100: the ticket will have the creation date on it
[09:21] <pstolowski> sil2100, yeah, it's been rebuilt a couple of times, and is at least 2 months old afair
[09:22] <sil2100> 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] <sil2100> This is really strange that the superseeded packages were still considered, but yeah
[09:23] <sil2100> robru: thanks! Would take me ages to guess that britey would be confused by those
[09:24] <robru> 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] <sil2100> robru: ok, but now you go REST!
[09:25] <sil2100> But not like REST API, just rest
[09:27] <pstolowski> awesome
[09:28] <pstolowski> sil2100, thanks for investigating!
[09:43] <Saviq> 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] <rvr> Saviq: Ack
[11:39] <Mirv> when can I have yakkety silos :D
[13:35] <dobey> sil2100: hey, do you need to do anything to ensure another package's translations end up in the langpacks for phone?
[13:40] <sil2100> dobey: hey! Is that some new package?
[13:46] <dobey> sil2100: not a new package, but it has translations now and has the debian/ changes to enable langpacks
[13:46] <dobey> sil2100: pay-service
[18:40] <ChrisTownsend> 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:44] <alesage> ChrisTownsend, sure a couple mins
[18:44] <ChrisTownsend> alesage: Thanks
[18:49] <alesage> ChrisTownsend, grep -C10 REJE for those logs http://paste.ubuntu.com/15988762/
[18:50] <alesage> ChrisTownsend, attaching that log to bug
[18:50] <ChrisTownsend> 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] <alesage> ChrisTownsend, http://paste.ubuntu.com/15988851/
[18:53] <ChrisTownsend> alesage: Ah, there's the problem.  The ContainersConfig.json is bad.  I wonder if that's how it's in the image?????
[18:54] <ChrisTownsend> alesage: I think the image may have been created incorrectly, but it's hard to tell.
[18:54] <alesage> ChrisTownsend, I assure you no manual editing by me :)
[18:54] <alesage> ChrisTownsend, how to test?
[18:54] <ChrisTownsend> alesage: Yeah, that's why I suspect the image itself:)
[18:55] <ChrisTownsend> alesage: Remove ~/.local/share/libertine/ContainersConfig.json, then either reboot or run 'initctl --session start puritine-click' and then try it again.
[18:55] <alesage> ChrisTownsend, ack
[18:57] <alesage> ChrisTownsend, now getting an XChat launch
[18:58] <ChrisTownsend> alesage: Yeah, image is messed up.
[18:58] <alesage> ChrisTownsend, ok, reassign bug?
[18:58] <ChrisTownsend> alesage: Yeah, but not sure who.
[18:59] <alesage> ChrisTownsend, everyone?
[18:59] <alesage> or alphabetically
[18:59] <ChrisTownsend> alesage: lol, have to start somewhere.
[18:59] <alesage> until it sticks
[18:59] <ChrisTownsend> alesage: I'll make a comment about the bogus ContainersConfig.json being in the image.
[19:01] <alesage> ok maybe it does belong in the system-image project at least and we'll expect another triage
[19:01] <ChrisTownsend> alesage: Ack