It seems that over the years I have taken over maintenance for too many packages and I cannot really give all of them the care that they deserve. Thus, I request an adopter for the stunnel4 package. The package description is: The stunnel program is designed to work as SSL encryption wrapper between remote client and local (inetd-startable) or remote server. The concept is that having non-SSL aware daemons running on your system you can easily setup them to communicate with clients over secure SSL channel. . stunnel can be used to add SSL functionality to commonly used inetd daemons like POP-2, POP-3 and IMAP servers without any changes in the programs' code. . This package contains a wrapper script for compatibility with stunnel 3.x
Hi Peter, I saw your RFA for stunnel4 and I am interested in adopting the package. I've previously helped with other Debian packages and would like to step up to maintainership with this one. I've been looking at the current packaging and I have a few initial improvements in mind to align it with current best practices: 1. Set "Priority: optional" in debian/control to satisfy Lintian. 2. Modernize the debhelper setup by switching to "debhelper-compat (= 14)" and removing the "X-DH-Compat" header. 3. Address bug #826883 by standardizing the systemd unit names (e.g. renaming stunnel4@.stunnel.service to a more conventional stunnel4@.service) and potentially removing the associated Lintian override. 4. Fix the case of the "version" field in debian/watch. I've already retitled the bug to ITA and set myself as the owner. Since I'm new to being the primary maintainer, I'd really value any advice or specific areas of the code you think I should focus on. If you're open to it, I'd appreciate any feedback on these proposed changes as I get started. Best regards, James Montgomery
complex than some of the other Debian packages out there. For instance, there is one item that I have been putting off for years: renaming the package itself (both binary and source) to "stunnel". The "stunnel4" name is an unfortunate legacy of the now distant past, when stunnel migrated from version 3 to version 4; we have been at version 5 for many years now, and I have put off renaming the package mainly for reasons of backwards incompatibility, but it is high time now. Actually I think I will start that process in the coming day or two; I say "start that process" because it will involve at least one, possibly two trips through the NEW queue. the Lintian version from Debian unstable will not warn about it, since this is not a problem. "Priority: optional" is dpkg's default now, there is no need to specify it explicitly. So this one is already in line with current best practices :) If you look at the debhelper manual page in testing or unstable, you will see that the X-DH-Compat header is the recommended way now; debhelper looks for it first. Also, just in case you've seen a pedantic-level Lintian message, yes, debhelper does recommend that the header's name be spelled exactly that way. So this one is also in line with current best practices :) because the package shall be renamed to "stunnel" and I wanted to make sure that people who enable per-config-file systemd units will not have to rename them soon. This is by design. Also, the #826883 bug itself will go away soon in a different way: once the stunnel4 package is renamed to stunnel, I also intend to drop the "start all the configured tunnels" SysV init script because it has long been unsupported by upstream, a Debian-specific addition, and it requires that the stunnel configuration deviate from recommended upstream best practices (e.g. it relies on PID files). So, once that is removed, there will be no SysV init script without a corresponding systemd unit file :) Take a look at the debian-watch(5) manual page in testing or unstable; the first paragraph consisting of a single "Version: 5" line is exactly as recommended there. Well, TBH, first I would recommend making sure that you do your package builds on either a testing or unstable system, so that you can use the most recent versions of the Debian packaging tools and so adhere to current best practices :) Other than that, could you please hold off making any changes to the repository for a couple of days? I think I will really start the package rename process Real Soon Now(tm). But apart from that, it's great that you want to help, and actually taking on a not-trivial package is a good way to learn how to handle the not-trivial parts of Debian packaging :) I will be glad to help with that. G'luck, Peter
...of course I meant Policy versio 4.7.3 here :) [snip] And of course I meant "non-trivial" here in both places, no idea what my fingers were thinking... G'luck, Peter
Hi Peter, Thank you for the detailed feedback and for outlining the planned rename. I've updated my local packaging to align with your direction: - Dropped the systemd renaming and Priority changes. - Preserved debhelper compat level 14. I’ve pushed a `contributor-mode` branch to my Salsa fork containing some housekeeping and upstream-bound fixes: https://salsa.debian.org/monty/stunnel This includes a consolidated patch (06-upstream-fixes.patch) addressing: - ulimit portability in the init script - a minor manpage typo I plan to forward these fixes upstream to the stunnel-users mailing list. If helpful, I would be glad to assist with the package rename or prepare any transition-related changes. Best regards, James
[snip] a couple of things, mostly outside Debian, interfered. But now the package rename should be complete: both unstable and testing now have the new "stunnel" source package that builds the "stunnel" binary package and also the "stunnel4" compatibility one. The compatibility package must be kept at least until the next Debian release so that `apt upgrade` will bring in "stunnel". Apologies for holding you back; as far as I am concerned, you have a green light now for adopting stunnel if I have not completely killed your desire to do so :/ G'luck, Peter