[05:35] <telexicon> if i wanted to port a sysvinit script to upstart, is there a page documenting how to do this?
[08:37] <keesj> hi
[08:38] <keesj> telexicon: does the script do the stantard start/stop/restart stuff?
[08:39] <telexicon> yes
[08:40] <keesj> I am pretty new to this but what I do is write a very simple job "start on start-myservice , stop on stop-myservice" and put the exec in there
[08:40] <keesj> let me find a simple sample
[08:41] <telexicon> it'd be nice if there were a few non-trivial examples on the wiki at least
[08:41] <telexicon> for making scripts for daemons or something
[08:43] <keesj> http://paste-it.net/7198/raw/
[08:44] <keesj> after that I "emit start-myservice"
[08:45] <keesj> but I agree that there is room for improvement in the docs and specialy examples
[08:46] <keesj> I would really like a non sysv example.
[08:46] <telexicon> ah ok
[08:46] <telexicon> well id like to see converting a standard sysv init script to an equivalent upstart form
[08:47] <keesj> telexicon: the thing really is that the guts of sysv are in the file called inittab , there are the read progams that get started and stopped at a special runlevel
[08:47] <keesj> the "rc" scripts are really implemented differently by every distro.
[08:48] <telexicon> ok
[08:48] <telexicon> but ubuntu has done away with inittab
[08:49] <keesj> telexicon: yes ,while ubuntu uses upstart it uses a "sysv" like implmentations that emulates the old system
[08:50] <keesj> if you have a ubuntu system running you can look in /etc/event.d/ and grep for inittab to see the "hacks"
[08:52] <keesj> I am implmenting a state machine based system atm(something like the runlevels but with more possible transitions between the levels)
[08:53] <keesj> in other words i am experimenting :PO
[08:53] <telexicon> ah
[08:54] <keesj> I think that what I would like is to have more conventions something like  /etc/upstart/services/[myservice]
[08:55] <keesj> and that by default I can call emit myservice-start
[08:56] <keesj> everything is a job in upstart therms. perhaps it is better to wait for somebody with more knowlegde 
[14:04] <keesj> OK , I have my next interesting problem :p
[14:05] <keesj> I  have an init script that starts two commands in the background and I want to convert that one to "one or tree" jobs
[14:05] <keesj> I really wonder how...
[14:06] <keesj> is that /etc/upstart/services/[myservice]
[14:06] <keesj> a good idea anyway?
[14:07] <keesj> or can a jobs have multiple exec's?
[14:09] <Keybuk> err
[14:09] <Keybuk> I'm not sure what you mean
[14:09] <Keybuk> can you be more verbose?
[14:50] <keesj> I am trying to replace some old init scripts that performed start_a & start_b &  (if stop killall a killall b)
[14:51] <keesj> I kinda like the idea that a service can consit of multiple processes (like the nfs/portmap hell)
[14:52] <keesj> \
[14:52] <Keybuk> shouldn't they be multiple services?
[14:53] <Keybuk> what benefit would there be for having them as one
[14:53] <Keybuk> you need portmap for things other than nfs, for example, so it needs a separate lifecycle
[14:54] <keesj> perhaps , I like the idea of being able to star "something" and don't want to know that that something actualy consist of multiple parts
[14:54] <Keybuk> right
[14:54] <Keybuk> but that can be done with events, where each part starts something else?
[14:54] <Keybuk> e.g. "start dbus" causes all dbus services like NM to start
[14:55] <keesj> Yes , I think that that would be valid
[14:57] <keesj> how about the /etc/upstart/services/[myservice] idea
[14:58] <keesj> or actualy whould/should it be possible to have a "start script and a stop script?
[14:58] <Keybuk> it is possible
[14:58] <Keybuk> if you have /etc/event.d/foo
[14:58] <Keybuk> then you can do "start foo" and "stop foo"
[14:59] <keesj> "emit start foo"
[15:01] <keesj> initctl start foo
[15:01] <Keybuk> the latter, not the former
[15:01] <Keybuk> emit is for making events
[15:01] <Keybuk> start/stop are for starting and stopping jobs
[15:02] <Keybuk> events can, of course, start and stop jobs
[15:02] <Keybuk> but there's a more direct way
[15:03] <keesj> the symlink trics also works  (BTW) so creating a symlink start to initctl
[15:03] <keesj> Keybuk: I am holding my breath
[15:03] <Keybuk> yes
[15:04] <Keybuk> make install will do that for you
[15:10] <keesj> hmm yes, I would love the split the even listener and the services, perhaps just giving them an extention is a good (and compatible) start
[15:13] <keesj> FYI this is a part of my "change_handler/state_machine" http://paste-it.net/b33db14/raw/
[15:43] <Keybuk> err, what does that do?
[15:43] <Keybuk> --
[15:43] <Keybuk> the way I'd do NFS/portmap would be to have an nfs-server service that starts the actual nfs server
[15:43] <Keybuk> and in portmap have
[15:43] <Keybuk>    start on starting nfs-servre
[15:43] <Keybuk> so if you "start nfs-server" you get portmap
[15:43] <Keybuk> --
[17:42]  * Keybuk cannot figure out what the buggering bollocks a D-Bus VTable is
[17:43] <ion_> Must be somehow related to D-Bus flicking you the Vs.
[17:47] <Keybuk> it's a pointer which is typedef'd to a struct that appears to be internal to D-Bus
[18:22] <Keybuk> *sigh*
[18:22] <Keybuk> my test suite continues its long-standing tradition of finding bugs in other people's software
[18:22] <Keybuk> dbus has this function that tells you whether data is remaining to be dispatched
[18:22] <Keybuk> so assumedly you do:
[18:23] <Keybuk>   while (dbus_connection_get_dispatch_status (conn) == DBUS_DISPATCH_DATA_REMAINS)
[18:23] <Keybuk>           dbus_connection_dispatch (conn);
[18:23] <Keybuk> except it turns out that data_remains can be true if there are unparsed bytes in there too
[18:24] <Keybuk> so you'll be in a loop
[18:24] <Keybuk> and since dispatch doesn't read(), it'll loop forever
[18:24] <ion_> Heh
[18:24] <Keybuk> if you only call dispatch() once, it will only dispatch one message, and will sit at select() for the next incoming message
[18:37] <Keybuk> actually, I can shorten that still :)
[18:37] <Keybuk> while (dbus_connection_dispatch (conn) != DBUS_DISPATCH_DATA_REMAINS)
[18:37] <Keybuk>  ;
[18:40] <Keybuk> that seems to cure the problem, in fact
[18:40] <ion_> Nice
[18:53] <keesj> Keybuk: the upstart code and nih looks very nice indeed.
[18:54] <keesj> what kind of tests are you talking about (I also saw a post/news about it)
[18:56] <Keybuk> look under the nih/tests and init/tests directories
[18:56] <Keybuk> or just run "make check"
[18:58] <keesj> thanks
[20:01] <sadmac_> Keybuk: so, what was your final answer wrt the license for the example jobs?
[20:01] <Keybuk> sadmac_: MIT/X11
[20:03] <Keybuk> http://upstart.ubuntu.com/download/example-jobs/COPYING
[20:04] <sadmac_> cool
[20:06] <Keybuk> 203             if (! dbus_bus_register (conn, &error)) {
[20:06] <Keybuk> (gdb) n
[20:06] <Keybuk> 204                     nih_dbus_error_raise (&error);
[20:06] <Keybuk> (gdb) p error.name
[20:06] <Keybuk> $2 = 0x2b367a0d0be8 "org.freedesktop.DBus.Error.NoMemory"
[20:06] <Keybuk> (gdb) p error.message
[20:06] <Keybuk> $3 = 0x2b367a0d5600 "Not enough memory"
[20:06] <Keybuk> weird
[20:07] <Keybuk> oh
[20:07] <Keybuk> just a silly error
[20:07] <Keybuk> it seems it always adds watches and timeouts to the main loop
[20:07] <Keybuk> even if you just want it to block
[20:07] <Keybuk> (multi-thread safe I guess)
[20:13] <sadmac_> Keybuk: using the dbus C api I see.
[20:14] <sadmac_> Keybuk: good. DBus cannot become an excuse for GObject.
[20:14] <Keybuk> indeed
[20:14] <sadmac_> *shudder*
[20:14] <Keybuk> GObject is wrong
[20:14] <Keybuk> and the dbus bindings to it are actually just as weong
[20:15] <Keybuk> quest nih% ./test_dbus 
[20:15] <Keybuk> :1.183
[20:15] <Keybuk> \m/
[20:15] <Keybuk> I have achieved ... A CONNECTION!
[20:15] <sadmac_> Keybuk: my initial attemt at writing a little /etc/rc replacement was previously done by someone else with GObject. It was 1/3 the way to working and probably had more code than upstart.
[20:15] <Keybuk> :p
[20:15] <sadmac_> whee
[20:16] <AlexExtreme> last time I used GObject it made me want to kill every single glib developer
[20:16] <AlexExtreme> in fact, i often get that feeling just using glib
[20:18] <sadmac_> AlexExtreme: I often get that feeling just laying awake at night
[20:18] <AlexExtreme> haha
[20:20] <Keybuk> *** 
[20:20] <Keybuk> *** #upstart is now known as #theglibfanclub
[20:21] <sadmac_> glib (adj): showing little forethought or preparation : offhand
[20:22] <sadmac_> "lacking depth and substance : superficial <glib solutions to knotty problems>"
[20:22] <Keybuk> did you know that it's another word for castration?
[20:22] <Keybuk> I feel the same way about both
[20:23] <sadmac_> Keybuk: so you would rather become a woman than a GNOME developer?
[20:24] <Keybuk> one is certainly more likely than the other
[20:24] <Keybuk> I got told "I don't contribute enough" to be a GNOME developer
[20:24] <sadmac_> Women tell me that all the time.
[20:26] <AlexExtreme> I think my most hated thing about glib is the way that it implements libc functions itself and just sticks g_ in front, and typedefs g<type> to <type> for many types
[20:27] <sadmac_> AlexExtreme: its a performance thing. G is a very fast character, because its right next to your pointer finger. So it makes the front of variables quicker.
[20:28] <AlexExtreme> haha
[20:28] <sadmac_> the front is the part in 'high' memory, and glib people believe in doing many things while high
[20:30] <AlexExtreme> interesting
[20:30] <AlexExtreme> my iPhone kernel paniced
[20:31] <ion_> URL?
[20:31] <ion_> keybuk: Congrats. :-)
[20:32] <Amaranth> glib has gint and such for portability reasons
[20:32] <Amaranth> it future proofs the library for new architectures
[20:32] <Keybuk> *HOW*
[20:32] <Keybuk> how is gint any more portable than the int type its typedef'd to?!: :)
[20:32] <Amaranth> make sure int is always the same size
[20:32] <Keybuk> but it doesn't
[20:33] <Keybuk> gint is int
[20:33] <Amaranth> on a new arch they can change gint to typedef to something else
[20:33] <Keybuk> but they don't
[20:33] <Amaranth> but they could :)
[20:33] <Keybuk> and, the best thing is, C *already* has typedefs for this
[20:33] <Keybuk> int32_t
[20:33] <Keybuk> uint64_t
[20:33] <Keybuk> etc.
[20:33] <Keybuk> if you *care* about the size
[20:33] <Amaranth> aren't those C99?
[20:33] <Keybuk> yes, they're from a C standard that is almost 10 years old
[20:33] <Amaranth> that many compilers still don't get right
[20:33] <Keybuk> in fact, I think C99 was C96 before, so more than 10 years old
[20:34] <Keybuk> name one
[20:34] <Keybuk> name a compiler that doesn't get them right that you can actually compile GNOME on :p
[20:34] <Amaranth> i think think windows has int16
[20:34] <Keybuk> MSVC++ is one of the better C99 compilers out there
[20:34] <Keybuk> it might have other typedefs, but it certainly supports the standard
[20:34] <Amaranth> but this is the stdlib
[20:34] <Keybuk> SUNWspro certainly supports them
[20:34] <Keybuk> gcc does
[20:35] <sadmac_> Keybuk: gcc doesn't fully support C99, by their own admission. I don't know the discrepancies though. Obviously small.
[20:35] <Amaranth> i'm pretty sure windows doesn't have all of them
[20:35] <Amaranth> saw a debian guy bitching about this a couple days ago
[20:35] <Keybuk> you certainly don't need to protect the size of "int"
[20:35] <Keybuk> gchar
[20:35] <Keybuk> (!!)
[20:36] <Keybuk> whoah!  fat characters!
[20:36] <sadmac_> Most people I know that are big into C consider C99 to be a failed standard though.
[20:36] <Amaranth> wasn't the main point of C99 to make C and C++ mix better?
[20:36] <Keybuk> sadmac_: http://gcc.gnu.org/c99status.html
[20:36] <Amaranth> also, glib is rather old...
[20:37] <Amaranth> everything might support that stuff now but did it in 2001?
[20:37] <Keybuk> glib is just over-engineered
[20:37] <Amaranth> that too
[20:37] <sadmac_> Keybuk: cool.
[20:37] <Keybuk> it's a library written for writing programs in C for people who don't like writing programs in C
[20:37] <Amaranth> just use vala :)
[20:37] <Keybuk> everything C-like is hidden so you can pretend you're writing in G
[20:37] <Keybuk> when, in reality, you probably just wanted C++ in the first place
[20:38] <Keybuk> or compiled C# or Java
[20:38] <Amaranth> but C++ is evil
[20:38] <Keybuk> glib is evil ;)
[20:38]  * sadmac_ still needs to learn Objective C
[20:38] <Amaranth> slightly less evil :)
[20:38] <Keybuk> the difference between C++ and glib in terms of evil is like the difference between Steve Ballmer and Bill Gates
[20:38] <Keybuk> at least C++ *knows* its evil
[20:38] <sadmac_> Java is more evil than C++. C# is somewhere between the two.
[20:38] <Amaranth> C# is pretty nice, really
[20:38] <Keybuk> it wakes up in the morning, has a good manic laugh, and sets out to see what new evil it can bring to the day
[20:39] <ion_> :-)
[20:39] <Keybuk> glib just brings the same evil without trying
[20:39] <Keybuk> C# does generally seem nice
[20:39] <Keybuk> it was invented by the guy who did Delphi and ObjectPascal
[20:39] <Keybuk> and I liked them
[20:39] <AlexExtreme> it was?
[20:39] <Amaranth> I'd rather use C# than C++ because if I'm going to have to deal with that bullshit at least I don't have to deal with memory management and pointers :P
[20:39] <Keybuk> my only issue with it is that its interpreted
[20:39] <sadmac_> Digital Mars D looks nice, but the implementation just isn't there yet.
[20:39] <Amaranth> Keybuk: which vala 'fixes' :)
[20:55]  * sadmac_ looks into vala
[20:55] <sadmac_> interesting
[21:17] <Keybuk> yay
[21:17] <Keybuk> I *think* I have dbus now hooked properly into the nih main loop
[21:19] <ion_> Yay
[21:29] <Keybuk> of course, that's the easy bit
[21:30] <Keybuk> sending messages and handling those you get is the hard bit ;)
[21:33] <ion_> :-)
[21:55] <Keybuk>         server = nih_dbus_server ("unix:abstract=/com/ubuntu/upstart/test");
[21:55] <Keybuk>         if (! server) {
[21:55] <Keybuk>                 err = nih_error_get ();
[21:55] <Keybuk>                 printf ("ERROR: %s\n", err->message);
[21:55] <Keybuk>                 exit (1);
[21:55] <Keybuk>         }
[21:55] <Keybuk> ...
[21:55] <Keybuk> ahh, a nice API at least
[21:56] <ion_> Great
[21:57] <Keybuk> ok, that still needs to have something to handle publishing objects
[21:57] <Keybuk> etc.
[21:57] <Keybuk> but in theory, all upstart needs to call is nih_dbus_server() to handle direct clients and nih_dbus_system_bus() to handle indirect
[22:28] <sadmac__> nih_error_get sounds like a 4chan meme
[22:28] <sadmac__> 250 ERROR GET!