Bug#1072221: secure_permission from user-group-modes.patch does not account for symlinks installed by systemd
On Thu, May 30, 2024 at 12:04:02PM -0400, Ryan Kavanagh wrote: > systemd services that use ssh (e.g., backup services launched by a > systemd timer) abort with: > > Bad owner or permissions on > /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf > > After quickly tracing through the sources, I suspect that this is due to > Debian's user-group-modes.patch. It introduces a function > secure_permission and patches read_config_file_depth in readconf.c to > use secure_permission to check that a configuration file is not world > writeable. Unfortunately, the check > > if ((st->st_mode & 002) != 0) > > in secure_permission does not account for symlinks. I'm not sure that can be it, because as far as I can tell this is only ever called on a stat buffer resulting from stat() or equivalent, not lstat(). It shouldn't see the permissions on the symbolic link itself. Are you in a position to trace any further? A copy of one of the relevant systemd units might be helpful information. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071997: RM: troffcvt -- ROM; unmaintained upstream; broken with groff 1.23.0
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove The troffcvt package, which I've maintained since 2001, is broken as of groff 1.23.0 (see https://bugs.debian.org/1059802). This is because it relies on groff's macros, but it uses its own parser for the underlying *roff language, and that parser doesn't implement some features added to groff in 2001 that groff's macros now rely on more fundamentally than they used to. I've spent some time trying to fix this, and while I've made some progress it would take quite a bit more time to finish. I've reached the conclusion that it probably isn't worth spending that time. There hasn't been an upstream release of troffcvt since 1997; https://qa.debian.org/popcon.php?package=troffcvt shows negligible use; and nothing depends or build-depends on it. Any users are likely better off using groff's own facilities for formatting to HTML or plain text, or perhaps using something like pandoc. Please remove troffcvt from unstable. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071292: openssh-server: sshd fails to restart at package upgrade, future logins to server impossible
On Fri, May 17, 2024 at 09:42:05PM +0200, Sven-Haegar Koch wrote: > I just upgraded openssh as part of my normal "apt dist-upgrade" every > few days, from 1:9.7p1-4 to 1:9.7p1-5. > > The whole apt went through without any errors - but afterwards sshd > was no longer running / listening on its network ports. Hm, I haven't seen this elsewhere either in my own upgrades or from anyone else, and as you say the ssh.service logs don't give much to go on. Is there anything informative in /var/log/auth.log, perhaps? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1030119: Bug#1018260: openssh-server: fills the log with "deprecated reading of user environment enabled"
Control: tag -1 patch On Mon, May 01, 2023 at 03:57:38PM +0100, Richard Lewis wrote: > Was there an update on this bug against release-notes: the MR against openssh > at > https://salsa.debian.org/ssh-team/openssh/-/merge_requests/21/diffs > doesnt seem to be merged - has this been parked? After some of the more recent discussion, I'm persuaded that I should move up the timeline I proposed, and remove this and document the removal in the release notes of the same Debian release. > Based on the text in that MR , but if I i used this feature i would > want to know: > - can this prevent me logging in? (eg if i am doing the upgrade over ssh) > - will it drop my ssh connection (release-notes does iirc advise > upgrading inside tmux or screen) > - what do i do if i need the settings in pam-envionment - can i add > them to ssh_config? (I assume re-enabling a > deprecated setting is not a good thing to recommend in release-notes) > (and should i do so before or after upgrading?) > > > The release notes could say something like: > > > ssh no longer reads ~/.pam-environment > > The ssh package, which allows > secure login to remote systems, no longer reads the user's > ~/.pam_environment file by default. > See for details. > If you used this feature, you should move variables set in > ~/.pam_environment file to > ~/.ssh/ssh_config before upgrading . > > > > (should there be something about the pam deprecation itself?) Thanks for this. I've adapted these notes into https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/204. (They weren't quite right in some areas: any changes have to be made on the server, not the client, and the only non-root-accessible sshd configuration options that are relevant to this such as ~/.ssh/environment are disabled by default, so I just resorted to suggesting that people move settings to their shell initialization files instead. It isn't perfect, but I think it's OK to assume that people who've gone to the effort of setting this can figure something out given the hint.) -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071676: Packages-arch-specific: Remove ethtool?
Package: buildd.debian.org Severity: normal Tags: patch ethtool has been declared as "Architecture: linux-any" since 1:5.8-1 (see https://bugs.debian.org/961965), which predates oldstable. It's still a problem in oldoldstable, but I'm not sure Packages-arch-specific systematically cares about that. Can we just remove it? diff --git a/Packages-arch-specific b/Packages-arch-specific index aa69ebe..d15ba5f 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -56,6 +56,5 @@ fdflush: alpha amd64 i386 # amd64/i3 # linux specific %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 -%ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %vmpk: !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 # needs RtMidi/real ALSA, see #557899 Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071674: Packages-arch-specific: Remove linux-wlan-ng
Package: buildd.debian.org Severity: normal Tags: patch linux-wlan-ng hasn't been in any stable release for years, and was removed from unstable in November 2023 (see https://tracker.debian.org/pkg/linux-wlan-ng), so it's no longer in the archive at all. There should be no need to keep it in Packages-arch-specific any more. diff --git a/Packages-arch-specific b/Packages-arch-specific index aa69ebe..9112a32 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -22,7 +22,6 @@ fdflush: alpha amd64 i386 # amd64/i386/alpha specific %libgcr410: i386 amd64 # [ANAIS] -%linux-wlan-ng: amd64 i386 powerpc armel armhf alpha hppa# ANAIS [?] # xorg stuff %xf86-input-multitouch: !s390x Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#961970: vmpk: Please change to Architecture: linux-any
Control: reassign -1 buildd.debian.org Control: retitle -1 Packages-arch-specific: Remove vmpk Control: tag -1 patch On Tue, Apr 05, 2022 at 09:00:20PM +0200, Pedro Lopez-Cabanillas wrote: > > vmpk is linux specific (#557899). > > This was true many years ago, when vmpk was based on RtMidi. It was > replaced by drumstick-rt in vmpk-0.6.0 released in 2014-09-07. > > Since then, vmpk has been successfully ported to FreeBSD. > https://www.freshports.org/audio/vmpk > https://www.freshports.org/audio/drumstick This suggests that we should remove vmpk from Packages-arch-specific. As it happens, kFreeBSD has been removed from debian-ports, and libdrumstick-dev hasn't been built for Hurd (https://buildd.debian.org/status/package.php?p=libdrumstick) - but that just means that vmpk will automatically sit in dep-wait, and there's no need to have a special exception for it. diff --git a/Packages-arch-specific b/Packages-arch-specific index aa69ebe..05a7b08 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -58,4 +58,3 @@ fdflush: alpha amd64 i386 # amd64/i3 %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 -%vmpk: !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 # needs RtMidi/real ALSA, see #557899 Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1066822: linuxtv-dvb-apps: diff for NMU version 1.1.1+rev1500-1.5
Control: tags 961967 + patch
Control: tags 961967 + pending
Control: tags 1066822 + patch
Control: tags 1066822 + pending
Dear maintainer,
I've prepared an NMU for linuxtv-dvb-apps (versioned as
1.1.1+rev1500-1.5) and uploaded it to DELAYED/5. Please feel free to
tell me if I should delay it longer.
I would have sent these as git merge requests of some form, but
Vcs-Git/Vcs-Browser are still set to the obsolete anonscm.debian.org and
I couldn't find any corresponding repositories on salsa, so this was the
best I could do; you should be able to find more detailed history via
"dgit clone linuxtv-dvb-apps" if you need it.
Regards,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog 2020-07-26 19:42:38.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog 2024-05-23 16:49:59.0 +0100
@@ -1,3 +1,11 @@
+linuxtv-dvb-apps (1.1.1+rev1500-1.5) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Work around UAPI break in Linux input events (Closes: #1066822).
+ * Set Architecture to linux-any (Closes: #961967).
+
+ -- Colin Watson Thu, 23 May 2024 16:49:59 +0100
+
linuxtv-dvb-apps (1.1.1+rev1500-1.4) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/control linuxtv-dvb-apps-1.1.1+rev1500/debian/control
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/control 2016-04-07 17:11:50.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/control 2024-05-23 16:49:59.0 +0100
@@ -11,7 +11,7 @@
Homepage: http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps
Package: dvb-apps
-Architecture: any
+Architecture: linux-any
Depends:
${shlibs:Depends},
makedev | udev,
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series 2020-07-26 19:38:59.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series 2024-05-23 16:49:59.0 +0100
@@ -11,3 +11,4 @@
dst_test-no-set-id.patch
glibc-stime.patch
gcc-10-sid-redefinition.patch
+work-around-uapi-break-in-linux-input-ev.patch
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch 1970-01-01 01:00:00.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch 2024-05-23 16:49:59.0 +0100
@@ -0,0 +1,25 @@
+From: Colin Watson
+Date: Thu, 23 May 2024 16:38:37 +0100
+X-Dgit-Generated: 1.1.1+rev1500-1.5 5d2fca4cdce8ddcdf7e13a0681da7b381301
+Subject: Work around UAPI break in Linux input events
+
+See
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=152194fe9c3f.
+
+Closes: #1066822
+
+---
+
+diff --git a/test/evtest.c b/test/evtest.c
+index a61593e..73fb5af 100644
+--- a/test/evtest.c
b/test/evtest.c
+@@ -241,7 +241,7 @@ int main (int argc, char **argv)
+
+ for (i = 0; i < rd / (int) sizeof(struct input_event); i++)
+ printf("Event: time %ld.%06ld, type %d (%s), code %d (%s), value %d\n",
+-ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,
++ev[i].input_event_sec, ev[i].input_event_usec, ev[i].type,
+ events[ev[i].type] ? events[ev[i].type] : "?",
+ ev[i].code,
+ names[ev[i].type] ? (names[ev[i].type][ev[i].code] ? names[ev[i].type][ev[i].code] : "?") : "?",
Bug#961964: bidentd: diff for NMU version 1.1.4-1.3
Control: tags 961964 + patch
Control: tags 961964 + pending
Dear maintainer,
I've prepared an NMU for bidentd (versioned as 1.1.4-1.3) and uploaded
it to DELAYED/5. Please feel free to tell me if I should delay it
longer.
Regards,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru bidentd-1.1.4/debian/changelog bidentd-1.1.4/debian/changelog
--- bidentd-1.1.4/debian/changelog 2020-03-11 13:12:52.0 +
+++ bidentd-1.1.4/debian/changelog 2024-05-23 16:23:26.0 +0100
@@ -1,3 +1,10 @@
+bidentd (1.1.4-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Set Architecture to linux-any (closes: #961964).
+
+ -- Colin Watson Thu, 23 May 2024 16:23:26 +0100
+
bidentd (1.1.4-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru bidentd-1.1.4/debian/control bidentd-1.1.4/debian/control
--- bidentd-1.1.4/debian/control 2020-03-11 13:12:52.0 +
+++ bidentd-1.1.4/debian/control 2024-05-23 16:23:26.0 +0100
@@ -6,7 +6,7 @@
Standards-Version: 3.8.4
Package: bidentd
-Architecture: any
+Architecture: linux-any
Depends: ${shlibs:Depends}, ${misc:Depends}, netbase, debconf, openbsd-inetd | inet-superserver
Provides: ident-server
Conflicts: ident-server
Bug#1071673: Packages-arch-specific: Remove libgcr410?
Package: buildd.debian.org Severity: normal Tags: patch I was looking at Packages-arch-specific and trying to work out if anything else could be removed from it. I wondered about this line: %libgcr410: i386 amd64# [ANAIS] The architecture is in fact included in the source nowadays - it's just "Architecture: any". I tried building it on armhf and it built fine, albeit with a few warnings, and from a quick grep I don't see anything obviously architecture-specific. Since the CVS history wasn't carried over to git and cvs.debian.org no longer exists, I can't tell exactly when this was added. But at this point it looks like it's an accidental leftover and it would make more sense to just let the package at least try to build elsewhere. diff --git a/Packages-arch-specific b/Packages-arch-specific index aa69ebe..d7a26d9 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -21,7 +21,6 @@ # PACKAGE: [SOURCE PACKAGE] [REASON] fdflush: alpha amd64 i386 # amd64/i386/alpha specific -%libgcr410: i386 amd64 # [ANAIS] %linux-wlan-ng: amd64 i386 powerpc armel armhf alpha hppa# ANAIS [?] # xorg stuff Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071657: libdebbugs-perl: Undeclared dependency on unpackaged Search::Estraier
Package: libdebbugs-perl Version: 2.6.0 Severity: important While investigating failing autopkgtests in debbugs, I noticed that Debbugs::Estraier needs Search::Estraier. This used to be in Debian, but was removed (https://tracker.debian.org/pkg/libsearch-estraier-perl), and the dependency doesn't seem to be declared. I'm not sure what to do about this. Is there some other packaged substitute we could use instead? Or would we have to fix up libsearch-estraier-perl and get it back into Debian? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071574: bookworm-pu: package netcfg/1.187+deb12u1
On Tue, May 21, 2024 at 03:20:52PM +0200, Cyril Brulebois wrote: > Colin Watson (2024-05-21): > > I've just fixed this in unstable, but it would be helpful to have it > > in place for installs of bookworm too. > > ACK on principle; you'll want a dch -r though. Indeed, I usually just leave that until after approval in case any last-minute changes are needed. Uploaded now, thanks. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071574: bookworm-pu: package netcfg/1.187+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-b...@lists.debian.org
Control: affects -1 + src:netcfg
[ Reason ]
Certain kinds of network architectures in Debian deployments (e.g.
https://phabricator.wikimedia.org/phame/post/view/312/ganeti_on_modern_network_design/,
https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/) are
difficult because the installer doesn't support single-address netmasks
out of the box (https://bugs.debian.org/1064005). You can sort of
handle this with point-to-point preseeding, but that isn't quite
identical and it doesn't work for IPv6.
I've just fixed this in unstable, but it would be helpful to have it in
place for installs of bookworm too.
[ Impact ]
It's possible to work around this without changing netcfg, but it
requires messy and fragile early_command preseeding to defeat netcfg's
behaviour (see #1064005).
[ Tests ]
The change includes automated tests for the changes to the gateway
reachability test. For the changes to the routing table setup and to
confirm that no changes were needed to network configuration in the
installed system, I used libvirt machines with a DHCP server along the
lines of https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/;
Wikimedia has also tested this using their own setup and confirmed that
it now works out of the box.
[ Risks ]
I've taken care that all the new code is guarded by interface->masklen
checks, so it should be obvious that it's a no-op on any system that
isn't using this unusual single-address netmask setup.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
It turns out that fixing this is very straightforward: it's just a
matter of special-casing the gateway reachability test and then telling
the routing table to pretend that the gateway is directly attached to
the relevant link. The installed system (ifupdown, NetworkManager)
already gets this right; it's just the installer that had trouble with
it.
[ Other info ]
This work was requested and sponsored by the Wikimedia Foundation.
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru netcfg-1.187/debian/changelog netcfg-1.187+deb12u1/debian/changelog
--- netcfg-1.187/debian/changelog 2023-05-23 19:24:01.0 +0100
+++ netcfg-1.187+deb12u1/debian/changelog 2024-05-14 11:27:14.0
+0100
@@ -1,3 +1,9 @@
+netcfg (1.187+deb12u1) UNRELEASED; urgency=medium
+
+ * Handle routing for single-address netmasks (closes: #1064005).
+
+ -- Colin Watson Tue, 14 May 2024 11:27:14 +0100
+
netcfg (1.187) unstable; urgency=medium
* Team upload
diff -Nru netcfg-1.187/netcfg-common.c netcfg-1.187+deb12u1/netcfg-common.c
--- netcfg-1.187/netcfg-common.c2022-06-03 19:25:43.0 +0100
+++ netcfg-1.187+deb12u1/netcfg-common.c2024-05-14 11:26:51.0
+0100
@@ -1680,8 +1680,22 @@
inet_pton(interface->address_family, interface->gateway, _addr);
if (interface->address_family == AF_INET) {
+if (interface->masklen == 32) {
+/* Special case for single-address networks. We'll handle
+ * routing manually in this case.
+ */
+return 1;
+}
+
return (gw_addr.in4.s_addr && ((gw_addr.in4.s_addr & mask.in4.s_addr)
== net.in4.s_addr));
} else if (interface->address_family == AF_INET6) {
+if (interface->masklen == 128) {
+/* Special case for single-address networks. We'll handle
+ * routing manually in this case.
+ */
+return 1;
+}
+
if ((ntohs(gw_addr.in6.s6_addr16[0]) & 0xffc0) == (0xfe80 & 0xffc0)) {
return 1;
}
diff -Nru netcfg-1.187/static.c netcfg-1.187+deb12u1/static.c
--- netcfg-1.187/static.c 2021-09-22 19:07:01.0 +0100
+++ netcfg-1.187+deb12u1/static.c 2024-05-14 11:27:14.0 +0100
@@ -338,6 +338,12 @@
di_snprintfcat(buf, sizeof(buf), "%s", interface->ipaddress);
rv |= di_exec_shell_log(buf);
} else if (!empty_str(interface->gateway)) {
+if (interface->masklen == 32) {
+snprintf(buf, sizeof(buf), "route add -interface %s %s",
interface->gateway, interface->ipaddress);
+di_info("executing: %s", buf);
+rv |= di_exec_shell_log(buf);
+}
+
snprintf(buf, sizeof(buf), "route add default %s", interface->gateway);
rv |= di_exec_shell_log(buf);
}
@@ -373,6 +379,8 @@
}
else if (!empty_str(interface->gateway)) {
snprintf(buf, sizeof(buf), "ip route add default via %s",
interface->gateway);
+
Bug#1025450: python-gssapi: enable testing when packaging python-gssapi
On Sun, Dec 04, 2022 at 10:15:38PM +, Taihsiang Ho (tai271828) wrote: > The current debian package building process does not launch any testing > when building python-gssapi. It will be great if the building process > launches the corresponding upstream tests. > > FWIW: the upstream stopped using nosetests > https://github.com/pythongssapi/python-gssapi/commit/5552513a47a636a4d956f76b498c6fa2e368cc98 > and we have removed nose as debian package dependency (see BTS > bug:#1018505) . However, the package building process still does not > launch the corresponding upstream testing. I believe this is currently blocked on (at least) k5test not being packaged in Debian. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1070733: linux-image-5.10.0-29-amd64 fails to boot with Error 16: Inconsistent filesystem structure
On Wed, May 08, 2024 at 06:31:53AM +0100, Dan Poltawski wrote: > After upgrading to linux-image-5.10.0-29 the system fails to boot with > grub 'Error 16: Inconsistent filesystem structure'. Booting into > linux-image-5.10.0-28-amd64 > and the system is once again bootable > > The console displays: > Booting 'Debian GNU/Linux, kernel 5.10.0-29-amd64' > root (hd0,0) > Filesystem type is ext2fs, partition type 0x83 > kernel /boot/vmlinuz-5.10.0-29-amd64 root=UUID=ca38e015-f8d1-4ef0-9dc9-b56d7c8 > le0f1 ro > [Linux-bzImage, setup=0x3c00, size=0x6b5f40] > Initrd /boot/initrd. img-5.10.0-29-amd64 > Error 16: Inconsistent filesystem structure > Press any key to continue...- If I find time I'll have a look at this (probably just by looking through GRUB 2 for candidate backports and hoping that one of them helps). However, I should warn you that GRUB Legacy is extremely very unmaintained at this point; I've really just been doing last-resort patching for years, and this normally hasn't included debugging its filesystem code. It'd be in your interests to migrate to GRUB 2. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1070098: openssh-sftp-server: False dependency on openssh-client
On Mon, Apr 29, 2024 at 10:19:14PM -0500, Wolf wrote: > Only the openssh-sftp-server package to be installed, as it has no ties to the > openssh-client files and is in fact only used by the server side components. It's not precisely a false dependency: $ ls -l /usr/share/doc/openssh-sftp-server lrwxrwxrwx 1 root root 14 Feb 26 12:26 /usr/share/doc/openssh-sftp-server -> openssh-client This saves a bit of space if all the packages are installed together, which is the common case. However, it's true that it's not very much space (200K or so), so maybe it's not worth the resulting confusion ... > Related but dropbear-bin also has a suggestion to install openssh-client, > however dropbear-bin includes all relevant key-generation tools natively, > so perhaps this 'Suggestion' should point to openssh-sftp-server instead? You'll have to report that as a separate bug - I don't maintain the dropbear packages. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069756: readability: build time test error: lxml.html.clean module is now a separate project lxml_html_clean
On Wed, Apr 24, 2024 at 11:16:17AM +0200, Étienne Mollier wrote: > As far as I could witness, replacing the python3-lxml build > dependency by python3-lxml-html-clean resolved the issue at > least for the bulid time test. The package is subject to > autodep8 python3 test, which raises that the binary package will > also need it dependencies adjusted; this suggests the setup.py > would probably need patching so this is addressed appropriately > at a larger scale than Debian's. Based on https://github.com/buriy/python-readability/issues/179, it looks as though upstream intends to switch to bleach; I think we can just patch setup.py in Debian in the meantime though. I'll do that. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1066788: gyoto: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 check-lorene returned exit code 2
Control: tag -1 patch On Wed, Mar 13, 2024 at 03:56:54PM +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[3]: Entering directory '/<>/yorick' > > Makefile:136: warning: overriding recipe for target 'check-dll' > > ../yorick/Makepkg:158: warning: ignoring old recipe for target 'check-dll' > > make[3]: 'check-lorene' is up to date. > > make[3]: Leaving directory '/<>/yorick' > > make[2]: Leaving directory '/<>' > > dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" > > VERBOSE=1 check-lorene returned exit code 2 A more relevant part was: ImportError: /<>/python/gyoto/_std.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN5Gyoto7AstrobjlsERSoRKNS0_14PolishDoughnutE I sent a patch for this upstream as https://github.com/gyoto/Gyoto/pull/17. Here's a patch to fix the Debian package in the meantime. -- Colin Watson (he/him) [cjwat...@debian.org] >From 19e6f4bcdc33cbd7995027bf56ec3b5a7125ea5f Mon Sep 17 00:00:00 2001 From: Colin Watson Date: Wed, 24 Apr 2024 15:25:19 +0100 Subject: [PATCH] Remove undefined operator<< declaration for PolishDoughnut Closes: #1066788 --- debian/changelog | 7 ++ .../patches/remove-polish-doughnut-operator | 25 +++ debian/patches/series | 1 + 3 files changed, 33 insertions(+) create mode 100644 debian/patches/remove-polish-doughnut-operator diff --git a/debian/changelog b/debian/changelog index 8f74908..0188483 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +gyoto (2.0.2-1.2) UNRELEASED; urgency=medium + + * Remove undefined operator<< declaration for PolishDoughnut (closes: +#1066788). + + -- Colin Watson Wed, 24 Apr 2024 14:32:29 +0100 + gyoto (2.0.2-1.1) unstable; urgency=medium * Non-maintainer upload. diff --git a/debian/patches/remove-polish-doughnut-operator b/debian/patches/remove-polish-doughnut-operator new file mode 100644 index 000..ead15f5 --- /dev/null +++ b/debian/patches/remove-polish-doughnut-operator @@ -0,0 +1,25 @@ +Description: Remove undefined operator<< declaration for PolishDoughnut + On current Debian systems this resulted in `undefined symbol: + _ZN5Gyoto7AstrobjlsERSoRKNS0_14PolishDoughnutE` while running tests. +Bug-Debian: https://bugs.debian.org/1066788 +Forwarded: https://github.com/gyoto/Gyoto/pull/17 +Last-Update: 2024-04-24 + +Index: b/include/GyotoPolishDoughnut.h +=== +--- a/include/GyotoPolishDoughnut.h b/include/GyotoPolishDoughnut.h +@@ -262,13 +262,6 @@ + // Outputs + // --- + public: +- +- /// Display +- friend std::ostream& operator<<(std::ostream& , const PolishDoughnut& ) ; +- +- public: +- +- + }; + + #endif diff --git a/debian/patches/series b/debian/patches/series index b9e8f3b..b8e9081 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,3 +1,4 @@ interpreter-path +remove-polish-doughnut-operator # This patch is conditionally applied by debian/rules: # no-fp-ilogb0 -- 2.43.0
Bug#1058888: pyferret FTBSF on several architectures: dh_install: error: missing files, aborting
Control: retitle -1 pyferret FTBFS on several architectures: dh_install: error: missing files, aborting Control: tag -1 patch On Sun, Dec 17, 2023 at 08:24:07PM +0200, Adrian Bunk wrote: > https://buildd.debian.org/status/logs.php?pkg=pyferret=7.6.5-5 > > ... >dh_install -a > dh_install: warning: Cannot find (any matches for) > "debian/tmp/ext_func/pylibs" (tried in ., debian/tmp) > > dh_install: warning: python3-ferret missing files: debian/tmp/ext_func/pylibs > install -m0755 -d debian/python3-ferret//usr/bin > cp --reflink=auto -a ./debian/pyferret3 debian/python3-ferret//usr/bin/ > install -m0755 -d debian/python3-ferret//usr/lib/python3/dist-packages > cp --reflink=auto -a > ./debian/tmp/lib/python3.11/libpyferret.cpython-311-powerpc64le-linux-gnu.so > ./debian/tmp/lib/python3.12/libpyferret.cpython-312-powerpc64le-linux-gnu.so > ./install/local/lib/python3.11/dist-packages/__pycache__ > ./install/local/lib/python3.11/dist-packages/gcircle-7.65-py3.11.egg-info > ./install/local/lib/python3.11/dist-packages/gcircle.py > ./install/local/lib/python3.11/dist-packages/pipedviewer > ./install/local/lib/python3.11/dist-packages/pipedviewer-7.65-py3.11.egg-info > ./install/local/lib/python3.11/dist-packages/pyferret > ./install/local/lib/python3.11/dist-packages/pyferret-7.65-py3.11.egg-info > debian/python3-ferret//usr/lib/python3/dist-packages/ > install -m0755 -d > debian/python3-ferret//usr/share/bash-completion/completions/ > cp --reflink=auto -a ./debian/bash_completion.d/pyferret3 > debian/python3-ferret//usr/share/bash-completion/completions// > dh_install: error: missing files, aborting > make: *** [debian/rules:8: binary-arch] Error 25 I've proposed https://salsa.debian.org/science-team/pyferret/-/merge_requests/3 to fix this. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1057562: closed by Debian FTP Masters (reply to Jeremy Bícha ) (Bug#1057562: fixed in gcr4 4.2.0-2)
0x7f4fef2a4981 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f4fef2d1ab1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f4fef08f45c in start_thread (arg=) at ./nptl/pthread_create.c:444 #6 0x7f4fef10fbbc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 2 (Thread 0x7f4fee97c6c0 (LWP 31753)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x7f4fef2ffac4 in g_cond_wait () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f4fef26e16b in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f4fef2d213a in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f4fef2d1ab1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f4fef08f45c in start_thread (arg=) at ./nptl/pthread_create.c:444 #6 0x7f4fef10fbbc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 --Type for more, q to quit, c to continue without paging-- Thread 1 (Thread 0x7f4fed97a6c0 (LWP 31755)): #0 0x7f4fef3a5633 in find_attribute (attr_type=3, n_attrs=12008468691120727718, attrs=0x55bef952d90a) at ../gck/gck-attributes.c:336 #1 gck_attributes_find (attrs=attrs@entry=0x55bba2e8a980, attr_type=3) at ../gck/gck-attributes.c:2077 #2 0x7f4fee9b616c in enumerate_and_find_objects (object=2, attrs=0x55bba2e8a980, user_data=0x7f4fed979ac0) at ../gck/gck-mock.c:1081 #3 0x7f4fee9b8237 in gck_mock_module_enumerate_objects (handle=handle@entry=113, func=func@entry=0x7f4fee9b6110 , user_data=user_data@entry=0x7f4fed979ac0) at ../gck/gck-mock.c:203 #4 0x7f4fee9b8380 in gck_mock_C_FindObjectsInit (hSession=113, pTemplate=0x7f4fe4001770, ulCount=1) at ../gck/gck-mock.c:1114 #5 0x7f4fef3b13e9 in perform_find_objects (args=0x55bba2e95980) at ../gck/gck-session.c:1527 #6 0x7f4fef3b91d6 in perform_call (args=, cancellable=, cancellable@entry=0x55bba2e95980, func=) at ../gck/gck-call.c:67 #7 perform_call_chain (perform=0x7f4fef3b1370 , complete=0x0, cancellable=cancellable@entry=0x0, args=0x55bba2e95980) at ../gck/gck-call.c:97 #8 0x7f4fef3b936b in _gck_call_thread_func (task=0x55bba2e959b0, source_object=, task_data=0x55bba2e93250, cancellable=0x0) at ../gck/gck-call.c:132 #9 0x7f4feeed0ca7 in () at /lib/x86_64-linux-gnu/libgio-2.0.so.0 #10 0x7f4fef2d2462 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x7f4fef2d1ab1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #12 0x7f4fef08f45c in start_thread (arg=) at ./nptl/pthread_create.c:444 #13 0x7f4fef10fbbc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 But the failures present unreliably in different ways (SIGSEGV, SIGTRAP, etc.); this is just one of them. My suspicion is that this is a thread-safety issue of some kind, perhaps something like accesses to a hash table not being locked properly, but that's just a guess. I'm not even sure whether it's in gcr4 or in some other layer of the stack. I'd be happy to try some other things if anyone has pointers for where might be good places to look, or things I might be able to tweak to make the bug more reliably reproducible (e.g. places to insert artificial delays). I remain entirely unable to reproduce this bug in any form on my laptop. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target
On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote: > According to systemd.special(7) > > nss-user-lookup.target > > A target that should be used as synchronization point for all > regular UNIX user/group name service lookups. [...] All > services for which the availability of the full user/group > database is essential should be ordered after this target, but > not pull it in. All services which provide parts of the > user/group database should be ordered before this target, and > pull it in. > > I have a custom .service that does exactly as described in the second > part, i.e. provides part of the user/group database and says > Before=nss-user-lookup.target, Wants=nss-user-lookup.target > (concretely, it modifies /etc/shadow to update a default password, but > that's not really important). I believe sshd definitely belongs in the > former category, i.e. sshd should not be started until any such > service that updates the user/group database, such as updating > /etc/shadow, have run. > > Hence the ssh.service and ssh.socket files should add > > After=nss-user-lookup.target > > in their [Unit] sections. This is a no-op on systems that do not have > any service pulling in that target, but required for correctness on > systems that do. > > Of course, I could, and currently do, handle this via a drop-in config > fragment in some ssh.service.d/ directory. But this, and other similar > synchronization targets, exist so that one does not necessarily need > to know about every other service running on the system. This sounds like a reasonable proposal to me. I'm just CCing Debian's systemd maintainers for a quick review to make sure I'm not missing anything subtle. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069227: man-db: Please do not change MANWIDTH behavior just in Debian
On Thu, Apr 18, 2024 at 12:56:06PM +0200, Jérémy Lal wrote: > Le jeu. 18 avr. 2024 à 12:29, Colin Watson a écrit : > Ok, and sorry, I got frustrated by the "1 column space on the right" change > of > https://gitlab.com/man-db/man-db/-/merge_requests/11 [...] > Indeed, the upstream version changes how width is configured. > - man: match the display width to the configured width (closes:#1059537). > > It's just making another package (node-marked-man) render man pages > differently, and fail its tests, preventing some other package > migration (nodejs) and it would have been nice not having that change > during this t64 transition. Well, I'm sorry for the inconvenience, but I think this change was reasonable on its own merits and I don't plan to revert it. The exact details of margins and such are very much an implementation detail that other packages should in no way be relying upon. Perhaps node-marked-man should do a whitespace-insensitive comparison of some kind? Whitespace details in the output don't seem terribly relevant to what it's trying to do. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069227: man-db: Please do not change MANWIDTH behavior just in Debian
On Thu, Apr 18, 2024 at 10:19:51AM +0200, Jérémy Lal wrote: > It seems that man-db debian maintainer decided on its own to make > some arbitrary change to how MANWIDTH is handled. > > This is probably going to break things, for no good reason besides a personal > preference. Huh? 1) The man-db Debian maintainer is the same person as the upstream maintainer, i.e. me. 2) The Debian packaging does not contain any changes to how MANWIDTH is handled. What are you talking about? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages
On Mon, Apr 08, 2024 at 09:19:09AM +0200, Iker Pedrosa wrote: > On Sat, Apr 6, 2024 at 11:48 PM Chris Hofstaedtler wrote: > > util-linux upstream provides three binary objects to be built: > > - liblastlog2.so > > - pam_lastlog2.so > > - lastlog2 (program) > > > > Debian's PAM policy says to put PAM modules into their own package, > > thus libpam-lastlog2. liblastlog2.so would go into the > > > liblastlog2(-0) package. The lastlog2 program either into its own > > lastlog2 package, or elsewhere. > > > > Please, let's call this pam_lastlog2 and not libpam-lastlog2. AFAIK, all > pam modules start with the prefix pam_*. The file names do, but the package names almost always start with "libpam-". (Also, Debian package names may not contain "_".) $ apt-file search security/pam_ | grep -v libpam-modules | grep --count ^libpam- 68 $ apt-file search security/pam_ | grep -v libpam-modules | grep --count ^pam- 1 And the Debian PAM mini-policy says: 1) Packages should use the naming scheme of `libpam-' (eg. libpam-ldap). -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1068487: man-db: Failed to get unit file state for man-db.service: Transport endpoint is not connected
Control: reassign -1 systemd On Sat, Apr 06, 2024 at 11:18:55AM +0800, Bo YU wrote: > Today upgraded my riscv64 sid , I got: > > ``` > Setting up man-db (2.12.1-1) ... > Updating database of manual pages ... > Reload daemon failed: Transport endpoint is not connected > > Failed to get unit file state for man-db.service: Transport endpoint is not > connected > Failed to retrieve unit state: Transport endpoint is not connected > man-db.service is a disabled or a static unit not running, not starting it. > Failed to get unit file state for man-db.timer: Transport endpoint is not > connected > Failed to retrieve unit state: Transport endpoint is not connected > man-db.timer is a disabled or a static unit not running, not starting it. > ... > Setting up openssh-sftp-server (1:9.7p1-4) ... > Setting up openssh-server (1:9.7p1-4) ... > Reload daemon failed: Transport endpoint is not connected > Failed to get properties: Transport endpoint is not connected > Reload daemon failed: Transport endpoint is not connected > Failed to get unit file state for ssh.service: Transport endpoint is not > connected > Failed to retrieve unit state: Transport endpoint is not connected > ssh.service is a disabled or a static unit not running, not starting it. > ^B^[[5~Reload daemon failed: Transport endpoint is not connected > Failed to get unit file state for ssh.socket: Transport endpoint is not > connected > Failed to retrieve unit state: Transport endpoint is not connected > ... > ``` > > And this process is very time-consuming also. Hi, This is all fairly clearly a systemd issue rather than anything specifically to do with man-db, so reassigning there. I'm afraid I don't have any further clues though. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1068311: tcp-wrappers: Can anything be done to avoid the libnsl dependency?
On Wed, Apr 03, 2024 at 02:55:08PM +0200, Marco d'Itri wrote: > On Apr 03, Colin Watson wrote: > > I wondered if anything could be done to avoid this or refactor it > > somehow? > Sure: I think that it makes sense to just disable NETGROUP (which is > the conditional for yp_get_default_domain), because I do not think that > anybody in 2024 still uses NIS and if they do then we are only doing > them a favour by disabling netgroups support here. You would know better than I do how common that is, but I can't say I have any particular objection. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1068311: tcp-wrappers: Can anything be done to avoid the libnsl dependency?
Source: tcp-wrappers
Version: 7.6.q-32
Severity: wishlist
The main reason why libwrap is an issue in
https://lists.debian.org/debian-ssh/2024/04/msg4.html is that it
links to libnsl, which links to libtirpc, which links to libgssapi_krb5.
That ends up being quite a heavyweight dependency chain. As far as I
can see, libwrap uses libnsl in exactly one place: host_match calls
yp_get_default_domain.
I wondered if anything could be done to avoid this or refactor it
somehow? If that dependency chain weren't there, I would find it much
easier to justify retaining libwrap support in Debian's openssh
packaging once its direct dependency on libgssapi_krb5 is gone as
planned in the above email.
The obvious approach seems to be to dlopen libnsl only when it's needed.
As far as I can see, libwrap only needs it when you use the user@host
syntax in hosts.{allow,deny}, and people only do that on systems that
actually use NIS; such people would very likely have libnsl2 installed
for other reasons anyway (e.g. libnss-nis). Everyone else could lose
the dependency. It would be a slight increase in the complexity of
libwrap, I realize, but since NIS is only used on a minority of systems
these days, it would do a lot to reduce the number of libraries in the
process spaces of quite a few daemons on typical systems.
If such an approach sounds reasonable to you, I don't mind working on a
patch.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1068017: util-linux: please ship liblastlog2 packages
On Sat, Mar 30, 2024 at 01:41:40AM +0100, Chris Hofstaedtler wrote: > On Sat, Mar 30, 2024 at 01:32:08AM +0100, Chris Hofstaedtler wrote: > > On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote: > > > It seems desirable to ship liblastlog2 in trixie, considering that the > > > /var/log/lastlog file is not Y2038-safe and pam in unstable has already > > > dropped pam_lastlog.so, meaning that non-ssh logins are no longer > > > recorded in /var/log/lastlog. > > > [..] > > At the same time, all traditional writing to /var/log/lastlog should > > stop. > > > > So, after some of the current fog clears, src:util-linux could > > introduce new binary packages (at least libpam-lastlog2), but > > src:pam would need to add it to the common-* config files. > > > > Does this seem right? > > Answering my own question, not quite. > > Apparently, traditionally we have: > > * sshd writes to /var/log/lastlog by itself. > * login has pam_lastlog.so in its PAM snippet. > > Both of these would need to be replaced by pam_lastlog2.so. I don't > really know what the other distros are doing right now, and/or if > we should align on this. > > So we could either put pam_lastlog2.so into a common-* file from > src:pam, or openssh and shadow should switch their setup. I think I'm OK with configuring openssh with --disable-lastlog, although I haven't tested it. I think we should at least roughly coordinate this so that there isn't a long period when testing users have no last login information at all, though, so let me know when you'd like me to do that. It might be a good idea to wait until the main bulk of the 64-bit time_t transition is over so that we have a little more reasonable expectation of changes migrating to testing somewhat promptly. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1066060: libpam-modules: pam_lastlog.so missing
On Tue, Apr 02, 2024 at 10:58:01AM +0200, Chris Hofstaedtler wrote: > I'll note that #1068017 has discussion about enabling > pam_lastlog2.so, where we'd also appreciate your input regarding > sshd, Colin. Yep, replied there. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1068162: Please consider adding MP-TCP support
Control: tags -1 wontfix On Mon, Apr 01, 2024 at 01:21:27AM +0200, Juliusz Chroboczek wrote: > Please consider applying the following patch: > > https://github.com/openssh/openssh-portable/pull/335 > > MP-TCP support allows moving from one IP address to another without > breaking connections, and does so in a way that remains compatible with > existing clients and servers. It solves the main issue that causes people > to prefer mosh to ssh. While I realize that this doesn't introduce a new external dependency, I have to say that this is not the week to be asking for a new distro patch to OpenSSH! I'd be happy to include this if upstream does, but I don't think I'm likely to apply this in advance of upstream. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1066060: libpam-modules: pam_lastlog.so missing
On Mon, Mar 11, 2024 at 10:12:29PM +0100, Mourad De Clerck wrote: > I noticed the following line in my logs: > > login[2449]: PAM unable to dlopen(pam_lastlog.so): > /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such > file or directory > > I looked in the deb files from snapshot.debian.org, and noticed the last > version > that had it was 1.5.2-9.1 - starting from 1.5.3-1 it disappeared. > > Maybe it's fallout from the time_t transition and you're already aware of it, > in > which case feel free to close. I don't know what the Debian pam maintainers intend to do about it, but this is surely the result of: https://github.com/linux-pam/linux-pam/commit/357a4ddbe9b4b10ebd805d2af3e32f3ead5b8816 A note in NEWS.Debian might be worthwhile. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067891: nmu: memcached_1.6.23-1
Control: reopen -1 On Thu, Mar 28, 2024 at 04:12:19PM +0100, Sebastian Ramacher wrote: > On 2024-03-28 13:46:14 +0000, Colin Watson wrote: > > Package: release.debian.org > > Severity: normal > > X-Debbugs-Cc: memcac...@packages.debian.org > > Control: affects -1 + src:memcached > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > nmu memcached_1.6.23-1 . armel armhf . unstable . -m "Rebuild for time_t" > > Scheduled Argh, I got the version wrong, sorry. My fault for trusting reportbug while running testing ... nmu memcached_1.6.24-1 . armel armhf . unstable . -m "Rebuild for time_t" Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067891: nmu: memcached_1.6.23-1
Package: release.debian.org Severity: normal X-Debbugs-Cc: memcac...@packages.debian.org Control: affects -1 + src:memcached User: release.debian@packages.debian.org Usertags: binnmu nmu memcached_1.6.23-1 . armel armhf . unstable . -m "Rebuild for time_t" -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
On Sat, Mar 23, 2024 at 01:49:19AM +, Thorsten Glaser wrote: > Colin Watson dixit: > >Could you try the somewhat further reduced patch in > > The package made from that branch built fine in my cowbuilder, > and I have all reason to assume it’ll do so in sbuild/buildd. Thanks for the testing! -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
On Thu, Mar 21, 2024 at 10:35:17PM +, Thorsten Glaser wrote: > Colin Watson dixit: > >Could you try the somewhat further reduced patch in > > I’ve started a build and will let you know probably when I get > back late tomorrow. Thanks! No rush - I won't be at a proper computer until Sunday or so anyway. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
On Wed, Mar 20, 2024 at 07:14:42PM +, Thorsten Glaser wrote:
> I can confirm that appending…
>
> int snprintf_eta;
> double snprintf_time_per_line;
> int snprintf(char *str, size_t size, const char *format, ...) {
> snprintf_eta = snprintf_time_per_line;
> }
>
> … (lightly changed from the above) to the program from
> m4/openssh.m4 OSSH_COMPILER_FLAG_TEST_PROGRAM fails with:
>
> (pbuild-15711)root@ara2:/tmp# gcc -O2 -fPIE -fno-strict-aliasing
> -fzero-call-used-regs=used t.c
> during RTL pass: zero_call_used_regs
> t.c: In function 'snprintf':
> t.c:51:1: internal compiler error: in change_address_1, at emit-rtl.cc:2287
>51 | }
> | ^
> […]
I don't love overriding snprintf here, since it seems possible that that
could disturb the check on other architectures. Could you try the
somewhat further reduced patch in
https://salsa.debian.org/ssh-team/openssh/-/tree/zero-call-used-regs-m68k,
please? I wanted to use the mitchy.debian.net porterbox but I got
ECONNREFUSED.
> Alternatively, just hardcode disabling this flag on m68k for now,
> which we’ll eventually have to revert once GCC is on a fixed release
> (14 probably).
This configure check doesn't use the usual autoconf result caching
arrangements, which makes it a bit more awkward to override from
debian/rules. There are options, but an extended configure check that I
could send upstream would probably be best.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#848194: Want way to get Release (or InRelease) file from cache
Hi, I don't know if it helps or hinders this bug since I have rather different reasons from Ian, but I found myself looking at this bug today because I also wanted a way to get hold of an [In]Release file. The difference is that I'm not trying to get hold of it for a particular package, but for (roughly) a sources.list entry; but all my other requirements seem basically the same as Ian's. My use case is as follows, and you can tell me if it's too different to include in the same report: * In order to be able to implement an "import the contents of this repository into our database" task in debusine (https://freexian-team.pages.debian.net/debusine/), I want to discover which architectures are supported by a given suite in a repository, assuming that it has at least a Release file. And of course then I want to be able to fetch all the files, but at least that part isn't so hard. * If you already know which architectures you want, then this is easy. But if you want to ask the repository which architectures it supports, as far as I know the only sensible way is to consult the Release file. * Acquiring and verifying Release files correctly is, as I'm sure you know, challenging. I would like to avoid writing my own code to call gpgv in just the right way (again). I've been here before with #918304. * I'd hoped to use python-debian, but its GPG verification support is currently not as good as it should be (#710923) and in any case what you get from its Release file handling is not very helpful (#1067160). * So I looked at apt/python-apt. I know how to instantiate a temporary apt cache with its own configuration (in the manner of chdist(1), for instance), and if I could discover the available architectures after an initial fetch then I could call "apt-get update" a second time with APT::Architectures set and then I'd have everything. However, given a cache, I seem to be able to access basically everything _except_ for the Release file in documented ways. As mentioned in this bug, "apt-get indextargets" omits the Release file. For now, I'll probably dodge the problem by requiring the user to specify which architectures they want, and then I don't need the Release file. But I feel like I'm missing something. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067160: python3-debian: Difficult to iterate over next-level index files from Release
Package: python3-debian Version: 0.1.49 Severity: wishlist I've trying to figure out how to build a specialized repository mirroring tool as part of debusine (https://freexian-team.pages.debian.net/debusine/), and I started by looking at python-debian. First I ran into https://bugs.debian.org/710923, which would be an issue - past experience with https://bugs.debian.org/918304 suggests that that's much harder to get right than it seems. But, assuming that that could be solved somehow, I then started thinking about what would be needed next. After verifying the Release file, a mirroring tool needs to fetch the next level of index files (typically Packages and Sources). python-debian offers very little help with this - you get a parsed version of the various checksums fields, but that's about it - and there are some non-trivial complications here. For instance, https://deb.debian.org/debian/dists/unstable/InRelease lists checksums for main/binary-amd64/Packages, but those are the checksums you get after fetching a compressed version of the file and uncompressing it; the uncompressed version isn't actually on the mirror, and you have to fetch https://deb.debian.org/debian/dists/unstable/main/binary-amd64/Packages.xz or similar instead. While I have a rough idea of how to implement this and could borrow code from apt, I don't really want to have to write more versions of this than necessary. Ideally (for me), Release would have some way to list the next-level index files, and provide a way to fetch checksum-verified versions of them given a base URL, parsed into Packages/Sources instances as appropriate, and abstracting over all the details of compression algorithms and such. I think I may end up using apt or python-apt for now, but python-apt is always a slightly awkward dependency in a Python codebase due to its tight coupling with apt, and python-debian is much more convenient in those terms. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067159: python-respx: Backport to bookworm
Source: python-respx Version: 0.20.2-2 Severity: wishlist Hi, I'd like to have the option of migrating debusine (https://freexian-team.pages.debian.net/debusine/) from requests to httpx, since I've heard good things about the latter. One blocker is that we currently rely on the responses library quite heavily in tests, and so we'd need a replacement; the thing to use seems to be respx. However, debusine needs to run on bookworm. Would you consider maintaining a backport in bookworm-backports? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067128: RM: python3-watchfiles [armel armhf] -- RoQA; skewed due to time_t rebootstrap; not in testing
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: python-watchfi...@packages.debian.org Control: affects -1 + src:python-watchfiles User: ftp.debian@packages.debian.org Usertags: remove I noticed that pelican isn't currently in testing, and it seems to just be blocked on python3-watchfiles. That's currently blocked because of out-of-date binaries on armel/armhf: python-watchfiles | 0.21.0-2 | unstable | source python-watchfiles | 0.21.0-2 | unstable-debug | source python-watchfiles | 0.21.0-3 | unstable | source python-watchfiles | 0.21.0-3 | unstable-debug | source python3-watchfiles| 0.21.0-2 | unstable | armel, armhf python3-watchfiles| 0.21.0-3 | unstable | amd64, arm64, i386, ppc64el, riscv64, s390x python3-watchfiles-dbgsym | 0.21.0-2 | unstable-debug | armel, armhf python3-watchfiles-dbgsym | 0.21.0-3 | unstable-debug | amd64, arm64, i386, ppc64el, riscv64, s390x Those are blocked on various cycles arising from the 64-bit time_t rebootstrap. However, since this package has never been in testing, I think it should be fine to remove just the armel/armhf binaries here and let the others proceed. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067092: man-db: “man -K --regex” fails to match whole words in some cases
On Mon, Mar 18, 2024 at 11:54:42AM +0100, Manny wrote:
> Searching the whole DB for a whole word requires using --regex and
> then using word boundaries. So to find pages that reference the TZ
> environment variable, this *should* work (in principle):
>
> $ man -aK --regex '\'
>
> It appears to work because it finds many pages. But it misses the
> “tree” package (/usr/share/man/man1/tree.1.gz).
>
> $ zgrep 'TZ' /usr/share/man/man1/tree.1.gz
> \fBTZ\fPTimezone for timefmt output, see \fBstrftime\fP(3).
>
> As you can see, the nroff language intereferes with matching the
> regular expression as “TZ” is surrounded by code. Users of man-db
> obviously do not intend to have their regex matched against nroff
> code. Thus operations are being performed in the wrong order. The
> regular expression matching needs to happen on nroff-decoded text.
In principle I certainly agree that this would be more usable, but I've
considered this in the past and given up as making it perform well would
have been very difficult. There's a note about this in man(1), under
the description of -K:
Note that this searches the sources of the manual pages, not the
rendered text, and so may include false positives due to things
like comments in source files, or false negatives due to things
like hyphens being written as "\-" in source files. Searching
the rendered text would be much slower.
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1066725: python-django-pgtrigger: Backport to bookworm
Source: python-django-pgtrigger Version: 4.11.0-1 Severity: wishlist Hi, I'm considering some possible uses of triggers in (https://freexian-team.pages.debian.net/debusine/), and django-pgtrigger looks like a good fit. However, debusine needs to run on bookworm, and so I'm looking into the possibility of a backport. I'm happy with either of these options: * I look after the backport, in which case this bug is a courtesy notification * you look after the backport Let me know what you'd prefer, and also whether you know of anything else I need to consider here. Thanks! -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1064697: flask-babelex: FTBFS: ImportError: cannot import name '_request_ctx_stack' from 'flask' (/usr/lib/python3/dist-packages/flask/__init__.py)
On Sun, Feb 25, 2024 at 08:37:09PM +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. [...] > > == > > ERROR: flask_babelex (unittest.loader._FailedTest.flask_babelex) > > -- > > ImportError: Failed to import test module: flask_babelex > > Traceback (most recent call last): > > File "/usr/lib/python3.12/unittest/loader.py", line 427, in > > _find_test_path > > package = self._get_module_from_name(name) > > > > File "/usr/lib/python3.12/unittest/loader.py", line 337, in > > _get_module_from_name > > __import__(name) > > File > > "/<>/.pybuild/cpython3_3.12_flask-babelex/build/flask_babelex/__init__.py", > > line 20, in > > from flask import _request_ctx_stack > > ImportError: cannot import name '_request_ctx_stack' from 'flask' > > (/usr/lib/python3/dist-packages/flask/__init__.py) https://github.com/mrjoes/flask-babelex is archived and shows a deprecation warning: "All Flask-BabelEx features were merged into Flask-Babel and Flask-BabelEx package should no longer be used in your projects. Please migrate." Apparently this was originally packaged as a dependency of pgadmin4, but pgadmin4 no longer uses it: https://github.com/pgadmin-org/pgadmin4/commit/d644b4f94ec71af78a46434121bce0fcd626a2dc Should we just remove this package from Debian? I'm CCing everyone who's uploaded it in the past just in case, but I suspect this is an easy decision. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1042679: quark-sphinx-theme: FTBFS with Sphinx 7.1, docutils 0.20: AssertionError: no elements
etUpClass
run_sphinx(cls.source_dir, cls.build_dir, cls.builder, cls.config,
File
"/<>/.pybuild/cpython3_3.11_quark-sphinx-theme/build/test/util.py",
line 65, in run_sphinx
raise Exception('%s returned non-zero exit status %s\n'
Exception: ['-b', 'qthelp', '-N',
'/<>/.pybuild/cpython3_3.11_quark-sphinx-theme/build/test/testdoc-html_rewrite',
'/tmp/tmp-sphinx-build-test-g9rskfhy'] returned non-zero exit status 2
--- Output:
Running Sphinx v7.2.6
Configuration error:
HTML 4 is no longer supported by Sphinx. ("html4_writer=True" detected in
configuration options)
==
ERROR: setUpClass (test.test_theme.TestThemeEntrypoint)
--
Traceback (most recent call last):
File
"/<>/.pybuild/cpython3_3.11_quark-sphinx-theme/build/test/util.py",
line 84, in setUpClass
run_sphinx(cls.source_dir, cls.build_dir, cls.builder, cls.config,
File
"/<>/.pybuild/cpython3_3.11_quark-sphinx-theme/build/test/util.py",
line 65, in run_sphinx
raise Exception('%s returned non-zero exit status %s\n'
Exception: ['-b', 'html', '-N',
'/<>/.pybuild/cpython3_3.11_quark-sphinx-theme/build/test/testdoc-theme-entrypoint',
'/tmp/tmp-sphinx-build-test-huhej5mg'] returned non-zero exit status 2
--- Output:
Running Sphinx v7.2.6
Theme error:
no theme named 'quark' found (missing theme.conf?)
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1061754: python-json-log-formatter ftbfs with Python 3.12 as default
On Tue, Mar 05, 2024 at 06:15:32PM +, Colin Watson wrote: > While it looks like this was fixed upstream in > https://github.com/marselester/json-log-formatter/commit/74f04ee4f6aa8e461fcb2d688459888b7279fc73 > and I guess we could cherry-pick that, I also can't reproduce this > failure in current unstable with Python 3.12. Can you still reproduce > this? I guess it doesn't hurt to apply this anyway, so I'm just going ahead. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1008502: vdirsyncer: Unknown error occured: unmatched ')'
Control: tag -1 unreproducible On Mon, Mar 28, 2022 at 01:44:58AM +0200, Christof Schulze wrote: > Running vdirsyncer sync causes the above error message about unmatched > ')'. This renders 0.4.4 - the version in stable - unusable. The root cause is > that > python-click-threading 0.4.4, which vdirsyncer is depending on, > introduced an incompatibility with python-click. > More info on the problem can be found in [2] and [3]. > > The version in testing (0.18.0-6) is working fine as it depends on a > python-click-version that does not have the problem. So installing the > version from testing including its dependencies works. > > Would you please upgrade vdirsyncer in stable to the current version in > testing to make the program work again for everyone on stable? I know this was a long time ago, but I've been going through some Python team bugs to see if I can do anything with them, and came across this; it interested me because I've been using vdirsyncer since 2017, and that definitely involved a period when I was using it on bullseye and I don't think I ever ran across this bug. I just tried setting up a clean bullseye container, installing vdirsyncer, copying over my configuration, and running "vdirsyncer discover contacts && vdirsyncer sync". Everything worked perfectly. > [1] https://github.com/pimutils/vdirsyncer/pull/891 > [2] https://github.com/click-contrib/click-threading/pull/5 > [3] https://github.com/pimutils/vdirsyncer/issues/887 If we were to update anything here in bullseye, it would make more sense to just cherry-pick the fix to click-threading; the only thing a new vdirsyncer would add would be a tighter dependency on click-threading, but for Debian stable release purposes we might as well just issue the click-threading update and have people upgrade to it. However, [2] and [3] both make it clear that the problem with the combination of click and click-threading was introduced in click 8.0.0 and does not exist with click 7.1.2. bullseye has click 7.1.2, and indeed the package versions in your bug show that as well: > Versions of packages vdirsyncer depends on: > ii init-system-helpers1.60 > ii python33.9.2-3 > ii python3-atomicwrites 1.4.0-2 > ii python3-click 7.1.2-1 > ii python3-click-log 0.2.1-2 > ii python3-click-threading0.4.4-2 > ii python3-requests 2.25.1+dfsg-2 > ii python3-requests-toolbelt 0.9.1-1 ... so I am quite suspicious that there may be some relevant information that's not in the bug report. You didn't include a traceback, which might have made it clearer; but is it possible that you have a locally installed version of click >= 8.0.0 from PyPI, perhaps due to running "pip install" outside a virtual environment? That would explain this happening to you. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1061754: python-json-log-formatter ftbfs with Python 3.12 as default
Control: tag -1 moreinfo
On Mon, Jan 29, 2024 at 01:10:20PM +0100, Matthias Klose wrote:
> With python3-defaults from experimental, the package fails to build:
>
> [...]
> = test session starts
> ==
> platform linux -- Python 3.12.1, pytest-7.4.4, pluggy-1.4.0
> cachedir: .tox/py312/.pytest_cache
> rootdir: /<>
> collected 29 items
>
> tests.py ...FF
>
> === FAILURES
> ===
> _
> JSONFormatterTest.test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided
> _
>
> self = testMethod=test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided>
>
> def
> test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided(self):
> logger.info('Sign up', extra={'fizz': 'bazz'})
> json_record = json.loads(log_buffer.getvalue())
> expected_fields = set([
> 'message',
> 'time',
> 'fizz',
> ])
> > self.assertEqual(set(json_record), expected_fields)
> E AssertionError: Items in the first set but not the second:
> E 'taskName'
While it looks like this was fixed upstream in
https://github.com/marselester/json-log-formatter/commit/74f04ee4f6aa8e461fcb2d688459888b7279fc73
and I guess we could cherry-pick that, I also can't reproduce this
failure in current unstable with Python 3.12. Can you still reproduce
this?
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1061516: Please add a sshd@.service template for socket activation
On Wed, Feb 28, 2024 at 01:17:32AM +0100, Marco d'Itri wrote: > On Jan 25, Marco d'Itri wrote: > > systemd currently expects the template to be named sshd@.service > > (because that is what Fedora uses), but if you prefer to keep the > > ssh@.service name then I suppose that we could patch systemd as well. > > Is there any way I can help with this? > The major issue is deciding how you want the template to be called. Does this patch look workable? It mostly just resurrects the template unit we used to ship, under a different name. diff --git a/debian/changelog b/debian/changelog index 873dddcfa..78863e039 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,14 @@ +openssh (1:9.6p1-5) UNRELEASED; urgency=medium + + * Restore systemd template unit for per-connection sshd instances, +although without any corresponding .socket unit for now; this is mainly +for use with the forthcoming systemd-ssh-generator (closes: #1061516). +It's now called sshd@.service, since unlike the main service there's no +need to be concerned about compatibility with the slightly confusing +"ssh" service name that Debian has traditionally used. + + -- Colin Watson Sun, 03 Mar 2024 19:49:58 + + openssh (1:9.6p1-4) unstable; urgency=medium * Add sshd_config checksums for 1:9.2p1-1 to ucf reference file, and add a diff --git a/debian/openssh-server.install b/debian/openssh-server.install index cf86dce41..5bf99be16 100755 --- a/debian/openssh-server.install +++ b/debian/openssh-server.install @@ -14,6 +14,7 @@ debian/openssh-server.ufw.profile => etc/ufw/applications.d/openssh-server debian/systemd/ssh.service lib/systemd/system debian/systemd/ssh.socket lib/systemd/system debian/systemd/rescue-ssh.target lib/systemd/system +debian/systemd/sshd@.service lib/systemd/system debian/systemd/ssh-session-cleanup usr/lib/openssh # dh_apport would be neater, but at the time of writing it isn't in unstable diff --git a/debian/systemd/sshd@.service b/debian/systemd/sshd@.service new file mode 100644 index 0..29864a800 --- /dev/null +++ b/debian/systemd/sshd@.service @@ -0,0 +1,12 @@ +[Unit] +Description=OpenBSD Secure Shell server per-connection daemon +Documentation=man:sshd(8) man:sshd_config(5) +After=auditd.service + +[Service] +EnvironmentFile=-/etc/default/ssh +ExecStart=-/usr/sbin/sshd -i $SSHD_OPTS +StandardInput=socket +RuntimeDirectory=sshd +RuntimeDirectoryPreserve=yes +RuntimeDirectoryMode=0755 Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1065437: debos: Build on arm64
Source: debos
Version: 1.1.3-1
Severity: wishlist
Tags: patch
Since fakemachine now builds on arm64 as well as amd64, it should be
possible to build debos on arm64 too. I've only build-tested this
patch, but I think it should work given that debos is tested upstream on
arm64.
Note that qemu-system-x86 provides qemu-system-amd64, so the substvar
here shouldn't change behaviour on amd64; this was simpler than
computing a custom substvar in debian/rules.
diff --git a/debian/control b/debian/control
index ed69af8..12d3ef8 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,7 @@ XS-Go-Import-Path: github.com/go-debos/debos
Testsuite: autopkgtest-pkg-go
Package: debos
-Architecture: amd64
+Architecture: amd64 arm64
Built-Using:
${misc:Built-Using},
Recommends:
@@ -38,7 +38,7 @@ Recommends:
dosfstools,
e2fsprogs,
fdisk,
- linux-image-amd64,
+ linux-image-${Arch},
mount,
ovmf,
parted,
@@ -49,7 +49,7 @@ Recommends:
Depends:
busybox | busybox-static,
debootstrap,
- qemu-system-x86,
+ qemu-system-${Arch},
qemu-user-static,
systemd-container,
${misc:Depends},
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1064898: /usr/bin/sshd: mktemp - literal X-s in /tmp directory names
On Tue, Feb 27, 2024 at 12:56:47PM +0100, Csillag Tamas wrote: >* What led up to the situation? > After upgrading to debian 12 I am seeing directories in /tmp like: > ssh-XXnOKqkt, ssh-XXtGmfLV >* What was the outcome of this action? >* What outcome did you expect instead? > These directories are created by sshd. > In oldstable and OpenBSD the directories are as expected: > ssh-LwxtSMoGSV, ssh-JPcQMaBN6s > > The regression might be only in openssh-portable? > > As there are still 6 variable characters this might not be easily exploitable > security-wise and it used to be 10 just as in OpenBSD current. This is the same as https://bugs.debian.org/1001186; it's fixed for the next development release, but not yet for bookworm. Since this doesn't appear to be immediately serious, my inclination is to queue this up to fix along with the next bookworm openssh security update (whenever that might be), but not to trouble the security team with it right away. Does that sound reasonable? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1064852: incus: missing depends on iproute2
On Tue, Feb 27, 2024 at 01:33:08AM +, Mathias Gibbens wrote: > iproute2 is Priority: important, which according to Policy §2.5 means > that it is generally expected to be present on a Debian system. Do you > have a specific use case where for some reason you don't have iproute2 > installed? Would you mind reassessing your view in light of Policy 3.5 (https://www.debian.org/doc/debian-policy/ch-binary.html#dependencies)? I think it's quite straightforward and unambiguous. Section 2.5 has traditionally not been what controls decisions about when dependencies ought to be specified, and this particular case is one that I'm surprised to find being controversial. The fine distinction between "Priority: required" and "Essential: yes" has sometimes confused people in the past and has needed some discussion, but it's always been my experience that if one package needs another "Priority: important" package for proper functioning then it's been quite uncontroversial that the first package must declare a dependency. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1065174: incus: VM agent isn't injected if /etc/environment sets PATH
Package: incus Version: 0.6-1 Severity: normal If /etc/environment sets PATH (as is the case by default in Ubuntu, but it's possible users have done this too), then the changes in https://salsa.debian.org/go-team/packages/incus/-/commit/0048583bbb4d10f86cb402b9c51b8660afaf5402 to incus.service and incus-user.service to add /usr/libexec/incus to PATH don't work, because EnvironmentFile= overrides Environment= (see systemd.exec(5)). We spent a bit of time debugging this in https://discuss.linuxcontainers.org/t/incus-agent-fails-to-start/18969. It looks like the right answer is to arrange that "PATH=/usr/libexec/incus:/usr/sbin:/usr/bin:/sbin:/bin" is in a file that you can give to EnvironmentFile=, and then things will work properly: settings read from later files will override those read from earlier files. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1065164: python3.11-dbg: postinst/prerm reference libpython3.11-dbg rather than libpython3.11t64-dbg
Package: python3.11-dbg Version: 3.11.8-2 Severity: normal >From an upgrade: Setting up python3.11-dbg (3.11.8-2) ... dpkg-query: package 'libpython3.11-dbg' is not installed Use dpkg --contents (= dpkg-deb --contents) to list archive files contents. python3.11-dbg: can't get files for byte-compilation This doesn't cause the upgrade to fail, but it does mean that some files that should be byte-compiled aren't. The same goes for the code in the prerm to remove bytecode. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.0-14-generic (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages python3.11-dbg depends on: ii libc6 2.37-15 ii libexpat1 2.6.0-1 ii libpython3.11t64-dbg 3.11.8-2 ii python3.113.11.8-2 ii zlib1g1:1.3.dfsg-3+b1 Versions of packages python3.11-dbg recommends: ii gdb 13.2-1 Versions of packages python3.11-dbg suggests: pn python3-gdbm-dbg pn python3-tk-dbg -- no debconf information -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1063345: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#1063345: fixed in python3.12 3.12.2-2)
Control: reopen 1063345 > python3.12 (3.12.2-2) unstable; urgency=medium > . > [ Colin Watson ] >* Don't rely on module state in teedataobject_clear (from Brandt Bucher in > https://github.com/python/cpython/issues/115874). Closes: #1063345. Unfortunately this commit just added my changelog entry but not the actual patch, and so the bug is still present: https://salsa.debian.org/cpython-team/python3/-/commit/c2e29e5e5d9daf98d28a682349341408ac3fadca -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1065064: libpam-doc: doc-base reports missing files
Package: libpam-doc Version: 1.5.3-4 Severity: normal An upgrade reported: Error in `/usr/share/doc-base/libpam-doc.pam-admin-guide', line 14: all `Format' sections are invalid. Error in `/usr/share/doc-base/libpam-doc.pam-applications-guide', line 17: all `Format' sections are invalid. Error in `/usr/share/doc-base/libpam-doc.pam-modules-guide', line 14: all `Format' sections are invalid. This is true; all of /usr/share/doc/libpam-doc/html/Linux-PAM_SAG.html, /usr/share/doc/libpam-doc/html/sag-*.html, /usr/share/doc/libpam-doc/txt/Linux-PAM_SAG.txt.gz, /usr/share/doc/libpam-doc/html/Linux-PAM_ADG.html, /usr/share/doc/libpam-doc/html/adg*.html, /usr/share/doc/libpam-doc/txt/Linux-PAM_ADG.txt.gz, /usr/share/doc/libpam-doc/html/Linux-PAM_MWG.html, /usr/share/doc/libpam-doc/html/mwg*.html, and /usr/share/doc/libpam-doc/txt/Linux-PAM_MWG.txt.gz are listed in those doc-base files but are in fact missing. I don't know whether this is intentional (in which case the doc-base registrations should be removed to match), or an accidental build issue that should be fixed. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.0-14-generic (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect -- no debconf information -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1065063: libpng16-16t64: doc-base file invalid after 64-bit time_t transition
Package: libpng16-16t64 Version: 1.6.43-2 Severity: normal An upgrade reported: Error in `/usr/share/doc-base/libpng16-16t64.libpng16', line 25: all `Format' sections are invalid. This is true; the doc-base file says "Files: /usr/share/doc/libpng16-16/libpng-manual.txt.gz", but this should now be "Files: /usr/share/doc/libpng16-16t64/libpng-manual.txt.gz". -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.0-14-generic (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages libpng16-16t64 depends on: ii libc6 2.37-15 ii zlib1g 1:1.3.dfsg-3+b1 libpng16-16t64 recommends no packages. libpng16-16t64 suggests no packages. -- no debconf information -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1058317: Bug#1063345: python3.12: Segmentation fault in get_module_state_by_cls at ../Modules/itertoolsmodule.c
Control: unmerge 1058317 1063345 Control: reassign 1063345 python3.12 Control: affects 1063345 celery Control: forwarded 1063345 https://github.com/python/cpython/issues/115874 Control: block 1058317 by 1063345 Control: tag 1063345 patch On Tue, Feb 06, 2024 at 02:26:55PM +0100, Jérémy Lal wrote: > python3-celery test suite crashes with python 3.12 during gc before exit (see > attached stack trace). > > It can be reproduced quickly with > > apt build-dep celery > dget -xu https://deb.debian.org/debian/pool/main/c/celery/celery_5.3.4-2.dsc > cd celery-5.3.4 > python3.12 -m pytest -v > t/unit/tasks/test_canvas.py::test_group::test_apply_contains_chords_containing_empty_chain > t/unit/tasks/test_canvas.py::test_group::test_apply > > > Results (0.56s): >1 passed >1 xfailed > Erreur de segmentation (core dumped) There are two separate issues in the current celery FTBFS, so I'm unmerging these two bugs again because they ought to be tracked separately - and it turns out that this one really is a bug in Python 3.12. I happened to notice that something very similar to #1063345 had recently been reported to Python upstream as https://github.com/python/cpython/issues/115874, with a much more manageably-sized reproducer, and there's a patch for it in https://github.com/python/cpython/issues/115874#issuecomment-1965775536. I've built the Debian python3.12 package with this patch, and I've confirmed that Celery 5.3.6 passes its tests with this patch when it previously failed. Celery is unlucky to run into this, but it doesn't seem to be anything particularly intrinsic to Celery - it's an artifact of the particular set of pytest plugins it happens to use, which manage to tickle this particular bug. I think it would be worth applying this patch to Debian's python3.12 package, as it could easily bite in other places and this was a real time-sink for me before I managed to find the upstream bug that somebody else had fortunately filed. (It would also be nice to get Celery back into Debian testing and Ubuntu noble if at all possible, the latter of which has a fairly close deadline.) Separately, #1058317 still has the test failure in test_AsyncResult.test_del. That was fixed in Celery 5.3.5, and 5.3.6 is currently on salsa, but there's only limited point in uploading it until the Python bug is fixed. Suggested Python patch follows, though you might want to check whether it's progressed any further upstream in case there've been any additional tweaks: diff --git a/debian/changelog b/debian/changelog index 0e16636..b57f7dc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +python3.12 (3.12.2-1.1) UNRELEASED; urgency=medium + + * Don't rely on module state in teedataobject_clear (from Brandt Bucher in +https://github.com/python/cpython/issues/115874; closes: #1063345). + + -- Colin Watson Tue, 27 Feb 2024 10:15:37 + + python3.12 (3.12.2-1) unstable; urgency=medium * Python 3.12.2 release. diff --git a/debian/patches/itertools-clear-crash.diff b/debian/patches/itertools-clear-crash.diff new file mode 100644 index 000..cdaeebb --- /dev/null +++ b/debian/patches/itertools-clear-crash.diff @@ -0,0 +1,19 @@ +Description: Don't rely on module state in teedataobject_clear +Origin: other, https://github.com/python/cpython/issues/115874#issuecomment-1965775536 +Bug: https://github.com/python/cpython/issues/115874 +Bug-Debian: https://bugs.debian.org/1063345 + +Index: b/Modules/itertoolsmodule.c +=== +--- a/Modules/itertoolsmodule.c b/Modules/itertoolsmodule.c +@@ -832,8 +832,7 @@ + Py_CLEAR(tdo->values[i]); + tmp = tdo->nextlink; + tdo->nextlink = NULL; +-itertools_state *state = get_module_state_by_cls(Py_TYPE(tdo)); +-teedataobject_safe_decref(tmp, state->teedataobject_type); ++teedataobject_safe_decref(tmp, Py_TYPE(tdo)); + return 0; + } + diff --git a/debian/patches/series b/debian/patches/series index 63c72c2..0a85028 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -31,3 +31,4 @@ fix-py_compile.diff ntpath-import.diff python3.12-updates.diff issue108447.diff +itertools-clear-crash.diff Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1056232: celery's autopkg tests fail with Python 3.12
Control: reassign -1 python3-kombu Control: forwarded -1 https://github.com/celery/kombu/issues/1804 Control: affects -1 src:celery Control: fixed -1 kombu/5.3.4-1 Control: close -1 On Sun, Nov 19, 2023 at 12:08:09PM +0100, Matthias Klose wrote: > celery's autopkg tests fail with Python 3.12. All failing like: [...] > 544s self = > 544s instance = > 544s value = 0x73c86780> > 544s > 544s def __set__(self, instance, value): > 544s if instance is None: > 544s return self > 544s > 544s > with self.lock: > 544s E AttributeError: 'cached_property' object has no attribute > 'lock' > 544s > 544s /usr/lib/python3/dist-packages/kombu/utils/objects.py:37: > AttributeError This was https://github.com/celery/kombu/issues/1804, fixed in kombu 5.3.3, which has been in Debian for a few months now. (#1058317 is still a problem, but is a separate bug.) Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1064530: pagure: (Build-)depend on celery rather than python-celery-common
Source: pagure Version: 5.11.3+dfsg-2.1 Severity: normal https://bugs.debian.org/1038295 requests that the transitional package python-celery-common be dropped from the archive. However, pagure still (build-)depends on it. Please could you (build-)depend on its replacement "celery" package instead, if that's still appropriate? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059393: openssh: CVE-2023-51767
On Fri, Feb 23, 2024 at 12:40:41PM +, P Tamil Selvam wrote: > Pls. let us know the ETA by when openssh issue will be fixed in bookworm > release ? No fix exists anywhere to my knowledge, so there is currently no ETA. The right place to ask about a fix would be upstream. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1064276: bookworm-pu: package python-channels-redis/4.0.0-1+deb12u1
On Wed, Feb 21, 2024 at 07:40:27AM +, Jonathan Wiltshire wrote: > On Mon, Feb 19, 2024 at 01:26:17PM +0000, Colin Watson wrote: > > [ Reason ] > > The version of python-channels-redis in bookworm suffers from > > https://bugs.debian.org/1027387 / > > https://github.com/django/channels_redis/issues/332, which was > > introduced in 4.0.0 and is a regression from bullseye. I ran into this > > while working on debusine. > > Please go ahead. Uploaded, thanks. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1027387: python3-channels-redis: upstream bug: runtimeError: event loop is closed
On Mon, Feb 19, 2024 at 11:58:02AM +, Colin Watson wrote: > Since there is now an upstream fix > (https://github.com/django/channels_redis/pull/347), I think it would be > worth backporting this to bookworm. I've filed https://bugs.debian.org/1064276 to request permission to upload this. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1064276: bookworm-pu: package python-channels-redis/4.0.0-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: python-channels-re...@packages.debian.org, Michael Fladischer
Control: affects -1 + src:python-channels-redis
[ Reason ]
The version of python-channels-redis in bookworm suffers from
https://bugs.debian.org/1027387 /
https://github.com/django/channels_redis/issues/332, which was
introduced in 4.0.0 and is a regression from bullseye. I ran into this
while working on debusine.
[ Impact ]
I believe that any application that (a) runs Celery, (b) uses
channels-redis, and (c) sends to a channel via async_to_sync in a Celery
task without explicitly closing redis pools will encounter RuntimeErrors
as per the upstream bug report above.
I was able to work around this in my application
(https://salsa.debian.org/freexian-team/debusine/-/merge_requests/594),
but I lost a few hours to figuring this out and it would be good if
others didn't have to.
[ Tests ]
It's covered by the upstream test suite, which is run via autopkgtest.
I also confirmed that this change fixes the problems I ran into in
debusine, without applying any workarounds.
[ Risks ]
The alternative is letting applications work around this individually,
which I think on balance is probably worse - I initially tried switching
to RedisPubSubChannelLayer instead, which did more or less work but
required various other rather strange workarounds.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
This is a straight cherry-pick of an upstream change to close redis
connection pools when closing the asyncio loop.
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru python-channels-redis-4.0.0/debian/changelog
python-channels-redis-4.0.0/debian/changelog
--- python-channels-redis-4.0.0/debian/changelog2022-10-10
21:13:47.0 +0100
+++ python-channels-redis-4.0.0/debian/changelog2024-02-19
12:04:40.0 +
@@ -1,3 +1,11 @@
+python-channels-redis (4.0.0-1+deb12u1) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Cherry-pick from upstream:
+- Ensure pools are closed on loop close in core (closes: #1027387).
+
+ -- Colin Watson Mon, 19 Feb 2024 12:04:40 +
+
python-channels-redis (4.0.0-1) unstable; urgency=medium
* New upstream release.
diff -Nru
python-channels-redis-4.0.0/debian/patches/loop-close-pools-in-core.patch
python-channels-redis-4.0.0/debian/patches/loop-close-pools-in-core.patch
--- python-channels-redis-4.0.0/debian/patches/loop-close-pools-in-core.patch
1970-01-01 01:00:00.0 +0100
+++ python-channels-redis-4.0.0/debian/patches/loop-close-pools-in-core.patch
2024-02-19 12:04:34.0 +
@@ -0,0 +1,227 @@
+From: Devid
+Date: Tue, 28 Mar 2023 11:30:35 +0200
+Subject: Assured pools are closed on loop close in core (#347)
+
+Origin: upstream, https://github.com/django/channels_redis/pull/347
+Bug: https://github.com/django/channels_redis/issues/332
+Bug-Debian: https://bugs.debian.org/1027387
+Last-Update: 2024-02-19
+---
+ channels_redis/core.py | 64
+ channels_redis/pubsub.py | 18 +-
+ channels_redis/utils.py | 16
+ 3 files changed, 54 insertions(+), 44 deletions(-)
+
+diff --git a/channels_redis/core.py b/channels_redis/core.py
+index 7c04ecd..c3eb3b3 100644
+--- a/channels_redis/core.py
b/channels_redis/core.py
+@@ -15,7 +15,7 @@ from redis import asyncio as aioredis
+ from channels.exceptions import ChannelFull
+ from channels.layers import BaseChannelLayer
+
+-from .utils import _consistent_hash
++from .utils import _consistent_hash, _wrap_close
+
+ logger = logging.getLogger(__name__)
+
+@@ -69,6 +69,26 @@ class BoundedQueue(asyncio.Queue):
+ return super(BoundedQueue, self).put_nowait(item)
+
+
++class RedisLoopLayer:
++def __init__(self, channel_layer):
++self._lock = asyncio.Lock()
++self.channel_layer = channel_layer
++self._connections = {}
++
++def get_connection(self, index):
++if index not in self._connections:
++pool = self.channel_layer.create_pool(index)
++self._connections[index] = aioredis.Redis(connection_pool=pool)
++
++return self._connections[index]
++
++async def flush(self):
++async with self._lock:
++for index in list(self._connections):
++connection = self._connections.pop(index)
++await connection.close(close_connection_pool=True)
++
++
+ class RedisChannelLayer(BaseChannelLayer):
+ """
+ Redis channel layer.
+@@ -101,8 +121,7 @@ class RedisChannelLayer(BaseChannelLayer):
+ self.hosts = self.decode_hosts(hosts)
+ self.ring_size =
Bug#1027387: python3-channels-redis: upstream bug: runtimeError: event loop is closed
Control: forwarded -1 https://github.com/django/channels_redis/issues/332 Control: tags -1 fixed-upstream Control: fixed -1 4.1.0-1 On Fri, Dec 30, 2022 at 08:39:40PM +0100, Jérémy Lal wrote: > multiple python applications using channels-redis 4.0.0 have that issue: > https://github.com/django/channels_redis/issues/332 > > It doesn't look like it's going to be fixed soon. > It might be a good idea to not ship channels-redis 4.0.0 in bookworm. I ran into this too just now, and it was very confusing. I was able to work around it by switching to RedisPubSubChannelLayer, but I'm not totally sure that's a good idea: it's still marked as being in beta even now, 4.0.0's RedisPubSubChannelLayer also suffers from https://github.com/django/channels_redis/issues/343, and in my application the switch provoked some kind of extremely weird coverage failure, possibly https://github.com/python/cpython/issues/106749. Since there is now an upstream fix (https://github.com/django/channels_redis/pull/347), I think it would be worth backporting this to bookworm. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1063842: openssh-server: Binding to a static IPv6 address causes sshd to fail at bootup
On Tue, Feb 13, 2024 at 01:13:17PM +, Bert wrote: > I configured SSH with a static IPv6 ListenAddress. > During bootup, SSH tries to start before the IPv6 address has been fully > bound to the host (ie during duplicate address detection) > This results in SSH failing to start with "Cannot bind any address" and a > return code of 255. > The systemd unit file for ssh contains "RestartPreventExitStatus=255" which > causes it to give up when it encounters this error. > In a cloud environment this is a critical failure as it renders the host > inaccessible. > The same thing occurs if the static IPv6 address is assigned a different way > (eg via SLAAC or DHCPv6) > If you remove this line, systemd tries again and succeeds once the address > has been bound to the host. I generally also add "StartSec=15s" to prevent it > trying too frequently. > This manual change is not persistent, as it gets overwritten next time you > update the package. I suggest that in such unusual configurations you should use the After= directive in the [Unit] section to ensure that ssh.service doesn't start until the relevant other systemd unit has been started. You can do this in a way that persists across upgrades using a drop-in unit; see "man systemd.unit" or use "systemctl edit ssh.service". However, a simpler solution might well be to remove ListenAddress and instead use firewall rules to restrict incoming SSH connections to only the desired address(es), as is recommended in README.Debian. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1063762: Build path leaks in generated documents, introducing reproducibility issues
On Mon, Feb 12, 2024 at 01:37:56PM +0100, Enrico Zini wrote: > Hello, and thank you for your work on sphinx! > > Possibly due to > https://salsa.debian.org/python-team/packages/sphinx/-/commit/4a1ebb237fb0f10adef3df39c2844aa68b9da79c > sphinx leaks the build path into the generated output (see attached > output.html.gz). > > This looks like an accidental mistake that is currently making packages > unreproducible. This actually turns out not to be a sphinx regression at all. It's just a coincidence that this upload was at around the same time as https://salsa.debian.org/salsa-ci-team/pipeline/-/commit/9d97899bfdfde393d69312a67881330ade63b5ba, which enabled build path variation in reprotest runs that we were previously missing. I think the correct fix is to enable the todo_link_only option on our side. I'm currently testing that, and if that works then I think this bug can be closed. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1019980: lintian: source-is-missing check for HTML is much too sensitive
On Thu, Feb 08, 2024 at 06:39:18PM +, Bastien Roucariès wrote: > Are you sure it is not embdeded base64 encoded png or minified javascript* ? Yes, I'm absolutely certain. > If not we could try to know why it choke ? I already gave a full explanation of this in my first message, which for some reason people are ignoring: """ So it issues a diagnostic for every HTML file with a somewhat long line (over 512 characters) unless it has an associated .fragment.js somewhere """ The HTML files it's issuing a diagnostic on here are perfectly innocuous and readable. Here's an example of one of the "offending" lines: In version 0.51 and before, local echo could not be separated from local line editing (where you type a line of text locally, and it is not sent to the server until you press Return, so you have the chance to edit it and correct mistakes before the server sees it). New in version 0.52, local echo and local line editing are separate options, and by default PuTTY will try to determine automatically whether to enable them or not, based on which protocol you have selected and also based on hints from the server. If you have a problem with PuTTY's default choice, you can force each option to be enabled or disabled as you choose. The controls are in the Terminal panel, in the section marked Line discipline options. I mean, come on. Sure, there are a couple of character entities (which have nothing to do with the diagnostic here anyway), but otherwise you can't tell me with a straight face that that's some kind of obscure compiled format; I would have written it exactly the same way by hand except for the word-wrapping. > Another alternative if we could determine the file was compiled by halibut, > we could demote to pedantic warning > and ask to repack in order to be sure to recompile from source. Or we could fix the ridiculously-oversensitive diagnostic. On the matter of repacking (which I will not do in this case), please see my comment in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019980#15. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file
On Wed, Feb 07, 2024 at 11:13:01PM +0100, Holger Wansing wrote: > Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca : > > Dumping the encoded keymaps for pc105... > > WARNING: Can not find "caps_switch" in "group". > > WARNING: Can not find "caps_toggle" in "group". > > gzip -9n >/Keyboard/pc105.ekbd > > >/<>/Keyboard/pc105.ekbd.gz > > /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such file > > make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] Error 2 > > make[1]: Leaving directory '/<>' > > make: *** [debian/rules:204: udeb-install] Error 2 > > > >Version 1.223 builds fine in unstable instead. Perhaps this is related > >to the fact that 1.224 dropped the binary package console-setup-pc-ekbd? > > What makes you think, that this has happened? > > There is a merge request that includes the removal of said package, > but it has not yet been merged. It's not in git, but you appear to have built 1.224 from an unclean source tree that had that patch applied. My inclination is to upload 1.225 without that patch for now, as we need to rebuild for the new xkb-data to sort out uninstallability in unstable, and then get the kFreeBSD-removal patch sorted out after that. Objections? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1063216: parted: NMU diff for 64-bit time_t transition
On Mon, Feb 05, 2024 at 03:08:55PM -0300, Lucas Kanashiro wrote: > diff -Nru parted-3.6/debian/libparted-fs-resize0t64.maintscript > parted-3.6/debian/libparted-fs-resize0t64.maintscript > --- parted-3.6/debian/libparted-fs-resize0t64.maintscript 1969-12-31 > 21:00:00.0 -0300 > +++ parted-3.6/debian/libparted-fs-resize0t64.maintscript 2023-06-26 > 19:34:57.0 -0300 > @@ -0,0 +1 @@ > +dir_to_symlink /usr/share/doc/libparted-fs-resize0 libparted2 3.5-2~ Does this need to be /usr/share/doc/libparted-fs-resize0t64 instead? (Alternatively, maybe this .maintscript file can just be dropped, since the new directory name won't need to be switched to a symlink.) > diff -Nru parted-3.6/debian/rules parted-3.6/debian/rules > --- parted-3.6/debian/rules 2023-06-26 19:34:57.0 -0300 > +++ parted-3.6/debian/rules 2024-02-05 14:58:17.0 -0300 > @@ -69,18 +69,18 @@ > dh_install -pparted-udeb -plibparted2-udeb -plibparted-fs-resize0-udeb > --sourcedir=debian/tmp-udeb > > override_dh_installdocs-arch: > - dh_installdocs --link-doc=libparted2 > + dh_installdocs --link-doc=libparted2t64 > > override_dh_installdocs-indep: > - dh_installdocs -pparted-doc --doc-main-package=libparted2 > + dh_installdocs -pparted-doc --doc-main-package=libparted2t64 > dh_installdocs --remaining-packages > > override_dh_strip: > - dh_strip -plibparted2 --ddeb-migration='libparted2-dbg (<< 3.2-11~)' > - dh_strip -plibparted-fs-resize0 \ > + dh_strip -plibparted2t64 --ddeb-migration='libparted2-dbg (<< 3.2-11~)' > + dh_strip -plibparted-fs-resize0t64 \ > --ddeb-migration='libparted-fs-resize0-dbg (<< 3.2-11~)' Is the --ddeb-migration option here still needed? Presumably it won't have any common files with the old -dbg package any more (the file names in /usr/lib/debug/ change all the time, and the only other common file was /usr/share/doc/libparted-fs-resize0-dbgsym). In fact, since 3.2-11 was before oldoldstable, I'm just going to remove this override_dh_strip rule entirely, as it isn't needed any more: https://salsa.debian.org/parted-team/parted/-/commit/2ede9a43a0cb5e5abb52cd3c519769ad9d8d489d Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1062517: RM: libfido2/experimental -- ROM; unnecessary 64-bit time_t transition
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: libfi...@packages.debian.org, Steve Langasek Control: affects -1 + src:libfido2 Please remove libfido2 1.14.0-1.1~exp1 from experimental, as per Steve's attached email. (Thanks for the confirmation, Steve!) -- Colin Watson (he/him) [cjwat...@debian.org] --- Begin Message --- On Thu, Feb 01, 2024 at 01:17:29PM +, Colin Watson wrote: > On Thu, Feb 01, 2024 at 12:26:58AM +, Steve Langasek wrote: > > As part of the 64-bit time_t transition required to support 32-bit > > architectures in 2038 and beyond > > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > > libfido2 as a source package shipping runtime libraries whose ABI > > either is affected by the change in size of time_t, or could not be > > analyzed via abi-compliance-checker (and therefore to be on the safe > > side we assume is affected). > [...] > > If you have any concerns about this patch, please reach out ASAP. Although > > this package will be uploaded to experimental immediately, there will be a > > period of several days before we begin uploads to unstable; so if > > information > > becomes available that your package should not be included in the > > transition, > > there is time for us to amend the planned uploads. > This one surprised me, because there doesn't seem to be anything about > either times or offsets in libfido2's ABI as far as I can see. > https://people.canonical.com/~vorlon/armhf-time_t/compat_reports/libfido2-dev/lfs_to_timet/compat_report.html > reports 100% binary compatibility. The source compatibility tab there > does indeed show a time_t change, but I didn't think that was cause for > a SONAME change as long as it doesn't affect libfido2's own exported > symbols - am I missing something here? The thing is, the way in which we're driving a-c-c doesn't actually inspect the .so's because it's non-trivial to map these from headers, so the "binary compatibility" table is always a no-op unfortunately. I've checked libfido2.so.1 and confirmed that these functions are not exported and therefore this is a false positive. I've updated the tooling to exclude libfido2-dev, and am closing this bug report. The NMU to experimental can be ignored / superseded / removed at your discretion. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature --- End Message ---
Bug#1062291: libfido2: NMU diff for 64-bit time_t transition
On Thu, Feb 01, 2024 at 12:26:58AM +, Steve Langasek wrote: > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > libfido2 as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). [...] > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. This one surprised me, because there doesn't seem to be anything about either times or offsets in libfido2's ABI as far as I can see. https://people.canonical.com/~vorlon/armhf-time_t/compat_reports/libfido2-dev/lfs_to_timet/compat_report.html reports 100% binary compatibility. The source compatibility tab there does indeed show a time_t change, but I didn't think that was cause for a SONAME change as long as it doesn't affect libfido2's own exported symbols - am I missing something here? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059804: bullseye-pu: package exuberant-ctags/1:5.9~svn20110310-14+deb11u1
On Thu, Feb 01, 2024 at 06:39:29AM +, Adam D. Barratt wrote: > On Mon, 2024-01-01 at 17:20 +0000, Colin Watson wrote: > > I'd like to belatedly fix CVE-2022-4515 in bullseye. > > Please go ahead. Uploaded, thanks. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1061870: man: nroff: Bad system call (core dumped)
On Mon, Jan 29, 2024 at 10:42:18PM +, Thorsten Glaser wrote: > #define __NR_getrandom 355 > > Seems to be this one. Blocked by man-db’s policy, I suppose? Yes, and see: man-db 2.8.7 (26 August 2019) = ... * Make `seccomp` sandbox allow `getrandom`, used by Hardened Malloc. So I guess this is because your shell calls getrandom on startup, rather than waiting until $RANDOM is evaluated, or something like that. And nroff is a shell script. I don't have a problem with backporting that trivial change, though I'd need to work out the LTS development workflow. Added to my to-do list. FYI, you can also use MAN_DISABLE_SECCOMP=1 to bypass the seccomp sandbox for the time being. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#797071: debconf: dpkg-preconfigure extracting template message is written to stderr, should be stdout.
On Thu, Aug 27, 2015 at 04:52:41PM +0200, Benoît SÉRIE wrote: > When installing packages, apt calls dpkg-preconfigure. > The message "Extracting templates from packages..." is written to > stderr. > http://anonscm.debian.org/cgit/debconf/debconf.git/tree/dpkg-preconfigure#n173 > > IMHO, it should be written to stdout as this not an error. When I added that message in 2005, I wrote it to stderr because stdout was already in use for the output from apt-extracttemplates, which is read and parsed by dpkg-preconfigure so adding human-readable text into it isn't a good idea. However, there's nothing to stop us using a separate pipe to communicate with apt-extracttemplates - it's just a bit more fiddly. I've done that now: https://salsa.debian.org/pkg-debconf/debconf/-/commit/ad03066a1b69f634a81bfb3083a81de1900c91a9 Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#798819: debconf: support for Wayland
On Sun, Sep 13, 2015 at 02:21:09PM +0530, Ritesh Raj Sarraf wrote: > So I'm running "GNOME on Wayland" and now the Debconf Graphical User > Interface does not show up. This seems to be because of the limitation > Wayland has, as it does not support X11 like Forwarding. > > The FAQ on Wayland has some ideas, but I don't think anything is readily > available. > > http://wayland.freedesktop.org/faq.html#heading_toc_j_7 I'm sorry for the very long delay in replying to this! I don't quite see the link with forwarding, unless you're connecting over SSH. I just tested the debconf UI in a bookworm VM running Wayland, and things seemed to work fine (it used Xwayland until I realized I had to pass the XDG_RUNTIME_DIR environment variable through sudo, but that was the only hitch). Is it possible that this has been fixed by something other than debconf in the intervening years? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Mon, Jan 08, 2024 at 03:01:11PM -0800, Steve Langasek wrote: > On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote: > > On 05-01-2024 17:36, Rene Engelhard wrote: > > > Also a problem is that experimental also might already contain totally > > > unrelated updates like new upstream versions... > > > I share this worry. Have you thought about how to handle the cases where you > > don't have experimental to upload to? How big is this problem? > > > Another worry, how will you provide the required changes to the maintainers > > of the packages? Via BTS? For those working on salsa: MR? Both? Something > > else? Obviously we should not end in the situation that a new upload goes > > back to the old name (or are the ftp-masters so keen on this transition that > > that won't happen? But what about newer versions with the old name already > > in experimental, conform the former worry?). I've seen NMU's being ignored > > by subsequent uploads by the maintainer, even when they fixed RC issues > > which were then reintroduced. > > I would intend to provide diffs via the BTS. This remains the standard > policy for NMUs in Debian per the Developer's Reference, and as far as I > know has worked effectively for all such previous ABI transitions. In the current situation, though, not having experimental available means that there's no opportunity for dumat to weigh in regarding usrmerge interactions, which seems problematic given Helmut's preliminary analysis. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059903: autopkgtest: Add Incus support
else:
adtlog.debug('will start a container (with isolation-container
capability)')
capabilities.append('isolation-container')
@@ -127,7 +127,7 @@
container_name = args.remote + get_available_container_name()
adtlog.debug('using container name %s' % container_name)
VirtSubproc.check_exec(
-['lxc', 'launch', '--ephemeral', args.image, container_name] +
extra_lxcargs,
+['incus', 'launch', '--ephemeral', args.image, container_name] +
extra_incusargs,
outp=True,
timeout=600
)
@@ -140,11 +140,11 @@
# We also want to avoid exiting with 255 as that's auxverb's exit code
# if the auxverb itself failed; so we translate that to 253.
# Tests or builds sometimes leak background processes which might still
-# be connected to lxc exec's stdout/err; we need to kill these after
the
-# main program (build or test script) finishes, otherwise we get
+# be connected to incus exec's stdout/err; we need to kill these after
+# the main program (build or test script) finishes, otherwise we get
# eternal hangs.
VirtSubproc.auxverb = [
-'lxc', 'exec', container_name, '--',
+'incus', 'exec', container_name, '--',
'env', '-i', 'bash', '-c',
'set -a; '
'[ -r /etc/environment ] && . /etc/environment 2>/dev/null ||
true; '
@@ -168,7 +168,7 @@
]
except Exception:
# Clean up on failure
-VirtSubproc.execute_timeout(None, 300, ['lxc', 'delete', '--force',
container_name])
+VirtSubproc.execute_timeout(None, 300, ['incus', 'delete', '--force',
container_name])
raise
@@ -184,7 +184,7 @@
def get_uptime():
try:
(rc, out, _) = VirtSubproc.execute_timeout(
-None, 10, ['lxc', 'exec', container_name, '--', 'cat',
'/proc/uptime'],
+None, 10, ['incus', 'exec', container_name, '--', 'cat',
'/proc/uptime'],
stdout=subprocess.PIPE, stderr=subprocess.PIPE)
if rc != 0:
@@ -204,7 +204,7 @@
def hook_wait_reboot(*func_args, **kwargs):
adtlog.debug('hook_wait_reboot: waiting for container to shut down...')
-# "lxc exec" exits with 0 when the container stops, so just wait longer
+# "incus exec" exits with 0 when the container stops, so just wait longer
# than our timeout
initial_uptime = kwargs['initial_uptime']
@@ -234,7 +234,7 @@
def hook_cleanup():
VirtSubproc.downtmp_remove()
-VirtSubproc.check_exec(['lxc', 'delete', '--force', container_name],
timeout=600)
+VirtSubproc.check_exec(['incus', 'delete', '--force', container_name],
timeout=600)
def hook_capabilities():
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-14-generic (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND,
TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Versions of packages autopkgtest depends on:
ii apt-utils 2.7.7
ii libdpkg-perl1.22.2
ii mawk1.3.4.20231126-1
ii procps 2:4.0.4-2
ii python3 3.11.6-1
ii python3-debian 0.1.49
Versions of packages autopkgtest recommends:
ii autodep8 0.28
ii fakeroot 1.32.2-1
Versions of packages autopkgtest suggests:
pn docker.io
pn fakemachine
ii genisoimage 9:1.1.11-3.4
pn lxc
pn lxd
ii ovmf 2023.11-2
pn ovmf-ia32
pn podman
ii python3-distro-info 1.7
ii qemu-efi-aarch64 2023.11-2
ii qemu-efi-arm 2023.11-2
pn qemu-system
ii qemu-utils 1:8.2.0+ds-1
pn schroot
ii util-linux 2.39.3-2
pn vmdb2
pn zerofree
-- no debconf information
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059804: bullseye-pu: package exuberant-ctags/1:5.9~svn20110310-14+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: exuberant-ct...@packages.debian.org Control: affects -1 + src:exuberant-ctags [ Reason ] I'd like to belatedly fix CVE-2022-4515 in bullseye. [ Impact ] Security vulnerability as described in https://security-tracker.debian.org/tracker/CVE-2022-4515, though the security team has marked it no-dsa and asked that any fix go via a point release instead. [ Tests ] I tested this manually by calling ctags with various -o options, e.g. "ctags -o 'a b' -R", and checking that it produces the requested output file names. [ Risks ] The fix is just a straight cherry-pick from bookworm (which in turn was backported as closely as possible from universal-ctags upstream), and while I hate the continued use of system(3) here it's probably better than introducing a novel rewrite for a security update. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] As attached. git-dpm has introduced a small amount of additional noise; I didn't think it was worth the effort to persuade it to avoid that in this case. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org] diff --git a/debian/.git-dpm b/debian/.git-dpm index be86f1e84..e26b5ab8c 100644 --- a/debian/.git-dpm +++ b/debian/.git-dpm @@ -1,6 +1,6 @@ # see git-dpm(1) from git-dpm package -ed1d00e4c005ecc20f298630cce7635d88f5b669 -ed1d00e4c005ecc20f298630cce7635d88f5b669 +5c9ca1167f9eebf78bf28763e3604b1af79c967d +5c9ca1167f9eebf78bf28763e3604b1af79c967d 4b0ebb9d344fd369c889291478986c65a5a36ea8 4b0ebb9d344fd369c889291478986c65a5a36ea8 exuberant-ctags_5.9~svn20110310.orig.tar.gz diff --git a/debian/changelog b/debian/changelog index 62ccf7654..75c7d8e08 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +exuberant-ctags (1:5.9~svn20110310-14+deb11u1) UNRELEASED; urgency=medium + + * Backport from universal-ctags: +- CVE-2022-4515: main: quote output file name before passing it to + system(3) function (closes: #1026995). + + -- Colin Watson Sun, 24 Dec 2023 12:41:53 + + exuberant-ctags (1:5.9~svn20110310-14) unstable; urgency=low [ Debian Janitor ] diff --git a/debian/patches/gcc-no-common.patch b/debian/patches/gcc-no-common.patch index 024422c9e..308f7d9c9 100644 --- a/debian/patches/gcc-no-common.patch +++ b/debian/patches/gcc-no-common.patch @@ -14,7 +14,7 @@ Patch-Name: gcc-no-common.patch 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/objc.c b/objc.c -index 2a5de58..a5811ec 100644 +index 2a5de58ab..a5811ec59 100644 --- a/objc.c +++ b/objc.c @@ -432,16 +432,16 @@ typedef void (*parseNext) (vString * const ident, objcToken what); @@ -38,7 +38,7 @@ index 2a5de58..a5811ec 100644 /** Grammar */ diff --git a/ocaml.c b/ocaml.c -index 104a777..235862f 100644 +index 104a77706..235862fd3 100644 --- a/ocaml.c +++ b/ocaml.c @@ -514,26 +514,26 @@ typedef void (*parseNext) (vString * const ident, ocaToken what); diff --git a/debian/patches/go.patch b/debian/patches/go.patch index 760f47bd0..bce44fd73 100644 --- a/debian/patches/go.patch +++ b/debian/patches/go.patch @@ -17,7 +17,7 @@ Patch-Name: go.patch diff --git a/go.c b/go.c new file mode 100644 -index 000..6bd3a36 +index 0..6bd3a369a --- /dev/null +++ b/go.c @@ -0,0 +1,670 @@ @@ -692,7 +692,7 @@ index 000..6bd3a36 + return def; +} diff --git a/parsers.h b/parsers.h -index 600f636..3a24d6e 100644 +index 600f63614..3a24d6e09 100644 --- a/parsers.h +++ b/parsers.h @@ -31,6 +31,7 @@ @@ -704,7 +704,7 @@ index 600f636..3a24d6e 100644 JavaParser, \ JavaScriptParser, \ diff --git a/source.mak b/source.mak -index c97617f..985d56c 100644 +index c97617f34..985d56cfc 100644 --- a/source.mak +++ b/source.mak @@ -24,6 +24,7 @@ SOURCES = \ diff --git a/debian/patches/jscript-set-tag-scope.patch b/debian/patches/jscript-set-tag-scope.patch index baf036ffc..a0958b573 100644 --- a/debian/patches/jscript-set-tag-scope.patch +++ b/debian/patches/jscript-set-tag-scope.patch @@ -17,7 +17,7 @@ Patch-Name: jscript-set-tag-scope.patch 1 file changed, 51 insertions(+), 3 deletions(-) diff --git a/jscript.c b/jscript.c -index 5de3367..a790355 100644 +index 5de3367f9..a790355b8 100644 --- a/jscript.c +++ b/jscript.c @@ -215,6 +215,7 @@ static void deleteToken (tokenInfo *const token) diff --git a/debian/patches/memmove.patch b/debian/patches/memmove.patch index d23551a4b..b3e0ad9e1 100644 --- a/debian/patches/memmove.patch +++ b/debian/patches/memmove.patch @@ -16,7 +16,7 @@ Patch-Name: memmove.patch 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/routines.c b/routines.c -index 83bcdcc..8ebe2e0 100644 +index 83bcdccda..8ebe2e
Bug#1059802: troffcvt: Broken with groff 1.23.0: .de1 etc. unimplemented
Package: troffcvt Version: 1.04+repack1-1 Severity: grave Justification: renders package unusable groff 1.23.0 makes more use of the .de1 request (and probably others) than previous versions did. This causes troffcvt to be unable to even format its own documentation, with this error: /usr/share/groff/current/tmac/devtag.tmac (line 74): you cannot alias to non-existing name That's probably just the first error; some work is needed to get this rendering properly again. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-10-generic (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages troffcvt depends on: ii groff 1.23.0-3 ii libc6 2.37-13 ii perl 5.36.0-10 troffcvt recommends no packages. troffcvt suggests no packages. -- no debconf information -- Colin Watson [cjwat...@debian.org]
Bug#1059393: ABACuS arXiv.2310.09977
On Tue, Dec 26, 2023 at 12:03:36PM +0100, Boud Roukema wrote: > There's a proposed mitigation for CVE-2023-51767 with ABACuS: > > https://arxiv.org/abs/2310.09977 > > https://github.com/CMU-SAFARI/ABACuS This is a proposal for redesigned memory controllers. It isn't an actionable mitigation at the level of OpenSSH. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059639: please give possibility for custom ssh-agent parameters
On Fri, Dec 29, 2023 at 07:38:40PM +0100, Marc Haber wrote: > /usr/lib/openssh/agent-launch starts ssh-agent with a standard set of > parameters. I'd like to have -t 1200 added to that. > > Please consider adding a possibility to control the parameters that the > ssh agent is being invoked, for example by having an override unit, or > having /usr/lib/openssh/agent-launch read a user-specific configuration > file. My main concern is getting quoting right: ssh-agent does take some options were quoting can be relevant, especially -P. IMO that rules out approaches such as environment variables (well, it's not impossible, but it'd be a likely source of bugs). I think the simplest approach would be to allow invoking something like "/usr/lib/openssh/agent-launch start -- -t 1200", and pass the extra arguments on to ssh-agent. You could then write a drop-in unit like this: [Service] ExecStart= ExecStart=/usr/lib/openssh/agent-launch start -- -t 1200 Would that be acceptable? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3
On Sat, Dec 30, 2023 at 12:13:28AM +0100, Philipp Kern wrote: > On 29.12.23 11:30, Simon Josefsson wrote: > > SSH3 is a complete revisit of the SSH protocol, mapping its semantics on > > top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for > > secure channel establishment and the HTTP Authorization mechanisms for > > user authentication. Among others, SSH3 allows the following > > improvements: > > I feel like SSH3 is an unfortunate name. The program claims "SSH3 stands for > the concatenation of SSH and H3." - well sure, but you're also reusing the > name of an existing protocol and bump its version. ssh-h3? I agree - as the Debian OpenSSH maintainer, I'm concerned that this will cause a new source of user confusion because people will think "ah, ssh3, that must be better than ssh" (which indeed seems to have been a deliberate marketing choice by this project) and not realize that it's a largely incompatible thing. Not to mention the way that it parses OpenSSH configuration files, which may work today but I doubt OpenSSH offers any guarantees that it won't make changes that will break this independent parser in future. I also feel that something security-critical like this that's labelled by upstream as "still experimental" probably shouldn't be in a Debian release. Maybe it should be kept in Debian experimental for the time being? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1058500: base-passwd: Proposal to Assign a Fixed Group ID to the render Group
On Tue, Dec 12, 2023 at 10:13:36AM -0800, Stanley Phoong wrote: >* What led up to the situation? >The transition of /dev/dri/renderD* from the video to the render >group in SystemD has led to issues due to the lack of a fixed GID for >render. This has impacted various projects and forced the community >to adopt workarounds some workarounds are potentially security hazard >(e.g. enabling privilege mode or root access to mitigate this issue) >This impacts Docker users and VM users the most. I'm not necessarily opposed to allocating a fixed group ID in the 6-64999 range for "render", but normally this sort of request would come from a maintainer of one of the relevant packages (i.e. the packages that currently create that group dynamically) so that I can be sure that the maintainers of relevant packages agree with this action and are prepared to take the necessary transitional steps. Are there any other Debian bug reports on this subject in which package maintainers have analysed the problem and agreed that this is what needs to be done? >Reference commit ID: >github.com/systemd/systemd/commit/4e15a7343cb389e97f3eb4f49699161862d8b8b2 > >Some examples of issues around this: >https://github.com/blakeblackshear/frigate/issues/7640 > > https://unix.stackexchange.com/questions/747523/docker-permissions-issue-accessing-dev-dri-device >https://github.com/linuxserver/docker-plex/issues/211 > > https://support.xilinx.com/s/question/0D52E6mfsHaSAI/permission-denied-when-running-hardware >https://github.com/jellyfin/jellyfin/issues/9229 It's less than clear that the change you suggest would fix these issues. If what you're trying to do is to make sure that the "render" group has the same ID in the host and in containers, the change you suggest won't systematically achieve that, and there's really no way to achieve that. (After all, the host or the containers might not even be using a Debian-based distribution.) Maybe there's some other approach? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1049995: openssh: catalan translation [INTL:ca]
On Fri, Aug 18, 2023 at 04:37:50AM +0200, Pablo Huguet wrote: > I did the catalan translation of it, and I will add the translation is > included > thanks for reading! Hi, Thanks for the translation! However, it contains syntax errors: $ msgmerge -U debian/po/ca.po debian/po/templates.pot debian/po/ca.po:41:59: syntax error debian/po/ca.po:57:27: syntax error msgmerge: found 2 fatal errors Could you please fix these? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1056590: dh_movetousr: consider updating symlink targets
Package: debhelper Version: 13.11.4 Severity: normal X-Debbugs-Cc: Helmut Grohne Owner: Helmut Grohne I tried adding "Build-Depends: dh-sequence-movetousr" to parted. The build was apparently successful, but lintian warned me: W: libparted-fs-resize0: lacks-unversioned-link-to-shared-library example: usr/lib/x86_64-linux-gnu/libparted-fs-resize.so [usr/lib/x86_64-linux-gnu/libparted-fs-resize.so.0.0.5] W: libparted2: lacks-unversioned-link-to-shared-library example: usr/lib/x86_64-linux-gnu/libparted.so [usr/lib/x86_64-linux-gnu/libparted.so.2.0.5] This is because libparted-dev has a /usr/lib/x86_64-linux-gnu/libparted.so -> /lib/x86_64-linux-gnu/libparted.so.2 symlink (and similar for libparted-fs-resize.so), but libparted2 now ships /usr/lib/x86_64-linux-gnu/libparted.so.2 instead. Technically this is fine since the /lib -> /usr/lib symlink is now mandatory, but lintian apparently doesn't know that, and I think it's rather confusing. We ought to either change lintian to not warn about this, or change dh_movetousr to fix up the symlinks; either way, developers shouldn't see a warning here. Talking to Helmut at the mini-Debconf in Cambridge, we went back and forth a bit but his gut feeling appeared to be that it would make sense to at least experiment with having dh_movetousr update symlink targets, so I'm filing this bug as a reminder. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1054098: base-passwd: Fix non-linux build
On Tue, Oct 17, 2023 at 01:12:46AM +0200, Samuel Thibault wrote: > I tried to build base-passwd on hurd-amd64, but this change > > Make it possible to configure whether to use SELinux or not. > > broke the non-Linux builds. Here is a patch to fix this. I used my preferred spelling of the variable name, but otherwise applied. Thanks! -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1041731: Hyphens in man pages
My plan, as indicated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041731#62, had been to leave things much as they are for most of the period while trixie is in development, and then put the ".char - \-" etc. workarounds back in place for nroff output for trixie's release; this would have meant a higher chance of more manual page authoring tools being updated to handle the groff input language more strictly (although this isn't always easy, as Russ has indicated, since sometimes the input languages of those tools are less rich than groff). However, after wading through an enormous amount of inordinately verbose stuff in my inbox about this, I'm afraid I've now lost patience with the whole thing and am definitely not willing to put up with it for another year or more, so I'm putting the workaround back in place now. Sorry to anyone who will end up dissatisfied by non-terminal printed output as a result. https://salsa.debian.org/debian/groff/-/commit/d5394c68d7 It is still true that being strict about the use of the "\-", "\[aq]", "\[ga]", "\[ha]", and "\[ti]" escape sequences (as opposed to "-", "'", "`", "^", and "~" respectively) will produce better printed output. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1053924: timew: autopkgtests fail with man-db 2.12.0
Source: timew Version: 1.5.0+ds.1-1 Severity: important Tags: patch In response to https://gitlab.com/man-db/man-db/-/issues/17, I changed the mandb program in man-db 2.12.0 to issue a warning if it's run without the -u/--user-db option but doesn't have the necessary permissions to write to system databases. This caused timew's autopkgtests to fail due to the extra text on stderr. The following patch fixes it. diff --git a/debian/tests/timewarrior b/debian/tests/timewarrior index 53bea1c..dcd6021 100644 --- a/debian/tests/timewarrior +++ b/debian/tests/timewarrior @@ -11,7 +11,7 @@ mkdir src ln -s /usr/bin/timew src/timew # regen man DB, since the tests use it -mandb +mandb -u cd test # requires compilation Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1015754: man-db: man should hint about uninstalled manpages
On Wed, Jul 20, 2022 at 05:05:03PM +0200, Martin Quinson wrote: > It would be great if man-db could hint about uninstalled manpages. One > possible > use-case would be when requesting the manpage of pthread_mutex_create when > glibc-doc is not installed. > > Right now, it displays: "No manual entry for pthread_mutex_create" > > My idea is that it would be much more user-friendly to display something like > "The manual entry of pthread_mutex_create is not available. Please install the > package glibc-doc to retrieve it." > > I understand that the information requires a global knowledge over the archive > and that it will be outdated very easily. I still think that it'd be a good > improvement for our users to provide this information. Several implementations > are possible, such as an external package providing the information about all > existing packages in the Debian archive. It should be possible to keep it > kinda > up to date in testing, and almost perfectly up to date in stable, I think. > > I would be interested in helping here, but I first need to know about your > feeling about this feature. There is no point thinking of an infrastructure to > retrieve the info if you don't want to include this feature at the end. I agree it would be helpful to have such a feature. My first instinct is that it would make a lot of sense to work rather similarly to command-not-found or AppStream, ideally sharing infrastructure if possible; it would be a shame to have to add another piece of infrastructure like that when there are at least two that already exist and are somewhat similar. (I think the approach of having to keep a package up-to-date in the archive with all the data is a rather old-fashioned one that we should try to avoid if possible.) The job is a bit harder than for today's command-not-found though, because it would need to handle things like .so links in manual pages that can't be derived solely from file names. Maybe it would make sense for debhelper to scan pages at package build time and add control fields, or perhaps something like the machinery that builds the AppStream catalog could run lexgrog over everything and see what names it reports. Anyway, in terms of what could be done in man-db, I think I'd be willing to add some kind of simple hook interface along the lines of bash's command_not_found_handle, and then something could be plugged into that. I don't think I have time to work on the infrastructure for implementing such a hook, but I do have some experience with implementing this sort of thing in Ubuntu and would be happy to give advice on things that seem like they'd fit most easily into archive infrastructure (both in Ubuntu's which I know professionally, and in what I know of Debian's). Thanks, and sorry for the slow response, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1052462: parted: libparted2 package dependencies (dmidecode) differ between arm64 and amd64
On Fri, Sep 22, 2023 at 03:41:53PM +0100, Phil Roche wrote: > While working on new arm64 Ubuntu 23.10 Mantic minimal cloud images > (http://cloud-images.ubuntu.com/minimal/daily/mantic/) we discovered that > `dmidecode` was not being installed in the arm64 images. > > In debugging, I found that the package dependencies of the libparted2 > package > differ between arm64 and amd64. arm64 `libparted2` does not depend on > `dmidecode` but on amd64 it does. This is intentional, because libparted only uses dmidecode for identifying old Intel Macs with special GPT quirks, and that's only relevant on x86. I don't personally see why this needs to be extended to arm64, although of course if somebody comes forward and explicitly confirms that it's relevant to partitioning on Apple Silicon or whatever then we could do that - but I wouldn't do it just for architectural symmetry. If you explicitly need dmidecode to be on your images, then I think you should have an explicit dependency or similar to ensure that, rather than relying on a dependency via libparted (which is an implementation detail). Is that a problem? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1052221: man-db: cache cleanup race
Control: tag -1 fixed-upstream On Tue, Sep 19, 2023 at 10:13:24AM +0200, Ferenc Wágner wrote: > I suppose this happened because the cleanup prescribed by > /usr/lib/tmpfiles.d/man-db.conf and the "manual" cleanup implemented by > the find call in /lib/systemd/system/man-db.service ran concurrently. > This results in man-db.service spuriously entering failed state, > triggering false monitoring alarms. Please avoid this by choosing one > cleanup method only (if the above analysis is correct). Thanks for your report and analysis. I feel like I must have had a reason for including both, but I can't think what it was, so I may just have been wrong. I've pushed https://gitlab.com/man-db/man-db/-/commit/ef9baff127 to fix this for the next upstream release. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1052150: bullseye-pu: package openssh/1:8.4p1-5+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: open...@packages.debian.org
Control: affects -1 + src:openssh
[ Reason ]
https://bugs.debian.org/1042460 is a security issue affecting bullseye.
The security team doesn't think it warrants a DSA, but thinks it's worth
fixing in a point release. I agree.
[ Impact ]
Forwarding an SSH agent to a remote system may be exploitable by
administrators of that remote system in complicated conditions. See
https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh-forwarded-ssh-agent.txt.
[ Tests ]
I have tested this manually as far as I'm able to do so. Essentially,
this shuts down the exploit at the first hurdle by refusing to load
objects that don't appear to be valid FIDO/PKCS#11 modules intended for
use by ssh-agent.
[ Risks ]
The code isn't quite trivial, but it's fairly straightforward once you
understand what it's doing.
The second upstream patch in the series wasn't in OpenSSH 9.3p2 (the
initial upstream release addressing this vulnerability), but I think
it's worth taking anyway because it shuts down a range of clever attacks
along these same lines without introducing an unreasonable amount of
extra complexity. Ubuntu did the same thing in their security updates
for this.
I wasn't able to backport the other part of upstream's fix for this
(disallowing remote addition of FIDO/PKCS#11 keys by default), because
that relies on the mechanism in
https://www.openssh.com/agent-restrict.html and bullseye doesn't have
that.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
See attached debdiff.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru openssh-8.4p1/debian/.git-dpm openssh-8.4p1/debian/.git-dpm
--- openssh-8.4p1/debian/.git-dpm 2022-07-01 23:37:41.0 +0100
+++ openssh-8.4p1/debian/.git-dpm 2023-09-17 23:46:46.0 +0100
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-ed99ef256258d8556dbe39d976c2528ede050f14
-ed99ef256258d8556dbe39d976c2528ede050f14
+fb685ebb9f8391ab2836715c9c347ee50a0c9f48
+fb685ebb9f8391ab2836715c9c347ee50a0c9f48
2b2c99658e3e8ed452e28f88f9cdbcdfb2a461cb
2b2c99658e3e8ed452e28f88f9cdbcdfb2a461cb
openssh_8.4p1.orig.tar.gz
diff -Nru openssh-8.4p1/debian/changelog openssh-8.4p1/debian/changelog
--- openssh-8.4p1/debian/changelog 2022-07-01 23:37:41.0 +0100
+++ openssh-8.4p1/debian/changelog 2023-09-17 23:46:46.0 +0100
@@ -1,3 +1,12 @@
+openssh (1:8.4p1-5+deb11u2) bullseye; urgency=medium
+
+ * Cherry-pick from OpenSSH 9.3p2:
+- [CVE-2023-38408] Fix a condition where specific libraries loaded via
+ ssh-agent(1)'s PKCS#11 support could be abused to achieve remote code
+ execution via a forwarded agent socket (closes: #1042460).
+
+ -- Colin Watson Sun, 17 Sep 2023 23:46:46 +0100
+
openssh (1:8.4p1-5+deb11u1) bullseye; urgency=medium
* Backport from upstream:
diff -Nru openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch
openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch
--- openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch 1970-01-01
01:00:00.0 +0100
+++ openssh-8.4p1/debian/patches/CVE-2023-38408-1.patch 2023-09-17
23:46:46.0 +0100
@@ -0,0 +1,30 @@
+From 8175e38eaf5636f45c3f27f4eadee1d583b70d35 Mon Sep 17 00:00:00 2001
+From: Damien Miller
+Date: Thu, 13 Jul 2023 12:09:34 +1000
+Subject: terminate pkcs11 process for bad libraries
+
+Origin: upstream,
https://anongit.mindrot.org/openssh.git/commit/?id=b23fe83f06ee7e721033769cfa03ae840476d280
+Last-Update: 2023-09-17
+
+Patch-Name: CVE-2023-38408-1.patch
+---
+ ssh-pkcs11.c | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
+index f495883d1..d864051c4 100644
+--- a/ssh-pkcs11.c
b/ssh-pkcs11.c
+@@ -1519,10 +1519,8 @@ pkcs11_register_provider(char *provider_id, char *pin,
+ error("dlopen %s failed: %s", provider_id, dlerror());
+ goto fail;
+ }
+- if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL) {
+- error("dlsym(C_GetFunctionList) failed: %s", dlerror());
+- goto fail;
+- }
++ if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL)
++ fatal("dlsym(C_GetFunctionList) failed: %s", dlerror());
+ p = xcalloc(1, sizeof(*p));
+ p->name = xstrdup(provider_id);
+ p->handle = handle;
diff -Nru openssh-8.4p1/debian/patches/CVE-2023-38408-2.patch
openssh-8.4p1/debian/patches/CVE-2023-38408-2.patch
--- openssh-8.4p1/debian/patches/CVE-2023-38408-2.patch 1970-01-01
01:00:00.0 +0100
+++ openssh-8.4p1/debian/patches/CVE-2023-38408-2.p
Bug#1052149: bookworm-pu: package openssh/1:9.2p1-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: open...@packages.debian.org
Control: affects -1 + src:openssh
[ Reason ]
https://bugs.debian.org/1042460 is a security issue affecting bookworm.
The security team doesn't think it warrants a DSA, but thinks it's worth
fixing in a point release. I agree.
[ Impact ]
Forwarding an SSH agent to a remote system may be exploitable by
administrators of that remote system in complicated conditions. See
https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh-forwarded-ssh-agent.txt.
[ Tests ]
I have tested this manually as far as I'm able to do so. Essentially,
this shuts down the exploit at the first hurdle by refusing to load
objects that don't appear to be valid FIDO/PKCS#11 modules intended for
use by ssh-agent, and by disallowing remote addition of FIDO/PKCS#11
keys by default.
[ Risks ]
The code isn't quite trivial, but it's fairly straightforward once you
understand what it's doing.
The third upstream patch in the series wasn't in OpenSSH 9.3p2 (the
initial upstream release addressing this vulnerability), but I think
it's worth taking anyway because it shuts down a range of clever attacks
along these same lines without introducing an unreasonable amount of
extra complexity. Ubuntu did the same thing in their security updates
for this.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
See attached debdiff.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru openssh-9.2p1/debian/.git-dpm openssh-9.2p1/debian/.git-dpm
--- openssh-9.2p1/debian/.git-dpm 2023-02-08 10:43:07.0 +
+++ openssh-9.2p1/debian/.git-dpm 2023-09-17 21:23:50.0 +0100
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-74edce484429249265baaee1e8a5d1785ee7afa7
-74edce484429249265baaee1e8a5d1785ee7afa7
+29c7785a3673101b3af8f6f712795fa128e52ddd
+29c7785a3673101b3af8f6f712795fa128e52ddd
cf3c3acb2b8f74eeca7fcee269b1d33ac83f1188
cf3c3acb2b8f74eeca7fcee269b1d33ac83f1188
openssh_9.2p1.orig.tar.gz
diff -Nru openssh-9.2p1/debian/changelog openssh-9.2p1/debian/changelog
--- openssh-9.2p1/debian/changelog 2023-02-08 10:43:07.0 +
+++ openssh-9.2p1/debian/changelog 2023-09-17 21:23:50.0 +0100
@@ -1,3 +1,12 @@
+openssh (1:9.2p1-2+deb12u1) UNRELEASED; urgency=medium
+
+ * Cherry-pick from OpenSSH 9.3p2:
+- [CVE-2023-38408] Fix a condition where specific libraries loaded via
+ ssh-agent(1)'s PKCS#11 support could be abused to achieve remote code
+ execution via a forwarded agent socket (closes: #1042460).
+
+ -- Colin Watson Sun, 17 Sep 2023 21:23:50 +0100
+
openssh (1:9.2p1-2) unstable; urgency=medium
* Fix mistakenly-unreleased entry for 1:9.2p1-1 in debian/NEWS.
diff -Nru openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch
openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch
--- openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch 1970-01-01
01:00:00.0 +0100
+++ openssh-9.2p1/debian/patches/CVE-2023-38408-1.patch 2023-09-17
21:23:50.0 +0100
@@ -0,0 +1,30 @@
+From dee3878689aef5365955442869be02d420b65ea6 Mon Sep 17 00:00:00 2001
+From: Damien Miller
+Date: Thu, 13 Jul 2023 12:09:34 +1000
+Subject: terminate pkcs11 process for bad libraries
+
+Origin: upstream,
https://anongit.mindrot.org/openssh.git/commit/?id=b23fe83f06ee7e721033769cfa03ae840476d280
+Last-Update: 2023-09-17
+
+Patch-Name: CVE-2023-38408-1.patch
+---
+ ssh-pkcs11.c | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
+index b2e2b32a5..9e48c134e 100644
+--- a/ssh-pkcs11.c
b/ssh-pkcs11.c
+@@ -1537,10 +1537,8 @@ pkcs11_register_provider(char *provider_id, char *pin,
+ error("dlopen %s failed: %s", provider_id, dlerror());
+ goto fail;
+ }
+- if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL) {
+- error("dlsym(C_GetFunctionList) failed: %s", dlerror());
+- goto fail;
+- }
++ if ((getfunctionlist = dlsym(handle, "C_GetFunctionList")) == NULL)
++ fatal("dlsym(C_GetFunctionList) failed: %s", dlerror());
+ p = xcalloc(1, sizeof(*p));
+ p->name = xstrdup(provider_id);
+ p->handle = handle;
diff -Nru openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch
openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch
--- openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch 1970-01-01
01:00:00.0 +0100
+++ openssh-9.2p1/debian/patches/CVE-2023-38408-2.patch 2023-09-17
21:23:50.0 +0100
@@ -0,0 +1,104 @@
+From 5c06b89189eb27f692b900526d60bf744918511e Mon Sep 17 00:00:00 2001
+From: Damie
Bug#1050089: bootstrap tries to search for gnulib PO files in spite of '--skip-po'
Control: tag -1 fixed-upstream On Sat, Aug 19, 2023 at 03:52:35PM +, Bjarni Ingi Gislason wrote: > bootstrapping with --no-git --gnulib-srcdir=/home/bg/git/gnulib --skip-po > --bootstrap-sync In general, this is an "if it breaks, you get to keep both pieces" set of options. However, it probably does make sense to provide a way to suppress the downloads performed by gnulib-tool here, so I've done that for the next upstream release: https://gitlab.com/man-db/man-db/-/commit/b403f6d413 -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1041731: groff-base: "-" mapped as HYPHEN
Control: severity -1 serious On Mon, Aug 14, 2023 at 02:18:51PM +0200, Samuel Thibault wrote: > As in: maybe we can leave the symptom open until the freeze period, so > that developers notice the issue and fix their bugs, and on the freeze > period, introduce the workaround so that end users of the eventual > released distribution don't get affected while we are still fixing the > bugs. This is more or less exactly my plan, but I'd prefer to leave it the way it is for a while to shake out some of the problems. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1043360: ITP: python-poetry-dynamic-versioning -- dynamic versioning plugin for Poetry
On Wed, Aug 09, 2023 at 04:16:29PM +0200, Jakub Ružička wrote: > * Package name: python-poetry-dynamic-versioning > Version : 0.25.0 > Upstream Contact: Matthew T. Kennerly > * URL : https://github.com/mtkennerly/poetry-dynamic-versioning > * License : Expat > Programming Lang: Python > Description : dynamic versioning plugin for Poetry > > This is a Python plugin for Poetry and Poetry Core to enable dynamic > versioning based on tags in your version control system, powered by Dunamai. > Many different version control systems are supported, including Git and > Mercurial. > > > Poetry is very popular in the Python world and this plugin makes it easy to > use dynamic versioning in Poetry-managed projects. > > Having this in Debian is a prerequisite for packaging of any projects using > poetry-dynamic-versioning. Some of existing packages require this in order to > update to latest upstream version which started using the plugin. How will this sort of thing work when a git tree isn't necessarily available at binary package build time, since buildds build binary packages from a source package rather than directly from git and the source package doesn't usually include a git tree? Is it just a matter of causing the plugin to exist so that pybuild doesn't fail, but in practice the version is still going to be set by something that's actually in the source package? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1043256: man.local: missing font transformation for 'C'
Control: reassign -1 zip On Mon, Aug 07, 2023 at 08:02:11PM -0500, G. Branden Robinson wrote: > In my opinion, this bug should be reassigned to the zip package. Agreed. Reassigning there. > Also, the correct term is "font translation", not "font transformation". > > https://www.gnu.org/software/groff/manual/groff.html.node/Selecting-Fonts.html > > At 2023-08-07T22:11:43+, Bjarni Ingi Gislason wrote: > > Package: man-db > > Version: 2.11.2-3 > > Severity: normal > > > > Dear Maintainer, > > man zip > /dev/null > > > >* What was the outcome of this action? > > > > troff::175: warning: cannot select font 'C' > > ... > > Can reproduce. This warning occurs many times, along with two others. > > troff:zip.1:1675: warning: cannot select font 'N' > troff:zip.1:2636: warning: escape character ignored before 'i' > > These two appear to be due to typos. > > >* What outcome did you expect instead? > > > > No warnings. > > These messages arise due to errors in the page sources; the formatter is > unable to do what is being asked of it. > > > File "/etc/groff/man.local" needs a font transformation > > > > .if n .ftr C R > > Colin Watson rejected this idea when Python docutils-generated man pages > exhibited the same problem. This issue has now been fixed upstream in > python-docutils--the right place, in my opinion--and uploaded to Debian. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041809 > > zip(1) appears to have been composed directly by a human. The page is > (strictly speaking) buggy, and use of the `\fC` escape sequence is not > portable across *roff implementations. It is also ineffectual on > terminal output devices regardless of implementation. > > There are a number of related problems here. > > * It's impossible to change font family or type size in an nroff > document. Nevertheless, it is attempted commonly enough that GNU > troff (and all other troffs I know of) silently ignore such attempts. > * Not all troffs even support the _concept_ of "font families"; you will > not find it in Ossanna troff or Kernighan troff. > * Portable man pages must use only fonts named `R`, `I`, and `B`. It is > consequently better to use man(7)'s facilities for switching fonts. > * Even on typesetting devices, a font named `C` is not guaranteed to > exist. As far as I can tell from my research over the years, this > font name was never supported by the troff in BSD Unix until it > replaced its AT troff with GNU troff. > * AT device-independent troff, in lines of descent from Kernighan > troff (ca. 1980), _sometimes_ supported a font named `C`. Sometimes > it was called `CW` instead. Sometimes both were available. Sometimes > it wasn't available at all. > * There is no portable interface for testing the availability of a font > in the output device. GNU troff supports `.if F` for this purpose; > AT troff and at least some of its descendants do not. > > It appears to me that in most or all cases, zip(1) uses this 'C' font > mark up literal input, like examples of command-line usage, on their own > output lines. That's good, because it suggests that the page can easily > migrate to the EX/EE man(7) extension, first developed in Research Ninth > Edition Unix (1986) and adopted by groff in 2007-2009. > > To retain portability, since Info-ZIP likely wants to retain support for > a huge variety of systems, the page could take the approach recently > adopted by lexgrog(1) in the man-db project. > > It looks like the upstream package hasn't been updated in 15 years. I'm > happy to prepare some patches to improve its man pages for the Debian > package. It looks like most of the corrections relevant to this bug > report can be straightforwardly automated with sed(1). > > I'm also happy to contribute some further correctness and portability > issues to the page per groff_man_style(7). > > Let me know. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1042358: openvswitch: FTBFS: make[3]: *** [Makefile:6743: manpage-check] Error 1
On Mon, Aug 07, 2023 at 04:45:30PM +0200, Thomas Goirand wrote:
> Ok, so if there's only 5 patches, not 6, then I should be able to manage
> (even though it's not the best convenient way). Thanks for your patches.
I think I possibly understand what you meant now. Is this more
convenient?
--
Colin Watson (he/him) [cjwat...@debian.org]
>From 45a2a2245f6c73dc6898f63c8d30ffd138920066 Mon Sep 17 00:00:00 2001
From: Colin Watson
Date: Fri, 4 Aug 2023 18:22:31 +0100
Subject: [PATCH v2 0/5] docs: Fix manpage-check warnings with groff 1.23.0
https://bugs.debian.org/1042358 reported a manpage-check failure with
groff 1.23.0 in Debian testing/unstable. Fixing the immediate mistake
here exposed a few other issues in how the tables in ovs-fields(7) are
rendered.
Colin Watson (5):
docs: Wrap more table entries in text blocks
docs: Shorten overly-wide table heading
docs: Tweak width of name column in field property tables
docs: Fix rendering of VLAN Comparison Chart
docs: Run tbl preprocessor in manpage-check rule
Makefile.am | 2 +-
build-aux/extract-ofp-fields | 20 ++--
lib/meta-flow.xml| 25 +
3 files changed, 28 insertions(+), 19 deletions(-)
--
2.39.2
>From 97fb673b2b09747beabe8625ac86dbfc5aa0c023 Mon Sep 17 00:00:00 2001
From: Colin Watson
Date: Fri, 4 Aug 2023 11:19:06 +0100
Subject: [PATCH v2 1/5] docs: Wrap more table entries in text blocks
This fixes a number of "table wider than line length minus indentation"
warnings from tbl. The table cells are too narrow for centered text to
look good, so left-align the contents of the text blocks.
Reported-by: Lucas Nussbaum
Reported-at: https://bugs.debian.org/1042358
Signed-off-by: Colin Watson
---
build-aux/extract-ofp-fields | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index efec59c25..2f566d2b9 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -189,12 +189,14 @@ def field_to_xml(field_node, f, body, summary):
ovs_version = [int(x) for x in ovs_version_s.split(".")]
if min_ovs_version is None or ovs_version < min_ovs_version:
min_ovs_version = ovs_version
-summary += ["\\fB%s\\fR" % f["name"]]
+summary += ["T{\n.ad l\n\\fB%s\\fR" % f["name"]]
if f["extra_name"]:
summary += [" aka \\fB%s\\fR" % f["extra_name"]]
-summary += [";%d" % f["n_bytes"]]
+summary += ["\nT}"]
+summary += [";T{\n.ad l\n%d" % f["n_bytes"]]
if f["n_bits"] != 8 * f["n_bytes"]:
summary += [" (low %d bits)" % f["n_bits"]]
+summary += ["\nT}"]
summary += [";%s;" % {"MFM_NONE": "no", "MFM_FULLY": "yes"}[f["mask"]]]
summary += ["%s;" % {True: "yes", False: "no"}[f["writable"]]]
summary += ["%s;" % f["prereqs"]]
@@ -203,7 +205,7 @@ def field_to_xml(field_node, f, body, summary):
support += ["OF %s+" % VERSION_REVERSE[min_of_version]]
if min_ovs_version is not None:
support += ["OVS %s+" % ".".join([str(x) for x in min_ovs_version])]
-summary += " and ".join(support)
+summary += ["T{\n.ad l\n", " and ".join(support), "\nT}"]
summary += ["\n"]
# Full description.
@@ -230,8 +232,10 @@ l lx.
body += ["Width:;"]
if f["n_bits"] != 8 * f["n_bytes"]:
body += [
+"T{\n",
"%d bits (only the least-significant %d bits "
-"may be nonzero)" % (f["n_bytes"] * 8, f["n_bits"])
+"may be nonzero)" % (f["n_bytes"] * 8, f["n_bits"]),
+"\nT}",
]
elif f["n_bits"] <= 128:
body += ["%d bits" % f["n_bits"]]
--
2.39.2
>From 36207097b0c3de75d562b93e666c54f954da763c Mon Sep 17 00:00:00 2001
From: Colin Watson
Date: Fri, 4 Aug 2023 18:01:55 +0100
Subject: [PATCH v2 2/5] docs: Shorten overly-wide table heading
Using "NXM/OXM Support" makes these tables a little too wide to fit well
when rendered in 80 columns, causing warnings from groff. There's
already some abbreviation going on here (e.g. "RW?"), so "NXM/OXM?"
seems acceptable.
Reported-by: Lucas Nussbaum
Reported-at: https://bugs.debian.org/1042358
Signed-off-by: Colin Watson
---
build-aux/extract-ofp-fields | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/build-aux/extract-ofp-fiel
Bug#1042358: openvswitch: FTBFS: make[3]: *** [Makefile:6743: manpage-check] Error 1
On Mon, Aug 07, 2023 at 10:54:52AM +0200, Thomas Goirand wrote: > I very much appreciate that you've sent patches for this bug, thanks for > this. However, it is difficult to apply your patches because they are sent > inline, and therefore hard to save on disk. Also, I would have done the work > by hand to avoid annoying you, but your "Message part 2" doesn't contain > the patch at all, only a diffstat. > > Could you send me the 6 patches as separate files, so I could more easily > add them to debian/patches? Or at least send the first patch that's > completely missing... I don't mind sending you patches in a different format if it's helpful, but I'm confused; I _did_ send them as separate files, MIME-encapsulated. How else would I have sent them as separate files? The "PATCH v2 0/5" message is a cover letter for the patch set. It's not supposed to contain a patch itself. Cheers, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1041704: $MANWIDTH does not overwrite explicit line length in "~/.manpath"
Control: tag -1 fixed-upstream
On Sun, Jul 23, 2023 at 12:23:58AM +0100, Colin Watson wrote:
> On Sat, Jul 22, 2023 at 01:10:23PM +, Bjarni Ingi Gislason wrote:
> > In my ".manpath" for "nroff" was:
> >
> > DEFINE nroff test-nroff -b -ww -mandoc -rF=0 -P-i -rHY=0 -dAD=l
> > -rCHECKSTYLE=0 -rLL=90m
> >
> > Changing the line length with, say "export MANWIDTH=80", had no effect.
>
> I believe this can be fixed as follows:
>
> diff --git a/src/man.c b/src/man.c
> index 70d0dc7a..68515eed 100644
> --- a/src/man.c
> +++ b/src/man.c
> @@ -685,8 +685,7 @@ static int get_roff_line_length (void)
> {
> int line_length = cat_width ? cat_width : get_line_length ();
>
> - /* groff >= 1.18 defaults to 78. */
> - if ((!troff || ditroff) && line_length != 80) {
> + if (!troff || ditroff) {
> int length = line_length * 39 / 40;
> if (length > line_length - 2)
> return line_length - 2;
>
> This may be the right thing to do. However, it will mean that the -rLL
> in your ~/.manpath is always overridden, so I don't understand why
> you're going to the effort of specifying it explicitly in the first
> place if you want it to be overridden. Can you explain why you're doing
> this?
In the absence of feedback, I've gone ahead and committed this upstream,
since it doesn't seem to make sense for the -rLL to be overridden if and
only if the requested width is 80 columns.
https://gitlab.com/man-db/man-db/-/commit/39cdee4ada
--
Colin Watson (he/him) [cjwat...@debian.org]
