Package Details: nzbhydra2 7.10.2-1

Git Clone URL: https://aur.archlinux.org/nzbhydra2.git (read-only, click to copy)
Package Base: nzbhydra2
Description: Search aggregator for newznab and torznab indexers.
Upstream URL: https://github.com/theotherp/nzbhydra2
Licenses: Apache-2.0
Submitter: fryfrog
Maintainer: fryfrog (jkhsjdhjs)
Last Packager: fryfrog
Votes: 18
Popularity: 0.000000
First Submitted: 2018-01-06 20:01 (UTC)
Last Updated: 2024-12-04 04:08 (UTC)

Dependencies (5)

Sources (7)

Pinned Comments

IncredibleLaser commented on 2023-01-24 14:39 (UTC)

The command listed in https://aur.archlinux.org/packages/nzbhydra2?O=10#comment-887324 doesn't work without further modifications because systemd doesn't expand variables in the Environment directive. As such, starting the service fails because the sh command can't be found. A possible workaround is to hardcode the path, i.e. Environment=PATH="/usr/lib/jvm/java-17-openjdk/bin:/usr/bin"

jkhsjdhjs commented on 2023-01-21 16:50 (UTC) (edited on 2023-01-21 17:08 (UTC) by jkhsjdhjs)

With the update to version 5, nzbhydra2 now requires java 17, so you'll have to make sure that nzbhydra2 is run with java 17: https://aur.archlinux.org/packages/nzbhydra2?O=10#comment-887324
This is only required for running, the package should build fine in any case.

Furthermore, while nzbhydra2 now also provides binaries for windows and linux (which are apparently built using GraalVM), this package will continue to build the generic jar, as it doesn't seem to be possible to build the binaries with OpenJDK and GraaVM is only available in the AUR.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

fryfrog commented on 2022-11-29 00:55 (UTC)

@jkhsjdhjs, do your build skills work in .NET too? All of the sonarr, radarr, lidarr, readarr and prowlarr packages are binary too and I'd love for them to be source. But building .NET stuff is beyond my meagre talent, so they've remained binary w/o the -bin name.

fryfrog commented on 2022-11-29 00:41 (UTC)

Yeah, I think parsing output of archlinux-java get for the correct version would be good. I'd probably also echo the command archlinux-java status to them and suggest archlinux-java set java-11-openjdk as the likely solution.

I'm not sure I'll get around to doing it soon, you're welcome to if you have time in the next day or two.

jkhsjdhjs commented on 2022-11-29 00:28 (UTC) (edited on 2022-11-29 00:30 (UTC) by jkhsjdhjs)

@fryfrog Since Java on Arch is a mess and this package has such weird requirements, I guess that would be a good idea. What do you think about just using archlinux-java get for that in the prepare function? Do you implement it?

Edit: Or might as well put it in the build function, since that's where the requirement must be met.

fryfrog commented on 2022-11-29 00:21 (UTC)

I just tried to build it w/ the wrong java version and saw the error. Would it be crazy to check the current java version in the PKGBUILD and exit if it is wrong?

jkhsjdhjs commented on 2022-11-28 23:38 (UTC) (edited on 2022-11-28 23:54 (UTC) by jkhsjdhjs)

This package is being built from source now. If you want to continue using a binary version of this package you can switch to https://aur.archlinux.org/packages/nzbhydra2-bin

If you continue using this package please mind that while it can be run with OpenJDK 17, it can only be built with OpenJDK 11 or older.

Both packages disable the self-updating functionality now, since it only creates litter in /usr that isn't removed when the package is removed via the package manager. Furthermore we don't want the updating functionality in the first place, since updating is done via the package manager.

If you used the updating functionality in the past you may want to clean your /usr/lib/nzbhydra2. I also recommend setting updateCheckEnabled to false in /var/lib/nzbhydra2/nzbhydra.yml, if you're using an existing config.

jkhsjdhjs commented on 2022-10-31 17:21 (UTC)

@fryfrog Sure, feel free to add me

fryfrog commented on 2022-10-31 16:34 (UTC)

@jkhsjdhjs, you've got some great ideas! How would you feel about co-maintainer and making them happen?

jkhsjdhjs commented on 2022-10-30 23:14 (UTC)

Also the README of nzbhydra2 states that the wrapper script that is currently used for launching isn't necessary: https://github.com/theotherp/nzbhydra2#how-to-run Thought I'd mention this as you wrote you are open for package improvements.

jkhsjdhjs commented on 2022-10-30 22:52 (UTC) (edited on 2022-10-30 22:52 (UTC) by jkhsjdhjs)

@fryfrog As per [1], additional constraints such as java-runtime-headless<=17 can be specified by listing the respective dependency multiple times. So in this case, you can leave java-runtime-headless>=8 as is and add java-runtime-headless<=17.

If someone has multiple java versions installed they can either change their default java version using archlinux-java or add an override using systemctl edit nzbhydra2 like the following:

[Service]
Environment=PATH="/usr/lib/jvm/java-11-openjdk/bin:$PATH"

Setting JAVA_HOME as in [2] doesn't seem work here unfortunately.

[1] https://wiki.archlinux.org/title/PKGBUILD#depends
[2] https://wiki.archlinux.org/title/Java#Launching_an_application_with_the_non-default_java_version

fryfrog commented on 2022-09-19 19:33 (UTC)

@hicklemon, if you know of a good Arch way to handle this I'm open to package improvements. I just looked at my java setup and my system was just set to use java-11-openjdk via archlinux-java.

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »