This email isn't a criticism of rxtx - thanks Scott for accepting my patch.
It's more of a starting point for issues with development on Debian and
distributions - see the last comment.
On 23/10/11 15:08, Scott Howard wrote:
clone 646069 -1
retitle -1 rxtx: make -dbg package for rxtx
retitle 646069 rxtx: fails when "java.ext.dirs" system property
contains more than one directory
rxtx doesn't fail, it just fails to read any gnu.io.rxtx.properties file
exist in one of these directories because the filename is constructed
from the directory names joined with ":".
I created a gnu.io.rxtx.properties file in one of the directories but I
don't know what would happen (Java-wise) if there were more than one of
these files - I haven't tested it.
It will work without finding any gnu.io.rxtx.properties file.
severity -1 wishlist
Thanks for the patch, great work.
Separated this into two bugs
1) I'll apply the patch and forward it upstream. RXTX really isn't
maintained much anymore upstream, but I'll at least share it on the
2) We'll build with make -DDEBUG_VERBOSE and make a -dbg package for gdb.
A "foo-dbg" package is one with debugging symbols for package "foo".
Maybe "rxtx-verbose" would be a better name, with
rxtx <- conflicts -> rxtx-verbose
as an install option.
As for the make uninstall, autotools does a poor job with uninstall
targets  and upstream has a custom install target that just puts
the RXTXcomm.jar into the same directory as the jvm and libtool
install the native libraries. The Debian source package really isn't
intended to be used to install outside of the debian packaging system.
That's a shame if it's the case in general.
I certainly wouldn't have considered using
given the turnaround I wanted with the source code changes.
fakeroot debian/rules binary
didn't work either.
I've got some packages in SourceForge. You can get them via
You can build Debian/Ubuntu packages with
You can install/uninstall them with
using the makefile in the package root that wraps automake.
You will need to use "sudo" if you want to install them in a system
like /usr or /usr/local.
If you've git-cloned a package repository you can also do things like
make git branch=a.b.c distcheck
make git tag=a.b.c release debian
The "tag" variant is for branches you tag locally.
If you want to build a package in a sandbox along with all its dependent
v3c packages, you git clone the v3c packages into some directory writeable
by you, then you can use v3c's "v3c-tryout" script
v3c-tryout <pkg-name-version> <sandbox-dir>,
./v3c-tryout v3c-dcom-0.3.2-01 tryout-v3c-dcom
and it will
1. git checkout the respective versions of the dependent packages as
required by the version of the package you specified, into the sandbox dir.
2. build and install them to the sandbox dir in order.
3. create shell scripts to set up a (b/d)ash session inside the sandbox, to
test the packages or run "make check", mess with the sources, uninstall...
to uninstall, just delete the .jar and
glibtool --mode=uninstall $(RM) list_of_targetlib
I'd really like to see something like this adapted by Debian and other
distributions to save developers from reinventing the wheel or discovering
that the package doesn't adhere to published documentation.
What do you think?
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com