[00:36] <RAOF> infinity: Huh, sorry. I didn't notice us adding that to Build-Deps. :(
[00:36] <RAOF> Grr, wireless.
[00:37] <infinity> RAOF: Oh hai.
[00:37]  * RAOF has just given up on working out why wifi is continuously associationg and disassociating and has just gone cat5
[00:37] <infinity> RAOF: BTW, I'm about to push an MP to build on PPC.  I assume that even if that lands on trunk, if I want this in the distro in a timely fashion, I need to land it elsewhere too?
[00:38] <RAOF> That's... a fair question.
[00:38] <RAOF> I think you actually just want to land on trunk and do a manual upload to distro.
[00:38] <infinity> RAOF: I can just upload directly, of course, but since it touches the orig, that's a bit annoying.
[00:39] <infinity> Well, annoying if someone else does something goofy on top.
[00:39] <infinity> But yeah, I can just do that.
[00:39] <RAOF> You shouldn't *need* to touch the .orig, right? It should be patchable.
[00:40] <RAOF> But trunk→distro is a fair distance for us.
[00:40] <RAOF> Or, at least, is a manual step.
[00:40] <infinity> RAOF: No, I need to re-roll the orig because of the stupid binary data in the testsuite.
[00:40] <infinity> RAOF: Which I've already done, FWIW, so no big deal.
[00:41] <RAOF> Copy it from debian/ :) ?
[00:41] <infinity> RAOF: So, uhm.  Gross.
[00:41] <RAOF> :P
[00:41] <infinity> RAOF: Oh, and still wouldn't work, cause it's a v1 package.
[00:41] <infinity> RAOF: If diff can't represent it, you lose.
[00:41] <RAOF> Seriously? We don't set v3? Sadface.
[00:41] <RAOF> Yeah, the binary data is somewhat annoying, but I don't see a way around it.
[00:42] <infinity> RAOF: It's not world-ending.
[00:42] <infinity> RAOF: In another MP, I might add a few more Debian arches (ppc64, s390x, etc) for potential future-proofing.
[00:43] <RAOF> AlbertA: Have you rolled 0.13.2 yet? Could we roll infinity's changes into it for convenience?
[00:45] <infinity> RAOF: https://code.launchpad.net/~adconrad/mir/powerpc-porting/+merge/261055
[00:46] <infinity> RAOF: And, of course, I'd love to do a direct upload, but it'll end up dep-wait because of your new build-dep.  Grr.
[00:46] <infinity> I guess I can cheat with a PPA, since that's how you guys got it in there in the first place. :P
[00:47] <RAOF> Oh, ooooh.
[00:47] <RAOF> Yay multiple parallel semi-synched processes!
[00:51] <infinity> RAOF: Hrm.  Now that I think about future-proofing, I should probably invert pretty much every arch spec in there.
[00:52] <infinity> RAOF: As in, x86 and armhf are actually the unique snowflakes, and linux-any should be the norm.
[00:52] <RAOF> Yeah.
[00:52] <infinity> RAOF: But I can worry about that when I add more arches later.
[00:52] <RAOF> I've also added a todo card to make the testsuite not fail on archs we don't have a lib$ARCH.so for, which should make adding more archs easier.
[00:53] <RAOF> We can then opportunistically add lib$ARCH.so blobs.
[00:54] <infinity> RAOF: Would be slick if the test code was generated on the fly based on `ls -1 test_data/*.so` so enabling that test was just a matter of dropping the blob in without editing code.
[00:54] <infinity> RAOF: Then, on arches that don't ship the blob, you could just generate one on the fly.
[00:54] <RAOF> infinity: Actually, we could always generate one on the fly...
[00:54] <infinity> RAOF: Right, you can generate one on the fly, but see the note about the code needing manual mangling right now. :)
[00:55] <RAOF> Yeah.
[00:55] <infinity> RAOF: Fix the code to be dynamic based on the available content, then make the testsuite depend on libarch.so with a rule to make it if it doesn't exist, and done.
[00:55] <infinity> RAOF: THen someone can just add them later.
[00:56] <RAOF> Oh, by the way, what are our big-endian failures? I thought we were paying attention to endianness :(
[00:56] <infinity> RAOF: Anyhow, I think I'll build this in a clean PPA and copy it in, and let you guys deal with the fallout, since I have no clue how you go from bzr to distro branches to uploads.
[00:57] <RAOF> Convolutedly.
[00:57] <infinity> RAOF: There's one function that no one ported, and intentionally bails because of it.
[00:57] <infinity> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/server/scene/gl_pixel_buffer.cpp#L59
[00:58] <RAOF> Oh, hah.
[00:58] <RAOF> At least it fails at compile time, then :)
[00:58] <infinity> RAOF: It's probably not hard to port, but I imagine it might take pen and paper and a bit of thought.
[00:58] <infinity> RAOF: No, it compiles fine.  Just fails the testsuite.
[00:58] <RAOF> Hm, no. At least it dies at runtime rather than giving incorrect results.
[01:01] <infinity> RAOF: Also, my OpenGL is weak, but I vaguely recall that it's little-endian across the board (much like network is always big-endian), so it's really just a matter of GL<->host swaps if you intend to operate on things using the host CPU.
[01:01] <infinity> RAOF: At least, that sounds like a familiar thing from a past life.
[01:05]  * infinity double-checks there's no taint in his PPA and uploads the wily package.
[01:08] <RAOF> That's the class that's doing GPU→CPU translation, so it does actually need some work. :)
[01:09] <infinity> RAOF: Oh, also, not sure who maintains the toolkit integration bits (eg: gtk3 links to libmirclient), but enabling that on powerpc while Mir is known-broken might be dumb. ;)
[01:10] <RAOF> It'd actually be fine - that's a server-side issue, and all the toolkit integration is client-side.
[01:10] <infinity> Oh, that's good news.
[01:10] <RAOF> So it'd be not very useful, because no-one could run ppc GTK against a Mir server, but it'd equally be harmless.
[01:40] <infinity> RAOF: Right, if the client stuff is all harmless, then I guess once this lands, we can slowly stop arch-restricting the world.
[01:40] <RAOF> Yes.
[01:40] <infinity> RAOF: And put "fix the endian bug" on the TODO before someone decides a Mir server on a BE arch is fun.
[01:41] <RAOF> armhfbe!
[01:43] <infinity> RAOF: Well, I intend to sent a followup to enable ppc64 and s390x at some point.  At which point, I'll switch that testsuite-disabling to check for DEB_HOST_ARCH_ENDIAN instead of DEB_HOST_ARCH, and clean everything up so that !x86/!armhf is the norm, and those unique snowflakes get their own brand of special.
[01:43] <infinity> s/sent/send./
[01:43] <infinity> RAOF: So, then we'll have 3 BE arches.
[01:44] <RAOF> And I'll have the testsuite do the generate-a-dso thing soon.
[01:44] <infinity> RAOF: Sure.  Doesn't block me doing those two, since I'll generate the .so on Debian porter boxes, but still nice future-proofing.
[01:45] <infinity> Actually, I may as well just add all the Debian non-ports arches while I'm in there.
[01:46] <infinity> So, armel, mips, mipsel,  s390s, sparc, ppc64.
[01:46] <infinity> I assume Mir is Linux-specific, and attempting to build it on kfreebsd or hurd would end in tears?
[01:49] <bschaefer> make snap fails in lp:mir :(
[01:50] <bschaefer> http://paste.ubuntu.com/11554636/
[01:55] <infinity> mir_0.14.0_amd64.snap: FAIL
[01:55] <infinity> Generated 'mir_0.14.0_amd64.snap' snap
[01:55] <infinity> Brilliant.
[01:55] <infinity> IT BROKE, HERE'S A PACKAGE.
[01:57] <bschaefer> infinity, yeah haha i tried installing it as well
[01:57] <RAOF> :)
[01:57] <RAOF> I think deb2snap is a better bet for the moment.
[01:57] <bschaefer> it didnt install anything that i could find haha
[01:58] <bschaefer> RAOF, i was just trying the 0.12 branch
[01:58] <bschaefer> if that fails... ill look into that :)
[01:58] <RAOF> infinity: We use epoll and such; it's linux-any, yes.
[01:58] <bschaefer> eek 0.12 doesnt have snappy in ith
[01:58] <bschaefer> it*
[01:59]  * bschaefer tries copying lp:mir snap
[02:00] <infinity> RAOF: Kay, noted.  Next time I'm bored, I'll submit that MP to enable it on effectively all linux-any, then.
[02:01] <RAOF> bschaefer: deb2snap; it's how we built the demo snap.
[02:01] <bschaefer> RAOF, o nice, yeah just saw it https://launchpad.net/deb2snap
[02:01] <bschaefer> RAOF, hopefully it still works :)
[02:01] <RAOF> It worked a couple of days ago :)
[02:01] <bschaefer> RAOF, excellent :)
[02:01] <bschaefer> thanks!
[02:12] <infinity> RAOF: Other than fixing the testsuite and adding blobs (I'll whip those up later), this looks like it should fix the arch brain damage: http://paste.ubuntu.com/11555020/
[02:13] <RAOF> WTF is install_ld_so_conf.sh there for?
[02:13] <infinity> RAOF: ellifiknow.
[02:14] <RAOF> I'm *pretty* sure that's unnecessary now.
[02:14] <infinity> RAOF: rgrep doesn't seem to find any references to it...
[02:15] <RAOF> Hm. I guess we just didn't delete the various workaround helpers when we fixed the platform loading code.
[02:17] <infinity> RAOF: Well, I'll leave that to you to delete. :P
[02:17] <RAOF> Yeah, will do.
[02:17] <infinity> RAOF: I'll push this as a formal MP after the current one's merged, and once I get a bunch of blobs and twiddle the testsuite to match them.
[02:18] <RAOF> I'll be proposing the dynamic blob generation before you do.
[02:18] <RAOF> (It's almost finished)
[02:18] <infinity> RAOF: Including dynamic code?  Shiny.
[02:18] <RAOF> Yeah. The dynamic code is done, just need the cmakery to generate libARCH.so
[02:19] <infinity> RAOF: When I see that land, then, I'll push this, and we'll call it good.  Ulterior motive on my part, since there may be some new ports coming up soon, and I *hate* dealing with arch-restricted nonsense when bootstrapping the world.
[02:19] <infinity> And Mir has weaseled its way pretty low in the stack by now.
[02:19] <RAOF> Who'd've thought the display server would be low in the stack! :P
[02:28] <infinity> RAOF: Okay, screw it, if you're fixing the test, I pushed the rest just now.
[02:28] <infinity> RAOF: If you need to re-ACK the MP or something.
[02:28] <RAOF> Will do.
[02:31] <bschaefer> :(, cant find libmirclient8.so hmm o well time to eod
[02:38] <infinity> RAOF: And hacked up build on all arches copied to wily-proposed.
[02:38] <infinity> tedg: ^
[02:48] <tedg> Cool!
[02:49] <infinity> tedg: I retried the builds in silo 008.  Was that the ones you needed?
[02:49] <tedg> Yup, it is.
[02:49] <infinity> Alright.  We'll see how they fare.
[02:49] <tedg> Oh, you did it in the PPA. I was looking at the dashboard :-)
[02:49] <tedg> Thanks infinity!
[02:50] <infinity> tedg: Yeah, I don't believe in this bizarre "reupload the source and force rebuilds on all arches" madness when I have a nice "retry" button for individual builds. :P
[02:51] <infinity> Oh, pay-service depends on app-launch.  Guess I need to wait a bit and hit more buttons. ;)
[02:51] <infinity> But app-launch built, so that's a good sign.
=== chihchun_afk is now known as chihchun
[02:54] <RAOF> Stupid damn cmake.
[03:01] <infinity> RAOF: But cmake is the way and the light, or something.
[03:15] <infinity> RAOF: Oh, and I know we got all sidetracked and such, but someone still needs to file that abi-checky-thingee MIR.
[04:52] <infinity> RAOF: Once jenkins is happy, does a human need to intervene to do the actual merge, or does something magical happen?
[05:27] <RAOF> infinity: Automerge once someone hits the Accepted status on the top.
[05:28] <RAOF> ...which I'll do once I've re-reviewed it.
[05:29] <RAOF> And done.
[05:35] <infinity> RAOF: Ta.
[06:32] <RAOF> infinity: Oh, you seem like the sort of person who knows this arcana:
[06:32] <RAOF> How does one re-export a symbol with a different version?
[06:33] <RAOF> (In the case of moving a symbol versioned LIB_A_1 to libb, a dependency of liba)
[06:38] <RAOF> infinity: unping, the answer turns out to be obivous.
[07:18] <duflu> Holy crap. FreeSync monitors exist. In my local store even! https://www.ple.com.au/ViewItem.aspx?InventoryItemId=617352
[07:18] <duflu> This affects my choice of algorithm
[09:58]  * alan_g finds https://wiki.ubuntu.com/Unity8inLXC and thinks it would be cool to set up a similar ppa for mir_demo_server et alia
[10:57] <Mirv> greyback: bug #1403758 for quick overview. comments #6 and #8 have copy-pasted IRC logs
[10:57] <ubot5> bug 1403758 in gcc-defaults (Ubuntu) "Unity8 shows black screen with Qt 5.4.0" [Undecided,New] https://launchpad.net/bugs/1403758
[11:00] <greyback> Mirv: interesting, ta
=== chihchun is now known as chihchun_afk
=== alan_g is now known as alan_g|lunch
=== tvoss is now known as tvoss|afk
=== alan_g|lunch is now known as alan_g
[13:23] <alan_g> alf_: could you review a small refactoring in USC? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/decouple-WindowManager-from-DMMessageHandler/+merge/260979
[13:29] <alf_> alan_g: done
[13:38] <alan_g> alf_: is that even better?
[14:03] <kdub> we now have next_buffer, exchange_buffer, and 'the new buffer semantics'... pondering whether to deprecate next_buffer in this process
[14:04] <kdub> and even exchange_buffer and 'new buffer semantics' are incompatible with working at the same time, even
[14:23]  * alan_g knows the feeling: "I wouldn't start from here if I were you".
[14:41] <AlbertA> RAOF: yeah mir 0.13.2 is already pending on QA approval
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[16:39] <alan_g> kdub: I'm seeking GL advice again: I've done something daft but can't see what. (Confused color and alpha channels I think.) Could you look at why the spinner looks weird: lp:~alan-griffiths/unity-system-compositor/incorporate-logo-into-spinner-binary (You can run this bin/unity-system-compositor-spinner as a Mir client, no need to mess with USC - the old one needed pngs installed)
[16:40] <kdub> alan_g, sure
[16:47] <kdub> alan_g, just figuring out the fastest way to cross compile :)
[16:48] <alan_g> kdub: I just build and run on the desktop
[16:49] <kdub> yeah, probably will go faster, trying that
[17:02] <alan_g> kdub: gotta go but will pick up again in morning. If you spot my idiocy let me know, if not thanks for looking.
=== alan_g is now known as alan_g|EOD
[17:02] <kdub> alan_g|EOD, sure, no problem
=== tvoss|afk is now known as tvoss
=== tvoss is now known as tvoss|eod
=== tvoss|eod is now known as tvoss