[02:03] <thomi> robert_ancell: ping?
[02:03] <robert_ancell> thomi, hey
[02:03] <thomi> robert_ancell: so I think I'm getting close to getting all the infrastructure stuff lined up so we can run mir_stress as part of a CI run. However, there are a few issues yet to solve:
[02:05] <thomi> first, mir_stress currently fails - it causes the server to crash, and the test to hang, which means that if we were to integrate it today, it would take a long time before we got any MP feedback (although we could set the jenkins job timeout to something a little tighter I guess)
[02:05] <robert_ancell> bug #?
[02:05] <robert_ancell> (I know the bug, just don't have the number handy)
[02:05] <thomi> https://bugs.launchpad.net/mir/+bug/1195089
[02:06] <thomi> the second issue is that our infrastructure seems really flakey, but until I have a job that passes when everything does work, it's hard for me to apply pressure to get those issues fixed up
[02:08] <robert_ancell> thomi, I'll have a look at that one
[02:09] <thomi> thanks. :)
[02:25] <duflu> robert_ancell: To clarify the confusion I've made this tag/group ... https://bugs.launchpad.net/mir/+bugs?field.tag=multimonitor
[02:25] <robert_ancell> duflu, thanks
[02:40] <duflu> RAOF: It's a bit inaccurate to keep tracking XMir bugs in the Mir project. Can we use a new project for it?
[02:41] <RAOF> duflu: We can file them against X with the xmir tag.
[02:41] <duflu> RAOF: Where's the code BTW?
[02:41] <RAOF> github.com/RAOF/xserver
[02:41] <duflu> Awesome.
[02:41] <duflu> Hmm
[02:47] <RAOF> Why is cmake suddenly unable to find glog?
[03:06] <RAOF> Argh.
[03:07] <RAOF> CMake doesn't understand multiarch?
[03:10] <RAOF> God damn it build systems. DON'T REIMPLEMENT A HALF-ARSED, BROKEN VERSION OF PKG-CONFIG.
[03:20] <kgunn> xmir...finally!
[03:20] <robert_ancell> kgunn, \o/
[03:21] <kgunn> no doubt!
[03:23] <RAOF> Woot!
[03:37] <duflu> RAOF: It's not Mir's fault! (which is bad news) https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1194004
[03:38] <RAOF> Whoops!
[03:41] <duflu> RAOF: Also, we now have https://launchpad.net/xmir
[03:44] <kgunn> quick, one, anyone know how to get runtime config dumps of xorg, e.g. let's say i want to see what the color format
[03:45] <kgunn> of a front buffer is that an app is rendering into
[03:45] <kgunn> or resolution etc
[03:46] <kgunn> RAOF: duflu ^ ?
[03:47] <duflu> kgunn: /var/log/Xorg.0.log is my best guess but may be insufficient
[03:51] <RAOF> kgunn: “xwininfo -root” does some of that.
[03:51] <RAOF> There's no single ‘introspect X’ tool, though.
[03:52] <kgunn> thanks guys....will poke around thos
[04:13] <duflu> kgunn: From memory, Compiz (rightly or wrongly) uses the current X visual. Even when it could (in theory) choose anything the GL implementation allows
[04:13] <duflu> So that means asking X tools should be accurate right now. But you can't rely on them indefinitely
[04:30] <robert_ancell> thomi, I've updated bug 1195089 - I'm not reproducing
[04:31] <RAOF> Woot!
[04:31] <thomi> robert_ancell: hmmm
[04:32] <RAOF> So when the documentation says “set the CTEST_ENVIRONMENT variable to influence the environment your tests are run in” what it *means* is ‘the CTEST_ENVIRONMENT variable is totally ignored, sucker’.
[04:32] <thomi> robert_ancell: only thing I'm doing differently is I'm not running mir_demo_server or mir_stress as root. Will try with latest trunk - maybe it got fixed some time in the last 12 hours?
[04:32] <robert_ancell> thomi, hopefully :)
[04:33] <robert_ancell> thomi, note if you don't run as root you can't get the VT
[04:33] <thomi> robert_ancell: I ususally ssh in to run mir_stress
[04:53] <RAOF> Man, I get all the good things.
[04:54] <RAOF> Non-deterministic double-free in  unit-tests.GBMGraphicsPlatform.*
[05:05] <tvoss_> good morning :)
[05:05] <duflu> Ah tvoss_ is here.
[05:05] <duflu> Must be time for lunch
[05:05] <duflu>  :)
[05:05] <tvoss_> duflu, exactly :)
[05:05] <tvoss_> RAOF, good morning :)
[05:05] <RAOF> tvoss_: Good morning.
[05:06] <tvoss_> RAOF, happy new week
[05:06] <RAOF> tvoss_: You should be pleased to learn that https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 should finally pass the tests on the CI infrastructure.
[05:06] <tvoss_> \o/
[05:06] <RAOF> (Pending one final change to mir_discover_gtest_tests)
[05:07] <tvoss_> RAOF, that's great news :)
[05:10] <tvoss_> thomi, hey there :)
[05:10] <thomi> tvoss_: o/
[05:10] <tvoss_> thomi, hey, for the autopilot integration tests: sounds good, thanks for clarifying :)
[05:11] <thomi> tvoss_: it sucks that the three of us are in really awkward timezones, but I think it'd be good to have a chat some time to work out the big picture: what we need, and where autopilot fits
[05:12] <thomi> Martin knew a lot more about the app functional test suite progress ....
[05:13] <tvoss_> thomi, yeah, I know. Are there some example jobs that are run on real hardware?
[05:15] <thomi> tvoss_: Yes, I believe that all the core apps are run on the real hardware, but I'm not the person to speak to about that
[05:15] <tvoss_> thomi, who would that be now?
[05:15] <thomi> tvoss_: I think ChrisGagnon and om26er are the ones to try
[05:15] <tvoss_> thomi, cool, thx
[05:15] <thomi> tvoss_: no worries - Omer is (AFAIK) the one working for the phone app teams
[05:16] <thomi> Chris does a lot of deployment work
[05:31] <tvoss_> RAOF, still get the non-deterministic double-free?
[05:31] <RAOF> Yes, but I'm pretty sure I can avoid it.
[05:32] <tvoss_> RAOF, if the busid is still a char*, it's most likely that :)
[05:32] <RAOF> Could be :)
[05:32] <tvoss_> RAOF, I think I had this pastebin last week ...
[05:32] <RAOF> I've still got the patch in a bzr shelf.
[05:32] <tvoss_> RAOF, ah cool
[05:49] <NikTh> Hello. I have reported this bug : https://bugs.launchpad.net/mir/+bug/1196355 . Now I'm in this corrupted system and I will stay for 2 hours at least. Anything you want me to do, just ask it. I will not logout-login or reboot or restart DM.
[05:51] <tvoss_> duflu, ping
[05:51] <duflu> tvoss_,  hi
[05:51] <tvoss_> NikTh, looking at your bug report :)
[05:51] <NikTh> Also you have to know that is difficult for me to handle the system , because of the lack of windows decoration , unity and almost everything else.
[05:52] <duflu> NikTh, unfortunately lack of decorations and general "wrong things on screen" is not related to Mir
[05:52] <duflu> NikTh: Only failure to start up is a Mir issue. Can't you reproduce it?
[05:53] <NikTh> duflu, I attached the logs you asked.
[05:53]  * duflu looks
[05:57] <duflu> NikTh: Yep, if it's working now then we can't figure out the original problem
[05:57] <duflu> Unity failing to start is a different bug
[05:59] <NikTh> duflu: I will reboot the system and see if I can reproduce it.  Thanks
[05:59] <duflu> Though it looks like the issue was XMir crashing. I suspect other people have reported similar but not known why they had blank screens
[05:59] <duflu> So we have some progress I guess
[06:00] <RAOF> Hah. Once again my tests catch me out :)
[06:01] <NikTh> Is it a big difference if Xmir is enabled or disabled ?
[06:02] <duflu> tvoss_, I think sabdfl was getting similar startup issues till last weekend. Now he doesn't... randomly
[06:03] <tvoss_> duflu, yup, RAOF's prober branch should help a lot here
[06:03] <tvoss_> duflu, at least in diagnosing
[06:04] <duflu> Oh, wait, no. Twas a different error: https://bugs.launchpad.net/mir/+bug/1195509
[06:04]  * RAOF is just removing intermediate debugging before pushing something that will pass CI (fingers crossed)
[06:04] <NikTh> This system was created for this propose . Testing Xmir .  So it is a pure system. The only package I installed is "ubuntu-restricted-extras" . Nothing else.
[06:04] <duflu> RAOF: If Mir spits an exception to stderr will it go in the X log?
[06:05] <RAOF> duflu: Do you mean if libmirclient spits an exception to stderr?
[06:05] <duflu> RAOF: Not sure. I mean XMir
[06:05] <NikTh> I will reboot now to see if I can reproduce the problem.  Thanks.
[06:05] <RAOF> The X log will only catch output generated by X, and XMir only links to libmirclient.
[06:06] <RAOF> duflu: But lightdm will (should) catch anything printed to either stderr or stdout by unity-system-compositor
[06:11] <duflu> RAOF: Hmm, well it was the X server crashing apparently.
[06:12] <duflu> Forgive me for not continuing with this issue. I've already spent half the day triaging Mir bugs
[06:12] <duflu> ... which is enough
[06:17] <RAOF> NikTh: Neither of the Xorg.0.log files attached on that bug appear to come from failed attempts to run xmir?
[06:56] <RAOF> duflu: If you want to comment on https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 beyond your ‘abstain’, I'm pretty confident that this go will pass CI :)
[06:57] <RAOF> Hah. Apart from the merge conflicts, apparently :(
[07:01] <duflu> RAOF: Yeah trying to catch up on all the MPs I'm holding up :(
[07:02]  * duflu wishes it was easier to have a say in what lands, _and_ get some work done himself
[07:34] <arsson> latest updates, unity is gone.
[07:42] <tvoss_> arsson, did you pin the ppa priority?
[07:46] <arsson> tvoss_ no special methods are use in here
[07:46] <tvoss_> arsson, the lightdm version you are pulling in is newer than the version in the system compositor testing ppa
[07:47] <tvoss_> see https://launchpad.net/~mir-team/+archive/system-compositor-testing
[07:47] <tvoss_> arsson, let me find you the pinning instructions
[07:48] <arsson> tvoss_  dumbass  version please?
[07:49] <tvoss_> arsson, so when upgrading, you get a lightdm version that is newer than the one in the testing ppa. That newer version is not mir-enabled right now as we are in the process of landing Mir to universe
[07:49] <tvoss_> arsson, to make a long story short: yup, might well break your setup and I'm searching for the instructions to help you fix the issue :)
[07:53] <arsson> there was some kernel and unity updates and i was using gdm at the time.
[08:13] <tvoss_> arsson, okay, thx for the information
[08:37] <admiralmarcus> hi, how will window decorations be handled in mir? client side (csd) or server side (ssd)?
[08:42] <duflu> admiralmarcus: It's still debatable. The people designing it argue client side whereas the people implementing it still prefer server side
[08:42] <duflu> Not sure where the argument ended last
[08:43] <tvoss_> duflu, the tendency is server-side right now
[08:43] <duflu> \o/
[08:46] <duflu> admiralmarcus: Though technically right now, XMir makes X a single client and everything (including compiz and decorations) is inside the client
[08:46] <duflu> ping RAOF
[08:47] <RAOF> Pong duflu
[08:47] <RAOF> duflu: You're aware that "the tests" that are disabled without umockdev are "all the GBM tests", right?
[08:48] <duflu> RAOF: Different subject :)
[08:48] <duflu> RAOF: So XMir talks native GBM, but only as far as being a native GBM client, right? It never accesses the physical server buffers by GBM?
[08:49] <duflu> Cos that would be bypass
[08:50] <RAOF> I'm not sure what you mean by "physical server buffers" in this case; it does directly touch the buffers handed out via libmirclient, which means it's touching the server buffers.
[08:50] <RAOF> But it's *not* touching the framebuffer, unless the server is handing that out (and it doesn't, yet)
[08:50] <duflu> RAOF: Yes, umm, I mean it still can't bypass the composition
[08:50] <duflu> Right
[08:51] <duflu> RAOF: OK I will look at ways to automagically hand out the framebuffer (under conditions when it's safe)
[08:51] <RAOF> That would be good
[08:52] <duflu> Though I thought alf might have strong opinions on that
[08:53] <RAOF> Plausibly?
[08:54] <tvoss_> alf, ping
[08:55] <alf> duflu: I haven't looked into bypass at all. Last I know alan_g was looking into it for Android, but I guess the non-platform specific part of the mechanisms would be made generic enough to support all platforms.
[08:55] <alf> tvoss_: pong
[08:56]  * tvoss_ calls trigger_conversation(duflu, alf); :))
[08:56] <alf> duflu: also kdub was working into supporting it in the buffer swapping component
[08:57] <admiralmarcus> duflu: okay, thanks for the answer
[08:58] <alf> duflu: it's probably worth syncing with both alan_g and kdub to check what their plans where
[08:58] <alf> were
[09:02] <duflu> alf: kgunn asked me to start on it ASAP. Research at least
[09:03] <duflu> alf: Oh I see where alan_g started
[09:08] <RAOF> duflu: Note: when I said "the framebuffer", what I really meant was "a framebuffer"; for the gbm platform we can have arbitrarily many framebuffers. The only difference between a potential framebuffer and a regular buffer is an allocation flag.
[09:09] <duflu> RAOF: OK, so something scan-out-able
[09:09] <NikTh> Hi again. Sorry before, but I had a connection problem. (general not IRC only). I attached the new logs, I reproduced the problem. You can review them when you have time.  https://bugs.launchpad.net/mir/+bug/1196355 . Thanks
[09:10] <alf> RAOF: duflu: (also keep in mind the discussions we had about giving new framebuffers or clearing the framebuffer for security reasons)
[09:10] <alf> RAOF: or is this resolved with prime fds?
[09:10] <duflu> alf: OK, I have the issue in mind. But was not in the discussions
[09:11] <RAOF> alf: No, not resolved with prime fds.
[09:14] <duflu> alf: Yep, the code I was already looking at is the groundwork that Alan did late May
[09:16] <alf> duflu: ok
[09:31] <duflu> alf: GBM doesn't have actual documentation does it?
[09:35] <alf> duflu: there is doxygen documentation in the source files (in the mesa tree)
[09:49] <alf> RAOF: Have you started working on a C++ Udev class? I may need to do some work there soon to support monitor hotplugging.
[09:49] <tvoss> duflu, regarding the prober branch: What would be your proposal for an alternative umockdev package available on other platforms?
[09:50] <duflu> tvoss: My only suggestion is: Fall back to whatever we do now (without umockdev) if it's not present
[09:50] <duflu> I don't know the details, but I'm pretty sure it's not a portable assumption to assume a distro has it
[09:51] <tvoss> duflu, not appropriate from my perspective, we will skip a bunch of tests
[09:51] <duflu> tvoss: People building on other distros care more that the code is unbuildable than the reduced coverage, I think
[09:51] <tvoss> duflu, and that makes it a required build-dep from my pov
[09:52] <duflu> I mean, we're moving further away from Mir being portable and usable outside of Ubuntu. And we said we would work on that
[09:54] <tvoss> duflu, hmmm, I think failing at build time with a clear indication of the missing dependency is quite straightforward to fix outside of Ubuntu
[09:55] <duflu> tvoss: Not realistic. We can't depend on packages that other distros don't have packaging for yet. Unless we properly document how to build all-the-things from source
[09:56] <tvoss> duflu, hold on: I think it's a bad idea to automatically skip tests that ensure that Mir's components are working correctly
[09:56] <duflu> tvoss: It's not as bad as not being able to build (or test) it at all
[09:57] <duflu> tvoss: The debian build-dep is OK. We use that for Jenkins. I'm just saying don't impose it as a CMake requirement
[09:57] <duflu> Make the CMakeLists smarter
[09:57] <tvoss> RAOF, want me to help with that?
[09:59] <duflu> tvoss: didrocks and RAOF has already said that build-dep is a superset of the actual requirements. But if you're clever enough to build from CMake then you should have the option of not requiring things that are not required
[09:59] <duflu> -has +have
[09:59] <tvoss> duflu, I would consider something that enables all of our gbm-platform testing as required
[10:00] <duflu> tvoss: This does not limit the Ubuntu requirements. Those come from debian/control. I'm only saying loosen the restriction in CMakeLists
[10:00] <duflu> We're going in the wrong direction if Mir continually becomes less portable, as it keeps doing
[10:01] <tvoss> duflu, that's what I'm trying to say: disabling tests that are meant to be run at build-time is a dangerous thing
[10:01] <duflu> tvoss: They're still enabled for Ubuntu builds
[10:01] <duflu> By virtue of debian/control forcing them to be installed
[10:02] <duflu> But we need to be more flexible for people building Mir by hand (which includes external packagers)
[10:03] <tvoss> duflu, how do you document the udevmock dependency then for external packagers?
[10:04] <duflu> tvoss: It's enforced for Ubuntu in debian/control, and documented for everyone in CMake output as the usual "detecting XYZ: Not found: Not enabling XYZ"
[10:04] <tvoss> duflu, hmm, is that really sufficient?
[10:04] <duflu> tvoss: It's how all CMake projects work
[10:05] <duflu> You give a warning that "we think you should install XYZ", but don't absolutely require it
[10:05] <duflu> And Ubuntu packagers will never see that warning because the control file already forces umockdev to be installed
[10:06] <tvoss> okay, I think we need to agree to disagree here
[10:06] <duflu> tvoss: No problem. You can land stuff without my approval. I'll propose changes if/when it bugs me. Or someone else will
[10:07] <tvoss> duflu, fair
[10:08] <duflu> We'll stall too much if we allow vetos on everything. And we'll also land things that need more fixing later. But that's life
[10:08] <RAOF> alf: I have indeed started on a udev C++ class.
[10:10] <alf> RAOF: ok, then I will use something hacky as a first step with a TODO to replace it with services from your class when it lands
[10:12] <RAOF> alf: Sounds good.
[12:09] <tvoss_> alf, any news from jenkins?
[12:10] <alf> tvoss_: no, jobs still stuck http://s-jenkins:8080/job/mir-ci/
[12:11] <ogra_> did you contact IS ?
[12:12] <alf> ogra_: We are waiting for the US to wake up
[12:12] <ogra_> ah, yeah, lexington
[14:49] <racarr> Morning!
[14:52] <alf> racarr: Hi!
[15:00] <kdub> morning racarr
[15:02] <alf> status: Implementing notification and reconfiguration when a monitor is plugged in/out
[15:07]  * alf has found a new indicator for EOD... noticable reduction in internet speed as people come home from work and start browsing :)
[15:08] <kdub> status, got rid of ms::Surface : public mi::InputTarget, which lets us untangle a few things
[15:15] <racarr> kdub: ? What is the InputTarget then
[15:16] <racarr> alf: Happens to me too XD
[15:18] <kdub> ms::Surface is not an InputTarget, but rather owns an InputTarget
[15:19] <racarr> ok
[15:19] <racarr> kdub: I think the toyds.Window should just fire up an inputReceiver goroutine
[15:19] <racarr> err
[15:20] <racarr> :p
[15:21] <kdub> hah :P
[15:22] <kdub> breaking that inheritance though lets us proxy ms::Surface, which resolves a lot of funny lifetime issues in msh
[15:22] <racarr> I understand I think
[15:22] <racarr> makes sense
[16:39] <kgunn> bregma: ping
[16:40] <kgunn> bregma: just curious, since your guys do a lot of x debug....if i have an app rendering, and i wanted to check (runtime) what the color format of the render buffer is...is there a simple way to do that?
[17:34] <mhall119> kgunn: did we get any metrics for XMir vs. just X that aren't based on OpenGL and Framerate?
[17:35] <mhall119> for things like Lubuntu, who's performance concerns aren't about games, but rather how fast Gtk and Openbox are
[17:42] <robotfuel> mhall119: is there an existing test that measures that?
[17:45] <mhall119> I don't know
[17:45] <mhall119> just wondering if the phoronix guy measured anything except games
[17:46] <kdub> hey racarr, if you have time today  look over lp:~kdub/mir/remove-surface-target :)
[17:48] <robotfuel> mhall119: I can have jenkins run test via utah, if you have a test you want me to run I can set that up.
[17:48] <racarr> kdub: Ok
[17:48] <robotfuel> there is a regression today though. so the results won't be very useful
[17:48] <robotfuel> until that's fixed.
[17:48] <kdub> racarr, thanks :D
[17:55] <greyback> mhall119: you've seen: http://www.phoronix.com/scan.php?page=article&item=ubuntu_xmir_2d&num=1 - he measured gtk and x11 perf
[17:57] <mhall119> greyback: ah, thanks, missed that somehow
[18:00] <mhall119> robotfuel: could we run those gtkperf tests (and any other performance benchmarks" in utah?
[19:31] <racarr> Anyone...flashed a phone this morning?
[19:31] <racarr> phablet-flash is failing over and over with md5 validation errors
[19:31] <racarr> when I download the images
[19:52] <ogra_> racarr, tried re-downloading ?
[19:53] <racarr> ogra_: Like 20 times now :p
[19:53] <racarr> I am now faking the md5sum
[19:53] <racarr> That can't go wrong right
[19:53] <ogra_> which images is that ? flipped (as you should) or unflipped ?
[19:54] <racarr> the md5sum on +mako was right, just not on
[19:54] <racarr> preinstalled-touch-armhf
[19:54] <racarr> flipped
[19:54] <ogra_> hmm
[19:54] <racarr> ogra_: Presumably its the NSA slipping a backdoor in ubuntu touch
[19:55] <racarr> though you'd think theyw ould update .md5sum
[19:55] <racarr> :p
[19:55] <ogra_> we do
[19:55] <ogra_> oh, they, heh
[19:58] <ogra_> racarr, well, comparing the md5sums here all seems right
[19:58] <racarr> :/
[19:58] <racarr> what does it mean
[19:58] <racarr> haha
[19:58] <ogra_> racarr, oh
[19:58] <ogra_> can you check if there is a path in your md5sum ?
[19:59] <ogra_> if so, edit it and remove that
[19:59] <ogra_> you only want a filename
[19:59] <racarr> lets see, I already replaced the downloaded version with one that works
[19:59] <racarr> but didnt look at the contents
[19:59] <ogra_> ah, well
[20:02]  * ogra_ thinks he fixed it server side now
[20:06] <racarr> ailed to fetch bzip2:/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_saucy_main_binary-armhf_Packages  Hash Sum mismatch
[20:06] <racarr> W: Failed to fetch bzip2:/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_saucy_universe_binary-armhf_Packages  Hash Sum mismatch
[20:06] <racarr> wow
[20:06] <racarr> am I being
[20:07] <racarr> mitmed on apt by comcast
[20:07] <racarr> or something
[20:18] <racarr> hmm things are in fact broken on nexus 4
[20:18] <racarr> will investigate ter lunch
[20:18] <racarr> things are still running and input still works but nothing
[20:18] <racarr> on screen
[20:19] <kdub> really o.O? tip worked on my device this morning
[20:19] <kdub> granted, its a week or two since I flashed latest phablet
[20:24] <racarr|lunch> well this is unity
[20:24] <racarr|lunch> I will test just mir after I eat SPICY BASIL WITH TOFU AND VEGETABLES
[20:25] <racarr|lunch> omnomnom
[20:46] <racarr> hmm
[20:46] <racarr> mir_demo_egltriangle works
[21:17] <bschaefer> interesting crash that halted the xserver: http://paste.ubuntu.com/5834336/
[21:17] <bschaefer> full x log: http://paste.ubuntu.com/5834333/
[21:23] <jono> olli, tvoss hey
[21:23] <olli> jono, what's up
[21:23] <jono> olli, tvoss so I think it could be useful to have a schedule in place for dogfooding
[21:24] <jono> as an example, this is what I would need:
[21:24] <jono>  * Get rid of the cursor and use an overlay (cursor makes it difficult to use)
[21:25] <jono>  * Basic multi-monitor support (even if just mirrored)
[21:25] <jono> Unity 7 seems functional on XMir for me for daily use
[21:25] <jono> olli, would this be worth posting about to mir-devel?
[21:26] <olli> jono, I just took an AI to follow up
[21:26] <olli> I think it's good for us to have a more specific plan in place
[21:26] <olli> need to chat with poor kgunn though
[21:26] <ahayzen> is there any way of running Mir in a VM yet?
[21:27] <jono> olli, yeah
[21:27] <olli> jono, eta Wed/Thu
[21:27] <jono> olli, I think it could be good for rallying around a goal
[21:27] <jono> olli, cool
[21:29] <greyback> racarr: hey, compiler errors for you: http://pastebin.ubuntu.com/5834366/ I've merged Mir trunk into implement-client-credentials, and installed that, all fine. Then trying to build platform-api "mir-with-packaging" branch again with platform-api trunk merged into that. But it fails to compile with that message
[21:31] <racarr> greyback: Just revert the last revision
[21:31] <racarr> I tried merging trunk and didn't test yet
[21:31] <greyback> racarr: ah ok
[21:31] <racarr> I dunno
[21:35] <racarr> hmm I dont even know in regards to that compile error -.-
[21:47] <greyback> racarr: this should fix the first error: http://pastebin.ubuntu.com/5834416/ . still not sure about the second
[21:49] <racarr> greyback: Do you have any ide hat
[21:49] <racarr> //home/phablet/phablet-integrate-mir/Shell.qml:20:1: module "LightDM" plugin "LightDM-qml" not found  import LightDM 0.1 as LightDM
[21:49] <racarr> may be about?
[21:50] <racarr> greyback: Something weird is going on there I have to understand
[21:50] <racarr> because mir trunk compiles...
[21:51] <greyback> racarr: did you run the "./run" script in phablet-integrate-mir?
[21:51] <greyback> racarr: it should compile the QML plugin that you're missing
[21:53] <greyback> racarr: sorry, I meant "./build"
[21:53] <greyback> "./build -s" will pull in any build dependencies it needs, so that's usually run first.
[21:53] <racarr> greyback: Yeah :) nvm
[21:53] <racarr> I was trying to get away with a partial build XD
[21:53] <racarr> and forgot what I did
[21:53] <greyback> :)
[21:54] <racarr> no one can make it work
[21:54] <racarr> including me :(
[21:54] <racarr> it's all black screens
[21:54] <racarr> input works because multi touch crashes the binary (and doesnt with ix-pointer-indexing!)
[21:54] <greyback> grrr, what broke/changed
[21:59] <racarr> I dunno
[21:59] <racarr> build -s doesn't work either because it wants libboost 1.49
[21:59] <racarr> and mir wants 1.53 now
[21:59] <racarr> Ill figure out what broke XD
[22:02] <greyback> blimey, dependencies are changing all over the place
[22:07] <greyback> racarr: above patch fixes platform-api compile error completey
[22:08] <racarr> greyback: I don't understand it though
[22:09] <racarr> how can mir build
[22:09] <racarr> if that header cant be included
[22:09] <greyback> racarr: see that the inherited class SurfaceBufferAccess has a deconstructor defined as ~SurfaceBufferAccess() noexcept - explicitly says it won't throw an exception
[22:11] <greyback> but Surface's deconstructor didn't define what exceptions it could throw (if any) - which is considered too loose by gcc. I think clang is ok with it though, if you don't define what exceptions you throw, it assumes you can throw any
[22:11] <racarr> except it's not
[22:11] <racarr> because it builds :p
[22:11] <greyback> why Mir builds: you using gcc4.7?
[22:11] <racarr> so why doesn't it build in the platorm-api pbuilder
[22:11] <racarr> I think we are using 4.
[22:11] <racarr> 8
[22:11] <greyback> ok, me too
[22:11] <racarr> 4.8
[22:11] <racarr> yeah
[22:12] <greyback> then yeah, I don't understand that.
[22:14] <racarr> I don't think noexceot should be needed because it's the parent is defaulted
[22:16] <racarr> greyback: Maybe you are using 4.7 somehow? https://code.launchpad.net/~vanvugt/mir/fix-1196415/+merge/172279
[22:17] <greyback> racarr: holy sh*t I am. wtf
[22:17] <greyback> whaaat
[22:18] <racarr> greyback: It's ok. I'm begining to suspect the structure of logic itself is deteriorating
[22:19] <greyback> racarr: I've both 4.7 and 4.8 installed. cmake must go for the first one it sees, even though 4.8 is the default
[22:19] <greyback> dammit, sorry for wasting your item
[22:19] <greyback> time
[22:20] <racarr> no worries :)
[23:03] <RAOF> racarr: Good morning!
[23:03] <RAOF> Or afternoon. Or whatever.
[23:05] <bschaefer> RAOF, hey, I've a new crash from the x.log...this time it actually killed the server... figure you were the one to poke about it
[23:05] <bschaefer> full log: http://paste.ubuntu.com/5834333/, cut out bit: http://paste.ubuntu.com/5834336/
[23:07] <bschaefer> also, when the xserver went down, mir was still running, as the hardware cursor was still working. Just everything else was black....if thats any help :)
[23:08] <olli> RAOF, ping
[23:11] <olli> bschaefer, ping
[23:11] <bschaefer> olli, hello
[23:12] <racarr> RAOF: Morning!
[23:12] <racarr> RAOF: You must have good news right? ;
[23:12] <racarr> )
[23:13] <RAOF> bschaefer: Cool.
[23:14] <RAOF> racarr: Not any particularly good news? Except that it's morning!
[23:15] <racarr> oh well that's great news
[23:39] <thomi> hi guys - what things land in the compositor-testing PPA?
[23:39] <RAOF> thomi: Whatever we manually copy across.
[23:39] <RAOF> thomi: Also, hi!
[23:39] <thomi> RAOF: Hi :)
[23:40] <RAOF> thomi: How do I get umockdev installed in jenkins? https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/105/console
[23:40] <thomi> RAOF: hmmmm, olli is wondering if we can do something to prevent people having to use pinning in order to test the compositor - any ideas?
[23:40] <thomi> RAOF: add it as a build-dep to the mir source package, if you need it as part of the build process
[23:42] <RAOF> Impromptu baby,.
[23:43] <thomi> RAOF: .....
[23:43] <thomi> Of course I'm serious, and stop calling me Shirley?
[23:47] <RAOF> thomi: Re: not pinning.
[23:48] <thomi> I don't understand...
[23:48] <RAOF> There are two options that I can think of -
[23:49] <RAOF> 1) Ensure everything in the PPA has a higher version than in the archive. We can do this with an epoch. Downsides: you'll need to ppa-purge to get off those package versions, and that's somewhat fragile.
[23:49] <RAOF> 2) Add a new package in the PPA, depending on a virtual package provided only by the packages in the PPA.
[23:50] <RAOF> Downsides: users who dist-upgrade need to be sure the upgrade doesn't remove that package.
[23:53] <RAOF> bschaefer: Wow, that's a fun Xorg log!
[23:53] <thomi> RAOF: hmmm, it seems to be that those options both suck :-/
[23:53] <RAOF> thomi: Correct. Which is why we chose pinning ☺
[23:53] <thomi> yeah
[23:53] <thomi> ok
[23:53] <bschaefer> RAOF, yeah, its only happened twice today though...both while my CPU was close to 100% (from compiling..)
[23:54] <RAOF> Is your system particularly slow?
[23:54] <bschaefer> hmm not really, every now and then everything hangs for 5-10 seconds
[23:55] <bschaefer> and sometimes during that hang, the xserver crashes...which it just seems like the event queue is getting filled up
[23:55] <RAOF> It looks like it might be triggered by something that only happens when the event queue fills up, yeah.
[23:56] <bschaefer> does mir give events off to X? If so maybe mir needs to filter out more events?
[23:56] <RAOF> Mir doesn't give X any events; it's a strictly standard X input stack.
[23:57] <bschaefer> o well ignore that thought then :)
[23:58] <RAOF> It's a bit curious that libmirclient is above synaptics in that stack, but I suspect that's it being slow on message submission because everything's slow.
[23:59] <bschaefer> hmm yeah, im really wondering what is blocking...that causes ~500 events to be missed
[23:59] <RAOF> You're not using something silly, like btrfs are you?
[23:59] <RAOF> That's *excellent* at blocking
[23:59]  * bschaefer isn't sure what that is
[23:59] <bschaefer> haha
[23:59] <RAOF> bschaefer: Want to try the X stack from ppa:raof/aubergine? That's xmir rebased on 1.14, which may just fix this for you.