Created attachment 542096 [details] nzbget-20.0 ebuild patch I've modified the eapi 7 compliant ebuild for nzbget-20.0 with some assistance from fedeliallalinea and completed testing of adding systemd service file. I've attached an ebuild patch that makes two categoric alterations to the ebuild one which fixes a minor bug with nzbget runtime environment inconsistency on gentoo linux ** Add systemd nzbget.service install directives to src_install() systemd service file is available in comments below with successful test results. ** nzbget-20.0 ebuild does not currently set fowners or fperms for /etc/nzbget.conf within the pkg_preinst() function but the init scripts should use nzbget.conf by default in init.d and proposed systemd service files. This nzbget.conf file issue is not fatal but restricts the web ui from writing changes due to nzbget.conf being owned by root:root ** nzbget default config files and documents instruct users to edit nzbget.conf and make no mention of an nzbgetd.conf config file. additionally an upstream default nzbget.conf file template is provided in /usr/share/nzbget nzbgetd.conf file appears to be a manufactured unnecessary addition. The additional unnecessary config file is also confusing as it does not apply to any required default upstream config files necessary for nzbget to function. nzbget.conf.d.patch file below added to address the issue with openrc ** Consider retiring and removing nzbgetd.conf to standardize with upstream and harmonize gentoo's config between openrc proposed systemd enhancements. nzbget.service [Unit] Description=NZBGet Daemon Documentation=http://nzbget.net/Documentation After=network.target [Service] User=nzbget Group=nzbget Type=forking PIDFile=/run/nzbget/nzbget.pid RuntimeDirectory=nzbget RuntimeDirectoryMode=0775 ExecStart=/usr/bin/nzbget -D -c /etc/nzbget.conf ExecStop=/usr/bin/nzbget -Q ExecReload=/usr/bin/nzbget -O KillMode=process Restart=on-failure [Install] WantedBy=multi-user.target nzbget.conf.d-r1.patch --- /usr/portage/net-nntp/nzbget/files/nzbget.confd 2015-08-08 19:38:18.000000000 -0500 +++ nzbget.conf.d-r1 2018-08-02 09:57:19.445548967 -0500 @@ -9,7 +9,7 @@ NZBGET_GROUP="nzbget" # Location of config file -NZBGET_CONFIGFILE="/etc/nzbgetd.conf" +NZBGET_CONFIGFILE="/etc/nzbget.conf" # Other options NZBGET_OPTS="" Service successfully running illusion ~ # systemctl status nzbget ● nzbget.service - NZBGet Daemon Loaded: loaded (/usr/lib/systemd/system/nzbget.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2018-08-02 08:36:26 CDT; 1h 2min ago Docs: http://nzbget.net/Documentation Process: 919 ExecStart=/usr/bin/nzbget -D -c /etc/nzbget.conf (code=exited, status=0/SUCCESS) Main PID: 920 (nzbget) Tasks: 10 (limit: 4915) Memory: 1.3G CGroup: /system.slice/nzbget.service └─920 /usr/bin/nzbget -D -c /etc/nzbget.conf Aug 02 08:36:26 illusion systemd[1]: Starting NZBGet Daemon... emerge --info https://bpaste.net/show/849bac581363 bonus credit to fedeliallalinea for tips and advice https://forums.gentoo.org/viewtopic-t-1084798-highlight-.html Best regards, ali3nx
Created attachment 542098 [details] nzbget.service
Created attachment 542100 [details, diff] nzbget.conf.d.patch
Created attachment 542220 [details] nzbget-20.0 ebuild patch Fixed ebuild patch submission
Hi, Thanks for the unit, it's probably a really useful addition but I can't test it right now. I think that the idea behind the two config files was to let users run nzbget themselves without passing an extra config file as parameter, hence the "~" in most configuration options. If a user were to run "nzbget" without arguments, it would probably work now but it wouldn't if we were to overwrite the file. I don't have any strong arguments for or against that behaviour as I didn't introduce it. Is there any problem is you make the sytemd unit use the nzbgetd.conf file? You should use use systemd_dounit from the systemd eclass, not doins.
I guess the systemd stuff is due to the eclass not supporting EAPI 7 yet, let's wait, a patch is currently being reviewed on the ML.
i suspected the systemd eclass support was coming but had no idea on a timeline so the ebuild patch using doins appeared to be an eapi 7 supported approach if the eclass was not being updated and potentially abandoned. If waiting for the eclass is preferred that's great. best to do it once the right way. If you need testers i'm not sure who would qualify or how you would find volunteers. I've been using gentoo for fifteen years, was on the infra team with Daniel Robbins briefly but in that time there's many things i've never learned :)
Yes, I'd rather wait for a few days/weeks. Have you tried passing --configfile /etc/nzbgetd.conf to the sytemd unit to see if it works?
(In reply to Louis Sautier (sbraz) from comment #7) > Yes, I'd rather wait for a few days/weeks. Have you tried passing > --configfile /etc/nzbgetd.conf to the sytemd unit to see if it works? I'm sure it would work. harmonizing the config file used between openrc, systemd and upstream appeared to be a beneficial approach.
Hi i'm curious if any progress has been made with EAPI 7 systemd.eclass? If not perhaps it may be acceptable to adjust the proposed ebuilds for EAPI 6? Nearly three months has passed since this package enhancement was submitted and perhaps some gentoo users would greatly enjoy being able to use nzbget
Finding a systemd environment isn't easy for me, I'm looking into this now.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=895aef81080868046d66517df146ee6fb4cd034d commit 895aef81080868046d66517df146ee6fb4cd034d Author: Louis Sautier <sbraz@gentoo.org> AuthorDate: 2018-10-29 21:49:32 +0000 Commit: Louis Sautier <sbraz@gentoo.org> CommitDate: 2018-10-29 22:21:22 +0000 net-nntp/nzbget: bump to 21.0_pre2220, add systemd unit Closes: https://bugs.gentoo.org/662648 Signed-off-by: Louis Sautier <sbraz@gentoo.org> Package-Manager: Portage-2.3.51, Repoman-2.3.11 net-nntp/nzbget/Manifest | 1 + net-nntp/nzbget/files/nzbget.service | 18 ++++ net-nntp/nzbget/nzbget-21.0_pre2220.ebuild | 129 +++++++++++++++++++++++++++++ 3 files changed, 148 insertions(+)
(In reply to Louis Sautier (sbraz) from comment #10) > Finding a systemd environment isn't easy for me, I'm looking into this now. Thank you :)