[00:11] robert_ancell: I'll email francis and see what he thinks [00:34] RAOF, I think I saw you had some bzr magic that tells you if you have merged branches that can now be pruned - is that right? [00:38] robert_ancell: Correct. [00:39] robert_ancell: You're looking for the bzr-removable plugin. [00:39] cd ~/.bazaar/plugins; bzr branch lp:bzr-removable removable [00:46] RAOF, ta [00:47] for I in $(bzr removable trunk) ; do rm -r $I ; done [00:47] (Obviously in the repository) [00:49] so handy [00:51] You'll likely find that it misses a number of branches that are actually removable - it's quite conservative. So if you've got any untracked files or uncommitted changes, the branch will not be marked as removable. [00:51] ‘bzr unremovable trunk’ will tell you why things aren't removable. === owner is now known as Guest76879 [01:49] duflu: you around? [01:49] thomi: Maybe [01:49] duflu: any idea how I can narrow down the reason why, as of this morning, compiz is using 80% of my CPU, and Xorg the other 20%? [01:50] even when I have no windows open :( [01:50] thomi: Wow. What driver/GPU? [01:50] well, other than a terminal [01:50] duflu: it's an nvidia GF116M [GeForce GT 560M] [01:51] thomi: Yeah Nvidia's the worst for CPU usage on a good day... [01:51] it's never been this bad [01:51] I also have a bangin' CPU, so 80% is quite a lot :) [01:51] thomi: It's probably some hidden(?) window generating damage [01:51] hmmmm [01:52] thomi: Try the compiz plugin CCSM>Utility>Show Repaint [01:52] duflu: I don't see that plugin in ccsm - is there a separate package I need to install? [01:52] thomi: Yes, the compiz-plugins package [01:53] gotchya [01:54] thomi: Also, some snapshots of the compiz threads using a script I will email you... [01:55] duflu: hmm, interesting. I now have a very colorful desktop [01:55] thomi: That's showing the windows generating damage/redraws [01:55] duflu: also, it seems like when I enabled that plugin the CPU usage dropped down to 30% [01:55] thomi: Perhaps it's the root window; nautilus misbehaving? [01:56] Or the unityshell plugin [01:56] wow, there we go... [01:56] ? [01:56] epileptic fit time :-/ [01:56] back up to 80% :-/ [01:57] thomi: sudo dstack compiz # a few times [01:57] https://launchpadlibrarian.net/106890342/dstack [01:57] it seems to be repainting both monitors every frame :-/ [01:57] And then send me the output somehow. In a bug? [01:58] I'm not going to *fix* compiz but might be able to tell you what the issue is [01:58] thomi: Also try unloading the unityshell plugin. It has a history of doing such things [01:59] duflu: http://paste.ubuntu.com/6001417/ [02:00] thomi: Yep, that confirms something is triggering rendering constantly. And unityshell being slow at rendering makes that 100% CPU [02:01] thomi: But unityshell is not always the trigger. Can you try disabling it in CCSM, briefly? [02:01] sure [02:02] duflu: with unityshell disabled, CPU usage drops to 63% [02:02] thomi: Still busy tho? [02:03] thomi: OK, try killall nautilus :) [02:03] hmmm, I don't see the repaint plugin flashing me anymore [02:04] * thomi tries re-enabling unity [02:05] hmm, seems to be better... so far [02:06] thomi: Yeah I think I've seen that before. Nautilus randomly goes nuts and since it draws the desktop, that means everything gets repainted [02:07] interestingly, this happened after a reboot as well [02:07] it's interesting to see just how often we repaint things, sometimes for no discernable reason [02:07] for example, as I type this on the RHS monitor, chromioum is busy repainting all sorts of things on the LHS monitor [02:09] thomi: Yes, we browsers will repaint constantly due to animations, somehere, on some tab [02:09] -we +web [02:13] well, it seems to be sitting at 60%, which is at least somewhat usable - thanks for your help [02:17] thomi: 60% is bad. Is the flashing at least limited to a window now? [02:19] I mean, Show Repaint no longer shows the whole screen repainting, right? [02:29] ... You have to treat the root cause, which sounds like nautilus in this case. Unfortunately using unityshell (< 8.0) and Nvidia drivers will make performance worse [02:54] * duflu vanishes to test some ISOs briefly [03:02] thomi: I'm curious and concerned... Still 60%? Is showrepaint showing the whole screen repainting or just some windows? [03:17] duflu: hey, yeah, still %64 [03:17] but showrepaint no longer shows whole screens being redrawn [03:17] so I think we're one step better than we were [03:19] ahaaaaa [03:19] thomi: Without a browser? [03:19] duflu: one of my chromium tabs had a notification, which makes chromium fade the tab colour in and out endlessly. if I get rid of the notification, it drops down to 19% [03:20] thomi: Also, I think some hacks in unityshell means compiz will get damage events from minimized windows. Which is not ideal. [03:20] :-/ [03:20] man, I can't wait until we have mir - I'm sure then we won't see these sorts of problem.... RIGHT GUYS!?? [03:20] :P [03:22] thomi: Yeah Mir has a simpler and more sensible damage model. It also doesn't have Unity7/Nux sitting on top of it to consume yet more CPU/GPU [03:22] yup [03:23] by then hopefully we'll have better graphics driver support as well [03:23] thomi: Tho we can't "fix" browsers or make Nvidia's proprietary drivers any less CPU hungry [03:23] :-/ [03:24] By "fix" I mean stopping them from repainting when they actually need to [03:24] You could "fix" /all/ the web pages to make them more efficient for idle desktops [03:24] There can't be that many web pages === chihchun_afk is now known as chihchun [03:45] thomi: CPU usage is really an equation with many coefficients. So we don't need to "fix" browsers or drivers if we can lower enough of the coefficients using Mir/Unity8 [03:46] sure [04:59] thomi, I'm going to merge in the Ubuntu packaging into LightDM - https://code.launchpad.net/~robert-ancell/lightdm/debian-packaging/+merge/180766. Can you make the appropriate changes to CI / autolanding so it doesn't try and use the obsolete lp:~lightdm-team/lightdm/trunk-packaging? [05:02] robert_ancell: yes, but we cannot redeploy those changes until tomorrow [05:02] thomi, that's fine [05:03] ok, cool [05:05] robert_ancell: while I'm in here, do you still need/want autolanding & CI for lp:~mir-team/lightdm/unity ? [05:05] thomi, nope, that branch is dead [05:06] cool [05:06] Mir support is in trunk now, and in the archive [05:06] thomi, oh, did the raring builds get turned off for the staging PPA? [05:07] they seem to still be building [05:07] robert_ancell: hmm, I could have sworn I'd landed that change, but it seems they're still configured [05:07] removing them now as well [05:11] robert_ancell: FYI: https://code.launchpad.net/~autopilot/cupstream2distro-config/lightdm-config-tweaks/+merge/180768 [05:12] thomi, does the staging PPA still get lightdm built from trunk? Is that done from somewhere else? [05:13] good morning [05:13] tvoss_, hello [05:13] robert_ancell: no, it looks like lightdm trunk gets built into ppa:lightdm-team/daily [05:13] robert_ancell, hey there :) happy new week [05:13] hi tvoss_, how's it going? [05:13] thomi, ah, ok [05:13] thomi, good, but my week is roughly 13 minutes old :) [05:13] robert_ancell: and in that PPA we build for precise<->saucy and everything inbetyween [05:13] thomi, how are you? [05:14] tvoss_: so far so good :) [05:14] enjoying a quiet monday without all you europeans asking me for things :P [05:14] thomi, cool. So I'll delete lightdm from the staging PPA and point people at the lightdm-team/daily PPA if they need to test new changes [05:14] thomi, so does the config need updating for the daily PPA to change the packaging? [05:14] robert_ancell: yeah. If we want it built into two places we may be able to accomodate that, but TBH that sounds like a bad idea to me [05:15] thomi, shouldn't be any need [05:15] robert_ancell: that's what I just changed [05:15] robert_ancell: diff line 17 from that MP [05:16] ah, ok [05:16] awesome! [05:16] although, the diff is kind of hard to read, since LP doesn't give us much context around changes :-/ [05:16] yeah, that's what go me [05:31] RAOF, can haz review plz? https://code.launchpad.net/~robert-ancell/unity-system-compositor/apport-pci-info/+merge/180771 [05:31] stolen shamelessly from xorg packaging [05:32] * robert_ancell -> EOD [05:42] didrocks: Are we able to reproduce the ATI bug on the jenkins machine with the most recent mir? [05:42] RAOF: not sure, as we stopped building it [05:42] RAOF: do you think there is hope? [05:43] didrocks: Well, https://bugs.launchpad.net/mir/+bug/1212516 is maybe related and might be fixed... [05:43] Launchpad bug 1212516 in Mir "valgrind integration-tests: [ FAILED ] BespokeDisplayServerTestFixture.*" [Undecided,In progress] [05:43] RAOF: ok, I'll ask to have a try later today [07:01] good morning [07:16] dholbach, salut [07:18] hi tvoss_ [07:24] morning all [07:26] Ah, yes. When changing XMir ABI it's important to actually update the drivers… [07:28] * duflu is still impressed every time he sees Mir smoothly and reliably use multiple monitors [07:28] Then prepare to be amazed by XMir smoothly and reliably using multiple monitors! [07:28] *: FSVO ‘smoothly’ [07:29] *: FSVO ‘reliably’ ☺ [07:29] FSVO? [07:29] For Some Values Of. [07:30] Ah, my math terminology is rusty [07:31] sudo apt-get install bsdgames; wtf fsvo :) [07:32] Woot! [07:32] Gone from no output to infinite loop after presenting the first frame! [07:32] It's /a step/ [07:33] One small step for correctness, one giant leap for fan noise [07:41] Gah. Stupid closures in C and their stupid type-erasing void *ctx. [07:49] RAOF, https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801 [07:50] mzanetti, good morning :) [07:50] good morning tvoss_ [07:50] mzanetti, hey :) so can you check if our friend the upstream merger is still alive? [07:50] hehe, sure [07:52] tvoss_: what makes you think it isn't? [07:53] mzanetti, I pushed to https://code.launchpad.net/~thomas-voss/platform-api/location-service/+merge/180692 [07:53] mzanetti, an hour ago, and still no vote [07:53] tvoss_: right. I'll check [07:53] tvoss_: otherwise it seems to do stuff. not sure why this one wasn't picked up [07:53] mzanetti, thx :) [07:54] tvoss_: "no vote" -> maybe he's undecided and wants to vote blank ;) [07:54] didrocks, well, I always figured that our jenkins setup might evolve to become skynet, but I haven't expected it that early [07:55] tvoss_: oh... the build queue holds like 50 jobs :/ [07:55] mzanetti, oops [07:56] this is not looking good. [07:56] tvoss_: ahah ;) [07:58] duflu: Hi! Bypass question: why do we care about transformations of non-fullscreen windows in the bypass filter? [07:58] alf__: Because no one uses the fullscreen state yet. It's not "wired up" [07:59] When it is, the certainly we'll use it [07:59] duflu: no, I mean we are checking for orthogonality of all windows, why is that? [08:00] alf__: Because a rotated window should not get bypassed. It would lose transformation [08:00] Oh, I see [08:00] Hang on [08:01] That was to fix a bug, let me find it [08:02] alf__: It's to reliably detect overlaps. If a window overlaps a fullscreen window then the fullscreen window can't be bypassed. And I do calculate the overlap for "orthogonal" windows, but for rotated windows it's too hard/unreliable. Safer to assume if anything is rotated (not orthogonal) then some fullscreen window "might" be overlapped. [08:03] And there are test cases which will fail otherwise... [08:04] duflu: ok, thanks [08:05] alf__: Also, I suspect in future that rotation will not be an attribute of a surface, but rather a function of an effect or animation that's in progress. If that changes then we will test for "any effects in progress" instead [08:09] alf__: I now see however that I shouldn't be caring about rotated windows that are underneath [08:10] Unless we start using Z-buffers [08:10] duflu: I think that's ok for now (for the XMir use case) [08:11] alf__: I think it may even become preferable to be "less correct" in future to stop more edge cases from accidentally un-bypassing a fullscreen window [08:12] Although that's less important for Mir where bypass can be switched on/off between frames. It was important in Compiz where there's a 2-frame lag [08:15] alf__: Actually that's a fun multimonitor test for bypass: Run egl{plasma,triagnle} -n -f, and then a second smaller windowed client. See how the first fullscreen client speeds up when there's nothing overlapping it [08:15] duflu: ack, will try it out [08:17] tsdgeos, so it's not looking like racarr got anywhere on Friday? :/ [08:18] i think not :_/ [08:18] Saviq, is ogra_ back? [08:18] ogra_, ping [08:18] tvoss_, was he away? [08:18] Saviq, ah no, that was rsalveti [08:19] tvoss_, canonicaladmin.com says he should be back today [08:19] Saviq, ah [08:19] greyback, tsdgeos let me know what I can halp with, will try the app auth out now [08:20] tvoss_, yup [08:20] Saviq: thanks [08:20] ogra_, hey, did something change in the lxc-android-container configuration in terms of memory limits? [08:21] tvoss_, nope, not that i'm aware of [08:21] hmm ... unless ... [08:21] ask the security team, they might have tightened apparmor rules [08:22] thats the only thing that comes to mind [08:22] ogra_, for some weird reason, when Mir tries to access the framebuffer, we see ENOMEM in ptrace [08:22] ogra_, thanks for the hint [08:24] tvoss_, oh, there were also apparmor kernel changes now that i think of it, but i dont think xnox has rebuilt the android package for them yet [08:24] might be that something is out of sync there [08:25] ogra_: ack. [08:25] ogra_, thanks [08:39] tvoss_: jenkins doesn't come up again after a restart. I fear we need to live without it for the next couple of hours until some of our jenkins experts are online [08:40] mzanetti, thx [08:41] tvoss_: maybe ask gema? her team should have some people for this kind of production issue? [08:49] hikiko: welcome back. Good break? [08:50] hi alan_g :) yes it was nice! [08:52] hikiko: Are you caught up yet? We landed some nested mir stuff while you were away and more is waiting for review: https://code.launchpad.net/~alan-griffiths/mir/native-platform/+merge/180618 [08:52] let me get a look at it :) [08:55] hikiko: Once you've done that we should plan the next steps together. [08:59] alan_g, you merged the nested-display branch and you added the NestedGbmPlatform isn't it? [09:00] tvoss_, oh, interesting find (re ENOMEM) [09:01] hikiko: *Native*GbmPlatform (and NativeAndroidPlatform) [09:02] Saviq, yup, that was the only thing that was hinting to an issue [09:04] sorry that's what I meant I am pulling :) [09:19] didrocks, can you give https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing a try on the ati machine [09:20] sil2100: ^ [09:21] tvoss_: weird that RAOF told me that latest trunk may fix it [09:21] as it's not merged yet [09:21] ;/ [09:21] so we will need a ppa + rebuild [09:21] ;\ [09:21] didrocks: That's another possible fix. [09:21] sil2100: handling that? [09:22] sil2100: maybe take latest mir trunk + merge that [09:22] and push to a ppa [09:22] once built, push u-s-c there [09:22] and we can then just test installing from the ppa? [09:34] Ok [09:49] Hmm, I could return to trying to figure out test case side-effects and whether they're important... [09:50] ... or I could finish early and work on preparing a healthy meal [09:50] Right then [09:51] alan_g, when I build trunk [09:51] I get this: [09:51] make[2]: *** No rule to make target `/usr/lib/libboost_chrono.so', needed by `lib/libmirclient.so.1'. Stop. [09:51] although I have libboost-chrono-dev installed [09:52] hikiko: your cmake cache is out of date with saucy [09:52] delete it and run cmake again [09:52] but I just did bzr branch lp:mir :s [09:52] ok [09:52] I will try [09:53] hikiko: that's odd then [09:54] hikiko: are you using any ppas? [09:54] greyback, oh, tricky... webbrowser creates a separate surface it seems [09:55] greyback, and it gets rejected [09:55] Saviq: quite likely, as the webprocess separate. Good catch...wonder how to work-around [09:55] greyback, indeed [09:56] alan_g, mir-team/staging/ubuntu and http://ppa.launchpad.net/phablet-team/ppa/ubuntu [09:57] greyback, it feels like unity8 starts faster with Mir, are you seeing the same? [09:57] Saviq: hud is disabled :) [09:57] lol [09:57] must re-enable it [09:57] alan_g, I am dist-upgrading maybe that will solve the problem, I didn't upgrade for 10 days or more [09:57] greyback, desktop hint → happroved [09:58] Saviq: thanks. [09:58] hikiko: you shouldn't need the ppas as everything ought to be in the distro [09:59] ok, I ll remove them and try again, thanks! [10:21] alan_g, the branch looks good but shouldn't we call the NativeGbmPlatform NativeGBMPlatform to match the GBMPlatform? could I rename it? [10:22] hikiko: we should, but as alf__ top-approved without that tweak we can do it in a future MP (it only affects a couple of lines in a .cpp we need to change anyway) [10:26] hikiko: you building OK now? [10:27] yes alan_g [10:27] after upgrading everything is fine === hikiko is now known as hikiko|lunch === tvoss_ is now known as tvoss|lunch [10:49] tsdgeos, hey, I might take over QDesktopServices::openUrl from you, interested? [10:49] Saviq: all yours, i'm doing some unit/auto/something-tests for greyback [10:50] tsdgeos, yup, know that [10:50] tsdgeos, any quick pointers where I should put that in (e.g. the DBus service backing it)? [10:51] Saviq: tbh not sure what's needed, so we want QDesktopServices::openUrl to do what? open the appropiate app for that url? do we have such system in place? [10:52] tsdgeos, a preliminary one, yes [10:52] and that's going to call ApplicationManager::startProcess or something unrelated to start the app? [10:52] tsdgeos, https://launchpad.net/url-dispatcher [10:53] tsdgeos, upstart [10:53] Saviq: ok, why not ApplicationManager::startProcess? it needs to have upstart support afaics from the comments [10:53] may as well have the upstart code only once? [10:53] tsdgeos, yeah, it seems url-dispatcher is a self-contained thing now [10:54] tsdgeos, will talk to tedg on that later [10:56] Saviq: i would understand that it should go in unity-mir, probably [10:56] tsdgeos, yeah, that's for sure [10:56] not sure which class exactly [10:57] i don't think ApplicationManager is a bad place [10:57] but gerry may disagree [10:57] tsdgeos, we agreed on that before already [10:57] fine with me [10:57] ah, did we? [10:57] :D [10:57] * tsdgeos can't read lately [10:58] * greyback_ rebooting as Mir seems to freeze his machine [10:59] alan_g: ping [10:59] greyback_: hello [10:59] alan_g: hey there, I need some advice from you [11:00] alan_g: I am trying a simple unity-mir server on my desktop. Something is not happy, as when running it, my machine's graphics completely hangs. I can ssh in, but could you give me tips on how to debug? [11:01] does ssh work? [11:01] mlankhorst: yes [11:02] I suppose catching output into a file is necessary for a start [11:02] alan_g: also, if using XMir, would my Mir instance with XMir collide? (I've disabled xmir) [11:02] greyback_: I usually try running from an ssh session so that I can see errors. (and maybe turning on some logging) [11:03] greyback_: yes, we don't have nested mir sessions working yet [11:03] alan_g: ack [11:04] alan_g: any way to confirm xmir not running? [11:05] greyback_: I'm the wrong one to ask (I have never enabled it) [11:05] alan_g: ok, thanks === greyback_ is now known as greyback|unstabl [11:06] greyback_: I'd guess there's be a u-s-c process running (but I don't actually know) [11:06] greyback|unstabl, lp:platform-api/mir is merged into lp:platform-api already? [11:08] Saviq: yes [11:08] greyback|unstabl, good, thanks [11:08] Saviq: same with qtubuntu [11:10] alan_g: ever got this exception: "Failed to mute keyboard" when launching over ssh? Would it be that I'm sshing into my primary machine (that I'm typing this on) [11:12] greyback|unstabl: yeah, sounds like X owns the keyboard. You need to be in a VT (and tell your server which one with --vt) [11:12] alan_g: aha, --vt! Thanks [11:13] greyback|unstabl: ./mir_demo_server --help is wonderful [11:18] greyback|unstabl: how do i "stop" a QMirServer? [11:18] it seems that returning from the function i pass to runWithClient is not enough === hikiko|lunch is now known as hikiko === alan_g is now known as alan_g|lunch [12:49] alf__: hey...nice job on mm... [12:53] kgunn: thanks, did you try it out? [12:54] alf__: not yet....was just looking at what landed while i was out.... [12:54] alf__: and what new problems we have :) === kode54_ is now known as kode54 === alan_g|lunch is now known as alan_g [13:52] tvoss|lunch: so are we able to pilot https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801 on didrocks machine? (sorry if this is old news) [13:54] kgunn, I think sil2100 did === tvoss|lunch is now known as tvoss_ [13:55] sil2100: how many successful runs? i only ask because this is a heisenbug....i know didrocks got 10 in a row once [13:55] with the "current failing config" [14:02] didrocks, got an update on https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801 [14:03] tvoss_: as you told, sil2100 is on it [14:03] I didn't got any update since, he had some issue with his ppa, then I think he copied to another one but didn't get feedback [14:03] let's wait for him :) [14:09] didrocks: running the tests, but so far no failures - but no many tests have passed yet [14:10] if 2 tests pass, we're fine TBH [14:10] sil2100: you will rerun it then? [14:10] (hum, aren't we at next tick though?) [14:10] still 30 minutes until the first stack starts I guess [14:10] I know ;p [14:11] uuuu [14:12] didrocks: hmmm [14:12] didrocks: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console [14:12] didrocks: looks to me like 'it' ;/ [14:12] didrocks: since it seems that it stopped on the opengl [14:12] kgunn: ^ [14:13] right [14:13] tvoss_: ^ [14:13] sil2100: we'll need to free it for production in some minutes (reboot electrically directly the machines to avoid having next test failing) [14:14] sil2100: let's wait a little bit to see if kgunn/tvoss have a chance to get to it [14:15] Ok [14:24] tvoss_: ? [14:24] didrocks: I guess we might have to reset the machine? [14:24] sil2100: didrocks ...can we get another opportunity to build in the patch [14:24] sil2100: agreed [14:24] from RAOF http://paste.ubuntu.com/5983202/ [14:25] understanding this might be a while [14:25] kgunn: IIRC, this one was already tried [14:25] kgunn: without any success [14:25] didrocks: its not a solution... [14:25] its debug [14:25] yeah, we tried it [14:25] and couldn't get any blocking situation [14:25] (after 20 runs) [14:26] damn heisenberg… :p [14:26] didrocks: oh...the debug patch changes timing... [14:26] ug [14:26] right :/ [14:27] didrocks: sil2100 ...can you at least grab the logs off it before rebooting [14:28] sil2100: mind doing that? see the logs I attached to the bug and paste the same [14:28] sil2100: just log into the container and installs pastebinit [14:28] it's the easiest [14:28] sil2100: can help you if needed (but in meetings) [14:29] Doing ;) [14:29] Looking at the bug first [14:35] kgunn, tvoss_: attached the logs to the bug as a comment [14:35] sil2100: thank alot [14:36] didrocks: would it be enough if I just restart the machine through ssh? [14:36] sil2100, thx [14:37] sil2100: yeah [14:37] didrocks: do I have to detach the lxc containers first or nothing needed ;p ? [14:37] sil2100: no no, it's fine [14:38] sil2100: just reboot outside the container though :p [14:38] or you just shut down the container then :p [14:38] Rebooting normally then, thanks ;) I prefer to double-ask with fragile things [14:40] sil2100, does not look like anything failed judging from the logs [14:41] tvoss_: didn't paste in compiz logs, but it's the same as before - it's stopping on loading the opengl plugin [14:42] sil2100, ah, what was the error message again? [14:44] tvoss_: no error message really, just this from compiz, as seen in this comment: https://bugs.launchpad.net/mir/+bug/1204939/comments/11 [14:44] Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (Mir fails to respond to drm_auth_magic request)" [Critical,Triaged] [14:45] Saviq: confirmed with alan_g ....current mir worked on old image....so, makes me wonder if we updated android trees or move kernel [14:45] more so than i did [14:45] kgunn, right [14:46] Saviq: even better...alan_g says old mir fails on new image [14:46] ricmm, hey, wanted to ask, where should put the platform api part of QDesktopServices::openUrl()? [14:47] Saviq: I need more context [14:47] ricmm, it'll effectively be just a DBus call to AppManager [14:47] sil2100, so it segfaults? [14:47] ricmm, that will ask it to open the url provided [14:47] kgunn: Saviq - alf__ tried an old mir on the new image === alan_g is now known as alan_g|tea [14:48] tvoss_: hm, hard to say this time, I would assume yes but it says nothing in the logs: jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console [14:48] tvoss_: scroll down to the bottom and try finding compiz init phase [14:49] sil2100, I get an error accessing https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console [14:49] hm, then maybe http://10.97.0.1:8080/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console <- with VPN access === alan_g|tea is now known as alan_g [15:11] Morning [15:20] afternoon === dholbach_ is now known as dholbach === sfeole` is now known as sfeole [16:17] racarr_: ping [16:19] so wrt "mir doesn't work on n4"...the current belief is that its a um/km out of sync issue.... [16:19] looks like at ~1:30 today there will be a 19.2 image available (where all will be resync'd) [16:20] racarr_: so basically....save beating your head on the n4 mir thing until then....& [16:20] hopefully it will just be corrected by the image creation...can you test that this afternoon ?? [16:20] kgunn: um/km? [16:20] I definitely can! and that's [16:20] user mode/kernel mode [16:20]