[08:19] <ypwong> could someone please release indicator-china-weather 1.1.0-0ubuntu3 from trusty-proposed?
[09:01] <infinity> ypwong: Done.  It was a bit broken because the .changes file didn't have the bug closure.  I guess the uploader didn't build the source on Ubuntu.
[09:20] <ypwong> infinity, oh..
[09:20] <ypwong> infinity, thanks
[15:51] <tedg> We're adding a feature to UAL to make dealing with Mir trusted prompt sessions easier.
[15:51] <tedg> Which unfortunately makes libubuntu-app-launch dependent on libmir
[15:52] <tedg> Which has the result of making it so that libual can't build on ppc or ppc64
[15:52] <tedg> So, I need some help deleting binaries for libual and anything that depends on it for those architectures.
[19:15] <tedg> infinity, Perhaps are you around? ^
[19:17] <infinity> tedg: That looks like quite a mess to untangle on a day off.
[19:25] <tedg> infinity, Heh, yes.
[19:25] <tedg> For the record, I have gotten a card on the MIr backlog to fix the PPC issue.
[19:25] <tedg> But trying to get silos landed in the mean time.
[19:29] <infinity> tedg: I was just about to try a PPC build to see what "the issue" is.  It's been going on more than long enough.
[19:30] <infinity> tedg: Anyhow, I'm on VAC until tomorrow.  If it can wait until then, I'll help you tidy up.  If it can't, I'm sure you can hunt someone else down to try to unwind the mess.
[19:30] <tedg> infinity, I think the issue is something with Mesa and the test suite, I've suggested the test suite passing isn't as important as getting a build.
[19:32] <infinity> tedg: My plan was to cargo-cult exactly the same hacks that are in place for arm64, and then see where it explodes.
[19:32] <infinity> Which I've half done now.  Was too lazy to do the other half before trying a quick build.
[19:32] <tedg> WFM, I just don't want per-arch stuff leeching up the stack.
[19:37] <infinity> Okay, so it indeed builds, and then fails 2 tests:
[19:37] <infinity> 99% tests passed, 2 tests failed out of 281
[19:37] <infinity> I need to employ the rest of the arm64 hacks and see if those affect that.
[19:37] <infinity> And then we can probably just temp ignore the ppc-specific failures.
[19:37] <infinity> And skip out on removing your packages altogether.
[19:49] <infinity> tedg: Can you ask a Mirish person where the source for test_data/lib$(arch).so is?
[19:50] <tedg> infinity, asked
[19:51] <infinity> Was hoping some grepping would make it jump out, but I guess I grep poorly.  Or that blob is sourceless, which would be unfortunate. :P
[19:51] <tedg> echo /dev/urandom > lib$(arch).so # Confuse release team
[19:51] <tedg> cat
[19:52] <infinity> It's definitely not urandom, since it's a valid ELF object for the target arch. ;)
[19:52] <tedg> urandom, c++, who can tell the difference? :-)
[19:53] <infinity> Maybe it'll be kind and make me one during the build.  Not holding my breath.
[19:54] <infinity> Yeah, no such luck there, it comes from an external something.
[19:54]  * infinity shrugs.
[19:54] <infinity> 	167 - mir_unit_tests.MesaClientPlatformTest.* (Failed)
[19:54] <infinity> 	233 - mir_unit_tests.SharedLibraryProber.* (Failed)
[19:55] <infinity> So, the second one would be fixed by getting those objects built for ppc/ppc64el.
[19:55] <infinity> The first one is worth a dig, but also perfectly reasonable for us to give a temp pass, and stop playing these awful arch restriction games, IMO.
[19:57] <infinity> Value of: reinterpret_cast<struct gbm_device*>(pkg.data[previous_data_count])
[19:57] <infinity> Expected: is equal to 0x10023e2f340
[19:57] <infinity>   Actual: 0x23e2f340 (of type gbm_device*)
[19:57] <infinity> Hrm.  Curious.
[19:58] <infinity> That looks pretty tractable.
[19:58] <infinity> What with all the suspiciously similar but not quite numbers.
[20:01] <infinity> tedg: Quite confident we can just sort this in the morning when I'm back from VAC.  I might enjoy my last day and go nap or beer or beer and then nap, though.
[20:01] <tedg> infinity, Sounds great, thank you!
[20:01] <infinity> tedg: If you can hunt down the mysterious test data source for me, that would be awesome, then it's just this one bug that needs squashing or ignoring.
[20:01] <tedg> Enjoy your napping beer ;-)
[20:02] <tedg> Will do
[20:43] <flexiondotorg> infinity, I've had a few sponsor requests turned down.
[20:43] <flexiondotorg>  infinity, Please take a peek at this - https://bugs.launchpad.net/ubuntu-mate/+bug/1456591
[20:43] <flexiondotorg> infinity, I'm just wanting to know if this is standard practice?
[20:44] <flexiondotorg> infinity, Should all sponsoring "bugs" be self referencing?
[20:44] <flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu-mate/+bug/1456597