Bug 902086 (Elasticsearch) - Review request: Elasticsearch
Summary: Review request: Elasticsearch
Keywords:
Status: CLOSED RAWHIDE
Alias: Elasticsearch
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Zbigniew Jędrzejewski-Szmek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 872103 compress-lzf 1026523 1053563 1116363 1121402 1175401 1187718 1194110
Blocks: 1181564
TreeView+ depends on / blocked
 
Reported: 2013-01-20 20:16 UTC by Richard Pijnenburg
Modified: 2015-08-12 09:58 UTC (History)
23 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-24 09:59:59 UTC
zbyszek: fedora-review+
puiterwijk: fedora-cvs+


Attachments (Terms of Use)
build log for updated v1 (48.93 KB, text/plain)
2014-09-05 10:29 UTC, jiri vanek
no flags Details
gil's error log (29.81 KB, text/plain)
2014-09-11 11:42 UTC, jiri vanek
no flags Details
jvanek's error log (55.47 KB, text/plain)
2014-09-11 11:43 UTC, jiri vanek
no flags Details
v4 install failure (1.46 MB, text/plain)
2015-01-30 18:14 UTC, jiri vanek
no flags Details
elasticsearch.service (154 bytes, text/plain)
2015-02-19 04:28 UTC, Zbigniew Jędrzejewski-Szmek
no flags Details
elasticsearch.service (195 bytes, text/plain)
2015-02-19 04:30 UTC, Zbigniew Jędrzejewski-Szmek
no flags Details
elasticsearch.service (334 bytes, text/plain)
2015-02-19 22:00 UTC, Zbigniew Jędrzejewski-Szmek
no flags Details


Links
System ID Priority Status Summary Last Updated
Github elasticsearch kibana issues 1764 None None None Never

Description Richard Pijnenburg 2013-01-20 20:16:30 UTC
SPEC: https://github.com/electrical/package-elasticsearch/tree/master/RPM
RPM/SRPM: http://packages.ispavailability.com/elasticsearch/

