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