| 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:15 |
| ion_ | Heh, yeah | 00:19 |
| Keybuk | I still want to know what the big security panic is | 00:28 |
| ion_ | Security panic? | 00:33 |
| 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:04 |
| ion_ | Wait, what? I don’t understand anything you said. :-) I must be missing something obvious here. | 01:27 |
| ion_ | Security, as in the hardy-security repo perhaps? Embargo? I haven’t been reading mailing lists for a while. :-) | 01:28 |
| rgl | hi | 08:37 |
| rgl | how do we disable an event from starting? | 08:37 |
| 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. | 08:38 |
| Keybuk | when testing arrays of int, it's very hard not to use the numbers 4, 8, 15, 16, 23 & 42 | 12:02 |
| Keybuk | today's task: | 12:43 |
| Keybuk | design an API for D-Bus properties | 12:43 |
| Keybuk | can't decide which would be best | 12:43 |
| ion_ | Hehe (the numbers) | 13:24 |
| 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:37 |
| 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:38 |
| ion_ | What are these properties? | 13:47 |
| Keybuk | job name, description, goal, state, etc. | 13:48 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| Keybuk | admittedly, almost all of them are going to be get only given the design | 13:55 |
| Keybuk | with class one settable to the object that made them I guess | 13:56 |
| 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:57 |
| 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:58 |
| 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 | 13:59 |
| 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 | 14:00 |
| 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 | 20:07 |
| sadmac | Keybuk: yo | 22:18 |
| 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:19 |
| Keybuk | sadmac: tbh, most of the help I need right now is in testing | 22:40 |
| Keybuk | am making fast progress now | 22:40 |
| sadmac | Keybuk: good to hear :) | 22:45 |
| 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:46 |
| 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:47 |
| Keybuk | heh, don't install | 22:48 |
| Keybuk | if compiled with DEBUG you can just run init as a normal user out of the src directory | 22:53 |
| sadmac | Keybuk: and when doing that it will look in /etc/init/jobs.d? | 22:55 |
| Keybuk | yeah | 22:56 |
| sadmac | yeehaw | 22:56 |
| sadmac | in 2 days I'll probably be running 0.3.9 by default | 22:57 |
| sadmac | assuming I can get upgraded right away | 22:57 |
| 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:10 |
| 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:11 |
| sadmac | heh | 23:12 |
| sadmac | Keybuk: does init fork or should I launch it in the background? | 23:16 |
| 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:17 | |
| 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 | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!