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
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
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
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#749658: mactelnet: Function declaration without parameter list shadows risk of stack underflow
Thanks! Will fix :) On 29 May 2014 00:43, Michael Tautschnig wrote: > Package: mactelnet > Version: 0.4.0-1 > Severity: minor > Usertags: goto-cc > > During an analysis of all Debian packages using our research compiler > tool-chain > (using tools from the cbmc package) the following error was found: > > The function net_init_raw_socket requires one argument: > > http://sources.debian.net/src/mactelnet/0.4.0-1/interfaces.c?hl=250#L250 > > Yet the declaration here > > http://sources.debian.net/src/mactelnet/0.4.0-1/interfaces.h?hl=42#L42 > > does not include a parameter list (and neither specifies it as "void"), > thus the > compiler cannot warn about the missing argument. > > At present, however, this appears safe as the argument is not used. > > Best, > Michael > > -- Håkon
Bug#737845: cavezofphear: please provide a desktop and menu file and icons
Hi, I could create a desktop and/or a menu file. But the game does not have any official logo or icon. What would I use as icon? Any ideas? I will contact the upstream author if thats the best solution. Regards, Håkon On 6 February 2014 13:44, Markus Koschany wrote: > Package: cavezofphear > Version: 0.5.1-1 > Severity: wishlist > User: pkg-games-de...@lists.alioth.debian.org > Usertags: desktop-integration goals not-gamesteam > > Dear maintainer, > > currently cavezofphear does not supply a desktop file and no desktop and > menu icons. Hence the game is not well integrated into the user's > desktop environment. Please consider helping to improve the desktop > integration of games in Debian. > > https://wiki.debian.org/Games/JessieReleaseGoal > > Regards, > > Markus > > -- Håkon
Bug#650690: ITP: cavezofphear -- ASCII boulder dash clone game
Package: wnpp Owner: "Håkon Nessjøen" Severity: wishlist * Package name : cavezofphear Version : 0.5.1 Upstream Author : Tom Rune Flo * URL : http://www.x86.no/cavezofphear/ * License : GPL3+ Programming Lang: C Description : ASCII boulder dash clone game in color This is a boulder dash type of game, for terminals. You walk around in a ASCII underground cave system, where you need to keep clear of boulders falling in on your head while you are searching for diamonds. It depends on libncurses5, and compiles fine on kfreebsd and hurd too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#615823: ITP: mactelnet -- Console tools for telneting and pinging via MAC addresses
Package: wnpp Severity: wishlist Owner: "Håkon Nessjøen" * Package name: mactelnet Version : 0.3 Upstream Author : Håkon Nessjøen * URL : https://github.com/haakonnessjoen/MAC-Telnet * License : GPL Programming Lang: C Description : Console tools for telneting and pinging via MAC addresses Ping, discovery and telnet tools for connecting to Mikrotik RouterOS devices, or other MAC-Telnetd powered machines/devices. Includes telnet-client and server, ping application, and discovery application. Telnet deamon is able to receive connections from other computers on the same physical network, even when the network interface has wrong or no ip address. This makes a easier job for human error prone network administrators. Tested on both big and small endianed platforms. Tested on: i386/amd64 and MIPS 4kc(with qemu emulator). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
