Please merge solr 1.4.0+ds1-1 (universe) from Debian testing/unstable (main)

this seems that It can be merged from debian as and when new upstream version is released

regards

It appears that a Solr 1.3/Tomcat 6 package has been release for Debian - see the last comment from Jan-Pascal on this bug report:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521009

Also the deb package files can be found here:

ftp://ftp.debian.org/debian/pool/main/s/solr/

As a follow-on, I was able to install the debian solr 1.3 packages on top of the new Karmic tomcat 6.0.20 packages. So far everything appears to be working great.

Solr 1.3 doesn't build: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560611

Solr 1.4 (1.4.0+ds1-1) is in debian unstable and testing. Ubuntu has been shipping 1.2 since hardy. It would be nice to get a fresher version of solr into Lucid. In addition to me not having to keep a copy from debian squeeze in my private repo for the next 2 years, there are some nice features in 1.4. I'd really like to take advantage of the improved replication and distribution offered in 1.4.

Debian bug tracker suggests that there is no issues with the package either, see http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=solr Debian bug 550694 is no longer relevant (see my comment on it - if it ever shows up) Bug 538229 has been a problem since 1.2 in Debian (and most likely the 1.2 debs in lucid).

The Debian ChangeLog available at http://packages.debian.org/changelogs/pool/main/s/solr/solr_1.4.0+ds1-1/changelog

Quick follow up, it looks like tomcat5.5 has been dropped from lucid, so users currently running solr with tomcat won't have any upgrade path. solr-tomcat in Debian testing/unstable depends on tomcat6.

More comments. Just looking at the ubuntu packaging, it looks like the 2 ubuntu specific patches can be dropped.

* The debian/{control,rules} changes to reenable building solr-jetty aren't needed as Debian is now shipping a jetty version of solr - see http://packages.debian.org/squeeze/solr-jetty

* It would appear that debian/patches/ubuntu_07_junit-ignore-online-tests.dpatch is covered by Debian's debian/disable-tests-that-break-on-buildd patch. the description of the patch is "Disable tests that need network access, because they fail for (some of) the autobuilders"

Thierry, can you please ack/nack this?

ACK from me. Solr needs a refresh and 1.4 is the version that actually works in Debian. It's an applicative stack that won't affect other packages (nothing depends on it). Shipping 1.2 in Lucid would not be consistent with the rest of our stack (no more tomcat5.5, in particular), and would render the solr packages basically useless (everyone would just manually install solr 1.4 from upstream).

I'll look into the merge (or sync, given comment #7) and go ahead if you grant the FFe on this.

Thierry, thanks. Approved then.

Please subscribe ubuntu-archive if you need a sync, and change the bug title accordingly.

@Dave Hall:
I looked into it, the only thing blocking Solr 1.4 is its dependency on glassfish-mail >= 1:2ur2-b04. However it would be better if we wouldn't have to upgrade glassfish as well (and ask for a FFe for that).

solr build-depends on glassfish-mail but might build with alternatives (libgnumail-java, libgeronimo-javamail-1.4-*-java). It also depends on glassfish-mail, but I fail to see where it makes use of it (since glassfish-javamail is missing in debian/solr-common.links). I'm just unsure how much it depends on JavaMail 1.4.1 (which glassfish-javamail provides).

I can try building it with libgnumail-java in a PPA, but I don't know enough of Solr to correctly exercise it: would you be available to test it if I did provide you with a package ?

Subscribing Thomas Koch, Solr maintainer in debian, to get his advice on the previous comment.

@Thierry

I tried emailing an update to launchpad earlier today, but it failed. Anyway, here it is.

On Mon, 2010-03-08 at 16:52 +0000, Thierry Carrez wrote:
> I can try building it with libgnumail-java in a PPA, but I don't know
> enough of Solr to correctly exercise it: would you be available to test
> it if I did provide you with a package ?

I should have time later this week. I will just spin it up on VM and
give it a whirl with drupal's apache solr module (my target platform)
and see how it goes. Let me know what it is ready for testing.

Thanks for sorting this.

It builds with libgnumail-java instead of glassfish-mail, and in all cases glassfish-mail didn't seem to be used at run-time (not included in the webapp classpath AFAICT).

Pushed to my ppa for testing:
https://launchpad.net/~ttx/+archive/ppa

I tested these debs and it worked fine after I installed java6-sdk and restarted jetty. I hope the dependency issue doesn't become a blocker

@Dave: Any chance you could also validate the solr-tomcat version ? Sounds ok from where I stand, but I didn't exercise it so much.

FWIW, I would like to second the points made by @Dave in his first comment on March 7th.

Among other things Solr 1.4 is required for Solr search integration with Drupal 6.
http://drupal.org/node/343467
http://drupal.org/project/apachesolr

@ttx I have never run solr with tomcat, but I'll try to find some time over the weekend to give it a go with drupal and make it works as expected.