Description: package for elasticsearch ( http://www.elasticsearch.org/ )

This is my first package for submission into EPEL and require a sponsor.
Any feedback is appreciated.

Comment 1 Jörg Prante 2013-01-22 09:01:12 UTC
Depends on Lucene. 
Rawhide package is outdated: lucene-3.6.0-11.fc19.src.rpm
Current version: Lucene 3.6.2

Comment 2 Richard Pijnenburg 2013-01-22 09:59:59 UTC
Lucene is included in the whole package / jar file.
Therefor its not an external dependency.

See: https://github.com/elasticsearch/elasticsearch/tree/master/src/main/java/org/apache/lucene

Comment 3 Jörg Prante 2013-01-22 10:18:30 UTC
Elasticsearch ships with a Maven pom.xml where Lucene is noted as external dependency. Internal dependencies are shaded.

Unfortunately, https://github.com/tavisto RPM spec (from where you started your work) did not take care of Fedora packaging guidelines at all. Please check Fedora packaging guidelines for Java.

https://fedoraproject.org/wiki/Packaging:Java

Comment 4 Peter Robinson 2014-02-05 11:49:37 UTC
(In reply to Richard Pijnenburg from comment #2)
> Lucene is included in the whole package / jar file.
> Therefor its not an external dependency.

This is against Fedora/EPEL package bundling policy. Also it's a requirement for the package to be packaged in Fedora before EPEL.

Comment 5 Volker Fröhlich 2014-02-05 12:05:06 UTC
(In reply to Peter Robinson from comment #4)
> Also it's a requirement
> for the package to be packaged in Fedora before EPEL.

That's wrong. There's no requirement to even package for Fedora at all!

Comment 6 Peter Robinson 2014-02-05 12:31:52 UTC
(In reply to Volker Fröhlich from comment #5)
> (In reply to Peter Robinson from comment #4)
> > Also it's a requirement
> > for the package to be packaged in Fedora before EPEL.
> 
> That's wrong. There's no requirement to even package for Fedora at all!

But it should be unless there's a decent reason for it not to.

Also the package should build from source and not contain bundled libraries such as Lucene. This is just packaging the precompiled bundled package from upstream.

Comment 7 Richard Pijnenburg 2014-02-05 12:45:59 UTC
We have decided to setup our own repositories at Elasticsearch to avoid the discussions at the different distro's ( like we have here now )

I think we can close this issue.

Comment 8 Jörg Prante 2014-02-05 22:10:01 UTC
What about being Elasticsearch on the Fedora package maintainers wishlist?

http://fedoraproject.org/wiki/Package_maintainers_wishlist

So if there is still interest, I could help to build all dependencies from source as Fedora packages, so an Elasticsearch package can conform to Fedora guidelines.

Some of the dependencies are: Guava, Netty, Jackson, Joda, Lucene, HPPC ...

That is quite a piece of work. The plan would be to mavenize the sources of the dependencies so they can be built with http://fedoraproject.org/wiki/Features/Simplified_Maven_Packaging

Comment 9 Volker Fröhlich 2014-02-05 22:24:22 UTC
EL 6 has no Maven. It would be great to have it on EL6 too. I'm particularly thinking about getting Logstash packaged.

Comment 10 Jörg Prante 2014-02-05 22:48:15 UTC
I would suggest packaging for RHEL7 where Maven is available.

Of course, packaging the complete ELK stack (Elasticsearch/Logstash/Kibana) makes absolutely sense, plus adding community plugins.

Comment 11 Christopher Meng 2014-02-08 08:10:55 UTC
EPEL7 is still amazing and expected.

And it's nosense to package RPMs for EPEL _only_ since EPEL is always behind Fedora.

Comment 12 Matthias Runge 2014-02-20 15:34:56 UTC
(In reply to Christopher Meng from comment #11)
> EPEL7 is still amazing and expected.
> 
> And it's nosense to package RPMs for EPEL _only_ since EPEL is always behind
> Fedora.

That is nonsense, too. There are quite a few examples for packages primarily living in EPEL, where Fedora is practically not existing, e.g. python-sphinx10

Comment 13 Peter Robinson 2014-02-20 15:47:28 UTC
> That is nonsense, too. There are quite a few examples for packages primarily
> living in EPEL, where Fedora is practically not existing, e.g.
> python-sphinx10

The only reason for something like that is where there is a requirement of shipping older releases in EPEL like an older version is needed due to the older RHEL package set (eg python 2.6) or where there's desire for multiple versions to be parallel installable. In the original bug report [1] the example you provide was intended and review for both Fedora and RHEL. In a later Fedora release it was clearly decided to drop that, possibly because the dependent applications were ported to the newer release. There continues to be python-sphinx in Fedora

[1] https://bugzilla.redhat.com/show_bug.cgi?id=648633

Comment 14 Peter Robinson 2014-02-20 15:48:32 UTC
Oh, and I forgot to mention that I don't see that the above use case is relevant here as there's no reason not to package elasticsearch for both Fedora and EPEL

Comment 15 Christopher Meng 2014-02-21 06:53:30 UTC
(In reply to Matthias Runge from comment #12)
> (In reply to Christopher Meng from comment #11)
> > EPEL7 is still amazing and expected.
> > 
> > And it's nosense to package RPMs for EPEL _only_ since EPEL is always behind
> > Fedora.
> 
> That is nonsense, too. There are quite a few examples for packages primarily
> living in EPEL, where Fedora is practically not existing, e.g.
> python-sphinx10

Bad example.

Elasticsearch 1.0 GA was just released. Listen everyone, I don't have interests anymore on arguing with people insist on building packages for EPEL only, but at least EPEL should be a better environment for building if you prefer doing this. Currently I can't see.

Also Fedora is a place for testing in some guys' opinion, so if you want to risk your consumers to test it in EPEL first, I have no idea.

-----------------------------------------------
Back to the packaging:

1. Mock build with some information provided, as it's a list for bundled libraries:

/usr/lib/elasticsearch/elasticsearch-1.0.0.jar
/usr/lib/elasticsearch/jna-3.3.0.jar
/usr/lib/elasticsearch/jts-1.12.jar
/usr/lib/elasticsearch/log4j-1.2.17.jar
/usr/lib/elasticsearch/lucene-analyzers-common-4.6.1.jar
/usr/lib/elasticsearch/lucene-codecs-4.6.1.jar
/usr/lib/elasticsearch/lucene-core-4.6.1.jar
/usr/lib/elasticsearch/lucene-grouping-4.6.1.jar
/usr/lib/elasticsearch/lucene-highlighter-4.6.1.jar
/usr/lib/elasticsearch/lucene-join-4.6.1.jar
/usr/lib/elasticsearch/lucene-memory-4.6.1.jar
/usr/lib/elasticsearch/lucene-misc-4.6.1.jar
/usr/lib/elasticsearch/lucene-queries-4.6.1.jar
/usr/lib/elasticsearch/lucene-queryparser-4.6.1.jar
/usr/lib/elasticsearch/lucene-sandbox-4.6.1.jar
/usr/lib/elasticsearch/lucene-spatial-4.6.1.jar
/usr/lib/elasticsearch/lucene-suggest-4.6.1.jar
/usr/lib/elasticsearch/sigar/sigar-1.6.4.jar
/usr/lib/elasticsearch/spatial4j-0.3.jar

2. We need to create systemd files for elasticsearch from the observation, and we even need to set vm.max_map_count via sysctl due to some issues reported on Github, we may also need to use tmpfile.d for it, too.

Comment 16 Jörg Prante 2014-02-23 11:20:37 UTC
The vm.max_map_count setting is mainly required for better memory management for virtual machines on Ubuntu/Debian, but it does not hurt to add it to the systemd startup. 

More important is increasing the file descriptor limit from 1024 to a more reasonable size (>10000 or even 65535).

Here is my idea: I would travel down the path like the Solr package build which is at

https://bugzilla.redhat.com/show_bug.cgi?id=1025904

because both depend on Lucene.

I would like to contribute to offer a source RPM, but I do not know what is the best point to start from. From what I understand I could install an F20 or RHEL7 Beta for a private build system, or both?

From there, I could build Solr RPMs, then make appropriate changes to build Elasticsearch, so they are based on the same dependencies.

I'd like to note, because of sigar and jna, that means building for a noarch target is not correct because there are architecture dependent shared libraries. There should be a build for the target x86_64.

For many reasons, 32bit i686 target will result in some runtime glitches in Elasticsearch (several memory tuning options rely on 64bit JVM). This is well aligned with RHEL7 where there is no more 32bit support. So I'm not sure if a 32bit Elasticsearch RPM target would make sense.

Comment 17 jiri vanek 2014-04-02 11:39:27 UTC
Hi! Is there any effort on this?

I would like to se elastic search in fedora. So I can assign myself as reviewer, or take this work where i stopped as maintainer.

Comment 18 Lukas Zapletal 2014-05-28 14:19:33 UTC
Please go ahead, our team is interested as well. I will be writing SELinux policy in the incoming months for it. (https://bugzilla.redhat.com/show_bug.cgi?id=1102119)

Comment 19 Volker Fröhlich 2014-05-31 21:32:06 UTC
On an attempt to totally redo the spec file, based on the actual .java files, it seems like the following are required but are not in Fedora:

- jackson-dataformat-yaml
- jackson-dataformat-cbor
- mustache
- t-digest

Comment 20 Peter Robinson 2014-05-31 22:32:55 UTC
I've been (slowly) working on packaging from source. I spoke with a number of the ES dev team at Buzzwords (http://berlinbuzzwords.de) about it and it's some what complex, although I don't believe insurmountable, in that releases are often dependent on particular versions of other java packages (or at least particular versions). I think (from my terrible java packaging experience) there's a number of missing deps. Happy to help out where possible

Comment 21 Björn 'besser82' Esser 2014-06-01 10:11:32 UTC
If there is someone needed to get the missings dependencies reviewed, you can ping me directly and I'll take care of it.

Comment 22 jiri vanek 2014-06-16 13:11:58 UTC
I will help with dependences. 


The t-digest have quite a few dependences too:(

The jackson-dataformat-cbor - https://github.com/FasterXML/jackson-dataformat-cbor - seems to be pretty simple. So I will start with this.

jackson-dataformat-yaml - https://github.com/FasterXML/jackson-dataformat-yaml - looks ok too.. will follow.

The mustache - Are we speaking about https://github.com/spullara/mustache.java or https://github.com/samskivert/jmustache (or some else? Or does not meter?)  - Will come even later...

Comment 23 Volker Fröhlich 2014-06-16 15:43:18 UTC
Thanks a lot! I attempted both jackson-dataformat{cbor,yaml} and had issues. One had a failing unit test and the other had problems with snakeyaml, if I remember correctly.

Comment 24 Volker Fröhlich 2014-07-04 10:25:45 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1116363 -- Review request for jackson-dataformat-cbor

Comment 25 jiri vanek 2014-07-09 11:18:52 UTC
Gil had made amazing job and updated/added all  jacson* (and mustache) stuff.
Ihope to move with t-digest asap.

Comment 26 jiri vanek 2014-07-31 14:31:27 UTC
So all requested dependences are done.  
Volker,Peter , were they enough?

If you encounter some more, please give a note!
//me looking forward to new spec/srpm and... rpms!

Comment 27 Jörg Prante 2014-07-31 15:32:07 UTC
Elasticsearch scripting will soon switch to Groovy by default. Groovy scripting is available in current 1.3 and will be default in 1.4

Is there an RPM for Groovy 2.3.x?

Comment 28 jiri vanek 2014-07-31 15:38:27 UTC
If it *will* swithc. Can we live fore now with released versions which do not use grovyscripting?

Comment 29 Jörg Prante 2014-07-31 15:49:59 UTC
It will switch: http://www.elasticsearch.org/blog/elasticsearch-1-3-0-released/

Groovy support is already in 1.3 but the switch to default mode was postponed to 1.4 so developers have more time to adapt.

I suggest to support Groovy from now, so you will not have trouble to add Groovy in a few weeks or so.

Comment 30 jiri vanek 2014-07-31 16:04:42 UTC
I agree. But I would not like to make it blocker for this package.

Comment 31 Jörg Prante 2014-07-31 16:21:06 UTC
FWIW here is the issue for Groovy 2.3.x https://bugzilla.redhat.com/show_bug.cgi?id=843417

Comment 32 jiri vanek 2014-08-20 16:44:30 UTC
It seems that also https://code.google.com/p/forbidden-apis/ are necessary to pack elastic search. or have I missed them?
If no, any volunteer?

Comment 33 jiri vanek 2014-08-20 18:46:43 UTC
Update - I have finished forbiddenapis package - it is completly based on gil's work and I need to comunicate  some details with him.


Another - probably - missing dep is com.mycila:license-maven-plugin:2.5  - Is it  missing in fedora to? And I'm pretty confused about it :(  https://github.com/mycila

Comment 34 jiri vanek 2014-08-21 11:21:57 UTC
ok. I'm doing something wrong or I dont know :(
Packaging the
https://github.com/mycila/license-maven-plugin
nedds
https://github.com/mycila/licenses/
which needs maven-wagon-webdav , which, although maven-wagon is packed for f21, is excluded with "missing dependences"

Checking state of webdav with maintainers now.

Comment 35 jiri vanek 2014-09-04 12:49:34 UTC
here is small update
 - the mustache is still missing. See above blocker -  I will review it soon
   - you can get ^ RPMS  from my local copy  https://jvanek.fedorapeople.org/elasticsearch/v1-reallyBad/downlaoded/gil/

Except that, some new depndences have been found, and done by myself:
 - https://jvanek.fedorapeople.org/elasticsearch/v1-reallyBad/results/forbiddenapis/
 - https://jvanek.fedorapeople.org/elasticsearch/v1-reallyBad/results/mycila-license-maven-plugin/
 - https://jvanek.fedorapeople.org/elasticsearch/v1-reallyBad/results/mycila-license/
 - https://jvanek.fedorapeople.org/elasticsearch/v1-reallyBad/results/mycila-pom/
 - https://jvanek.fedorapeople.org/elasticsearch/v1-reallyBad/results/mycila-xmltool/

Only the mycila-license-maven-plugin is needed by elastic search, but all this mycila* needs each other.
All those  rpms needs a lot of tuning before sent for review itself.

After those done, I have some spec and srpm
Spec URL: https://jvanek.fedorapeople.org/elasticsearch/v1-reallyBad/elasticsearch.spec
SRPM URL: https://jvanek.fedorapeople.org/elasticsearch/v1-reallyBad/elasticsearch-1.3.2-1.fc20.src.rpm

However this one ends with error:

[WARNING] The POM for org.mvel:mvel2:jar:2.2.0.Final is missing, no dependency information available
[WARNING] The POM for io.netty:netty:jar:3.9.1.Final is missing, no dependency information available
[WARNING] The POM for org.codehaus.groovy:groovy-all:jar:2.3.2 is missing, no dependency information available
[WARNING] The POM for org.fusesource:sigar:jar:1.6.4 is missing, no dependency information available

[ERROR] Failed to execute goal on project elasticsearch: Could not resolve dependencies for project org.elasticsearch:elasticsearch:jar:1.3.2: The following artifacts could not be resolved: org.mvel:mvel2:jar:2.2.0.Final, io.netty:netty:jar:3.9.1.Final, org.codehaus.groovy:groovy-all:jar:2.3.2, org.fusesource:sigar:jar:1.6.4: Cannot access Codehaus Snapshots (http://repository.codehaus.org/) in offline mode and the artifact org.mvel:mvel2:jar:2.2.0.Final has not been downloaded from it before. -> [Help 1]


From those I'm unhappy from netty3, which is packed  as 3.6 in f21. I have not suceeded with 3.6 used during build. But Maybe I'm doing something wrong... I have pinged mgoldmann (maintainer) and as him if he can update. (java-devel thread should be started about this)

The sigar I don't understand - as I have it as build dependency.  But I'm probably missing its java api. Which is probably not packed. However both sigar and groovy can be dropped for now (at least I think...they can be...)

The mvel2 is whole new package to be packed with probably its own chain of dependences.... /me to tired to continue today. 

Thats for now!
J.

Comment 36 jiri vanek 2014-09-04 12:54:00 UTC
> The mvel2 is whole new package to be packed with probably its own chain of
> dependences.... /me to tired to continue today. 

https://github.com/mvel/mvel/blob/master/pom.xml  :(

Comment 37 jiri vanek 2014-09-04 13:28:53 UTC
note, building  with NETTY 3.6 leads to
[WARNING] The POM for io.netty:netty:jar:SYSTEM is missing, no dependency information available

And later ot error on that.

Comment 38 gil cattaneo 2014-09-04 13:30:05 UTC
(In reply to jiri vanek from comment #25)
> Ihope to move with t-digest asap.
open https://bugzilla.redhat.com/show_bug.cgi?id=1138312

Comment 39 gil cattaneo 2014-09-04 13:33:14 UTC
(In reply to jiri vanek from comment #35)
> However this one ends with error:
> 
> [WARNING] The POM for org.mvel:mvel2:jar:2.2.0.Final is missing, no
> dependency information available
> [WARNING] The POM for io.netty:netty:jar:3.9.1.Final is missing, no
> dependency information available
> [WARNING] The POM for org.codehaus.groovy:groovy-all:jar:2.3.2 is missing,
> no dependency information available
> [WARNING] The POM for org.fusesource:sigar:jar:1.6.4 is missing, no
> dependency information available
> 
> [ERROR] Failed to execute goal on project elasticsearch: Could not resolve
> dependencies for project org.elasticsearch:elasticsearch:jar:1.3.2: The
> following artifacts could not be resolved: org.mvel:mvel2:jar:2.2.0.Final,
> io.netty:netty:jar:3.9.1.Final, org.codehaus.groovy:groovy-all:jar:2.3.2,
> org.fusesource:sigar:jar:1.6.4: Cannot access Codehaus Snapshots
sigar should be provided by
http://pkgs.fedoraproject.org/cgit/sigar.git/
https://github.com/hyperic/sigar/tree/master/bindings/java (required pom file)
> (http://repository.codehaus.org/) in offline mode and the artifact
> org.mvel:mvel2:jar:2.2.0.Final has not been downloaded from it before. ->
> [Help 1]
mvel2 is available (may be should be update)
http://pkgs.fedoraproject.org/cgit/mvel.git/

Comment 40 jiri vanek 2014-09-04 13:37:51 UTC
Yes. Sigar should but is not ;((

Oh and thanx for mvel. I was searching for mvel2 - and it is mvel-2 Although I wildchared, probably wrongly. Thats  make life much easier! (me will try mvel-2)

Comment 41 gil cattaneo 2014-09-04 13:48:43 UTC
About groovy 2.x: use gradle as build tool
see https://lists.fedoraproject.org/pipermail/java-devel/2013-October/004971.html
Now gradle 2.x series use groovy 2.x, but there are again problems with its deps
You can try to use groovy 1.x and replace the references to groovy-all (aId only for 1.x ...) with groovy (aId)

Comment 42 jiri vanek 2014-09-05 10:28:03 UTC
I would rather disable groovy now..:(

Well It seems that update of netty is not necessary, but there is exactly 100 erros to solve... see build log. 

I have updated the 
Spec URL: https://jvanek.fedorapeople.org/elasticsearch/v1-reallyBad/elasticsearch.spec
SRPM URL: https://jvanek.fedorapeople.org/elasticsearch/v1-reallyBad/elasticsearch-1.3.2-1.fc20.src.rpm


Now it starts to build:)


..For some reason.. It complains to sigar nd groovy (yes I removed them, but they should be optional :( )  Not suree baout other failures - maybe really wrong netty?

/me hands off for some time

Comment 43 jiri vanek 2014-09-05 10:29:25 UTC
Created attachment 934730 [details]
build log for updated v1

Comment 44 gil cattaneo 2014-09-05 13:36:08 UTC

(In reply to jiri vanek from comment #43)
> Created attachment 934730 [details]
> build log for updated v1

build fails because ES use:
lucene 4.9.0 (early should be update to 4.10.0)
missing build deps: groovy, and sigar java binding

Comment 45 jiri vanek 2014-09-05 21:11:13 UTC
> missing build deps: groovy, and sigar java binding

Still those two are optional for build. Is there osme trickI'm missing?

Comment 46 gil cattaneo 2014-09-05 23:12:47 UTC
you should remove src/main/java/org/elasticsearch/script/groovy
or try to use groovy 1.x with
%pom_xpath_set "pom:dependencies/pom:dependency[pom:groupId= 'org.codehaus.groovy']/pom:artifactId" groovy
%pom_xpath_set "pom:dependencies/pom:dependency[pom:groupId= 'org.codehaus.groovy']/pom:version" 1.8.9
or
sed -i "s|<artifactId>groovy-all|<artifactId>groovy|" pom.xml
sed -i "s|<version>2.3.2|<version>1.8.9|" pom.xml


and remove also src/main/java/org/elasticsearch/monitor/sigar

if you're lucky you should not use any patch :)

Comment 47 jiri vanek 2014-09-11 11:39:35 UTC
In meantime, gil helepd, and improved (rewrite?) my terrible specfile to:
https://jvanek.fedorapeople.org/elasticsearch/v1-gil-help/elasticsearch.spec
 with
https://jvanek.fedorapeople.org/elasticsearch/v1-gil-help/elasticsearch-1.3.2-remove-sigar-service.patch

Which was close to build, now when mustche  is in, and his specfile do not need my terrible mycila nor forbidenapis  packages.

and worned me before, merge with my original one to honour
remove %pom_remove_dep io.netty:netty and need to move
%if 0 # Required netty == 3.9.1.Final
BuildRequires: mvn(io.netty:netty)
...
%endif
to
# Required netty == 3.9.1.Final
BuildRequires: mvn(io.netty:netty)
%if 0
# Required lucene == 4.9.0
BuildRequires: mvn(org.apache.lucene:lucene-analyzers-common) ...
%endif
and if is possible ElasticSearch should be ported for use netty 4.x series

Which I somehow forgot, and changed his original package to try to work with netty 3.6 and  lucene 4.10:

https://jvanek.fedorapeople.org/elasticsearch/v2-stillStrange/elasticsearch.spec
https://jvanek.fedorapeople.org/elasticsearch/v2-stillStrange/elasticsearch-1.3.2-1.fc20.src.rpm

My final error was same as Gil's - no-op  with lucene 4.10

Comment 48 jiri vanek 2014-09-11 11:42:19 UTC
Created attachment 936517 [details]
gil's error log

Comment 49 jiri vanek 2014-09-11 11:43:29 UTC
Created attachment 936518 [details]
jvanek's error log

Comment 50 jiri vanek 2014-09-11 11:45:27 UTC
Later Gil noted also this:

https://github.com/elasticsearch/elasticsearch/blob/master/pom.xml
ES 2.0.0-SNAPSHOT use lucene 4.10.0.
if you have intention to import this release, you should create a patch
from here https://github.com/elasticsearch/elasticsearch/commit/223dab892144b0c8f9d073baf1598a1e3cdfa3ed

So there is hope to patch this release, or move to the snapshot version.

The second is probably better.

Comment 51 jiri vanek 2014-09-12 11:56:32 UTC
Applied https://github.com/elasticsearch/elasticsearch/commit/223dab892144b0c8f9d073baf1598a1e3cdfa3ed.patch

99 Failed hunks in 33 .rej files... No to bad....

Comment 52 jiri vanek 2014-09-25 13:19:38 UTC
As the failures were not exactly trivial, I tried to update to 1.4.beta01

https://jvanek.fedorapeople.org/elasticsearch/v3-1.4.beta01-getBetter/elasticsearch.spec
https://jvanek.fedorapeople.org/elasticsearch/v3-1.4.beta01-getBetter/elasticsearch-1.4.beta01-1.fc20.src.rpm

This is version with removed netty support, still 4 failures (not sure if lucene 4.10.0 x 4.10.1 or because of netty). Anyway I would rather move it to work with netty 3.x which is curently in rawhide, or update netty3 to 3.9.3.final (again final :) 

Work in progress!


As of lucene 4.10, this is valid only for f22

Comment 53 jiri vanek 2014-09-25 13:21:44 UTC
Netty on looks good!

only
[ERROR]   symbol:   method headers()
  location: variable nettyRequest of type HttpRequest
/builddir/build/BUILD/elasticsearch-1.4.beta01/src/main/java/org/elasticsearch/http/netty/NettyHttpChannel.java:[183,28] error: cannot find symbol
[INFO] 26 errors  

So the one thing 26 times :)

Comment 54 jiri vanek 2014-09-25 16:19:16 UTC
Programming in its purest :D

With netty3  3.9 :
https://jvanek.fedorapeople.org/elasticsearch/v3-1.4.beta01-getBetter-2/elasticsearch.spec
https://jvanek.fedorapeople.org/elasticsearch/v3-1.4.beta01-getBetter-2/elasticsearch-1.4.beta01-1.fc20.src.rpm

e get to:
[ERROR] /builddir/build/BUILD/elasticsearch-1.4.beta01/src/main/java/org/elasticsearch/threadpool/ThreadPool.java:[299,51] error: cannot find symbol
[ERROR] symbol:   method directExecutor()
[ERROR] location: class MoreExecutors
[ERROR] /builddir/build/BUILD/elasticsearch-1.4.beta01/src/main/java/org/elasticsearch/common/compress/lzf/LZFCompressedStreamOutput.java:[41,56] error: incompatible types: BufferRecycler cannot be converted to int


Which is caused by packages:
com.ning.compress.BufferRecycler;
and
import com.google.common.util.concurrent.MoreExecutors;

I have never seen project so bounded by exact versions....

continue.. somewhen...

Comment 55 Jörg Prante 2014-09-25 23:10:54 UTC
Each Elasticsearch version is tied to exact versions in the dependencies.

Please note that it is important to use exactly the version of an Elasticsearch dependency as stated in the pom.xml

One reason is, Elasticsearch uses shaded dependencies, which might not work with different versions. For example, Netty is shaded.

Other reason is, Elasticsearch might contain some (rare) fixes to existing classes in the dependencies that are not in the upstream. This is implemented by setting the elasticsearch.jar always in front of the other dependent jars to override them (for instance, Lucene, Guava, Joda, just to name the most important).

Also, more reasons are compatibility issues, e.g. Elasticsearch is strictly aligned to features in the corresponding Lucene version, and maybe other jars.

The integration tests of Elasticsearch should be executed with success to reveal such problems in the build process.

If you ignore integration testing and use other versions as defined by Elasticsearch, Elasticsearch might not work as expected, and Elasticsearch might throw obscure errors and exceptions later at runtime.

Comment 56 jiri vanek 2014-09-26 08:29:44 UTC
Hi! 
Thanx for input. Yes. I'm aware of this. However its hard tyo fulfil it. And yes - to run the testsuite is second challenge after successful build.  As (due to netty al lucene)  this is moved to f22, it give us some more time and  freedom. Maybe it is worthy to suggest this as f22 feature. It will be good excuse to force specific versions of packages.

Comment 57 gil cattaneo 2014-11-03 07:52:24 UTC
Now Lucene 4.10.1 is available in rawhide.
The version tag, in the latest spec file, seem incorrect. 
See: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages and 
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages

Should be:

%global reltag .Beta1
%global namedversion %{version}%{?reltag}

Name:          elasticsearch
Version:       1.4.0
Release:       0.1%{?reltag}%{?dist}


For other build problems. This release use:
compress-lzf 1.0.2 (available in rawhide 1.0.3)
guava 18.0 (available 17.0)

Comment 59 jiri vanek 2014-11-20 13:16:45 UTC
proposed:
https://fedoraproject.org/wiki/Changes/Elasticsearch

Comment 60 jiri vanek 2015-01-30 18:09:44 UTC
With netty updated  ( jiri vanek 2015-01-30 13:05:06 EST, Depends On: 1187718) I was able to compile ES sucessfully. however install failed with:
+ xmvn-install -R .xmvn-reactor -n elasticsearch -d /builddir/build/BUILDROOT/elasticsearch-1.4.0-0.1.Beta1.fc22.x86_64
[INFO] Installing artifact org.elasticsearch:elasticsearch:jar:1.4.0.Beta1
[INFO] Installing artifact org.elasticsearch:elasticsearch:pom:1.4.0.Beta1
[INFO] Installing artifact org.elasticsearch:elasticsearch:tar.gz:1.4.0.Beta1
[ERROR] Artifact installation failed
org.fedoraproject.xmvn.tools.install.ArtifactInstallationException: Installation repository is incapable of holding artifact org.elasticsearch:elasticsearch:tar.gz:SYSTEM
	at org.fedoraproject.xmvn.tools.install.impl.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:119)
	at org.fedoraproject.xmvn.tools.install.impl.DefaultInstaller.installArtifact(DefaultInstaller.java:222)
	at org.fedoraproject.xmvn.tools.install.impl.DefaultInstaller.install(DefaultInstaller.java:332)
	at org.fedoraproject.xmvn.tools.install.cli.InstallerCli.run(InstallerCli.java:65)
	at org.fedoraproject.xmvn.tools.install.cli.InstallerCli.main(InstallerCli.java:86)
error: Bad exit status from /var/tmp/rpm-tmp.U6qOV7 (%install)
    Bad exit status from /var/tmp/rpm-tmp.U6qOV7 (%install)


I had never seen this error

Comment 61 jiri vanek 2015-01-30 18:11:20 UTC
The error and following logs are based on:
https://jvanek.fedorapeople.org/elasticsearch/v4/elastic/

(updated blocking depndencies avaiable also: https://jvanek.fedorapeople.org/elasticsearch/v4/ )

Comment 62 jiri vanek 2015-01-30 18:14:02 UTC
Created attachment 986126 [details]
v4 install failure

Comment 63 jiri vanek 2015-01-30 18:32:04 UTC
(In reply to jiri vanek from comment #59)
> proposed:
> https://fedoraproject.org/wiki/Changes/Elasticsearch

This was approved, In FeSCo meeting log was few very interesting sentences: [1]
* though a little worried whether everyone will be able to keep all of the packages in sync over time.
* Right, this is a prime example of the tradeoff we get with strict no-bundling policies.
* I'd rather reject this for F22 and have them work tightly with the Env/Stacks group for a better F23 plan. [2]
* SCLs would be great for such change
* No, the worst case is that we can't upgrade to a newer version of one of the deps because Elasticsearch is holding it back.
*  I’d much rather not have that blanket exception[3].  Compat packages are better.
*  I could keep the +1 with assumption that the contingency is “package does not added”, but sending this back for a revision wouldn’t hurt that much. [4]
* I *really* want this to get used to solve the wider problem of "big packages with tight dep requirements". Hence why I want to make this an Env/Stacks problem. [2] [again]

[1] http://meetbot.fedoraproject.org/fedora-meeting/2015-01-07/fesco.2015-01-07-18.01.log.html
[2] I understand this as an effort to support similar cases in future
[3] for bundling
[4] not added is ok for now, but what about future breakages?

Comment 64 Zbigniew Jędrzejewski-Szmek 2015-01-30 18:41:39 UTC
I think that so far the "tight bundling requirements" have not proven to be true. What is required instead is latest (or at least recent) versions of various packages. And I think that this push has been beneficial to the distribution as a whole: various packages refreshed, more stuff packaged.

Comment 65 gil cattaneo 2015-01-30 21:32:52 UTC
(In reply to jiri vanek from comment #61)
> The error and following logs are based on:
> https://jvanek.fedorapeople.org/elasticsearch/v4/elastic/
> 
> (updated blocking depndencies avaiable also:
> https://jvanek.fedorapeople.org/elasticsearch/v4/ )

Try with

%mvn_package org.elasticsearch:elasticsearch:tar.gz:%{namedversion}  __noinstall

or remove maven-dependency-plugin and maven-assembly-plugin

Comment 66 jiri vanek 2015-01-31 06:06:19 UTC
> 
> or remove maven-dependency-plugin and maven-assembly-plugin


Thanx that helped! 
https://jvanek.fedorapeople.org/elasticsearch/v4/elastic/ updated

with
https://jvanek.fedorapeople.org/elasticsearch/v4/elastic/elasticsearch-1.4.0-0.1.Beta1.fc22.noarch.rpm
https://jvanek.fedorapeople.org/elasticsearch/v4/elastic/elasticsearch-javadoc-1.4.0-0.1.Beta1.fc22.noarch.rpm

Somehow reliable packages! However still long way to go!

Comment 67 jiri vanek 2015-02-10 10:39:38 UTC
One colleague of me have packed optional build requirements, which are now xpathed out of pom.

 https://bugzilla.redhat.com/show_bug.cgi?id=1190728
 https://bugzilla.redhat.com/show_bug.cgi?id=1190746
 https://bugzilla.redhat.com/show_bug.cgi?id=1190733
 https://bugzilla.redhat.com/show_bug.cgi?id=1190735
 https://bugzilla.redhat.com/show_bug.cgi?id=1190740

They do not block release, but will be worthy to be included.

Comment 68 jiri vanek 2015-02-16 13:18:57 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #64)
> I think that so far the "tight bundling requirements" have not proven to be
> true. What is required instead is latest (or at least recent) versions of
> various packages. And I think that this push has been beneficial to the
> distribution as a whole: various packages refreshed, more stuff packaged.

Have not? Something get updated, todays build:
[ERROR] /builddir/build/BUILD/elasticsearch-1.4.0.Beta1/src/main/java/org/elasticsearch/search/suggest/context/ContextMapping.java:[262,29] error: method determinize in class Operations cannot be applied to given types;
[ERROR]   required: Automaton,int
  found: Automaton
  reason: actual and formal argument lists differ in length

five times....:( 

/me not sure what, ghoing to fix and submit regular review

Comment 69 jiri vanek 2015-02-16 14:24:15 UTC
lucene 4.10.2->4.10.3

Comment 70 jiri vanek 2015-02-16 16:28:28 UTC
Please, this official review request on cleaned specfile:


spec: https://jvanek.fedorapeople.org/elasticsearch/review/v1/elasticsearch.spec
srpm: https://jvanek.fedorapeople.org/elasticsearch/review/v1/elasticsearch-1.4.0-0.1.Beta1.fc23.src.rpm

generally all packages and patches:
https://jvanek.fedorapeople.org/elasticsearch/review/v1/


rpmlint is printing only one warning for me:
rpmlint  *.rpm ~/Desktop/elasticv4/elasticsearch.spec 
elasticsearch.src: W: invalid-url Source0: elasticsearch-1.4.0.Beta1-fedora.tar.xz
/home/jvanek/Desktop/elasticv4/elasticsearch.spec: W: invalid-url Source0: elasticsearch-1.4.0.Beta1-fedora.tar.xz
3 packages and 1 specfiles checked; 0 errors, 2 warnings.


Which is caused by repacking of upstream tarball (have many big inaries inside)

Also note.. I'm hesitating with requires a bit....

Comment 71 gil cattaneo 2015-02-16 17:49:16 UTC
mkdir $RPM_BUILD_ROOT/usr/share/java/
# I'm not aware of any JNI being built
mv $RPM_BUILD_ROOT/%{_jnidir}/elasticsearch.jar $RPM_BUILD_ROOT/%{_javadir}/elasticsearch.jar
sed -i "s;%{_jnidir}/elasticsearch.jar;%{_javadir}/elasticsearch.jar;g" .mfiles
this is probably occur becouse a class or classes try to load/use some native libraries (jni,C,...)

http://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI

Comment 72 Zbigniew Jędrzejewski-Szmek 2015-02-17 00:56:52 UTC
- Use %license for the license file

- Consider adding (from sigar):
# Use the same directory of the main package for subpackage licence and docs
%global _docdir_fmt %{name}

- %description needs to be extended to say what this package does.

- Consider using %autosetup

- Can the tests be enabled? If this package is as brittle as it is rumored to be, tests would be beneficial.

I'd very much prefer to review the whole thing, including the .service file if one is to be added.

Comment 73 Zbigniew Jędrzejewski-Szmek 2015-02-17 01:07:31 UTC
- Consider removing explicit requires on jpackage-*. Dependency on maven-local should add it automatically. Also there's no jpackage-tools afaics.

Comment 74 gil cattaneo 2015-02-17 02:05:34 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #73)
> - Consider removing explicit requires on jpackage-*. Dependency on
> maven-local should add it automatically. Also there's no jpackage-tools
> afaics.

Must removing all Requires, our maven tools autogenerate Requires list

Comment 75 gil cattaneo 2015-02-17 02:07:34 UTC
Must removing these lines see above

mkdir $RPM_BUILD_ROOT/usr/share/java/
# I'm not aware of any JNI being built
mv $RPM_BUILD_ROOT/%{_jnidir}/elasticsearch.jar $RPM_BUILD_ROOT/%{_javadir}/elasticsearch.jar
sed -i "s;%{_jnidir}/elasticsearch.jar;%{_javadir}/elasticsearch.jar;g" .mfiles

Comment 76 gil cattaneo 2015-02-17 02:16:21 UTC
it would be better to upgrade elasticsearch to the latest stable version (1.4.3)

Comment 77 Zbigniew Jędrzejewski-Szmek 2015-02-17 02:32:20 UTC
(In reply to gil cattaneo from comment #74)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #73)
> > - Consider removing explicit requires on jpackage-*. Dependency on
> > maven-local should add it automatically. Also there's no jpackage-tools
> > afaics.
> 
> Must removing all Requires, our maven tools autogenerate Requires list
Maybe the guidelines should be updated to be clearer. Maybe something like "Packages using BR: maven-local" SHOULD NOT have explicit R: jpackage-utils or R: java-headless" after the paragraph starting with "Java binary packages or their dependencies MUST have Requires on ...".

(In reply to gil cattaneo from comment #75)
> Must removing these lines see above
> 
> mkdir $RPM_BUILD_ROOT/usr/share/java/
> # I'm not aware of any JNI being built
> mv $RPM_BUILD_ROOT/%{_jnidir}/elasticsearch.jar
> $RPM_BUILD_ROOT/%{_javadir}/elasticsearch.jar
> sed -i "s;%{_jnidir}/elasticsearch.jar;%{_javadir}/elasticsearch.jar;g"
> .mfiles
Even if it is a pure Java .jar file?

(In reply to gil cattaneo from comment #76)
> it would be better to upgrade elasticsearch to the latest stable version
> (1.4.3)
Definitely.

Comment 78 gil cattaneo 2015-02-17 03:24:35 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #77)
> (In reply to gil cattaneo from comment #74)
> > (In reply to Zbigniew Jędrzejewski-Szmek from comment #73)
> > > - Consider removing explicit requires on jpackage-*. Dependency on
> > > maven-local should add it automatically. Also there's no jpackage-tools
> > > afaics.
> > 
> > Must removing all Requires, our maven tools autogenerate Requires list
> Maybe the guidelines should be updated to be clearer. Maybe something like
> "Packages using BR: maven-local" SHOULD NOT have explicit R: jpackage-utils
> or R: java-headless" after the paragraph starting with "Java binary packages
> or their dependencies MUST have Requires on ...".
yes the guidelines should be updated

if you use ant then you must have (there is a workaround to autogenerate the required dependencies[1]) all "Requires"

see also https://mizdebsk.fedorapeople.org/xmvn/cookbook/package.html
[1] https://fedorahosted.org/released/javapackages/doc/#ant

> (In reply to gil cattaneo from comment #75)
> > Must removing these lines see above
> > 
> > mkdir $RPM_BUILD_ROOT/usr/share/java/
> > # I'm not aware of any JNI being built
> > mv $RPM_BUILD_ROOT/%{_jnidir}/elasticsearch.jar
> > $RPM_BUILD_ROOT/%{_javadir}/elasticsearch.jar
> > sed -i "s;%{_jnidir}/elasticsearch.jar;%{_javadir}/elasticsearch.jar;g"
> > .mfiles
> Even if it is a pure Java .jar file?

if maven tools install the jar file in %_jnidir is possible for the reasons i told above

> (In reply to gil cattaneo from comment #76)
> > it would be better to upgrade elasticsearch to the latest stable version
> > (1.4.3)
> Definitely.
Great!

Comment 79 gil cattaneo 2015-02-17 03:35:23 UTC
(In reply to gil cattaneo from comment #71)
this is probably occur because a class or classes try to use System.loadLibrary
> http://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI

Comment 80 Zbigniew Jędrzejewski-Szmek 2015-02-17 03:41:13 UTC
(In reply to gil cattaneo from comment #79)
> (In reply to gil cattaneo from comment #71)
> this is probably occur because a class or classes try to use
> System.loadLibrary
> > http://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI
System.load or System.loadLibrary do not appear to be used. This package uses netty-tcnative, which uses JNI. Does this count?

Comment 81 gil cattaneo 2015-02-17 04:23:47 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #80)
> (In reply to gil cattaneo from comment #79)
> > (In reply to gil cattaneo from comment #71)
> > this is probably occur because a class or classes try to use
> > System.loadLibrary
> > > http://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI
> System.load or System.loadLibrary do not appear to be used. This package
> uses netty-tcnative, which uses JNI. Does this count?

yes also use sigar native libraries
elasticsearch-1.4.0.Beta1/lib/sigar/*sigar-*.*

an other problem
Elasticsearch bundle http://iharder.net/base64 src/main/java/org/elasticsearch/common/Base64.java, available as java-base64, should be removed

Comment 82 jiri vanek 2015-02-17 14:23:34 UTC
After reformanting, this are differences between packed basae64 and included one.

--- Base64.java
+++ Base64-es.java
@@ -1,4 +1,3 @@
-package net.iharder;
 
 /**
  * <p>
@@ -238,7 +237,7 @@
     /**
      * Preferred encoding.
      */
-    private final static String PREFERRED_ENCODING = "US-ASCII";
+    public final static Charset PREFERRED_ENCODING = Charset.forName("US-ASCII");
 
     private final static byte WHITE_SPACE_ENC = -5; // Indicates white space in encoding
     private final static byte EQUALS_SIGN_ENC = -1; // Indicates equals sign in encoding
@@ -265,7 +264,6 @@
     /**
      * Translates a Base64 value to either its 6-bit reconstruction value or a
      * negative number indicating some other meaning.
-     *
      */
     private final static byte[] _STANDARD_DECODABET = {
         -9, -9, -9, -9, -9, -9, -9, -9, -9, // Decimal  0 -  8
@@ -300,6 +298,7 @@
         -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, // Decimal 231 - 243
         -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, -9 // Decimal 244 - 255
     };
+
 
     /* ********  U R L   S A F E   B A S E 6 4   A L P H A B E T  ******** */
     /**
@@ -714,13 +713,7 @@
         }   // end finally
 
         // Return value according to relevant encoding.
-        try {
-            return new String(baos.toByteArray(), PREFERRED_ENCODING);
-        } // end try
-        catch (java.io.UnsupportedEncodingException uue) {
-            // Fall back to some Java default
-            return new String(baos.toByteArray());
-        }   // end catch
+        return new String(baos.toByteArray(), PREFERRED_ENCODING);
 
     }   // end encode
 
@@ -852,12 +845,7 @@
         byte[] encoded = encodeBytesToBytes(source, off, len, options);
 
         // Return value according to relevant encoding.
-        try {
-            return new String(encoded, PREFERRED_ENCODING);
-        } // end try
-        catch (java.io.UnsupportedEncodingException uue) {
-            return new String(encoded);
-        }   // end catch
+        return new String(encoded, PREFERRED_ENCODING);
 
     }   // end encodeBytes
 
@@ -915,7 +903,7 @@
 
         if (off + len > source.length) {
             throw new IllegalArgumentException(
-                    String.format("Cannot have offset of %d and length of %d with array of length %d", off, len, source.length));
+                    String.format(Locale.ROOT, "Cannot have offset of %d and length of %d with array of length %d", off, len, source.length));
         }   // end if: off < 0
 
         // Compress?
@@ -1052,11 +1040,11 @@
             throw new NullPointerException("Destination array was null.");
         }   // end if
         if (srcOffset < 0 || srcOffset + 3 >= source.length) {
-            throw new IllegalArgumentException(String.format(
+            throw new IllegalArgumentException(String.format(Locale.ROOT,
                     "Source array with length %d cannot have offset of %d and still process four bytes.", source.length, srcOffset));
         }   // end if
         if (destOffset < 0 || destOffset + 2 >= destination.length) {
-            throw new IllegalArgumentException(String.format(
+            throw new IllegalArgumentException(String.format(Locale.ROOT,
                     "Destination array with length %d cannot have offset of %d and still store three bytes.", destination.length, destOffset));
         }   // end if
 
@@ -1152,7 +1140,7 @@
             throw new NullPointerException("Cannot decode null source array.");
         }   // end if
         if (off < 0 || off + len > source.length) {
-            throw new IllegalArgumentException(String.format(
+            throw new IllegalArgumentException(String.format(Locale.ROOT,
                     "Source array with length %d cannot have offset of %d and process %d bytes.", source.length, off, len));
         }   // end if
 
@@ -1190,14 +1178,25 @@
 
                         // If that was the equals sign, break out of 'for' loop
                         if (source[i] == EQUALS_SIGN) {
+                            // check if the equals sign is somewhere in between
+                            if (i + 1 < len + off) {
+                                throw new java.io.IOException(String.format(Locale.ROOT,
+                                        "Found equals sign at position %d of the base64 string, not at the end", i));
+                            }
                             break;
                         }   // end if: equals sign
-                    }   // end if: quartet built
+                    } // end if: quartet built
+                    else {
+                        if (source[i] == EQUALS_SIGN && len + off > i && source[i + 1] != EQUALS_SIGN) {
+                            throw new java.io.IOException(String.format(Locale.ROOT,
+                                    "Found equals sign at position %d of the base64 string, not at the end", i));
+                        } // enf if: equals sign and next character not as well
+                    } // end else:
                 }   // end if: equals sign or better
             } // end if: white space, equals sign or better
             else {
                 // There's a bad input character in the Base64 stream.
-                throw new java.io.IOException(String.format(
+                throw new java.io.IOException(String.format(Locale.ROOT,
                         "Bad Base64 input character decimal %d in array position %d", ((int) source[i]) & 0xFF, i));
             }   // end else:
         }   // each input character
@@ -1237,13 +1236,7 @@
             throw new NullPointerException("Input string was null.");
         }   // end if
 
-        byte[] bytes;
-        try {
-            bytes = s.getBytes(PREFERRED_ENCODING);
-        } // end try
-        catch (java.io.UnsupportedEncodingException uee) {
-            bytes = s.getBytes();
-        }   // end catch
+        byte[] bytes = s.getBytes(PREFERRED_ENCODING);
         //</change>
 
         // Decode
@@ -1276,7 +1269,7 @@
 
                 } // end try
                 catch (java.io.IOException e) {
-                    e.printStackTrace();
+                    // e.printStackTrace();
                     // Just return originally-decoded bytes
                 } // end catch
                 finally {
@@ -1357,7 +1350,7 @@
                     @Override
                     public Class<?> resolveClass(java.io.ObjectStreamClass streamClass)
                             throws java.io.IOException, ClassNotFoundException {
-                        Class c = Class.forName(streamClass.getName(), false, loader);
+                        Class<?> c = Class.forName(streamClass.getName(), false, loader);
                         if (c == null) {
                             return super.resolveClass(streamClass);
                         } else {


IMHO they should be upstreamed, but it is obviusly not ES way.  Looking to them, I would rather kept them bundled.

Anyway jdk8 have standart base64 api, and taht should be used.

Comment 83 jiri vanek 2015-02-17 14:26:21 UTC
As for JNI - imho pure java jars which are only using other jars which are using  jni  should not be in  /usr/lib/java , but well you know better  saso I will remove my stupid sed.

Also I had updated to 1.4.3.. theirs adaptation to lucene 4.10.3 is quite funny, but at least one patch down :)

Also Ihad removed the requires. I always forgot xmvn is doing this for us!

Thanx both for check!

Comment 84 Zbigniew Jędrzejewski-Szmek 2015-02-17 15:11:03 UTC
New spec?

Comment 85 jiri vanek 2015-02-17 16:32:31 UTC
Sorry, got busted by launcher.. se below

SPEC: https://jvanek.fedorapeople.org/elasticsearch/review/v2/elasticsearch.spec
SRPM: https://jvanek.fedorapeople.org/elasticsearch/review/v2/elasticsearch-1.4.3-0.fc23.src.rpm

rpmlint: few warnings about spelong - well the descripton os copypasted from usptream pages, blame them :). Invalid url - still same excuse. Except that:
elasticsearch.noarch: W: only-non-binary-in-usr-lib
elasticsearch.noarch: W: no-manual-page-for-binary elasticsearch

Yes, only script is there, and no man page rigth now until we decide what next.

Well luncher to make you happy/make it testbale - right now only stupid classpath collector + mainclass + japckages tool jvm detection.

Seems to be running.

Pitfalls - no service, but service is moreover only wrapper around launcher, so it have time and may be added by comaintainers.
Upstream scripts do much more things. I need to find way how to use them.

So currently only simple generated script, with big pitfall that the generationmacro was unable to hndle long classpath... Thats why the sed:(

Comment 86 gil cattaneo 2015-02-17 18:17:29 UTC
(In reply to jiri vanek from comment #82)
> After reformanting, this are differences between packed basae64 and included
> one.
> 
> --- Base64.java
> +++ Base64-es.java
> @@ -1,4 +1,3 @@
> -package net.iharder;
>  
>  /**
>   * <p>
> @@ -238,7 +237,7 @@
>      /**
>       * Preferred encoding.
>       */
> -    private final static String PREFERRED_ENCODING = "US-ASCII";
> +    public final static Charset PREFERRED_ENCODING =
> Charset.forName("US-ASCII");
>  
>      private final static byte WHITE_SPACE_ENC = -5; // Indicates white
> space in encoding
>      private final static byte EQUALS_SIGN_ENC = -1; // Indicates equals
> sign in encoding
> @@ -265,7 +264,6 @@
>      /**
>       * Translates a Base64 value to either its 6-bit reconstruction value
> or a
>       * negative number indicating some other meaning.
> -     *
>       */
>      private final static byte[] _STANDARD_DECODABET = {
>          -9, -9, -9, -9, -9, -9, -9, -9, -9, // Decimal  0 -  8
> @@ -300,6 +298,7 @@
>          -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, // Decimal 231
> - 243
>          -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, -9, -9 // Decimal 244 - 255
>      };
> +
>  
>      /* ********  U R L   S A F E   B A S E 6 4   A L P H A B E T  ********
> */
>      /**
> @@ -714,13 +713,7 @@
>          }   // end finally
>  
>          // Return value according to relevant encoding.
> -        try {
> -            return new String(baos.toByteArray(), PREFERRED_ENCODING);
> -        } // end try
> -        catch (java.io.UnsupportedEncodingException uue) {
> -            // Fall back to some Java default
> -            return new String(baos.toByteArray());
> -        }   // end catch
> +        return new String(baos.toByteArray(), PREFERRED_ENCODING);
>  
>      }   // end encode
>  
> @@ -852,12 +845,7 @@
>          byte[] encoded = encodeBytesToBytes(source, off, len, options);
>  
>          // Return value according to relevant encoding.
> -        try {
> -            return new String(encoded, PREFERRED_ENCODING);
> -        } // end try
> -        catch (java.io.UnsupportedEncodingException uue) {
> -            return new String(encoded);
> -        }   // end catch
> +        return new String(encoded, PREFERRED_ENCODING);
>  
>      }   // end encodeBytes
>  
> @@ -915,7 +903,7 @@
>  
>          if (off + len > source.length) {
>              throw new IllegalArgumentException(
> -                    String.format("Cannot have offset of %d and length of
> %d with array of length %d", off, len, source.length));
> +                    String.format(Locale.ROOT, "Cannot have offset of %d
> and length of %d with array of length %d", off, len, source.length));
>          }   // end if: off < 0
>  
>          // Compress?
> @@ -1052,11 +1040,11 @@
>              throw new NullPointerException("Destination array was null.");
>          }   // end if
>          if (srcOffset < 0 || srcOffset + 3 >= source.length) {
> -            throw new IllegalArgumentException(String.format(
> +            throw new IllegalArgumentException(String.format(Locale.ROOT,
>                      "Source array with length %d cannot have offset of %d
> and still process four bytes.", source.length, srcOffset));
>          }   // end if
>          if (destOffset < 0 || destOffset + 2 >= destination.length) {
> -            throw new IllegalArgumentException(String.format(
> +            throw new IllegalArgumentException(String.format(Locale.ROOT,
>                      "Destination array with length %d cannot have offset of
> %d and still store three bytes.", destination.length, destOffset));
>          }   // end if
>  
> @@ -1152,7 +1140,7 @@
>              throw new NullPointerException("Cannot decode null source
> array.");
>          }   // end if
>          if (off < 0 || off + len > source.length) {
> -            throw new IllegalArgumentException(String.format(
> +            throw new IllegalArgumentException(String.format(Locale.ROOT,
>                      "Source array with length %d cannot have offset of %d
> and process %d bytes.", source.length, off, len));
>          }   // end if
>  
> @@ -1190,14 +1178,25 @@
>  
>                          // If that was the equals sign, break out of 'for'
> loop
>                          if (source[i] == EQUALS_SIGN) {
> +                            // check if the equals sign is somewhere in
> between
> +                            if (i + 1 < len + off) {
> +                                throw new
> java.io.IOException(String.format(Locale.ROOT,
> +                                        "Found equals sign at position %d
> of the base64 string, not at the end", i));
> +                            }
>                              break;
>                          }   // end if: equals sign
> -                    }   // end if: quartet built
> +                    } // end if: quartet built
> +                    else {
> +                        if (source[i] == EQUALS_SIGN && len + off > i &&
> source[i + 1] != EQUALS_SIGN) {
> +                            throw new
> java.io.IOException(String.format(Locale.ROOT,
> +                                    "Found equals sign at position %d of
> the base64 string, not at the end", i));
> +                        } // enf if: equals sign and next character not as
> well
> +                    } // end else:
>                  }   // end if: equals sign or better
>              } // end if: white space, equals sign or better
>              else {
>                  // There's a bad input character in the Base64 stream.
> -                throw new java.io.IOException(String.format(
> +                throw new java.io.IOException(String.format(Locale.ROOT,
>                          "Bad Base64 input character decimal %d in array
> position %d", ((int) source[i]) & 0xFF, i));
>              }   // end else:
>          }   // each input character
> @@ -1237,13 +1236,7 @@
>              throw new NullPointerException("Input string was null.");
>          }   // end if
>  
> -        byte[] bytes;
> -        try {
> -            bytes = s.getBytes(PREFERRED_ENCODING);
> -        } // end try
> -        catch (java.io.UnsupportedEncodingException uee) {
> -            bytes = s.getBytes();
> -        }   // end catch
> +        byte[] bytes = s.getBytes(PREFERRED_ENCODING);
>          //</change>
>  
>          // Decode
> @@ -1276,7 +1269,7 @@
>  
>                  } // end try
>                  catch (java.io.IOException e) {
> -                    e.printStackTrace();
> +                    // e.printStackTrace();
>                      // Just return originally-decoded bytes
>                  } // end catch
>                  finally {
> @@ -1357,7 +1350,7 @@
>                      @Override
>                      public Class<?> resolveClass(java.io.ObjectStreamClass
> streamClass)
>                              throws java.io.IOException,
> ClassNotFoundException {
> -                        Class c = Class.forName(streamClass.getName(),
> false, loader);
> +                        Class<?> c = Class.forName(streamClass.getName(),
> false, loader);
>                          if (c == null) {
>                              return super.resolveClass(streamClass);
>                          } else {
> 
> 
> IMHO they should be upstreamed, but it is obviusly not ES way.  Looking to
> them, I would rather kept them bundled.
> 
i dont know if upstream use old newer or modified Base64
then you must open an fpc exception
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Requirement_if_you_bundle
> Anyway jdk8 have standart base64 api, and taht should be used.

Comment 87 Zbigniew Jędrzejewski-Szmek 2015-02-18 04:08:04 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #72)
> - %description needs to be extended to say what this package does.
The new text seems to have been pasted from a website. It's a promotional blurb. It even ends with "Learn more".
 
> - Consider using %autosetup
It would make the spec a bit simpler.

> - Can the tests be enabled? If this package is as brittle as it is rumored
> to be, tests would be beneficial.
I'd like an answer here too.

> I'd very much prefer to review the whole thing, including the .service file
> if one is to be added.
I gather that this will not be run as a service then, but only from the
commandline?

(In reply to gil cattaneo from comment #86)
> (In reply to jiri vanek from comment #82)
> > After reformanting, this are differences between packed basae64 and included
> > one.
> > IMHO they should be upstreamed, but it is obviusly not ES way.  Looking to
> > them, I would rather kept them bundled.
Those changes seem to be mostly cosmetic (encoding fallback, localization, and a check for illegal char).

Your choices are a) unbundling, b) bundling with FESCo exception. I'd strongly advise against asking for a bundling exception, especially that in this case it simply does not seem worth it, and might cause this package to miss Alpha Freeze, and is likely to be denied. I'd suggest instead opening a bug against java-base64 to look at those changes and incorporate / upstream them if they look OK. ElasticSearch will almost certainly work fine without them, so the package can be approved without waiting for them.

Comment 88 jiri vanek 2015-02-18 18:05:07 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #87)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #72)
> > - %description needs to be extended to say what this package does.
> The new text seems to have been pasted from a website. It's a promotional
> blurb. It even ends with "Learn more".
>  
> > - Consider using %autosetup
> It would make the spec a bit simpler.

I still not gert used to it. Please submit patch for me to this issue. Or allow me with this oldschool approach.

> 
> > - Can the tests be enabled? If this package is as brittle as it is rumored
> > to be, tests would be beneficial.
> I'd like an answer here too.

Sorry - forgot to it. 
To enable tests quite a lot of dependencies are needed. IMHO it is not possible to make a deadline with them, but on long term they will be pretty necessary.

Si yes, I definitely agre with tests, but considering the date of deadline and my free time, I would like to avid it now.

> 
> > I'd very much prefer to review the whole thing, including the .service file
> > if one is to be added.
> I gather that this will not be run as a service then, but only from the
> commandline?

I'm not against service, we (me) is just runnoing out of time a bit. Service may be added sooner or later. I hope a bit you (and maybe more CC fromthis bug) will become a comaintainer(s) after review  and implement those missing features.

> 
> (In reply to gil cattaneo from comment #86)
> > (In reply to jiri vanek from comment #82)
> > > After reformanting, this are differences between packed basae64 and included
> > > one.
> > > IMHO they should be upstreamed, but it is obviusly not ES way.  Looking to
> > > them, I would rather kept them bundled.
> Those changes seem to be mostly cosmetic (encoding fallback, localization,
> and a check for illegal char).


Unluckily - mostly. If it would be only the the charset stuf, then I would be ok with removal.  But the check for invlaid charactter? I would say we can expect problems here.

> 
> Your choices are a) unbundling, b) bundling with FESCo exception. I'd
> strongly advise against asking for a bundling exception, especially that in
> this case it simply does not seem worth it, and might cause this package to
> miss Alpha Freeze, and is likely to be denied. I'd suggest instead opening a
> bug against java-base64 to look at those changes and incorporate / upstream
> them if they look OK. ElasticSearch will almost certainly work fine without
> them, so the package can be approved without waiting for them.

Yes, C is right.

Upstream changes and then make ES to use this nev version.

I would like to go with B now, and in lifetime move to C.

Actually - Gil - is it acceptable for you to include patch in RPMs? ( I guess not, and also I'm not advising it, just asking)

Comment 89 Zbigniew Jędrzejewski-Szmek 2015-02-18 18:26:30 UTC
Yikes, https://fedorahosted.org/fesco/ticket/1415 should have been for FPC. Sorry for getting them mixed up in my comment.

Comment 90 Zbigniew Jędrzejewski-Szmek 2015-02-18 18:39:23 UTC
(In reply to jiri vanek from comment #88)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #87)
> > (In reply to Zbigniew Jędrzejewski-Szmek from comment #72)
> > > - %description needs to be extended to say what this package does.
> > The new text seems to have been pasted from a website. It's a promotional
> > blurb. It even ends with "Learn more".
> >  
> > > - Consider using %autosetup
> > It would make the spec a bit simpler.
> 
> I still not gert used to it. Please submit patch for me to this issue. Or
> allow me with this oldschool approach.
Basically it's:
- %setup -q -n elasticsearch-%{namedversion}
- %patch0 -p0
- #%%patch1 -p0
+ %autosetup -n elasticsearch-%{namedversion}

Certainly not a requirement, but it makes it easier to keep the list of patches
and their application in sync.

> > > - Can the tests be enabled? If this package is as brittle as it is rumored
> > > to be, tests would be beneficial.
> > I'd like an answer here too.
> 
> Sorry - forgot to it. 
> To enable tests quite a lot of dependencies are needed. IMHO it is not
> possible to make a deadline with them, but on long term they will be pretty
> necessary.
> 
> Si yes, I definitely agre with tests, but considering the date of deadline
> and my free time, I would like to avid it now.
OK.

> > > I'd very much prefer to review the whole thing, including the .service file
> > > if one is to be added.
> > I gather that this will not be run as a service then, but only from the
> > commandline?
> 
> I'm not against service, we (me) is just runnoing out of time a bit. Service
> may be added sooner or later. I hope a bit you (and maybe more CC fromthis
> bug) will become a comaintainer(s) after review  and implement those missing
> features.

The problem is that elasticsearch is a daemon, so having a service file is actually
required by the Guidelines. Shouldn't be too hard, though java daemons have some
tricky corners. I'll give it a go.

> > (In reply to gil cattaneo from comment #86)
> > > (In reply to jiri vanek from comment #82)
> > > > After reformanting, this are differences between packed basae64 and included
> > > > one.
> > > > IMHO they should be upstreamed, but it is obviusly not ES way.  Looking to
> > > > them, I would rather kept them bundled.
> > Those changes seem to be mostly cosmetic (encoding fallback, localization,
> > and a check for illegal char).
> 
> 
> Unluckily - mostly. If it would be only the the charset stuf, then I would
> be ok with removal.  But the check for invlaid charactter? I would say we
> can expect problems here.
I don't think so. It'll skip part of an invalid input, instead of erroring out.
You don't expect to feed bad input into it in the normal case, and both
ways to handle invalid input are acceptable, although of course catching it
properly is nicer. But this is the kind of patch that should be acceptable
in the java-base64 package.
 
> > Your choices are a) unbundling, b) bundling with FESCo exception. 
Sorry once again for replacing FPC with FESCo here.

Comment 91 Mikolaj Izdebski 2015-02-18 20:23:06 UTC
My comment as Maven/XMvn maintainer: %mvn_install installs JARs to %_javadir unless it can find evidence that JAR is using JNI. If you enable debugging (%mvn_install -X) you should see why given JAR is considered as JNI and installed to %_jnidir. If this is incorrect then please file a bug and I'll be happy to fix that.

Requires on most stuff, including mvn(*), java-headless and jpackage-utils should be generated automatically and there is no need to explicitly list them in the spec file. Besides that some requires like mvn(org.apache.maven.plugins:maven-dependency-plugin) or mvn(org.sonatype.oss:oss-parent:pom:) look wrong - these are development packages usually needed for building only.

Comment 92 gil cattaneo 2015-02-18 23:05:09 UTC
(In reply to jiri vanek from comment #88)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #87)
> > (In reply to Zbigniew Jędrzejewski-Szmek from comment #72)

> Actually - Gil - is it acceptable for you to include patch in RPMs?
done, java-base64-2.3.8-7.fc23. please, try if ElasticSearch work/build with the applied changes in Base64

Comment 93 Zbigniew Jędrzejewski-Szmek 2015-02-19 04:24:16 UTC
Running /usr/bin/elasticsearch:
/usr/bin/build-classpath: Unable to execute xmvn-resolve.
/usr/bin/build-classpath: Make sure that XMvn is installed and M2_HOME is set correctly.
...
/usr/bin/build-classpath: error: Some specified jars were not found
Exception in thread "main" java.lang.NoClassDefFoundError: com/google/common/collect/ImmutableMap
	at org.elasticsearch.common.settings.ImmutableSettings.<init>(ImmutableSettings.java:65)
	at org.elasticsearch.common.settings.ImmutableSettings$Builder.build(ImmutableSettings.java:1077)
	at org.elasticsearch.common.settings.ImmutableSettings.<clinit>(ImmutableSettings.java:57)
	at org.elasticsearch.common.settings.ImmutableSettings$Builder.build(ImmutableSettings.java:1077)
	at org.elasticsearch.common.settings.ImmutableSettings$Builder.<clinit>(ImmutableSettings.java:664)
	at org.elasticsearch.bootstrap.Bootstrap.initialSettings(Bootstrap.java:106)
	at org.elasticsearch.bootstrap.Bootstrap.main(Bootstrap.java:177)
	at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:32)
Caused by: java.lang.ClassNotFoundException: com.google.common.collect.ImmutableMap
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	... 8 more

This seems to be a bug in build-classpath. I'll file a bug.

After I install xmvn:
$ elasticsearch 
Feb 18, 2015 10:56:21 PM org.elasticsearch.node.internal.InternalNode <init>
INFO: [Grasshopper II] version[1.4.3], pid[7546], build[${build/NA]
Feb 18, 2015 10:56:21 PM org.elasticsearch.node.internal.InternalNode <init>
INFO: [Grasshopper II] initializing ...
Feb 18, 2015 10:56:21 PM org.elasticsearch.plugins.PluginsService <init>
INFO: [Grasshopper II] loaded [], sites []
Feb 18, 2015 10:56:23 PM org.elasticsearch.bootstrap.Bootstrap main
SEVERE: {1.4.3}: Initialization Failed ...
- ExecutionError[java.lang.NoClassDefFoundError: org/apache/lucene/sandbox/queries/FuzzyLikeThisQuery]
	NoClassDefFoundError[org/apache/lucene/sandbox/queries/FuzzyLikeThisQuery]
		ClassNotFoundException[org.apache.lucene.sandbox.queries.FuzzyLikeThisQuery]

It seems lucene-sandbox has to be added to the script. With that added, it seems to run fine and to respond to commands.

First question: why would anyone ever run elasticsearch manually? It seem that the script
could be moved to /usr/libexec or somewhere.

Second question: elasticsearch listens on 0.0.0.0:9200 by default, accepting commands from the internet. 
This has to be fixed. Maybe a default configuration to limit it to ::1 should be added. I don't know what,
but something has to be done.

Finally: I promised to start with a service file. I'll attach one in a moment that should be good enough as a starting point. Its main limitation is that elasticsearch runs as Type=simple, so systemd cannot tell when it is ready to service requests. Two possible solutions: first, add notifications and turn elasticsearch into Type=notify. Second, actually better, add socket activation. Both require upstream changes so I guess we can leave them for the future.

Comment 94 Zbigniew Jędrzejewski-Szmek 2015-02-19 04:28:37 UTC
Created attachment 993402 [details]
elasticsearch.service

Comment 95 Zbigniew Jędrzejewski-Szmek 2015-02-19 04:30:06 UTC
Created attachment 993403 [details]
elasticsearch.service

Comment 96 gil cattaneo 2015-02-19 04:35:24 UTC
CP="%{name} com.carrotsearch:hppc com.fasterxml.jackson.core:jackson-core com.fasterxml.jackson.dataformat:jackson-dataformat-cbor com.fasterxml.jackson.dataformat:jackson-dataformat-smile com.fasterxml.jackson.dataformat:jackson-dataformat-yaml com.google.guava:guava com.ning:compress-lzf com.tdunning:t-digest commons-cli:commons-cli io.netty:netty:3.9.3.Final joda-time:joda-time org.antlr:antlr-runtime org.apache.commons:commons-lang3 org.apache.lucene:lucene-analyzers-common org.apache.lucene:lucene-core org.apache.lucene:lucene-highlighter org.apache.lucene:lucene-join org.apache.lucene:lucene-memory org.apache.lucene:lucene-queries org.apache.lucene:lucene-queryparser org.apache.lucene:lucene-spatial org.apache.lucene:lucene-suggest org.joda:joda-convert"


you could make it a little more readable? using the proper JARs

e.g.

CP="%{name} hppc jackson-core jackson-dataformat-cbor jackson-dataformat-smile jackson-dataformat-yaml guava compress-lzf ....

Comment 97 jiri vanek 2015-02-19 10:45:20 UTC
(In reply to Mikolaj Izdebski from comment #91)
> My comment as Maven/XMvn maintainer: %mvn_install installs JARs to %_javadir
> unless it can find evidence that JAR is using JNI. If you enable debugging
> (%mvn_install -X) you should see why given JAR is considered as JNI and
> installed to %_jnidir. If this is incorrect then please file a bug and I'll
> be happy to fix that.
> 
> Requires on most stuff, including mvn(*), java-headless and jpackage-utils
> should be generated automatically and there is no need to explicitly list
> them in the spec file. Besides that some requires like
> mvn(org.apache.maven.plugins:maven-dependency-plugin) or
> mvn(org.sonatype.oss:oss-parent:pom:) look wrong - these are development
> packages usually needed for building only.

Thanx for explanations. I run with -X and found nothing inmortant. Maybe your sharp eye will see more

https://jvanek.fedorapeople.org/elasticsearch/review/v3/mavenInstall-X

Comment 98 jiri vanek 2015-02-19 10:46:24 UTC
(In reply to gil cattaneo from comment #96)
> CP="%{name} com.carrotsearch:hppc com.fasterxml.jackson.core:jackson-core
...
> org.apache.lucene:lucene-suggest org.joda:joda-convert"
> 
> 
> you could make it a little more readable? using the proper JARs
> 
> e.g.
> 
> CP="%{name} hppc jackson-core jackson-dataformat-cbor
> jackson-dataformat-smile jackson-dataformat-yaml guava compress-lzf ....

Done. However reuslting classpath is a big longer...

https://jvanek.fedorapeople.org/elasticsearch/review/v3/classpaths

Comment 99 Mikolaj Izdebski 2015-02-19 10:49:10 UTC
(In reply to jiri vanek from comment #97)
> Thanx for explanations. I run with -X and found nothing inmortant. Maybe
> your sharp eye will see more
> 
> https://jvanek.fedorapeople.org/elasticsearch/review/v3/mavenInstall-X

[DEBUG] Native method mlockall(null) found in /builddir/build/BUILD/elasticsearch-1.4.3/target/elasticsearch-1.4.3.jar: org/elasticsearch/common/jna/CLibrary.class

https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/common/jna/CLibrary.java

Comment 100 jiri vanek 2015-02-19 10:51:57 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #93)
> Running /usr/bin/elasticsearch:
> /usr/bin/build-classpath: Unable to execute xmvn-resolve.
> /usr/bin/build-classpath: Make sure that XMvn is installed and M2_HOME is
> set correctly.
> ...
> /usr/bin/build-classpath: error: Some specified jars were not found
> Exception in thread "main" java.lang.NoClassDefFoundError:
> com/google/common/collect/ImmutableMap
> 	at
> org.elasticsearch.common.settings.ImmutableSettings.<init>(ImmutableSettings.
> java:65)
> 	at
> org.elasticsearch.common.settings.ImmutableSettings$Builder.
> build(ImmutableSettings.java:1077)
> 	at
> org.elasticsearch.common.settings.ImmutableSettings.
> <clinit>(ImmutableSettings.java:57)
> 	at
> org.elasticsearch.common.settings.ImmutableSettings$Builder.
> build(ImmutableSettings.java:1077)
> 	at
> org.elasticsearch.common.settings.ImmutableSettings$Builder.
> <clinit>(ImmutableSettings.java:664)
> 	at org.elasticsearch.bootstrap.Bootstrap.initialSettings(Bootstrap.java:106)
> 	at org.elasticsearch.bootstrap.Bootstrap.main(Bootstrap.java:177)
> 	at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:32)
> Caused by: java.lang.ClassNotFoundException:
> com.google.common.collect.ImmutableMap
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> 	... 8 more
> 
> This seems to be a bug in build-classpath. I'll file a bug.

According to 1194110, I have added the depndence. 

The only remaing artifact on build-classapth list is io.netty:netty:3.9.3.Final.  It was not working for me with package name.

If it is fixed, then the depndence can be removed again.
> 
> After I install xmvn:
> $ elasticsearch 
> Feb 18, 2015 10:56:21 PM org.elasticsearch.node.internal.InternalNode <init>
> INFO: [Grasshopper II] version[1.4.3], pid[7546], build[${build/NA]
> Feb 18, 2015 10:56:21 PM org.elasticsearch.node.internal.InternalNode <init>
> INFO: [Grasshopper II] initializing ...
> Feb 18, 2015 10:56:21 PM org.elasticsearch.plugins.PluginsService <init>
> INFO: [Grasshopper II] loaded [], sites []
> Feb 18, 2015 10:56:23 PM org.elasticsearch.bootstrap.Bootstrap main
> SEVERE: {1.4.3}: Initialization Failed ...
> - ExecutionError[java.lang.NoClassDefFoundError:
> org/apache/lucene/sandbox/queries/FuzzyLikeThisQuery]
> 	NoClassDefFoundError[org/apache/lucene/sandbox/queries/FuzzyLikeThisQuery]
> 	
> ClassNotFoundException[org.apache.lucene.sandbox.queries.FuzzyLikeThisQuery]
> 
> It seems lucene-sandbox has to be added to the script. With that added, it
> seems to run fine and to respond to commands.

added.

> 
> First question: why would anyone ever run elasticsearch manually? It seem
I would :)

> that the script
> could be moved to /usr/libexec or somewhere.

Anyway I agree it is rare case. I moved the script as you wished.

> 
> Second question: elasticsearch listens on 0.0.0.0:9200 by default, accepting
> commands from the internet. 
> This has to be fixed. Maybe a default configuration to limit it to ::1
> should be added. I don't know what,
> but something has to be done.

Afaik no simple option here. The firewalld shopud do this job or any other deployment tool like nginx  or similar...
> 
> Finally: I promised to start with a service file. I'll attach one in a
> moment that should be good enough as a starting point. Its main limitation
> is that elasticsearch runs as Type=simple, so systemd cannot tell when it is

Thank you . Included on my best, although I ddont have much experience with packaging services. (moreover walked through guidelines..)

> ready to service requests. Two possible solutions: first, add notifications
> and turn elasticsearch into Type=notify. Second, actually better, add socket
> activation. Both require upstream changes so I guess we can leave them for
> the future.

Comment 101 jiri vanek 2015-02-19 10:55:13 UTC
(In reply to Mikolaj Izdebski from comment #99)
> (In reply to jiri vanek from comment #97)
> > Thanx for explanations. I run with -X and found nothing inmortant. Maybe
> > your sharp eye will see more
> > 
> > https://jvanek.fedorapeople.org/elasticsearch/review/v3/mavenInstall-X
> 
> [DEBUG] Native method mlockall(null) found in
> /builddir/build/BUILD/elasticsearch-1.4.3/target/elasticsearch-1.4.3.jar:
> org/elasticsearch/common/jna/CLibrary.class
> 
> https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/
> elasticsearch/common/jna/CLibrary.java

I see. Well it is optional to use this agent, and we are not runnig it with it (iiuc). 

Anyway there is probably no need to fight with mvn_install.

Comment 102 jiri vanek 2015-02-19 10:59:15 UTC
SPEC: https://jvanek.fedorapeople.org/elasticsearch/review/v3/elasticsearch.spec
SRPM: https://jvanek.fedorapeople.org/elasticsearch/review/v3/elasticsearch-1.4.3-0.fc23.src.rpm

This is still version with bundled java-base64. I'm trying to work with depndent one right now

Comment 103 gil cattaneo 2015-02-19 11:04:45 UTC
(In reply to jiri vanek from comment #98)
> (In reply to gil cattaneo from comment #96)
> > CP="%{name} com.carrotsearch:hppc com.fasterxml.jackson.core:jackson-core
> ...
> > org.apache.lucene:lucene-suggest org.joda:joda-convert"
> > 
> > 
> > you could make it a little more readable? using the proper JARs
> > 
> > e.g.
> > 
> > CP="%{name} hppc jackson-core jackson-dataformat-cbor
> > jackson-dataformat-smile jackson-dataformat-yaml guava compress-lzf ....
> 
> Done. However reuslting classpath is a big longer...
> 
> https://jvanek.fedorapeople.org/elasticsearch/review/v3/classpaths

This is only for generate the script? you should use only javapackage-tools instead of xmvn/maven-local/javapackage-local
e.g.

CP="%{name} hppc jackson-core jackson-dataformat-cbor  jackson-dataformat-smile jackson-dataformat-yaml guava compress-lzf t-digest commons-cli netty3 joda-time antlr-runtime commons-lang3 lucene/lucene-analyzers-common lucene/lucene-core lucene/lucene-highlighter org.apache.lucene:lucene-join lucene/lucene-memory lucene/lucene-queries lucene/lucene-queryparser lucene/lucene-spatial lucene/lucene-suggest joda-convert"

or better
CP="%{name} hppc jackson-core jackson-dataformat-cbor  jackson-dataformat-smile jackson-dataformat-yaml guava compress-lzf t-digest commons-cli netty3 joda-time antlr-runtime commons-lang3 lucene joda-convert"

for netty3 i dont know if is correct, maybe netty3-3.9.3 ...

Comment 104 Mikolaj Izdebski 2015-02-19 11:07:09 UTC
(In reply to gil cattaneo from comment #103)
> for netty3 i dont know if is correct, maybe netty3-3.9.3 ...

"netty3-3.9.3" is correct, "netty3" won't work.

Comment 105 gil cattaneo 2015-02-19 11:10:39 UTC
then 
%jpackage_script org.elasticsearch.bootstrap.Elasticsearch "" ""  "%{name}:hppc:jackson-core:jackson-dataformat-cbor:jackson-dataformat-smile:jackson-dataformat-yaml:guava:compress-lzf:t-digest:commons-cli:netty3-3.9.3:joda-time:antlr-runtime:commons-lang3:lucene:joda-convert" %{name}  true

or

%jpackage_script org.elasticsearch.bootstrap.Elasticsearch "" ""  "%{name}:hppc:jackson-core:jackson-dataformat-cbor:jackson-dataformat-smile:jackson-dataformat-yaml:guava:compress-lzf:t-digest:commons-cli:netty3-3.9.3:joda-time:antlr-runtime:commons-lang3:lucene/lucene-analyzers-common:lucene/lucene-core:lucene/lucene-highlighter:lucene-join:lucene/lucene-memory:lucene/lucene-queries:lucene/lucene-queryparser:lucene/lucene-spatial:lucene/lucene-suggest:joda-convert" %{name}  true

Comment 106 gil cattaneo 2015-02-19 11:27:14 UTC
%license LICENSE.txt 
%doc NOTICE.txt

NOTICE.txt is part of the license  should be added to the %license macro
%license LICENSE.txt NOTICE.txt

Comment 107 jiri vanek 2015-02-19 11:45:33 UTC
ES is not working with packages-like classpath. I will turn back to maven-like

Comment 108 jiri vanek 2015-02-19 11:46:18 UTC
(In reply to gil cattaneo from comment #105)
> then 
> %jpackage_script org.elasticsearch.bootstrap.Elasticsearch "" "" 
> "%{name}:hppc:jackson-core:jackson-dataformat-cbor:jackson-dataformat-smile:
> jackson-dataformat-yaml:guava:compress-lzf:t-digest:commons-cli:netty3-3.9.3:
> joda-time:antlr-runtime:commons-lang3:lucene:joda-convert" %{name}  true
> 
> or
> 
> %jpackage_script org.elasticsearch.bootstrap.Elasticsearch "" "" 
> "%{name}:hppc:jackson-core:jackson-dataformat-cbor:jackson-dataformat-smile:
> jackson-dataformat-yaml:guava:compress-lzf:t-digest:commons-cli:netty3-3.9.3:
> joda-time:antlr-runtime:commons-lang3:lucene/lucene-analyzers-common:lucene/
> lucene-core:lucene/lucene-highlighter:lucene-join:lucene/lucene-memory:
> lucene/lucene-queries:lucene/lucene-queryparser:lucene/lucene-spatial:lucene/
> lucene-suggest:joda-convert" %{name}  true

Where did you find it should  works? It dont works for me.

Comment 109 jiri vanek 2015-02-19 11:47:36 UTC
(In reply to Mikolaj Izdebski from comment #104)
> (In reply to gil cattaneo from comment #103)
> > for netty3 i dont know if is correct, maybe netty3-3.9.3 ...
> 
> "netty3-3.9.3" is correct, "netty3" won't work.

Yes. I already found this. Just dont know why.

Comment 110 Mikolaj Izdebski 2015-02-19 11:50:04 UTC
(In reply to jiri vanek from comment #109)
> (In reply to Mikolaj Izdebski from comment #104)
> > (In reply to gil cattaneo from comment #103)
> > > for netty3 i dont know if is correct, maybe netty3-3.9.3 ...
> > 
> > "netty3-3.9.3" is correct, "netty3" won't work.
> 
> Yes. I already found this. Just dont know why.

Because there is no netty3.jar or netty3/ directory under /usr/share/java* or /usr/lib/java*. To see what locations are checked you can run: JAVAPACKAGES_DEBUG=1 build-classpath netty3

Comment 111 gil cattaneo 2015-02-19 11:55:30 UTC
(In reply to jiri vanek from comment #108)
> (In reply to gil cattaneo from comment #105)
> > then 
> > %jpackage_script org.elasticsearch.bootstrap.Elasticsearch "" "" 
> > "%{name}:hppc:jackson-core:jackson-dataformat-cbor:jackson-dataformat-smile:
> > jackson-dataformat-yaml:guava:compress-lzf:t-digest:commons-cli:netty3-3.9.3:
> > joda-time:antlr-runtime:commons-lang3:lucene:joda-convert" %{name}  true
> > 
> > or
> > 
> > %jpackage_script org.elasticsearch.bootstrap.Elasticsearch "" "" 
> > "%{name}:hppc:jackson-core:jackson-dataformat-cbor:jackson-dataformat-smile:
> > jackson-dataformat-yaml:guava:compress-lzf:t-digest:commons-cli:netty3-3.9.3:
> > joda-time:antlr-runtime:commons-lang3:lucene/lucene-analyzers-common:lucene/
> > lucene-core:lucene/lucene-highlighter:lucene-join:lucene/lucene-memory:
> > lucene/lucene-queries:lucene/lucene-queryparser:lucene/lucene-spatial:lucene/
> > lucene-suggest:joda-convert" %{name}  true
> 
> Where did you find it should  works? It dont works for me.

i use always this sintax for a launcher script and still work ...
i forgotten lucene-sandbox

Comment 112 jiri vanek 2015-02-19 11:57:33 UTC
build-classpath elasticsearch:hppc:jackson-core:jackson-dataformat-cbor:jackson-dataformat-smile:jackson-dataformat-yaml:guava:compress-lzf:t-digest:commons-cli:netty3-3.9.3:joda-time:antlr-runtime:commons-lang3:lucent:joda-conver 
[ERROR] Illegal artifact coordinates elasticsearch:hppc:jackson-core:jackson-dataformat-cbor:jackson-dataformat-smile:jackson-dataformat-yaml:guava:compress-lzf:t-digest:commons-cli:netty3-3.9.3:joda-time:antlr-runtime:commons-lang3:lucene:joda-convert, expected coordinates in format <groupId>:<artifactId>[:<extension>[:<classifier>]]:[<version>]

/usr/bin/build-classpath: error: Some specified jars were not found

Comment 113 jiri vanek 2015-02-19 11:59:13 UTC
build classapth is expecting space (or better $IFS) separated list. It can not work.

Anyway Currently I don't work  neither with maven-like nor package-like nuild-classpath arguments

Comment 114 jiri vanek 2015-02-19 12:47:01 UTC
Hmm. I turned back to package-like build-classpath (it is many times faster then maven like one) and it works for me again.

There canbe only one solution for me - not all dependeces are listed automatically, because I run those test on clean system, and yum pulled what read from rpm.

v3 updated:
SPEC: https://jvanek.fedorapeople.org/elasticsearch/review/v3/elasticsearch.spec
SRPM: https://jvanek.fedorapeople.org/elasticsearch/review/v3/elasticsearch-1.4.3-0.fc23.src.rpm

This is still version with bundled java-base64. I'm trying to work with depndent one right now

Comment 115 Zbigniew Jędrzejewski-Szmek 2015-02-19 13:20:25 UTC
(In reply to jiri vanek from comment #100)
> > Second question: elasticsearch listens on 0.0.0.0:9200 by default, accepting
> > commands from the internet. 
> > This has to be fixed. Maybe a default configuration to limit it to ::1
> > should be added. I don't know what,
> > but something has to be done.
> 
> Afaik no simple option here. The firewalld shopud do this job or any other
> deployment tool like nginx  or similar...
The problem is that Workstation product runs with firewall disabled. People might install ES without realizing that it listens on the network by default. Even if it is documented somewhere. It is also very likely that ES will become a dependency of other packages. Having it default to accepting commands from the network seems like something that will bite our users. "Secure by default" is the general principle.

> > Finally: I promised to start with a service file. I'll attach one in a
> > moment that should be good enough as a starting point. Its main limitation
> > is that elasticsearch runs as Type=simple, so systemd cannot tell when it is
> 
> Thank you . Included on my best, although I ddont have much experience with
> packaging services. (moreover walked through guidelines..)
Looks fine.

Comment 116 jiri vanek 2015-02-19 13:32:13 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #115)
> (In reply to jiri vanek from comment #100)
> > > Second question: elasticsearch listens on 0.0.0.0:9200 by default, accepting
> > > commands from the internet. 
> > > This has to be fixed. Maybe a default configuration to limit it to ::1
> > > should be added. I don't know what,
> > > but something has to be done.
> > 
> > Afaik no simple option here. The firewalld shopud do this job or any other
> > deployment tool like nginx  or similar...
> The problem is that Workstation product runs with firewall disabled. People

How come? Wasnt it vice versa until recently?

> might install ES without realizing that it listens on the network by
> default. Even if it is documented somewhere. It is also very likely that ES
> will become a dependency of other packages. Having it default to accepting
> commands from the network seems like something that will bite our users.
> "Secure by default" is the general principle.
> 
Hmm. I agree. But currently  no idea. Crap.

Comment 117 jiri vanek 2015-02-19 13:36:29 UTC
(In reply to jiri vanek from comment #114)
> Hmm. I turned back to package-like build-classpath (it is many times faster
> then maven like one) and it works for me again.
> 
> There canbe only one solution for me - not all dependeces are listed
> automatically, because I run those test on clean system, and yum pulled what
> read from rpm.
> 
> v3 updated:
> SPEC:
> https://jvanek.fedorapeople.org/elasticsearch/review/v3/elasticsearch.spec
> SRPM:
> https://jvanek.fedorapeople.org/elasticsearch/review/v3/elasticsearch-1.4.3-
> 0.fc23.src.rpm
> 
> This is still version with bundled java-base64. I'm trying to work with
> depndent one right now

hm. Some subset of following:
Installed:
  apache-commons-configuration.noarch 0:1.10-4.fc22                             
  apache-commons-jxpath.noarch 0:1.3-20.fc22                                    
  apache-commons-parent.noarch 0:37-2.fc22                                      
  apache-parent.noarch 0:16-1.fc22                                              
  apache-rat-plugin.noarch 0:0.11-1.fc23                                        
  avalon-framework.noarch 0:4.3-11.fc21                                         
  avalon-logkit.noarch 0:2.1-17.fc21                                            
  batik-css.noarch 0:1.8-0.17.svn1230816.fc22                                   
  dom4j.noarch 0:1.6.1-22.fc21                                                  
  fop.noarch 0:1.1-8.fc21                                                       
  hsqldb1.noarch 0:1.8.1.3-5.fc22                                               
  httpcomponents-project.noarch 0:7-1.fc22                                      
  jaxen.noarch 0:1.1.6-5.fc22                                                   
  jdom.noarch 0:1.1.3-7.fc21                                                    
  maven-dependency-plugin.noarch 0:2.10-1.fc22                                  
  maven-doxia-module-fo.noarch 0:1.6-1.fc22                                     
  maven-doxia-sitetools.noarch 0:1.6-1.fc22                                     
  maven-doxia-tools.noarch 0:1.6-2.fc22                                         
  maven-javadoc-plugin.noarch 0:2.10.1-3.fc22                                   
  maven-local.noarch 0:4.4.0-2.fc23                                             
  maven-parent.noarch 0:26-1.fc22                                               
  maven-plugin-annotations.noarch 0:3.3-4.fc22                                  
  maven-plugin-plugin.noarch 0:3.3-4.fc22                                       
  maven-plugin-tools-generators.noarch 0:3.3-4.fc22                             
  maven-plugins-pom.noarch 0:27-2.fc22                                          
  maven-release-manager.noarch 0:2.2.1-13.fc21                                  
  maven-release-plugin.noarch 0:2.2.1-13.fc21                                   
  maven-remote-resources-plugin.noarch 0:1.4-9.fc21                             
  maven-reporting-impl.noarch 0:2.2-11.fc22                                     
  maven-site-plugin.noarch 0:3.4-3.fc22                                         
  plexus-components-pom.noarch 0:1.3.1-3.fc21                                   
  plexus-containers-component-metadata.noarch 0:1.6-2.fc22                      
  plexus-tools-pom.noarch 0:1.0.11-9.fc21                                       
  plexus-velocity.noarch 0:1.1.8-17.fc21                                        
  tomcat-servlet-3.1-api.noarch 0:8.0.18-2.fc23                                 
  velocity.noarch 0:1.7-16.fc22                                                 
  ws-jaxme.noarch 0:0.5.2-13.fc23                                               

Dependency Installed:
  ant-antlr.noarch 0:1.9.4-7.fc22                                               
  ant-junit.noarch 0:1.9.4-7.fc22                                               
  apache-ivy.noarch 0:2.3.0-17.fc22                                             
  cobertura.noarch 0:2.0-1.fc22                                                 
  extra166y.noarch 0:1.7.0-2.fc22                                               
  gc.x86_64 0:7.4.2-2.fc22                                                      
  gcc-gdb-plugin.x86_64 0:5.0.0-0.15.fc23                                       
  gpars.noarch 0:1.2.1-2.fc22                                                   
  guile.x86_64 5:2.0.11-4.fc22                                                  
  hawtjni-runtime.noarch 0:1.10-3.fc22                                          
  jackson-annotations.noarch 0:2.5.0-1.fc22                                     
  jackson-databind.noarch 0:2.5.0-1.fc22                                        
  jcsp.noarch 0:1.1-0.3.rc5.fc22                                                
  jdom2.noarch 0:2.0.6-2.fc22                                                   
  jettison.noarch 0:1.3.4-4.fc21                                                
  libatomic_ops.x86_64 0:7.4.2-4.fc22                                           
  libksba.x86_64 0:1.3.2-1.fc22                                                 
  libtool-ltdl.x86_64 0:2.4.6-1.fc23                                            
  libunistring.x86_64 0:0.9.4-1.fc22                                            
  multiverse.noarch 0:0.7.0-3.fc22                                              
  npth.x86_64 0:1.1-1.fc22                                                      
  publicsuffix-list.noarch 0:20150217-1.fc23                                    
  xom.noarch 0:1.0-16.fc21                                                      
  xpp3-minimal.noarch 0:1.1.4-5.c.fc23                                          
  xstream.noarch 0:1.4.7-9.fc22     


Fixed the issue.

Comment 118 jiri vanek 2015-02-19 14:02:55 UTC
(In reply to jiri vanek from comment #114)
> Hmm. I turned back to package-like build-classpath (it is many times faster
> then maven like one) and it works for me again.
> 
> There canbe only one solution for me - not all dependeces are listed
> automatically, because I run those test on clean system, and yum pulled what
> read from rpm.

Scratch that all please. My chroot had to be somehow strongly corrupted.

Comment 119 jiri vanek 2015-02-19 14:06:14 UTC
Actually, have you noted the different names after startups?
INFO: [Strongarm] initializing .
INFO: [Firebolt] initializing ...
INFO: [Lady Mastermind] 
INFO: [Wolverine]
...

Thats intentional? Well.. bit better then  pid :)

Comment 120 Zbigniew Jędrzejewski-Szmek 2015-02-19 14:21:07 UTC
(In reply to jiri vanek from comment #116)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #115)
> > (In reply to jiri vanek from comment #100)
> > > > Second question: elasticsearch listens on 0.0.0.0:9200 by default, accepting
> > > > commands from the internet. 
> > > > This has to be fixed. Maybe a default configuration to limit it to ::1
> > > > should be added. I don't know what,
> > > > but something has to be done.
> > > 
> > > Afaik no simple option here. The firewalld shopud do this job or any other
> > > deployment tool like nginx  or similar...
> > The problem is that Workstation product runs with firewall disabled. People
> 
> How come? Wasnt it vice versa until recently?
You missed the big discussion on fedora-devel apparently. Short version is that Workstation working group proposed disabling the firewall, which FESCo rejected, so instead that made a firewall with all ports allowed, which FESCo approved, or at least declined to disapprove.

> > might install ES without realizing that it listens on the network by
> > default. Even if it is documented somewhere. It is also very likely that ES
> > will become a dependency of other packages. Having it default to accepting
> > commands from the network seems like something that will bite our users.
> > "Secure by default" is the general principle.
> > 
> Hmm. I agree. But currently  no idea. Crap.
I think socket activation would be the best way to go. It would solve two problems: listening on public address, and startup synchronization.

When I wrote comment #c93, I didn't know that upstream is sympathetic to doing socket activation. It might not be trivial with Java, but this would be the perfect solution in the long run.

Comment 121 Paul Howarth 2015-02-19 14:24:59 UTC
(In reply to jiri vanek from comment #116)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #115)
> > might install ES without realizing that it listens on the network by
> > default. Even if it is documented somewhere. It is also very likely that ES
> > will become a dependency of other packages. Having it default to accepting
> > commands from the network seems like something that will bite our users.
> > "Secure by default" is the general principle.
> > 
> Hmm. I agree. But currently  no idea. Crap.

Does this not help?

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/setup-configuration.html

Comment 122 jiri vanek 2015-02-19 14:50:54 UTC
ok.Removal of boundled bae64 was easy at the end:
Dont forget you need  gil's
http://koji.fedoraproject.org/koji/buildinfo?buildID=612895
otherwise the field PREFERRED_ENCODING has private access in Base64

SPEC: https://jvanek.fedorapeople.org/elasticsearch/review/v5/elasticsearch.spec
SRPM: https://jvanek.fedorapeople.org/elasticsearch/review/v5/elasticsearch-1.4.3-0.fc23.src.rpm

Comment 123 jiri vanek 2015-02-19 14:55:03 UTC
(In reply to Paul Howarth from comment #121)
> (In reply to jiri vanek from comment #116)
> > (In reply to Zbigniew Jędrzejewski-Szmek from comment #115)
> > > might install ES without realizing that it listens on the network by
> > > default. Even if it is documented somewhere. It is also very likely that ES
> > > will become a dependency of other packages. Having it default to accepting
> > > commands from the network seems like something that will bite our users.
> > > "Secure by default" is the general principle.
> > > 
> > Hmm. I agree. But currently  no idea. Crap.
> 
> Does this not help?
> 
> http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/setup-
> configuration.html

The only suspicious thing is network host in  ES_HOME/config/elasticsearch.yml 

But only suspicious.It do not seem to protect against outside pushes.

Comment 124 Zbigniew Jędrzejewski-Szmek 2015-02-19 14:55:03 UTC
(In reply to Paul Howarth from comment #121)
> http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/setup-
> configuration.html
Yes, this certainly helps. It does not solve the problem with lack of notification about completed startup, but is certainly a good interim solution.

Comment 125 Jörg Prante 2015-02-19 15:07:30 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #120)
> (In reply to jiri vanek from comment #116)
> > (In reply to Zbigniew Jędrzejewski-Szmek from comment #115)
> > > (In reply to jiri vanek from comment #100)
> > > > > Second question: elasticsearch listens on 0.0.0.0:9200 by default, accepting
> > > > > commands from the internet. 
> > > > > This has to be fixed. Maybe a default configuration to limit it to ::1
> > > > > should be added. I don't know what,
> > > > > but something has to be done.
> > > > 
> > > > Afaik no simple option here. The firewalld shopud do this job or any other
> > > > deployment tool like nginx  or similar...
> > > The problem is that Workstation product runs with firewall disabled. People
> > 
> > How come? Wasnt it vice versa until recently?
> You missed the big discussion on fedora-devel apparently. Short version is
> that Workstation working group proposed disabling the firewall, which FESCo
> rejected, so instead that made a firewall with all ports allowed, which
> FESCo approved, or at least declined to disapprove.
> 
> > > might install ES without realizing that it listens on the network by
> > > default. Even if it is documented somewhere. It is also very likely that ES
> > > will become a dependency of other packages. Having it default to accepting
> > > commands from the network seems like something that will bite our users.
> > > "Secure by default" is the general principle.
> > > 
> > Hmm. I agree. But currently  no idea. Crap.
> I think socket activation would be the best way to go. It would solve two
> problems: listening on public address, and startup synchronization.
> 
> When I wrote comment #c93, I didn't know that upstream is sympathetic to
> doing socket activation. It might not be trivial with Java, but this would
> be the perfect solution in the long run.

I am not familiar with the details of the discussion, but if you are about to consider to modify Elasticsearch for restricting HTTP port 9200 to open on a site-local network socket only, please see my patch

https://github.com/jprante/elasticsearch/commit/42392350850ae58b73f5a39939bc245f4faf2f44

This is for HTTP only and can block external requests by a default configuration. Please note, it is only complete with a solution for Elasticsearch node protocol port 9300, which is very similar.

Comment 126 Zbigniew Jędrzejewski-Szmek 2015-02-19 21:58:14 UTC
So... this is starting to look good.

Add BR and R: java-base64 >= 2.3.8-7

Why this:
  Requires(post):   chkconfig
  Requires(preun):  chkconfig

Change systemd-units to systemd in the requirements.

Still valid:
> > - %description needs to be extended to say what this package does.
> The new text seems to have been pasted from a website. It's a promotional
> blurb. It even ends with "Learn more".
Please add something more technical.

s/distributive search and analytic/distributed search and analytics/

The daemon creates /data/elasticsearch. It should use /var/lib/elasticsearch instead.

The daemon should run under its own user. See http://fedoraproject.org/wiki/Packaging:UsersAndGroups#Dynamic_allocation for the setup. /var/lib/elasticsearch has to be owned by this user.

Updated service file in attachment.

Comment 127 Zbigniew Jędrzejewski-Szmek 2015-02-19 22:00:03 UTC
Created attachment 993789 [details]
elasticsearch.service

- move Description to the right section
- add Documentation, ProtectHome, ProtectSystem, User, LimitNOFILE

Comment 128 jiri vanek 2015-02-20 09:17:49 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #127)
> Created attachment 993789 [details]
> elasticsearch.service
> 
> - move Description to the right section
> - add Documentation, ProtectHome, ProtectSystem, User, LimitNOFILE

It seems to have missing
User=elasticsearch
Group=elasticsearch

I will add it to it.

Comment 129 jiri vanek 2015-02-20 12:19:46 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #126)
> So... this is starting to look good.
> 
> Add BR and R: java-base64 >= 2.3.8-7
> 
> Why this:
>   Requires(post):   chkconfig
>   Requires(preun):  chkconfig

removed. I found in in some example..
> 
> Change systemd-units to systemd in the requirements.

changed.
> 
> Still valid:
> > > - %description needs to be extended to say what this package does.
> > The new text seems to have been pasted from a website. It's a promotional
> > blurb. It even ends with "Learn more".
> Please add something more technical.

Improved by paragraph from wikipedia

> 
> s/distributive search and analytic/distributed search and analytics/
> 

done
> The daemon creates /data/elasticsearch. It should use /var/lib/elasticsearch
> instead.

used [1]
> 
> The daemon should run under its own user. See
> http://fedoraproject.org/wiki/Packaging:UsersAndGroups#Dynamic_allocation
> for the setup. /var/lib/elasticsearch has to be owned by this user.
> 
good catch!
done. The user is never removed?
directory also owned.

> Updated service file in attachment.

used with small sync from upstream service (https://jvanek.fedorapeople.org/elasticsearch/review/v6/elasticsearch.service.in)


[1] This needed some rework. I had to get rid of %jpackage_script and use elasticsearch.in to 
This script is redirecting ES work to /var/lib/elasticsearch (in case of service)
and to XDG_CONFIG_HOME in case od regular user's run

My motivation is, that users data definitely should be separate from service's data. If one can use global data as default, he can always symlink.
see: https://jvanek.fedorapeople.org/elasticsearch/review/v6/elasticsearch.in



SPEC: https://jvanek.fedorapeople.org/elasticsearch/review/v6/elasticsearch.spec
SRPM: https://jvanek.fedorapeople.org/elasticsearch/review/v6/elasticsearch-1.4.3-0.fc21.src.rpm

Comment 130 jiri vanek 2015-02-20 12:21:40 UTC
Also note, deadline is 24th Feb, so we should push and build today, or in Monday as latest....

Comment 131 Zbigniew Jędrzejewski-Szmek 2015-02-21 23:10:25 UTC
Issues:
- please reflow %description into paragraphs separated with empty lines. rpm -i and other tools treat it as preformatted text and it looks a bit ugly right now.

- In %files javadoc move NOTICE.txt to %license too.

- I don't understand the change with R:jpackage-utils, R:java-headless. You mention #1194110 as the reason, but that bug was about missing dependency on xmvn-resolve. mvn-resolve is not needed iiuc, so why not remove this?

- R:java-base64 >= 2.3.8-7 is also needed. BR is not enough.

(In reply to jiri vanek from comment #129)
> The user is never removed?
Yes. It's very hard to cleanly remove a user, because in principle you'd have to search all of the filesystem for files owned by the user. So users are never removed except by the admin.

- /var/lib/elasticsearch should be owned by elasticsearch. You need to add %attr in the %files section. See http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html.

- When the daemon is started, is still listens on [::]:9200 and [::]:9300. The daemon has to be fixed to not accept commands from the network in the default configuration.

Comment 132 jiri vanek 2015-02-22 10:11:57 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #131)
> Issues:
> - please reflow %description into paragraphs separated with empty lines. rpm
> -i and other tools treat it as preformatted text and it looks a bit ugly
> right now.

fixed
> 
> - In %files javadoc move NOTICE.txt to %license too.

fixed
> 
> - I don't understand the change with R:jpackage-utils, R:java-headless. You
> mention #1194110 as the reason, but that bug was about missing dependency on
> xmvn-resolve. mvn-resolve is not needed iiuc, so why not remove this?
> 
on your responsibility! fixed!

> - R:java-base64 >= 2.3.8-7 is also needed. BR is not enough.
> 

ah sure, auto mvn deps donot handle version. sorry.

> 
> - /var/lib/elasticsearch should be owned by elasticsearch. You need to add
> %attr in the %files section. See
> http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html.

sorry, I read it as owned by packge es. user es is owning it now.
> 
> - When the daemon is started, is still listens on [::]:9200 and [::]:9300.
> The daemon has to be fixed to not accept commands from the network in the
> default configuration.

This is default upstream behaviour. Not packaging issue. It is worthy to be bugged as separate bug and to fix as different issue then pkg review.
updated to 1.4.4. although it really should be fixed, and fixed soon, it should not be an initial push blocker.

SPEC: https://jvanek.fedorapeople.org/elasticsearch/review/v7/elasticsearch.spec
SRPM: https://jvanek.fedorapeople.org/elasticsearch/review/v7/elasticsearch-1.4.4-0.fc23.src.rpm

ty for check!

Comment 133 Till Maas 2015-02-22 21:24:40 UTC
(In reply to jiri vanek from comment #132)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #131)

> > - When the daemon is started, is still listens on [::]:9200 and [::]:9300.
> > The daemon has to be fixed to not accept commands from the network in the
> > default configuration.
> 
> This is default upstream behaviour. Not packaging issue. It is worthy to be
> bugged as separate bug and to fix as different issue then pkg review.
> updated to 1.4.4. although it really should be fixed, and fixed soon, it
> should not be an initial push blocker.

Packaging is also about making sure that the packages have sane defaults, even if upstream does not care about them. The right thing to do for Fedora is do keep its users protected and knowingly putting them at risk.

FYI, there is an IMHO interesting blog post about the general problem:
http://mjg59.dreamwidth.org/34069.html

Comment 134 jiri vanek 2015-02-23 07:25:12 UTC
Then maybe the right thing is to disable service while the issue is resolved.

Comment 135 jiri vanek 2015-02-23 10:08:18 UTC
SPEC: https://jvanek.fedorapeople.org/elasticsearch/review/v8/elasticsearch.spec
SRPM: https://jvanek.fedorapeople.org/elasticsearch/review/v8/elasticsearch-1.4.4-0.fc23.src.rpm

changes:
 add missing dependecne on buildclasspath - snakeyaml
 packed configure templtes
  patched to use localhost only
  used on startup

The config file is correctly used, and remote connections seems not accepted

Hope that it is enough!

Thanx for forcing me!

Comment 136 Zbigniew Jędrzejewski-Szmek 2015-02-23 14:03:05 UTC
- There's no such thing as systmed-units. Please remove BR:systemd-units.

- I think you might want to remove printing of the jar list in the wrapper script. It is rather long and ends up in the logs.

- Putting the configuration in /var/lib/ is a bit nonstandard. It would be better to
move it to /etc/elasticsearch and provide a symlink /var/lib/elasticsearch/conf → /etc/elasticsearch
if necessary.

===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "Apache (v2.0)", "Unknown or generated", "*No copyright* Apache (v2.0)".
     19 files have unknown license. Detailed output of licensecheck in
     /var/tmp/902086-elasticsearch/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[x]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 30720 bytes in 3 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: %config files are marked noreplace or the reason is justified.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: No %config files under /usr.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

Java:
[x]: Bundled jar/class files should be removed before build
[x]: Packages have proper BuildRequires/Requires on jpackage-utils
     Note: Maven packages do not need to (Build)Require jpackage-utils. It is
     pulled in by maven-local
[x]: Javadoc documentation files are generated and included in -javadoc
     subpackage
[x]: Javadoc subpackages should not have Requires: jpackage-utils
[x]: Javadocs are placed in %{_javadocdir}/%{name} (no -%{version} symlink)

Maven:
[x]: If package contains pom.xml files install it (including depmaps) even
     when building with ant
[x]: POM files have correct Maven mapping
[x]: Maven packages should use new style packaging
[x]: Old add_to_maven_depmap macro is not being used
[x]: Packages DO NOT have Requires(post) and Requires(postun) on jpackage-
     utils for %update_maven_depmap macro
[x]: Package DOES NOT use %update_maven_depmap in %post/%postun
[x]: Packages use %{_mavenpomdir} instead of %{_datadir}/maven2/poms

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in
     elasticsearch-javadoc
Not needed.

[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Patches link to upstream bugs/comments/lists or are otherwise justified.
[x]: SourceX tarball generation or download is documented.
     Note: Package contains tarball without URL, check comments
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[ ]: %check is present and all tests pass.
TBD.

[x]: Packages should try to preserve timestamps of original installed files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: Dist tag is present (not strictly required in GL).
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

Java:
[x]: Package uses upstream build method (ant/maven/etc.)
[x]: Packages are noarch unless they use JNI

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: elasticsearch-1.4.4-0.fc23.noarch.rpm
          elasticsearch-javadoc-1.4.4-0.fc23.noarch.rpm
          elasticsearch-1.4.4-0.fc23.src.rpm
elasticsearch.noarch: W: spelling-error Summary(en_US) analytics -> analytic, analytic s, paralytics
elasticsearch.noarch: W: spelling-error %description -l en_US multitenant -> multinational
elasticsearch.noarch: W: spelling-error %description -l en_US analytics -> analytic, analytic s, paralytics
elasticsearch.noarch: W: spelling-error %description -l en_US Architected -> Architect ed, Architect-ed, Architect
elasticsearch.noarch: W: spelling-error %description -l en_US scalability -> availability, sociability, implacability
elasticsearch.noarch: E: executable-marked-as-config-file /var/lib/elasticsearch/conf/elasticsearch.yml
elasticsearch.noarch: E: script-without-shebang /var/lib/elasticsearch/conf/elasticsearch.yml
elasticsearch.noarch: E: executable-marked-as-config-file /var/lib/elasticsearch/conf/logging.yml
elasticsearch.noarch: E: script-without-shebang /var/lib/elasticsearch/conf/logging.yml
Bogus errors.

elasticsearch.src: W: spelling-error Summary(en_US) analytics -> analytic, analytic s, paralytics
elasticsearch.src: W: spelling-error %description -l en_US multitenant -> multinational
elasticsearch.src: W: spelling-error %description -l en_US analytics -> analytic, analytic s, paralytics
elasticsearch.src: W: spelling-error %description -l en_US Architected -> Architect ed, Architect-ed, Architect
elasticsearch.src: W: spelling-error %description -l en_US scalability -> availability, sociability, implacability
elasticsearch.src: W: invalid-url Source0: elasticsearch-1.4.4-fedora.tar.xz
3 packages and 0 specfiles checked; 4 errors, 11 warnings.




Rpmlint (installed packages)
----------------------------
Cannot parse rpmlint output:


Requires
--------
elasticsearch-javadoc (rpmlib, GLIBC filtered):
    jpackage-utils

elasticsearch (rpmlib, GLIBC filtered):
    /bin/bash
    /bin/sh
    config(elasticsearch)
    java-base64
    java-headless
    jpackage-utils
    lucene-sandbox
    mvn(com.carrotsearch:hppc)
    mvn(com.fasterxml.jackson.core:jackson-core)
    mvn(com.fasterxml.jackson.dataformat:jackson-dataformat-cbor)
    mvn(com.fasterxml.jackson.dataformat:jackson-dataformat-smile)
    mvn(com.fasterxml.jackson.dataformat:jackson-dataformat-yaml)
    mvn(com.google.guava:guava)
    mvn(com.ning:compress-lzf)
    mvn(com.tdunning:t-digest)
    mvn(commons-cli:commons-cli)
    mvn(io.netty:netty:3.9.3.Final)
    mvn(joda-time:joda-time)
    mvn(net.iharder:base64)
    mvn(org.antlr:antlr-runtime)
    mvn(org.apache.commons:commons-lang3)
    mvn(org.apache.lucene:lucene-analyzers-common)
    mvn(org.apache.lucene:lucene-core)
    mvn(org.apache.lucene:lucene-highlighter)
    mvn(org.apache.lucene:lucene-join)
    mvn(org.apache.lucene:lucene-memory)
    mvn(org.apache.lucene:lucene-queries)
    mvn(org.apache.lucene:lucene-queryparser)
    mvn(org.apache.lucene:lucene-spatial)
    mvn(org.apache.lucene:lucene-suggest)
    mvn(org.joda:joda-convert)
    shadow-utils
    snakeyaml
    systemd



Provides
--------
elasticsearch-javadoc:
    elasticsearch-javadoc

elasticsearch:
    config(elasticsearch)
    elasticsearch
    mvn(org.elasticsearch:elasticsearch)
    mvn(org.elasticsearch:elasticsearch:pom:)



Generated by fedora-review 0.5.2 (63c24cb) last change: 2014-07-14
Command line :/usr/bin/fedora-review -b 902086
Buildroot used: fedora-rawhide-x86_64
Active plugins: Generic, Shell-api, Java
Disabled plugins: C/C++, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby
Disabled flags: EXARCH, EPEL5, BATCH, DISTTAG

Comment 137 jiri vanek 2015-02-23 14:19:19 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #136)
> - There's no such thing as systmed-units. Please remove BR:systemd-units.
will be fixed ( I thought it was)
> - I think you might want to remove printing of the jar list in the wrapper
> script. It is rather long and ends up in the logs.
will be fixed ( I forgot -x in it)
> - Putting the configuration in /var/lib/ is a bit nonstandard. It would be
> better to
> move it to /etc/elasticsearch and provide a symlink
> /var/lib/elasticsearch/conf → /etc/elasticsearch

Yah, I thought you will not like it. I will put it into etc and link.
> if necessary.

Yes it will be.


> availability, sociability, implacability
> elasticsearch.noarch: E: executable-marked-as-config-file
> /var/lib/elasticsearch/conf/elasticsearch.yml
> elasticsearch.noarch: E: script-without-shebang
> /var/lib/elasticsearch/conf/elasticsearch.yml
> elasticsearch.noarch: E: executable-marked-as-config-file
> /var/lib/elasticsearch/conf/logging.yml
> elasticsearch.noarch: E: script-without-shebang
> /var/lib/elasticsearch/conf/logging.yml
> Bogus errors.

Crap, how did they sneeked in? I will move them to 644 and by that they will be fixed agin.
> 
>

Is there something more you need me to do?

Comment 138 Zbigniew Jędrzejewski-Szmek 2015-02-23 19:08:16 UTC
(In reply to jiri vanek from comment #137)
> Is there something more you need me to do?
Nope. Package is APPROVED.

Comment 139 jiri vanek 2015-02-24 08:05:02 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #138)
> (In reply to jiri vanek from comment #137)
> > Is there something more you need me to do?
> Nope. Package is APPROVED.

Ty! Just for completeness:
SPEC: https://jvanek.fedorapeople.org/elasticsearch/review/v9/elasticsearch.spec
SRPM: https://jvanek.fedorapeople.org/elasticsearch/review/v9/elasticsearch-1.4.4-0.fc23.src.rpm

Comment 140 jiri vanek 2015-02-24 08:19:42 UTC
New Package SCM Request
=======================
Package Name: elasticsearch
Short Description: Open source, flexible, distributed search and analytics engine
Upstream URL: https://github.com/elasticsearch/elasticsearch
Owners: jvanek zbyszek
Branches: f22
InitialCC: bjensen pbrobinson jorge  bkabrda mizdebsk theinric ahughes gil msrb fschwarz mrunge

Comment 141 jiri vanek 2015-02-24 08:41:57 UTC
New Package SCM Request
=======================
Package Name: elasticsearch
Short Description: Open source, flexible, distributed search and analytics engine
Upstream URL: https://github.com/elasticsearch/elasticsearch
Owners: jvanek zbyszek
Branches: f22
InitialCC: java-sig  bjensen pbrobinson jorge  bkabrda theinric ahughes gil msrb fschwarz mrunge

Comment 142 Patrick Uiterwijk 2015-02-24 09:23:35 UTC
Git done (by process-git-requests).

Comment 143 Pierre-YvesChibon 2015-03-06 10:20:21 UTC
Jorge has been put on watch list for this package, but the email set in FAS for this account is bouncing on google.

Can someone contact him so that he can change his email?

Otherwise, we can also remove him from the watch list or, as a last option, de-activate his account, knowing that he can always re-activate it by simply login in FAS.

Comment 144 jiri vanek 2015-03-06 11:24:39 UTC
Hello. He was disabled until he asked to be added again.
Sorry.

Comment 145 Pierre-YvesChibon 2015-03-06 13:06:11 UTC
Many thanks Jiri!

Comment 146 Tomas Curilla 2015-07-30 06:18:32 UTC
Please build an epel7 build of elasticsearch for EL7/CentOS7.
Thank you.

Comment 147 jiri vanek 2015-07-30 09:03:45 UTC
(In reply to Tomas Curilla from comment #146)
> Please build an epel7 build of elasticsearch for EL7/CentOS7.
> Thank you.

Not a smallest chance. If you wont it in epel. do it on your own.  And be warned - you will need to transport a lot of dependencies with you.... Sorry.


Note You need to log in before you can comment on or make changes to this bug.