[01:56] <Saviq> duflu, there's a Qt crasher we're looking into, that's what caused the stale socket
[01:56] <duflu> Saviq: Fun :)
[02:14] <duflu> kgunn: As the critical fix has now landed, I might draw a line and tag 0.1.6. It's getting pretty big
[02:14] <kgunn> duflu: so i was just in the processs of updating the debian ch log
[02:14] <kgunn> so if you wanna tag on
[02:15] <duflu> kgunn: No problem. That's not a requirement for upstream releasing
[02:15] <kgunn> 1433
[02:15] <duflu> But I can wait
[02:15] <duflu> I have a while of reviewing my own code reviews yet
[02:15] <duflu> 1433 sounds good
[02:15] <kgunn> duflu: ok...thanks tho...i'll push in a moment for lp:mir....you can have your usual look :)
[02:15] <kgunn> but i think i got it this time
[02:17] <duflu> kgunn: Also Monday is a holiday for West Aust and Greece AFAIK
[02:18] <kgunn> ah thanks for that...didn't realize it
[02:18] <kgunn> duflu: just Western Australia ?
[02:18] <duflu> I think?
[02:18] <kgunn> guys the in the east just suffer and work
[02:18] <duflu> Ignoring the fact that RAOF is holidaying in WA :)
[02:19] <duflu> kgunn: Yep.  Labour day is different for each state
[02:29] <kgunn> duflu: ok...here's my attempt
[02:29] <kgunn> https://code.launchpad.net/~mir-team/mir/trunk-0.1.6/+merge/208717
[02:30] <duflu> kgunn: Thanks I will check it today. Quick thoughts - the changelog needs to wrap before column 80. Also we don't need and probably don't want comments about every commit (do we?)
[02:32] <kgunn> duflu: i wasn't sure...i do remove redundant/irrelevant comments
[02:32] <kgunn> like "merge from trunk"
[02:32] <kgunn> and...yeah...some are kinda weak...i can do a better job next time...
[02:32] <kgunn> and damn it!
[02:33] <kgunn> i forgot 80 col
[02:33] <kgunn> even tho i thot "don't forget 80 col"
[02:33] <kgunn> i'll fix in a jiffy
[02:43] <kgunn> duflu: ok...hopefully not much else wrong :)
[02:43] <kgunn> see ya tomorrow...have a good one
[02:47] <xnox> is this normal with trunk:
[02:47] <xnox> /usr/include/glm/detail/type_vec3.inl:86:33: error: invalid static_cast from type 'const glm::detail::tvec3<float, (glm::precision)0u>' to type 'float'
[02:47] <xnox> ?
[02:53] <duflu> xnox: I believe that problem appeared from the glm package last night. Not from Mir itself
[02:54] <xnox> duflu: sure, is there a fix for it? (or a merge proposal, or something?!)
[02:54] <xnox> i can downgrade, but i don't want to =)
[02:54] <duflu> xnox: Yes it appears a workaround was applied to Mir last night. Will be in 0.1.6 when I cut it today
[02:55] <xnox> duflu: is that https://code.launchpad.net/~afrantzis/mir/work-around-glm-initializer-list-breakage/+merge/208670 ?
[02:55] <duflu> xnox: Looks like it yes.
[02:56] <duflu> I've done a pile of builds this morning with the fix and they all succeeded
[02:56] <duflu> Beyond that it's all news to me
[02:58] <duflu> xnox: 11 hours ago apparently. Here's where the problems came from: https://launchpad.net/ubuntu/+source/glm
[03:02] <xnox> duflu: kind of sad that upstream, breaks compat in a micro minor point release.
[03:02] <xnox> duflu: did they ever advertise using initialisation lists? or is it us who used it, just because.
[03:03] <duflu> xnox: Yes. We only recently moved to using the external glm a few months ago. Before then it was embedded in the Mir source
[03:03] <xnox> i guess better of the two evils.
[03:04] <duflu> xnox: I don't know who to blame. I do know the Mir team often uses initializer syntax instead of constructor syntax, but I have trusted that they knew what they were doing
[03:04] <duflu> I don't know if that
[03:04] <duflu> 's the new ways for C++11+ or just style
[03:05] <xnox> duflu: well initializer syntax is only support with c++11, and if a given project decides that they don't support c++11, they are free to break source-level compatibility, without breaking ABI...
[03:05] <xnox> (e.g. as part of working on c++11 compat/apis adding initilizer list syntax etc....)
[03:06] <xnox> duflu: anyway, took the hint from the branch, thus my bugfix is compiling against stable, such that i can test it.
[03:07] <duflu> xnox: Sounds good. I would like Mir to use a better (maybe even internal) math library in future. But it's not a priority for anyone right now
[03:14] <xnox> duflu: what's wrong with libm?
[03:19] <duflu> xnox: For 3D matrix math? :)
[03:20] <xnox> duflu: ah, i see =)
[03:20] <xnox> duflu: that would cool, if it did that =)
[03:21] <duflu> xnox: I was hoping to myself. I wrote an awesome one in 1998 and could adapt it
[03:23] <duflu> ... and then GPUs came on the scene around 2000 and it was forbidden to do matrix math by hand. But then GLES came along and threw away a bunch of matrix manipulation functions, meaning you have to do them on the GPU or in a GPU shader now
[03:23] <duflu> on the CPU or in a GPU shader
[03:24] <duflu> Ideally you would never do any. Just send numbers off to the vertex shader and let it do all the matrix work
[03:24] <xnox> duflu: i'm yet to do any GPU / GL / GLES / shader coding.
[03:25] <duflu> xnox: It's like C with high-level matrix/vector math built in. Very little effort
[03:29] <duflu> Since the whole 3D math library has changed, I better do some manual testing to make sure it's still sane
[15:35] <greyback> Hey folks, am using cross-compiling chroot to compile mir, it failed with http://pastebin.ubuntu.com/7010931/
[15:35] <greyback> anyone seen anything like that before?
[15:42] <alan_g> greyback: yeah alf_ MP'd a workaround last night
[15:43] <greyback> alan_g: aha good. My chroot not bad then. thanks
[15:43] <alan_g> https://code.launchpad.net/~afrantzis/mir/work-around-glm-initializer-list-breakage/+merge/208670