https://github.com/nzbget/nzbget is archived, but I came across an active fork at https://github.com/nzbget-ng/nzbget. Could the ebuild be changed over to this? Cheers.
Since this has been open for some time I'll work on this and offer to proxy maintain it. I am familiar with the software and a heavy usenet user (used to use this before going to sabnzbd). Sven, just so I don't step on your toes if you still want it just reassign to yourself.
Putting swegener into CC.
(In reply to Joe Kappus from comment #1) > Since this has been open for some time I'll work on this and offer to proxy > maintain it. I am familiar with the software and a heavy usenet user (used > to use this before going to sabnzbd). Sven, just so I don't step on your > toes if you still want it just reassign to yourself. Hi, Sven hasn't touched the ebuild since 2016. I have been maintaining it since then. I just didn't feel like changing upstreams before being sure that the new one was trustworthy. Have you tried it yet? I guess we could release upstream's v21.4-rc2 as 21.4_pre2. It's too bad the new maintainer didn't update the changelog though. I don't mind co-maintainers, feel free to make a PR and add yourself.
It came to my attention that there is another fork: https://github.com/nzbgetcom/nzbget What do you guys think?
That fork might actually be better to target, here's their discussion/philosophy on it: https://github.com/nzbgetcom/nzbget/discussions/37 and reddit release announcement: https://www.reddit.com/r/usenet/comments/17k0tda/new_nzbget_project/ nzbget's had a longstanding issue where it can't de-obfuscate nzb releases posted by a certain group. nzbget-ng can but it also breaks support for BSD OS's. This new fork seems to have taken a more planned/conservative approach to support new hardware/OS and leaves handling the de-obfuscation task to an external script. Yeah, we should probably use this one instead.
