[03:55] <JohnFlux> Hey all
[03:56] <JohnFlux> to any developers..  could you include a package with the header files etc?
[03:56] <JohnFlux> it's currently impossible to write a program that queries upstart etc
[08:52] <soren> JohnFlux: Huh? How do you figure that?
[09:03] <JohnFlux> soren: ah hey!
[09:04] <JohnFlux> soren: I have ubuntu
[09:04] <JohnFlux> soren: If I look at what packages there are, there's no libupstart of libupstart-dev etc
[09:05] <soren> JohnFlux: Why do you need them?
[09:05] <JohnFlux> soren: if I look at the files that come with it just "upstart" there's no libraries nor header files
[09:05] <JohnFlux> soren: so that I can make a gui for upstart
[09:05] <soren> JohnFlux: Er..
[09:06] <soren> JohnFlux: You don't need header files or libraries to do anything like that.
[09:06] <JohnFlux> soren: in particular, I want to be able to get a list of running services, for example
[09:06] <soren> status
[09:07] <JohnFlux> I'd much prefer a library to trying to parse the output of programs :/
[09:07] <soren> Sorry, I meant "initctl list".
[09:09] <JohnFlux> soren: so how about?  a libupstart ? :)
[09:10] <soren> There's no such thing. You can try convincing Keybuk that it'd be useful and you might get lucky :)
[09:10] <JohnFlux> he's comes in here right?
[09:10] <JohnFlux> I'll give that a shot thanks
[09:10] <soren> Yeah, he'll be around in an hour or so, I'd guess.
[09:10] <JohnFlux> btw I'm the maintainer of the kde "task manager" type thinig
[09:11] <JohnFlux> thing
[09:11] <JohnFlux> just looking to use upstart info to improve the info of what's shown
[10:06] <Jc2k> JohnFlux: i think libupstart is about to be killed off
[10:06] <Jc2k> see the mailing list post that the topic refers to
[10:06] <Jc2k> "libupstart goes away, which nobody else is using anyway."
[10:09] <Jc2k> instead there will be dbus aplenty
[01:42] <Keybuk> "Pack-based repositories"
[01:42] <Keybuk> THE RAPTORS ARE COMING!
[01:47] <Keybuk> ravenous raptor
[01:48] <soren> Good one.
[01:50] <Keybuk> I need a brain-to-tomboy sync plugin
[01:51] <Keybuk> so when I think of neat code changes in bed, I don't need to have to try and remember them in the morning
[01:53] <soren> Any reasonable person would suggest some sort of intermediate storage like a piece of paper, but I haven't managed to implement that either.
[01:53] <soren> Althought it is a bit alarming to imagine how many good ideas have just vanished because I haven't bothered to write them down before falling asleep.
[01:54] <Keybuk> aye
[02:44] <JohnFlux> Jc2k: nobody is using it because it's impossible to use
[02:44] <JohnFlux> Jc2k: it's not actually shipped
[02:44] <JohnFlux> Jc2k: I've been wanting to use it for ages
[02:44] <JohnFlux> Jc2k: I asked on the mailing list about it like 6 months ago
[02:45] <JohnFlux> Jc2k: it will be a shame if it's just killed off 
[02:46] <Jc2k> why? isnt libupstart mostly about ipc? which will be handled via dbus, and thus *easily* accessible?
[02:49] <Keybuk> it's entirely about IPC
[02:50] <Jc2k> so therefore JohnFlux has nothing to fear by libupstart death, in fact has much to gain from it.
[02:51] <Keybuk> he won't have to rewrite his front-end with every minor release, for a start ;)
[02:52] <JohnFlux> actually that does sound good
[02:52] <Keybuk> JohnFlux: libupstart has never been a stable API
[02:52] <Keybuk> initctl uses it, but that's it
[02:53] <JohnFlux> how far along is it btw?
[02:53] <JohnFlux> the dcop thing
[02:53] <Keybuk> ?
[02:54] <Keybuk> how far along is what?
[02:54] <Jc2k> s/dcop/dbus/
[02:54] <JohnFlux> right hehe
[02:54] <JohnFlux> Does it offer a dbus service at the moment?
[02:54] <Jc2k> Keybuk: how long till 0.5 basically
[02:54] <Keybuk> no
[02:54] <Keybuk> far along = not even started
[02:54] <JohnFlux> heh
[02:54] <JohnFlux> fair enough
[02:55] <JohnFlux> do any other distros use upstart btw?
[02:55] <JohnFlux> or just ubuntu?
[02:56] <Keybuk> just ubuntu at the moment
[04:53] <Keybuk> I've made a few commits to Upstart in the last few days
[04:53] <Keybuk> and lots to libnih :p
[04:53] <Keybuk> so I'm at least starting on the roadmap to 0.5
[04:54] <Jc2k> \o/
[04:54] <Jc2k> oh
[04:54] <Jc2k> questionage
[04:55] <Jc2k> can upstart be forced to run as a slave of "old" init?
[04:56] <soren> Having two init implementations running side by side is hardly less controversial than what Ubuntu currently does?
[04:59] <Jc2k> if something depended on upstart and upstart could be installed without ripping the heart out of your distrothen it would be a lot more viable
[05:00] <Jc2k> *shrugs*
[05:01] <Keybuk> the problem with being a slave is that it isn't init
[05:01] <Keybuk> so doesn't get afforded init's special privileges
[05:01] <Jc2k> bleh
[05:01] <soren> Jc2k: You should know that UNIX kicks harder. :)
[05:02] <Jc2k> :)
[05:02] <Keybuk> you could write an upstart parser for inittab :)
[05:02] <Keybuk> then it could just be a drop-in replacement for sysvinit
[05:02] <Keybuk> on trunk, that should be quite easy
[05:03] <Jc2k> interesting
[05:05] <Keybuk> inittab would be a ConfSource, register jobs with useful names like "inittab/$id", etc.
[05:05] <Keybuk> certainly upstart supports a superset of inittab's features
[09:32] <ion_> :-)
[09:47] <Keybuk> now, of course, I have to work around the ways I was attempting to work around the lack of something I've now implemented
[10:15] <Keybuk> yay, ok init builds again
[10:15] <Keybuk> now for the tests
[11:09] <Keybuk> ==13312==  Address 0x1C is not stack'd, malloc'd or (recently) free'd
[11:09] <Keybuk> that would be bad, then
[12:23] <Keybuk> ==32728== Invalid write of size 4
[12:23] <Keybuk> ==32728==    at 0x8093F89: nih_list_cut (list.c:202)
[12:23] <Keybuk> ==32728==    by 0x809405D: nih_list_destroy (list.c:246)
[12:23] <Keybuk> ==32728==    by 0x8092C09: nih_free (alloc.c:330)
[12:23] <Keybuk> ==32728==    by 0x8092C34: nih_free (alloc.c:336)
[12:23] <Keybuk> ==32728==    by 0x808D243: parse_job (parse_job.c:278)
[12:23] <Keybuk> ==32728==    by 0x805DF5B: test_stanza_start (test_parse_job.c:2185)
[12:23] <Keybuk> ==32728==    by 0x8087030: main (test_parse_job.c:7303)
[12:23] <Keybuk> ==32728==  Address 0xBEEFA174 is just below the stack ptr.  To suppress, use: --workaround-gcc296-bugs=yes
[12:41] <Keybuk> oh I see