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.