Arch Linux User Repository

This package should no longer supply a non-numbered sysctl.d conf file, as it conflicts with Arch vendor supplied 10-arch.conf which specifies vm.max_map_count = 1048576.

This does not appear to run any longer with jdk-openjdk now that it’s version 22.

Edit: never mind, I had to rebuild it after the upgrade.

Edit 2: not such a drastic change was necessary, as it appears the only difference is the bundled symlink to the correct Java version.

The below commands don't seem to complain anymore. Something must have gotten fixed up somewhere else.

I recently adopted kibana-xpack and managed to make ./autoUpdate support it without resorting to compiling.

Even though this elasticsearch package builds from the git releases it doesn't build from master branch like AUR packages with the -git suffix would usually do. That said, it's not a -bin package either but kibana-xpack seems to function that way.

If I find the time later I may revert this package back to its original state with a modification to ./autoUpdate allowing the package to install from the originally-used artifacts.elastic.co sources. It would create a package faster than compiling on the fly for those with package AUR helpers and we would avoid use of makedepends=. I'll think on it.

I've opened https://github.com/Jguer/yay/issues/2369 hoping for answers. I can't piece together why this is suddenly a problem unless something has changed elsewhere. It also seems to happen if I try other java packages.

Using yay --debug revealed that it's calling: makepkg --nobuild -f -C --ignorearch which seems to be what actually throws the error (even just makepkg --nobuild throws it, but of course lacks -s). Checking out older commits also fails so I'm not really sure where this starts and ends. A machine with its last update being done 8th Jan 2024's yay also doesn't like trying to build this with the same error.

In my case /var/lib/elasticsearch was emptied before to avoid any broken data, and it was running as single-node cluster. Maybe this issue is fixed with 8.12.1.

But my test yesterday with "makepkg -rs" also failed with

BUILD SUCCESSFUL in 4m 25s
556 actionable tasks: 500 executed, 56 up-to-date
==> Entering fakeroot environment...
==> Starting package()...
error: package 'jdk-openjdk' was not found
==> ERROR: A failure occurred in package().
    Aborting...

I just built 8.12.1 here and its cluster status is green here too. I was going to fire up filebeat and send some test lines to it but want to focus on the build issue experienced with AUR helpers. I was once again unable to replicate the issue in a brand new Arch installroot in a docker container and it started just fine as well with a green cluster status. Even makepkg -rsi seems to be fine.

It's possible that once you start writing data to it, the expectation of multiple replica shards kicks in and upsets the single-node without cluster settings either persistently or transiently to not worry about replica shards. But as far as I can see here, everything is fine with this AUR package itself.

I've just now tried again with yay (which I already package) and have run into the problem. I will work on that from here.

Regarding your comment: "It already has jdk17-openjdk set as makedepends due to an inability to be built with newer versions but once built, it can be run with jdk-openjdk just fine." -> no, at least 8.12.0 did not run with jdk-openjdk, it just hangs at start and never leaves the "red" state. Unfortunately I don't find the upstream bug any more.

"aur sync" from aurtools still has this issue, running "makepkg -rsi" still leads to:

BUILD SUCCESSFUL in 4m 25s
556 actionable tasks: 500 executed, 56 up-to-date
==> Entering fakeroot environment...
==> Starting package()...
error: package 'jdk-openjdk' was not found
==> ERROR: A failure occurred in package().
    Aborting...

And jdk-openjdk is not installed and conflicts with jdk17-openjdk.