[08:31] <Keybuk> last day! \o/
[14:08] <ion> keybuk: Woot, a video site you can use without flash and with your video player plugin of choice. Awesome.
[14:09] <Keybuk> I know, yet people complain that it's h.264
[14:31] <sadmac> Keybuk: nice shoes
[14:31] <Keybuk> :D
[14:31] <Keybuk> which one are you watching?
[14:33] <sadmac> Keybuk: desktop one, because that one worked for me with streaming
[14:33] <sadmac> (gstreamer on fedora seems to keep hanging. The traces lead in to pulseaudio. Imagine my surprise.)
[14:34] <Keybuk> fortunately Lennart is working full time on pulseaudio
[14:34] <Keybuk> and isn't spending all his time on anything more critical
[14:34] <ion> :-P
[14:35] <sadmac> Keybuk: The one thing I've yet to understand is how multiple instances will behave in 1.0
[14:36] <Keybuk> configs and jobs are separated, and there are rules for how jobs are created from configs
[14:36] <Keybuk> one of those rules says that for each named state in the "while" clause, a job is created
[14:37] <Keybuk> so if you have a state with two instances
[14:37] <Keybuk> then you also have two instances of everything that is running in that state
[14:37] <Keybuk> so it's recursive
[14:37] <Keybuk> (with an "any" semantic)
[14:37] <Keybuk> multi-instance states are created automatically for things like devices, files, etc.
[14:38] <sadmac> so if you have while a and b, and you have two of a and two of b, you'd get 4 of that job?
[14:38] <Keybuk> err, you would have two
[14:38] <Keybuk> sorry, misread
[14:38] <Keybuk> if there's two a, and two b
[14:38] <Keybuk> you'd get four, yes
[14:39] <Keybuk> one for a1 and b1
[14:39] <Keybuk> one for a1 and b2
[14:39] <Keybuk> one for a2 and b1
[14:39] <Keybuk> one for a2 and b2
[14:39] <Keybuk> consider "a" being users, and "b" being user sessions
[14:39] <Keybuk> or "a" being network devices, and "b" being users
[14:39] <sadmac> the first one of those is broken
[14:40] <sadmac> I have an instance of metacity for my user on my neighbor's user session?
[14:40] <Keybuk> metacity is an application, not a service
[14:40] <Keybuk> yeah I meant a/b being computers/seats
[14:40] <Keybuk> been a long week
[14:40] <sadmac> pulseaudio teh
[14:40] <sadmac> *then
[14:41] <Keybuk> right, if a is users, and pulseaudio is while a
[14:41] <Keybuk> then you get two pulses for two users
[14:41] <Keybuk> screensaver!
[14:42] <Keybuk> if a is sessions, and screensaver is while a, you get once screensaver for each
[14:42] <sadmac> errrgh. I know I can break it, hold on...
[14:44] <Keybuk> and example
[14:44] <sadmac> well there's the kludgy case of apache existing for every device in the system if it has while net-device-up
[14:44] <Keybuk> you have a type of device that needs a program to connect to each one
[14:44] <Keybuk> and you have multiple users
[14:44] <Keybuk> so you'd need one for each device for each user
[14:44] <Keybuk> thus the while/and behaviour
[14:44] <Keybuk> kludgy case => apache would use "while any network-device" type thing
[14:45] <Keybuk> so it doesn't matter how many network devices come up
[14:45] <Keybuk> (it may be that "any" is default and "each" requires stanza)
[14:45] <Keybuk> so while network-device
[14:45] <Keybuk> foreach a and foreach b
[14:45] <Keybuk> that's just arguing sugar vs. hcfs
[14:45] <barefoot> how can I fix "The script you are attempting to invoke has been converted to an Upstart job, but lsb-header is not supported for Upstart jobs." ?
[14:46] <Keybuk> hfcs even
[14:46] <Keybuk> barefoot: upstart jobs can have lsb headers
[14:46] <Keybuk> indeed, for the case of a distribution migrating from one to the other, it's probably a good idea
[14:46] <Keybuk> if the upstart jobs obey runlevel behaviour
[14:46] <sadmac> Keybuk: the any stanza solves it for me.
[14:47] <Keybuk> sadmac: I'm still not sure which I like better
[14:47] <sadmac> Keybuk: either one solves the issue. As long as there's the distinction and the explicitness.
[14:47] <Keybuk> right
[14:47] <ion> I was thinking about the semantics of something like “task, on tree-changed /foo/bar and every 5 minutes”; how about this: each time either event occurs, it sets a flag true for the event in question in the job’s “on” tree, and whenever the job is in the stopped state the next time, if the tree evaluates to true, the flags are zeroed and the job is started. So, whenever both events happen again after the job was started the last time, the job will be ...
[14:48] <ion> ... started again. If the job is already running, it will be restarted whenever it stops.
[14:49] <Keybuk> makes some amount of sense
[14:49] <Keybuk> kinda watershedy
[14:49] <barefoot> Keybuk: hmm, k, guess ill look at the docs and write a new conf for /etc/init for this
[14:50] <ion> Indeed, watershed was exactly what i was thinking of, but combined with the support for boolean operators. “on tree-changed /foo/bar or tree-changed /foo/baz”: if either path changes after the job was started the last time, the “on” tree will evaluate to TRUE and the job will be started whenever it is in the stopped state.
[14:51] <Md> Keybuk: do you have plans to implement the "open the daemon's listening socket" stuff in upstart?
[14:51] <Keybuk> Md: yes, same plans I've always had
[14:52] <Md> cool. for me it's the major selling point of systemd, and I expect that many other believe the same
[14:52] <Keybuk> yeah, but it's broken if you *just* do it that way
[14:52] <Md> how do you plan to do it?
[14:52] <Keybuk> Apple only get away with it because they control the entire stack
[14:53] <Keybuk> so can avoid the circular dependencies
[14:53] <Keybuk> Linux has *hundreds* of circular dependencies
[14:53] <Keybuk> and you end up with three or more processes blocking on each other
[14:53] <Keybuk> and since the init system knows nothing about them, it can't do anything about it
[14:53] <Md> do you have some examples?
[14:54] <Keybuk> I think the one I hit when I tried to boot Ubuntu with launchd pre-Upstart was NM, D-Bus, HAL, dhclient, wpasupplicant and the dhcdbd thing
[14:54] <Keybuk> they ended up wedged
[14:54] <Keybuk> but there's plenty
[14:54] <Keybuk> the how:
[14:54] <Keybuk> a config will be able to specify ports/sockets/etc. to listen on
[14:54] <Keybuk> these will be combined with the "while"
[14:55] <Keybuk> so the socket only exists once the while is true (rather than always)
[14:55] <Keybuk> on connection, start the service, pass the socket
[14:55] <Keybuk> usual expectation
[14:55] <Keybuk> ignore the socket while the service is running
[14:55] <Keybuk> but most interesting, this can also be combined with other upstart events
[14:55] <Md> does this still allow starting daemons on demand?
[14:55] <Keybuk> like start a service when the system is idle on boot, or on initial connection (whichever comes first)
[14:56] <Keybuk> yes
[14:56] <Keybuk> you can still have a service that only has a "listen"
[14:56] <Keybuk> or have a service with only "while"
[14:56] <Md> do you already have a timeframe for implementing this?
[14:56] <Keybuk> but both is supported too
[14:56] <Keybuk> yes, next 6 months
[14:56] <Md> BTW, a problem I have found with systemd and which I am not sure Lennart is ready to solve is daemons which need to bind to a specific IP/interface
[14:56] <Keybuk> oh, and also, upstart will support things like "not when on battery"
[14:57] <Keybuk> and "not when the system load is high"
[14:57] <Keybuk> and "not when we need to conserve power"
[14:57] <Keybuk> which get very nice when combined with on demand things
[14:57] <Keybuk> so you won't be able to on-demand start something if it's inhibited because the system is low on power, or doing updates, etc.
[14:58] <Keybuk> Md: right :)  I'd planned to do that out of the box
[14:58] <Md> how?
[14:58] <Keybuk> Upstart gets an event when the network comes up ;)
[14:58] <Keybuk> it can use those itself; in this case to begin listening on that IP
[14:58] <Keybuk> when the IP concerned goes down, it would stop
[14:58] <Md> does it now? I remember we discussed this and I planned to write a child daemon to do it but I never even checked out the source...
[14:59] <Md> "when the IP concerned goes down, it would stop" is tricky because in some situations you want to move an IP address between different interfaces (e.g. wired/wireless) and not kill the daemon
[15:02] <sadmac> if NetworkManager consumes everything, it could signal those states safely
[15:03]  * sadmac is now wearing a complete Stig costume which arrived in the mail a few minutes ago
[16:39] <ion> Note to self: talk to Keybuk about ssh-agent: you don’t actually need to get environment variables from ssh-agent’s output and inject them into the user session. Just do
[16:39] <ion> while user
[16:39] <ion> env SSH_AUTH_SOCK=/var/run/ssh-agent/$USER/agent
[16:39] <ion> exec ssh-agent -a "$SSH_AUTH_SOCK"
[16:40] <ion> He probably has figured this already, but anyhoo
[16:40] <ion> while-around user, actually, for the lack of a better stanza. :-P