Bug#1039260: mactelnet: ships sysv-init script without systemd unit
I have pushed to the new vcs at https://salsa.debian.org/haakonn/mactelnet, and fixed the things you mentioned. I also added close tags for both bug #1047023 and #1039260 which I think is fixed by this release. I am unsure on how to test #1047023 if not by just running the mentioned commands "dpkg-buildpackage ; dpkg-buildpackage -S", and those ran without any errors, so hopefully that bug is also fixed. On Sun, 14 Apr 2024 at 23:12, Luca Boccassi wrote: > 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 > wrote: > > > > It needs the devices, but not for them to have ip yet. > > > > søn. 14. apr. 2024 kl. 21:25 skrev Luca Boccassi : > >> > >> 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 > 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 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, 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! >
Bug#1039260: mactelnet: ships sysv-init script without systemd unit
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 wrote: > > It needs the devices, but not for them to have ip yet. > > søn. 14. apr. 2024 kl. 21:25 skrev Luca Boccassi : >> >> 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 >> 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 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 >> >> 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, 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!
Bug#1039260: mactelnet: ships sysv-init script without systemd unit
It needs the devices, but not for them to have ip yet. søn. 14. apr. 2024 kl. 21:25 skrev Luca Boccassi : > 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 > 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 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 > 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, 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! >
Bug#1039260: mactelnet: ships sysv-init script without systemd unit
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 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 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 >> 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, 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!
Bug#1039260: mactelnet: ships sysv-init script without systemd unit
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 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 > 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, 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! >
Bug#1039260: mactelnet: ships sysv-init script without systemd unit
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 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, 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!
Bug#1039260: mactelnet: ships sysv-init script without systemd unit
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, 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! >
