[01:20] <Keybuk> sadmac_: yes
[01:21] <Keybuk> though in 0.3.x it will probably contain the event that stopped the job
[01:21] <Keybuk> whereas in trunk, UPSTART_EVENTS will contain the events that originally started it
[12:08] <keesj> Hi
[12:16] <Keybuk> hi
[12:24] <keesj> The chance I wil use upstart are growing every day :p
[12:25] <keesj> I am now looking into the kernel->upstart communication
[12:28] <keesj> special I am looking at the udev from the replacement-initscripts http://paste-it.net/7162/raw/
[12:29] <keesj> that script has a "emits block-device-added block-device-removed" section
[12:32] <keesj> what it that good for?
[12:32] <Keybuk> "emits" is just a documentation stanza
[12:33] <Keybuk> you'd use it in the job definitions of services that are known to emit their own events
[12:33] <Keybuk> and that way other frontend tools can draw pretty dependency graphs using things like dotty
[12:33] <keesj> sexy :p
[12:33] <Keybuk> it's not actually used by Upstart in any way, other than being available as a property
[12:34] <Keybuk> the theory there is that that distribution would ship udev rules that looked something like:
[12:34] <Keybuk>   SUBSYSTEM=="block", ACTION=="add", RUN+="/sbin/initctl emit block-device-added DEVPATH"
[12:34] <Keybuk>   SUBSYSTEM=="block", ACTION=="remove", RUN+="/sbin/initctl emit block-device-removed DEVPATH"
[12:35] <Keybuk>   SUBSYSTEM=="net", ACTION=="add", RUN+="/sbin/initctl emit network-device-added INTERFACE"
[12:35] <Keybuk>   SUBSYSTEM=="net", ACTION=="remove", RUN+="/sbin/initctl emit network-device-removed INTERFACE"
[12:35] <Keybuk> etc.
[12:35] <Keybuk> alternately we may want an upstart-addon-udev or something so we could have a generic RUN+="socket:/com/ubuntu/upstart/udev" at the end, and let the addon daemon turn those into events
[12:35] <Keybuk> OR we might just patch udev directly to emit events into upstart
[12:37] <keesj> my system does not use udev, i currently use <linux/netlink.h> to recieve NETLINK_KOBJECT_UEVENT events
[12:38] <keesj> I could just create a mini app that gets started and emits the kernel uevent
[12:40] <keesj> hmm I will look into it 
[12:43] <Keybuk> right
[12:43] <Keybuk> you could have a little daemon to listen on the netlink socket and inject into upstart
[12:44] <keesj> I do have the same kind of problems that are solved by udev , being that if a device get plugged before the daemon is started I will never know about
[12:45] <keesj> I then have to write custom code to look at the status .
[12:56] <Keybuk> why not just write to the uevent files like udev does?
[12:56] <Keybuk> for each object under /sys that a uevent was originally emitted for, there will be a uevent file
[12:56] <Keybuk> write "add" (no \0, no \n, etc.) to that, and the kernel will resend it
[13:03] <keesj> Thanks for the tip , I will have to look into how that works!
[19:12] <Keybuk> ion_: interesting thought of the day
[19:12] <Keybuk> all of the dbus_bus_ calls block
[19:17] <ion_> keybuk: Is that a problem?
[19:18] <Keybuk> I'm not sure
[19:20] <Keybuk> the fact that dbus_bus_get() can never return worries me enough :p
[19:20] <ion_> Heh
[19:23] <Keybuk> I guess it depends at what level of blocking we have to worry about in Upstart
[19:24] <Keybuk> in some senses, blocking is actually not necessarily bad
[19:24] <Keybuk> since it reduces system load
[19:24] <Keybuk> e.g. upstart blocks while it sets up a process, even though that's happening the child
[19:24] <Keybuk> and doesn't move onto the next until exec() completes
[19:24] <Keybuk> so arguably, after starting dbus, blocking to connect to it and say Hello isn't too bad
[19:40] <ion_> Yep...
[19:56] <ion_> Don’t they have a separate DBus (client) implementation in C#? Perhaps someone should NIH a DBus implementation that doesn’t suck in C. ;-)
[19:56] <Keybuk> ndesk-dbus
[20:01] <Keybuk> the C API isn't really that bad
[20:01] <Keybuk> the main problem is just figuring out how to dispatch methods
[20:14] <keesj> ion_: that would be great
[21:17] <Amaranth> @btlogin
[21:17] <Amaranth> err