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] dev-python/pylucene/pylucene-0.9.7.ebuild Attaching the ebuild...
Created attachment 50864 [details, diff] pylucene-makefile.patch
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 2.sys-devel/gcc-3.3.5.20050130-r1
Created attachment 59063 [details] dev-python/pylucene/pylucene-0.9.7.ebuild 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 comment #3.
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] dev-python/pylucene/pylucene-1.9.1.ebuild 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] pylucene-1.9.1.ebuild.patch 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] dev-python/pylucene-1.9.1.ebuild Updated the ebuild to work with either gcc-config or eselect-compiler.
Created attachment 90058 [details, diff] pylucene-makefile.patch updated pylucene-makefile.patch needed by the latest version of the ebuild
Created attachment 90919 [details] dev-python/pylucene-2.0.0-r1.ebuild 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] pylucene-2.0-perms.patch
Created attachment 90921 [details, diff] pylucene-2.0-nostrip.patch
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) Thoughts?
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) > Thoughts? 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] dev-python/pylucene-2.0.0-r1.ebuild New ebuild with amd64 fixes, thanks for the info!
Created attachment 94440 [details] pylucene-2.0.0-r1.ebuild 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: /usr /usr/bin /usr/bin/gcc-config /usr/lib64 /usr/lib64/misc /usr/lib64/misc/gcc-config 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. Many apologies.
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 http://downloads.osafoundation.org/PyLucene/jcc/ JCC is bundled within PyLucene, the source tarball can be downloaded seperately from http://pypi.python.org/packages/source/J/JCC/JCC-2.1.tar.gz http://pypi.python.org/pypi/JCC/2.1
(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 main tree. 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[1] 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. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
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 ;) http://overlays.gentoo.org/dev/liquidx/browser/dev-python/pylucene
FYI - an OSAF dev mentioned that pylucene has moved to apache: http://lucene.apache.org/pylucene/
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. https://overlays.gentoo.org/svn/proj/java/java-experimental/dev-python/pylucene/ (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.
