=== m_conley_away is now known as m_conley
=== duflu_ is now known as duflu
=== thumper is now known as thumper-afk
=== m_conley is now known as m_conley_away
=== thumper-afk is now known as thumper
Laneyhey ho09:02
pittihey Laney, had a good we?09:11
Laneyhey pitti, was nice thanks09:12
Laneymade beer & wine & mead, all fermenting away now09:12
pittiwe had some friends visiting, and spent much time walking, talking, playing badminton and Wizard :)09:13
larsumorning guys09:13
* Laney googles wizard09:13
pittihey larsu, how are you?09:14
Laneyhey larsu, how goes?09:14
pittiLaney: http://en.wikipedia.org/wiki/Wizard_%28card_game%2909:14
larsupitti, Laney: good, thanks! And you?09:14
* larsu feels efficient09:14
pittilarsu: very well, thanks09:14
Laneyremembering that I left before the weekend having made a patch which crashes AS09:15
Laneyand not wanting to look at it any more :P09:15
larsuis that why I had problems logging in this morning?09:15
Laneyno sir09:15
Laneyit didn't leave my computer yet09:15
larsuhm, must've been something else then09:16
larsuit worked after upgrading from a vt09:16
Laneycheck lightdm / upstart logs09:16
larsu"Failed during authentication"09:17
larsuthat's all lightdm had to say about that09:18
larsuin a debug message, no less09:18
Laneytseliot: hey, could you push screen-resolution-extra to bzr please?09:43
tseliotLaney: I maintain it in git09:44
tseliotLaney: I thought I had pushed it though. I can do that if you want09:45
LaneyPlease fix Vcs-Bzr then09:45
tseliotLaney: let me check09:45
tseliotLaney: done10:02
tseliotLaney: and thanks for making me notice ;)10:02
Laneytseliot: thanks to you!10:03
LaneyWhat I was going to do is to put the change I uploaded over the weekend into bzr10:03
tseliotLaney: oh, what change is it?10:03
LaneyI guess I can't push to the git repository, so if you could do that10:03
tseliotLaney: oh, no wonder my upload was rejected. Let me fix that10:04
LaneyI tried to push it back but found that bzr was out of date10:05
Laneyand then here we are10:05
tseliotoh, I see10:05
tseliotLaney: it should all be fixed now. Thanks again10:16
Laneycool, cheers10:17
=== MacSlow is now known as MacSlow|lunch
=== alan_g is now known as alan_g|lunch
=== MacSlow|lunch is now known as MacSlow
=== greyback is now known as greyback|lunch
=== alan_g|lunch is now known as alan_g
pittidesrt: hey Ryan, how are you? enjoyed your holidays?14:28
desrtwhat holidays? :)14:29
=== greyback|lunch is now known as greyback
pittidesrt: I thought you took some days off after the sprint?14:32
desrtah.  just a couple of swap days14:32
desrtone for travel and one for a missed holiday14:32
=== synaptix is now known as thecowmoos
pittidesrt: not sure whether you saw the recent updates on bug 118426214:32
ubot2Launchpad bug 1184262 in systemd-shim (Ubuntu Trusty) "[logind] times out too early, stuck in PrepareForSleep, causing network and other services to not resume" [High,In progress] https://launchpad.net/bugs/118426214:32
desrtdidn't see it14:33
pittidesrt: we need to find out how to change the timeout in -shim to not apply during method calls14:33
pittidesrt: as soon as a suspend/resume takes longer than 10s, the GTimeout hits, and the PrepareForSleep False signal is never sent14:33
=== thecowmoos is now known as synaptix
pittidesrt: I put an experimental version into my PPA which bumps it to 10mins, which helps for most people14:33
pittibut not for longer sleep cycles14:33
desrtpitti: did you want to take over systemd-shim maintainership? ;)14:34
pittidesrt: because of the PPA version? that was mostly to understand/confirm what the problem is14:35
desrt(at this point, you have a far far greater understanding of this stuff than i do)14:35
* desrt really just wanted working timedated :)14:35
larsulol. "I have this problem with your software. Can you help me fix it?" -- "Do you want to instead maintain the software forever?"14:36
larsuhi desrt! ;)14:36
Laneypatches welcome-ng14:36
pittidesrt: if you want to give me commit rights, I wouldn't mind14:37
desrtpitti: this is absolutely what i want :)14:37
desrtpitti: also: you could just fork the project and host it elsewhere14:37
pittidesrt: as for that actual bug, can you "suspend" a GTimeout source somehow?14:38
desrtpitti: so that it follows real time instead of monotonic time?14:38
pittidesrt: or should shim_method_call() just delete the source at the beginning, and re-create it at the end?14:38
desrtah ya.  there is no way to reset it, if that's what you mean14:38
desrtother than destroy/create14:38
pittiwe need to replace the returns with some "goto out", but *shrug*14:38
pittidesrt: destroy/creat seems safest indeed14:39
pittidesrt: ok, I'll look into that14:39
pittidesrt: where is the upstream git?14:39
desrtwhich is why i thought that maybe you like to fork it14:39
desrti'm happy to add your git account as a committer in any case14:40
desrt(if you have one on github)14:40
pittiyeah, better to have one trunk IMHO14:40
desrti'd probably take mine offline if you forked it :p14:40
pittidesrt: c'est moi: https://github.com/martinpitt14:40
desrtk.  you're "collaborator" on the project now14:42
desrtwhich i think means that you can push14:42
pittidesrt: ack, thanks14:42
desrtpitti: i'm happy to look at the patch for sanity on the timeout-use side if you explain to me what it is you're trying to do on the d-bus side :)14:42
dpmhi seb128, how are you?15:29
Sweetsha1kHeya seb128!15:30
=== alan_g is now known as alan_g|tea
* Sweetsha1k almost has a LO 4.2.0~alpha1 build on trusty done (plus a 4.1.3 in the PPA to be SRUed ~next week).15:31
seb128dpm, Sweetsha1k: sort of yeah, today is a national holiday, just hanging around but not working (e.g better to wait tomorrow if you have stuff you want me to do)15:31
dpmseb128, it can wait until tomorrow, enjoy your day off!15:32
pittidesrt: I added a reproducer to the bug, I now get the issue myself; WDYT about http://paste.ubuntu.com/6400271/ ?15:33
pittidesrt: that fixes it for me15:33
seb128dpm, yw ... you can still ask, I'm a bit curious of what you need (I might just tell you to ping me again tomorrow then ;-)15:34
desrtpitti: oh.  this.15:35
desrtpitti: so i already had a weaker form of this...15:35
pittidesrt: yes, disabling the timeout after shutdown15:35
desrtpitti: did you see that the poweroff job permanently disabled the inactivity timeout?  your patch will probably have a weird interaction there.15:35
dpmseb128, it's about moving sessions in the schedule. I've sorted it out by now, but it'd be good if we could swap tracks for the "Push notifications" and "Music app 14.04 development". I can do it myself for the music session, but I've got no permissions on the client track -> http://summit.ubuntu.com/uds-1311/2013-11-21/display15:36
pittidesrt: that flag is checked in exit_on_inactivity(), not in activity_timeout()15:36
pittidesrt: so while I could check in_shutdown in activity_timeout() as well, we shouldn't really have to?15:36
desrtpitti: evil :)15:36
desrti was lazy....15:36
pittidesrt: but poweroff isn't one long method call15:36
pittiwhile calling pm-suspend seems to be15:36
seb128dpm, done15:37
desrtpitti: i have a greater understanding of the problem after seeing this patch now.  thanks :)15:37
dpmawesome, thanks seb128 :)15:37
seb128dpm, yw15:37
pittidpm: it's pretty much the minimum change; we can certainly arrange for moving teh in_shutdown check, i. e. if (enable && !in_shutdown)15:37
pittisorry, desrt ^15:38
dpmnp :)15:38
pittidesrt: BTW, we recently got bug 1211514, so something there is still wrong, too :/15:39
ubot2Launchpad bug 1211514 in systemd (Ubuntu) "Shutdowns fail to finish if laptop lid is closed before completely shutdown" [High,Confirmed] https://launchpad.net/bugs/121151415:39
pittidesrt: (but that sounds unrelated; we need to disable logind's suspend during shutdown)15:39
pittidesrt: so if that patch seems ok to you, I'd look into that bug next, and release 415:40
desrtpitti: so the patch is simple and inelegant15:40
desrtwhich fits nicely with systemd-shim's entire existence :p15:40
pittidesrt: inelegant> agreed15:41
desrtthe only thing i'd consider changing is upping the complexity for favour of a bit more elegance:15:41
desrtwhen we get a method invocation in, do use_count++15:41
desrtthen hook up a weak ref handler to do use_count--15:41
desrtand don't exit when we have a positive use_count15:41
pittidesrt: ref handler? not just count-- on method exit?15:41
desrtpitti: that's where all your goto is coming from...15:42
desrtalso: this patch is kinda bogus, actually....15:42
=== alan_g|tea is now known as alan_g
desrtso everything in systemd-shim is synchronous15:43
desrtwhich is why your patch works at all15:43
desrtbut since that's the case, it means that the mainloop isn't running at all while any method is being handled15:43
desrtso it's impossible for a timeout to occur in the middle of a method call15:43
pittiyeah, I don't fully understandt this either; I'd expect the method return to be done before the main loop gets back and runs the timeout15:44
pittibut demonstrably it does15:44
desrtwhat's happening is surely this:15:44
desrtthe method call reply gets sent to the dbus worker thread15:44
desrtthe main thread hits the timeout15:44
desrtand the program quits before the worker thread has a chance to send the message15:44
desrtso we could fix this a couple of ways15:45
pittiwe have the while(1) g_main_context_iteration in main15:45
desrtjust move had_activity() to the bottom15:45
desrt(keeping your gotos)15:45
desrtie: reset the timer as of when the method call stopped, not started15:45
desrtand/or: flush the bus before we quit15:45
desrtto make sure the reply gets out properly15:45
pittidesrt: but we still need to explicitly stop it at the top, no?15:45
desrtthe mainloop isn't running anymore, so the timeout can't possibly fire15:46
pittiotherwise a timeout set by the previous call could hit in the middle of the next call15:46
pittibut it would have the same race with the main loop after return as right now?15:46
desrtno... because we'd always reset the timeout just before returning15:46
Sweetsha1kseb128: nothing urgent here, have fun celebrating that mantle slicing weirdness!15:46
desrtit really depends on your definition of inactivity timeout... in any case we should definitely be flushing the bus before we return15:47
desrtthis is a full-on bug right now, no matter how you consider it15:47
pittidesrt: ah, I see15:47
desrtthat race is the source of this problem -- even if all calls were handled instantly (or if we rescheduled at the bottom instead of the top), there would still be a theoretical race there in case that sending the message took longer than 10 seconds15:47
pittidesrt: how do you flush the dbus?15:48
pittidesrt: sorry, phone, bbl15:48
desrtthat theoretical race would "never" happen of course, because 10 seconds to send a message?  seriously?15:48
desrtbut we should still close it15:48
desrtpitti: i'll do a patch15:48
desrtthe flushing alone should make the bug go away but we might want to do your patch anyway (or a simplified version) to tweak our definition of 'inactivity' to be more sensible15:48
desrtpitti: okay.  i have a patch now.15:52
pittidesrt: oh, I see15:53
desrteven with your patch we should do this one15:53
pittidesrt: yes, I agree15:53
pittidesrt: so your's to never lose the reply, and mine to avoid immediately exiting after a (long) method call15:53
desrtbecause the race is still there (although it would only occur if the worker thread took >10 seconds to be scheduled for some bizarre reason)15:54
desrtpitti: we should do both15:54
pittidesrt: yes, as I said, I agree :)15:54
desrtpitti: i leave it to you to decide how you want your patch to look15:54
seb128desrt, pitti: the "suspend if closing the lid for shutdown" ... I think desrt had a tentative patch for that, but it dropped from my list and I didn't upload to to distro, the commit is the current one in his git though15:54
pittidesrt: but then with the modification to only set had_activity() at the bottom in success:15:54
desrtdescheduling at the top is strictly pointless15:54
desrtbecause the loop isn't running15:54
pittiseb128: oh, I had assumed we had that already15:55
seb128desrt, pitti: though it seems like you guys are doing extra fixing there, I'm just mentioning it in case it's useful15:55
seb128pitti, no we don't, I was supposed to test and backport and that slipped through :/15:55
pittiseb128: thanks, but that's a different bug; I was goin to look into this one, too15:55
desrtseb128: after these two patches it's worth a new upload for sure15:55
desrtprobably even an SRU15:55
seb128pitti, I can easily reproduce the suspend on shutdown bug, I can try the patch later15:56
seb128desrt, right15:56
pittiseb128: yes, me too15:56
pittidesrt: absolutely an SRU15:56
pittiI can do the trusty and saucy uploads15:56
desrtpitti: okay.  i pushed mine.  should i rework yours or do you want to do it?15:57
pittidesrt: hang on, rebasing/redoing/testing15:57
desrtpitti: (thanks, btw, for writing the patch in the first place -- for some reason i absolutely could not understand the problem as it was being presented to me in english... seeing the code helped)15:57
pittidesrt: http://paste.ubuntu.com/6400402/16:01
desrtpitti: did you type 'make'?16:01
desrt@@ -51,7 +51,10 @@ had_activity (void)16:01
meetingologydesrt: Error: "@" is not a valid command.16:01
desrt+  had_activity (TRUE);16:01
pittidesrt: no, not yet; I was going to ask "is that approach what you had in mind"16:02
desrtpitti: yes.  that looks fine to me.16:03
pittiah, forgot to fix the last call, erk16:03
desrtexcept setting the timeout to 0 is pointless16:03
desrtsince you unconditionally reset it again just below16:03
desrt+      inactivity_timeout = 0;16:03
desrt+    }16:03
desrt 16:03
desrt   inactivity_timeout = g_timeout_add (10000, exit_on_inactivity, NULL);16:03
pittiah right16:03
pittidesrt: http://paste.ubuntu.com/6400417/16:04
pitti(with cleanup)16:04
desrtlooks good16:04
pittiactualy, "before we can send16:04
pittithe reply."16:04
pittiisn't true any more after your patch16:04
desrtlooks good to me.  please push.16:05
pittidesrt: thanks!16:05
desrtassuming you didn't miss any 'return;'s in that function :)16:05
pittidesrt: yes, I searched :16:05
desrtthis was a very silly bug16:06
pittidesrt: I'll look into the suspend-during-shutdown bug now16:06
desrti'm surprised it existed for so long.  i should have known better.16:06
desrtpitti: that one is already fixed16:06
desrtpitti: seb128 just didn't get around to packaging the fix yet16:07
pittidesrt: so we already disable suspend if in_shutdown is true?16:08
desrtpitti: yes.16:08
pittiah, I see it now16:08
desrtthe problem with the code in ubuntu today is that we disabled suspend using a global variable16:08
pittidesrt: ok, verifying and then let's do a 4 release16:08
desrtand if the inactivity timer hit during long shutdowns then systemd-shim would exit and when reactivated, that variable would be back to its default value and suspend would be allowed again16:09
pittidesrt: right, I see src/power-unit.c:64 now which would do the trick (and understand that patch to fix it)16:09
desrt(this inactivity timeout thing sure does seem to be causing us a lot of annoying difficulties.....)16:10
desrti wonder how much memory systemd-shim uses by running anyway...16:10
desrtif we get any more bugs about inactivity timeout then maybe we should just let it run forever :p16:10
pittiVmRSS:    2492 kB16:11
desrtthat includes libraries...16:11
desrtwritable is more interesting but it doesn't tell the whole story either16:11
pittioh, does it?16:11
pittiVmData:  147708 kB16:11
pittinot very useful16:11
desrtmaybe vmrss doesn't include libraries after all?16:12
desrt~2.5MB looks largely consistent with the size of glib+gio... but what of libc?16:12
pittithat's just residential memory AFAIK, I thought VmLib would include the libs16:12
desrtmaybe they tweak it these days16:12
pittianyway, need to AFK for a bit for testing the other fix16:12
desrtk.  thanks for dealing with this.16:13
seb128desrt, pitti: once you are done debugging systemd stuff, can I convince one of you to look at gnome-keyring 3.10 build hanging the buildds? ;-) (seems to be gnome-keyring-daemon not exiting when dbus activated, the test suite let on of those behind and the buildds wait for ever for the process to exit)16:28
seb128well "not exiting", "not exiting when the bus it's using is going away" (which happens after the tests)16:29
pittiseb128, desrt: I still get suspend during shutdown on lid close even with latest trunk16:31
desrtpitti: >:|16:32
pittiand everything happens within 10 s, so it's not the timeout issue16:32
desrtpitti: that's simply not possible16:32
desrttry again :)16:32
pittithe issue that desrt's patch fixes is certainly real as well, though16:32
seb128I'm not really surprised because the "press shutdown -> close lid" time is usually under the 10s for me16:32
pittiI wonder if it shuts down through some API other than logind16:32
desrtpitti: maybe some other component in the system is issuing the suspend/shutdown commands?16:32
desrtya.  exactly.16:32
desrtbecause reading the code, it's very very simple, and what you are describing is impossible16:32
pittishutdown with just the laptop is almost instant, but it always takes some 15 s for me while it's docked16:33
pittidesrt: yes, I know; and yet it happens16:33
desrtpitti: it's because someone is shutting (or suspending) via something other than the shim16:33
pittiI don't have consolekit installed, so it's not that16:33
pittidoesn't do shutdown16:33
=== gatox is now known as gatox_lunch
* pitti wonders if we still have some suid/polkit helper in gnome-session16:34
seb128pitti, weird, iirc the syslog logs suggested that shutdown was happening through systemd here16:34
pittidesrt: the suspend on lid close during shutdown is logind's internal behaviour16:34
pittiat that time there's no session running any more16:35
desrtright... but it asks systemd to do the work16:35
pittiI'll try a few more times, with G_DBUS logging16:37
ricotzSweetsha1k, oh, i didnt copy them to 4-116:47
pittidesrt: followed up to bug 1211514 with a log16:47
ubot2Launchpad bug 1211514 in systemd-shim (Ubuntu Trusty) "Shutdowns fail to finish if laptop lid is closed before completely shutdown" [High,Triaged] https://launchpad.net/bugs/121151416:47
pittidesrt: anyway, running out of time for today; could we do a 4 release so that I can start the SRU, and I continue on this tomorrow?16:49
desrtpitti: sure.  i'm fairly certain that this problem is not inside of systemd-shim16:49
pittidesrt: I guess that's not more than NEWS, tag, distcheck?16:49
pittidesrt: yes, need to look at what the indicator does, etc.16:49
desrtunless it's one of those "we're not returning the correct version code so someone takes a fallback path" sort of things16:49
pittidesrt: I don't see any shutdown.target etc. in the log16:49
desrtpitti: i'll do the release today16:49
pittidesrt: ok, thanks; I'll package it tomorrow then, and do the SRU16:50
desrtpitti: enjoy your evening.  thanks for the patch!16:50
seb128desrt, pitti: thanks ;-)16:50
pittiand you, good night!16:50
seb128pitti, night!16:51
* desrt tries hard not to say anything on #systems16:51
seb128desrt, ;-)16:51
larsudesrt: ;) thanks anyway16:51
=== gatox_lunch is now known as gatox
Sweetsha1kricotz: heh, that was easy to fix then ;)17:40
=== alan_g is now known as alan_g|EOD
=== dpm is now known as dpm-afk
mfischfor an experiment is there a good way to disable bamfdaemon?18:14
mfischnm, I found the dbus service file, I'll disable that18:18
=== slomo_ is now known as slomo
desrtpitti: systemd-shim is 'released'20:37
mfischrobert_ancell: ping21:10
robert_ancellmfisch, hello21:10
mfischrobert_ancell: hey, we have a thin client demo (of all things!) and shutdown/restart is not working from the greeter21:11
mfischrobert_ancell: I'm out of ideas to debug. From what I can tell its trying to use the libpower.so from gnome-settings-daemon?21:11
robert_ancellmfisch, what does 'loginctl list-sessions' say?21:12
mfischlet me fire up my other VM21:12
robert_ancellmfisch, it's just contacting logind via dbus to do shutdown/restart21:12
robert_ancellyou contact upower for suspend/restart (yes, it's confusing with the split between the two services)21:13
robert_ancellmfisch, ultimately it's up to logind to decide if there's anything blocking shutdown, and then it checks policykit policy21:13
mfischdoes it log anywhere?21:13
robert_ancellmfisch, not that I know of21:14
mfischI dont seem to have loginctl installed21:14
robert_ancellmfisch, ps aux | grep logind?21:14
mfischthis is in precise if that matters21:14
robert_ancellmfisch, ah, then it's console kit doing it there21:14
robert_ancellso check ck-list-sessions21:15
mfischokay I see lightdm and my console session21:15
mfischlet me kill my console session and install openssh-server21:15
robert_ancellso the console session will stop the greeter from being shutdown21:15
mfischyeah I figured21:15
mfischbut not ssh?21:15
robert_ancellbecause the greeter is not running a policy kit agent to prompt for the admin password21:16
robert_ancellssh will also block shutdown21:16
mfischI see lightdm is listed as ACTIVE: false so that shouldn't block21:16
mfischand it worked21:16
robert_ancellmfisch, it will, because it's still open21:16
robert_ancellactive just means "in focus"21:16
mfischokay so I closed my console session and it works.21:16
mfischI always have a console open to work on this21:16
mfischI wonder if the guest sessions I'm using are not being cleaned up in some cases, I'll check that too21:17
robert_ancellmfisch, if you want to modify this edit /usr/share/polkit-1/actions/org.freedesktop.consolekit.policy21:18
robert_ancellchange the "auth_admin_keep" to "yes" in "org.freedesktop.consolekit.system.stop-multiple-users" and "org.freedesktop.consolekit.system.restart-multiple-users"21:18
robert_ancellor something like that21:18
mfischthat will let it work no matter what21:18
mfischits working now and so I suspect it was my console21:18
mfischalthough the guy who reported it should not have been using a console21:19
robert_ancellyeah, I'm trying to fix that now for trusty21:19
mfischokay I see the setting, so I can override this if needed too21:20
mfischthanks robert_ancell21:25
ochosirobert_ancell: hi23:28
robert_ancellochosi, hello23:28
ochosiyou might've read it anyway, but we release light-locker 1.1.0 yesterday/today23:28
ochosiand i have a question wrt a new feature we implemented23:28
ochosi(time-based locking, works with X11's screensaver extension)23:29
ochosiafter the screen blanks, the user gets redirected to the greeter23:29
ochosiso the screen wakes up again23:29
ochosii'm currently considering to make the greeter force the screensaver to keep the screen blank if the is_locker option is set23:30
ochosido you think this is a good/adviseable route to go?23:30
ochosiwhat i want is to 1) reduce the flickering when locking the screen (stupid VTs!) and 2) make light-locker function as a screensaver-replacement23:30
ochosi(without adding an actual screensaver)23:31
ochosiand as i heard some folks in ubuntu are considering light-locker too, i thought this might be an interesting issue for you too (despite all the phone-focussedness)23:33
ochosirobert_ancell: anyway, let me know if you still get a chance to reply, i'll read the backlog ^23:41
robert_ancellochosi, sorry, I didn't see you'd continued there23:41
ochosino worries, it was intended as a kinda ping ;)23:42
robert_ancellochosi, yeah, I think blanking the screen on the greeter when locking probably makes sense. That should match what the session does23:46
ochosirobert_ancell: ok, good to know! any plans on how to reduce the flickering on VT switches?23:47
ochosior: any other plans23:47
robert_ancellochosi, there is a plan for the session (greeter in this case) to be able to notify lightdm when it's ready which should mean when the VT switch is performed the greeter is already drawn correctly23:49
robert_ancellother than that it's up to the drivers to switch correctly23:49
ochosirobert_ancell: ok, that sounds nice!23:49
ochosirobert_ancell: thanks for the answer and the heads up23:51
robert_ancellno problem, thanks for the light-locker work!23:51
ochosirobert_ancell: well, i hate xscreensaver and gnome-screensaver is getting too tightly integrated lately, so it's my own itch i'm scratching ;)23:52
ochosi(don't get me wrong, i love how safe xscreensaver is, but i hate how it looks)23:52
ochosialso kinda looking forward to seeing what direction ubuntu will take on the locking23:53
robert_ancellochosi, we're really waiting for the Mir stuff to hit desktop, then we can more reliably switch to the greeter instead of using VTs23:55
robert_ancellI know the Unity 7 team were looking at putting the lock into the shell, since it's easier to grab input there23:55
ochosirobert_ancell: that makes sense. i guess in that case you don't need another locker (cause light-locker is mainly there to tackle the VT-issue)23:56
robert_ancellochosi, yeah. They're running light-locker now and it works great though!23:56
ochosirobert_ancell: oh, well, other than the fallback-session, right? that would still have to do vt-switching23:56
ochosicool! that's very nice to hear23:56
robert_ancellochosi, yeah, things like fallback are a pain. I'm not sure if we can cover all the cases before Mir hits the desktop23:57
robert_ancellochosi, it's annoying because for most people the experience is much better, but for the edge cases it can be worse23:57
ochosirobert_ancell: well making light-locker a dependency of XMir shouldn't be too hard ;)23:58
ochosiyeah, true that23:58
ochosihaving an nvidia card, i'm part of the edge cases group...23:58
ochosi(only tried XMir though)23:58
robert_ancellyes, nvidia is a big one23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!