And Solr 1.4 might be required for Solr search integration with TYPO3 4.3 and greater.

See http://forge.typo3.org/projects/show/extension-solr for details.

Hi,

I'm heavily occupied with exams right now. From what I recall, I've choosen glassfish-mail randomly to compile dataimporthandler-extras, which in the end wasn't included, because dataimporthandler-extras also depends on other packages (like tika) which are not available in Debian.
Please try to drop the glassfish-mail dependency. It should compile and run.

@Thomas: many thanks for your advice, it does in fact compile and run.

@Andreas,Noah: the FFe was granted, I'll upload this as soon as Beta1Freeze is over, no need to comment anymore on how much desirable this is :) In the mean time, please test the version in my PPA (https://launchpad.net/~ttx/+archive/ppa) to check if it works for you.

This bug was fixed in the package solr - 1.4.0+ds1-1ubuntu1

---------------
solr (1.4.0+ds1-1ubuntu1) lucid; urgency=low

  * Merge from debian testing (LP: #321889)
  * debian/control, debian/use-debian-java-libraries.diff: Switch to
    libgnumail-java for JavaMail.

solr (1.4.0+ds1-1) unstable; urgency=low

  * New upstream release (1.4.0). Closes: #559143.
  * Switched packaging to GIT. Closes: #540756.
  * Build with newest lucene version. Closes: #540756.
  * New version obsoletes Dependency bug. Closes: #521009.
  * Added japanese translation. Thanks to Hideki Yamane. Closes: #554110.
  * New Solr version builds with Lucene 2.9. Closes: #560611.
  * solr-jetty works now. Did it ever work?

solr (1.3.0+ds1-2) unstable; urgency=low

  * Moved Debian packaging source repository to git.

solr (1.3.0+ds1-1) unstable; urgency=low

  * New upstream release (1.3.0). Closes: #521009.
  * Removed dependency on javanet staxutils (see upstream issue SOLR-851).
  * Disable unit tests that need network access or otherwise break on buildds.
    Closes: #534031.
  * Change Section: to java.
  * Fix Tomcat policy for Solr 1.3.0.
  * Bump Standards-Version to 3.8.2 (no changes needed).
  * Rename solr-tomcat6 package to solr-tomcat.
  * Re-enable solr-jetty package now that Jetty6 is in sid.
  * Update watch file to automatically repackage source
  * Convert debian/copyright to machine-readable version

solr (1.2.0+ds2-6) unstable; urgency=low

  * Update dependency from tomcat5.5 to tomcat6. Closes: #526259.
  * Bump Standards-Version to 3.8.1 (no changes needed).
  * Remove dpkg-statoverride stuff from solr-tomcat6.postinst. It's not needed
    and does not work.
 -- Thierry Carrez <email address hidden> Mon, 22 Mar 2010 09:48:09 +0100

I just did 'apt-get install solr-jetty' (1.4.0+ds1-1ubuntu1) on a fresh server install of Beta 1.

Visiting http://localhost:8080/solr/ yields:
-----
HTTP ERROR 500

Problem accessing /solr/. Reason:

    Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK.
It is currently set to "/usr/lib/jvm/java-6-openjdk/jre"
Caused by:

Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK.
It is currently set to "/usr/lib/jvm/java-6-openjdk/jre"
 at org.apache.tools.ant.taskdefs.compilers.CompilerAdapterFactory.getCompiler(CompilerAdapterFactory.java:108)
        ...
-----

It seems as if a java compiler, such as the one installed by openjdk-6-jdk, is required for proper operation.
It's however not installed by default.

Installing openjdk-6-jdk fixes the issue.

While not specific to the solr package itself, minor jetty related annoyances include:
a) "/etc/init.d/jetty restart" doesn't stop Jetty if it's running
b) /etc/init.d/jetty says it binds to $HOSTNAME:8080, where HOSTNAME is given from $(uname -n), when it's in fact binding to 127.0.0.1 - which in most cases != the hostname.

@Noah: could you please file a separate bug against solr ? Sounds like an issue in jetty, but I'll have a look.

I can confirm issues with Jetty, I am on 64 bit if it make a difference.

a) /etc/init.d/jetty restart does not work correctly. jetty start and stop does work correctly.

b) /etc/init.d/jetty does not open port onto the network. I can now successfully connect to localhost:8080 but not remotely. I have tried hostname (which resolves to 127.0.0.1 so might be an issue) and my ip address of 192.168.1.200 neither give me access outside the local machine.

I can confirm the issue with SOLR but the error does not make sense, it is pointing to JRE and javac will not exist there. will look at SOLR project for that one.

I upgraded to Ubuntu 10.10. Solr now works localhost, Ubuntu 10 Solr has issues.

I cannot access port 8080 from a remote machine with the default set up. (Note that if I use the Solr start.jar in the examples directory on another port I can access it remotely.

@Ken: could you please open a new bug about your issue ? This one is about merging the latest version.