[01:53] <Arafangion> Hey guys, how do I send an event whenever my eth0 becomes up?
[01:56] <Keybuk> hello
[01:56] <Keybuk> Arafangion: initctl emit
[01:56] <Keybuk> (simple answer)
[01:56] <Arafangion> Keybuk: yes, where exactly do I put that?
[01:57] <Arafangion> My networking job does '/sbin/ip link set eth0 up', but it is only some time later that eth0 actually becomes up.
[01:57] <Keybuk> Arafangion: I cannot answer that question without detailed knowledge of how your distro of choice manages its network interfaces
[01:57] <Arafangion> Keybuk: It's custom, without sysv compatibility.
[01:58] <Keybuk> then only you can answer that question
[01:58] <Keybuk> you might have something like Network Manager
[01:58] <Keybuk> or at least HAL or udev
[01:58] <Arafangion> Keybuk: I have udev, I have yet to install HAL.
[01:58] <Arafangion> Do I need HAL?
[01:58] <Keybuk> udev would tell you when the interface comes UP
[01:59] <Arafangion> Would udev be able to send the event?
[01:59] <Keybuk> that wouldn't tell you whether it was configured or not
[01:59] <Keybuk> only something like Network Manager could tell you that
[01:59] <Arafangion> Hmm, so I'd pretty well need to setup HAL, and write a custom script to manage that?
[01:00] <Arafangion> For now, I suppose I'll have to make do with a sleep 2 in the networking script.
[01:00] <Keybuk> a Utopian Upstart install would look something like:
[01:01] <Keybuk>   Upstart as init
[01:01] <Keybuk>   D-BUS for IPC
[01:01] <Keybuk>   udev for kernel user-space management
[01:01] <Keybuk>   HAL for application management
[01:01] <Keybuk>   Network Manager dealing with network interfaces
[01:01] <Keybuk>   GNOME Power Manager dealing with ACPI/APM
[01:01] <Arafangion> I'll be doing something very similar. :)
[01:02] <Keybuk> we haven't figured out all the bits yet
[01:03] <Arafangion> Must be why the documentation is a bit sparse in some places. :)
[01:03] <Keybuk> exactly
[01:04] <Keybuk> Upstart 0.3 is, at best, a technology prototype/demo
[01:05] <Arafangion> I'm using upstart 0.3.8, with the install slightly patched to prevent broken symlinks.
[01:05] <Keybuk> 0.3.9 fixes that, no?
[01:05] <Arafangion> Hopefully. ;)
[01:06] <Arafangion> But it wasn't fixed in 0.3.8, which was the version that was up-to-date when I tried it. :)
[01:06] <Keybuk> you're using program-prefix/suffix/transform and the symlinks aren't transformed
[01:06] <Arafangion> What?
[01:06] <Keybuk> ?
[01:07] <Arafangion> No, just two symbolic links that deal with sysv compatibility was created regardless of sysv compatibility being enabled or not.
[01:07] <Arafangion> A minor thing, really.
[01:07] <Keybuk> oh
[01:07] <Keybuk> I think that's fixed in 0.3.9 too
[01:07] <Keybuk> yes
[01:07] <Arafangion> Cool. :)
[01:08] <Arafangion> Maybe in a few months, I'll backup and check out the latest version of upstart. :)
[01:08] <Arafangion> I'm aiming to have a /very/ nice boot sequence.
[01:08] <Arafangion> (It's a laptop)
[01:09] <Arafangion> My major fault with upstart so far is the diagnostics are a bit... raw.
[01:10] <Arafangion> If I add a new job to /etc/events.d, it complains about 'init: //etc/event.d/foo: unable to read: Invalid argument', without really giving me much more info.
[01:10] <Arafangion> Also seems to refer to a mythical /etc/event.d/4913, as well.
[01:11] <Keybuk> vim
[01:11] <Keybuk> it always makes a file called 4913 in whatever directory you're editing files
[01:11] <Keybuk> so Upstart thinks it's a job
[01:12] <Keybuk> and what other info do you expect there?
[01:12] <Keybuk> That's all the info Upstart *has*
[01:12] <Keybuk> it tried to read a file, and it got EINVAL
[01:12] <Keybuk> though that's a bug :)
[01:12] <Keybuk>        EINVAL (since Linux 2.6.12), length was 0.
[01:12] <Keybuk> you should file that <g>
[01:12] <Arafangion> Heh. :)
[01:13] <Arafangion> I may be a dev, but I'm a *user* here. ;)
[01:13] <Arafangion> Still, it's complaining about /two/ files, really.
[01:14] <Arafangion> Perhaps a fix would be an upedit command, which makes a copy of the job in /tmp, then edits it with the preferred editor.
[01:14] <Keybuk> or just don't use vim :)
[01:14] <Arafangion> DIE!
[01:14] <Keybuk> it's not really an issue
[01:14] <Keybuk> since it'll read it properly in the end anyway
[01:14] <Keybuk> it just tends to bitch a bit along the way
[01:15] <Arafangion> It just makes things a bit confusing for us mortals. :(
[01:16] <Arafangion> I must say I've been rather impressed with the design of upstart, nice and small, and simple.
[01:16] <Arafangion> That reminds me - how _do_ I get upstart to log itself verbositely to a file?
[01:16] <Keybuk> for things like that, I'd just rather fix the underlying problem
[01:17] <Keybuk> you can't
[01:17] <Keybuk> there's generally no filesystem to log *to* :-)
[01:17] <Arafangion> Well, it generally logs already, and that can be redirected, but how do I specify '-v' to init?
[01:18] <Keybuk> kernel command line
[01:18] <Keybuk> you can give it --debug too for even more
[01:18] <Arafangion> So, I do init=/sbin/init -v"
[01:19] <Arafangion> ?
[01:19] <Arafangion> But how would -v become associated with the init parameter?
[01:20] <ion_> Just add plain -v to the kernel command line.
[01:21] <Keybuk> init=/sbin/init -v
[01:21] <Arafangion> ion_: And that wouldn't conflict with any other parameters any other programs want?
[01:21] <Keybuk> kernel passes all parameters to init
[01:21] <Arafangion> Or is init always the last parameter?
[01:21] <Arafangion> Ahh, I see.
[01:22] <Arafangion> How come I haven't recieved my mail to the udev mailing list?
[01:22] <Arafangion> *upstart, not udev*
[01:23] <Keybuk> are you subscribed to the list?
[01:24] <Arafangion> I believe so.
[01:24] <Arafangion> And I've responded to the latest email sent on that list.
[01:24] <Arafangion> upstart-devel
[01:26] <Keybuk> it didn't hit the moderator queue
[01:28] <Arafangion> Was it blocked?
[01:28] <Arafangion> Oh, *sigh*.
 mail client.
[01:28] <Arafangion> Is the default reply to the user, nto the list?
[01:30] <Arafangion> Hmm, evidently.
[01:40] <Keybuk> user
[01:44] <Arafangion> Hmm, it's quite a moderated list. :)
[01:44] <Arafangion> Probably wise.
[01:48] <Keybuk> it's not moderated
[01:48] <Keybuk> just limited to subscribers
[01:48] <Arafangion> Well, it says:     Post by non-member to a members-only list
[01:48] <Arafangion> yet I'm obviously a subscriber, since I recieved the email in the first place.
[01:49] <Arafangion> Oh, my mistake.
[01:49]  * Arafangion used a different email address.
[01:50]  * Arafangion is feeling very 'newbie' today. :(
[01:53] <Keybuk> I can accept that one
[01:55] <Arafangion> I do find it rather peculiar that ubuntu does not seem to use upstart's extra features - it's still entirely in sysv compatibility? (That correct?)
[01:57] <Keybuk> right
[01:59] <Keybuk> that's correct
[01:59] <Keybuk> why peculiar?
[02:00] <Arafangion> Because I seem to suspect that the only reason why ubuntu wanted upstart was becuase "nothing else was good enough", yet they still do everything the same way.
[02:01] <Keybuk> Upstart's still being developed
[02:03] <Arafangion> Yes, there's that, I guess I'm just used to Debian. If it were debian, it'd already be starting to be integrated into the main distro properly, imho.
[02:03] <Arafangion> Not stable, mind you, it'd be in testing or unstable. ;)
[02:05] <Keybuk> not true
[02:06] <Keybuk> you can't integrate something unfinished
[02:06] <Keybuk> you have to finish it first
[02:06] <Keybuk> especially if the bits that aren't finished are the bits that let you integrate it
[02:07] <Arafangion> That's what unstable and experimental are for. ;)
[02:07] <Arafangion> What are the current showstoppers for upstart, though?
[02:09] <Keybuk> no
[02:09] <Keybuk> unstable is for packages intended for release
[02:09] <Keybuk> you wouldn't put something there that simply doesn't boot
[02:10] <Keybuk> experimental, perhaps
[02:10] <Keybuk> but that's just a playground
[02:10] <Keybuk> main showstopper is that it's not possible to develop complex interdependencies between jobs
[02:10] <Keybuk> or relate those to hardware
[02:10] <Arafangion> What's an example of such a complex interdependency?
 Hey guys, how do I send an event whenever my eth0 becomes up?
[02:11] <Keybuk> for example
[02:11] <Keybuk> :p
[02:13] <Arafangion> Heh, but arguably, it should be sufficient to have udev start a script that then does some monitoring, though it would indeed be even nicer if that was part of the job itself, as perhaps another stanza.
[02:15] <Keybuk> udev shouldn't start things like that
[02:15] <Keybuk> it's a daemon for getting devices created
[02:15] <Keybuk> not a device manager
[02:15] <Arafangion> Perhaps, but it already has the functionality.
[02:16] <Keybuk> no, it doesn't
[02:16] <Arafangion> And to do what I wanted with eth0, you need the signal from udev anyway, so udev's already a requirement.
[02:16] <Arafangion> It doesn't?
[02:16] <Keybuk> not true
[02:16] <Keybuk> you want to use HAL
[02:16] <Arafangion> run+="foobar"?
[02:16] <Arafangion> Hmm.
[02:16] <Keybuk> how do you stop foobar?
[02:18] <Arafangion> Good question.
[12:26] <Jc2k> ooh thats magic
[12:27] <Keybuk> hmm?
[12:27] <Jc2k>  [i=scott@conference/ubuntu-developer-summit/x-23c3b871e5ad4e13]
[12:27] <Keybuk> yeah, it's a Cloak
[12:27] <Keybuk> we're all at the same IP address, so FreeNode would k-line us for "cloning" otherwise
[12:28] <Keybuk> so we tell them that we're at a conference, and they add a magic cloak
[12:28] <Jc2k> i c :)
[12:28] <Jc2k> oh well, back to sync coding.
[12:29] <Jc2k> my BDFL wants to drum up some attention at UDS with pretty Planet Gnome posts..
[12:32] <Jc2k> holy cow. seems conduit is on the board of topics...
[12:32]  * Jc2k works harder