[01:28] <Absorto> hello! I'm running Gutsy and unable to get a text mode login with Ctrl-Alt-F[1..6]. Help!
[12:30] <Keybuk> heh @ Absorto
[12:30] <Keybuk> that's actually the most logical bug to blame on Upstart in a while
[12:30] <Keybuk> better than last week when someone filed a bug on Upstart for muting their sound card when they switched to a VT
[12:30] <AlexExtreme> haha
[12:30] <ion_> He even had a whopping five minutes of patience!
[12:32] <Keybuk> (I *love* the fact that sound card stops when you switch VT
[12:32] <Keybuk>  it proves that Linux is really starting to get the underlying architecture correct)
[12:33] <ion_> Yeah
[12:34] <ion_> Unfortunately, that feature hasn't been ported to my drivers yet.
[12:35] <ion_> We'd still have time to make that feature consistent by the Hardy release. Could boast about it in the release notes.
[13:54]  * Keybuk tries to work out what the dbus marshalling code should actually look like
[14:52] <Keybuk> it'd be nice if a method just looked likt
[14:52] <Keybuk> int
[14:53] <Keybuk> dbus_job_start (Job *job,
[14:53] <Keybuk>                 char **env)
[14:53] <Keybuk> {
[14:53] <Keybuk>     /* do stuff to start the job, or nih_error_raise */
[14:53] <Keybuk> }
[14:53] <Keybuk> and there was auto-generated wrapper code to marshal the function call, and generate the reply
[14:54] <Keybuk> not sure how to handle errors though
[14:58] <Keybuk> since NihError and DBusError don't quite 1:1 match
[15:16] <sadmac2> Keybuk: that reminds me. We've had to patch nih so that it would recognize rpm tempfiles as package manager files (and thus upstart would ignore them in event.d)
[15:16] <sadmac2> do you want that upstream?
[15:16] <Keybuk> yeah, definitely
[15:17] <jdong> Keybuk: if I am not careful, is it possible to end up with a circular start-stop relationship? :D
[15:17] <Keybuk> jdong: sure
[15:17] <Keybuk> foo:
[15:17] <Keybuk>   start on stopped bar
[15:17] <Keybuk>   stop on started bar
[15:17] <Keybuk> bar:
[15:17] <Keybuk>   start on stopped foo
[15:17] <Keybuk>   stop on started foo
[15:18] <jdong> cool :)
[15:18] <jdong> Keybuk: a less silly question, are there any plans/ideas for revamping initramfs with something upstart related?
[15:18] <Keybuk> general idea is that /sbin/init in the initramfs is upstart
[15:18] <Keybuk> and you copy the bits of /etc/event.d you want in too
[15:19] <jdong> Keybuk: it seems like rigth now more than 1/3 of my bootup is in initramfs and I can't help but think it can be done more efficiently
[15:19] <Keybuk> hand-over by reexec, it would pass the job configuration over as "deleted jobs"
[15:19] <jdong> sounds cool
[15:19] <Keybuk> so the upstart in the real system would know the status/pid/etc. of those started in initramfs
[15:19] <jdong> what's the Ubuntu timeline for having more stuff done by Upstart? Next cycle?
[15:20] <Keybuk> yeah
[15:20] <jdong> awesome, I really look forward to it. Hacking my Hardy box to boot off upstart has been one of the more exciting things I've done recently
[15:20] <jdong> Keybuk: also, what kinds of files are ignored in event.d?
[15:21] <sadmac2> Keybuk: check your email. you have a patch
[15:21] <Keybuk> jdong: hidden files, backup files, swap files, RCS control files and packaging debris
[15:21] <jdong> Keybuk: very nice
[15:22] <jdong> Keybuk: does Upstart understand subdirectory structure in event.d?
[15:22] <Keybuk> yes
[15:22] <jdong> does it have any special meaning, or can I arbitrarily use it to organize my job files?
[15:22] <Keybuk> arbitrary organisation
[15:22] <Keybuk> the /etc/event.d/foo/bar/baz file defines a job called foo/bar/baz
[15:22] <jdong> cool
[15:23] <jdong> Keybuk: also, is there a way for sysv jobs to interact with upstart, such as automatic firing of events for when sysv jobs start/stop?
[15:23] <jdong> other than hacking /etc/init.d/rc :)
[15:24] <Keybuk> why is not hacking rc important?
[15:24] <Keybuk> I'd just hack rc to emit sysv-started and sysv-stopped at appropriate times
[15:24] <jdong> Keybuk: just wondering if there's any standardized way yet. I have no problem hacking rc if that's the right way(tm)
[15:24] <sadmac2> jdong: that's how we're doing it in Fedora
[15:25] <jdong> Keybuk: could this also be an upstart-compat-sysv feature for Intrepid?
[15:25] <jdong> sadmac2: yeah, I'll do that locally  for now
[15:33] <sadmac2> Keybuk: I'm thinking that some time very shortly after 0.5 NetworkManagerDispatcher could be replaced entirely by upstart.
[15:40] <sadmac2> brb moving desk
[17:01] <Keybuk> I can't decide which is better
[17:01] <Keybuk> changing NihError to have some kind of dbus-compatible error string
[17:01] <Keybuk> or having a look-up table to convert between NihError enums and DBusError strings
[17:55] <Keybuk> thought-of-the-day
[17:56] <Keybuk> should the Start() method return immediately, or not return until the service is running/task is finished?
[22:06] <ion_> keybuk: I’m not familiar enough with how dbus APIs generally behave to give an opinion.
[22:06] <Keybuk> me neither
[22:06] <Keybuk> you basically expose objects
[22:06] <Keybuk> objects have interfaces
[22:06] <Keybuk> interfaces have methods
[22:06] <Keybuk> so that's all well and good
[22:06] <Keybuk> Upstart has JobConfigs and Jobs
[22:06] <Keybuk> (or Jobs and Instances, depending on the direction I'm explaining from :p)
[22:07] <Keybuk> so in theory, these should map well
[22:07] <Keybuk> we'd have a /com/ubuntu/Upstart object with a com.ubuntu.Upstart.Manager interface
[22:08] <Keybuk> that has a FindByName(String name) -> (Object) method
[22:08] <Keybuk> obviously that's going to return a Job object
[22:09] <Keybuk> to start a Job, you need to find or create an Instance, then start that Instance
[22:09] <Keybuk> it can fail because you didn't supply enough parameters to identify an Instance
[22:09] <Keybuk> it can fail because the Instance was already started
[22:10] <Keybuk> if you start a job, you probably want to also be notified of its goal and status changes (initctl does anyway)
[22:10] <Keybuk> and you want to be notified when it is actually started, or the starting failed
[22:10] <ion_> Yeah
[22:11] <Keybuk> the goal and status changes are clearly Signals
[22:11] <Keybuk> you have to tell D-Bus that you want a signal, so this wouldn't work:
[22:11] <Keybuk>   job = FindByName("apache")
[22:11] <Keybuk>   instance = job.Start(...)
[22:12] <Keybuk>   dbus.AddMatch(instance, "StatusChanged")
[22:12] <Keybuk> since you have a race between the Start and the AddMatch where you'll miss signals
[22:12] <ion_> Yep
[22:12] <ion_> Fix dbus API? :-P
[22:12] <Keybuk> you only want the signals from the instance you're going to start
[22:12] <Keybuk> you don't care about the other running apache instances
[22:13] <Keybuk> (and jobs don't have goals or status anyway)
[22:15] <Keybuk> we could expose the entire process to the client, and let it do the hard work
[22:15]  * ion_ envisions the DBus API taking a Ruby-style block, which is executed *after* the object is created but *before* the command has been sent, i.e. instance = job.Start(...) {|it| dbus.AddMatch(it, "StatusChanged") }
[22:15] <Keybuk> but I think that's generally bad
[22:17] <Keybuk> so my idea was to have a magic D-Bus "request" object
[22:17] <Keybuk>   job = FindByName("apache")
[22:17] <Keybuk>   request = job.Start(...)
[22:17] <Keybuk>   dbus.AddMatch(request, "StatusChanged")
[22:17] <Keybuk>   request.Go()
[22:17] <ion_> Yeah, that would be equivalent (without the syntactic sugar). :-)
[22:30] <Keybuk> though I guess it should be StartRequest(...)
[22:30] <Keybuk> since Start() would do it without an intermediate object
[22:32] <Keybuk> and almost everything other than initctl will just use Start()