elasticsearch6
- Path: arch/private/elasticsearch6
- Last Apache-licensed Elasticsearch (6.3.2), kept under a renamed
pkgname=elasticsearch6 (_pkgname=elasticsearch for the real
upstream tarball/dir names) specifically so it doesn’t collide with
any future plain elasticsearch package — see arch/private/README.
Used for a commercial project.
- 2026-08-27: log4j 2.17.0 → 2.17.1 mitigation,
pkgrel 2 → 3
(packaging-only, [[feedback_pkgrel_vs_pkgver]]), applied from the
user’s own ~/todo/elasticsearch working copy (an updated AUR
checkout, upstream pkgname=elasticsearch there — deliberately did
not pull that rename in, kept our own elasticsearch6/_pkgname
split since this package is already published under that name).
Diffed against the tracked copy first: only PKGBUILD actually
changed (all the elasticsearch-*.service/.conf/elasticsearch-env
support files were byte-identical) — the log4j bundled-jar swap in
package() (log4j-{core,api,1.2-api}-2.17.0.jar →
...-2.17.1.jar) plus the matching source=/sha256sums entry.
This is presumably a follow-up round of the Log4Shell
(CVE-2021-44228 family) response — the original 2.17.0 bump predates
this project’s tracking of the package.
- Sources mirrored to our own
src/ (user request, even though
both origin URLs still resolve): elasticsearch-oss-6.3.2.tar.gz
(artifacts.elastic.co, alive) and apache-log4j-2.17.1-bin.tar.gz
(archive.apache.org — alive but sent Vary: Slow,Glacial, i.e.
deliberately throttled; the newer dlcdn.apache.org mirror the
user’s local copy’s PKGBUILD had switched to already 404s once a
release ages off the fast mirrors). Both verified byte-identical
(sha256) against the existing/new PKGBUILD entries before uploading.
Original URLs kept as comments above each source= entry, matching
[[makemkv]]’s established convention.
- Built+published cleanly for
arch=any (fans out to every configured
arch’s db via repo_publish.sh’s symlink mechanism, see its own
header comment) on the first try, no other issues.