[03:35] <duflu> RAOF: Got a fix for devel cooking?  https://bugs.launchpad.net/mir/+bug/1351133
[03:36] <RAOF> duflu: Have I not proposed that?
[03:36]  * duflu double checks
[03:36] <duflu> Can't see it
[03:37] <RAOF> Bah.
[03:37] <RAOF> I did it first, but didn't push it.
[03:40] <RAOF> duflu: Enjoy
[03:41]  * duflu prefers other forms of enjoyment
[03:41] <RAOF> https://code.launchpad.net/~raof/mir/finish-off-mirprotobuf-removal/+merge/229374
[03:47] <duflu> RAOF: Glad to have a proposal to approve. ;)
[05:37] <duflu> RAOF: Err we appear to have broken mirclient dependencies used by gtk-3.0 in the coming Mir 0.6.0 :(
[05:38] <duflu> So things outside-the-silo (gtk 3) won't work any more
[05:38] <RAOF> duflu: Really? What's the error?
[05:38] <duflu> https://bugs.launchpad.net/mir/+bug/1352149
[05:39] <RAOF> No, that's ok.
[05:39] <RAOF> Or, at least, it should be.
[05:39] <duflu> RAOF: What? The old one can linger?
[05:39] <RAOF> Absolutely.
[05:40] <RAOF> It'll be NBS (not built from source), but it's not an ABI break.
[05:40]  * duflu tries it
[06:06] <seb128> RAOF, nbs means the new source is going to be blocker in proposed by britney (if I understand correctly what you are saying)
[06:07] <seb128> blocked even
[06:07] <RAOF> seb128: And so gtk3 gets a no-change rebuild, and we go back to base for debriefing and cocktails?
[06:08] <seb128> yes
[06:08] <seb128> just need that no change rebuild ;-)
[06:08] <seb128> well, if it's really no change
[06:08] <RAOF> It really is.
[06:08] <seb128> wait
[06:09] <seb128> you are dropping a .so from a binary without renaming it?
[06:09] <RAOF> Yes.
[06:09] <seb128> shrug
[06:09] <RAOF> Dropping libmirprotobuf entirely.
[06:09] <seb128> that's going to make gtk apps fail to start
[06:09] <seb128> nothing is going to block mir to migrate in that context
[06:10] <seb128> but gtk, until rebuild, is going to try to load that library and fail to load
[06:10] <seb128> you can't do that
[06:10] <RAOF> gtk will have a dependency on the libmirprotobuf package, right?
[06:10] <seb128> is that a package
[06:10] <RAOF> Yup.
[06:10] <seb128> or is a .so in a binary that is not going away?
[06:10] <RAOF> It's a .so in a package that *is* going away.
[06:10] <seb128> oh, ok, it was properly split
[06:11] <seb128> k, in this case all good
[06:11] <seb128> thanks for replying, sorry for the noise
[06:11] <RAOF> No problem :)
[06:12] <RAOF> Good to have you in to UTC+lots :)
[06:20] <duflu> seb128: I'm just checking that issue ;) https://bugs.launchpad.net/mir/+bug/1352149
[06:41] <duflu> RAOF: Do you remember the ldd equivalent command that doesn't list dependencies of dependencies?
[06:48] <anpok_> objdump -p bin?
[06:52] <duflu> anpok_: Ah yes, thanks
[06:52] <duflu> Also: objdump -x /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 | grep NEEDED
[06:55] <duflu> Oh, -p is shorter :)
[07:18] <duflu> camako: Anything blocking 0.6.0 that needs my help today?
[07:18] <camako> duflu, yeah there was yet another blocker
[07:19] <camako> duflu, alan_g is working on it though
[07:19] <duflu> camako: Awesome. Why haven't I seen it?
[07:19] <duflu> OK
[07:19] <camako> (or will work on it)
[07:19] <camako> duflu, it was in the downstream libs
[07:20] <duflu> camako: I'm accumulating branches that need a lot of fixing before reproposing them. Just checking on the state of things before I dive back into those large tasks
[07:20] <camako> alan_g's branch is up but not finalized
[07:20] <camako> duflu, understood. I think I might pick up the last couple of commits made on devel, too.
[07:20]  * duflu looks
[07:21] <camako> duflu, after I make sure they don't break downstream.
[07:21] <camako> specifically, would be nice to pickup r1811
[07:22]  * camako is not sure if downstream components were tested before r1811 was approved.
[07:23] <duflu> camako: Best to keep 0.6 unmodified. I've started lining up items for 0.6.1 later (which is easier since there's no ABI break then)
[07:24] <camako> duflu, yeah probably
[07:25] <duflu> OK, I've now reached my code review argument limit for the day.
[07:25]  * duflu goes to working on actual code
[07:30] <duflu> RAOF: Can you attach any known branches to this? https://bugs.launchpad.net/mir/+bug/1293944
[07:30] <RAOF> duflu: WIP
[07:30] <duflu> RAOF: OK, so long as no proposed ones should be there already
[07:31] <RAOF> duflu: That was https://code.launchpad.net/~raof/mir/privatise-all-the-things/+merge/228796 , but it's WIP while I get proper platform probing going.
[07:53] <alf_> RAOF: Hi! It turns out that we send a lifecycle connection lost event to ourselves when we release a client connection. Is this on purpose?
[07:54] <RAOF> alf_: Yes
[07:55] <RAOF> alf_: Because there didn't seem to be any reason not to, and this allows cleanup code to be in one place: the lifecycle event handler.
[08:00] <alf_> RAOF: the only complication is that we send a SIGTERM in the default lifecycle handler (which wasn't working well before, but is fixed by https://code.launchpad.net/~afrantzis/mir/client-lifecycle-terminate-properly/+merge/229234)
[08:01] <RAOF> Yeah, I noticed that. Why are we doing that, and why aren't we sending SIGQUIT?
[08:04] <RAOF> I guess having it overridable is better than libX11's “I KILL YOU WITH A SWORD” SIGPIPE, but...
[08:07] <RAOF> alf_: Need me to do anything now? Otherwise I'll EOD.
[08:09] <alf_> RAOF: No, thanks, just wanted to ensure we send the event on purpose.
[08:09] <alf_> RAOF: Enjoy your day!
[22:23] <bschaefer> racarr, hey, do you know that cursors: mir_omnidirectional_resize_cursor_name and mir_closed_hand_cursor_name are the same?
[22:23] <bschaefer> also have you had the time to get a crosshair cursor landed :)?
[22:34] <racarr> bschaefer: I think omnidirectional resize cursor
[22:34] <racarr> and closed hand are only the same
[22:34] <racarr> in the ubuntu theme
[22:35] <racarr> but omnidirectional resize maps to "fleur"
[22:35] <racarr> and closed hand maps to "grabhand" or something
[22:35] <racarr> grabbing
[22:35] <racarr> ill look in to crosshair I cant remember why I skipped it
[22:35] <racarr> maybe ubuntu default them didnt have it...
[22:37] <bschaefer> interesting, yeah x11 uses fleur in place of grab hand
[22:37]  * bschaefer switches to omnidirection
[22:37] <bschaefer> racarr, theres also the case of
[22:37] <bschaefer> case SDL_SYSTEM_CURSOR_NO:        shape = XC_pirate; break;
[22:37] <bschaefer> missing
[22:37] <bschaefer> the CURSOR NO seems to be like an X marks the spot on a treasure map
[22:37] <bschaefer> racarr, but cool, and thanks!
[22:42] <racarr> cursor no lol...
[22:42] <racarr> bschaefer: Maybe it's "disabled"
[22:42] <racarr> not as in disabled cursor
[22:42] <racarr> but
[22:42] <racarr> disabled action
[22:42] <racarr> like clicking here is not a valid
[22:42] <racarr> action
[22:43] <racarr> whioch I guess we dont have a cursor for either :)
[22:43] <racarr> lol XC_pirate
[22:43] <racarr> ...plus caret = "xterm", etc...
[22:43] <racarr> its like someone was intentionally trying to be funny with the cursor names -.-
[23:45] <RAOF> Bah.
[23:45] <RAOF> Why is mir_discover_gtest_tests suddenly segfaulting during global construction?
[23:48]  * RAOF tries a dist-upgrade.
[23:52] <racarr> haha oh no...I have been all happy that my qtmir acceptance test is supposedly passing but just realized the client should actually get denied connection....
[23:54] <RAOF> Hah
[23:54] <RAOF> Ba baw!
[23:55] <racarr> oh no I guess it shouldn't
[23:55] <RAOF> Hm. libstdc++6 upgrade, you say?
[23:55] <racarr> that logic is in the other part
[23:55] <racarr> that may be related :p
[23:55] <racarr> mir_discover_gtest_tests is not segfaulting for me