When compiling fresh lucene-2.4.0, this error occurs : dev-java/lucene-2.4.0 USE="-doc -source -test" jar-core: [jar] Building jar: /var/tmp/portage/dev-java/lucene-2.4.0/work/lucene-2.4.0/build/lucene-core-2.4.0.jar [jar] Manifest is invalid: The attribute "POOL DEBUG" may not occur more than once in the same section BUILD FAILED /var/tmp/portage/dev-java/lucene-2.4.0/work/lucene-2.4.0/common-build.xml:193: The following error occurred while executing this line: /var/tmp/portage/dev-java/lucene-2.4.0/work/lucene-2.4.0/common-build.xml:263: Invalid Manifest: /var/tmp/portage/dev-java/lucene-2.4.0/work/lucene-2.4.0/build/MANIFEST.MF GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.14" JAVACFLAGS="-source 1.4 -target 1.4" COMPILER="javac" Reproducible: Always
See also invalid bug #http://bugs.gentoo.org/248673
Created attachment 203539 [details] build.log of failed lucene build I can confirm this bug on an fsck'd partition which had no errors so the comments in bug #248673 holds no truth for my particular situation. lucene-analyzers-2.3.2 also fails with a similar message. This makes me think that there is something seriously wrong with either lucene or the amd64 builds of javac. Since the JAVACFLAGS is source 1.4 and target 1.4 and the build explicitly states that it's using the 1.6 JDK I'm thinking that could be the culprit? Are 1.6 backwards compatible? sun-jdk-1.4.2.19 doesn't exist for x64 it seems so if it isn't we're in a bad spot.
Created attachment 203541 [details] MANIFEST.MF
Your system is doing something really screwy, writing bad data to the Manifest.
Ok, but _why_? And how could this happen? I'm positive that it's not hardware related so obviously people who are running into this must have something else in common. Afaik the people who've run into this are all running amd64, that's one. But else than that I'm pretty stumped. How do we proceed to narrow down what could be wrong? Other java-packages are compiling fine so our (or at least mine) JDK being completely broken can be ruled out too. Is there anyone out there on amd64 that can confirm that they don't hit this bug?
Might as well paste this too for reference: [ebuild R ] dev-java/sun-jdk-1.6.0.16 USE="X alsa -derby -doc -examples -jce -nsplugin -odbc" [ebuild N ] dev-java/lucene-2.4.0 USE="-doc -source -test"
Will this bug die in silence? As long as the problem persists this is a stopper for building multiple java related packages - including openoffice - and we're at least 3-4 people who've hit this in different bugs. This is not a random coincidence due to faulty hardware or wierd user configuration. Please?
At least not intentional wierd user configuration. ;)
Created attachment 204802 [details] emerge --info as requested on IRC, emerge --info
Created attachment 204805 [details] manifest creation straced I'm not 100% sure this is the (complete) info requested. Please contact me on irc (marinmo) or leave a comment here if there's anything I missed.
Created attachment 204807 [details] the 2nd process launched after manifest creation (strace) This is where it says something about SIGSEGV and from what I've learnt, that is never a good thing to see. :) Manifest creation PID -> 10842 This log PID -> 10844
thank's to Victor's logs, we've traced it to potentially subversion being broken. From his strace you can see it segfault, and generate it's traceback. Here's your workaround for the moment: mv /usr/bin/svnversion{,.foo} && emerge lucene && mv /usr/bin/svnversion{.foo,} Now we get to figure out why subversion is broken.
But what calls svnversion? Build system of lucene? Also post the output of: emerge -ptv subversion apr:1 apr-util
I've opened bug 286845 to trace the svn side of the failure. I'm going to patch the Ant build files to not call svnversion at all in the meantime. arfrever: yes, ant calls svnversion to generate part of the version string for the manifest file. Worse it includes stderr in the version string, and if that stderr contains a full traceback, then an invalid manifest is generated.
Just got redirected from Bug 248673. I solved this yesterday. I rebuilt a number of packages yesterday to not use the -debug flag, and that made lucene and lucene-analyzers build correctly. Subversion was one of the packages that got rebuilt. I'm testing it now to see if the debug flag could be the cause of this (rebuilding subversion with use debug, then rebuild lucene to see if it fails.) or if I just got lucky. I'll report back with results as soon as I have some.
Tim: per bug 286845 we already confirmed that USE=debug was the cause of the breakage. (specifically apr built with it).
(In reply to comment #16) > Tim: per bug 286845 we already confirmed that USE=debug was the cause of the > breakage. (specifically apr built with it). > Yeah, my bad. I noticed that shortly after posting. I tried to post on it shortly before that got discovered, but my computer at work was stupid. And then I got caught out of sync.
*** Bug 290009 has been marked as a duplicate of this bug. ***
*** Bug 297093 has been marked as a duplicate of this bug. ***
Ok, this is resolved now since bug 286845. If this comes back we can do something like: !apr[debug] in the DEPEND.
