[10:26] <Keybuk> interesting
[10:26] <Keybuk> upstart's tests consistently fail on the buildds
[10:26] <Keybuk> (null):alloc.c:416: Assertion failed in nih_alloc_size: ptr != NULL
[10:26] <Keybuk> FAIL: test_file
[10:28] <Keybuk> passed on powerpc and sparc
[10:28] <Keybuk> failed on both real architectures, and itanium
[01:26] <drakeoutlaw> hi all, can we boot to a non gui console with the single command?
[01:26] <drakeoutlaw> !single
[01:30] <Keybuk> drakeoutlaw: depends on the distribution; which are you using?
[01:32] <drakeoutlaw> edgy, but there is no /etc/inittab
[01:33] <Keybuk> yes, you can still use "single" to get to single-user mode
[01:34] <drakeoutlaw> ok, but how to change the default run level?
[01:34] <Keybuk> see /usr/share/doc/upstart/README.Debian.gz
[01:35] <drakeoutlaw> ok willdo
[02:01] <Keybuk> hmm
[02:01] <Keybuk> again I can't help but think that "failed" shouldn't be a separate event, but should be an argument to the "stopped" event
[02:01] <Keybuk> (or stopping)
[06:50] <wasabi> Keybuk: I agree with that. It makes the job easier for other people who want to know when the job is "no longer running"
[06:50] <wasabi> Without having to explicitly say stopped or failed
[06:50] <wasabi> And most dependencies care about the fact that the server is gone, less about the particulars about why it is gone.
[07:09] <Amaranth> so can we actually start writing useful jobs or whatever with 0.3? :)
[07:11] <Keybuk> well, failed was always going to be followed by stopped
[07:11] <Keybuk> the reason I was thinking of merging them is that there's no way right now to say "until this job succeeds"
[07:11] <Keybuk> e.g. ntpdate, you only want to run once
[07:11] <Keybuk> on network-interface-up and from startup until $NTPDATE_DIDNT_FAIL
[07:12] <Keybuk> Amaranth: that's the intent
[07:12] <Keybuk> 0.2 was "let's see if the daemon code works, and is sound in principal"
[07:12] <Amaranth> heh
[07:12] <Amaranth> i'll have to look into converting willowng to use it
[07:12] <Amaranth> although it's not particularly complex, just starting and stopping, no fancy stuff
[07:19] <Keybuk> that's a dbus service?
[07:25] <AlexExtreme> hmm, Keybuk: when you do that talk at linux.conf.au, will there be any way of seeing a video/audio of the talk? i'd quite like to see it but I can't easily get to Australia for it ;)
[07:25] <Keybuk> I've no idea
[07:25] <Keybuk> I suspect, given jdub, that they'll all be live streamed or something
[07:25] <Keybuk> I'm in the big hall, so it's possible
[07:25] <AlexExtreme> great
[07:27] <Keybuk> Amaranth: looking at the willowng package in edgy; it'd be something like
[07:27] <Keybuk>      start on started dbus
[07:27] <Keybuk>      stop on stopping dbus
[07:27] <Keybuk>     exec /usr/sbin/willowng
[07:28] <Amaranth> yeah, real simple :)
[07:28] <Keybuk> I'd probably write it as
[07:28] <Keybuk>     from started dbus until stopping dbus
[07:28] <Keybuk>     respawn /usr/sbin/willowng
[07:28] <Keybuk> so it gets respawned as well; and acts statefully
[07:34] <Amaranth> wow, i love upstart
[07:34] <Amaranth> the init script is like 20 lines of garbage
[07:34] <Amaranth> that's 2 lines that tell you exactly what's going on
[07:35] <AlexExtreme> yeah
[07:35] <AlexExtreme> it's the simplest i've ever seen
[07:35] <AlexExtreme> none of the other "next-gen" init systems do that as simply as that
[07:36] <Amaranth> There is a lot of magic behind the scenes to make things that simple, I'm sure.
[07:36] <AlexExtreme> see the specifications for upstart on launchpad ;)
[07:38] <Keybuk> I like reading the really old specs, and being amused by how much has changed in a year
[07:38] <AlexExtreme> yeah
[07:38] <Keybuk> the PDF on the upstart website is particularly good <g>
[07:38] <Keybuk> "The basic design of upstart is that tasks exist in one of three states:"
[07:39] <Keybuk> we have something like 8 now
[07:39] <AlexExtreme> :P
[07:39] <_ion> :-)
[07:40] <Keybuk> and that goes on about "edge events" and "level events"
[07:50] <Keybuk> we do still need to rename /etc/event.d
[07:51] <AlexExtreme> why's that?
[07:51] <Keybuk> it's not very descriptive of its content
[07:51] <Keybuk> it contains definitions of services, tasks and states
[07:51] <Keybuk> not events :)
[07:51] <AlexExtreme> so, servicetaskstate.d? :)
[07:54] <AlexExtreme> gotta go
[07:54] <Keybuk> http://opensolaris.org/os/project/smf-profiles/;jsessionid=A8CF91BE41ED07443BFA5A4F686515D0
[07:54] <Keybuk> interesting