[10:40] <alan_g> greyback: can you confirm? Unity8 uses QtCompositor from qtmir, not Mir's MultiThreadedCompositor?
[10:41] <greyback> alan_g: confirmed
[10:44]  * alan_g add Compositor to a list of customization points that could be improved
[11:18] <alf_> alan_g: greyback: There have been various talks about changing Unity8 to MTC, but there were always more pressing topics to pursue
[11:18] <greyback> alf_: right, kdub_ did work on that, but is blocked until we adopt qt5.5
[11:30] <Saviq> alf_, hey,so I was trying lp:~afrantzis/jenkins-launchpad-plugin/deb-artifacts-in-any-dir
[11:30] <Saviq> DUH
[11:39] <Saviq> alf_, actually, seems to be working fine, yeah
[11:41] <alf_> Saviq: good to hear
[11:42] <Saviq> alf_, and it seems to work for old s-jenkins format as well, cool
[11:43] <Saviq> alf_, one thing though, think it would make sense to order alphabetically?
[11:43] <Saviq> I've always felt lost in the list tbh
[11:47] <alf_> Saviq: I think builds at the same level were ordered alphabetically by jenkins.
[11:49] <alf_> Saviq: not sure that imposing a global alphabetical sort would make things easier to read, since it would mix different levels
[11:50] <Saviq> alf_, don't think it is ordered, http://pastebin.ubuntu.com/14886578/
[11:50] <Saviq> alf_, ah wait, it is
[11:50] <Saviq> alf_, but the problem is that it's breadth-first instead of depth-first
[11:51] <alf_> Saviq: yeah, for example all the build-2-binpkg jobs are ordered
[11:51] <Saviq> alf_, right, it'd be better if it would be depth-first IMO
[11:53] <alf_> Saviq: well, ok, I can take a look, but perhaps better to leave this for a different MP? Better to have this now I think than no output at all.
[11:53] <Saviq> alf_, yeah sure, just talking :)
[12:14] <Saviq> alf_, minor comments on https://code.launchpad.net/~afrantzis/jenkins-launchpad-plugin/triggered-builds/+merge/284117
[12:29] <alf_> Saviq: thanks, commented and updated
[12:38] <Saviq> alf_, didn't save comments, did you?
[12:41] <alan_g> alf_: (not urgent) I'd like your thoughts on duflu's suggestion. (The more I think about it the more complex making it work seems - but maybe I'm missing something.) https://code.launchpad.net/~alan-griffiths/mir/fix-1535894/+merge/285058
[12:51] <alf_> Saviq: I replied inline, did these get lost?
[12:51] <Saviq> alf_, need to press "save comments" at the top
[12:51] <Saviq> alf_, should still be in your browser
[12:52] <alf_> Saviq: ah, closed tab... in any case: using set() directly would arbitrarily rearrange builds, the way it's done now the order is retained
[12:53] <Saviq> alf_, regardless if you closed tab ;)
[12:54] <Saviq> alf_, they're stored in browser
[12:54] <Saviq> alf_, right, I thought that might be the reasoning
[12:54] <Saviq> alf_, so you can go to that same URL and press Save and they should be there :0
[13:04] <Saviq> alf_, approved, let's see if they use autolanding :)
[15:38] <alf_> Saviq: Thanks for the reviews. Unless there are any objections I will trigger the recipe to publish the new version in the ppa
[15:38] <Saviq> alf_, +1 from me
[15:54] <alf_> Saviq: tools PPA now contains all the MP message goodies! Enjoy!
[15:55] <Saviq> alf_, yay, /me updates
[16:43] <mariogrip> kdub_:  AlbertA: hi could one of you help debug this issue? https://github.com/ubports/android/issues/1
[16:44] <mariogrip> android 5.1 on fairphone
[16:44] <mariogrip> 2
[17:00] <AlbertA> mariogrip: so it seems then the module open call did not return an error but returned null for the alloc_device_t...
[17:01] <AlbertA> that's in android_buffer_allocator.cpp (AndroidGraphicBufferAllocator constructor)
[17:05] <mariogrip> do you know why it does not return? it seems to print correct address
[17:05] <tvoss> mariogrip, it returns, and let's please keep the conversation in one channel
[17:05] <AlbertA> mariogrip: oh just looked at the pastebin...
[17:06] <AlbertA> mariogrip: you are missing symbols in the stack trace so could have crashed on the android side
[17:07] <tvoss> AlbertA, top of the stack is 0x0 ;) unlikely that anything is mapped to that address
[17:08] <tvoss> mariogrip, do you have a link to the actual libw module implementation handy?
[17:08] <AlbertA> null function pointer?
[17:08] <AlbertA> sounds like android side issue :)
[17:08] <tvoss> AlbertA, yup
[17:09] <tvoss> AlbertA, https://github.com/CyanogenMod/android_hardware_qcom_display/tree/cm-12.1-caf-8974
[17:09] <tvoss> AlbertA, https://github.com/CyanogenMod/android_hardware_qcom_display/blob/cm-12.1-caf-8974/libgralloc/gpu.cpp#L46
[17:09] <tvoss> alloc is null after the assignment
[17:10] <tvoss> l. 39 is funky, too, as alloc_device_t is a direct base of gpu_context_t
[17:10] <mariogrip> tvoss: libw?
[17:11] <tvoss> mariogrip, sorry, libhardware :)
[17:11] <mariogrip> https://github.com/CyanogenMod/android_hardware_libhardware
[17:11] <mariogrip> https://github.com/CyanogenMod/android_hardware_libhardware/tree/cm-12.1
[17:11] <AlbertA> tvoss: umm treating as pod, but maybe it's not a pod
[17:16] <tvoss> AlbertA, also assumes default alignment
[17:18] <tvoss> mariogrip, so I think the gralloc device is initialized here: https://github.com/CyanogenMod/android_hardware_libhardware/blob/cm-12.1/modules/gralloc/gralloc.cpp
[17:19] <mariogrip> tvoss: it should not, but I can test
[17:20] <tvoss> mariogrip, ah, no worries, I might be wrong
[17:22] <tvoss> mariogrip, I will eat something and read code later on
[17:22] <mariogrip> okey :)
[21:13] <coretex__> yay mir 0.19.1