Package Details: nzbhydra2-nojava-bin 5.1.2-2

Git Clone URL: https://aur.archlinux.org/nzbhydra2-nojava-bin.git (read-only, click to copy)
Package Base: nzbhydra2-nojava-bin
Description: Search aggregator for newznab and torznab indexers.
Upstream URL: https://github.com/theotherp/nzbhydra2
Licenses: Apache
Conflicts: nzbhydra2
Provides: nzbhydra2
Submitter: gee
Maintainer: gee (jkhsjdhjs)
Last Packager: gee
Votes: 0
Popularity: 0.000000
First Submitted: 2023-01-23 12:31 (UTC)
Last Updated: 2023-02-07 19:58 (UTC)

Latest Comments

1 2 3 Next › Last »

jkhsjdhjs commented on 2023-02-07 12:17 (UTC)

Feel free to propose the other changes upstream if you have the time. Btw regarding the package update: it's better to export NZBHYDRA_DISABLE_WRAPPER_CHECK in the nzbhydra2.sh script, as it is then also exported when nzbhydra is ran manually, without the systemd service.

gee commented on 2023-02-07 02:52 (UTC)

We got the ARM build so I updated the package and we don't need to keep the OG wrapper anymore. Do you want to request the other env variables to drop some patches or would you rather I do it?

jkhsjdhjs commented on 2023-02-05 21:04 (UTC)

Hey, didn't update this package yet as the arm64 build is not part of the release assets. Let's see if it will be added in the near future.

gee commented on 2023-02-02 00:50 (UTC)

I've created a first issue: https://github.com/theotherp/nzbhydra2/issues/839

If that is accepted I'll ask about the others.

jkhsjdhjs commented on 2023-01-31 21:39 (UTC)

I agree. The wrapper-remove-update-support.patch may be implemented upstream via the NZBHYDRA_DISABLE_UPDATE environment variable, that is already implemented for the main application.

The release type detection doesn't work because it checks for the existance of files/directories, that aren't present in the same directory.... wait I think the release type detection would actually work for this package, since the file core is located in the same directory as the wrapper. However, it doesn't work for the other packages. Maybe it could be patched to also check the path given by HYDRAWORKINGFOLDER, which is where the .jar file is located for the other packages.

The last problem would be the base path checks. To workaround the check for readme.md we could install a dummy file or a symlink to the actual location of the readme. I'm not sure how it could be adjusted to work for us as well, and I don't think upstream would be willing to remove the check. The other check checks for the lib-directory. A workaround would again be installing a dummy lib file. Not sure how a clean solution aside from removing the check would look like.

gee commented on 2023-01-29 02:21 (UTC)

Right but for others it is useful to disable. Like nzbhydra2 already displays different stuff when the update is disabled and tells you to ask your docker/package manager submitter.

jkhsjdhjs commented on 2023-01-28 18:42 (UTC)

I don't think so, since the patches explicitely disable or remove functionality that would be useful for installations that aren't managed by a package manager.

gee commented on 2023-01-28 15:17 (UTC)

Yup it's strange.

Maybe it's worth asking upstream for a toggle. Actually maybe your patches can be toggled directly in upstream's wrapper?

jkhsjdhjs commented on 2023-01-28 14:22 (UTC) (edited on 2023-01-28 14:31 (UTC) by jkhsjdhjs)

Hmm that's also weird. If it doesn't find any wrapper, why does it show the "outdated wrapper banner"? Also, for me it doesn't find any wrapper, but also doesn't show a banner.

gee commented on 2023-01-28 12:58 (UTC)

Is this the one?

"Didn't find any of the expected wrapper files (/usr/lib/nzbhydra2) in folder NZBHydra2.exe, NZBHydra2 Console.exe, nzbhydra2, nzbhydra2wrapper.py, nzbhydra2wrapperPy3.py"

Maybe I need to add the original one, let's try. Yup that seemed to work, it's a bit dirty though but only 30k...