PyLucene is a GCJ-compiled version of Java Lucene integrated with Python via SWIG. Its goal is to allow you to use Lucene's text indexing and searching capabilities from Python. It is designed to be API compatible with the latest version of Java Lucene.
Lucene is a high-performance, full-featured text search engine library written entirely in Java. It is a technology suitable for nearly any application that requires full-text search, especially cross-platform.
If included, Documancer (already in Portage) could use it, see bug #31999.
Created attachment 50863 [details]
Attaching the ebuild...
Created attachment 50864 [details, diff]
i suppose this ebuild should check wether gcc is installed with 'gcj' USE flag
analyzers/analysis/nl/WordlistLoader.java: In class `org.apache.lucene.analysis.nl.WordlistLoader':
analyzers/analysis/nl/WordlistLoader.java: In method `org.apache.lucene.analysis.nl.WordlistLoader.getStemDict(java.io.File)':
analyzers/analysis/nl/WordlistLoader.java:71: error: Can't find method `split(Ljava/lang/String;I)' in type `java.lang.String'.
wordstem = line.split("\t", 2);
Re comment #3: yes, but how? I didn't find anything in Ebuild HOWTO nor in ebuilds under /usr/portage...
Re comment #4: and your gcc version is...?
1.see an example in x11-libs/wxmozilla
Created attachment 59063 [details]
Attaching new ebuild with dependency on gcc >= 3.4, PyLucene apparently
requires its implementation.
As for checking gcj USE flag, this ebuild does it since its first version in
the same way that wxmozilla ebuild does, so I'm more than a little confused by
i'm confused to, because first time i wanted to emerge pylucene it died during
COMPILATION because it couldn't find gcj :)
Created attachment 75647 [details]
Updated to the latest stable upstream version.
Reassigned to maintainer-wanted.
The same ebuild works for latest 1.9.1 version.
Created attachment 85922 [details, diff]
the 1.9.1 version compiles for me. But I had to modify a little bit the ebuild. The package source tarball hasn't the right name, and it needs swig-1.3.24
This ebuild should probably test for gcc > 3.4, per http://svn.osafoundation.org/pylucene/branches/release-1.9/INSTALL
Looks like I'm gonna need to upgrade. ;(
Created attachment 90057 [details]
Updated the ebuild to work with either gcc-config or eselect-compiler.
Created attachment 90058 [details, diff]
updated pylucene-makefile.patch needed by the latest version of the ebuild
Created attachment 90919 [details]
Updated for latest upstream version ("-r1" is because upstream has 2.0.0-1 packages). Also made some cleanup: Python bytecode is now compiled and stripping of the binary is left to Portage so that /usr/lib/debug works. SWIG is no longer used by upstream.
Created attachment 90920 [details, diff]
Created attachment 90921 [details, diff]
This doesn't compile on amd64, because it's a multilib system -- `gcc-config -L` returns a colon-separated list of directories, which the ebuild puts into the make variable GCJ_LIBDIR, which the Makefile expects to contain a single directory name.
I'm not much of an ebuild author, so while I'll look the right way to solve this, any pointers would be appreciated.
This seems to work -- change the GCC_LDPATH assignment in the ebuild to:
GCC_LDPATH=$(gcc-config -L | sed 's/:.*//')
(this is taken from gnustep-base/gnustep-base/gnustep-base-1.10.1-r1.ebuild)
I should add that such a patched ebuild could be keyworded ~amd64 -- it compiles and imports into Python, at least.
(In reply to comment #20)
The files PyLucene needs are platform independent, so it should be OK to use any of them. Could you please check if the same problem exists (and fix works for) "eselect compiler getval LDPATH" (using eselect-compiler package)? TIA!
I installed eselect-compiler and used it without modification:
GCC_LDPATH=`eselect compiler getval LDPATH`
and it worked fine.
Sorry for the delay.
Created attachment 94153 [details]
New ebuild with amd64 fixes, thanks for the info!
Created attachment 94440 [details]
I'm getting crashes in PyLucene when indexing and when compiled with gcc-4.1 as well as 4.0, so this version adds checks to verify that gcc-3.4, which works, is used for compilation.
Interesting -- your latest revision gives:
/path/to/pylucene-2.0.0-r1.ebuild: line 29: gcc-version: command not found
I'm not sure what package `gcc-version' is in, but either way, that's probably not going to work!
(In reply to comment #26)
> Interesting -- your latest revision gives:
> /path/to/pylucene-2.0.0-r1.ebuild: line 29: gcc-version: command not found
> I'm not sure what package `gcc-version' is in, but either way, that's probably
> not going to work!
It's in gcc-config ("qfile gcc-config") and if you look at the ebuild, you can see that a) it has a dependency on it (or eselect-compiler) and b) it checks if gcc-config exists before calling, so the only explanation I have is that you do have /usr/bin/gcc-config (not executable, broken symlink, whatever).
(In reply to comment #27)
> It's in gcc-config ("qfile gcc-config") and if you look at the ebuild, you can
> see that a) it has a dependency on it (or eselect-compiler) and b) it checks if
> gcc-config exists before calling, so the only explanation I have is that you do
> have /usr/bin/gcc-config (not executable, broken symlink, whatever).
Yes, I have `gcc-config', but not `gcc-version':
sword-of-justice / $ file /usr/bin/gcc-config
/usr/bin/gcc-config: Bourne-Again shell script text executable
sword-of-justice / $ file /usr/bin/gcc-version
/usr/bin/gcc-version: cannot open `/usr/bin/gcc-version' (No such file or directory)
sword-of-justice / $ equery f gcc-config
[ Searching for packages matching gcc-config... ]
* Contents of sys-devel/gcc-config-1.3.13-r3:
No need to be hostile -- really.
Sorry, misread the report :( gcc-version is a function defined in toolchain-funcs.eclass (which this ebuild inherits), so I don't see how could it possibly be undefined for you (which is probably why I misread it in the first place). Can you see something I'm missing? Hope that saying I don't know is not "hostile" in your eyes.
It's my turn for a sheepish grin -- I had updated the ebuild, but missed the change to the 'inherit' declaration when merging it with my local changes. So gcc-version *is*, in fact, available.
the requirement for gcc 3.4 isn't required any more, just successfully compiled with 4.1.1 on amd64
It works with gcc 4.1.1 on amd64 (pylucene 2.0.0-8) :)
There are newer versions of PyLucene, they depend on JCC, source tarballs exist at
JCC is bundled within PyLucene, the source tarball can be downloaded seperately from
(this is an automated message based on filtering criteria that matched this bug)
'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached
to this bug.
This bug is assigned to maintainer-wanted which means that it is not in the
Hello, The Gentoo Team would like to firstly thank you for your ebuild
submission. We also apologize for not being able to accommodate you in a timely
manner. There are simply too many new packages.
Allow me to use this opportunity to introduce you to Gentoo Sunrise. The
sunrise overlay is a overlay for Gentoo which we allow trusted users to
commit to and all users can have ebuilds reviewed by Gentoo devs for entry
into the overlay. So, the sunrise team is suggesting that you look into this
and submit your ebuild to the overlay where even *you* can commit to. =)
Because this is a mass message, we are also asking you to be patient with us.
We anticipate a large number of requests in a short time.
On behalf of the Gentoo Sunrise Team,
FYI: You can find pylucene-2.0.0-r1 in liquidx's overlay. If anyone has a 2.4.0 ebuild, it is still eligable for sunrise ;)
FYI - an OSAF dev mentioned that pylucene has moved to apache:
This blocks Bug#77914
Created attachment 181977 [details]
New ebuild for pylucene-2.4.0-2
The ebuild builds, and seems to work for me (~x86). However the jakarta useflag does not quite work yet - do not enable it. I'm working with upstream on how to enable it. I'm submitting this ebuild here in preparation for submission to sunrise. Any finishing touches (like the jakarta flag) will be worked out there. Also, with the move to apache, there will be a new version of pylucene soon and the java will change slightly (from org.osafoundation to org.apache) an update will be needed when this happens.
After a bit of work and lots of help on #gentoo-java (thanks weisso and
Serkan!) I've redone the ebuild to be a whole lot cleaner and it takes into
account a few other un-niceties in the ebuild I'd already submitted. It uses
the ant-python task which would mean a dependency on dev-java/ant-python
(meaning that this bug would depend on Bug#259312)
As soon as I can I'll get this put up on some overlay or other. e-mail me if you need a copy right away.
Version 2.4.1-1 Now available in the java-experimental overlay. All tests work for me on x86. Please test on other arches.
(Please add [java-experimental] to the status whiteboard)
This obsoletes all ebuilds attached to this bug.
Happy birthday! We're past the 10 years anniversary for this bug report! On a more serious note, PyLucene packaging hasn't happened in the past 10 years and it most likely won't (ever happen). If you're still interested in having this library in the tree, feel free to reopen. I'm also closing depending/blocking bugs.