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