| Keybuk | *sigh* | 15:17 |
|---|---|---|
| Keybuk | I wish upstart's test suite wouldn't drop a core file | 15:17 |
| Keybuk | but I don't see any way of fixing that | 15:17 |
| Keybuk | (unless anyone knows a syscall that you can invoke on a child process to find out the name of the core file it generated? :p) | 15:20 |
| sadmac_ | Keybuk: I think you pass a parameter to that one that tells you whether an arbitrary binary/input will halt | 15:45 |
| sadmac_ | :D | 15:45 |
| Keybuk | I can find out that it generated a core file | 15:47 |
| Keybuk | since that's exactly what's being tested :p | 15:47 |
| Keybuk | which means this test case leaves a core file in the working directory | 15:47 |
| sadmac_ | Inotify? | 15:48 |
| Keybuk | bah, | 15:54 |
| Keybuk | foiled by Ubuntu anyway | 15:54 |
| Keybuk | apport steals the core file and writes it itself | 15:54 |
| Keybuk | so it shows up after the test has completed | 15:54 |
| ion_ | Heh | 15:54 |
| Keybuk | so, which config fields should undergo parameter expansion? | 16:08 |
| Keybuk | the obvious ones to me are: | 16:08 |
| Keybuk | "stop on" | 16:08 |
| Keybuk | "instance" | 16:08 |
| Keybuk | "uses" | 16:08 |
| Keybuk | "depends" | 16:09 |
| Keybuk | (where the last two are resources and file dependencies respectively) | 16:09 |
| Keybuk | exec and script obviously don't need to undergo parameter expansion since a shell is used, which will do it for us | 16:10 |
| Keybuk | "start on" can't, since it's matched for the config not the job | 16:10 |
| Keybuk | (and it would be nonsensical anyway) | 16:10 |
| Keybuk | "description", "author" and "version" don't seem to need it | 16:11 |
| Keybuk | "emits" probably doesn't (and isn't used by anything anyway) | 16:11 |
| Keybuk | "wait for", "respawn timer", "kill timer", "normal exit", "console", etc. are kinda tricky | 16:12 |
| Keybuk | "umask", "nice", "limit", "chroot", "chdir", etc. likewise | 16:12 |
| ion_ | What kind of parameter expansion? | 16:25 |
| Keybuk | so, say you have this job | 16:26 |
| Keybuk | start on tty-added | 16:26 |
| Keybuk | stop on tty-removed $TTY | 16:26 |
| Keybuk | instance $TTY | 16:26 |
| Keybuk | respawn | 16:26 |
| Keybuk | exec /sbin/getty 38400 $TTY | 16:26 |
| Keybuk | -- | 16:26 |
| Keybuk | and the tty-added and tty-removed events have the TTY parameter set | 16:27 |
| Keybuk | that job can be started/stopped by things like: | 16:27 |
| Keybuk | start getty TTY=ttyS0 | 16:27 |
| Keybuk | stop getty TTY=ttyS0 | 16:27 |
| Keybuk | emit tty-added TTY=ttyS0 | 16:27 |
| Keybuk | emit tty-removed TTY=ttyS0 | 16:27 |
| Keybuk | the $TTY in the "stop on" is expanded at match time, against the $TTY variable stored in the job when it was started | 16:27 |
| Keybuk | (the variables in the job come from the start request, which is either explicit or the combination of the events) | 16:28 |
| Keybuk | I've also suggested there allowing the instance stanza to be expanded | 16:29 |
| Keybuk | this would provide the instance match | 16:29 |
| Keybuk | so you could have one instance of the getty job running for each unique value of the $TTY variable | 16:29 |
| Keybuk | if you did | 16:29 |
| Keybuk | start getty TTY=ttyS0 | 16:29 |
| Keybuk | start getty TTY=ttyS0 | 16:29 |
| Keybuk | the second one would fail with "already running" | 16:29 |
| Keybuk | (the $TTY in the exec is actually *NOT* undergoing upstart parameter expansion, the entire exec string is passed to a shell, so /bin/sh expands that with the environment) | 16:30 |
| Keybuk | the question is, what other stanzas should undergo parameter expansion? | 16:31 |
| ion_ | Right | 16:33 |
| sadmac_ | Keybuk: can start on use parameter matching? i.e. start on hal.have_tty TTY==ttyS0 ? | 16:36 |
| Keybuk | sadmac_: yes | 16:37 |
| Keybuk | though it's just TTY=ttyS0 | 16:37 |
| sadmac_ | cool. | 16:37 |
| Keybuk | (HAL is an entire WORLD of pain though) | 16:37 |
| Keybuk | do you know how difficult it would be to have an event or state to simply say, for any given HAL udi, "available"/"not available" ? :) | 16:38 |
| === kylem_ is now known as kylem | ||
| sadmac_ | "I'm sorry, Dave, but I'm afraid I can't do that" | 16:39 |
| Keybuk | something (and here's the problem already) would listen for org.freedesktop.Hal.Manager.DeviceAdded and DeviceRemoved signals | 16:42 |
| Keybuk | also NewCapability as well | 16:42 |
| Keybuk | those signals only contain the object ref, so are pretty useless | 16:42 |
| Keybuk | the something would then need to probe the device | 16:43 |
| Keybuk | so it needs to know in advance what kinds of devices it's actually looking for | 16:43 |
| Keybuk | as well as, for each device, listen for PropertyModified signals | 16:43 |
| Keybuk | ion_, sadmac: so, any comments? | 17:38 |
| ion_ | Not yet. Too tired for the synapses to fire. :-) | 17:39 |
| ion_ | Sounds good so far. | 17:39 |
| Keybuk | umask $UMASK | 17:40 |
| Keybuk | I don't think that kind of thing should be allowed | 17:40 |
| ion_ | I can’t think of a use case for that. | 17:41 |
| Keybuk | aye, me neither | 17:43 |
| Keybuk | I think the same applies for everything process-setup wise | 17:43 |
| Keybuk | so console, umask, nice, limit, chroot & chdir shouldn't be expanded either | 17:43 |
| Keybuk | if you reeeeally want that, after all, you can just call things in the script | 17:44 |
| ion_ | Indeed. | 17:44 |
| Keybuk | respawn related things like respawn timeout, kill timeout & normal exit don't make sense to me to be expanded | 17:44 |
| ion_ | Ack | 17:45 |
| Keybuk | which pretty much just leaves the newer things | 17:45 |
| Keybuk | "stop on" definitely makes sense to match against the events found by "start on" | 17:46 |
| Keybuk | so no argument there | 17:46 |
| Keybuk | and I think using it for instance limiting makes sense too | 17:46 |
| Keybuk | "uses" is about locking, so there is actually a use-case for it | 17:46 |
| Keybuk | start on block-device-added | 17:46 |
| Keybuk | uses $DEVICE | 17:46 |
| Keybuk | would be a job that locked out any other job using $DEVICE | 17:47 |
| ion_ | Is there a way to do something equivalent to /lib/udev/watershed’s functionality with ‘uses’ or something else? | 17:47 |
| Keybuk | something like that is an idea on the TODO list, yeah | 17:47 |
| Keybuk | the main difference between uses and watershed is that in the former, all jobs are queued | 17:48 |
| Keybuk | whereas with watershed, only one needs to be queued | 17:48 |
| ion_ | Yep | 17:48 |
| ion_ | Would be nice if watershed were in /bin, btw. :-) It’s useful outside udev as well. | 17:49 |
| * Keybuk is amused | 17:53 | |
| Keybuk | an English sci-fi magazine (SFX) did a summary of Peter Petrelli's powers, | 17:53 |
| Keybuk | working out who they came from, and what other ones he might possess by inference | 17:54 |
| ion_ | Heh | 17:54 |
| Keybuk | they first of all worked out that since his absorption appears instant, he will always have the upper hand on Sylar since the minute they meet, Peter will also have whatever other powers he's gained in the meantime | 17:54 |
| ion_ | Yep :-) | 17:55 |
| Keybuk | then they worked out that Peter's met the Haitian, so he must have the power to stop Sylar's powers whenever they meet | 17:55 |
| Keybuk | (unless the Haitian's power inherently stopped Peter from absorbing it -- possible writer loophole) | 17:55 |
| ion_ | Hehe | 17:55 |
| Keybuk | finally obviously Peter has met Hiro, and absorbed his powers | 17:55 |
| Keybuk | so all Peter needs to do is use Molly's powers (they met in S1 finale) to find everybody else | 17:56 |
| Keybuk | absorb all their powers | 17:56 |
| Keybuk | (quick and easy using teleportation) | 17:56 |
| Keybuk | and then go back in time, and meet himself | 17:56 |
| ion_ | :-) | 17:56 |
| Keybuk | thereby giving his younger self all the powers of everybody | 17:56 |
| ion_ | Heh | 17:56 |
| Keybuk | they suggested his might be unlikely, since it would give the writers a bit of a problem | 17:58 |
| ion_ | There’s a big fuss about some guy scripting a wireframe 3D cube in Excel™ <http://youtube.com/watch?v=vypETZbkU94> while we made a texturemapped raytraced tunnel in Excel™ four years ago <http://youtube.com/watch?v=_whSnPErl7c>. :-P | 18:00 |
| Keybuk | oops | 18:35 |
| Keybuk | it appears I've broken "respawn limit" | 18:35 |
| ion_ | No problem, it’s just a matter of adding a sufficient amount of hardware. | 18:38 |
| ion_ | (E.g. if whatever you execute forks and exits) | 18:39 |
| Keybuk | lol | 18:40 |
| sadmac_ | Keybuk: the counterstrike fans will prefer it this way | 18:40 |
| Keybuk | the bug is that the instances get cleaned up now | 18:40 |
| Keybuk | so if you stop; sleep 5; start ... the start won't be subject to any limit since the stop would have freed the struct that contains the count of how many times the instance has actually been started or stopped recently :) | 18:41 |
| Keybuk | it's also not immediately obvious to me whether a respawn limit is per job or per instance | 18:41 |
| Keybuk | e.g. dbus, it clearly doesn't matter since there can only be one | 18:42 |
| Keybuk | but getty, if you start 6 different gettys in quick succession, does that mean that the 6th fails to start? | 18:42 |
| Keybuk | or does it only apply should they attempt to respawn themselves? | 18:42 |
| sadmac_ | Keybuk: the latter. It is a REspawn limit | 18:42 |
| ion_ | Agreed. | 18:42 |
| Keybuk | but for a multi-instance job, you can start as many as you like very very quickly | 18:43 |
| Keybuk | should it apply to them? | 18:43 |
| Keybuk | *shrug* | 18:43 |
| sadmac_ | Keybuk: no. If we need that functionality we need a separate feature for it | 18:43 |
| Keybuk | I guess that respawn limit is useful if it just catches a job that's runaway respawning] | 18:43 |
| Keybuk | ie. dying and resurrecting over and over again very quickly | 18:43 |
| sadmac_ | "instance count" or such | 18:43 |
| Keybuk | in which case you actually don't want it to catch a restarting job | 18:44 |
| Keybuk | or new job | 18:44 |
| Keybuk | (manual restart, that is) | 18:44 |
| Keybuk | if you do; | 18:44 |
| Keybuk | while true; do stop --no-wait dbus; start --no-wait dbus; done | 18:44 |
| Keybuk | then I guess that technically *shouldn't* trigger the respawn limit, since the request is external | 18:45 |
| ion_ | Yep. | 18:45 |
| ion_ | The user requested it to do something stupid instead of there being a problem. :-) | 18:45 |
| sadmac_ | You need it to keep the automated behavior from breaking things. If the admin breaks it its not upstart's business | 18:45 |
| sadmac_ | what happens when respawn limit is hit? Does it retry after some time? | 18:46 |
| Keybuk | no, stops the job | 18:46 |
| sadmac_ | yeah, makes sense. | 18:46 |
| * sadmac_ thinks about adding exponential backoff for jobs that contend on resources. | 18:47 | |
| * sadmac_ hits himself with a stapler | 18:47 | |
| ion_ | Oh, i didn’t know you’re into that. | 18:47 |
| sadmac_ | ion_: collision recovery? | 18:48 |
| ion_ | selfstapling | 18:48 |
| sadmac_ | ion_: yeah. office supplies make me feel like more of a man. | 18:49 |
| sadmac_ | Keybuk: I've been thinking about a potential new stanza called "expect" Where you could specify a way to tell that the service is ready | 18:50 |
| ion_ | Isn’t the post-start script sufficient? | 18:50 |
| sadmac_ | ion_: not always. some services are dumb and there's no clean way to do it in bash. | 18:51 |
| Keybuk | sadmac_: what kind of thing would we put there? | 18:52 |
| sadmac_ | Keybuk: "expect sigstop" for services that will stop themselves when prepped, "expect file /path" for services that are ready when a file appears (presumably a named pipe or unix domain socket) | 18:52 |
| sadmac_ | Keybuk: you can even (and this is scary) do a bit more ptrace magic. "expect syscall_listen" | 18:53 |
| Keybuk | pretty much like the "wait for" in trunk then? :) | 18:55 |
| Keybuk | wait for signal | 18:55 |
| Keybuk | wait for fork | 18:55 |
| Keybuk | wait for daemon | 18:55 |
| sadmac_ | ah. | 18:55 |
| Keybuk | I'd planned to extend that to wait for a dbus name | 18:55 |
| Keybuk | the listen() is kinda cool, though I'm not sure how easy that would be to trap | 18:55 |
| sadmac_ | Keybuk: wait for file would also be useful. rhgb is ready when a certain pts device appears. | 18:56 |
| sadmac_ | wait for file /dev/pts/0 | 18:56 |
| sadmac_ | what's different between wait for fork and wait for daemon? | 18:57 |
| Keybuk | one waits for a single fork() | 18:58 |
| Keybuk | the other waits for a double fork() | 18:59 |
| sadmac_ | hm | 19:00 |
| sadmac_ | Keybuk: how hard would it be to get arguments/environment variables persistent across respawns in 0.3.9? | 19:02 |
| sadmac_ | Its becoming kind of a major issue | 19:02 |
| Keybuk | I really don't understand why that is an issue | 19:03 |
| Keybuk | sysvinit doesn't even *have* this | 19:03 |
| Keybuk | so if you're only trying to replace sysvinit, why are you using events at all? | 19:03 |
| sadmac_ | Because we had something really ugly that's going to be easier to do the right way than it is to rebuild in upstart. | 19:03 |
| Keybuk | I'm still unclear what you're actually trying to do :-/ | 19:05 |
| sadmac_ | Keybuk: we want upstart to run agetty every time a serial console becomes available | 19:06 |
| Keybuk | any serial console? | 19:07 |
| Keybuk | you run getty on all serial ports? | 19:07 |
| sadmac_ | any serial console | 19:07 |
| sadmac_ | Keybuk: there's a nearly infinite potential number | 19:07 |
| Keybuk | right | 19:07 |
| Keybuk | so you're using an instance job? | 19:07 |
| sadmac_ | In effect I suppose | 19:08 |
| sadmac_ | oh | 19:08 |
| sadmac_ | that would be an issue. | 19:08 |
| Keybuk | you know you can only start one job once, right? :) | 19:08 |
| Keybuk | start getty | 19:08 |
| Keybuk | ... ok | 19:08 |
| Keybuk | start getty | 19:08 |
| Keybuk | ... already running | 19:08 |
| Keybuk | so you could only have one getty at a time with your job file anyway | 19:08 |
| Keybuk | start on fedora.serial-console-available * | 19:09 |
| Keybuk | 19:09 | |
| Keybuk | stop on runlevel [016] | 19:09 |
| Keybuk | respawn | 19:09 |
| Keybuk | exec /sbin/agetty /dev/$1 $2 vt100-nav | 19:09 |
| Keybuk | (stealing from your bugzilla) | 19:09 |
| Keybuk | won't work, since only one instance of that can run at a time | 19:09 |
| Keybuk | (the "*" is kinda unnecessary too, btw) | 19:10 |
| sadmac_ | this I'm just realizing | 19:10 |
| Keybuk | want an ugly way to fix it? :) | 19:10 |
| Keybuk | start on fedora.serial-console-available | 19:10 |
| Keybuk | instance | 19:10 |
| Keybuk | stop on runlevel [016] | 19:10 |
| Keybuk | exec /sbin/agetty /dev/$1 $2 vt100-nav | 19:11 |
| Keybuk | post-stop exec initctl emit fedora.serial-console-available $1 $2 | 19:11 |
| * Keybuk grins | 19:11 | |
| Keybuk | though that would respawn forever, ignoring the "stop on" bit | 19:12 |
| sadmac_ | oh, instance jobs are in 0.3.9? | 19:12 |
| Keybuk | yeah | 19:12 |
| Keybuk | start on fedora.serial-console-available | 19:12 |
| sadmac_ | I thought that was still trunk only | 19:12 |
| Keybuk | stop on runlevel [016] | 19:12 |
| Keybuk | instance | 19:12 |
| Keybuk | exec /sbin/agetty /dev/$1 $2 vt100-nav | 19:12 |
| Keybuk | pre-stop script | 19:12 |
| Keybuk | touch /tmp/ok-to-respawn-$1 | 19:12 |
| Keybuk | end script | 19:12 |
| Keybuk | post-stop script | 19:13 |
| Keybuk | [ -f /tmp/ok-to-respawn $1 ] || exit 0 | 19:13 |
| Keybuk | initctl emit fedora.serial-console-available $1 $2 | 19:13 |
| Keybuk | rm -f /tmp/ok-to-respawn | 19:13 |
| Keybuk | end script | 19:13 |
| Keybuk | (using the fact that pre-stop won't be run if the getty stops unnaturally) | 19:13 |
| Keybuk | and fix my obvious bugs of the ok-to-respawn filename :p | 19:15 |
| sadmac_ | It needs to respawn in that case too. | 19:15 |
| Keybuk | ? | 19:16 |
| Keybuk | oh, I have the logic backwards | 19:16 |
| Keybuk | should be do-not-respawn :p | 19:16 |
| sadmac_ | Its making sense now. | 19:16 |
| Keybuk | it's a hack, I know | 19:22 |
| Keybuk | but it will suffice | 19:22 |
| Keybuk | in trunk, the job would be somewhat simpler | 19:22 |
| sadmac_ | Keybuk: do you want to post that to bugzilla or should I? | 19:22 |
| Keybuk | already done | 19:23 |
| sadmac_ | cool | 19:23 |
| Keybuk | start on fedora.serial-console-available | 19:23 |
| Keybuk | stop on runlevel [016] or fedora.serial-console-gone $TTY | 19:23 |
| Keybuk | instance $TTY | 19:23 |
| Keybuk | respawn | 19:23 |
| Keybuk | exec /sbin/agetty /dev/$TTY $BAUD vt100-nav | 19:23 |
| Keybuk | -- | 19:23 |
| Keybuk | you might even stick | 19:23 |
| Keybuk | env BAUD=38400 | 19:23 |
| sadmac_ | Keybuk: the big ugly in the 0.3.9 one is explicitly running /sbin/stop won't do anything | 19:24 |
| Keybuk | in there so you don't have to supply $BAUD to start if you don't want to | 19:24 |
| Keybuk | sadmac_: how do you mean? | 19:24 |
| sadmac_ | Keybuk: never mind | 19:24 |
| Keybuk | running stop in a job script kinda hangs? :p | 19:24 |
| sadmac_ | Keybuk: I was following the logic wrong | 19:25 |
| ion_ | sadmac: http://gitweb.heh.fi/?p=ion/wait-for-file.git;a=blob;f=wait-for-file.c;hb=master | 19:43 |
| sadmac_ | Interesting | 19:44 |
| sadmac_ | ion_: I already have an inotifywait+bashism solution. | 19:45 |
| sadmac_ | though this might be better | 19:45 |
| ion_ | With a race condition. :-) | 19:45 |
| sadmac_ | ion_: ah, you were there | 19:45 |
| ion_ | I specifically open the inotify watch first, then check whether the file exists and decide whether to begin waiting for the appropriate inotify event. | 19:45 |
| sadmac_ | Hmm, I could build this in event-compat-sysv I suppose. | 19:46 |
| ion_ | (I’m tired, there may very well be something wrong with the code. I did some quick testing and valgrinding and it seems to work.) | 19:47 |
| sadmac_ | cool :) | 19:47 |
| sadmac_ | ion_: thanks | 19:47 |
| ion_ | np | 19:47 |
| sadmac_ | ion_: is there a git:// url for this? | 19:48 |
| ion_ | http://gitweb.heh.fi/?p=ion/wait-for-file.git shows it: git://heh.fi/ion/wait-for-file.git | 19:50 |
| sadmac_ | cool | 19:51 |
| Keybuk | http://bazaar.launchpad.net/~keybuk/upstart/trunk/revision/scott%40netsplit.com-20080307213253-zd7x3w606y947zoj?start_revid=scott%40netsplit.com-20080307213253-zd7x3w606y947zoj | 21:30 |
| Keybuk | \o/ | 21:30 |
| ion_ | \o\ | 21:31 |
| Keybuk | o o o o o <o <o> o> o | 21:32 |
| Keybuk | .|. \|. \|/ // X \ | <| <|> | 21:32 |
| Keybuk | /\ >\ /< >\ /< >\ /< >\ /< | 21:32 |
| ion_ | ^ ^ | 21:32 |
| ion_ | 21:32 | |
| ion_ | _ | 21:32 |
| sadmac__ | pimp | 21:39 |
| === sadmac__ is now known as sadmac | ||
| sadmac | (^-_-^) <( -_-<) (>-_- )> (V-_-v) | 21:42 |
| ion_ | Did you know that your nick reversed is cadmas? | 21:42 |
| sadmac | ion_: actually its camdas | 21:42 |
| ion_ | No, i reject that. | 21:42 |
| sadmac | ion_: kernel panic - not syncing: total ordering property assertion failed | 21:43 |
| * ion_ considers going to maintenance mode. | 21:44 | |
| sadmac | ion_: you can only fix code problems and configuration problems that way. It doesn't help you when math is broken. | 21:45 |
| sadmac | Keybuk: so what else is outstanding? | 21:49 |
| ion_ | Bug #1 for one. | 21:50 |
| Keybuk | sadmac: still a few bits for an 0.5.0 | 21:52 |
| Keybuk | name-limited instances | 21:52 |
| Keybuk | and obviously D-BUS, which will involve rewriting initctl | 21:52 |
| Keybuk | other 0.5 bits can then come after the release | 21:52 |
| sadmac | Keybuk: what's with name-limited instances? | 21:53 |
| Keybuk | so at the moment, there are two possibilities | 21:53 |
| Keybuk | a job may only have one instance (the default) | 21:53 |
| Keybuk | if you attempt to start when already started, you'll just get an error | 21:53 |
| Keybuk | OR | 21:53 |
| Keybuk | a job may have unlimited instances ("instance") | 21:53 |
| Keybuk | if you attempt to start, you'll always get another job | 21:53 |
| Keybuk | I want to add a third | 21:53 |
| Keybuk | a job may have a limited number of instances, each identified by a unique name | 21:54 |
| Keybuk | ("instance $TTY") | 21:54 |
| sadmac | ahh | 21:54 |
| Keybuk | if you attempt to start, it may start a new job OR fail because it's already started, depending on the value of $TTY you give | 21:54 |
| Keybuk | that means, for example, that if you have a job like: | 21:54 |
| Keybuk | start on tty-added | 21:55 |
| Keybuk | stop on tty-removed $TTY | 21:55 |
| Keybuk | instance $TTY | 21:55 |
| Keybuk | and you very quickly do | 21:55 |
| Keybuk | initctl emit --no-wait tty-added TTY=ttyS0 | 21:55 |
| Keybuk | initctl emit --no-wait tty-removed TTY=ttyS0 | 21:55 |
| Keybuk | initctl emit --no-wait tty-added TTY=ttyS0 | 21:55 |
| Keybuk | that will cause the *existing* instance to be restarted, rather than spawn a new one | 21:55 |
| sadmac | ha | 21:55 |
| sadmac | so for tomcat, say.... | 21:56 |
| sadmac | the tomcat instances might be named after the apps they are running | 21:56 |
| Keybuk | right | 21:56 |
| Keybuk | it's also the basis for an interesting way to permit multiple instances of things like apache | 21:57 |
| Keybuk | instance $CONFFILE | 21:57 |
| sadmac | hm | 21:57 |
| Keybuk | exec apache2 -f $CONFFILE | 21:57 |
| Keybuk | for example | 21:57 |
| ion_ | If i want to start such instances automatically on startup based on a list of apps in /etc/something, would i need another job to start those ones? | 21:57 |
| Keybuk | that'd let you start as many instances as apache2 as you had conffiles | 21:58 |
| Keybuk | ion_: only until we have file eventts | 21:58 |
| ion_ | Ah, right. They’ll be a nice solution to that. | 21:58 |
| sadmac | Keybuk: this is really important for the user session case | 21:59 |
| sadmac | instance $SOMESESSIONUNIQUEPROPERTY | 21:59 |
| Keybuk | yeah, you can be quite arbitrary | 22:00 |
| Keybuk | instance $USER-$TTY-$BAUD-$FOO | 22:00 |
| Keybuk | etc. | 22:00 |
| Keybuk | that's why I decided to just expand environment there | 22:00 |
| Keybuk | instance ${TTY:-notatty} | 22:00 |
| ion_ | Nice | 22:00 |
| * Keybuk had fun writing that | 22:00 | |
| sadmac | Keybuk: you're going to want to talk about this to the PolicyKit folk | 22:01 |
| Keybuk | If by "the PolicyKit folk", you mean davidz? ... :) | 22:01 |
| ion_ | No, he’s now DavidKit. | 22:01 |
| sadmac | ion_: I still have the original david, its not kit built | 22:02 |
| Keybuk | sadmac: I talk to david a fair amount | 22:02 |
| sadmac | Keybuk: ah, cool | 22:02 |
| sadmac | I'd imagine it will get interesting once we need policies around starting and stopping jobs for per-session tasks | 22:02 |
| sadmac | DBus will probably give us a lot of that for cheap though. | 22:04 |
| Keybuk | the trouble with Upstart is a tendancy for people to try and fix all their problems at once with it | 22:04 |
| Keybuk | including myself | 22:04 |
| sadmac | Keybuk: 0.5 will be able to simonize my car, right? | 22:04 |
| Keybuk | user sessions are easy in Upstart, since a user session is just a collection of environment variables to set | 22:04 |
| Keybuk | "simonize" ? | 22:04 |
| sadmac | Its a fancy waxing job that I could be misspelling | 22:05 |
| ion_ | dict(1) knows simonize. :-) | 22:05 |
| Keybuk | well, obviously misspelling since it should be "simonise" ;) | 22:05 |
| ion_ | :-D | 22:05 |
| * sadmac just got britished | 22:05 | |
| ion_ | Britised, you mean. | 22:05 |
| Keybuk | not our fault you guys aren't keeping up with the updates to the language you're using ;) | 22:05 |
| * sadmac git pull english | 22:06 | |
| Keybuk | (actually -ize vs. -ise is a long standing division between the major two British dictionary presses, but I digress) | 22:06 |
| sadmac | I was really surprised when I found out you guys had an extra vowel in "Alumin[i]um." I just thought it was creative pronounciation. | 22:07 |
| ion_ | In which dialect do you pronounce pronunciation pronounciation? :-) | 22:10 |
| sadmac | ion_: good question | 22:11 |
| sadmac | pronounciation (n): The act of making something into a pronoun. | 22:14 |
| ion_ | In Finnish, pronoun is pronomini, but noun is substantiivi. | 22:16 |
| sadmac | hm | 22:20 |
| sadmac | prosubstantiivi | 22:20 |
| sadmac | ^^If that's edible, I want some. | 22:20 |
| ion_ | No, but you can take it intravenously. | 22:22 |
| sadmac | what's it do | 22:22 |
| sadmac | ? | 22:22 |
| ion_ | It puts your mind to a state where you experience being on IRC, usually on #upstart@Freenode, and you have very vivid hallucinations about other people talking with you online. | 22:25 |
| sadmac | Is Julia Child there? | 22:26 |
| ion_ | You’ll have to ask her. | 22:27 |
| * sadmac expands his mind | 22:29 | |
| Keybuk | http://bazaar.launchpad.net/~keybuk/upstart/trunk/revision/scott%40netsplit.com-20080307232034-k4dlc4humlxubprd?start_revid=scott%40netsplit.com-20080307232050-9u2sj8ld588t441q | 23:18 |
| Keybuk | ^ name-limited-instance support | 23:19 |
| sadmac | Keybuk: so that leaves DBus. | 23:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!