[06:07] <HTSJacket_> Hello, I am try to write an event for upstart 0.2.7 that needs input from the keyboard.  I've put "console output" as the last line.  Am I heading in the wrong direction?  Thanks for any help you may be able to give!
[06:22] <HTSJacket_> the three lines in my event are: start on startup          exec /usr/bin/passwd         console output
[06:36] <HTSJacket_> I've been testing with no splash... but I guess I am misunderstanding the concept of /dev/console... how would I switch to a tty to get the input?
[10:04] <fatal> Could this be correct or should it be fixed some other way? http://fatal.se/tmp/upstart-sig.diff
[10:37] <_ion> fatal: You probably should send it to Keybuk or the mailing list.
[10:53] <fatal> I probably fucked something up, so I'll wait a while more before spreading it around too much... I just posted it to http://bugs.debian.org/413944 ... hopefully "djpig" will do another build attempt on sparc soon and verify if it's enough to build...
[01:04] <Keybuk> *sigh*
[01:04] <Keybuk> every time I try to explain or demonstrate how upstart works, I find buts
[01:04] <Keybuk> bugs too
[01:05] <Keybuk> the diagram says that pre-stop to running should not emit a "started" event, because we never emitted stopping or stopped.  However the code did emit a started event again, and also didn't "forget" the reason that the job was tried to be stopped.
[01:06] <Keybuk> the other was that the diagram and code both said that starting to waiting shouldn't emit "stopped"; however this transition occurs if respawn/restart fails, so we do need to emit stopped
[01:23] <_ion> It occurs to me that there might be nice state machine generators that generate both efficient code *and* a graphviz-style diagram, which could be checked for errors. They probably have the same problems as yacc has as a parser generator (which is why you wrote your own config parser).
[01:23] <_ion> Btw,
[01:23] <_ion> to110450 < fatal> Could this be correct or should it be fixed some other way? http://fatal.se/tmp/upstart-sig.diff
[01:23] <_ion> to113739 < _ion> fatal: You probably should send it to Keybuk or the mailing list.
[01:23] <_ion> to115309 < fatal> I probably fucked something up, so I'll wait a while more before spreading it around too much... I just posted it to  http://bugs.debian.org/413944 ... hopefully "djpig" will do another build attempt on sparc soon and verify if it's enough to  build...
[01:24] <Keybuk> http://codebrowse.launchpad.net/~keybuk/libnih/main/revision/scott%40netsplit.com-20070213153816-p1uyfqil3b33jt2w?start_revid=scott%40netsplit.com-20070302112615-e8kojdbnxg2pytz0
[01:24] <Keybuk> http://codebrowse.launchpad.net/~keybuk/libnih/main/revision/scott%40netsplit.com-20070213180004-442ndyfx5pq1a70i?start_revid=scott%40netsplit.com-20070302112615-e8kojdbnxg2pytz0
[01:25] <_ion> Ah. :-)
[01:32] <_ion> keybuk: Btw, have you had time to inspect the delayed_watch changes?
[01:32] <_ion> Of course, there are more acute things.
[01:33] <Keybuk> yeah I've looked over them quite a bit
[01:34] <Keybuk> my plan is to integrate your patch directly into nih/watch.c, since it's useful enough that it should be done by default
[01:34] <_ion> Ok, nice.
[01:35] <Keybuk> it doesn't eliminate the need to make sure that handling functions are idempotent, but it does at least eliminate some of the strange churn with the way editors make backup files, or write over other files
[02:00] <Keybuk> (random)
[02:00] <Keybuk> the difference in languages is incredible
[02:00] <Keybuk> upstart would be substantially larger and more complex if it *weren't* written in C
[02:01] <Keybuk> but initctl would be substantially smaller and simpler if it was written in something like Python
[02:03] <_ion> Heh
[04:15] <wasabi_> merging huge branches of code which have been independent for 2 months is pretty mindnumbing.

[04:16] <Keybuk> yeah