The devices are all configured already by the time a normal service is started, so you can omit it entirely then
On Sun, 14 Apr 2024 at 20:26, Håkon Nessjøen <haakon.nessj...@gmail.com> wrote: > > It needs the devices, but not for them to have ip yet. > > søn. 14. apr. 2024 kl. 21:25 skrev Luca Boccassi <bl...@debian.org>: >> >> If it doesn't need the network to be configured then you can avoid any >> dependency at all. >> >> On Sun, 14 Apr 2024 at 20:22, Håkon Nessjøen <haakon.nessj...@gmail.com> >> wrote: >> > >> > Thanks for your help, so far. Great to hear that you are willing to >> > sponsor it! >> > >> > I will change the dependencies of the service file as you said, but since >> > it in theory works before you have an IP address, so it shouldn't need to >> > wait for a DHCP client to finish before starting up, is it possible that >> > there are other dependencies I should target? Or does it still give most >> > sense to use the dependencies you mentioned? I don't have very much >> > experience with the order of things in the systemd startup process. >> > >> > I will request an account for Salsa in the meantime. >> > >> > On Sun, 14 Apr 2024 at 21:06, Luca Boccassi <bl...@debian.org> wrote: >> >> >> >> Requires=systemd-networkd.service >> >> After=systemd-networkd.service >> >> >> >> if you want to order it after the network is available, instead of >> >> those two lines you should use: >> >> >> >> Wants=network-online.target >> >> After=network-online.target >> >> >> >> so that it works with other network managers too. Also if >> >> mactelnet-locales only install locales, then it should be architecture >> >> "all" instead of "any". Also, consider requesting an account for Salsa >> >> and moving the repository there. >> >> >> >> If you fix these things and close the changelog I can sponsor the upload. >> >> >> >> On Sun, 14 Apr 2024 at 19:48, Håkon Nessjøen <haakon.nessj...@gmail.com> >> >> wrote: >> >> > >> >> > Hi, >> >> > >> >> > In relation to a new upstream version of mactelnet, I have updated the >> >> > debian packaging for this new version, which uses systemd service file >> >> > instead of the old sysv-init. I just need to find a sponsor, so that >> >> > the package can be updated. My last sponsor stopped being a DM for 6 >> >> > years ago I think. I'm not sure if it is ok to use this bug as a reason >> >> > for updating the module to a new minor version, not just a patch or >> >> > debian patch. As mactelnet has new functionality, supporting newer >> >> > devices/authentication protocol. >> >> > >> >> > Looking at RFS requests, they seem to either be about new packages, >> >> > adopted packages, or just security fixes. But this is a new upstream >> >> > version. How should I go forward with this? >> >> > >> >> > On Mon, 26 Jun 2023 at 00:26, <bl...@debian.org> wrote: >> >> >> >> >> >> Package: mactelnet >> >> >> Severity: important >> >> >> User: bl...@debian.org >> >> >> Usertags: missing-systemd-service >> >> >> >> >> >> Dear Maintainer(s), >> >> >> >> >> >> mactelnet has been flagged by Lintian as shipping a sysv-init script >> >> >> without a corresponding systemd unit file. The default init system in >> >> >> Debian is systemd, and so far this worked because a transitional >> >> >> sysv-init-to-unit generator was shipped by systemd. This is in the >> >> >> process of being deprecated and will be removed by the time Trixie >> >> >> ships, so the remaining packages that ship init scripts without >> >> >> systemd units will stop working. >> >> >> >> >> >> There are various advantages to using native units, for example the >> >> >> legacy generator cannot tell the different between a oneshot service >> >> >> and a long running daemon. Also, sanboxing and security features >> >> >> become available for services. For more information, consult the >> >> >> systemd documentation: >> >> >> https://www.freedesktop.org/software/systemd/man/systemd.unit.html >> >> >> >> >> >> You can find the Lintian warning here: >> >> >> >> >> >> https://lintian.debian.org/sources/mactelnet >> >> >> >> >> >> In case this is a false positive, please add a Lintian override to >> >> >> silence it and then close this bug. >> >> >> >> >> >> Thanks!
