Bug#1074175: netkit-rwho: remove for trixie?
Hi. Most tools from netkit are candidates for migration to GNU InetUtils, and rwho(d) may be another one -- see email and bug report below. Cc'ing debian-devel to have broader discussion. First, I think we need to understand the rationale for doing anything about 'netkit-rwho': do we want to do something because 1) it is not maintained upstream? or 2) because it is an insecure design?, or 3) something else? I believe that like telnet and ftp the second argument is not convincing enough: sometimes you need these implementations for various strange things, and it is poor style to dictate what people must do with their software. The position I've taken in GNU InetUtils is that it is better for users to offer maintained tools and include a notice that they are insecure, rather to offer un-maintained tools and refuse to work further on them because they are insecure, putting users into a worse situation than before. Some people may disagree, and instead believe it is better to actively kill old things rather than continue support them. This is a subjective decision, and if people are willing to do the work to keep things alive, I think it is better to let them than to refuse this contribution. So, are our reason for doing anything about netkit-rwho really because netkit upstream is not maintained? If so, then one option is to add a rwho(d) implementation to GNU InetUtils and let that replace the netkit implementation in Debian. Historically, netkit tools have often had unclear or weird license situation, so my preference is to import rwho(d) from some of the BSD and to make that build for a wide variety of architectures and platforms like we do with other tools in GNU InetUtils. The BSD implementations are usually not intended to be portable, and often have some minor flaw that makes them troublesome to build on Debian -- we fix those issues in GNU InetUtils. That said, introducing yet another fork into the ecosystem shouldn't be done lightly, so we should explore some way to pool resources (like I've tried to establish with tnftp(d) maintainers when we have joint bugs). I haven't analyzed what rwho(d) implementations are out there. I see NetBSD/FreeBSD has one still in -current, but OpenBSD removed it during 5.x. Are people aware of any other implementations worth considering? What do you think? /Simon Gürkan Myczko writes: > rwho(d) is a design from a different time, when networks were > trusted, and so on. It seems to me, we should and could stop > shipping it for trixie. > > I'm raising this bug now, to: > 1) establish awareness > > I was long aware of this, as I was using rwhod/ruptime when networks > were not split into thousand networks... > > 2) auto-rm it from trixie > > I'd rather have a migration path, not binary compatible, but > functionality compatible > > 3) give people time to chime in / secure replacements to show up > > Please have a look at https://github.com/alexmyczko/rutpime (there's > an ITP for it, and it has > been in new queue several times: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013361 > > After a while I intend to clone this bug to ftp.debian.org for > removal from unstable. > > Please do not remove it if possible. I really wish to have a migration > path for this, but well > we're waiting for ftp team. > > Best, > Alex > > Chris > > signature.asc Description: PGP signature
Bug#982253: Bug#986997: O: netkit-telnet -- basic telnet client
Chris Hofstaedtler writes: > * Simon Josefsson [210415 19:06]: >> Hi! Upstream is not maintained either -- at least the download URL in >> netkit-telnet's debian/copyright file does not work. How about dropping >> netkit-telnet from Debian? > > In #982253 I've expressed that I for one would find that to be a > good idea. But quite clearly it is work that needs to be a) done and > b) well coordinated. I'm happy to work on replacing netkit-based tools with inetutils once bullseye is out, although Guillem have to agree since he maintains inetutils in Debian. If something needs to be modified in inetutils to be more compatible with netkit, I will help to arrange that. Starting with telnet+telnetd seems like a good idea. As far as I can tell, telnet is not installed by default on buster nor bullseye which is good. Btw, the suggestion to symlink telnet to netcat is not a good one: telnet is a complex protocol, netcat doesn't support any of it as far as I know. /Simon signature.asc Description: PGP signature
Bug#951010: signify and signify-openbsd names
Hi
I would like that 'apt install signify' install OpenBSD's signify (from
the Debian 'signify-openbsd' package) and not the 2003 mail-related
signify perl script from the Debian 'signify' source package.
I would also like that /usr/bin/signify is OpenBSD's signify, after
doing the 'apt install signify', instead of /usr/bin/signify-openbsd.
As background please read:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951010
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738884
What do you think about the attached debdiff for the existing
(non-OpenBSD) 'signify' source package?
This will rename the binary package to 'signify-mail', as suggested in
the first bug report above, and add a 'signify (<< 1.14-8~)' Replaces
header.
Is anything more required here? Any objections to an upload? The
package seems to be orphan'ed and QA-maintained. One alternative is to
remove the package, but that seems to involve more effort than a QA
upload.
The next step would be for the 'signify-openbsd' source package to
rename the 'signify-openbsd' binary package to 'signify'. I believe it
should declare a Conflicts and Breaks towards 'signify (<< 1.14-8~)'.
The final step would be for signify-openbsd's 'signify' package to
rename the binary into /usr/bin/signify, and that would require adding a
Conflicts/Breaks towards all versions of signify-mail.
Tomasz, what do you think about this?
Adding debian-devel to get wider review of the
Replaces/Conflicts/version magic, this always tend to confuse me.
See pipeline for the 'signify' source package that I propose to upload:
https://salsa.debian.org/jas/signify/-/pipelines/742414
To make this happen for trixie, I don't see how to do it. Anyone having
the old 'signify' package on their system would get OpenBSD's signify
instead of the new 'signify-mail' package after an upgrade. Is that
problem really worth caring about? I think a release note about this
could solve it. I believe OpenBSD's 'signify' is important enough to
warrant this to be part of trixie instead of having to wait for t+1.
/Simon
diff -Nru signify-1.14/debian/changelog signify-1.14/debian/changelog
--- signify-1.14/debian/changelog 2020-06-05 21:06:41.0 +0200
+++ signify-1.14/debian/changelog 2024-10-05 11:58:55.0 +0200
@@ -1,3 +1,14 @@
+signify (1.14-8) unstable; urgency=medium
+
+ * QA upload.
+ * Rename binary package signify to signify-mail, adding Replaces
+field.
+ * Standards-Version: 4.7.0.
+ * Fix lintian update-debian-copyright.
+ * d/t/control: Use new package name.
+
+ -- Simon Josefsson Sat, 05 Oct 2024 11:58:55 +0200
+
signify (1.14-7) unstable; urgency=medium
* QA upload.
diff -Nru signify-1.14/debian/control signify-1.14/debian/control
--- signify-1.14/debian/control 2020-06-05 21:06:41.0 +0200
+++ signify-1.14/debian/control 2024-10-05 11:58:55.0 +0200
@@ -4,14 +4,15 @@
Build-Depends: debhelper-compat (= 13)
Maintainer: Debian QA Group
Rules-Requires-Root: no
-Standards-Version: 4.5.0
+Standards-Version: 4.7.0
Testsuite: autopkgtest-pkg-perl
Vcs-Browser: https://salsa.debian.org/debian/signify
Vcs-Git: https://salsa.debian.org/debian/signify.git
Homepage: http://signify.sf.net
-Package: signify
+Package: signify-mail
Depends: ${misc:Depends}, ${perl:Depends}
+Replaces: signify (<< 1.14-8~)
Architecture: all
Description: Automatic, semi-random ".signature" rotator/generator
Signify is a neat little program that allows a random signature to be
diff -Nru signify-1.14/debian/copyright signify-1.14/debian/copyright
--- signify-1.14/debian/copyright 2020-06-05 21:06:41.0 +0200
+++ signify-1.14/debian/copyright 2024-10-05 11:58:55.0 +0200
@@ -10,6 +10,7 @@
Files: debian/*
Copyright: 1996-2004 Brian White
2015 Mattia Rizzolo
+ 2024 Simon Josefsson
License: public-domain
License: public-domain
diff -Nru signify-1.14/debian/rules signify-1.14/debian/rules
--- signify-1.14/debian/rules 2020-06-05 21:06:41.0 +0200
+++ signify-1.14/debian/rules 2024-10-05 11:58:55.0 +0200
@@ -1,6 +1,6 @@
#! /usr/bin/make -f
-p := signify
+p := signify-mail
%:
dh $@
diff -Nru signify-1.14/debian/tests/control signify-1.14/debian/tests/control
--- signify-1.14/debian/tests/control 2020-06-05 21:06:41.0 +0200
+++ signify-1.14/debian/tests/control 2024-10-05 11:58:55.0 +0200
@@ -1 +1,2 @@
Test-Command: signify --input=debian/tests/files/filetest.txt
+Depends: signify-mail
signature.asc
Description: PGP signature
Bug#1086100: Replace obsolete Build-Depends: libidn11-dev with libidn-dev
Package: hesiod Version: 3.2.1-4 Control: block 1066855 by -1 Severity: important Hi! This package build-depends on "libidn11-dev" but that is a transitional package that we want to remove before trixie. Could you update your package to Build-Depends on libidn-dev instead of libidn11-dev? For more information, see: https://bugs.debian.org/1066855#20 Thanks, Simon signature.asc Description: PGP signature
Bug#1086102: Replace obsolete Build-Depends: libidn11-dev with libidn-dev
Package: jreen Version: 1.2.0+ds-2 Control: block 1066855 by -1 Severity: important Hi! This package build-depends on "libidn11-dev" but that is a transitional package that we want to remove before trixie. Could you update your package to Build-Depends on libidn-dev instead of libidn11-dev? For more information, see: https://bugs.debian.org/1066855#20 Thanks, Simon signature.asc Description: PGP signature
