Bug#1055599: dh_installsystemd tries to start static unit which deb-systemd-invoke rejects
Package: debhelper Version: 13.11.4 If I include this static (i.e. no [Install] section) systemd service: # debian/debhelper-example.service [Service] Type=oneshot ExecStart=true then dh_installsystemd will insert this snippet in postinst: if [ -n "$2" ]; then _dh_action=restart else _dh_action=start fi deb-systemd-invoke $_dh_action 'debhelper-example.service' >/dev/null || true When I install the package, deb-systemd-invoke issues a warning: debhelper-example.service is a disabled or a static unit, not starting it. Indeed, such a unit should not be started on package installation (but rather by a path, socket or timer unit). I notice that dh_installsystemd produces another snippet which enables the unit if it contains an [Install] section. I think both snippets should be omitted for static units. On upgrades, the restart part makes more sense, but for type=oneshot I think that's only relevant if RemainAfterExit=true. As a workaround, I can write: override_dh_installsystemd: dh_installsystemd --no-start in debian/rules, but that prevents any units from being started, not just the static ones. I assume you have to list the static units with --no-start, and the others without it, but that's more error prone than letting debhelper handle it.
Bug#1055591: maintainer-script-lacks-home-in-adduser erroneously raised
Package: lintian Version: 2.116.3 If my postinst contains: adduser --system --home=/var/lib/myuser myuser Then lintian complains: E: lintian-adduser-bug: maintainer-script-lacks-home-in-adduser "adduser --system --home=/var/lib/myuser myuser" [postinst:2] As a workaround, I can wrap adduser or --system in quotes, or remove the equals sign between --home and the directory. Then lintian does not complain, even though those variations have the same meaning.
Bug#1053449: VisiData requires python3-pkg-resources
Package: visidata Version: 2.11-1 When I install visidata in a fresh debian:sid docker container, it crashes when I try to start it: File "/usr/bin/vd", line 3, in import visidata.main File "/usr/lib/python3/dist-packages/visidata/__init__.py", line 102, in import visidata.main File "/usr/lib/python3/dist-packages/visidata/main.py", line 19, in from pkg_resources import resource_filename ModuleNotFoundError: No module named 'pkg_resources' If I also install python3-pkg-resources, it does start. Is it a dependency? I see that bullseye is not affected, but bookworm and trixie are.
Bug#1051423: Documentation for return command
Package: dash Version: 0.5.11+git20200708+dd9ef66-5 Dear maintainer, The dash manpage states: The syntax of the return command is return [exitstatus] It terminates the currently executing function. Return is implemented as a builtin command. I can't find any reference to what happens when exitstatus is omitted. Bash does this: return [n] Causes a function to stop executing and return the value specified by n to its caller. If n is omitted, the return status is that of the last command executed in the function body. Is it the same? Could a sentence be added to the manpage (or return could be added to the builtins section, like exit)? Kind regards, Dan
Bug#1025976: python3-minimal: debpython.files.from_package passes input to system shell
Package: python3-minimal
Version: 3.9.2-3
Severity: normal
X-Debbugs-Cc: danseb...@gmail.com
Dear Maintainer,
The from_files function in /usr/share/python3/debpython/files.py passes its
argument to the shell. It calls `Popen("/usr/bin/dpkg -L %s" %
package_name, shell=True)`, executing the contents of package_name as code.
A safe alternative is `subprocess.run("/usr/bin/dpkg", "-L", package_name)`.
A consequence of this is that `py3clean "--package=; touch /tmp/hello"`
runs the embedded command and shows the incorrect error message
"dpkg-query: error: --listfiles needs at least one package name argument"
instead of e.g. "dpkg-query: package '; touch /tmp/hello' is not installed".
Yours faithfully,
Dan
Bug#987188: libcurl3-gnutls from buster-backports enables broken tls 1.3
I stumbled upon the same issue when trying to use libcurl to send e-mail via "smtp.googlemail.com" as part of a C application. With curl 7.64, TLS 1.2 is used and the e-mail is sent. However, with curl 7.74, TLS 1.3 is used, and I see (before any SMTP communication): * GnuTLS recv error (-10): The specified session has been invalidated for some reason. * Closing connection 0 context.c:91 Cannot transfer: Failure when receiving data from the peer So the e-mail is not sent. libcurl3-gnutls never used TLS 1.3 before https://github.com/curl/curl/pull/5223 . We could revert that change for buster backports by disabling this "if" check https://github.com/curl/curl/blob/curl-7_74_0/lib/vtls/gtls.c#L587 so that +SRP is always in the "priority list" and TLS 1.3 is always disabled. git has a GIT_SSL_VERSION option, but it doesn't seem to work (this fails, trying to use TLS 1.3 anyway): GIT_CURL_VERBOSE=T GIT_SSL_VERSION=tlsv1.2 git clone https://github.com/git/git In case it helps anyone else, my application works again when I set CURLOPT_SSLVERSION to CURL_SSLVERSION_MAX_TLSv1_2 .
