| ion | keybuk: Btw, have you seen http://check.sourceforge.net/? (I didn’t take a look at it yet, just noticed something else uses it.) | 00:59 |
|---|---|---|
| ion | “ In C, a unit test is just as likely to trash its address space as it is to fail to meet its test requirements, and if the test framework sits in the same address space, goodbye test framework. | 01:05 |
| ion | To solve this problem, Check uses the fork() system call to create a new address space in which to run each unit test, and then uses message queues to send information on the testing process back to the test framework. That way, your unit test can do all sorts of nasty things with pointers, and throw a segmentation fault, and the test framework will happily note a unit test error, and chug along. ” | 01:05 |
| === sadmac2_ is now known as sadmac2 | ||
| Keybuk | mbiebl: applied, pushed | 11:50 |
| Keybuk | ion: I looked at check, but found it far too complicated for what I needed | 11:50 |
| Keybuk | for me, the primary thing a C-based test suite should give you is the ability to run gdb or valgrind on the tests to debug | 11:50 |
| === robbiew1 is now known as robbiew | ||
| ion | keybuk: Alright | 14:07 |
| Esmil | Is there a way to 'reset' jobs? Right now I have a job stop/killed, process 1050 and both start/stop job hangs, but there is no process 1050 running on my system | 14:24 |
| Keybuk | that's odd | 14:25 |
| Keybuk | that implies upstart missed SIGCHLD for it | 14:25 |
| Esmil | Apparently the avahi-daemon needs 'expect daemon' not 'expect fork'. That's how it happened | 14:26 |
| Keybuk | ah, so you have a floating ptrace entry basically? | 14:26 |
| Esmil | Sorry, don't know what that means >.< | 14:26 |
| Keybuk | I don't think there's a way to get rid of that | 14:27 |
| Esmil | Hmm.. ok. Next reboot then | 14:27 |
| Keybuk | I'll test with avahi myself and see if I can find out why it lost track of things | 14:27 |
| Esmil | upstart 0.6.2 btw | 14:28 |
| Keybuk | don't suppose you can pastebin your avahi conf file? | 14:28 |
| Keybuk | (/etc/init one that is) | 14:28 |
| Esmil | http://pastebin.org/5048 | 14:29 |
| Esmil | Ohh, thats after I changed expect fork to daemon | 14:29 |
| Keybuk | thanks | 14:29 |
| Esmil | btw. I had sort of the opposite problem with hald. It needs expect fork not daemon. Sort of the same happened when I stopped the hald job | 14:31 |
| Esmil | Only this time upstart would TERM/KILL a sub-process of hald | 14:31 |
| Keybuk | right, I see the issue | 14:32 |
| Keybuk | well, I can replicate it ;) | 14:32 |
| Esmil | Heh, and when I sent a SIGTERM to the real hald process upstart would throw an error and hang my system | 14:33 |
| Esmil | Ok, good | 14:33 |
| Keybuk | ooh, that's fun :) | 14:33 |
| Keybuk | what was the error? | 14:34 |
| Esmil | Can't remember exactly. Assert something != NULL when it was I think, but I can try and replicate it if you want | 14:35 |
| Keybuk | yes please | 14:36 |
| Keybuk | could you file a bug about the avahi issue? (http://bugs.launchpad.net/upstart) | 14:40 |
| Keybuk | likewise, once you can get the assert out of hal, a bug about that one too | 14:43 |
| Keybuk | (I can't get it to assert, but I can see the sigchld issue) | 14:43 |
| Esmil | Yes, I just saw you need to be a bit more clever to make upstart error than I just described | 15:02 |
| Esmil | When upstart kills the child process of hald, hald exits, so start/stop hald works | 15:03 |
| Esmil | ..but in my hald.conf i have 'stop on stopping dbus-system' | 15:03 |
| Esmil | and when I go stop dbus-system, upstart goes into a funny state | 15:03 |
| Esmil | the command hangs, and when you ^C and list dbus-system is stop/stopping, process ... and hald is stop/killed process ... | 15:04 |
| Keybuk | no assert though? | 15:04 |
| Keybuk | could the assert have been with 0.6.1 ? | 15:04 |
| Esmil | No, the assert comes when you kill the dbus-daemon | 15:05 |
| Keybuk | you still get it? | 15:05 |
| Esmil | yes | 15:05 |
| Keybuk | what's the assert message? | 15:05 |
| Esmil | init: dbus-system main process ended, respawning | 15:05 |
| Esmil | init: job.c: 282: Assertion failed in job_changed_state: job ->blocker == NULL | 15:05 |
| Keybuk | that's not an assert message? | 15:05 |
| Keybuk | ah! | 15:05 |
| Keybuk | that is :D | 15:06 |
| Esmil | init: Caught abort, core dumped | 15:06 |
| Esmil | Kernel panic - ... | 15:06 |
| Esmil | Sorry I should really do this on a virtual machine, so I don't have to copy to paper and then back >.< | 15:06 |
| Esmil | job.c: 283 actually | 15:07 |
| Keybuk | *nods* | 15:07 |
| Keybuk | ok blocker isn't being cleared | 15:07 |
| sadmac | Keybuk: a job can be blocked by an event. When can an event block another event? | 15:08 |
| Keybuk | can you file a bug about that one too ;) include the assert message in the title | 15:08 |
| Keybuk | sadmac: can't | 15:08 |
| sadmac | Keybuk: hmm. I thought there was code for it | 15:09 |
| sadmac | Keybuk: also, a finished event can't block anything, correct? | 15:10 |
| Keybuk | correct | 15:10 |
| sadmac | Keybuk: ok, then EventOperator seems to be doing something strange | 15:10 |
| sadmac | Keybuk: suppose I have a job with "start on a and b" | 15:11 |
| Keybuk | event operators can block events | 15:11 |
| sadmac | Keybuk: oh. oh wow. That's actually kinda scary. | 15:11 |
| Keybuk | there's some deeply fun side-effects of that simple little stanza you just quoted aren't there <g> | 15:12 |
| Keybuk | start on starting a and starting b | 15:12 |
| Keybuk | suddenly a won't be started until b is too ;-) | 15:12 |
| sadmac | Keybuk: yeah. I picked the right area of the code to rework :) | 15:12 |
| sadmac | Keybuk: did I mention reorganizing EventOperator? | 15:13 |
| Keybuk | yeah you did | 15:13 |
| Keybuk | not how though? | 15:13 |
| sadmac | Keybuk: Its an N-ary tree the way I'm doing it. | 15:13 |
| Keybuk | one of the reasons it's a binary tree is efficient traversal-without-leafs | 15:14 |
| sadmac | Keybuk: before if you had "a or b or (c and d)" you'd get a tree like (or (or (or b (and c d)))) | 15:14 |
| sadmac | Keybuk: now you get (or a b (and c d)) | 15:14 |
| Keybuk | yes | 15:14 |
| Keybuk | that's deliberate though | 15:14 |
| Keybuk | if a, c and d happen | 15:14 |
| Keybuk | err | 15:15 |
| Keybuk | imaging | 15:15 |
| Keybuk | imagine | 15:15 |
| Keybuk | (a and b) or (c and d) | 15:15 |
| Keybuk | if a, c & d happen | 15:15 |
| Keybuk | you *don't* want the environment from a being leaked to the job | 15:15 |
| Keybuk | if you can keep that, sweeet | 15:15 |
| sadmac | as soon as a happens the operator is true | 15:15 |
| Keybuk | yeah, I had to clarify | 15:16 |
| sadmac | Keybuk: that tree would remain binary | 15:17 |
| sadmac | Keybuk: there's no optimization to it | 15:17 |
| Keybuk | what about | 15:17 |
| Keybuk | ok | 15:17 |
| Keybuk | I look forwards to playing with it :) | 15:17 |
| sadmac | Keybuk: it makes it easier to do 0.10-with-0.6-compatibility and check your errors, since you can make qualifying statements about EventOperators more quickly | 15:18 |
| Keybuk | *nods* | 15:18 |
| Keybuk | sounds good to me | 15:19 |
| sadmac | cool | 15:19 |
| Keybuk | if you could write up what you're doing and post it to the list at some point, great | 15:19 |
| Keybuk | otherwise no problem if that comes with the code ;-) | 15:19 |
| Keybuk | (not everyone writes their plans before they code like me :p) | 15:19 |
| sadmac | yeah, dunno which will get done first. The testcases will probably take long enough to justify taking a break to write it in human. | 15:20 |
| Keybuk | lol | 15:20 |
| sadmac | Keybuk: I also noticed libnih still uses a cursor for FOREACH. I thought the reference stuff gave us a nifty way around that. | 15:23 |
| Keybuk | cursor is still useful when removing | 15:24 |
| Keybuk | and traversing a list that may be reordered | 15:24 |
| sadmac | cool | 15:25 |
| Keybuk | Esmil: did you file those two bugs? | 15:25 |
| Esmil | Writing on the second one at the moment | 15:31 |
| Esmil | Done | 15:39 |
| sadmac | Keybuk: 0.6.2 is using proc connector now, right? | 15:41 |
| sadmac | or have we not gone there yet? | 15:41 |
| Keybuk | no | 15:47 |
| Esmil | Is there some way to tell init that the system dbus is up, so please register yourself there? | 15:53 |
| Esmil | ..or planned something like that? | 15:53 |
| sadmac | Esmil: planned | 15:54 |
| Esmil | Ok, good. Thanks | 15:54 |
| Keybuk | Esmil: telinit q | 15:59 |
| sadmac | Keybuk: has behavior of that changed? | 16:00 |
| Esmil | Hah, cool. | 16:01 |
| Keybuk | sadmac: in what sense? | 16:01 |
| sadmac | Keybuk: does it still re-exec? | 16:01 |
| Keybuk | sadmac: q reloads, you're confusing with u | 16:01 |
| sadmac | Keybuk: oh. shit. that's a good place for that. | 16:01 |
| Keybuk | e.g. in dbus.conf | 16:06 |
| Keybuk | post-start exec telinit q | 16:06 |
| Keybuk | ;-) | 16:06 |
| Keybuk | it's a hack really, but it suffices for now | 16:06 |
| sadmac | Keybuk: I can't figure out what the interface should look like | 16:07 |
| Keybuk | which? | 16:07 |
| sadmac | Keybuk: to mark the dbus job as allowing dbus to start | 16:08 |
| Keybuk | dunno | 16:08 |
| Keybuk | I was wondering whether it'd be interesting to add a "dbus name" field | 16:08 |
| Keybuk | so you can hold the job in SPAWNED until it registers a name | 16:08 |
| Keybuk | if you specified org.freedesktop.DBus it'd behave magically ;) | 16:08 |
| Keybuk | that'd also mean you could StartByDBusName("...") | 16:08 |
| Keybuk | which might be nice for D-Bus activation purposes | 16:09 |
| Esmil | Is it possible to start certain instances on events? E.g. start agetty TTY=vc/2 when sysinit.conf fails to start without having another job just to do exec start --no-wait agetty TTY=vc/2 | 16:14 |
| Keybuk | no, that's one problem I haven't solved yet ;-) | 16:25 |
| Esmil | Ok, just wondering if just hadn't found it in the man pages yet. There are many hacks around it I guess | 16:27 |
| * sadmac sighs at fedora-devel | 20:21 | |
| sadmac | Lennart + Pulseaudio vs. The World, Round 13 | 20:22 |
| ion | Please elaborate, for the lazy ones among us. :-) | 20:51 |
| sadmac | ion: Lennart: "New pulse release with mixer changes." Everyone: "WE HATE YOU AND ALL YOU STAND FOR." Lennart: "Let me further you in those convictions." JGarzik: "Some of your ideas for Pulse are bad." Lennart: "You don't know about /new/ soundcards. You're the /old/ audio guy." JGarzik: "God you're stupid. I'm gonna go get some coffee." | 20:53 |
| sadmac | Pulse is an example of what happens when someone correctly times a bad solution to a serious problem. | 20:55 |
| ion | Hehe | 20:55 |
| sadmac | I'd punch Lennart if I could reach his head. | 20:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!