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
Jeff Breidenbach [EMAIL PROTECTED] said:
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
I also did some digging. I found the same removal message
and then tracked down a gcj maintainer IRC. He simply said:
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
Matthew, I just built your package on sarge, it went fine. Good job.
python2.4-pylucene_1.9-1_i386.deb
I noticed you chose not to have a README.Debian file. That's probably
ok, since most of the weirdness affects package maintainers and not
package users. On the other hand, you might want to
Jeff Breidenbach [EMAIL PROTECTED] said:
However, it is technically possible to compile on Debian
stable then upload the binary package to unstable (a.k.a.
sid). This can - somewhat - bypass the swig issue and get
a working PyLucene package in Debian for one architecture,
presumably i386.
Jeff Breidenbach [EMAIL PROTECTED] said:
Matthew, I just built your package on sarge, it went fine.
Good job.
python2.4-pylucene_1.9-1_i386.deb
I noticed you chose not to have a README.Debian file. That's probably
ok, since most of the weirdness affects package maintainers and not
On Sun, 5 Feb 2006, Jeff Breidenbach wrote:
Andi, how about distributing the binary package (.deb) from the
PyLucene website while things are shaking out? Or perhaps Matthew
can distribute from canonical.org, and have a link from the PyLucene
homepage? This can be done immediately, allows
Andy,
I compiled PyLucene 1.9rc1-7 for the i386, amd64, and
powerpc Debian architectures. I created an APT repository
because I figured it would be easier to manage. So if you
add the follow instructions to your website they should make
sense to any Debian user:
There are binary PyLucene
On Sun, 5 Feb 2006, Matthew O'Connor wrote:
I compiled PyLucene 1.9rc1-7 for the i386, amd64, and
powerpc Debian architectures. I created an APT repository
because I figured it would be easier to manage. So if you
add the follow instructions to your website they should make
sense to any
Jeff Breidenbach [EMAIL PROTECTED] said:
Andi, Debian's infrastructure is designed such that a source package is not
allowed to be a build dependency. Matthew, please file a wishlist bug against
swig, requesting a version update.
I think I confused the issue. Unstable has SWIG 1.3.27.
Debian GCC team,
We're looking at packaging PyLucene for Debian, and are having
some build dependency problems with sid. PyLucene currently
requires gcj 3.4.x, x =3. However, sid appears to only have gcj 4.x
I'm a little surprised to see this - I had thought it likely multiple
versions of gcj
Matthew,
Regarding the swig incompatibility, I think you are right. It probably
is a matter
of poking the right people and waiting.
However, it is technically possible to compile on Debian stable then upload the
binary package to unstable (a.k.a. sid). This can - somewhat - bypass the swig
issue
On Sat, 4 Feb 2006, Jeff Breidenbach wrote:
The gcj situation is more serious. No way in hell can we package the gcj
runtime inside the PyLucene package. As far as I can tell this is a
showstopper,although I'm curious what the gcj package maintainers have to
say about the matter.
Ah, if
Matthew,
Given Andi's comments, one possibility is to put the PyLucene package
into Debian, but under the contrib section and marking it with appropriate
bug entries. The hope would be people could improve the build situation
over time.
Another possibility - maybe - is to package an older
Jeff Breidenbach [EMAIL PROTECTED] said:
Given Andi's comments, one possibility is to put the PyLucene package
into Debian, but under the contrib section and marking it with appropriate
bug entries. The hope would be people could improve the build situation
over time.
Personally, I'm fine
On Fri, 3 Feb 2006, Jeff Breidenbach wrote:
Another possibility - maybe - is to package an older version of PyLucene
that depends on Java Lucene 1.4.3. However, I suspect there are likely
to be similar issues and an upatched Java Lucene 1.4.3 will not be a viable
build dependency either.
The
On Fri, 3 Feb 2006, Matthew O'Connor wrote:
Personally, I'm fine with it going into contrib. I'd like
it to go into main but that's probably not feasible unless
there's a DFSG-free JDK that could compile it.
If Java Lucene exists as a Debian package already, then this problem must have
I'm dropping the Debian Java package maintainers from the CC: list.
Individuals can join in if they want.
Andi is correct, Java Lucene 1.4.3 compiles ok with a Free Software
toolchain. Specifically we use kaffe. Getting this to work took a lot
of time and effort. It is unknown at this time
On Fri, 3 Feb 2006, Jeff Breidenbach wrote:
Once there is a Debian Java Lucene 1.9 source package available, the PyLucene
1.9 package could be made to depend on it, unpack it, apply the patches, build
it (and not install it) and then build itself. Seems pretty straightforward to
me.
Sorry,
Jeff Breidenbach [EMAIL PROTECTED] said:
Andi is correct, Java Lucene 1.4.3 compiles ok with a Free Software
toolchain. Specifically we use kaffe. Getting this to work took a lot
of time and effort. It is unknown at this time whether the release
candidate for Java Lucene 1.9 can be built
On Fri, 3 Feb 2006, Matthew O'Connor wrote:
I'll play around with trying to get this to work. Andi,
when you normally compile the Lucene code which JDK do you
use and on which platform (sorry if you answered this
elsewhere)? Before I begin I want to verify I can at least
reproduce what Andi
Andi, Debian's infrastructure is designed such that a source package is not
allowed to be a build dependency. Matthew, please file a wishlist bug against
swig, requesting a version update.
Okay, I'll try to build it with a free software java stack.
However, if that proves too difficult is
I use Apple's JDK on Mac OS X, my main development platform.
Oh yeah. There is one more technical factor to add into the mix, hopefully
people's heads aren't ready to explode.
Debian supports a lot of architecture, I think the current number is 11.
There are autobuilders for all of these
On Fri, 3 Feb 2006, Jeff Breidenbach wrote:
I use Apple's JDK on Mac OS X, my main development platform.
Oh yeah. There is one more technical factor to add into the mix, hopefully
people's heads aren't ready to explode.
Debian supports a lot of architecture, I think the current number is
By architectures I mean i386, powerpc, sparc, S390, mips, m68k, AMD64, etc.
http://www.debian.org/ports/
you should first make sure gcj is functional on these 11 architectures.
No real need to check ahead of time - gcj will either work on a given
architecture or it won't. We just want to be in
On Thu, 2 Feb 2006, Jeff Breidenbach wrote:
Hi Matthew,
Good work on the package. However, I don't like that it starts with
Java bytecode
instead of canonical source code. Do you think it would be possible to have the
PyLucene package use the Java Lucene package as a build dependency?
With
26 matches
Mail list logo