| === 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 | ||
| Laney | hey ho | 09:02 |
|---|---|---|
| pitti | hey Laney, had a good we? | 09:11 |
| Laney | hey pitti, was nice thanks | 09:12 |
| Laney | made beer & wine & mead, all fermenting away now | 09:12 |
| Laney | you? | 09:12 |
| pitti | yummy | 09:12 |
| pitti | we had some friends visiting, and spent much time walking, talking, playing badminton and Wizard :) | 09:13 |
| larsu | morning guys | 09:13 |
| * Laney googles wizard | 09:13 | |
| pitti | hey larsu, how are you? | 09:14 |
| Laney | hey larsu, how goes? | 09:14 |
| Laney | ha | 09:14 |
| larsu | haha | 09:14 |
| pitti | Laney: http://en.wikipedia.org/wiki/Wizard_%28card_game%29 | 09:14 |
| larsu | pitti, Laney: good, thanks! And you? | 09:14 |
| * larsu feels efficient | 09:14 | |
| pitti | larsu: very well, thanks | 09:14 |
| Laney | remembering that I left before the weekend having made a patch which crashes AS | 09:15 |
| Laney | and not wanting to look at it any more :P | 09:15 |
| larsu | is that why I had problems logging in this morning? | 09:15 |
| Laney | no sir | 09:15 |
| Laney | it didn't leave my computer yet | 09:15 |
| larsu | hm, must've been something else then | 09:16 |
| larsu | it worked after upgrading from a vt | 09:16 |
| Laney | eww | 09:16 |
| Laney | check lightdm / upstart logs | 09:16 |
| larsu | "Failed during authentication" | 09:17 |
| larsu | that's all lightdm had to say about that | 09:18 |
| larsu | in a debug message, no less | 09:18 |
| Laney | tseliot: hey, could you push screen-resolution-extra to bzr please? | 09:43 |
| tseliot | Laney: I maintain it in git | 09:44 |
| tseliot | Laney: I thought I had pushed it though. I can do that if you want | 09:45 |
| Laney | Please fix Vcs-Bzr then | 09:45 |
| tseliot | Laney: let me check | 09:45 |
| tseliot | Laney: done | 10:02 |
| tseliot | Laney: and thanks for making me notice ;) | 10:02 |
| Laney | tseliot: thanks to you! | 10:03 |
| Laney | What I was going to do is to put the change I uploaded over the weekend into bzr | 10:03 |
| tseliot | Laney: oh, what change is it? | 10:03 |
| Laney | I guess I can't push to the git repository, so if you could do that | 10:03 |
| Laney | https://launchpadlibrarian.net/156207976/screen-resolution-extra_0.16_0.16ubuntu1.diff.gz | 10:04 |
| tseliot | Laney: oh, no wonder my upload was rejected. Let me fix that | 10:04 |
| Laney | :-) | 10:04 |
| Laney | I tried to push it back but found that bzr was out of date | 10:05 |
| Laney | and then here we are | 10:05 |
| tseliot | oh, I see | 10:05 |
| tseliot | Laney: it should all be fixed now. Thanks again | 10:16 |
| Laney | cool, cheers | 10: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 | ||
| pitti | desrt: hey Ryan, how are you? enjoyed your holidays? | 14:28 |
| desrt | what holidays? :) | 14:29 |
| === greyback|lunch is now known as greyback | ||
| pitti | desrt: I thought you took some days off after the sprint? | 14:32 |
| desrt | ah. just a couple of swap days | 14:32 |
| desrt | one for travel and one for a missed holiday | 14:32 |
| === synaptix is now known as thecowmoos | ||
| pitti | desrt: not sure whether you saw the recent updates on bug 1184262 | 14:32 |
| ubot2 | Launchpad 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/1184262 | 14:32 |
| desrt | didn't see it | 14:33 |
| pitti | desrt: we need to find out how to change the timeout in -shim to not apply during method calls | 14:33 |
| pitti | desrt: as soon as a suspend/resume takes longer than 10s, the GTimeout hits, and the PrepareForSleep False signal is never sent | 14:33 |
| === thecowmoos is now known as synaptix | ||
| pitti | desrt: I put an experimental version into my PPA which bumps it to 10mins, which helps for most people | 14:33 |
| pitti | but not for longer sleep cycles | 14:33 |
| desrt | pitti: did you want to take over systemd-shim maintainership? ;) | 14:34 |
| pitti | desrt: because of the PPA version? that was mostly to understand/confirm what the problem is | 14: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 | |
| larsu | lol. "I have this problem with your software. Can you help me fix it?" -- "Do you want to instead maintain the software forever?" | 14:36 |
| larsu | hi desrt! ;) | 14:36 |
| Laney | haha | 14:36 |
| Laney | patches welcome-ng | 14:36 |
| larsu | :D | 14:36 |
| pitti | desrt: if you want to give me commit rights, I wouldn't mind | 14:37 |
| desrt | pitti: this is absolutely what i want :) | 14:37 |
| desrt | pitti: also: you could just fork the project and host it elsewhere | 14:37 |
| pitti | desrt: as for that actual bug, can you "suspend" a GTimeout source somehow? | 14:38 |
| desrt | pitti: so that it follows real time instead of monotonic time? | 14:38 |
| pitti | desrt: or should shim_method_call() just delete the source at the beginning, and re-create it at the end? | 14:38 |
| desrt | ah ya. there is no way to reset it, if that's what you mean | 14:38 |
| desrt | other than destroy/create | 14:38 |
| pitti | we need to replace the returns with some "goto out", but *shrug* | 14:38 |
| pitti | desrt: destroy/creat seems safest indeed | 14:39 |
| pitti | desrt: ok, I'll look into that | 14:39 |
| pitti | desrt: where is the upstream git? | 14:39 |
| desrt | github/desrt/systemd-shim | 14:39 |
| desrt | which is why i thought that maybe you like to fork it | 14:39 |
| desrt | i'm happy to add your git account as a committer in any case | 14:40 |
| desrt | (if you have one on github) | 14:40 |
| pitti | yeah, better to have one trunk IMHO | 14:40 |
| desrt | i'd probably take mine offline if you forked it :p | 14:40 |
| pitti | desrt: c'est moi: https://github.com/martinpitt | 14:40 |
| desrt | k. you're "collaborator" on the project now | 14:42 |
| desrt | which i think means that you can push | 14:42 |
| pitti | desrt: ack, thanks | 14:42 |
| desrt | pitti: 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 |
| dpm | hi seb128, how are you? | 15:29 |
| Sweetsha1k | Heya 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 | |
| seb128 | dpm, 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 |
| dpm | seb128, it can wait until tomorrow, enjoy your day off! | 15:32 |
| pitti | desrt: I added a reproducer to the bug, I now get the issue myself; WDYT about http://paste.ubuntu.com/6400271/ ? | 15:33 |
| pitti | desrt: that fixes it for me | 15:33 |
| seb128 | dpm, 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 |
| dpm | hahaha | 15:34 |
| desrt | pitti: oh. this. | 15:35 |
| desrt | pitti: so i already had a weaker form of this... | 15:35 |
| pitti | desrt: yes, disabling the timeout after shutdown | 15:35 |
| desrt | pitti: did you see that the poweroff job permanently disabled the inactivity timeout? your patch will probably have a weird interaction there. | 15:35 |
| dpm | seb128, 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/display | 15:36 |
| pitti | desrt: that flag is checked in exit_on_inactivity(), not in activity_timeout() | 15:36 |
| pitti | desrt: so while I could check in_shutdown in activity_timeout() as well, we shouldn't really have to? | 15:36 |
| desrt | pitti: evil :) | 15:36 |
| desrt | i was lazy.... | 15:36 |
| pitti | desrt: but poweroff isn't one long method call | 15:36 |
| pitti | while calling pm-suspend seems to be | 15:36 |
| seb128 | dpm, done | 15:37 |
| desrt | pitti: i have a greater understanding of the problem after seeing this patch now. thanks :) | 15:37 |
| dpm | awesome, thanks seb128 :) | 15:37 |
| seb128 | dpm, yw | 15:37 |
| pitti | dpm: 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 |
| pitti | sorry, desrt ^ | 15:38 |
| dpm | np :) | 15:38 |
| pitti | desrt: BTW, we recently got bug 1211514, so something there is still wrong, too :/ | 15:39 |
| ubot2 | Launchpad bug 1211514 in systemd (Ubuntu) "Shutdowns fail to finish if laptop lid is closed before completely shutdown" [High,Confirmed] https://launchpad.net/bugs/1211514 | 15:39 |
| pitti | desrt: (but that sounds unrelated; we need to disable logind's suspend during shutdown) | 15:39 |
| pitti | desrt: so if that patch seems ok to you, I'd look into that bug next, and release 4 | 15:40 |
| desrt | pitti: so the patch is simple and inelegant | 15:40 |
| desrt | which fits nicely with systemd-shim's entire existence :p | 15:40 |
| pitti | lol | 15:40 |
| pitti | desrt: inelegant> agreed | 15:41 |
| desrt | the only thing i'd consider changing is upping the complexity for favour of a bit more elegance: | 15:41 |
| desrt | when we get a method invocation in, do use_count++ | 15:41 |
| desrt | then hook up a weak ref handler to do use_count-- | 15:41 |
| desrt | and don't exit when we have a positive use_count | 15:41 |
| pitti | desrt: ref handler? not just count-- on method exit? | 15:41 |
| desrt | pitti: that's where all your goto is coming from... | 15:42 |
| desrt | also: this patch is kinda bogus, actually.... | 15:42 |
| === alan_g|tea is now known as alan_g | ||
| desrt | so everything in systemd-shim is synchronous | 15:43 |
| desrt | which is why your patch works at all | 15:43 |
| desrt | but since that's the case, it means that the mainloop isn't running at all while any method is being handled | 15:43 |
| desrt | so it's impossible for a timeout to occur in the middle of a method call | 15:43 |
| pitti | yeah, 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 timeout | 15:44 |
| pitti | but demonstrably it does | 15:44 |
| desrt | what's happening is surely this: | 15:44 |
| desrt | the method call reply gets sent to the dbus worker thread | 15:44 |
| desrt | the main thread hits the timeout | 15:44 |
| desrt | and the program quits before the worker thread has a chance to send the message | 15:44 |
| pitti | yes | 15:44 |
| desrt | so we could fix this a couple of ways | 15:45 |
| pitti | we have the while(1) g_main_context_iteration in main | 15:45 |
| desrt | just move had_activity() to the bottom | 15:45 |
| desrt | (keeping your gotos) | 15:45 |
| desrt | ie: reset the timer as of when the method call stopped, not started | 15:45 |
| desrt | and/or: flush the bus before we quit | 15:45 |
| desrt | to make sure the reply gets out properly | 15:45 |
| pitti | desrt: but we still need to explicitly stop it at the top, no? | 15:45 |
| desrt | no | 15:46 |
| desrt | the mainloop isn't running anymore, so the timeout can't possibly fire | 15:46 |
| pitti | otherwise a timeout set by the previous call could hit in the middle of the next call | 15:46 |
| pitti | but it would have the same race with the main loop after return as right now? | 15:46 |
| desrt | no... because we'd always reset the timeout just before returning | 15:46 |
| Sweetsha1k | seb128: nothing urgent here, have fun celebrating that mantle slicing weirdness! | 15:46 |
| desrt | it really depends on your definition of inactivity timeout... in any case we should definitely be flushing the bus before we return | 15:47 |
| desrt | this is a full-on bug right now, no matter how you consider it | 15:47 |
| pitti | desrt: ah, I see | 15:47 |
| desrt | that 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 seconds | 15:47 |
| pitti | desrt: how do you flush the dbus? | 15:48 |
| pitti | desrt: sorry, phone, bbl | 15:48 |
| desrt | that theoretical race would "never" happen of course, because 10 seconds to send a message? seriously? | 15:48 |
| desrt | but we should still close it | 15:48 |
| desrt | pitti: i'll do a patch | 15:48 |
| desrt | the 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 sensible | 15:48 |
| pitti | re | 15:52 |
| desrt | pitti: okay. i have a patch now. | 15:52 |
| desrt | http://ur1.ca/g0kc0 | 15:53 |
| pitti | desrt: oh, I see | 15:53 |
| desrt | even with your patch we should do this one | 15:53 |
| pitti | desrt: yes, I agree | 15:53 |
| pitti | desrt: so your's to never lose the reply, and mine to avoid immediately exiting after a (long) method call | 15:53 |
| desrt | because 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 |
| desrt | pitti: we should do both | 15:54 |
| pitti | desrt: yes, as I said, I agree :) | 15:54 |
| desrt | pitti: i leave it to you to decide how you want your patch to look | 15:54 |
| seb128 | desrt, 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 though | 15:54 |
| pitti | desrt: but then with the modification to only set had_activity() at the bottom in success: | 15:54 |
| desrt | descheduling at the top is strictly pointless | 15:54 |
| desrt | because the loop isn't running | 15:54 |
| pitti | seb128: oh, I had assumed we had that already | 15:55 |
| seb128 | desrt, pitti: though it seems like you guys are doing extra fixing there, I'm just mentioning it in case it's useful | 15:55 |
| seb128 | pitti, no we don't, I was supposed to test and backport and that slipped through :/ | 15:55 |
| pitti | seb128: thanks, but that's a different bug; I was goin to look into this one, too | 15:55 |
| desrt | seb128: after these two patches it's worth a new upload for sure | 15:55 |
| desrt | probably even an SRU | 15:55 |
| seb128 | pitti, I can easily reproduce the suspend on shutdown bug, I can try the patch later | 15:56 |
| seb128 | desrt, right | 15:56 |
| pitti | seb128: yes, me too | 15:56 |
| pitti | desrt: absolutely an SRU | 15:56 |
| pitti | I can do the trusty and saucy uploads | 15:56 |
| desrt | pitti: okay. i pushed mine. should i rework yours or do you want to do it? | 15:57 |
| pitti | desrt: hang on, rebasing/redoing/testing | 15:57 |
| desrt | pitti: (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 |
| pitti | desrt: http://paste.ubuntu.com/6400402/ | 16:01 |
| desrt | pitti: did you type 'make'? | 16:01 |
| desrt | @@ -51,7 +51,10 @@ had_activity (void) | 16:01 |
| meetingology | desrt: Error: "@" is not a valid command. | 16:01 |
| desrt | + had_activity (TRUE); | 16:01 |
| pitti | desrt: no, not yet; I was going to ask "is that approach what you had in mind" | 16:02 |
| desrt | pitti: yes. that looks fine to me. | 16:03 |
| pitti | ah, forgot to fix the last call, erk | 16:03 |
| desrt | except setting the timeout to 0 is pointless | 16:03 |
| desrt | since you unconditionally reset it again just below | 16: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 |
| pitti | ah right | 16:03 |
| pitti | desrt: http://paste.ubuntu.com/6400417/ | 16:04 |
| pitti | (with cleanup) | 16:04 |
| desrt | looks good | 16:04 |
| pitti | actualy, "before we can send | 16:04 |
| pitti | the reply." | 16:04 |
| pitti | isn't true any more after your patch | 16:04 |
| desrt | true. | 16:04 |
| pitti | http://paste.ubuntu.com/6400421/ | 16:05 |
| desrt | looks good to me. please push. | 16:05 |
| pitti | done | 16:05 |
| pitti | desrt: thanks! | 16:05 |
| desrt | assuming you didn't miss any 'return;'s in that function :) | 16:05 |
| pitti | desrt: yes, I searched : | 16:05 |
| desrt | this was a very silly bug | 16:06 |
| pitti | desrt: I'll look into the suspend-during-shutdown bug now | 16:06 |
| desrt | i'm surprised it existed for so long. i should have known better. | 16:06 |
| desrt | pitti: that one is already fixed | 16:06 |
| desrt | https://github.com/desrt/systemd-shim/commit/6c65a11321fc102cacd4a9cc2189f74bb1c89ca5 | 16:06 |
| desrt | pitti: seb128 just didn't get around to packaging the fix yet | 16:07 |
| pitti | desrt: so we already disable suspend if in_shutdown is true? | 16:08 |
| desrt | pitti: yes. | 16:08 |
| pitti | ah, I see it now | 16:08 |
| desrt | the problem with the code in ubuntu today is that we disabled suspend using a global variable | 16:08 |
| pitti | desrt: ok, verifying and then let's do a 4 release | 16:08 |
| desrt | and 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 again | 16:09 |
| pitti | desrt: 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 |
| desrt | i wonder how much memory systemd-shim uses by running anyway... | 16:10 |
| desrt | if we get any more bugs about inactivity timeout then maybe we should just let it run forever :p | 16:10 |
| pitti | VmRSS: 2492 kB | 16:11 |
| desrt | that includes libraries... | 16:11 |
| desrt | writable is more interesting but it doesn't tell the whole story either | 16:11 |
| pitti | oh, does it? | 16:11 |
| pitti | VmData: 147708 kB | 16:11 |
| pitti | not very useful | 16:11 |
| desrt | ! | 16:11 |
| desrt | maybe 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 |
| pitti | that's just residential memory AFAIK, I thought VmLib would include the libs | 16:12 |
| desrt | maybe they tweak it these days | 16:12 |
| pitti | anyway, need to AFK for a bit for testing the other fix | 16:12 |
| desrt | k. thanks for dealing with this. | 16:13 |
| seb128 | desrt, 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 |
| seb128 | well "not exiting", "not exiting when the bus it's using is going away" (which happens after the tests) | 16:29 |
| pitti | seb128, desrt: I still get suspend during shutdown on lid close even with latest trunk | 16:31 |
| seb128 | :-( | 16:31 |
| desrt | pitti: >:| | 16:32 |
| pitti | and everything happens within 10 s, so it's not the timeout issue | 16:32 |
| desrt | pitti: that's simply not possible | 16:32 |
| desrt | try again :) | 16:32 |
| pitti | the issue that desrt's patch fixes is certainly real as well, though | 16:32 |
| seb128 | I'm not really surprised because the "press shutdown -> close lid" time is usually under the 10s for me | 16:32 |
| pitti | I wonder if it shuts down through some API other than logind | 16:32 |
| desrt | pitti: maybe some other component in the system is issuing the suspend/shutdown commands? | 16:32 |
| desrt | ya. exactly. | 16:32 |
| desrt | because reading the code, it's very very simple, and what you are describing is impossible | 16:32 |
| pitti | shutdown with just the laptop is almost instant, but it always takes some 15 s for me while it's docked | 16:33 |
| pitti | desrt: yes, I know; and yet it happens | 16:33 |
| desrt | pitti: it's because someone is shutting (or suspending) via something other than the shim | 16:33 |
| pitti | I don't have consolekit installed, so it's not that | 16:33 |
| desrt | pmutils!! | 16:33 |
| pitti | doesn't do shutdown | 16:33 |
| === gatox is now known as gatox_lunch | ||
| * pitti wonders if we still have some suid/polkit helper in gnome-session | 16:34 | |
| seb128 | pitti, weird, iirc the syslog logs suggested that shutdown was happening through systemd here | 16:34 |
| pitti | desrt: the suspend on lid close during shutdown is logind's internal behaviour | 16:34 |
| pitti | at that time there's no session running any more | 16:35 |
| desrt | right... but it asks systemd to do the work | 16:35 |
| pitti | I'll try a few more times, with G_DBUS logging | 16:37 |
| ricotz | Sweetsha1k, oh, i didnt copy them to 4-1 | 16:47 |
| pitti | desrt: followed up to bug 1211514 with a log | 16:47 |
| ubot2 | Launchpad 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/1211514 | 16:47 |
| pitti | desrt: 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 |
| desrt | pitti: sure. i'm fairly certain that this problem is not inside of systemd-shim | 16:49 |
| pitti | desrt: I guess that's not more than NEWS, tag, distcheck? | 16:49 |
| pitti | desrt: yes, need to look at what the indicator does, etc. | 16:49 |
| desrt | unless it's one of those "we're not returning the correct version code so someone takes a fallback path" sort of things | 16:49 |
| pitti | desrt: I don't see any shutdown.target etc. in the log | 16:49 |
| desrt | pitti: i'll do the release today | 16:49 |
| pitti | desrt: ok, thanks; I'll package it tomorrow then, and do the SRU | 16:50 |
| desrt | pitti: enjoy your evening. thanks for the patch! | 16:50 |
| seb128 | desrt, pitti: thanks ;-) | 16:50 |
| pitti | and you, good night! | 16:50 |
| seb128 | pitti, night! | 16:51 |
| * desrt tries hard not to say anything on #systems | 16:51 | |
| seb128 | desrt, ;-) | 16:51 |
| larsu | desrt: ;) thanks anyway | 16:51 |
| === gatox_lunch is now known as gatox | ||
| Sweetsha1k | ricotz: 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 | ||
| mfisch | for an experiment is there a good way to disable bamfdaemon? | 18:14 |
| mfisch | nm, I found the dbus service file, I'll disable that | 18:18 |
| === slomo_ is now known as slomo | ||
| desrt | pitti: systemd-shim is 'released' | 20:37 |
| mfisch | robert_ancell: ping | 21:10 |
| robert_ancell | mfisch, hello | 21:10 |
| mfisch | robert_ancell: hey, we have a thin client demo (of all things!) and shutdown/restart is not working from the greeter | 21:11 |
| mfisch | robert_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_ancell | mfisch, what does 'loginctl list-sessions' say? | 21:12 |
| mfisch | let me fire up my other VM | 21:12 |
| robert_ancell | mfisch, it's just contacting logind via dbus to do shutdown/restart | 21:12 |
| robert_ancell | you contact upower for suspend/restart (yes, it's confusing with the split between the two services) | 21:13 |
| robert_ancell | mfisch, ultimately it's up to logind to decide if there's anything blocking shutdown, and then it checks policykit policy | 21:13 |
| mfisch | does it log anywhere? | 21:13 |
| robert_ancell | mfisch, not that I know of | 21:14 |
| mfisch | I dont seem to have loginctl installed | 21:14 |
| robert_ancell | mfisch, ps aux | grep logind? | 21:14 |
| mfisch | this is in precise if that matters | 21:14 |
| robert_ancell | mfisch, ah, then it's console kit doing it there | 21:14 |
| robert_ancell | so check ck-list-sessions | 21:15 |
| mfisch | okay I see lightdm and my console session | 21:15 |
| mfisch | let me kill my console session and install openssh-server | 21:15 |
| robert_ancell | so the console session will stop the greeter from being shutdown | 21:15 |
| mfisch | yeah I figured | 21:15 |
| mfisch | but not ssh? | 21:15 |
| robert_ancell | because the greeter is not running a policy kit agent to prompt for the admin password | 21:16 |
| robert_ancell | ssh will also block shutdown | 21:16 |
| mfisch | I see lightdm is listed as ACTIVE: false so that shouldn't block | 21:16 |
| mfisch | and it worked | 21:16 |
| robert_ancell | mfisch, it will, because it's still open | 21:16 |
| robert_ancell | active just means "in focus" | 21:16 |
| mfisch | okay so I closed my console session and it works. | 21:16 |
| mfisch | I always have a console open to work on this | 21:16 |
| mfisch | I wonder if the guest sessions I'm using are not being cleaned up in some cases, I'll check that too | 21:17 |
| robert_ancell | mfisch, if you want to modify this edit /usr/share/polkit-1/actions/org.freedesktop.consolekit.policy | 21:18 |
| robert_ancell | change 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_ancell | or something like that | 21:18 |
| mfisch | that will let it work no matter what | 21:18 |
| mfisch | ok | 21:18 |
| robert_ancell | yes | 21:18 |
| mfisch | its working now and so I suspect it was my console | 21:18 |
| mfisch | although the guy who reported it should not have been using a console | 21:19 |
| robert_ancell | yeah, I'm trying to fix that now for trusty | 21:19 |
| mfisch | okay I see the setting, so I can override this if needed too | 21:20 |
| mfisch | thanks robert_ancell | 21:25 |
| ochosi | robert_ancell: hi | 23:28 |
| robert_ancell | ochosi, hello | 23:28 |
| ochosi | you might've read it anyway, but we release light-locker 1.1.0 yesterday/today | 23:28 |
| ochosi | and i have a question wrt a new feature we implemented | 23:28 |
| ochosi | (time-based locking, works with X11's screensaver extension) | 23:29 |
| robert_ancell | ok | 23:29 |
| ochosi | after the screen blanks, the user gets redirected to the greeter | 23:29 |
| ochosi | so the screen wakes up again | 23:29 |
| ochosi | i'm currently considering to make the greeter force the screensaver to keep the screen blank if the is_locker option is set | 23:30 |
| ochosi | do you think this is a good/adviseable route to go? | 23:30 |
| ochosi | what i want is to 1) reduce the flickering when locking the screen (stupid VTs!) and 2) make light-locker function as a screensaver-replacement | 23:30 |
| ochosi | (without adding an actual screensaver) | 23:31 |
| ochosi | and 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 |
| ochosi | robert_ancell: anyway, let me know if you still get a chance to reply, i'll read the backlog ^ | 23:41 |
| robert_ancell | ochosi, sorry, I didn't see you'd continued there | 23:41 |
| robert_ancell | reading | 23:42 |
| ochosi | no worries, it was intended as a kinda ping ;) | 23:42 |
| robert_ancell | ochosi, yeah, I think blanking the screen on the greeter when locking probably makes sense. That should match what the session does | 23:46 |
| ochosi | robert_ancell: ok, good to know! any plans on how to reduce the flickering on VT switches? | 23:47 |
| ochosi | or: any other plans | 23:47 |
| robert_ancell | ochosi, 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 correctly | 23:49 |
| robert_ancell | other than that it's up to the drivers to switch correctly | 23:49 |
| ochosi | robert_ancell: ok, that sounds nice! | 23:49 |
| ochosi | robert_ancell: thanks for the answer and the heads up | 23:51 |
| robert_ancell | no problem, thanks for the light-locker work! | 23:51 |
| ochosi | robert_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 |
| ochosi | also kinda looking forward to seeing what direction ubuntu will take on the locking | 23:53 |
| robert_ancell | ochosi, we're really waiting for the Mir stuff to hit desktop, then we can more reliably switch to the greeter instead of using VTs | 23:55 |
| robert_ancell | I know the Unity 7 team were looking at putting the lock into the shell, since it's easier to grab input there | 23:55 |
| ochosi | robert_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_ancell | ochosi, yeah. They're running light-locker now and it works great though! | 23:56 |
| ochosi | robert_ancell: oh, well, other than the fallback-session, right? that would still have to do vt-switching | 23:56 |
| ochosi | cool! that's very nice to hear | 23:56 |
| robert_ancell | ochosi, yeah, things like fallback are a pain. I'm not sure if we can cover all the cases before Mir hits the desktop | 23:57 |
| robert_ancell | ochosi, it's annoying because for most people the experience is much better, but for the edge cases it can be worse | 23:57 |
| ochosi | robert_ancell: well making light-locker a dependency of XMir shouldn't be too hard ;) | 23:58 |
| ochosi | yeah, true that | 23:58 |
| ochosi | having an nvidia card, i'm part of the edge cases group... | 23:58 |
| ochosi | (only tried XMir though) | 23:58 |
| robert_ancell | yes, nvidia is a big one | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!