packaging beepcore-c
Chris Hanson <[email protected]> Fri, 19 Jul 2002 21:24:09 -0400
| Newsgroups | gmane.network.beep.beepcore.c.general |
|---|---|
| Message-ID | <[email protected]> |
[I'm not sure this is the right forum for these comments. I'm looking for feedback from the beepcore-c developers, and secondarily from other users, but there doesn't appear to be any mailing list specifically for discussions with the developers. If this message is OT, please let me know and I'll shut up.] I've been packaging beepcore-c 0.2 for Debian, which isn't straightforward since the software doesn't appear to have been designed to accomodate packaging. I'd like to get my changes back into the upstream sources so that this and other packaging efforts are simplified. There are two problems I've run into. The first is that "make install" doesn't install the right things, and isn't flexible enough to put what it does install in the right places. At present, I've worked around this by writing a custom install script, rather than rewriting all the makefiles. The second problem is that the include files are all referenced using relative names, rather than <...>, which doesn't really work. Furthermore, the organization of the include files seems excessively complex. It strikes me that it would be much simpler to flatten all that heirarchy and everywhere refer to the files using <beepcore-c/FOO.h> This will simplify the use of beepcore-c by end users, and will also simplify installation. Do these sound like reasonable changes? I'd be happy to do the edits and forward diffs to the developers for inclusion if desired. ---------------- In parallel with this packaging activity, I've been playing around with the examples prior to using beep to build an application. I've run into a problem that appears to have been seen by others: the beepng/beepd example pauses for arbitrary amounts of time and has very long round-trip times under some circumstances. I believe this problem may be a bug in the Linux kernel. (FYI, I'm running Debian unstable with Linux 2.4.19-pre10, and have patched the kernel with RML's preempt-kernel patch.) What I've observed is that the delays occur when the machine is quiescent. If I start beepng, it usually hangs, but if I generate some X events, it immediately unhangs and finishes. However, if I just let the machine sit there, beepng will hang for a long time. I also noticed that when I was running a kernel compilation in the background, it didn't hang at all -- instead it reliably finished in reasonable amounts of time. This behavior smells like a scheduler bug. To those of you who have also seen this problem -- are you running Linux too? Do you see the same symptoms? Has anyone got more information? ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf