On Tue, 7 Feb 2006, Jeff Breidenbach wrote:
Hi, I did a little digging. Package gcj-3.4 was removed
from Debian Unstable on Aug 14, 2005 because it was
"Not Built by Source"
http://ftp-master.debian.org/removals.txt
Since gcj is the critical path, this suggests to me that
maybe gcj-4.x is the better place to put effort. Andi, do you
and OSAF already have all the communication and clout
you need with gcj devs?
I tried gcj 4.x and have had little luck with it. For the longest time, I
wasn't even able to build it. I should try it again...
gcj 3.4.x is the safe and stable route for the time being.
With the arrival of Intel Macs and no Intel OS X gcj available until probably
gcj 4.2, this may change sometime in the next 12 months.
As for 'clout' with the gcj devs, well, that word would be inappropriate.
I suppose we could try getting Debian maintainers to lean
on upstream a little bit - not that they responded to my
initial inquiry. And Ubuntu might also care. On the other hand,
gcj is so high profile they may be immune to a little extra
persuasion. Are the bugs rocket sciencish, or can a random C
programmer like me dive in and help? Any other way we can
help?
Definitely not a random C programmer. gcj is actually at least 3 projects put
together, with their own interests and schedules: gcc + classpath + boehm-gc.
I've had very little luck in getting any issue resolved, most of them are hard
to isolate and reproduce or not on the gcj devs' agenda (static linking, for
example). The [EMAIL PROTECTED] mailing list is quite active and very
responsive and can be very helpful if you're willing to do most of the work
since there is a lot more work than gcj devs can handle.
I've had better luck working around issues on my own.
* Swig sounds like it is progressing just fine.
In a way, it is, but distros are very quick to upgrade to the latest swig in
spite of the fact that swig keeps making incompatible changes that make it
unlikely for a new swig release to work out of the box for pre-existing
software packages.
* Andi, think about - eventually - having a future PyLucene source
release that is more sourcetastic. For example, maybe include a
tarball of the SVN snapshot and a new build target that untars,
patches, and rebuilds the .jar files.
This is how PyLucene is built from scratch. The source release includes the
pre-compiled jars because the audience for PyLucene is Python programmers and
I didn't want to impose a JDK requirement on them. GCJ is difficult enough to
get right - on the Mac, you have to build gcj yourself since Apple doesn't
ship it - adding a JDK requirement on top of it (+ ant) would be gratuitous.
The precompiled .jar files can still be included. If that's a real pain,
then defer because it is not on the critical path. But this or something
like it will eventually be helpful, especially since it sounds like the
gcj-3.4 package got kicked out of Debian for similar reasons.
I have no problems with making a source-only package, it'd add a java compiler
requirement to this exercise. Whichever works best in the world of Debian is
fine by me.
* Mathew, the PyLucene module will not be found if one tries to
import it from python 2.3 right? I don't have the PyLucene package
in front of me to double check this.
It'll be found if it is in the right place to be found. If PyLucene is built
against Python 2.4 headers it may very well crash the process when imported
from Python 2.3.
Anyway, great job on getting this far with the sarge packages.
Matthew, you've already made a significant positive difference, and
I'm already hearing positive comments. Most recently from a hacker
at PARC (my employer) who is actively migrating an internal application
called UpLib from Java Lucene towards PyLucene.
Excellent !
Andi..
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
