[20:53] <kklimonda> hey, any idea why are my gnome-settings-daemon and dconf-service using all the cpu?
[20:54] <kklimonda> both have ~/.config/dconf/user opened and seem to be fighting over it..
[22:05] <RAOF> desrt: I'm awake now (nominally)
[22:05] <RAOF> Stupid bloody heat.
[22:05] <desrt> RAOF: dude.  it's february
[22:06] <desrt> how hot can it be?!
[22:06]  * desrt may or may not be intentionally oblivious
[22:06] <RAOF> It was 39 on Saturday and 37 yesterday, and this house only has a day's worth of thermal mass.
[22:06] <desrt> no AC?
[22:06] <RAOF> Dude, no.
[22:06] <desrt> ow.
[22:06] <desrt> ya... that's pretty bad.
[22:07] <desrt> what latitude is taz?
[22:07] <RAOF> 42°
[22:07]  * desrt would figure it's cool by being close to antarctica or something
[22:07] <ajmitch> RAOF: move to NZ, you won't have that problem
[22:07] <desrt> eh... same as toronto, more or less
[22:07] <RAOF> These are outliers.
[22:07] <desrt> we get weather like that in the summer
[22:07] <desrt> but everyone here as AC to deal with it
[22:07] <RAOF> I'm surprised.
[22:08] <RAOF> We get like one day or less a year at that temperature.
[22:08] <RAOF> On average, clearly :)
[22:08] <desrt> ya... 40 is nothing usual here
[22:08] <desrt> but you expect to see it once or twice
[22:08] <RAOF> What, really?  Urgh.
[22:08] <RAOF> Oh.
[22:09] <RAOF> Bah, missing negation.
[22:09] <desrt> :)
[22:09] <desrt> anyway... wanted to ask about another X issue
[22:09] <desrt> you a hendrix fan?
[22:09] <RAOF> Ish.
[22:10] <desrt> so my laptop sometimes gets what i can only describe as a purple haze
[22:10] <RAOF> As in, the screen gets a purple tint?
[22:10] <desrt> it usually happens when i undock while suspended (although i think i've seen it when i'm not suspended as well)
[22:11] <desrt> the resolution on the panel is exactly half (or double, depending on your perspective) of what it should be (ie: i see the left half of the content of screen, stretched across the entire screen)
[22:11] <desrt> and there is this purple haze effect
[22:11] <desrt> maybe 'snow' is a better word for it, actually
[22:12] <RAOF> Ah, ok.
[22:12] <RAOF> Something's got confused.
[22:12] <desrt> have you heard of this at all or should i try to get it to happen so you can gather some info?
[22:13] <RAOF> I've not heard of this, but there are plausible guesses; what are the resolutions of your internal & external monitor?  This is intel?
[22:13] <desrt> it's intel on a t420
[22:13] <desrt> just about as stock as you can get
[22:14] <desrt> http://fpaste.org/Dwd4/
[22:15] <desrt> (i have two 24" screens connected to the dock)
[22:15] <robert_ancell> desrt, hey, why you hate the fork so much?
[22:16] <desrt> robert_ancell: don't get me started...
[22:16] <desrt> FORK YOU!!!
[22:16] <RAOF> desrt: Oh, wow.  Triple head!
[22:16] <desrt> robert_ancell: fork() is truly insane...
[22:16] <desrt> RAOF: not quite.
[22:16] <desrt> RAOF: the chip only has two crtcs
[22:17] <desrt> so i dock it with the lid down
[22:17]  * RAOF knew he should have lobbied jasoncwarner_ for funding for another monitor :)
[22:17] <robert_ancell> desrt, is the only issue regarding glib the fact I can't create a new dbus connection (I was trying to do that) and it's not safe to return to the main loop (not going to do that)
[22:17] <desrt> robert_ancell: well, the entire functioning of gdbus is predicated on a worker thread
[22:17] <desrt> robert_ancell: and threads don't follow you across fork()
[22:17] <desrt> well... one of them does... the one that's calling fork()
[22:17] <desrt> the others don't
[22:17] <robert_ancell> desrt, is that owned by the GDBusConnection?
[22:18] <desrt> no. shared.
[22:18] <robert_ancell> couldn't that be changed?
[22:18] <RAOF> desrt: Yeah, but you've got 3 connected devices.  Which is an uncommon case, so it's entirely possible that you're hitting a problem there.
[22:18] <desrt> ya.  david has often mused about changing it
[22:18] <desrt> but there's quite a lot of other problems as well
[22:18] <desrt> 'not returning to gmaincontext' is impractical because that's how gdbus functions internally
[22:19] <desrt> ie: it uses gmaincontext to communicate between its worker thread and your thread
[22:19] <desrt> RAOF: very possible.
[22:19] <robert_ancell> desrt, but if you did synchronous calls it would be fine right?
[22:19] <desrt> robert_ancell: no.  synchronous calls are implemented by creating a private main context and doing an async call
[22:19] <desrt> and waiting for the result to be delivered
[22:20] <robert_ancell> desrt, yeah, so isn't that safe then?
[22:20] <desrt> robert_ancell: there is very very little that is safe to do after fork()
[22:20] <desrt> like __really__ not very much
[22:20] <desrt> practically only the things that are safe to do in unix signal handlers
[22:21] <desrt> the reason for that is because another thread could be in the middle of a printf() and therefore holding the libc's stdio lock
[22:21] <desrt> you're really very much in a bad place when you start mixing threads and fork()
[22:22] <robert_ancell> hmm
[22:22] <desrt> (to be more clear: the process memory gets copied with the lock held... it gets unlocked in the original copy of the process, but the new copy lacks the running thread to unlock it, so it is locked forever)
[22:23] <desrt> what are you trying to do?
[22:23] <robert_ancell> desrt, making the PAM code in lightdm run in a separate process
[22:23] <robert_ancell> if you make it a separate program I have to copy a lot of state over which gets messy
[22:23] <desrt> is this so that you can run multiple concurrent pam conversations?
[22:24] <desrt> pam really really really needs to be killed....
[22:24] <robert_ancell> desrt, yes, but also so I can handle crashing PAM code (it happens) and PAM modules can call setenv (which they do)
[22:24] <desrt> everyone uses it because everyone uses it
[22:24] <desrt> robert_ancell: be bold!  be the change you want to see in the world!  occupy authentication!
[22:25] <robert_ancell> desrt, it's not too bad, but it does force you to use fork
[22:25] <robert_ancell> I was avoiding it in lightdm, but it's too ingrained
[22:26] <desrt> so you want to fork and interact with PAM
[22:26] <desrt> and communicate the results back using dbus?
[22:27] <robert_ancell> desrt, I need to open a CK session, and the best place to do it is when I open/close the PAM session (i.e. in the child process)
[22:27] <robert_ancell> which will be obsolete once CK dies :)
[22:27] <desrt> robert_ancell: can whatever you're doing wait until after the LTS?
[22:27] <kklimonda> ah, good we are switching to systemd - no more problems with CK.. oh, wait ;)
[22:27] <desrt> ya.... that's what i'm getting at :)
[22:27] <robert_ancell> desrt, not really, it breaks some corporate use cases currently
[22:28] <robert_ancell> kklimonda, not for 12.04 at least
[22:28]  * desrt seems to recall mark saying during a keynote in orlando that we would not focus on the authentication needs of corporate users
[22:28] <desrt> (specifically -- he used that as an example)
[22:28] <kklimonda> desrt: bah, he did say that? :/
[22:29] <robert_ancell> it still needs fixing though
[22:30] <robert_ancell> desrt, but from what your saying I have to do an exec anyway as printf could deadlock?
[22:30] <desrt> yes.
[22:30] <robert_ancell> yuck
[22:30] <desrt> man 7 signal has a list of 'safe' functions
[22:30] <desrt> exec is among them...
[22:32] <RAOF> Along with basically nothing else that you'd like to use :)
[22:41] <robert_ancell> RAOF, desrt, are you planning on flying into SFO or OAK for UDS?
[22:42] <desrt> SFO looked cheaper when i checked
[22:42] <RAOF> robert_ancell: SFO for me.
[22:42] <desrt> the BART goes to oakland, i think?
[22:42] <robert_ancell> cool, I assume you can just get a train from SFO to oakland?
[22:42] <desrt> BART = bay area rapid transit
[22:43] <robert_ancell> yup
[22:44] <desrt> hum
[23:14] <Sweetshark>  desrt: FORK YOU? nonono! FORK YEAH: http://www.youtube.com/watch?v=-zRN7XLCRhc (esp. minutes 33-40) ...