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.
Depends on Lucene. Rawhide package is outdated: lucene-3.6.0-11.fc19.src.rpm Current version: Lucene 3.6.2
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
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
(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.
(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!
(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.
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.
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
EL 6 has no Maven. It would be great to have it on EL6 too. I'm particularly thinking about getting Logstash packaged.
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.
EPEL7 is still amazing and expected. And it's nosense to package RPMs for EPEL _only_ since EPEL is always behind Fedora.
(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
> 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
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
(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.
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.
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.
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)
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
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
If there is someone needed to get the missings dependencies reviewed, you can ping me directly and I'll take care of it.
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...
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1116363 -- Review request for jackson-dataformat-cbor
Gil had made amazing job and updated/added all jacson* (and mustache) stuff. Ihope to move with t-digest asap.
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!
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?
If it *will* swithc. Can we live fore now with released versions which do not use grovyscripting?
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.
I agree. But I would not like to make it blocker for this package.
FWIW here is the issue for Groovy 2.3.x https://bugzilla.redhat.com/show_bug.cgi?id=843417
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?
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
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.
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.
> 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 :(
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.
(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
(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/
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)
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)
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
Created attachment 934730 [details] build log for updated v1
(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
> missing build deps: groovy, and sigar java binding Still those two are optional for build. Is there osme trickI'm missing?
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 :)
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
Created attachment 936517 [details] gil's error log
Created attachment 936518 [details] jvanek's error log
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.
Applied https://github.com/elasticsearch/elasticsearch/commit/223dab892144b0c8f9d073baf1598a1e3cdfa3ed.patch 99 Failed hunks in 33 .rej files... No to bad....
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
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 :)
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...
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.
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.
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)
available https://github.com/elasticsearch/elasticsearch/archive/v1.4.0.Beta1.tar.gz
proposed: https://fedoraproject.org/wiki/Changes/Elasticsearch
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
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/ )
Created attachment 986126 [details] v4 install failure
(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?
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.
(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
> > 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!
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.
(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
lucene 4.10.2->4.10.3
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....
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
- 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.
- Consider removing explicit requires on jpackage-*. Dependency on maven-local should add it automatically. Also there's no jpackage-tools afaics.
(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
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
it would be better to upgrade elasticsearch to the latest stable version (1.4.3)
(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.
(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!
(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
(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?
(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
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.
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!
New spec?
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:(
(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.
(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.
(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)
Yikes, https://fedorahosted.org/fesco/ticket/1415 should have been for FPC. Sorry for getting them mixed up in my comment.
(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.
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.
(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
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.
Created attachment 993402 [details] elasticsearch.service
Created attachment 993403 [details] elasticsearch.service
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 ....
(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
(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
(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
(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.
(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.
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
(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 ...
(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.
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
%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
ES is not working with packages-like classpath. I will turn back to maven-like
(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.
(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.
(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
(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
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
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
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
(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.
(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.
(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.
(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.
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 :)
(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.
(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
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
(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.
(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.
(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.
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.
Created attachment 993789 [details] elasticsearch.service - move Description to the right section - add Documentation, ProtectHome, ProtectSystem, User, LimitNOFILE
(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.
(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
Also note, deadline is 24th Feb, so we should push and build today, or in Monday as latest....
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.
(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!
(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
Then maybe the right thing is to disable service while the issue is resolved.
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!
- 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
(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?
(In reply to jiri vanek from comment #137) > Is there something more you need me to do? Nope. Package is APPROVED.
(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
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
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
Git done (by process-git-requests).
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.
Hello. He was disabled until he asked to be added again. Sorry.
Many thanks Jiri!
Please build an epel7 build of elasticsearch for EL7/CentOS7. Thank you.
(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.