Arch Linux User Repository

elasticsearch 8.9.0 released.

How are the other elastic AUR packages handling this differently where they're up to date in a short timespan but the elasticsearch and elasticsearch-bin AUR packages are always months out of date at a time?

The entire elastic project is infeasible to use on Archlinux given this ongoing desync and the beats agents and elasticsearch itself advise against mixing the versions when the connection establishes.

Could always chuck this .git onto a cicd pipeline to check for a new version and update the AUR package version var and checksums accordingly. It would be much better than cluster's falling apart over the beats sending new data formats to non-updated elasticsearch clusters every few months. In this recurring state the package just isn't reliable at all.

E: I'm putting together some bash lines to compare the stored version in the PKGBUILD and what git considers to be the latest release via api.github.com so it can check if a newer release is available and automatically update its checksums and fetch the latest tar.gz instead of using the version defined in the PKGBUILD

The choice made of the beats package was to have elasticsearch as an optdepend.
I won't go against the decision of the beats maintainer.
And it is true nowaways that the fork opensearch is more promoted by the Arch Linux community.

I will have a look at Renovate and other maintainer tools to automate the updates of this elasticsearch package.

If the maintainer of this package and beats are willing, this one could be deleted and added as a subpackage of beats.

Not sure why elasticsearch should be a subpackage of beats.

That was assuming this statement is accurate: "They're supposed to be a suite but I often run into issues with this package falling behind."

Updating a single pkgbase would update all subpackages simultaneously.

Is there a way we can prevent this from falling so far behind the other key Elastic programs?

Flagging out-of-date. And I guess I could try to use automation with Renovate: https://docs.renovatebot.com/user-stories/maintaining-aur-packages-with-renovate/.

If the maintainer of this package and beats are willing, this one could be deleted and added as a subpackage of beats.

Not sure why elasticsearch should be a subpackage of beats.

elasticsearch has been updated to 8.8.1.

@ipaqmaster If the maintainer of this package and beats are willing, this one could be deleted and added as a subpackage of beats.

Otherwise, flag out of date?

The Filebeat AUR package is shipping 8.8.1 but this package is shipping 8.7.1. This is a 'huge' problem because Filebeat throws this trying to ship logs to it by default:

Connection marked as failed because the onConnect callback failed: Elasticsearch is too old. Please upgrade the instance. If you would like to connect to older instances set output.elasticsearch.allow_older_versions to true.

Is there a way we can prevent this from falling so far behind the other key Elastic programs? They're supposed to be a suite but I often run into issues with this package falling behind.

@mklein994 Thanks! I updated the package.

I'm getting an error message when I start elasticsearch.service (version 8.7.1-1):

Starting Elasticsearch...
warning: ignoring JAVA_HOME=/usr/lib/jvm/default-runtime; using bundled JDK
/usr/share/elasticsearch/bin/elasticsearch-cli: line 14: /usr/share/elasticsearch/jdk/bin/java: No such file or directory
elasticsearch.service: Control process exited, code=exited, status=127/n/a
elasticsearch.service: Failed with result 'exit-code'.
Failed to start Elasticsearch.

The package is still creating a symlink to JDK 19 (PKGBUILD:59):

ln -s /usr/lib/jvm/java-19-openjdk "$pkgdir"/usr/share/elasticsearch/jdk
#                       ^^-- should this be 20?

The jre-openjdk-headless package is currently at 20.0.1.u9-3. Changing the symlink in the PKGBUILD to java-20-openjdk seems to fix it.