[00:15] <Keybuk> I can't help but notice that little discussion is actually happening on #unix-init
[00:15] <Keybuk> or the attached mailing list
[00:19] <ion_> Heh, yeah
[00:28] <Keybuk> I still want to know what the big security panic is
[00:33] <ion_> Security panic?
[01:04] <Keybuk> yeah, still embargo'd
[01:04] <Keybuk> I have no idea what it is
[01:04] <Keybuk> just that I was told not to ask lest by weekend be ruined by the panic
[01:27] <ion_> Wait, what? I don’t understand anything you said. :-) I must be missing something obvious here.
[01:28] <ion_> Security, as in the hardy-security repo perhaps? Embargo? I haven’t been reading mailing lists for a while. :-)
[08:37] <rgl> hi
[08:37] <rgl> how do we disable an event from starting? 
[08:38] <rgl> I mean, I created /etc/event.d/foo but how do I disable it?  doing a stop foo stops the service, but the next time the system boots, its started again.
[12:02] <Keybuk> when testing arrays of int, it's very hard not to use the numbers 4, 8, 15, 16, 23 & 42
[12:43] <Keybuk> today's task:
[12:43] <Keybuk> design an API for D-Bus properties
[12:43] <Keybuk> can't decide which would be best
[13:24] <ion_> Hehe (the numbers)
[13:37] <Keybuk> for the property API, which sounds better
[13:37] <Keybuk> 1) for each property, you have to define a _get and _set function
[13:38] <Keybuk> 2) for each property, you have to define a single function which takes two arguments (set from first, store old value in second)
[13:38] <Keybuk> 3) you have to define a single _get and _set function, which gets passed the property to set/get and a union of the possible types
[13:47] <ion_> What are these properties?
[13:48] <Keybuk> job name, description, goal, state, etc.
[13:51] <ion_> I don’t like 2) a lot. 1) would make a pretty API, but because of C’s lack of dynamicity, you wouldn’t be able to e.g. iterate over an array of properties and _get each one of them (for a GUI for instance).
[13:52] <Keybuk> sure you would
[13:52] <ion_> So i guess i’d choose 3). Perhaps i’m missing some considerations.
[13:52] <Keybuk> remember that these are accessor functions
[13:52] <Keybuk> for job in manager.GetAllJobs():
[13:53] <Keybuk>     for name, value in job.GetAllProperties():
[13:53] <ion_> Oh, sorry, i thought this being a C API, not a D-Bus API.
[13:53] <Keybuk>         print name, value
[13:53] <Keybuk> C API you just do obj->value ;)
[13:53] <ion_> Ah, ok.
[13:53] <Keybuk> this is the functions to convert the struct into d-bus properties that the GUIs can use
[13:54] <Keybuk> so there'd be a goal property, a state property, a name property, etc.
[13:54] <Keybuk> having
[13:54] <Keybuk> job_class_get_name (...)
[13:54] <Keybuk> job_get_goal (...)
[13:54] <Keybuk> job_get_state (...)
[13:54] <Keybuk> is a lot of properties
[13:55] <Keybuk> admittedly, almost all of them are going to be get only given the design
[13:56] <Keybuk> with class one settable to the object that made them I guess
[13:57] <ion_> I’m not sure whether to pick 1) or 3).
[13:57] <Keybuk> the main problem with 3 is that the types are so varied I guess
[13:57] <Keybuk> so you'd need a "JobClassProperty" union
[13:57] <Keybuk> which is a bit crappy
[13:57] <Keybuk> at least 1) you just write lots of very very simple functions
[13:58] <ion_> Indeed
[13:58] <Keybuk> int
[13:58] <Keybuk> job_get_goal (Job *job, NihDBusMessage *message)
[13:58] <Keybuk> {
[13:58] <Keybuk>  err.
[13:58] <Keybuk> int
[13:58] <Keybuk> job_get_goal (Job *job, NihDBusMessage *message, const char **goal)
[13:58] <Keybuk> {
[13:58] <Keybuk>     *goal = job_goal_name (job);
[13:58] <Keybuk>     return 0;
[13:58] <Keybuk> }
[13:58] <ion_> If the amount of functions with 1) isn’t a problem, i’d pick it.
[13:59] <Keybuk> I think that the thought that they'll be get only for the majority has made me happier about that
[13:59] <Keybuk> not sure how to do job setup
[14:00] <Keybuk> you'd do a d-bus call to define a source, which would be attached to your d-bus unique name (so if you disconnect, your jobs are all deleted)
[14:00] <Keybuk> you'd then need to define files and attach jobs to them
[14:00] <Keybuk> and set up the jobs before committing them
[14:00] <Keybuk> after committing, you wouldn't be able to change the job
[14:00] <Keybuk> you'd create a new one and delete the old
[14:00] <Keybuk> or the changes could be always permitted, and always result in the old being automatically deleted
[20:07] <Keybuk> ion_: security embargos are no fun :-(
[20:07] <Keybuk> even I'm not allowed to know what the big security panic is
[20:07] <Keybuk> all I'm told is that it's very scary, and we'll all know on Tuesday
[22:18] <sadmac> Keybuk: yo
[22:19] <sadmac> Keybuk: RH is still sorting through the assignment agreement, but I could get going now and just wait to commit until they straighten it out
[22:40] <Keybuk> sadmac: tbh, most of the help I need right now is in testing
[22:40] <Keybuk> am making fast progress now
[22:45] <sadmac> Keybuk: good to hear :)
[22:46] <Keybuk> if you can compile it with -DDEBUG and create test jobs in /etc/init/jobs.d (you get a "debug" event instead of a startup one)
[22:46] <Keybuk> and see if you can crash it then
[22:47] <sadmac> Keybuk: I have only my laptop now (left my school housing, so my boxen are packed away) so I'll probably have to wait until I get to westford to requesition a good test box
[22:47] <sadmac> Though I don't mind crashing the lappy a bit.
[22:48] <Keybuk> heh, don't install
[22:53] <Keybuk> if compiled with DEBUG you can just run init as a normal user out of the src directory
[22:55] <sadmac> Keybuk: and when doing that it will look in /etc/init/jobs.d?
[22:56] <Keybuk> yeah
[22:56] <sadmac> yeehaw
[22:57] <sadmac> in 2 days I'll probably be running 0.3.9 by default
[22:57] <sadmac> assuming I can get upgraded right away
[23:10] <sadmac> Keybuk: getting these:
[23:10] <sadmac> configure.ac:31: required file `intl/Makefile.in' not found
[23:10] <sadmac> configure.ac:14: required file `./ABOUT-NLS' not found
[23:10] <sadmac> configure.ac:18: required file `./ltmain.sh' not found
[23:10] <sadmac> Makefile.am:3: required directory ./intl does not exist
[23:11] <sadmac> trying to build libnih
[23:11] <Keybuk> did you run autoreconf -i ?
[23:11] <sadmac> no -i
[23:11] <Keybuk> that might help
[23:12] <sadmac> heh
[23:16] <sadmac> Keybuk: does init fork or should I launch it in the background?
[23:17] <Keybuk> just leave it in the foreground so you can watch the output?
[23:17] <sadmac> Keybuk: ahh
[23:17]  * sadmac Ctrl+a c
[23:59] <sadmac> Keybuk: it seems initctl doesn't build by default in trunk
[23:59] <Keybuk> no, it's not done yet
[23:59] <sadmac> Keybuk: ahh. that'd do it