[12:27] <Keybuk> yeah, it has that
[12:31] <mbiebl> Keybuk: I've been toying around a bit with r502
[12:31] <mbiebl> And with minor updates to the job files it works fine.
[12:32] <mbiebl> I was just wondering, why the job files have all these "stop on shutdown|runlevel-x" stanzas
[12:32] <mbiebl> For scripts, stop is never really called, right?
[12:33] <Keybuk> well
[12:33] <Keybuk> because they're rc scripts
[12:33] <Keybuk> and sysv was never designed with running the rc6 (reboot) script while starting into rc2
[12:33] <Keybuk> I have that so if you press Ctrl-Alt-Del while booting, it stops booting, and switches into reboot
[12:33] <Keybuk> which is roughly compatible
[12:34] <Keybuk> oh
[12:34] <Keybuk> you'll want the new job files
[12:34] <Keybuk> heh
[12:35] <mbiebl> well, i used the old ones compat job files and adapted them.
[12:35] <Keybuk> http://upstart.ubuntu.com/new-example-jobs/
[12:35] <Keybuk> the main differences are
[12:35] <Keybuk> 1) "runlevel" is now a single event, with an argument specifying the new runlevel
[12:35] <Keybuk> 2) "shutdown" is no more
[12:36] <Keybuk> so things now just "stop on runlevel" (ie. kill the running rc script if the runlevel changes)
[12:37] <mbiebl> Cool, I'll try these ones.
[12:49] <Keybuk> they work for me
[12:49] <Keybuk> which isn't to say much
[12:49] <Keybuk> I found a pretty nasty error with logd in the process though
[12:49] <Keybuk> which is why they're console output for now
[01:11] <_ion> pe011840 < Keybuk> I don't like "extensions"
[01:11] <_ion> Amen to that.
[01:20] <Keybuk> ok
[01:20] <Keybuk> well
[01:20] <Keybuk> that's job_change_state () rewritten
[01:21] <Keybuk> which could be happily described as the most core function
[01:21] <Keybuk> it actually got a *lot* simpler
[01:21] <Keybuk> which I think is encouraging
[01:22] <_ion> Nice.
[01:35] <Keybuk> of course, none of it *compiles* yet :p
[01:35] <_ion> Naaah, having it compile isn't as important as they say. :-)
[01:36] <Keybuk> it's annoying that the tests don't compile either
[01:37] <Keybuk> so I'm not sure if the changes I'm making to them are right :p
[01:37] <Keybuk> lots of things had assumptions about the state model
[01:38] <_ion> Have you already implemented it as a lookup table (i think you mentioned something like that earlier), or are the state decisions still plain code?
[01:41] <Keybuk> plain code
[01:41] <Keybuk> much more efficient
[01:50] <int0x0c> What is the status of Upstart on Gentoo?
[01:51] <int0x0c> Has there been any effort to write a backend for it?
[01:52] <Keybuk> it shouldn't need a "backend" ?
[01:52] <_ion> He probably means a compatibility layer.
[01:52] <int0x0c> _ion, yep, thanks
[01:52] <int0x0c> wrong terminology
[01:52] <Keybuk> there's been a few efforts to write jobs that emulate the existing Gentoo init system
[01:52] <Keybuk> I haven't actually seen any completed ones yet though
[01:53] <int0x0c> hmm
[01:53] <int0x0c> alright
[01:59] <Keybuk> _ion: do you remember who was doing them?
[02:00] <_ion> Sorry, nope.
[02:00] <_ion> 2006-12-15 19:52:46 < steev64> as much as people are going to hate me for it (not necessarily *in here*), I am trying to get up
[02:01] <_ion> start working on Gentoo
[02:03] <Keybuk> Sep 13 22:28:06 <rubengonc>     i am trying it on gentoo
[02:03] <Keybuk> Oct 04 17:12:15 <smlgb1>        Hi there. Did anybody of you try to install upstart on gentoo yet?
[02:03] <Keybuk> we should get these people together :p
[02:04] <_ion> 2006-10-27 23:31:21 < phsdv> hi all, I just managed to get my gentoo system booted using upstart.
[02:07] <Keybuk> http://upstart.ubuntu.com/wiki/UpstartOnGentoo
[02:07] <Keybuk> :p
[02:08] <_ion> :-)
[02:12] <int0x0c> I might try my hand this weekend at getting upstart going
[02:20] <Keybuk> http://upstart.ubuntu.com/wiki/JobStates?action=AttachFile&do=get&target=states.png
[02:20] <Keybuk> I am *so* glad I did that ^
[02:22] <_ion> :-)
[02:23] <Keybuk> though I've added to it since then
[02:31] <Keybuk> mbiebl: re
[02:36] <mbiebl> Keybuk: yes?
[02:38] <Keybuk> just hi
[02:39] <mbiebl> ah, thanks ;-)
[02:40] <mbiebl> About Md's question:
[02:40] <mbiebl> Seems as if in r502, dpkg-(old|new) files are not ignored.
[02:41] <Keybuk> uh, maybe I didn't push that yet
[02:41] <Keybuk> does nih/file.c have a nih_file_is_packaging ?
[02:41] <mbiebl> nope
[02:46] <Keybuk> ah
[05:17] <Keybuk> woo, she compiles again!
[01:35] <Keybuk> whee
[02:02] <Keybuk> I wasn't hallucinating last night; the test cases *do* pass
[02:07] <phsdv> congrats!
[02:28] <Keybuk> am trying to decide whether to continue to allow "respawn COMMAND" as a shortcut for both "exec COMMAND" and "respawn"
[02:29] <Md> yes. syntactical sugar is nice :-)
[02:37] <Keybuk> well, moment of truth
[02:40] <Keybuk> http://rafb.net/p/s2LD5c17.html
[02:40] <Keybuk> sweeeeeeet; ^ new job life cycle
[02:41] <Keybuk> note that the "test" job doesn't get to start until "test2" finishes, because test2 is marked "start on starting test"
[02:56] <Keybuk> http://rafb.net/p/HtgNXP55.html
[02:56] <Keybuk> ^ example of a job that needs another running
[02:57] <Keybuk> note how hal is started once dbus is running, but that when dbus is stopped, hal actually gets stopped first and dbus isn't stopped until hal is
[02:57] <Keybuk> http://rafb.net/p/eGZbr976.html
[02:58] <Keybuk> ^ and there's a counter-example of the opposite behaviour
[02:58] <Keybuk> tomcat is able to indicate that "apache needs it", so when you try and start apache, you get tomcat started *first*
[03:10] <giuseppe_> hi, i'm building a smal linux distro for learning purpose, and i was searching for something dealing with dependencies between daemons. I see upstart has removed this feature (https://launchpad.net/upstart/+spec/remove-depends). Does anyone has suggestions? are there init implementations dealing with dependencies? 
[03:13] <Keybuk> for what reason do you want dependencies?
[03:13] <Keybuk> there are (currently) four basic classes of init daemon, which all handle the problem differently:
[03:13] <Keybuk> 1) those that run scripts in order, so the order expresses "what must come first"
[03:14] <Keybuk>    e.g. sysvinit
[03:14] <giuseppe_> Keybuk: because i don't want to hardcode init scripts. I'm listening btw
[03:14] <Keybuk> 2) those that run everything at once, and expect the jobs to sort themselves out
[03:14] <Keybuk>    e.g. launchd
[03:14] <Keybuk> 3) those that use a package-manager style dependency chain, when you start a daemon anything it "depends" on is started first (and likewise, when you stop a daemon, it's dependencies aren't stopped until afterwards)
[03:15] <Keybuk>    e.g. Solaris SMF, init-NG
[03:15] <Keybuk> 4) those that use events; when you start or stop a daemon, it issues events; other daemons can be started or stopped by those events; and block the other
[03:15] <Keybuk>    e.g. upstart
[03:15] <Keybuk> I assume that #1 is what you're already familar with, and #2 isn't useful
[03:15] <giuseppe_> ok so basically you're telling me to read the upstart doc better :)
[03:16] <Keybuk> the upstart docs aren't that good :p
[03:16] <Keybuk> (yet)
[03:16] <Keybuk> my two usual examples are dbus/hal and apache/tomcat
[03:16] <Keybuk> hal needs dbus to be running while it is, if dbus is stopped, hal must be too
[03:17] <Keybuk> tomcat is needed by apache if installed, so apache is started, tomcat must be started first (and tomcat must not be stopped until apache is)
[03:17] <giuseppe_> ok this is not possible with simple dependencies then.. you have to use events
[03:17] <giuseppe_> from what i understand
[03:17] <Keybuk> in a dependency-based system you might try something like
[03:17] <Keybuk>   hal depends dbus
[03:17] <Keybuk>   and hal is a goal
[03:17] <Keybuk> so when you start hal, dbus is started first
[03:18] <Keybuk> the second one is more tricky in a dependency-based system because you don't want to edit the apache job description just because tomcat is installed
[03:18] <Keybuk> so you actually need something like
[03:18] <Keybuk>   tomcat is-dependency-of apache
[03:18] <Keybuk>   and apache is a goal
[03:18] <Keybuk> (the first being in the tomcat description)
[03:18] <giuseppe_> ok very clear
[03:18] <giuseppe_> thanks Keybuk 
[03:18] <Keybuk> don't know whether initNG supports that
[03:18] <Keybuk> I know SMF doesn't
[03:19] <Keybuk> in a event-based system, like upstart, you instead hook the events generated by hal, dbus, apache, tomcat, etc.
[03:19] <Keybuk> so you might use something like
[03:19] <Keybuk>   hal: start on starting dbus
[03:19] <Keybuk> err
[03:19] <Keybuk> sorry
[03:19] <Keybuk>   hal: start on started dbus
[03:19] <Keybuk>   hal: stop on stopping dbus
[03:19] <Keybuk> and for the tomcat case, it's easy
[03:19] <Keybuk>   tomcat: start on starting apache
[03:19] <Keybuk>   tomcat: stop on stopped apache
[03:20] <Keybuk> http://rafb.net/p/HtgNXP55.html
[03:20] <Keybuk> http://rafb.net/p/eGZbr976.html
[03:20] <Keybuk> (those two URLs given an example of both of those)
[03:20] <giuseppe_> Keybuk: thank you very much i'm going to read
[03:20] <Keybuk> in theory, the event-based system requires less manual or semi-automatic configuration
[03:20] <Keybuk> you can ship job definitions that do the right thing
[03:21] <Keybuk> and you don't need to modify other jobs or goals when you install a new daemon
[04:57] <giuseppe_> hi, i'm having troubles compiling upstart with gcc 3.3.5, is it a known issue?
[04:58] <giuseppe_> child.c: In function `nih_child_poll':
[04:58] <giuseppe_> child.c:141: error: `WEXITED' undeclared (first use in this function)
[04:58] <AlexExtreme> yes
[04:59] <AlexExtreme> upstart only compiles with 4.x afai
[04:59] <AlexExtreme> *afaik
[04:59] <giuseppe_> :|
[05:00] <Keybuk> that's more likely an out of date libc
[05:00] <AlexExtreme> ah
[05:00] <Keybuk> upstart needs both kernel and libc support for the waitid() system call
[05:00] <AlexExtreme> yeah
[05:01] <giuseppe_> i'm using debian's 2.3.2.ds1-22
[05:02] <giuseppe_> is there a particular libc version waitid() is available from?
[05:04] <Keybuk> 2.4 seems fine
[05:05] <Keybuk> there's a Debian package already
[05:05] <Keybuk> http://packages.debian.org/experimental/admin/upstart
[05:05] <giuseppe_> yep even 2.3.6 is ok
[05:05] <Keybuk> though it's a little out of date; if you have those build-deps, you should be fine
[05:05] <int0x0c> Have the upstart service files for the base ubuntu installation been developed yet (i.e. not the initrd wrapper)
[05:06] <Keybuk> int0x0c: they'll be available by monday
[05:06] <int0x0c> heh, wow, I picked quite a time to ask
[05:06] <AlexExtreme> woohoo :)
[05:06] <int0x0c> Are they in bzr at the moment?
[05:07] <giuseppe_> Keybuk: yes the problem is i'm trying to maintain a cross toolchain.. :|
[05:07] <AlexExtreme> Keybuk, let me know when/where I can get them when they are released, I can't wait to try it :)
[05:07] <Keybuk> no; I have a bunch of them on my laptop, but they're a bit broken because I'm busy rewriting upstart :p
[05:07] <Keybuk> and keep changing things
[05:08] <giuseppe_> Keybuk: i'm using this libc config: http://rafb.net/p/Kv1hho71.html, do you see problems with it? it is relative to glibc 2.3.6
[05:08] <int0x0c> What is the bzr branch?
[05:08] <Keybuk> int0x0c: for?
[05:08] <int0x0c> the service files
[05:09] <Keybuk> giuseppe_: I don't really know libc compiles; I would imagine it's fine
[05:09] <Keybuk> int0x0c: there isn't one just yet
[05:09] <Keybuk> I'll get them published this weekend :)
[05:09] <int0x0c> bah, alright
[05:09] <int0x0c> thanks a ton
[05:09] <Keybuk> (I could publish them now, but they wouldn't work for you :p)
[05:09] <Keybuk> http://upstart.ubuntu.com/states.png
[05:09] <Keybuk> ^ now, isn't *that* neater
[05:09] <AlexExtreme> nice
[05:10] <AlexExtreme> don't you just love dot ;)
[05:10] <int0x0c> Keybuk, I'm running gentoo
[05:10] <int0x0c> Keybuk, and looking into writing a set of services
[05:11] <int0x0c> Keybuk, I just need something for reference
[05:11] <int0x0c> If you had a sec, I would love a tarball
[05:11] <int0x0c> but don't worry about it if not
[05:11] <AlexExtreme> as he said, they won't work right now :)
[05:11] <Keybuk> I understand that :)  these just literally aren't ready right now
[05:12] <Keybuk> they're not even useful for reference
[05:12] <int0x0c> ahh, alright
[05:12] <int0x0c> fair enough
[05:14] <Keybuk> interesting; excluding tests, upstart 0.2.7 was 9,204 lines of code
[05:14] <Keybuk> since then (also excluding tests)
[05:14] <Keybuk>  36 files changed, 6899 insertions(+), 4654 deletions(-)
[05:14] <Keybuk> so I've changed roughly 50% of the code
[05:14] <Keybuk> that's kinda cool
[05:14] <AlexExtreme> yeah
[05:15] <Keybuk> test suites rock for this kind of mass-scale refactoring
[05:16] <Keybuk> a more odd stat ...
[05:16] <Keybuk> 0.3.5 has 11,360 lines of code ... but only 2,835 semi-colons
[05:17] <AlexExtreme> hah
[05:17] <AlexExtreme> I wish I could code as fast as this ><
[05:18] <Keybuk> the usual metric is 2.5 logical lines to a semi-colon
[05:22] <AlexExtreme> so for feisty do you reckon only the base services will be converted to upstart jobs for feisty's final release, seeing as feature freeze has started (it has, hasn't it?) ?
[05:22] <Keybuk> which makes upstart about 35% comments
[05:23] <AlexExtreme> hmm, just realised I said "for feisty" twice. ignore that :p
[05:25] <Keybuk> that's the plan
[05:26] <Keybuk> always has been, actually
[05:26] <AlexExtreme> mmm, k
[05:26] <Keybuk> most daemons will retain sysv init scripts for feisty
[05:26] <Keybuk> except the interesting ones
[05:26] <AlexExtreme> like dbus?
[05:26] <Keybuk> right
[05:28] <Keybuk> ok, that's config file deletion support pushed
[06:03] <Keybuk> I guess I should run valgrind over the new core :p
[06:03] <AlexExtreme> :P
[06:04] <Keybuk> shouldn't be any problems, since I didn't much around with memory stuff
[06:05] <Keybuk> all good
[07:00] <_ion> So you made "deleted" a state. That's good.
[07:03] <Keybuk> yeah, it made the most sense
[07:03] <Keybuk> it's the most trivial way of handling all the cases
[07:04] <Keybuk> - means it can't be started again, since it's not in the waiting state
[07:04] <Keybuk> - means that all deleted jobs can be quickly found and freed
[07:04] <Keybuk> - means that clients know that it's being deleted
[07:04] <Keybuk> etc.
[07:07] <_ion> Indeed.
[07:08] <Keybuk> it even means the clients can detect when they tried to start a deleted job :p
[07:08] <Keybuk> start "foo"
[07:08] <Keybuk> foo (stop) deleted
[12:23] <Keybuk> bloody ISP