[20:37:45]  halfline: you looked at the CK signal order patches right? [20:38:04]  mccann: yup, briefly [20:38:18]  i didn't try them [20:38:23]  but lenny said he tried them [20:38:32]  and they look plausible [20:38:33]  the dump signal strikes me as really gross. [20:38:46]  yea i didn't like that much either [20:38:48]  was there a reason why my suggested fix wouldn't work? [20:39:03]  * halfline didn't see your suggested fix [20:39:06]  let me look at the bug [20:39:08]  or maybe that was a bit too gobjecty for lenny [20:39:15]  comment 0 [20:39:34]  oh the needs-dump property? [20:39:40]  * halfline still looking for the bug number [20:39:47]  i was hoping we could also avoid unnecessary dumps that way [20:39:57]  https://bugs.freedesktop.org/show_bug.cgi?id=22112 [20:40:50]  yea your way sounds good to [20:40:59]  could be that lennart doesn't know about notify signal [20:41:03]  mccann: deine mudda! [20:41:10]  it's lennART [20:41:12]  mezcalero: do you know about notify? [20:41:21]  halfline: i do [20:41:30]  be right back dinner is bubbling over stove [20:41:39]  mccann: as i understood your comment this would have helped to delay the dumps until later [20:41:48]  but what is necessary here is to move them earlier [20:41:54]  that's formal! [20:42:22]  Herr Lennart, please! [20:42:45]  muahahaahah! [20:43:35]  no it wouldn't be later [20:43:50]  a property notify is a signal [20:43:58]  then i don't get it [20:44:09]  but how would that suppress anything? [20:44:49]  there are two different things we can do here [20:44:59]  lemme check [20:45:21]  (the first patch of the two i posted is ok, isn't it?) [20:45:58]  well we may want to do something similar there [20:46:34]  one reason why i think a needs-dump property is interesting is we don't want to separately handle every property change that needs syncing to disk [20:47:01]  another is that it has a clear contract [20:47:19]  it isn't confused with properties and bus signal emission [20:47:43]  another is that we can change the property at any time [20:47:56]  more or less [20:48:08]  i think it wuld be of great benefit getting rid of the redundant signals here [20:48:13]  and we can use the property to skip dumps that don't have changes [20:48:26]  mezcalero: what is redundant? [20:48:29]  the stuff that the seat and the session send out signals when the session changes is just bad and racy [20:48:41]  explain [20:48:51]  to make things race free there should only be a single signal when the session is switched [20:49:00]  i.e. a bit like D-Bus' NameOwnerChanged [20:49:28]  which takes to args: old session, new session; wher one of them may be NULL [20:50:07]  right now session changes are artificially forwarded to the bus in two signals [20:50:21]  with some time in between where apparently no session is active [20:50:26]  which is of course not true [20:50:57]  i.e. you get the session becomes inactive, and a seperate session becomes active signal [20:51:02]  and that's bad [20:51:27]  there is only one active session changed signal from the seat [20:52:00]  which is completely redundant [20:52:14]  not redundant - it is authoritative [20:52:31]  that's the only one you need [20:52:35]  hmm, why do we need three signals when we swicth a session? [20:53:11]  the fact that you have three of those also causes the current logic to update the db three times on each session switch [20:53:33]  i can't remember why the signal doesn't have "was" "is" arguments but that would be ok too.  I think it  only has "is-now" atm [20:54:46]  the signals are there only because dbus glib didn't do properties btw.  that's not a super reason but that's why [20:55:18]  hmm, yes, i expected that to be the resaon already ;-) [20:55:31]  still it's useful if you only care about one session to only listen to that session signal [20:55:41]  instead of listening to every vt change [20:55:46]  but it should have been a property [20:55:48]  but yeah [20:56:09]  it wouldn't make sense to listen to two session signals to try to catch teh transition between them [20:56:13]  that's what the seat signal is for [20:56:14]  halfline: bu that's an optimization that comes at the price of signals sent to the bus daemon [20:56:33]  true [20:56:36]  halfline: i mean, if you want to optimize signals, you shouldn't sent them out in the first place [20:57:27]  will davidz's new gobject dbus stuff allow more flexible handling of signals in this area? [20:57:33]  presumably with the egg dbus stuff you subscribe to property changes or something [20:57:51]  dunno [20:58:26]  there shouldn't be races here any more than dbus signals are already anyway [20:58:40]  you don't have to match signals from different objects [20:58:56]  but if we are hitting disk more than we should that's a bug [20:59:30]  and I was thinking that the needs-dump property would help with that [20:59:41]  if it doesn't need a dump it doesn't do one [21:00:17]  hmm, with the old hal code we do have this ugly thing that acls are first removed from a device and then added to it in two steps on each session switch, which causes a drop out in audio. i eally wonder how much of that is actually rooted in ck, or if that was simply a hal fuckup [21:05:56]  hmm [21:07:04]  so really the callouts should be run from the seat [21:07:04]  * mezcalero wished he had a kernel where mutexes worked [21:07:16]  that seems to be the problem [21:07:34]  david added them.  I'm not sure why they are on the session. [21:07:49]  devices are attributes of the seat not the session [21:08:48]  mezcalero: that's part of your problem, right? [21:09:24]  could be [21:09:41]  yes, i guess it makes sense to move them to the seat [21:11:12]  of course if you move it to the seat, some of the environment variables will need to get changed [21:11:25]  yeah it is designed around the session now it seems [21:11:36]  getting this changed in udev should be easy [21:11:53]  especially since kay is hanging around in your office one of these days, right? [21:11:56]  too bad we didn't discuss with david and kay today in the office [21:12:35]  oh he was in today? [21:12:42]  yes [21:12:44]  shoot, i knew he was coming in sometime this week [21:12:44]  but not tomorrow [21:13:15]  ah well. instead i got the privilege of shelling out $620 bucks on my car [21:13:29]  so right now we're running the session callout twice.  once for the newly inactive once for the newly active [21:13:37]  just slightly less than 1/3 of what i paid for the car [21:13:48]  mezcalero: that's what you see right? [21:14:24]  instead we should run it once per transition with environment variable for the active session and the previously active session [21:14:31]  http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/udev-acl/udev-acl.c;h=3eb29fe2f28951bb5ba91f527dcbd0d9472b1537;hb=HEAD#l154 [21:14:38]  I guess if we don't want to break things we can just add a seat callout [21:14:39]  that's what udev-acl makes of those callouts [21:15:14]  mccann: break?  nobody's using udev-acl yet [21:15:19]  you won't break anything [21:15:31]  at least nothing we couldn't fix without a small patch to udev-acl [21:15:34]  some people are using the callouts already I think [21:15:43]  for pam console replacements [21:16:05]  but even for those a seat callout is better [21:16:14]  ***  xkahn (~xkahn@pool-71-174-240-233.bstnma.fios.verizon.net) has joined chat #fedora-desktop. [21:16:24]  anyway, I should check with david to see what his reasoning was for putting them there [21:16:46]  calling it run-seats.d though wouldn't make sense [21:16:59]  it would be very nice that if you switch from one session of a user to another session of the same user we wouldn't have top drop and readd acls [21:17:15]  as mentioned this causes dropouts in audio, which sucks [21:17:19]  would certainly make twoerner happy [21:17:30]  mezcalero: if you have one callout then you can handle that [21:17:36]  halfline: why wouldn't that name make sense? [21:17:49]  i am all for coalescing callouts and signals [21:18:18]  mccann: if run-sessions.d is called when a session becomes active or inactive [21:18:25]  mccann: probably one of the reasons he put them there was that HAL was working that way [21:18:31]  then you'd expect run-seats.d to get called when a seat is added or removed i think [21:18:54]  oh I see [21:19:22]  halfline: actually there are different ways it can be called [21:19:59]  different actions [21:20:02]  oh i see there's an action arg [21:20:31]  so i think it is fine [21:20:54]  right, keep session_active_changed on run-seats.d [21:20:57]  for this case [21:21:00]  but i'll check with david tomorrow if he is around [21:21:11]  since I may be missing something [21:21:14]  and then add a seat_removed or something later if necessary [21:21:16]  but I think this is right [21:22:50]  "There are 1298 updates available" [21:23:01]  f13: busy tagging the world ? [21:23:15]  yes indeed. [21:23:19]  mass rebuilds will do that [21:23:30]  well, I thought I had most of it installed already [21:23:38]  by means of running off the koji repo [21:23:41]  it didn't get tagged until this morning [21:23:45]  but it seems I get them all again [21:23:57]  sorry shutdown I mean [21:24:10]  there's a feature page [21:24:16]  and I sent a mail to gdm-list at one point [21:24:38]  http://www.fedoraproject.org/wiki/Features/ConsoleKitInhibitAPI [21:24:50]  right.  now that things are heating up in gtk session management land.  probably makes sense to post that upstream someplace [21:25:05]  oh, dang, almost 3:30 am, /me needs to go to bed [21:29:04]  mezcalero: ok well you got some review tonight as promised but the rest has to wait for tomorrow i'm afraid [21:29:34]  would be good if we could get that fixed before the alpha [21:29:34]  once we do the right thing with the callouts fixing the dumping should be easy [21:29:47]  the wrong order of the db dump really fucks up the acls from time to time [21:30:36]