Bug#1071822: libseccomp2: missing support for newer syscalls like fchmodat2 in bookworm(-backports)
Control: fixed -1 libseccomp/2.5.5-1 Hi, On 25.05.24 08:48, Tianon Gravi wrote: Source: libseccomp Version: 2.5.4-1 Severity: normal X-Debbugs-Cc: tia...@debian.org Hi! When using Docker in bookworm (current stable) and trying to run containers based on newer distributions (like the recently released Alpine 3.20), they will sometimes attempt to invoke newer syscalls like fchmodat2. Due to the way syscalls that libseccomp does not know about interact with Docker's seccomp profiles, these sometimes get EPERM instead of ENOSYS like they should, which breaks their fallback. Is there any chance of getting these newer syscalls into some version in bookworm? (backports is very acceptable, but it *seems* like this might be appropriate for a stable update too? I very much defer to your wisdom/experience! <3) I think this is suitable for a stable update. At least I've pushed the same kind of change to bullseye. I've opened #1071920 for the release team. I think you're probably already way more aware than I am, but from my own look at the changes in the 2.5.5 upstream release, they're pretty minimal (a few typo fixes and the desired syscall table updates [1]), so perhaps 2.5.5 would be appropriate/sufficient and it's not necessary to backport the patch by itself While the source changes of 2.5.5 look reasonably small, it looks different when you diff the tarballs with pre-generated C and autotools files. That's why I prefer to cherry-pick the commit. Cheers, Felix
Bug#1071920: bookworm-pu: package libseccomp/2.5.4-1+deb12u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bookworm Severity: normal [ Reason ] libseccomp 2.5.4 only knows about syscall up to Linux 6.4. The proposed changes add the syscalls up to Linux 6.7. [ Impact ] Syscalls for Linux 6.5 to 6.7 can't be allowed. Software built with support for newer kernels (often the case in containers) expect newer syscalls to work or return ENOSYS. If that syscall is not supported by libseccomp and a default filter action of returning EPERM is used, such software will break. Therefore you often need to be able to allow a syscall even when the running kernel doesn't support it. [ Tests ] * autopkgtest passes on amd64 * Verified adding a filter for the fchmodat2() syscall works (new in 6.6) * Verified that systemd and Docker run [ Risks ] The changes only extend the syscall csv table and add new syscall defines. [ 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 ] Cherry-pick upstream commit to support new syscalls.diff -Nru libseccomp-2.5.4/debian/changelog libseccomp-2.5.4/debian/changelog --- libseccomp-2.5.4/debian/changelog 2022-04-21 22:23:12.0 +0200 +++ libseccomp-2.5.4/debian/changelog 2024-05-25 20:36:52.0 +0200 @@ -1,3 +1,9 @@ +libseccomp (2.5.4-1+deb12u1) bookworm; urgency=medium + + * Add support for syscalls up to Linux 6.7. (Closes: #1071822) + + -- Felix Geyer Sat, 25 May 2024 20:36:52 +0200 + libseccomp (2.5.4-1) unstable; urgency=medium * New upstream release. diff -Nru libseccomp-2.5.4/debian/patches/series libseccomp-2.5.4/debian/patches/series --- libseccomp-2.5.4/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.4/debian/patches/series 2024-05-25 20:08:25.0 +0200 @@ -0,0 +1 @@ +update_the_syscall_table_for_Linux_v6.7-rc3.patch diff -Nru libseccomp-2.5.4/debian/patches/update_the_syscall_table_for_Linux_v6.7-rc3.patch libseccomp-2.5.4/debian/patches/update_the_syscall_table_for_Linux_v6.7-rc3.patch --- libseccomp-2.5.4/debian/patches/update_the_syscall_table_for_Linux_v6.7-rc3.patch 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.4/debian/patches/update_the_syscall_table_for_Linux_v6.7-rc3.patch 2024-05-25 20:06:55.0 +0200 @@ -0,0 +1,129 @@ +From 53267af3fb56eed93a50b8ef92f41825c97a7813 Mon Sep 17 00:00:00 2001 +From: Paul Moore +Date: Fri, 5 May 2023 14:03:38 -0400 +Subject: [PATCH] all: update the syscall table for Linux v6.7-rc3 + +Signed-off-by: Paul Moore +Signed-off-by: Tom Hromatka +--- + include/seccomp-syscalls.h | 17 + + src/syscalls.csv | 12 +--- + 2 files changed, 26 insertions(+), 3 deletions(-) + +diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +index ee467183..611c78db 100644 +--- a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +@@ -276,6 +276,7 @@ + #define __PNR_renameat-10242 + #define __PNR_riscv_flush_icache -10243 + #define __PNR_memfd_secret-10244 ++#define __PNR_map_shadow_stack-10245 + + /* + * libseccomp syscall definitions +@@ -401,6 +402,8 @@ + #define __SNR_cacheflush __PNR_cacheflush + #endif + ++#define __SNR_cachestat __NR_cachestat ++ + #define __SNR_capget __NR_capget + + #define __SNR_capset __NR_capset +@@ -595,6 +598,8 @@ + + #define __SNR_fchmodat__NR_fchmodat + ++#define __SNR_fchmodat2 __NR_fchmodat2 ++ + #ifdef __NR_fchown + #define __SNR_fchown __NR_fchown + #else +@@ -717,14 +722,20 @@ + + #define __SNR_futex __NR_futex + ++#define __SNR_futex_requeue __NR_futex_requeue ++ + #ifdef __NR_futex_time64 + #define __SNR_futex_time64__NR_futex_time64 + #else + #define __SNR_futex_time64__PNR_futex_time64 + #endif + ++#define __SNR_futex_wait __NR_futex_wait ++ + #define __SNR_futex_waitv __NR_futex_waitv + ++#define __SNR_futex_wake __NR_futex_wake ++ + #ifdef __NR_futimesat + #define __SNR_futimesat __NR_futimesat + #else +@@ -1075,6 +1086,12 @@ + + #define __SNR_madvise __NR_madvise + ++#ifdef __NR_map_shadow_stack ++#define __SNR_map_shadow_stack__NR_map_shadow_stack ++#else ++#define __SNR_map_shadow_stack__PNR_map_shadow_stack ++#endif ++ + #ifdef __NR_mbind + #define __SNR_mbind __NR_mbind + #else +diff --git a/src/syscalls.csv b/src/syscalls.csv +index ea13a0eb..b0da8e6e 100644 +--- a/src/syscalls.csv b/src/syscalls.csv +@@ -1,4 +1,4 @@ +-#syscall (v5.17.0 2022-04-05),x86,x86_64,x32,arm,aarch64,mips
Bug#1071920: bookworm-pu: package libseccomp/2.5.4-1+deb12u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bookworm Severity: normal [ Reason ] libseccomp 2.5.4 only knows about syscall up to Linux 6.4. The proposed changes add the syscalls up to Linux 6.7. [ Impact ] Syscalls for Linux 6.5 to 6.7 can't be allowed. Software built with support for newer kernels (often the case in containers) expect newer syscalls to work or return ENOSYS. If that syscall is not supported by libseccomp and a default filter action of returning EPERM is used, such software will break. Therefore you often need to be able to allow a syscall even when the running kernel doesn't support it. [ Tests ] * autopkgtest passes on amd64 * Verified adding a filter for the fchmodat2() syscall works (new in 6.6) * Verified that systemd and Docker run [ Risks ] The changes only extend the syscall csv table and add new syscall defines. [ 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 ] Cherry-pick upstream commit to support new syscalls.diff -Nru libseccomp-2.5.4/debian/changelog libseccomp-2.5.4/debian/changelog --- libseccomp-2.5.4/debian/changelog 2022-04-21 22:23:12.0 +0200 +++ libseccomp-2.5.4/debian/changelog 2024-05-25 20:36:52.0 +0200 @@ -1,3 +1,9 @@ +libseccomp (2.5.4-1+deb12u1) bookworm; urgency=medium + + * Add support for syscalls up to Linux 6.7. (Closes: #1071822) + + -- Felix Geyer Sat, 25 May 2024 20:36:52 +0200 + libseccomp (2.5.4-1) unstable; urgency=medium * New upstream release. diff -Nru libseccomp-2.5.4/debian/patches/series libseccomp-2.5.4/debian/patches/series --- libseccomp-2.5.4/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.4/debian/patches/series 2024-05-25 20:08:25.0 +0200 @@ -0,0 +1 @@ +update_the_syscall_table_for_Linux_v6.7-rc3.patch diff -Nru libseccomp-2.5.4/debian/patches/update_the_syscall_table_for_Linux_v6.7-rc3.patch libseccomp-2.5.4/debian/patches/update_the_syscall_table_for_Linux_v6.7-rc3.patch --- libseccomp-2.5.4/debian/patches/update_the_syscall_table_for_Linux_v6.7-rc3.patch 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.4/debian/patches/update_the_syscall_table_for_Linux_v6.7-rc3.patch 2024-05-25 20:06:55.0 +0200 @@ -0,0 +1,129 @@ +From 53267af3fb56eed93a50b8ef92f41825c97a7813 Mon Sep 17 00:00:00 2001 +From: Paul Moore +Date: Fri, 5 May 2023 14:03:38 -0400 +Subject: [PATCH] all: update the syscall table for Linux v6.7-rc3 + +Signed-off-by: Paul Moore +Signed-off-by: Tom Hromatka +--- + include/seccomp-syscalls.h | 17 + + src/syscalls.csv | 12 +--- + 2 files changed, 26 insertions(+), 3 deletions(-) + +diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +index ee467183..611c78db 100644 +--- a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +@@ -276,6 +276,7 @@ + #define __PNR_renameat-10242 + #define __PNR_riscv_flush_icache -10243 + #define __PNR_memfd_secret-10244 ++#define __PNR_map_shadow_stack-10245 + + /* + * libseccomp syscall definitions +@@ -401,6 +402,8 @@ + #define __SNR_cacheflush __PNR_cacheflush + #endif + ++#define __SNR_cachestat __NR_cachestat ++ + #define __SNR_capget __NR_capget + + #define __SNR_capset __NR_capset +@@ -595,6 +598,8 @@ + + #define __SNR_fchmodat__NR_fchmodat + ++#define __SNR_fchmodat2 __NR_fchmodat2 ++ + #ifdef __NR_fchown + #define __SNR_fchown __NR_fchown + #else +@@ -717,14 +722,20 @@ + + #define __SNR_futex __NR_futex + ++#define __SNR_futex_requeue __NR_futex_requeue ++ + #ifdef __NR_futex_time64 + #define __SNR_futex_time64__NR_futex_time64 + #else + #define __SNR_futex_time64__PNR_futex_time64 + #endif + ++#define __SNR_futex_wait __NR_futex_wait ++ + #define __SNR_futex_waitv __NR_futex_waitv + ++#define __SNR_futex_wake __NR_futex_wake ++ + #ifdef __NR_futimesat + #define __SNR_futimesat __NR_futimesat + #else +@@ -1075,6 +1086,12 @@ + + #define __SNR_madvise __NR_madvise + ++#ifdef __NR_map_shadow_stack ++#define __SNR_map_shadow_stack__NR_map_shadow_stack ++#else ++#define __SNR_map_shadow_stack__PNR_map_shadow_stack ++#endif ++ + #ifdef __NR_mbind + #define __SNR_mbind __NR_mbind + #else +diff --git a/src/syscalls.csv b/src/syscalls.csv +index ea13a0eb..b0da8e6e 100644 +--- a/src/syscalls.csv b/src/syscalls.csv +@@ -1,4 +1,4 @@ +-#syscall (v5.17.0 2022-04-05),x86,x86_64,x32,arm,aarch64,mips
Bug#1071197: ninja-build: 1.12 breaks chromium build
On 15.05.24 23:49, Andres Salomon wrote: Package: ninja-build Version: 1.12.1-1 Severity: serious Tags: affects -1 chromium X-Debbugs-Cc: Andres Salomon Chromium in unstable breaks with ninja-build 1.12. See here for example, where the same chromium version (124.0.6367.201-1) built fine on architectures where older ninja-build was available, but failed on newer ninja-build: https://buildd.debian.org/status/logs.php?pkg=chromium=amd64 https://buildd.debian.org/status/logs.php?pkg=chromium=armhf I've also verified in a sid chroot that 1.12.1-1 fails to build chromium 124.0.6367.207, but if I downgrade ninja-build to 1.11.1-2 then that same version of chromium successfully builds. I'll be investigating further to see if I can figure out whether the problem is a bug in chromium, gn, or ninja (and reassign accordingly if necessary). But in the meantime, I don't think it's a good idea for ninja-build to migrate to trixie just yet (hence the severity). This looks like https://issues.chromium.org/issues/336911498 Felix
Bug#1071197: ninja-build: 1.12 breaks chromium build
On 15.05.24 23:49, Andres Salomon wrote: Package: ninja-build Version: 1.12.1-1 Severity: serious Tags: affects -1 chromium X-Debbugs-Cc: Andres Salomon Chromium in unstable breaks with ninja-build 1.12. See here for example, where the same chromium version (124.0.6367.201-1) built fine on architectures where older ninja-build was available, but failed on newer ninja-build: https://buildd.debian.org/status/logs.php?pkg=chromium=amd64 https://buildd.debian.org/status/logs.php?pkg=chromium=armhf I've also verified in a sid chroot that 1.12.1-1 fails to build chromium 124.0.6367.207, but if I downgrade ninja-build to 1.11.1-2 then that same version of chromium successfully builds. I'll be investigating further to see if I can figure out whether the problem is a bug in chromium, gn, or ninja (and reassign accordingly if necessary). But in the meantime, I don't think it's a good idea for ninja-build to migrate to trixie just yet (hence the severity). This looks like https://issues.chromium.org/issues/336911498 Felix
Bug#1059315: tinyxml: CVE-2023-34194 CVE-2023-40462 CVE-2023-40458
Hi, On 30.12.23 16:06, Guilhem Moulin wrote: Control: tag -1 + patch Hi, I had a look at these issues for Buster (LTS). Unfortunately the upstream project appears to be inactive. On Fri, 22 Dec 2023 at 14:50:57 +0100, Moritz Mühlenhoff wrote: CVE-2023-34194[0]: | StringEqual in TiXmlDeclaration::Parse in tinyxmlparser.cpp in | TinyXML through 2.6.2 has a reachable assertion (and application | exit) via a crafted XML document with a '\0' located after | whitespace. I attach a patch for this. Felix, I can upload an NMU for sid if you'd like. Thanks for working on this! There are some minor changes staged in the salsa git repo. It would be good to include them as well. Feel free to push the patch to git and upload. Alternatively a merge request works as well of course. Cheers, Felix
Bug#1057693: valgrind: i386 vex x86->IR: unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26
On Fri, 8 Dec 2023 15:48:27 +0100 Emanuele Rocca wrote: > Hi Simon, > > On 2023-12-07 08:39, Simon Josefsson wrote: > > During debci autopkgtest of a new version of libgssglue on i386 I got > > a failure like this, which is fatal and execution halts. > > > > 117s vex x86->IR: unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26 > > The problem can be reproduced with valgrind 3.19 as well: > > $ autopkgtest --shell-fail libgssglue_0.8-1.dsc ~/Downloads/valgrind_3.19.0-1_i386.deb -- schroot sid-i386-sbuild > > [...] > > (sid-i386-sbuild)root@ariel:/tmp/autopkgtest.lmoplT/build.hLF/src# valgrind /usr/bin/gsasl 2>&1 | grep ^vex > vex x86->IR: unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26 > (sid-i386-sbuild)root@ariel:/tmp/autopkgtest.lmoplT/build.hLF/src# valgrind --version > valgrind-3.19.0 I'm pretty sure this is caused by glibc 2.37-13 valgrind's own testsuite fails with that version on i386: https://ci.debian.net/packages/v/valgrind/testing/i386/40850077/ #1057428 is a similar report and there are more autopkgtest failures on https://qa.debian.org/excuses.php?package=glibc Cheers, Felix
Bug#1057428: libseccomp ftbfs on i386
On 04.12.23 22:03, Matthias Klose wrote: Package: src:libseccomp Version: 2.5.4-2 Severity: serious Tags: sid trixie User: debian-pyt...@lists.debian.org Usertags: python3.12 libseccomp ftbfs on i386. probably not related to Python 3.12, but blocks the addition of Python 3.12 Seems like glibc 2.37-13 broke valgrind on i386: https://ci.debian.net/packages/v/valgrind/testing/i386/40527816/
Bug#1057428: libseccomp ftbfs on i386
On 04.12.23 22:03, Matthias Klose wrote: Package: src:libseccomp Version: 2.5.4-2 Severity: serious Tags: sid trixie User: debian-pyt...@lists.debian.org Usertags: python3.12 libseccomp ftbfs on i386. probably not related to Python 3.12, but blocks the addition of Python 3.12 Seems like glibc 2.37-13 broke valgrind on i386: https://ci.debian.net/packages/v/valgrind/testing/i386/40527816/
Bug#1055285: libseccomp misbehave on loong64
Hi, On 03.11.23 15:39, Miao Wang wrote: Package: libseccomp2 Version: 2.5.4-1+loong64 Severity: normal Tags: patch libseccomp2 in debian ports lonng64 cannot work properly because it is using a wrong mapping between syscall numbers and names, which can be reproduced by first installing package seccomp and then execute: ``` scmp_sys_resolver accept ``` The syscall number in the output is not correct, which should be 202 on loong64 architecture. Please report this to debian-loonga...@lists.debian.org instead since version 2.5.4-1+loong64 is not part of the Debian archive but added by the loongarch porter team. Felix
Bug#1051323: libseccomp: Please add support for loongarch64
Control: tags -1 - patch Hi, On 06.09.23 10:27, zhangdandan wrote: Would it be possible to include the support for LoongArch in the next upload? Your opinions are welcome. If you have any questions, you can contact me at any time. [1]:https://github.com/seccomp/libseccomp [2]:https://github.com/seccomp/libseccomp/pull/356 [3]:https://packages.debian.org/source/sid/libseccomp That's quite a large set of changes and they don't apply cleanly against v2.5.4. Therefore I'd prefer to wait until upstream has released v2.6.0 with LoongArch support. Best regards, Felix
Bug#1052785: marked as pending in golang-github-jinzhu-now
Control: tag -1 pending Hello, Bug #1052785 in golang-github-jinzhu-now reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-jinzhu-now/-/commit/fa9084aa580db10460f67684db88818ccbc0 Build-depend on tzdata-legacy (or older tzdata version) Closes: #1052785 (this message was generated automatically) -- Greetings https://bugs.debian.org/1052785
Bug#1052787: marked as pending in golang-github-mattn-go-sqlite3
Control: tag -1 pending Hello, Bug #1052787 in golang-github-mattn-go-sqlite3 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-mattn-go-sqlite3/-/commit/448a02fa5fd798dc833f99524a7bc2055f72890e Build-depend on tzdata-legacy (or older tzdata version) Closes: #1052787 (this message was generated automatically) -- Greetings https://bugs.debian.org/1052787
Bug#1052819: marked as pending in golang-github-mattn-go-runewidth
Control: tag -1 pending Hello, Bug #1052819 in golang-github-mattn-go-runewidth reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-mattn-go-runewidth/-/commit/3839ff3b053316621d85b16a488357ec693ea2b0 Fix building with unicode data 15.1.0 Closes: #1052819 (this message was generated automatically) -- Greetings https://bugs.debian.org/1052819
Bug#1037420: bookworm-pu: package systemd/252.11-1~deb12u1
Hi Luca, On Mon, 12 Jun 2023 15:33:45 +0100 Luca Boccassi wrote: > Dear Release Team, > > We would like to upload the latest stable point release of systemd 252 > to bookworm-p-u. Stable release branches are maintained upstream with > the intention of providing bug fixes only and no compatibility > breakages, and with automated non-trivial CI jobs that also cover > Debian and Ubuntu. This is the first upload to bookworm-p-u so this is > a pre-approval request. This stable update is affected by the regression (compared to what's in stable) described in #1040149 I saw you merged the fix [1] into the upstream 252 stable branch. Since the 12.1 deadline is approaching fast, are you planning to do another stable upload with that commit cherry-picked? Cheers, Felix [1] https://github.com/systemd/systemd-stable/commit/34e834f496338fdc2a8a8cc771cba4082079cf9a
Bug#1037420: bookworm-pu: package systemd/252.11-1~deb12u1
Hi Luca, On Mon, 12 Jun 2023 15:33:45 +0100 Luca Boccassi wrote: > Dear Release Team, > > We would like to upload the latest stable point release of systemd 252 > to bookworm-p-u. Stable release branches are maintained upstream with > the intention of providing bug fixes only and no compatibility > breakages, and with automated non-trivial CI jobs that also cover > Debian and Ubuntu. This is the first upload to bookworm-p-u so this is > a pre-approval request. This stable update is affected by the regression (compared to what's in stable) described in #1040149 I saw you merged the fix [1] into the upstream 252 stable branch. Since the 12.1 deadline is approaching fast, are you planning to do another stable upload with that commit cherry-picked? Cheers, Felix [1] https://github.com/systemd/systemd-stable/commit/34e834f496338fdc2a8a8cc771cba4082079cf9a
Bug#1035094: udev: /dev/serial/by-id/ symlinks not created anymore for USB devices
Package: udev Version: 247.3-7+deb11u2 Tags: bullseye Since udev 247.3-7+deb11u2 /dev/serial/by-id/* symlinks are not created anymore for USB serial devices. This is a regression from backporting udev-always-create-device-symlinks-for-USB-disks.patch It was fixed upstream by https://github.com/systemd/systemd/pull/25246 The diff doesn't apply cleanly because we don't have https://github.com/systemd/systemd-stable/commit/451ba55fecd8b494add2001b3ca3c1915c8fd655 Apply this commit and the PR fixes the issue for me. Felix
Bug#1035094: udev: /dev/serial/by-id/ symlinks not created anymore for USB devices
Package: udev Version: 247.3-7+deb11u2 Tags: bullseye Since udev 247.3-7+deb11u2 /dev/serial/by-id/* symlinks are not created anymore for USB serial devices. This is a regression from backporting udev-always-create-device-symlinks-for-USB-disks.patch It was fixed upstream by https://github.com/systemd/systemd/pull/25246 The diff doesn't apply cleanly because we don't have https://github.com/systemd/systemd-stable/commit/451ba55fecd8b494add2001b3ca3c1915c8fd655 Apply this commit and the PR fixes the issue for me. Felix
Bug#1033825: systemd-zram-generator: Not started automatically on install
Package: systemd-zram-generator Version: 1.1.2-2 systemd-zram-generator provides a default configuration for zram0 but doesn't start it automatically on package installation. It's only active after calling systemctl daemon-reload manually or rebooting. I think the package should call daemon-reload in its postinst script. Best regards, Felix
Bug#1033641: libseccomp failing to build from source on bookworm with python 3.11
On 29.03.23 10:28, Mayer, Dirk wrote: make[3]: Nothing to be done for 'install-data-am'. /usr/lib/python3/dist-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools. warnings.warn( /usr/lib/python3/dist-packages/setuptools/command/easy_install.py:146: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools. warnings.warn( TEST FAILED: /work/tmp/libseccomp_2.5.4-1/libseccomp-2.5.4/debian/tmp//usr/lib/python3.11/site-packages/ does NOT support .pth files This seems to happen because you have python3-setuptools installed but libseccomp doesn't build-depend on it. You should always build Debian packages in a minimal chroot. libseccomp uses distutils but the setuptools packages replaces the distutils module which results in this error. If you uninstall python3-setuptools the build should run fine. Once libseccomp switches to setuptools we need to fix the underlying problem though so I leave this bug open. Best regards, Felix
Bug#1003044: marked as pending in python-dateutil
Control: tag -1 pending Hello, Bug #1003044 in python-dateutil reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-dateutil/-/commit/963b19f968769247a62604bd0582131dc11d3329 Don't fall back on bundled zoneinfo database Closes: #1003044 (this message was generated automatically) -- Greetings https://bugs.debian.org/1003044
Bug#1003044: internal 'getzoneinfofile_stream' method emits a warning message
On Sun, 05 Mar 2023 18:50:06 +0100 Arnout Vandecappelle wrote: This still fails to address the original issue: an irrelevant warning is printed when performing a fairly mundane thing (requesting a nonexistent timezone). That part could be easily fixed. We can just remove the fallback from dateutil.tz.gettz() to get_zonefile_instance() since we know that the system database is available. I repeat: I don't think anyone really wants to use the bundled database. That's probably true but there are direct users of the dateutil.zoneinfo API which intrinsically uses the bundled database. For example within Debian packages: https://sources.debian.org/src/python-hypothesis/6.67.1-1/hypothesis-python/src/hypothesis/extra/dateutil.py/?hl=56#L56 https://sources.debian.org/src/python-sqlalchemy-utils/0.38.2-2/sqlalchemy_utils/types/timezone.py/?hl=44#L44 These are currently broken. Just silencing the warning will leave them broken. We could patch the implementation to use the system database but that means deviating from the upstream behavior and carrying that patch forever. The API even includes the metadata dictionary that would have to be faked as well: https://sources.debian.org/src/python-dateutil/2.8.2-1/dateutil/zoneinfo/__init__.py/#L46 Therefore shipping the bundled zoneinfo tarball seems like the better solution to me. The timezone database is clearly DFSG-free. We would have to repackage the upstream tarball to include the timezone database source though. Thankfully upstream ships the script to (re-)generate the zoneinfo tarball. Felix
Bug#1003044: internal 'getzoneinfofile_stream' method emits a warning message
On Sun, 05 Mar 2023 18:50:06 +0100 Arnout Vandecappelle wrote: This still fails to address the original issue: an irrelevant warning is printed when performing a fairly mundane thing (requesting a nonexistent timezone). That part could be easily fixed. We can just remove the fallback from dateutil.tz.gettz() to get_zonefile_instance() since we know that the system database is available. I repeat: I don't think anyone really wants to use the bundled database. That's probably true but there are direct users of the dateutil.zoneinfo API which intrinsically uses the bundled database. For example within Debian packages: https://sources.debian.org/src/python-hypothesis/6.67.1-1/hypothesis-python/src/hypothesis/extra/dateutil.py/?hl=56#L56 https://sources.debian.org/src/python-sqlalchemy-utils/0.38.2-2/sqlalchemy_utils/types/timezone.py/?hl=44#L44 These are currently broken. Just silencing the warning will leave them broken. We could patch the implementation to use the system database but that means deviating from the upstream behavior and carrying that patch forever. The API even includes the metadata dictionary that would have to be faked as well: https://sources.debian.org/src/python-dateutil/2.8.2-1/dateutil/zoneinfo/__init__.py/#L46 Therefore shipping the bundled zoneinfo tarball seems like the better solution to me. The timezone database is clearly DFSG-free. We would have to repackage the upstream tarball to include the timezone database source though. Thankfully upstream ships the script to (re-)generate the zoneinfo tarball. Felix
Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)
On 21.02.23 20:46, Sandro Tosi wrote: it produces output on stderr, which many tools consider it an error and fails build. When raising the severity of a bug to grave I would expect some concrete details on what exactly is broken instead of a hand-wavy "breaks some stuff". But anyway let's focus on the issue. dateutil.zoneinfo really shouldn't be used directly and I don't see any can you back this quote please? zoneinfo is part of the public API, and just breaking it (via the removal of the zonefile) and say not to use it is going in the wrong direction. https://dateutil.readthedocs.io/en/stable/zoneinfo.html#dateutil.zoneinfo.gettz has a warning that you shouldn't use it. For get_zonefile_instance() it only says "using the data provided by the dateutil package". This implies that the data is outdated most of the time since it's rarely updated. Unfortunately that's not clearly stated. Of course it's part of the public API. Unfortunately its design leaves us only with bad options. I guess we have two options if we want to change the current behavior: 1) Ship the outdated tzdata tarball even though nothing should really use it. 2) Add a patch to remove the dateutil.zoneinfo fallback. i think you're missing 3) fix dateutil.zoneinfo to use a system-available zone info file It wouldn't be fixing it since the sole purpose of this API is to use the bundled timezone database instead of the potentially absent (from a general POV, of course the Debian package depends on tzdata) system timezone database. I'm inclined to just ship the bundled timezone database with the package: - We wouldn't have to permanently patch the code. - dateutil consumers that just want accurate timezone information are supposed to use dateutil.tz.gettz() which already prefers the system database. - Direct dateutil.zoneinfo users kind of opted into receiving outdated timezone information. Felix
Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)
On 21.02.23 20:46, Sandro Tosi wrote: it produces output on stderr, which many tools consider it an error and fails build. When raising the severity of a bug to grave I would expect some concrete details on what exactly is broken instead of a hand-wavy "breaks some stuff". But anyway let's focus on the issue. dateutil.zoneinfo really shouldn't be used directly and I don't see any can you back this quote please? zoneinfo is part of the public API, and just breaking it (via the removal of the zonefile) and say not to use it is going in the wrong direction. https://dateutil.readthedocs.io/en/stable/zoneinfo.html#dateutil.zoneinfo.gettz has a warning that you shouldn't use it. For get_zonefile_instance() it only says "using the data provided by the dateutil package". This implies that the data is outdated most of the time since it's rarely updated. Unfortunately that's not clearly stated. Of course it's part of the public API. Unfortunately its design leaves us only with bad options. I guess we have two options if we want to change the current behavior: 1) Ship the outdated tzdata tarball even though nothing should really use it. 2) Add a patch to remove the dateutil.zoneinfo fallback. i think you're missing 3) fix dateutil.zoneinfo to use a system-available zone info file It wouldn't be fixing it since the sole purpose of this API is to use the bundled timezone database instead of the potentially absent (from a general POV, of course the Debian package depends on tzdata) system timezone database. I'm inclined to just ship the bundled timezone database with the package: - We wouldn't have to permanently patch the code. - dateutil consumers that just want accurate timezone information are supposed to use dateutil.tz.gettz() which already prefers the system database. - Direct dateutil.zoneinfo users kind of opted into receiving outdated timezone information. Felix
Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)
On Sat, 7 Jan 2023 03:34:19 -0500 Sandro Tosi wrote:
> python-dateutil expects to have 'dateutil-zoneinfo.tar.gz' in it's directory
> tree, but this file is removed in the packaging.
>
> Error:
> "/usr/lib/python3/dist-packages/dateutil/zoneinfo/__init__.py:26: UserWarning:
> I/O error(2): Datei oder Verzeichnis nicht gefunden
> warnings.warn("I/O error({0}): {1}".format(e.errno, e.strerror))"
>
> Using: "matplotlib.dates import DateFormatter"
indeed this is breaking matplotlib, thus the grave severity. it needs
to be addressed for bookworm
How exactly does this break matplotlib?
dateutil.zoneinfo really shouldn't be used directly and I don't see any
reference to it in the matplotlib code.
dateutil.tz prefers the system timezone database so you should see this
warning only when trying to use a non-existent timezone.
Even then it is just a warning, not an exception that is thrown.
>>> import dateutil.tz
>>> dateutil.tz.gettz('UTC')
tzfile('/usr/share/zoneinfo/UTC')
>>> dateutil.tz.gettz('foo')
/usr/lib/python3/dist-packages/dateutil/zoneinfo/__init__.py:26: UserWarning: I/O error(2): No
such file or directory
warnings.warn("I/O error({0}): {1}".format(e.errno, e.strerror))
I guess we have two options if we want to change the current behavior:
1) Ship the outdated tzdata tarball even though nothing should really use it.
2) Add a patch to remove the dateutil.zoneinfo fallback.
Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)
On Sat, 7 Jan 2023 03:34:19 -0500 Sandro Tosi wrote:
> python-dateutil expects to have 'dateutil-zoneinfo.tar.gz' in it's directory
> tree, but this file is removed in the packaging.
>
> Error:
> "/usr/lib/python3/dist-packages/dateutil/zoneinfo/__init__.py:26: UserWarning:
> I/O error(2): Datei oder Verzeichnis nicht gefunden
> warnings.warn("I/O error({0}): {1}".format(e.errno, e.strerror))"
>
> Using: "matplotlib.dates import DateFormatter"
indeed this is breaking matplotlib, thus the grave severity. it needs
to be addressed for bookworm
How exactly does this break matplotlib?
dateutil.zoneinfo really shouldn't be used directly and I don't see any
reference to it in the matplotlib code.
dateutil.tz prefers the system timezone database so you should see this
warning only when trying to use a non-existent timezone.
Even then it is just a warning, not an exception that is thrown.
>>> import dateutil.tz
>>> dateutil.tz.gettz('UTC')
tzfile('/usr/share/zoneinfo/UTC')
>>> dateutil.tz.gettz('foo')
/usr/lib/python3/dist-packages/dateutil/zoneinfo/__init__.py:26: UserWarning: I/O error(2): No
such file or directory
warnings.warn("I/O error({0}): {1}".format(e.errno, e.strerror))
I guess we have two options if we want to change the current behavior:
1) Ship the outdated tzdata tarball even though nothing should really use it.
2) Add a patch to remove the dateutil.zoneinfo fallback.
Bug#1023105: bullseye-pu: package tinyxml/2.6.2-4+deb11u1
On 23.11.22 21:48, Adam D. Barratt wrote: Control: tags -1 + confirmed On Sun, 2022-10-30 at 10:31 +0100, Felix Geyer wrote: Fixing the no-dsa tagged CVE-2021-42260 [ Impact ] DoS vulnerability Please go ahead. Uploaded, thanks! Felix
Bug#1023105: bullseye-pu: package tinyxml/2.6.2-4+deb11u1
On 23.11.22 21:48, Adam D. Barratt wrote: Control: tags -1 + confirmed On Sun, 2022-10-30 at 10:31 +0100, Felix Geyer wrote: Fixing the no-dsa tagged CVE-2021-42260 [ Impact ] DoS vulnerability Please go ahead. Uploaded, thanks! Felix
Bug#1024037: marked as pending in pytaglib
Control: tag -1 pending Hello, Bug #1024037 in pytaglib reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pytaglib/-/commit/f93efe9d20556aa37c1485ff029343f77959d84e Regenerate cython files. * Regenerate cython files. - Fixes FTBFS with Python 3.11 (Closes: #1024037) (this message was generated automatically) -- Greetings https://bugs.debian.org/1024037
Bug#1023959: python-crc32c ftbfs on arm64
On Sun, 13 Nov 2022 09:10:37 +0100 Matthias Klose wrote: Package: src:python-crc32c Version: 2.3-1 Severity: serious Tags: sid bookworm ftbfs User: debian-pyt...@lists.debian.org Usertag: python3.11 [...] In file included from crc32c_arm64.c:22: /usr/lib/gcc/aarch64-linux-gnu/12/include/arm_acle.h: In function ‘_crc32c_hw_arm64’: /usr/lib/gcc/aarch64-linux-gnu/12/include/arm_acle.h:197:1: error: inlining failed in call to ‘always_inline’ ‘__crc32cd’: target specific option mismatch 197 | __crc32cd (uint32_t __a, uint64_t __b) | ^ crc32c_arm64.c:91:12: note: called from here 91 | crc ^= __crc32cd(0, t0); |^~~~ The upstream build system adds -march=armv8-a+crc+crypto to the compiler flags if it's built on arm. It detects this by checking if sysconfig.get_platform() contains one of 'aarch64_be', 'aarch64', 'armv8b', 'armv8l', 'universal2'. However pybuild passes $DEB_HOST_ARCH (the Debian architecture name) in _PYTHON_HOST_PLATFORM: https://salsa.debian.org/python-team/tools/dh-python/-/blob/42fc6aba/pybuild#L84 Because of this sysconfig.get_platform() returns linux-arm64 instead of the expected linux-aarch64 on arm64 and -march isn't passed to the compiler. This seems like questionable behavior of pybuild. No software would expect to find the Debian architecture name in get_platform() instead of the kernel architecture name. There is already special casing for amd64 -> x86_64 but it really needs to do this for all architectures where both don't match. Felix
Bug#1023959: python-crc32c ftbfs on arm64
On Sun, 13 Nov 2022 09:10:37 +0100 Matthias Klose wrote: Package: src:python-crc32c Version: 2.3-1 Severity: serious Tags: sid bookworm ftbfs User: debian-pyt...@lists.debian.org Usertag: python3.11 [...] In file included from crc32c_arm64.c:22: /usr/lib/gcc/aarch64-linux-gnu/12/include/arm_acle.h: In function ‘_crc32c_hw_arm64’: /usr/lib/gcc/aarch64-linux-gnu/12/include/arm_acle.h:197:1: error: inlining failed in call to ‘always_inline’ ‘__crc32cd’: target specific option mismatch 197 | __crc32cd (uint32_t __a, uint64_t __b) | ^ crc32c_arm64.c:91:12: note: called from here 91 | crc ^= __crc32cd(0, t0); |^~~~ The upstream build system adds -march=armv8-a+crc+crypto to the compiler flags if it's built on arm. It detects this by checking if sysconfig.get_platform() contains one of 'aarch64_be', 'aarch64', 'armv8b', 'armv8l', 'universal2'. However pybuild passes $DEB_HOST_ARCH (the Debian architecture name) in _PYTHON_HOST_PLATFORM: https://salsa.debian.org/python-team/tools/dh-python/-/blob/42fc6aba/pybuild#L84 Because of this sysconfig.get_platform() returns linux-arm64 instead of the expected linux-aarch64 on arm64 and -march isn't passed to the compiler. This seems like questionable behavior of pybuild. No software would expect to find the Debian architecture name in get_platform() instead of the kernel architecture name. There is already special casing for amd64 -> x86_64 but it really needs to do this for all architectures where both don't match. Felix
Bug#1023912: marked as pending in python-uinput
Control: tag -1 pending Hello, Bug #1023912 in python-uinput reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-uinput/-/commit/c58022a9a69325ec219408057c568f1674034c56 Support Python 3.11 Closes: #1023912 (this message was generated automatically) -- Greetings https://bugs.debian.org/1023912
Bug#1023105: bullseye-pu: package tinyxml/2.6.2-4+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Fixing the no-dsa tagged CVE-2021-42260
[ Impact ]
DoS vulnerability
[ Tests ]
General testing of a few reverse-dependencies.
[ Risks ]
Targeted fix that has been sitting in bookworm, stretch and buster
for a while without any bug reports.
[ 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 ]
Fixes potential infinite loop in parser code.diff -Nru tinyxml-2.6.2/debian/changelog tinyxml-2.6.2/debian/changelog
--- tinyxml-2.6.2/debian/changelog 2016-10-20 20:36:11.0 +0200
+++ tinyxml-2.6.2/debian/changelog 2022-10-20 16:32:51.0 +0200
@@ -1,3 +1,10 @@
+tinyxml (2.6.2-4+deb11u1) bullseye; urgency=medium
+
+ * Import fix for CVE-2021-42260.
+- Add CVE-2021-42260.patch
+
+ -- Felix Geyer Thu, 20 Oct 2022 16:32:51 +0200
+
tinyxml (2.6.2-4) unstable; urgency=medium
[ Helmut Grohne ]
diff -Nru tinyxml-2.6.2/debian/patches/CVE-2021-42260.patch
tinyxml-2.6.2/debian/patches/CVE-2021-42260.patch
--- tinyxml-2.6.2/debian/patches/CVE-2021-42260.patch 1970-01-01
01:00:00.0 +0100
+++ tinyxml-2.6.2/debian/patches/CVE-2021-42260.patch 2022-10-20
16:31:07.0 +0200
@@ -0,0 +1,23 @@
+Description: In stamp always advance the pointer if *p= 0xef
+ .
+ The current implementation only advanced if 0xef is followed
+ by two non-zero bytes. In case of malformed input (0xef should be
+ the start byte of a three byte character) this leads to an infinite
+ loop. (CVE-2021-42260)
+Origin: https://sourceforge.net/p/tinyxml/git/merge-requests/1/
+
+--- a/tinyxmlparser.cpp
b/tinyxmlparser.cpp
+@@ -274,6 +274,12 @@ void TiXmlParsingData::Stamp( const char* now,
TiXmlEncoding encoding )
+ else
+ { p +=3; ++col; }
// A normal character.
+ }
++ else
++ {
++ // TIXML_UTF_LEAD_0 (239) is
the start character of a 3 byte sequence, so
++ // there is something wrong
here. Just advance the pointer to evade infinite loops
++ ++p;
++ }
+ }
+ else
+ {
diff -Nru tinyxml-2.6.2/debian/patches/series
tinyxml-2.6.2/debian/patches/series
--- tinyxml-2.6.2/debian/patches/series 2011-05-19 10:42:07.0 +0200
+++ tinyxml-2.6.2/debian/patches/series 2022-10-20 16:32:49.0 +0200
@@ -1,2 +1,3 @@
enforce-use-stl.patch
entity-encoding.patch
+CVE-2021-42260.patch
Bug#1023105: bullseye-pu: package tinyxml/2.6.2-4+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Fixing the no-dsa tagged CVE-2021-42260
[ Impact ]
DoS vulnerability
[ Tests ]
General testing of a few reverse-dependencies.
[ Risks ]
Targeted fix that has been sitting in bookworm, stretch and buster
for a while without any bug reports.
[ 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 ]
Fixes potential infinite loop in parser code.diff -Nru tinyxml-2.6.2/debian/changelog tinyxml-2.6.2/debian/changelog
--- tinyxml-2.6.2/debian/changelog 2016-10-20 20:36:11.0 +0200
+++ tinyxml-2.6.2/debian/changelog 2022-10-20 16:32:51.0 +0200
@@ -1,3 +1,10 @@
+tinyxml (2.6.2-4+deb11u1) bullseye; urgency=medium
+
+ * Import fix for CVE-2021-42260.
+- Add CVE-2021-42260.patch
+
+ -- Felix Geyer Thu, 20 Oct 2022 16:32:51 +0200
+
tinyxml (2.6.2-4) unstable; urgency=medium
[ Helmut Grohne ]
diff -Nru tinyxml-2.6.2/debian/patches/CVE-2021-42260.patch
tinyxml-2.6.2/debian/patches/CVE-2021-42260.patch
--- tinyxml-2.6.2/debian/patches/CVE-2021-42260.patch 1970-01-01
01:00:00.0 +0100
+++ tinyxml-2.6.2/debian/patches/CVE-2021-42260.patch 2022-10-20
16:31:07.0 +0200
@@ -0,0 +1,23 @@
+Description: In stamp always advance the pointer if *p= 0xef
+ .
+ The current implementation only advanced if 0xef is followed
+ by two non-zero bytes. In case of malformed input (0xef should be
+ the start byte of a three byte character) this leads to an infinite
+ loop. (CVE-2021-42260)
+Origin: https://sourceforge.net/p/tinyxml/git/merge-requests/1/
+
+--- a/tinyxmlparser.cpp
b/tinyxmlparser.cpp
+@@ -274,6 +274,12 @@ void TiXmlParsingData::Stamp( const char* now,
TiXmlEncoding encoding )
+ else
+ { p +=3; ++col; }
// A normal character.
+ }
++ else
++ {
++ // TIXML_UTF_LEAD_0 (239) is
the start character of a 3 byte sequence, so
++ // there is something wrong
here. Just advance the pointer to evade infinite loops
++ ++p;
++ }
+ }
+ else
+ {
diff -Nru tinyxml-2.6.2/debian/patches/series
tinyxml-2.6.2/debian/patches/series
--- tinyxml-2.6.2/debian/patches/series 2011-05-19 10:42:07.0 +0200
+++ tinyxml-2.6.2/debian/patches/series 2022-10-20 16:32:49.0 +0200
@@ -1,2 +1,3 @@
enforce-use-stl.patch
entity-encoding.patch
+CVE-2021-42260.patch
Bug#997366: speedcrunch: FTBFS: TypeError: 'SpeedCrunchSessionLexer' object is not callable
Control: tags -1 patch
Control: tags -1 pending
On Sat, 23 Oct 2021 21:41:50 +0200 Lucas Nussbaum wrote:
Source: speedcrunch
Version: 0.12.0-5
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
I've prepared a fix for building against Sphinx >= 4 and uploaded it to
DELAYED/5.
Please feel free to tell me if I should cancel it. The debdiff is attached.
Felixdiff -Nru speedcrunch-0.12.0/debian/changelog
speedcrunch-0.12.0/debian/changelog
--- speedcrunch-0.12.0/debian/changelog 2020-04-19 14:13:08.0 +0200
+++ speedcrunch-0.12.0/debian/changelog 2022-10-29 09:59:26.0 +0200
@@ -1,3 +1,11 @@
+speedcrunch (0.12.0-5.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix docs build with Sphinx >= 4. (Closes: #997366)
+- Add 0007-fix-docs-build-with-Sphinx-4.patch
+
+ -- Felix Geyer Sat, 29 Oct 2022 09:59:26 +0200
+
speedcrunch (0.12.0-5) unstable; urgency=medium
* d/patches, d/control: fix docs build with Sphinx >= 2.0
diff -Nru
speedcrunch-0.12.0/debian/patches/0007-fix-docs-build-with-Sphinx-4.patch
speedcrunch-0.12.0/debian/patches/0007-fix-docs-build-with-Sphinx-4.patch
--- speedcrunch-0.12.0/debian/patches/0007-fix-docs-build-with-Sphinx-4.patch
1970-01-01 01:00:00.0 +0100
+++ speedcrunch-0.12.0/debian/patches/0007-fix-docs-build-with-Sphinx-4.patch
2022-10-29 09:59:26.0 +0200
@@ -0,0 +1,33 @@
+Description: Fix FTBFS with Sphinx >= 4
+
+Pass the type instead of an instance to add_lexer().
+
+> Sphinx.add_lexer():
+> Take a lexer class as an argument.
+> An instance of lexers are still supported until Sphinx-3.x.
+
+--- speedcrunch-0.12.0.orig/doc/src/extensions/sc_lexer.py
speedcrunch-0.12.0/doc/src/extensions/sc_lexer.py
+@@ -108,16 +108,18 @@ class SpeedCrunchSessionLexer(SpeedCrunc
+ ]
+ }
+
++def __init__(self):
++super().__init__(stripnl=False)
++self.add_filter('raiseonerror')
++
+
+ __all__ = ['SpeedCrunchLexer', 'SpeedCrunchSessionLexer']
+
+
+ # Sphinx extension interface
+ def setup(app):
+-sc_lexer = SpeedCrunchSessionLexer(stripnl=False)
+-sc_lexer.add_filter('raiseonerror')
+-app.add_lexer('sc', sc_lexer)
+-app.add_lexer('speedcrunch', sc_lexer)
++app.add_lexer('sc', SpeedCrunchSessionLexer)
++app.add_lexer('speedcrunch', SpeedCrunchSessionLexer)
+ return {
+ 'version': '0.1',
+ 'parallel_read_safe': True,
diff -Nru speedcrunch-0.12.0/debian/patches/series
speedcrunch-0.12.0/debian/patches/series
--- speedcrunch-0.12.0/debian/patches/series2020-04-19 11:13:12.0
+0200
+++ speedcrunch-0.12.0/debian/patches/series2022-10-29 09:59:14.0
+0200
@@ -4,3 +4,4 @@
0004-Replace-the-REBUILD_MANUAL-option-with-a-path.patch
0005-docs-fix-docs-build-with-Sphinx-2.0.patch
0006-Use-CMake-s-CXX_STANDARD-property.patch
+0007-fix-docs-build-with-Sphinx-4.patch
Bug#997366: speedcrunch: FTBFS: TypeError: 'SpeedCrunchSessionLexer' object is not callable
Control: tags -1 patch
Control: tags -1 pending
On Sat, 23 Oct 2021 21:41:50 +0200 Lucas Nussbaum wrote:
Source: speedcrunch
Version: 0.12.0-5
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
I've prepared a fix for building against Sphinx >= 4 and uploaded it to
DELAYED/5.
Please feel free to tell me if I should cancel it. The debdiff is attached.
Felixdiff -Nru speedcrunch-0.12.0/debian/changelog
speedcrunch-0.12.0/debian/changelog
--- speedcrunch-0.12.0/debian/changelog 2020-04-19 14:13:08.0 +0200
+++ speedcrunch-0.12.0/debian/changelog 2022-10-29 09:59:26.0 +0200
@@ -1,3 +1,11 @@
+speedcrunch (0.12.0-5.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix docs build with Sphinx >= 4. (Closes: #997366)
+- Add 0007-fix-docs-build-with-Sphinx-4.patch
+
+ -- Felix Geyer Sat, 29 Oct 2022 09:59:26 +0200
+
speedcrunch (0.12.0-5) unstable; urgency=medium
* d/patches, d/control: fix docs build with Sphinx >= 2.0
diff -Nru
speedcrunch-0.12.0/debian/patches/0007-fix-docs-build-with-Sphinx-4.patch
speedcrunch-0.12.0/debian/patches/0007-fix-docs-build-with-Sphinx-4.patch
--- speedcrunch-0.12.0/debian/patches/0007-fix-docs-build-with-Sphinx-4.patch
1970-01-01 01:00:00.0 +0100
+++ speedcrunch-0.12.0/debian/patches/0007-fix-docs-build-with-Sphinx-4.patch
2022-10-29 09:59:26.0 +0200
@@ -0,0 +1,33 @@
+Description: Fix FTBFS with Sphinx >= 4
+
+Pass the type instead of an instance to add_lexer().
+
+> Sphinx.add_lexer():
+> Take a lexer class as an argument.
+> An instance of lexers are still supported until Sphinx-3.x.
+
+--- speedcrunch-0.12.0.orig/doc/src/extensions/sc_lexer.py
speedcrunch-0.12.0/doc/src/extensions/sc_lexer.py
+@@ -108,16 +108,18 @@ class SpeedCrunchSessionLexer(SpeedCrunc
+ ]
+ }
+
++def __init__(self):
++super().__init__(stripnl=False)
++self.add_filter('raiseonerror')
++
+
+ __all__ = ['SpeedCrunchLexer', 'SpeedCrunchSessionLexer']
+
+
+ # Sphinx extension interface
+ def setup(app):
+-sc_lexer = SpeedCrunchSessionLexer(stripnl=False)
+-sc_lexer.add_filter('raiseonerror')
+-app.add_lexer('sc', sc_lexer)
+-app.add_lexer('speedcrunch', sc_lexer)
++app.add_lexer('sc', SpeedCrunchSessionLexer)
++app.add_lexer('speedcrunch', SpeedCrunchSessionLexer)
+ return {
+ 'version': '0.1',
+ 'parallel_read_safe': True,
diff -Nru speedcrunch-0.12.0/debian/patches/series
speedcrunch-0.12.0/debian/patches/series
--- speedcrunch-0.12.0/debian/patches/series2020-04-19 11:13:12.0
+0200
+++ speedcrunch-0.12.0/debian/patches/series2022-10-29 09:59:14.0
+0200
@@ -4,3 +4,4 @@
0004-Replace-the-REBUILD_MANUAL-option-with-a-path.patch
0005-docs-fix-docs-build-with-Sphinx-2.0.patch
0006-Use-CMake-s-CXX_STANDARD-property.patch
+0007-fix-docs-build-with-Sphinx-4.patch
Bug#1020453: docker.io: consider backporting to stable
On Wed, 21 Sep 2022 22:33:39 +0200 Libor Klepáč wrote: Package: docker.io Followup-For: Bug #908603 Hello Maintainers, could you please consider backporting docker.io version 20.10.17 to stable? We are hitting problem with graylog docker image. https://github.com/Graylog2/graylog-docker/issues/217 This specific fix (support for the clone3 syscall) has already been backported to 20.10.5+dfsg1-1+deb11u1. What version of docker.io do you have running? Felix
Bug#1012140: bullseye-pu: package docker.io/20.10.5+dfsg1-1+deb11u2
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu [ Reason ] Docker uses containerd to manage containers but fails to setup the proper dependencies in the systemd service. https://bugs.debian.org/989490 [ Impact ] On system shutdown Docker often is unable to properly shutdown containers and just hangs. This delays shutdown until it reaches the timeout (by default 90s). [ Tests ] I have been running these changes on a few hosts for a month and haven't had any problems regarding start/shutdown since. [ Risks ] The changes only touch the systemd service and have been backported from current upstream. [ 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 ] * Order docker.service after containerd.service * Explicitly pass the containerd socket path to dockerd to make sure it doesn't start containerd on its own. diff -Nru docker.io-20.10.5+dfsg1/debian/changelog docker.io-20.10.5+dfsg1/debian/changelog --- docker.io-20.10.5+dfsg1/debian/changelog2021-12-04 11:53:03.0 +0100 +++ docker.io-20.10.5+dfsg1/debian/changelog2022-05-30 20:34:49.0 +0200 @@ -1,3 +1,12 @@ +docker.io (20.10.5+dfsg1-1+deb11u2) bullseye; urgency=medium + + * Order docker.service after containerd.service to fix shutdown of +containers (Closes: #989490) + * Explicitly pass the containerd socket path to dockerd to make sure it +doesn't start containerd on its own. + + -- Felix Geyer Mon, 30 May 2022 20:34:49 +0200 + docker.io (20.10.5+dfsg1-1+deb11u1) bullseye; urgency=medium * Backport patches for CVE-2021-41089 CVE-2021-41091 CVE-2021-41092 diff -Nru docker.io-20.10.5+dfsg1/debian/patches/engine-systemd-service-after-containerd.patch docker.io-20.10.5+dfsg1/debian/patches/engine-systemd-service-after-containerd.patch --- docker.io-20.10.5+dfsg1/debian/patches/engine-systemd-service-after-containerd.patch 1970-01-01 01:00:00.0 +0100 +++ docker.io-20.10.5+dfsg1/debian/patches/engine-systemd-service-after-containerd.patch 2022-05-30 20:09:40.0 +0200 @@ -0,0 +1,28 @@ +Description: Order docker.service after containerd.service + Fixes proper shutdown of containers. +Origin: upstream, cherry-picked parts of https://github.com/moby/moby/pull/42373 + and https://github.com/moby/moby/pull/42622 +Bug-Debian: https://bugs.debian.org/989490 + +--- docker.io-20.10.11+dfsg1.orig/engine/contrib/init/systemd/docker.service docker.io-20.10.11+dfsg1/engine/contrib/init/systemd/docker.service +@@ -1,8 +1,8 @@ + [Unit] + Description=Docker Application Container Engine + Documentation=https://docs.docker.com +-After=network-online.target docker.socket firewalld.service +-Wants=network-online.target ++After=network-online.target docker.socket firewalld.service containerd.service ++Wants=network-online.target containerd.service + Requires=docker.socket + + [Service] +@@ -11,7 +11,7 @@ Type=notify + # exists and systemd currently does not support the cgroup feature set required + # for containers run by docker + EnvironmentFile=-/etc/default/docker +-ExecStart=/usr/sbin/dockerd -H fd:// $DOCKER_OPTS ++ExecStart=/usr/sbin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock $DOCKER_OPTS + ExecReload=/bin/kill -s HUP $MAINPID + LimitNOFILE=1048576 + # Having non-zero Limit*s causes performance problems due to accounting overhead diff -Nru docker.io-20.10.5+dfsg1/debian/patches/series docker.io-20.10.5+dfsg1/debian/patches/series --- docker.io-20.10.5+dfsg1/debian/patches/series 2021-12-04 11:53:03.0 +0100 +++ docker.io-20.10.5+dfsg1/debian/patches/series 2022-05-30 20:10:09.0 +0200 @@ -11,6 +11,7 @@ cli-dont-duplicate-authconfig.patch engine-add-go.mod-file.patch +engine-systemd-service-after-containerd.patch libnetwork-add-go.mod-file.patch libnetwork_proto.patch
Bug#1012140: bullseye-pu: package docker.io/20.10.5+dfsg1-1+deb11u2
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu [ Reason ] Docker uses containerd to manage containers but fails to setup the proper dependencies in the systemd service. https://bugs.debian.org/989490 [ Impact ] On system shutdown Docker often is unable to properly shutdown containers and just hangs. This delays shutdown until it reaches the timeout (by default 90s). [ Tests ] I have been running these changes on a few hosts for a month and haven't had any problems regarding start/shutdown since. [ Risks ] The changes only touch the systemd service and have been backported from current upstream. [ 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 ] * Order docker.service after containerd.service * Explicitly pass the containerd socket path to dockerd to make sure it doesn't start containerd on its own. diff -Nru docker.io-20.10.5+dfsg1/debian/changelog docker.io-20.10.5+dfsg1/debian/changelog --- docker.io-20.10.5+dfsg1/debian/changelog2021-12-04 11:53:03.0 +0100 +++ docker.io-20.10.5+dfsg1/debian/changelog2022-05-30 20:34:49.0 +0200 @@ -1,3 +1,12 @@ +docker.io (20.10.5+dfsg1-1+deb11u2) bullseye; urgency=medium + + * Order docker.service after containerd.service to fix shutdown of +containers (Closes: #989490) + * Explicitly pass the containerd socket path to dockerd to make sure it +doesn't start containerd on its own. + + -- Felix Geyer Mon, 30 May 2022 20:34:49 +0200 + docker.io (20.10.5+dfsg1-1+deb11u1) bullseye; urgency=medium * Backport patches for CVE-2021-41089 CVE-2021-41091 CVE-2021-41092 diff -Nru docker.io-20.10.5+dfsg1/debian/patches/engine-systemd-service-after-containerd.patch docker.io-20.10.5+dfsg1/debian/patches/engine-systemd-service-after-containerd.patch --- docker.io-20.10.5+dfsg1/debian/patches/engine-systemd-service-after-containerd.patch 1970-01-01 01:00:00.0 +0100 +++ docker.io-20.10.5+dfsg1/debian/patches/engine-systemd-service-after-containerd.patch 2022-05-30 20:09:40.0 +0200 @@ -0,0 +1,28 @@ +Description: Order docker.service after containerd.service + Fixes proper shutdown of containers. +Origin: upstream, cherry-picked parts of https://github.com/moby/moby/pull/42373 + and https://github.com/moby/moby/pull/42622 +Bug-Debian: https://bugs.debian.org/989490 + +--- docker.io-20.10.11+dfsg1.orig/engine/contrib/init/systemd/docker.service docker.io-20.10.11+dfsg1/engine/contrib/init/systemd/docker.service +@@ -1,8 +1,8 @@ + [Unit] + Description=Docker Application Container Engine + Documentation=https://docs.docker.com +-After=network-online.target docker.socket firewalld.service +-Wants=network-online.target ++After=network-online.target docker.socket firewalld.service containerd.service ++Wants=network-online.target containerd.service + Requires=docker.socket + + [Service] +@@ -11,7 +11,7 @@ Type=notify + # exists and systemd currently does not support the cgroup feature set required + # for containers run by docker + EnvironmentFile=-/etc/default/docker +-ExecStart=/usr/sbin/dockerd -H fd:// $DOCKER_OPTS ++ExecStart=/usr/sbin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock $DOCKER_OPTS + ExecReload=/bin/kill -s HUP $MAINPID + LimitNOFILE=1048576 + # Having non-zero Limit*s causes performance problems due to accounting overhead diff -Nru docker.io-20.10.5+dfsg1/debian/patches/series docker.io-20.10.5+dfsg1/debian/patches/series --- docker.io-20.10.5+dfsg1/debian/patches/series 2021-12-04 11:53:03.0 +0100 +++ docker.io-20.10.5+dfsg1/debian/patches/series 2022-05-30 20:10:09.0 +0200 @@ -11,6 +11,7 @@ cli-dont-duplicate-authconfig.patch engine-add-go.mod-file.patch +engine-systemd-service-after-containerd.patch libnetwork-add-go.mod-file.patch libnetwork_proto.patch
Bug#989490: docker: systemd shutdown script takes a long time waiting for containers that aren't running?
Control: tags -1 patch On Tue, 12 Oct 2021 13:47:08 +0200 pedeb wrote: Hi Andrew, Looks like the systemd unit is not properly configured. I had the same the same problem and here is a solution. Meanwhile this is not solved in debian, you can place the systemd unit in a way that is not going to be changed because of upgrades ``` cp -p /lib/systemd/system/docker.service /etc/systemd/system/docker.service ``` and reload systemd daemon ``` systemctl daemon-reload ``` the solution is changing the systemd unit this way [0] I've opened a merge request at https://salsa.debian.org/go-team/packages/docker/-/merge_requests/6
Bug#996025: bullseye-pu: package libseccomp/2.5.1-1+deb11u1
On 03.12.21 17:40, Adam D. Barratt wrote: Control: tags -1 + confirmed On Thu, 2021-11-25 at 19:29 +0100, Felix Geyer wrote: On Sun, 10 Oct 2021 14:34:30 +0200 Felix Geyer wrote: libseccomp 2.5.1 only knows about syscall up to Linux 5.8. The proposed changes add the syscalls up to Linux 5.14. [...] I've updated the debdiff to include two more cherry-picked patches that add a new syscalls from Linux 5.15 and missing syscall defines. Please go ahead. Uploaded, thanks! Felix
Bug#996025: bullseye-pu: package libseccomp/2.5.1-1+deb11u1
On 03.12.21 17:40, Adam D. Barratt wrote: Control: tags -1 + confirmed On Thu, 2021-11-25 at 19:29 +0100, Felix Geyer wrote: On Sun, 10 Oct 2021 14:34:30 +0200 Felix Geyer wrote: libseccomp 2.5.1 only knows about syscall up to Linux 5.8. The proposed changes add the syscalls up to Linux 5.14. [...] I've updated the debdiff to include two more cherry-picked patches that add a new syscalls from Linux 5.15 and missing syscall defines. Please go ahead. Uploaded, thanks! Felix
Bug#996025: bullseye-pu: package libseccomp/2.5.1-1+deb11u1
On Sun, 10 Oct 2021 14:34:30 +0200 Felix Geyer wrote: Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu [ Reason ] libseccomp 2.5.1 only knows about syscall up to Linux 5.8. The proposed changes add the syscalls up to Linux 5.14. [ Impact ] Syscalls for Linux 5.9 and 5.10 can't be allowed. Software built with support for newer kernels (often the case in containers) expect newer syscalls to work or return ENOSYS. If that syscall is not supported by libseccomp and a default filter action of returning EPERM is used, such software will break. Therefore you often need to be able to allow a syscall even when the running kernel doesn't support it. [ Tests ] * autopkgtest passes on amd64 * Verified adding a filter for the close_range() syscall works (new in 5.9) * Verified that systemd and Docker run [ Risks ] The changes only extend the syscall csv table and add new syscall defines. [ 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 ] Cherry-pick upstream commits to support syscalls up to Linux 5.14. I've updated the debdiff to include two more cherry-picked patches that add a new syscalls from Linux 5.15 and missing syscall defines. Felixdiff -Nru libseccomp-2.5.1/debian/changelog libseccomp-2.5.1/debian/changelog --- libseccomp-2.5.1/debian/changelog 2020-12-21 10:50:30.0 +0100 +++ libseccomp-2.5.1/debian/changelog 2021-11-25 19:18:20.0 +0100 @@ -1,3 +1,9 @@ +libseccomp (2.5.1-1+deb11u1) bullseye; urgency=medium + + * Add support for syscalls up to Linux 5.15. + + -- Felix Geyer Thu, 25 Nov 2021 19:18:20 +0100 + libseccomp (2.5.1-1) unstable; urgency=medium * New upstream release. diff -Nru libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch --- libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch 2021-11-24 19:09:09.0 +0100 @@ -0,0 +1,104 @@ +From 8379ee877612f027f75592c8de5bf7969aa7fb51 Mon Sep 17 00:00:00 2001 +From: Paul Moore +Date: Wed, 27 Oct 2021 15:39:17 -0400 +Subject: [PATCH] api: update seccomp-syscalls.h + +It appears that the seccomp-syscalls.h header file had gotten out of +sync with the syscalls.csv syscall table, this patch fixes this +disconnect. + +The only edit that is somewhat interesting is that the oldwait4(2) +syscall probably never should have been included in the header file +as it appears to no longer exist (?). + +Reported-by: Mike Frysinger +Acked-by: Tom Hromatka +Signed-off-by: Paul Moore + +(imported from commit 3f47bba7c5c8cc18be80e625eedb2c1823233708) +--- + include/seccomp-syscalls.h | 22 -- + 1 file changed, 16 insertions(+), 6 deletions(-) + +diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +index 7075f3f6..4baa307a 100644 +--- a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +@@ -537,6 +537,8 @@ + + #define __SNR_epoll_pwait __NR_epoll_pwait + ++#define __SNR_epoll_pwait2__NR_epoll_pwait2 ++ + #ifdef __NR_epoll_wait + #define __SNR_epoll_wait __NR_epoll_wait + #else +@@ -1007,6 +1009,10 @@ + + #define __SNR_kill__NR_kill + ++#define __SNR_landlock_add_rule __NR_landlock_add_rule ++#define __SNR_landlock_create_ruleset __NR_landlock_create_ruleset ++#define __SNR_landlock_restrict_self __NR_landlock_restrict_self ++ + #ifdef __NR_lchown + #define __SNR_lchown __NR_lchown + #else +@@ -1141,6 +1147,8 @@ + + #define __SNR_mount __NR_mount + ++#define __SNR_mount_setattr __NR_mount_setattr ++ + #ifdef __NR_move_mount + #define __SNR_move_mount __NR_move_mount + #else +@@ -1277,12 +1285,6 @@ + #define __SNR_olduname__PNR_olduname + #endif + +-#ifdef __NR_oldwait4 +-#define __SNR_oldwait4__NR_oldwait4 +-#else +-#define __SNR_oldwait4__PNR_oldwait4 +-#endif +- + #ifdef __NR_open + #define __SNR_open__NR_open + #else +@@ -1299,6 +1301,8 @@ + + #define __SNR_openat __NR_openat + ++#define __SNR_openat2 __NR_openat2 ++ + #ifdef __NR_pause + #define __SNR_pause __NR_pause + #else +@@ -1327,6 +1331,8 @@ + + #define __SNR_personality __NR_personality + ++#define __SNR_pidfd_getfd __NR_pidfd_getfd ++ + #ifdef __NR_pidfd_open + #define __SNR_pidfd_open __NR_pidfd_open + #else +@@ -1395,6 +1401,8 @@ + + #define __SNR_prlimit64 __NR_prlimit64 + ++#define __SNR_process_madvise
Bug#996025: bullseye-pu: package libseccomp/2.5.1-1+deb11u1
On Sun, 10 Oct 2021 14:34:30 +0200 Felix Geyer wrote: Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu [ Reason ] libseccomp 2.5.1 only knows about syscall up to Linux 5.8. The proposed changes add the syscalls up to Linux 5.14. [ Impact ] Syscalls for Linux 5.9 and 5.10 can't be allowed. Software built with support for newer kernels (often the case in containers) expect newer syscalls to work or return ENOSYS. If that syscall is not supported by libseccomp and a default filter action of returning EPERM is used, such software will break. Therefore you often need to be able to allow a syscall even when the running kernel doesn't support it. [ Tests ] * autopkgtest passes on amd64 * Verified adding a filter for the close_range() syscall works (new in 5.9) * Verified that systemd and Docker run [ Risks ] The changes only extend the syscall csv table and add new syscall defines. [ 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 ] Cherry-pick upstream commits to support syscalls up to Linux 5.14. I've updated the debdiff to include two more cherry-picked patches that add a new syscalls from Linux 5.15 and missing syscall defines. Felixdiff -Nru libseccomp-2.5.1/debian/changelog libseccomp-2.5.1/debian/changelog --- libseccomp-2.5.1/debian/changelog 2020-12-21 10:50:30.0 +0100 +++ libseccomp-2.5.1/debian/changelog 2021-11-25 19:18:20.0 +0100 @@ -1,3 +1,9 @@ +libseccomp (2.5.1-1+deb11u1) bullseye; urgency=medium + + * Add support for syscalls up to Linux 5.15. + + -- Felix Geyer Thu, 25 Nov 2021 19:18:20 +0100 + libseccomp (2.5.1-1) unstable; urgency=medium * New upstream release. diff -Nru libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch --- libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.1/debian/patches/api_update_seccomp-syscalls.h.patch 2021-11-24 19:09:09.0 +0100 @@ -0,0 +1,104 @@ +From 8379ee877612f027f75592c8de5bf7969aa7fb51 Mon Sep 17 00:00:00 2001 +From: Paul Moore +Date: Wed, 27 Oct 2021 15:39:17 -0400 +Subject: [PATCH] api: update seccomp-syscalls.h + +It appears that the seccomp-syscalls.h header file had gotten out of +sync with the syscalls.csv syscall table, this patch fixes this +disconnect. + +The only edit that is somewhat interesting is that the oldwait4(2) +syscall probably never should have been included in the header file +as it appears to no longer exist (?). + +Reported-by: Mike Frysinger +Acked-by: Tom Hromatka +Signed-off-by: Paul Moore + +(imported from commit 3f47bba7c5c8cc18be80e625eedb2c1823233708) +--- + include/seccomp-syscalls.h | 22 -- + 1 file changed, 16 insertions(+), 6 deletions(-) + +diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +index 7075f3f6..4baa307a 100644 +--- a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +@@ -537,6 +537,8 @@ + + #define __SNR_epoll_pwait __NR_epoll_pwait + ++#define __SNR_epoll_pwait2__NR_epoll_pwait2 ++ + #ifdef __NR_epoll_wait + #define __SNR_epoll_wait __NR_epoll_wait + #else +@@ -1007,6 +1009,10 @@ + + #define __SNR_kill__NR_kill + ++#define __SNR_landlock_add_rule __NR_landlock_add_rule ++#define __SNR_landlock_create_ruleset __NR_landlock_create_ruleset ++#define __SNR_landlock_restrict_self __NR_landlock_restrict_self ++ + #ifdef __NR_lchown + #define __SNR_lchown __NR_lchown + #else +@@ -1141,6 +1147,8 @@ + + #define __SNR_mount __NR_mount + ++#define __SNR_mount_setattr __NR_mount_setattr ++ + #ifdef __NR_move_mount + #define __SNR_move_mount __NR_move_mount + #else +@@ -1277,12 +1285,6 @@ + #define __SNR_olduname__PNR_olduname + #endif + +-#ifdef __NR_oldwait4 +-#define __SNR_oldwait4__NR_oldwait4 +-#else +-#define __SNR_oldwait4__PNR_oldwait4 +-#endif +- + #ifdef __NR_open + #define __SNR_open__NR_open + #else +@@ -1299,6 +1301,8 @@ + + #define __SNR_openat __NR_openat + ++#define __SNR_openat2 __NR_openat2 ++ + #ifdef __NR_pause + #define __SNR_pause __NR_pause + #else +@@ -1327,6 +1331,8 @@ + + #define __SNR_personality __NR_personality + ++#define __SNR_pidfd_getfd __NR_pidfd_getfd ++ + #ifdef __NR_pidfd_open + #define __SNR_pidfd_open __NR_pidfd_open + #else +@@ -1395,6 +1401,8 @@ + + #define __SNR_prlimit64 __NR_prlimit64 + ++#define __SNR_process_madvise
Bug#996025: bullseye-pu: package libseccomp/2.5.1-1+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu [ Reason ] libseccomp 2.5.1 only knows about syscall up to Linux 5.8. The proposed changes add the syscalls up to Linux 5.14. [ Impact ] Syscalls for Linux 5.9 and 5.10 can't be allowed. Software built with support for newer kernels (often the case in containers) expect newer syscalls to work or return ENOSYS. If that syscall is not supported by libseccomp and a default filter action of returning EPERM is used, such software will break. Therefore you often need to be able to allow a syscall even when the running kernel doesn't support it. [ Tests ] * autopkgtest passes on amd64 * Verified adding a filter for the close_range() syscall works (new in 5.9) * Verified that systemd and Docker run [ Risks ] The changes only extend the syscall csv table and add new syscall defines. [ 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 ] Cherry-pick upstream commits to support syscalls up to Linux 5.14.diff -Nru libseccomp-2.5.1/debian/changelog libseccomp-2.5.1/debian/changelog --- libseccomp-2.5.1/debian/changelog 2020-12-21 10:50:30.0 +0100 +++ libseccomp-2.5.1/debian/changelog 2021-10-10 13:35:59.0 +0200 @@ -1,3 +1,9 @@ +libseccomp (2.5.1-1+deb11u1) bullseye; urgency=medium + + * Add support for syscalls up to Linux 5.14. + + -- Felix Geyer Sun, 10 Oct 2021 13:35:59 +0200 + libseccomp (2.5.1-1) unstable; urgency=medium * New upstream release. diff -Nru libseccomp-2.5.1/debian/patches/series libseccomp-2.5.1/debian/patches/series --- libseccomp-2.5.1/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.1/debian/patches/series 2021-10-10 13:05:00.0 +0200 @@ -0,0 +1,3 @@ +syscalls_update_the_syscall_table_to_v5.12-rc7.patch +syscalls_add_close_range_syscall.patch +syscalls_update_to_Linux_v5.14-rc7.patch diff -Nru libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch --- libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch 2021-10-10 13:05:00.0 +0200 @@ -0,0 +1,30 @@ +From ac849e7960547d418009a783da654d5917dbfe2d Mon Sep 17 00:00:00 2001 +From: Sascha Grunert +Date: Fri, 16 Jul 2021 12:13:36 +0200 +Subject: [PATCH] syscalls: add close_range() syscall + +The syscall has been added a while ago so we should support resolving +it, too. + +Signed-off-by: Sascha Grunert +Reviewed-by: Tom Hromatka +[PM: subject line tweak] +Signed-off-by: Paul Moore +(imported from commit 01e5750e7c84bb14e5a5410c924bed519209db06) +--- + include/seccomp-syscalls.h | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +index 7b69214c..1ca500be 100644 +--- a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +@@ -476,6 +476,8 @@ + + #define __SNR_close __NR_close + ++#define __SNR_close_range __NR_close_range ++ + #ifdef __NR_connect + #define __SNR_connect __NR_connect + #else diff -Nru libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch --- libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch 2021-10-10 13:05:00.0 +0200 @@ -0,0 +1,73 @@ +From c56a00fe173a7dd5a8326431ae28863ce432bbc1 Mon Sep 17 00:00:00 2001 +From: Paul Moore +Date: Sat, 17 Apr 2021 16:30:48 -0400 +Subject: [PATCH] syscalls: update the syscall table to v5.12-rc7 + +Due to additional ABIs in main we can't do a simple backport or copy +of the syscall table so we are generating it directly in the +release-2.5 branch. + +This patch also fixes the missing faccessat2() #defines in the +seccomp-syscalls.h header file. + +Signed-off-by: Paul Moore +--- + include/seccomp-syscalls.h | 2 ++ + src/syscalls.csv | 6 +- + 2 files changed, 7 insertions(+), 1 deletion(-) + +diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +index 2a4ebd3d..7b69214c 100644 +--- a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +@@ -564,6 +564,8 @@ + + #define __SNR_faccessat __NR_faccessat + ++#define __SNR_faccessat2 __NR_faccessat2 ++ + #ifdef __NR_fadvise64 + #define __SNR_fadvise64 __NR_fadvise64 + #else +diff --git a/src/syscalls.csv b/src/syscalls.csv +index 11d087a6
Bug#996025: bullseye-pu: package libseccomp/2.5.1-1+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu [ Reason ] libseccomp 2.5.1 only knows about syscall up to Linux 5.8. The proposed changes add the syscalls up to Linux 5.14. [ Impact ] Syscalls for Linux 5.9 and 5.10 can't be allowed. Software built with support for newer kernels (often the case in containers) expect newer syscalls to work or return ENOSYS. If that syscall is not supported by libseccomp and a default filter action of returning EPERM is used, such software will break. Therefore you often need to be able to allow a syscall even when the running kernel doesn't support it. [ Tests ] * autopkgtest passes on amd64 * Verified adding a filter for the close_range() syscall works (new in 5.9) * Verified that systemd and Docker run [ Risks ] The changes only extend the syscall csv table and add new syscall defines. [ 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 ] Cherry-pick upstream commits to support syscalls up to Linux 5.14.diff -Nru libseccomp-2.5.1/debian/changelog libseccomp-2.5.1/debian/changelog --- libseccomp-2.5.1/debian/changelog 2020-12-21 10:50:30.0 +0100 +++ libseccomp-2.5.1/debian/changelog 2021-10-10 13:35:59.0 +0200 @@ -1,3 +1,9 @@ +libseccomp (2.5.1-1+deb11u1) bullseye; urgency=medium + + * Add support for syscalls up to Linux 5.14. + + -- Felix Geyer Sun, 10 Oct 2021 13:35:59 +0200 + libseccomp (2.5.1-1) unstable; urgency=medium * New upstream release. diff -Nru libseccomp-2.5.1/debian/patches/series libseccomp-2.5.1/debian/patches/series --- libseccomp-2.5.1/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.1/debian/patches/series 2021-10-10 13:05:00.0 +0200 @@ -0,0 +1,3 @@ +syscalls_update_the_syscall_table_to_v5.12-rc7.patch +syscalls_add_close_range_syscall.patch +syscalls_update_to_Linux_v5.14-rc7.patch diff -Nru libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch --- libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch 2021-10-10 13:05:00.0 +0200 @@ -0,0 +1,30 @@ +From ac849e7960547d418009a783da654d5917dbfe2d Mon Sep 17 00:00:00 2001 +From: Sascha Grunert +Date: Fri, 16 Jul 2021 12:13:36 +0200 +Subject: [PATCH] syscalls: add close_range() syscall + +The syscall has been added a while ago so we should support resolving +it, too. + +Signed-off-by: Sascha Grunert +Reviewed-by: Tom Hromatka +[PM: subject line tweak] +Signed-off-by: Paul Moore +(imported from commit 01e5750e7c84bb14e5a5410c924bed519209db06) +--- + include/seccomp-syscalls.h | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +index 7b69214c..1ca500be 100644 +--- a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +@@ -476,6 +476,8 @@ + + #define __SNR_close __NR_close + ++#define __SNR_close_range __NR_close_range ++ + #ifdef __NR_connect + #define __SNR_connect __NR_connect + #else diff -Nru libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch --- libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch 1970-01-01 01:00:00.0 +0100 +++ libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch 2021-10-10 13:05:00.0 +0200 @@ -0,0 +1,73 @@ +From c56a00fe173a7dd5a8326431ae28863ce432bbc1 Mon Sep 17 00:00:00 2001 +From: Paul Moore +Date: Sat, 17 Apr 2021 16:30:48 -0400 +Subject: [PATCH] syscalls: update the syscall table to v5.12-rc7 + +Due to additional ABIs in main we can't do a simple backport or copy +of the syscall table so we are generating it directly in the +release-2.5 branch. + +This patch also fixes the missing faccessat2() #defines in the +seccomp-syscalls.h header file. + +Signed-off-by: Paul Moore +--- + include/seccomp-syscalls.h | 2 ++ + src/syscalls.csv | 6 +- + 2 files changed, 7 insertions(+), 1 deletion(-) + +diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +index 2a4ebd3d..7b69214c 100644 +--- a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h +@@ -564,6 +564,8 @@ + + #define __SNR_faccessat __NR_faccessat + ++#define __SNR_faccessat2 __NR_faccessat2 ++ + #ifdef __NR_fadvise64 + #define __SNR_fadvise64 __NR_fadvise64 + #else +diff --git a/src/syscalls.csv b/src/syscalls.csv +index 11d087a6
Bug#994285: libseccomp: FTBFS on arm64, armhf, mips64el and mipsel
Hi, On 30.09.21 08:40, Johannes Schauer Marin Rodrigues wrote: Hi Felix, On Fri, 17 Sep 2021 07:15:16 +0200 Johannes Schauer Marin Rodrigues wrote: you set the upstream bug to https://github.com/seccomp/libseccomp/issues/336 but I don't think that is correct. The failures is not the same for the different architectures. mipsel fails different than arm64. I bisected upstream git on both architectures and found out that the arm64 failure was introduced in aa0f858 and the mipsel failure comes from e976080. I contacted upstream about that here: https://github.com/seccomp/libseccomp/issues/338 the problem has no been present in unstable for three weeks. This is blocking my work. Could we revert the offending commits or at least set a deadline up to how long we want to wait for upstream to fix this issue? I'm willing to put work into an NMU in case you don't have the time right now. I've prepared a revert of the problematic commits in the git repo. So far I've tested amd64 build+autopkgtest and mipsel build, no issues yet. Cheers, Felix
Bug#994285: libseccomp: FTBFS on arm64, armhf, mips64el and mipsel
Hi, On 30.09.21 08:40, Johannes Schauer Marin Rodrigues wrote: Hi Felix, On Fri, 17 Sep 2021 07:15:16 +0200 Johannes Schauer Marin Rodrigues wrote: you set the upstream bug to https://github.com/seccomp/libseccomp/issues/336 but I don't think that is correct. The failures is not the same for the different architectures. mipsel fails different than arm64. I bisected upstream git on both architectures and found out that the arm64 failure was introduced in aa0f858 and the mipsel failure comes from e976080. I contacted upstream about that here: https://github.com/seccomp/libseccomp/issues/338 the problem has no been present in unstable for three weeks. This is blocking my work. Could we revert the offending commits or at least set a deadline up to how long we want to wait for upstream to fix this issue? I'm willing to put work into an NMU in case you don't have the time right now. I've prepared a revert of the problematic commits in the git repo. So far I've tested amd64 build+autopkgtest and mipsel build, no issues yet. Cheers, Felix
[Git][security-tracker-team/security-tracker][master] Add links to fixes for Docker CVEs
Felix Geyer pushed to branch master at Debian Security Tracker / security-tracker Commits: fd1859a8 by Felix Geyer at 2021-02-20T09:33:19+01:00 Add links to fixes for Docker CVEs - - - - - 1 changed file: - data/CVE/list Changes: = data/CVE/list = @@ -15065,9 +15065,13 @@ CVE-2021-21286 (AVideo Platform is an open-source Audio and Video platform. It i CVE-2021-21285 (In Docker before versions 9.03.15, 20.10.3 there is a vulnerability in ...) - docker.io 20.10.3+dfsg1-1 NOTE: https://github.com/moby/moby/security/advisories/GHSA-6fj5-m822-rqx8 + NOTE: https://github.com/moby/moby/commit/420b1d36250f9cfdc561f086f25a213ecb669b6f (v19.03) CVE-2021-21284 (In Docker before versions 9.03.15, 20.10.3 there is a vulnerability in ...) - docker.io 20.10.3+dfsg1-1 NOTE: https://github.com/moby/moby/security/advisories/GHSA-7452-xqpj-6rpc + NOTE: https://github.com/moby/moby/commit/1342c51d5e809d2994e6f7e490c8d2b3b12c28ae (v19.03) + NOTE: https://github.com/moby/moby/commit/5eff67a2c294b7e72607e0949ebc0de21710e4d3 (v19.03) + NOTE: https://github.com/moby/moby/commit/67de83e70bca92ae6a08e28a03b3fc8fcca9f3f1 (v19.03) CVE-2021-21283 (Flarum is an open source discussion platform for websites. The "Flarum ...) NOT-FOR-US: Flarum CVE-2021-21282 @@ -55962,6 +55966,7 @@ CVE-2020-15257 (containerd is an industry-standard container runtime and is avai - containerd 1.4.3~ds1-1 - docker.io 20.10.0~rc1+dfsg2-1 NOTE: https://github.com/containerd/containerd/security/advisories/GHSA-36xw-fx78-c5r4 + NOTE: https://github.com/containerd/containerd/commit/3519233e1b5a408c7e92b0af4293000820a0089b (v1.2) NOTE: docker.io switched to systemwide containerd packages in 20.10.0~rc1+dfsg2-1 TODO: check details CVE-2020-15256 (A prototype pollution vulnerability has been found in `object-path` ...) View it on GitLab: https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/fd1859a8870126abf487e5b007ba1e2bedfa687a -- View it on GitLab: https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/fd1859a8870126abf487e5b007ba1e2bedfa687a You're receiving this email because of your account on salsa.debian.org. ___ debian-security-tracker-commits mailing list debian-security-tracker-commits@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-security-tracker-commits
Bug#976090: zfsutils-linux: trim script fails if a pool doesn't support it
Package: zfsutils-linux Version: 0.8.5-1 /usr/lib/zfs-linux/trim fails if one of the pools doesn't support trim (e.g. is on a HDD). zpool trim seems to return exit code 255 in these cases. Since the script is started with sh -e trim is never run on any subsequent pools.
Bug#973533: nmu: util-linux_2.36-3+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu util-linux doesn't know about the new capabilities from Linux 5.9 yet, e.g.: % setpriv --bounding-set -all echo test setpriv: libcap-ng is too old for "all" caps The problem is not actually libcap-ng but util-linux having picked up an old CAP_LAST_CAP when it was built. Rebuilding against linux-libc-dev 5.9 fixes this: nmu util-linux_2.36-3+b1 . linux-any . unstable . -m "Rebuild against linux-libc-dev >= 5.9 to pick up new capabilities" --extra-depends 'linux-libc-dev (>= 5.9)' (not sure if linux-any is supported here)
Bug#973533: nmu: util-linux_2.36-3+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu util-linux doesn't know about the new capabilities from Linux 5.9 yet, e.g.: % setpriv --bounding-set -all echo test setpriv: libcap-ng is too old for "all" caps The problem is not actually libcap-ng but util-linux having picked up an old CAP_LAST_CAP when it was built. Rebuilding against linux-libc-dev 5.9 fixes this: nmu util-linux_2.36-3+b1 . linux-any . unstable . -m "Rebuild against linux-libc-dev >= 5.9 to pick up new capabilities" --extra-depends 'linux-libc-dev (>= 5.9)' (not sure if linux-any is supported here)
[Pkg-utopia-maintainers] Bug#970760: pipewire: PipeWire failing to open devices and loading libspa-alsa
On Wed, 23 Sep 2020 01:18:59 +0200 Paul Menzel wrote: Package: pipewire Version: 0.3.12-1 Severity: normal Forwarded: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/293 Dear Debian folks, If PipeWire is started first in the user session, it prevents PulseAudio from accessing the sound devices causing the sound devices not to found and working [1]. As a workaround, remove the package *pipewire*, or disable the user service and socket units. The fix seems to be part of the 0.3.13 release. It would be great to get this packaged since the issue is quite annoying and pipewire gets pulled in by default with Gnome. Cheers, Felix ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
Bug#970760: pipewire: PipeWire failing to open devices and loading libspa-alsa
On Wed, 23 Sep 2020 01:18:59 +0200 Paul Menzel wrote: Package: pipewire Version: 0.3.12-1 Severity: normal Forwarded: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/293 Dear Debian folks, If PipeWire is started first in the user session, it prevents PulseAudio from accessing the sound devices causing the sound devices not to found and working [1]. As a workaround, remove the package *pipewire*, or disable the user service and socket units. The fix seems to be part of the 0.3.13 release. It would be great to get this packaged since the issue is quite annoying and pipewire gets pulled in by default with Gnome. Cheers, Felix
Bug#972558: gnome-settings-daemon: gsd-housekeeping crashes with filesystem that lack atime
Package: gnome-settings-daemon Version: 3.38.0-2 Tags: fixed-upstream gsd-housekeeping segfaults every few minutes when /home is on a filesystem that lacks atime (for example ZFS with atime=off): > housekeeping-plugin:ERROR:../plugins/housekeeping/gsd-housekeeping-manager.c:139:read_dir_for_purge: > assertion failed: (g_file_info_has_attribute (info, > G_FILE_ATTRIBUTE_TIME_ACCESS)) > Bail out! > housekeeping-plugin:ERROR:../plugins/housekeeping/gsd-housekeeping-manager.c:139:read_dir_for_purge: > assertion failed: (g_file_info_has_attribute (info, > G_FILE_ATTRIBUTE_TIME_ACCESS)) This happens since glib2.0 2.66.0-2 which cherry-picked the following patch: glocalfile-Never-require-G_LOCAL_FILE_STAT_FIELD_ATIME.patch The problem is fixed with this commit (unfortunately not in 3.38.1): https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/647c0af7779757b18708a07b7cfc95e6b1bc79f0
Bug#970632: nmu: util-linux_2.36-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu util-linux doesn't know about the new capabilities from Linux 5.8 yet, e.g.: % setpriv --bounding-set -all echo test setpriv: libcap-ng is too old for "all" caps The problem is not actually libcap-ng but util-linux having picked up an old CAP_LAST_CAP when it was built. Rebuilding against linux-libc-dev 5.8 fixes this: nmu util-linux_2.36-3 . linux-any . unstable . -m "Rebuild against linux-libc-dev >= 5.8 to pick up new capabilities" --extra-depends 'linux-libc-dev (>= 5.8)' (not sure if linux-any is supported here)
Bug#970632: nmu: util-linux_2.36-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu util-linux doesn't know about the new capabilities from Linux 5.8 yet, e.g.: % setpriv --bounding-set -all echo test setpriv: libcap-ng is too old for "all" caps The problem is not actually libcap-ng but util-linux having picked up an old CAP_LAST_CAP when it was built. Rebuilding against linux-libc-dev 5.8 fixes this: nmu util-linux_2.36-3 . linux-any . unstable . -m "Rebuild against linux-libc-dev >= 5.8 to pick up new capabilities" --extra-depends 'linux-libc-dev (>= 5.8)' (not sure if linux-any is supported here)
Bug#962141: docker.io: CVE-2020-13401
Hi security team / maintainers,
On Wed, 03 Jun 2020 20:58:53 +0200 Salvatore Bonaccorso
wrote:
Source: docker.io
Version: 19.03.7+dfsg1-3
Severity: important
Tags: security upstream
Hi,
The following vulnerability was published for docker.io.
CVE-2020-13401[0]:
| An issue was discovered in Docker Engine before 19.03.11. An attacker
| in a container, with the CAP_NET_RAW capability, can craft IPv6 router
| advertisements, and consequently spoof external IPv6 hosts, obtain
| sensitive information, or cause a denial of service.
I've prepared an update for buster-security (debdiff attached).
With the update accept_ra is correctly set to 0 for bridges Docker creates.
@Maintainers:
Do you want me push the patch to the Git repo for unstable or are you
planning to update to 19.03.11 anyway?
Cheers,
Felix
diff -Nru docker.io-18.09.1+dfsg1/debian/changelog
docker.io-18.09.1+dfsg1/debian/changelog
--- docker.io-18.09.1+dfsg1/debian/changelog2019-09-03 19:59:35.0
+0200
+++ docker.io-18.09.1+dfsg1/debian/changelog2020-06-14 22:12:29.0
+0200
@@ -1,3 +1,9 @@
+docker.io (18.09.1+dfsg1-7.1+deb10u2) buster-security; urgency=medium
+
+ * Add upstream patch for CVE-2020-13401 (Closes: #962141)
+
+ -- Felix Geyer Sun, 14 Jun 2020 22:12:29 +0200
+
docker.io (18.09.1+dfsg1-7.1+deb10u1) buster-security; urgency=medium
[ Arnaud Rebillout ]
diff -Nru
docker.io-18.09.1+dfsg1/debian/patches/cve-2020-13401-disable-IPv6-router-advertisements.patch
docker.io-18.09.1+dfsg1/debian/patches/cve-2020-13401-disable-IPv6-router-advertisements.patch
---
docker.io-18.09.1+dfsg1/debian/patches/cve-2020-13401-disable-IPv6-router-advertisements.patch
1970-01-01 01:00:00.0 +0100
+++
docker.io-18.09.1+dfsg1/debian/patches/cve-2020-13401-disable-IPv6-router-advertisements.patch
2020-06-14 22:12:20.0 +0200
@@ -0,0 +1,65 @@
+From 153d0769a1181bf591a9637fd487a541ec7db1e6 Mon Sep 17 00:00:00 2001
+From: Samuel Karp
+Date: Fri, 3 Apr 2020 16:23:18 -0700
+Subject: [PATCH] bridge: disable IPv6 router advertisements
+
+Signed-off-by: Samuel Karp
+---
+ libnetwork/drivers/bridge/bridge.go | 6 ++
+ libnetwork/drivers/bridge/setup_device.go | 19 +++
+ 2 files changed, 25 insertions(+)
+
+diff --git a/drivers/bridge/bridge.go b/drivers/bridge/bridge.go
+index b617ea7bc4..22ee29e238 100644
+--- a/libnetwork/drivers/bridge/bridge.go
b/libnetwork/drivers/bridge/bridge.go
+@@ -679,6 +679,12 @@ func (d *driver) createNetwork(config
*networkConfiguration) (err error) {
+ bridgeAlreadyExists := bridgeIface.exists()
+ if !bridgeAlreadyExists {
+ bridgeSetup.queueStep(setupDevice)
++ bridgeSetup.queueStep(setupDefaultSysctl)
++ }
++
++ // For the default bridge, set expected sysctls
++ if config.DefaultBridge {
++ bridgeSetup.queueStep(setupDefaultSysctl)
+ }
+
+ // Even if a bridge exists try to setup IPv4.
+diff --git a/drivers/bridge/setup_device.go b/drivers/bridge/setup_device.go
+index 548ad951df..1343305ae9 100644
+--- a/libnetwork/drivers/bridge/setup_device.go
b/libnetwork/drivers/bridge/setup_device.go
+@@ -2,6 +2,9 @@ package bridge
+
+ import (
+ "fmt"
++ "io/ioutil"
++ "os"
++ "path/filepath"
+
+ "github.com/docker/docker/pkg/parsers/kernel"
+ "github.com/docker/libnetwork/netutils"
+@@ -49,6 +52,22 @@ func setupDevice(config *networkConfiguration, i
*bridgeInterface) error {
+ return err
+ }
+
++func setupDefaultSysctl(config *networkConfiguration, i *bridgeInterface)
error {
++ // Disable IPv6 router advertisements originating on the bridge
++ sysPath := filepath.Join("/proc/sys/net/ipv6/conf/", config.BridgeName,
"accept_ra")
++ if _, err := os.Stat(sysPath); err != nil {
++ logrus.
++ WithField("bridge", config.BridgeName).
++ WithField("syspath", sysPath).
++ Info("failed to read ipv6
net.ipv6.conf..accept_ra")
++ return nil
++ }
++ if err := ioutil.WriteFile(sysPath, []byte{'0', '\n'}, 0644); err !=
nil {
++ return fmt.Errorf("libnetwork: Unable to disable IPv6 router
advertisement: %v", err)
++ }
++ return nil
++}
++
+ // SetupDeviceUp ups the given bridge interface.
+ func setupDeviceUp(config *networkConfiguration, i *bridgeInterface) error {
+ err := i.nlh.LinkSetUp(i.Link)
diff -Nru docker.io-18.09.1+dfsg1/debian/patches/series
docker.io-18.09.1+dfsg1/debian/patches/series
--- docker.io-18.09.1+dfsg1/debian/patches/series 2019-09-03
17:25:39.0 +0200
+++ docker.io-18.09.1+dfsg1/debian/patches/series 2020-06-14
22:12:29.0 +0200
@@ -20,6 +20,7 @@
cve-2019-13509-03-DebugRequestMiddleware-unconditionally-scrub-data-f
Bug#954852: [Pkg-cmake-team] Bug#954852: cmake depends on libarchive13 3.3.3, but only 3.2.2 is available
Hi Andreas, On 24.03.20 14:14, Martijn de Gouw wrote: Package: cmake Version: 3.13.2-1~bpo9+1 Severity: important Dear Maintainer, cmake in stretch-backports depends on libarchive13 (>= 3.3.3), but libarchive13 (3.2.2-2+deb9u2) is the highest available version for stretch (including backports). Therefore apt update fails when backports are enabled Could you look into this? Seems like it also doesn't build because of this: https://buildd.debian.org/status/package.php?p=cmake=stretch-backports Cheers, Felix
Bug#950627: Regression: Unable to config with CMake
On 10.02.20 02:24, Brian Clinkenbeard wrote: I believe I am also having this issue. "find_package(SDL2 REQUIRED)" in CMakeLists.txt yields the following error: -- Target architecture: x86_64 CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message): Could NOT find SDL2 (missing: SDL2_INCLUDE_DIR) Call Stack (most recent call first): /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE) externals/cmake-modules/FindSDL2.cmake:239 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:155 (find_package) Without access to the code (externals/cmake-modules/FindSDL2.cmake in this case) I can't really help debug it. My guess is that the custom FindSDL2 module is doing something wrong when it tries to find the SDL2 header files. It doesn't seem to search in all system include paths. The headers have been moved from /usr/include/SDL2 to /usr/include//SDL2. Cheers, Felix
Bug#950688: boost1.71: python autopkgtest fails
Source: boost1.71 Version: 1.71.0-5 Severity: serious The boost1.71 python autopkgtest fails with cmake >= 3.16 because the python include path isn't added correctly. In debian/tests/srcs/python/CMakeLists.txt the variable Python_INCLUDE_DIR is used but the correct variable is Python_INCLUDE_DIRS (S at the end). I'm not quite sure why this worked before but Python_INCLUDE_DIR isn't part of the documented FindPython interface. See: https://cmake.org/cmake/help/v3.15/module/FindPython.html Filing as serious since it blocks cmake migrating to testing. Cheers, Felix
Bug#950688: boost1.71: python autopkgtest fails
Source: boost1.71 Version: 1.71.0-5 Severity: serious The boost1.71 python autopkgtest fails with cmake >= 3.16 because the python include path isn't added correctly. In debian/tests/srcs/python/CMakeLists.txt the variable Python_INCLUDE_DIR is used but the correct variable is Python_INCLUDE_DIRS (S at the end). I'm not quite sure why this worked before but Python_INCLUDE_DIR isn't part of the documented FindPython interface. See: https://cmake.org/cmake/help/v3.15/module/FindPython.html Filing as serious since it blocks cmake migrating to testing. Cheers, Felix
Bug#950627: Regression: Unable to config with CMake
Hi, On 2020-02-04 11:41, Kyuma Ohta wrote: Package: libsdl2-dev Version: 2.0.10+dfsg1-2 Severity: important Dear Maintainer, From this version, building any softwares with CMake, not configurable. This is *REGRESSION* of fix of BUG #946496. Please revert this fix, or apply fixes to CMake package, FindSDL.cmake. What exactly is broken? Can you please provide an example with the CMakeLists.txt code and the log output? Felix
Bug#947061: libsdl2-gfx-dev missing SDL2_gfxPrimitives_font.h
Hi David, On 20.12.19 08:10, David Griffith wrote: Package: libsdl2-gfx-dev Version: 1.0.4+dfsg-3 Severity: important I tried to compile a program that requires SDL2_gfxPrimitives_font.h from libsdl2-gfx-dev. Specifically I tried to compile https://github.com/lkundrak/koules from the SDL2 branch. Doing "make -f Makefile.sdl" resulted in this: ... gcc -g3 -Wall -Wno-error=array-bounds -Wno-error=unused-but-set-variable -Wno-error=unused-function -Isdl -DHAVEUSLEEP -D_REENTRANT -I/usr/include/SDL2 -DSOUNDDIR="\"/usr/local/lib/koules\"" -D SOUND -D MOUSE -D NETSUPPORT -DSOUNDSERVER=\"/usr/local/libexec/koules/koules.sndsrv.linux\" -DSOUNDDIR=\"/usr/local/lib/koules\" -DSOUNDDEV=\"/dev/dsp\" -DNODIRECT -DSDLSUPPORT -fomit-frame-pointer -O3 -ffast-math -Dlinux -Wall -Wall -c -o sdl/init.o sdl/init.c sdl/init.c:24:10: fatal error: SDL2_gfxPrimitives_font.h: No such file or directory #include ^~~ compilation terminated. make: *** [Makefile.sdl:54: sdl/init.o] Error 1 This seems to be a bug in koules. SDL2_gfxPrimitives_font.h is not installed by the upstream build system so it's not in the Debian package. The documentation of gfxPrimitivesSetFont says: > \param fontdata Pointer to array of font data. Set to NULL, to reset global font to the default 8x8 font. So calling gfxPrimitivesSetFont with NULL as fontdata is what koules should do instead of using gfxPrimitivesFontdata from a private header file. Cheers, Felix
Accepted snapcast 0.18.0-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 26 Jan 2020 15:59:12 +0100 Source: snapcast Architecture: source Version: 0.18.0-1 Distribution: unstable Urgency: medium Maintainer: Felix Geyer Changed-By: Felix Geyer Changes: snapcast (0.18.0-1) unstable; urgency=medium . * New upstream release. - Switch build-depends from libasio-dev to libboost1.71-dev. - Add libopus-dev to build-depends. * Switch from Makefile to cmake build system. Checksums-Sha1: ded6f11c4eecffbc4ad6fc44fd572e215d0feb5b 1981 snapcast_0.18.0-1.dsc 17cb17cc35400860599177933f1b5b2513032bb1 703820 snapcast_0.18.0.orig.tar.gz d99a222d389ff338acce30723ca7c841c2a72efc 5564 snapcast_0.18.0-1.debian.tar.xz Checksums-Sha256: af42294feff1325a1f91bc19fac3a1e432342f3ff20d6a242ef06d71894310d7 1981 snapcast_0.18.0-1.dsc b9849f7a4c9cfab6aba1ae44dac4daa6563b058b89123f74b17ebf864cac3665 703820 snapcast_0.18.0.orig.tar.gz f3417d6e25b5805c65916ee95037b0eb12a23634c74f1bfa06068c77fbd8ae63 5564 snapcast_0.18.0-1.debian.tar.xz Files: b9ee8b2cc521b728e448a22d7d03a002 1981 sound optional snapcast_0.18.0-1.dsc 59bf29a807e79b9481f1a58c28df0acb 703820 sound optional snapcast_0.18.0.orig.tar.gz dac3a88303ca7c6c67d3c2b1aa01b4fe 5564 sound optional snapcast_0.18.0-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEFkxwUS95KUdnZKtW/iLG/YMTXUUFAl4tqeoACgkQ/iLG/YMT XUXmAw/9H2R56GXi8XceLKSlDLw0xwEQfbUT9vDSLtDEto+RBilc3M/Xoluqg42U NRZNrcTFtfpa29l2Y46im4F60Pf1C4tqmOPD5JKG6uJgB5/Kq28IABJpQjwFgkdr IfAibbDL8U2T++RyBBIv/x5Cfu2OcXU1ilWaZV2OJLksRbJjEWtubj2+CE25ynr6 jC6LMyfEHyc9bkgH17EdQ7y0hqpFxwpp1dFU1haB6UauDBoVaPALDYS94fDa1YBg 9jN+1XYMkTdI8GGrake8CcIH0pICiSRspBXhkZK93tX2P9x3v1WEyHvNcYGKqau1 zssg3lxmhGrGmZfbkbRwKxDqY1DFAKwDIsair5FPCW+OH0MtyugvVOao6MdbyMy4 JMwp8IXxafTUKck0mFDFN8BBpj1qY7ms7BoRbb19MiWWs3CO2kP1uPc7FcITghU+ 65hLHA9xmdRmLneRXrq6//we/LSgSKdyzvXbAs0GJpGrhFToZ3G7COMd2yhIXBza jSQvQWx4zyHengljsII9Af+EmAvq6Hs23hjxSHlxKsVDRHp0Z4Vf9M6sVvFcFD1L O0N3dkNQZxrzBHqT0K9QtfNZchb0g3vR6560ajI52yGYVj3pfesNX4OEIW4wOpgz 2uZwqvUkMpSogkxud8zygw3YfVCCIa2i4gi/6b0TE+s2S3UFGA0= =PgXV -END PGP SIGNATURE-
Bug#949813: purple-plugin-pack: diff for NMU version 2.7.0-3.1
Hi Laurent, On 25.01.20 10:39, Laurent Bigonville wrote: Package: purple-plugin-pack Version: 2.7.0-3 Severity: normal Tags: patch pending Dear maintainer, I've prepared an NMU for purple-plugin-pack (versioned as 2.7.0-3.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Thanks for the NMU! You can move it to DELAYED/0 if you'd like. Cheers, Felix
Bug#909740: libsdl2-dev: No longer multi-arch co-installable
Hi Hugh, On 10.12.19 23:18, Hugh McMaster wrote: At this point, I don’t see anything preventing us from adding the extra include path, although I’m going to do some tests builds of various SDL2-based programs to be certain. Neverball could also be patched to call pkg-config with SDL2_ttf, which, IIRC, has both include paths already (since SDL2_ttf requires SDL2). Unfortunately, this won’t resolve the broader problem. I've pushed this change to the git repo: https://salsa.debian.org/sdl-team/libsdl2/commit/6f58f10282cf9b9af567ec520f0d2c4dc368dbea Did you have time to test-build some reverse-dependencies of SDL2? Cheers, Felix
Bug#948924: [Pkg-cmake-team] Bug#948924: Bug#948924: cmake: FTBFS: test failure against libxslt 1.1.34
On 2020-01-15 03:21, Mattia Rizzolo wrote:
Oh wow.
So it turns out that my attempt at hastening the rebuilds by
pre-installed the new binaries in the choort backfired here.
Having said that, reading that .cmake file is't not clear to me why it
would skip the test if libxslt1-dev is not installed.
That part is in the test code:
https://salsa.debian.org/cmake-team/cmake/blob/master/Tests/CMakeOnly/AllFindModules/CMakeLists.txt#L58
So we can
a) ignore it (until the cmake build somehow pulls in libxslt)
I'd probably go for this and close this bug if you agree.
Yes, I might even disable this particular unit test during the build
since the
autopkgtest is much better suited for it.
b) make cmake build-depend on pkg-config
Your call.
c) move all xslt headers into the same path
I'd rather avoid changing upstream's configuration even more.
Imho moving xsltconfig.h to a different directory deviates much more
from upstream than passing the multiarch path in --includedir.
For example the pkg-config file is technically not correct as it just
sets:
includedir=${prefix}/include
Cflags: -I${includedir}
Of course it mostly just works anyway because everything is in the
default compiler
search path but still ...
There is also a d) have that .cmake file use find_path() also to detect
the path of libxslt/xsltconfig.h, instead of assuming it lives with
xslt.h.
I guess, but you need to make sure that xsltconfig.h really is from the
same version
in case there are multiple libxslts installed.
Cheers,
Felix
Bug#948924: [Pkg-cmake-team] Bug#948924: cmake: FTBFS: test failure against libxslt 1.1.34
On 14.01.20 23:33, Mattia Rizzolo wrote: Hi Felix, thank you for the quick follow up On Tue, Jan 14, 2020 at 10:29:26PM +0100, Felix Geyer wrote: your package failed to rebuild in a sid/amd64 chroot against libslt 1.1.34. The problem seems to be that cmake's FindLibXslt can't deal with the headers being split across /usr/include and /usr/include/. Why do you say so? That part hasn't change for many many years (since 2017! version 1.1.29-3), and in particular doesn't change between the version currently in unstable and experimental: You are right of course. I jumped to my conclusion a bit too early. I forgot to mention indeed that besides dropping the xslt-config I also dropped the static library, I hope that cmakes doesn't depend on it :) Would you consider moving all headers to /usr/include/? This should make libxslt's packaging easier and avoid special cases in build systems like cmake that try to detect it. The fact that the single file xsltconfig.h is within the arch-specific path indeed comes from the packaging and I could move it all; that said, I can't imagine why cmake would even notice such thing. Tring to '#include ' ought to work regardless; if you are depending and checking the specific location of header files that are places in standard location, I deem to say that you are not doing yourself any favour. :) Could you perhaps point me toward the pieace of code in cmake that is dealing with this, and what is failing? Perhaps I'm able to help out a bit. The code is at https://salsa.debian.org/cmake-team/cmake/blob/master/Modules/FindLibXslt.cmake If pkg-config is installed it takes the version from there and everything should work fine. Otherwise it uses the path of libxslt/xslt.h and parses the version from xsltconfig.h in the same path. This fails as xsltconfig.h is in a different path. But as you pointed out this already fails with the package from unstable. The problem is actually triggered by having libxslt1-dev installed in your build chroot. In a clean cmake package build libxslt1-dev is not installed and cmake just skips the tests that fails in your build. So we can a) ignore it (until the cmake build somehow pulls in libxslt) b) make cmake build-depend on pkg-config c) move all xslt headers into the same path Cheers, Felix
Bug#948924: [Pkg-cmake-team] Bug#948924: cmake: FTBFS: test failure against libxslt 1.1.34
Hi Mattia, On 14.01.20 21:42, Mattia Rizzolo wrote: Source: cmake Version: 3.15.4-1 Severity: important Tags: ftbfs User: libx...@packages.debian.org Usertags: ftbfs-34 Dear maintainer, your package failed to rebuild in a sid/amd64 chroot against libslt 1.1.34. In particular, that version is not shipping the xslt-config script anymore, to push people toward pkg-config more. It may be relevant here. Attached is the full build log, hopefully relevant excerpt follows: The problem seems to be that cmake's FindLibXslt can't deal with the headers being split across /usr/include and /usr/include/. Would you consider moving all headers to /usr/include/? This should make libxslt's packaging easier and avoid special cases in build systems like cmake that try to detect it. Imho the disk space overhead when you have libxslt1-dev from multiple archs installed is negligible. Cheers, Felix
Bug#946931: [Pkg-kde-extras] Bug#946931: Bug#946931: quassel-core: apparmor denials
On 11.01.20 02:58, Scott Kitterman wrote:
I gave this a try and I still get apparmor denials:
Jan 10 20:54:13 relay02 kernel: [ 1372.562938] audit: type=1400
audit(1578707653.245:28): apparmor="DENIED" operation="open" profile="/usr/bin/
quasselcore" name="/proc/sys/kernel/random/boot_id" pid=1588
comm="quasselcore" requested_mask="r" denied_mask="r" fsuid=116 ouid=0
Jan 10 20:54:13 relay02 kernel: [ 1372.562955] audit: type=1400
audit(1578707653.245:29): apparmor="DENIED" operation="open" profile="/usr/bin/
quasselcore" name="/var/lib/dbus/machine-id" pid=1588 comm="quasselcore"
requested_mask="r" denied_mask="r" fsuid=116 ouid=0
Jan 10 20:54:13 relay02 kernel: [ 1372.576629] audit: type=1400
audit(1578707653.257:30): apparmor="DENIED" operation="link" profile="/usr/bin/
quasselcore" name="/var/lib/quassel/quasselcore.conf" pid=1588
comm="quasselcore" requested_mask="l" denied_mask="l" fsuid=116 ouid=116
target="/var/lib/quassel/#523668"
Suggestions?
Are you sure you have reloaded the AppArmor profile (apparmor_parser -r
/etc/apparmor.d/usr.bin.quasselcore)?
Maybe restart quasselcore if that still does not work.
I can't see how these denials can happen with the updated profile.
On 11.01.20 14:49, Thomas Schneider wrote:
> I agree on the change '/var/lib/quassel/** rwkl' (although AA convention
> seems to be 'rwkl', but that’s just cosmetic), but I would suggest
> adding '#include ' instead of
> specifying the IDs manually.
quasselcore doesn't use dbus. Qt just happens to read the the dbus machine-id
file. The intent for the dbus-session-strict abstraction is "allow access to
the dbus session bus" so that's not appropriate for quasselcore.
> Said 'abstractions/dbus-session-strict' does not allow access to
> '@{PROC}/sys/kernel/random/boot_id', but I didn’t get any audit messages
> about that after including the abstraction. I haven’t looked any
> further into it, but maybe it isn’t needed?
These files are only read when quasselcore updates its config which likely
doesn't happen very often.
Cheers,
Felix
Bug#909740: libsdl2-dev: No longer multi-arch co-installable
On 08.12.19 14:03, Hugh McMaster wrote: After reviewing the four proposals, I too prefer the pkg-config solution to the others. That said, your proposal using the Debian-specific header is wonderfully simple. In the longer term, I'm hoping there will be a push at some point to no longer install sdl2-config, since that will simplify some of the issues encountered here. Upstream have made it optional to install sdl2-config in 2.0.10. On a second though I fear having the include files of libsdl2 and libsdl2-* in different paths will break some build systems. A random example I quickly found: https://sources.debian.org/src/neverball/1.6.0+git20180603-2/Makefile/ It calls "sdl2-config --cflags" and then would fail to find SDL_ttf.h (from the libsdl2-ttf-dev package) in /usr/include/SDL2. One option would be to add -I/usr/include/SDL2 to sdl2-config or pkg-config but I'm not sure if that would cover all cases. Cheers, Felix
Bug#945489: llvm-toolchain-9: autopkgtest needs update for new version of cmake: fails on warning
Hi LLVM maintainers, On Mon, 25 Nov 2019 21:59:48 +0100 Paul Gevers wrote: > Source: llvm-toolchain-9 > Version: 1:9.0.0-3 > Severity: serious > X-Debbugs-CC: debian...@lists.debian.org, cm...@packages.debian.org > Tags: sid bullseye > User: debian...@lists.debian.org > Usertags: needs-update > Control: affects -1 src:cmake > > Dear maintainers, > > With a recent upload of cmake the autopkgtest of llvm-toolchain-9 fails > in testing when that autopkgtest is run with the binary packages of > cmake from unstable. It passes when run with only packages from testing. > In tabular form: I'd really appreciate an upload to unstable to fix this since it blocks testing migration of cmake. Cheers, Felix
Bug#945489: llvm-toolchain-9: autopkgtest needs update for new version of cmake: fails on warning
Hi LLVM maintainers, On Mon, 25 Nov 2019 21:59:48 +0100 Paul Gevers wrote: > Source: llvm-toolchain-9 > Version: 1:9.0.0-3 > Severity: serious > X-Debbugs-CC: debian...@lists.debian.org, cm...@packages.debian.org > Tags: sid bullseye > User: debian...@lists.debian.org > Usertags: needs-update > Control: affects -1 src:cmake > > Dear maintainers, > > With a recent upload of cmake the autopkgtest of llvm-toolchain-9 fails > in testing when that autopkgtest is run with the binary packages of > cmake from unstable. It passes when run with only packages from testing. > In tabular form: I'd really appreciate an upload to unstable to fix this since it blocks testing migration of cmake. Cheers, Felix
Bug#909740: libsdl2-dev: No longer multi-arch co-installable
Hi Simon, On 27.11.19 20:18, Simon McVittie wrote: > In an attempt to unblock this bug I've implemented several versions of a > solution to it, so that the SDL2 maintainers can choose their favourite > and merge it. > > [...] > > Do the SDL2 maintainers have any comments on these MRs, or preference > between them? Thanks a lot for putting in all the work to implement, test and summarize them! I'm leaning towards patching sdl2-config to call pkg-config (https://salsa.debian.org/sdl-team/libsdl2/merge_requests/5). My hope is that most software uses pkg-config or cmake to find SDL2. This solution wouldn't introduce any weirdness (forwarding header) into the default use cause. I'll merge that one unless someone wants to convince me otherwise soon ;) Cheers, Felix
Bug#944892: oce: autopkgtest fails due to broken CMakeLists.txt
Source: oce Version: 0.18.2-3 Severity: serious The oce autopkgtest fails since cmake 3.15 entered unstable: > CMake Warning (dev) in CMakeLists.txt: > No project() command is present. The top-level CMakeLists.txt file must > contain a literal, direct call to the project() command. Add a line of > code such as > > project(ProjectName) > > near the top of the file, but after cmake_minimum_required(). > > CMake is pretending there is a "project(Project)" command on the first > line. https://ci.debian.net/data/autopkgtest/testing/amd64/o/oce/3434170/log.gz Corresponding cmake documentation: https://cmake.org/cmake/help/v3.16/command/project.html#usage Note that this isn't a new requirement but cmake just started to print a warning. Filing as serious since this blocks cmake migration to testing.
Bug#944892: oce: autopkgtest fails due to broken CMakeLists.txt
Source: oce Version: 0.18.2-3 Severity: serious The oce autopkgtest fails since cmake 3.15 entered unstable: > CMake Warning (dev) in CMakeLists.txt: > No project() command is present. The top-level CMakeLists.txt file must > contain a literal, direct call to the project() command. Add a line of > code such as > > project(ProjectName) > > near the top of the file, but after cmake_minimum_required(). > > CMake is pretending there is a "project(Project)" command on the first > line. https://ci.debian.net/data/autopkgtest/testing/amd64/o/oce/3434170/log.gz Corresponding cmake documentation: https://cmake.org/cmake/help/v3.16/command/project.html#usage Note that this isn't a new requirement but cmake just started to print a warning. Filing as serious since this blocks cmake migration to testing. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#944893: wslay: autopkgtest fails due to broken CMakeLists.txt
Source: wslay Version: 1.1.0-1 Severity: serious The wslay autopkgtest fails since cmake 3.15 entered unstable: > CMake Warning (dev) in CMakeLists.txt: > No project() command is present. The top-level CMakeLists.txt file must > contain a literal, direct call to the project() command. Add a line of > code such as > > project(ProjectName) > > near the top of the file, but after cmake_minimum_required(). > > CMake is pretending there is a "project(Project)" command on the first > line. > This warning is for project developers. Use -Wno-dev to suppress it. https://ci.debian.net/data/autopkgtest/testing/amd64/w/wslay/3434172/log.gz Corresponding cmake documentation: https://cmake.org/cmake/help/v3.16/command/project.html#usage Note that this isn't a new requirement but cmake just started to print a warning. Filing as serious since this blocks cmake migration to testing.
Bug#944892: oce: autopkgtest fails due to broken CMakeLists.txt
Source: oce Version: 0.18.2-3 Severity: serious The oce autopkgtest fails since cmake 3.15 entered unstable: > CMake Warning (dev) in CMakeLists.txt: > No project() command is present. The top-level CMakeLists.txt file must > contain a literal, direct call to the project() command. Add a line of > code such as > > project(ProjectName) > > near the top of the file, but after cmake_minimum_required(). > > CMake is pretending there is a "project(Project)" command on the first > line. https://ci.debian.net/data/autopkgtest/testing/amd64/o/oce/3434170/log.gz Corresponding cmake documentation: https://cmake.org/cmake/help/v3.16/command/project.html#usage Note that this isn't a new requirement but cmake just started to print a warning. Filing as serious since this blocks cmake migration to testing.
Bug#944893: wslay: autopkgtest fails due to broken CMakeLists.txt
Source: wslay Version: 1.1.0-1 Severity: serious The wslay autopkgtest fails since cmake 3.15 entered unstable: > CMake Warning (dev) in CMakeLists.txt: > No project() command is present. The top-level CMakeLists.txt file must > contain a literal, direct call to the project() command. Add a line of > code such as > > project(ProjectName) > > near the top of the file, but after cmake_minimum_required(). > > CMake is pretending there is a "project(Project)" command on the first > line. > This warning is for project developers. Use -Wno-dev to suppress it. https://ci.debian.net/data/autopkgtest/testing/amd64/w/wslay/3434172/log.gz Corresponding cmake documentation: https://cmake.org/cmake/help/v3.16/command/project.html#usage Note that this isn't a new requirement but cmake just started to print a warning. Filing as serious since this blocks cmake migration to testing.
Accepted libseccomp 2.4.2-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 15 Nov 2019 18:12:53 +0100 Source: libseccomp Architecture: source Version: 2.4.2-2 Distribution: unstable Urgency: medium Maintainer: Kees Cook Changed-By: Felix Geyer Changes: libseccomp (2.4.2-2) unstable; urgency=medium . [ Christian Ehrhardt ] * d/rules: fix potential FTFBS after full python3 switch * d/t/control: drop python2 test following the removal of the package . [ Felix Geyer ] * Remove build-dependency on valgrind for mips64el as it's broken there. * Backport patch to define __SNR_ppoll again. - Add api_define__SNR_ppoll_again.patch * Replace custom patch for cython3 with the upstream fix. Checksums-Sha1: 92d2076691897d2e82319659335d26b95624f26e 2413 libseccomp_2.4.2-2.dsc 935391ad5c5f7de2746e80f736c65863c236c2ad 7736 libseccomp_2.4.2-2.debian.tar.xz Checksums-Sha256: cb9c0bc4e318250850ec3a13bff5fe2494fd3e46bedeb453bdb0bb13c69de08b 2413 libseccomp_2.4.2-2.dsc 7bbc0a96fbb8123ce11a946547d6479f481367b5a1342f2ad2a06f8f80de833f 7736 libseccomp_2.4.2-2.debian.tar.xz Files: 2a85a80c48f4bf7d679b300c662a1d74 2413 libs optional libseccomp_2.4.2-2.dsc 970c411a084e6b0f6aada3e398ec6bd3 7736 libs optional libseccomp_2.4.2-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEFkxwUS95KUdnZKtW/iLG/YMTXUUFAl3O3SAACgkQ/iLG/YMT XUU8fBAAhMYAqc6c6hoO+D/sySRHTodpKwYFq+jnELQUXmYPA07Ns9DiEjvC7qwh eQ/4H+uYHwDhJAzZYCR5WizOBYCAkYfK+T2DvH0rO/dayuXcU/TphDqg/H5o+tit gY742uqzmaVAby5VDqxPDBEBvBfSUHBxStbGrqYVknE6KOYtsGM0opRGSkACcC4w 2XeKWEYR3caHoRTBkenl8gHkIl0pfYX9vfFiMaG+hcyJIrfa9V/Mj2YERfLuGLQt KHRh1HD44h7eCJrUztNInW7z8ZJYoLa+J8zJObbZRO+4KbKdNmNMf7K5R5cjk6Z4 f1fWrFPugwOY0t3D3GvAtS0Gi7pCE0Wy6RvosXYpauEzdQow3AkK4HG7PrS2R8zt mqKqmmVEXUIAIo08ukS+yumwUnDRI7sVM9zRga+aiWM4IcZ9YhAqs6noQsdDXEDU rl33cy7jSX3YcUiRlcBpWFbJhJJhF8pnhykUITKxy/6zfmuW2u6eW+teD8d0VjKI lkKi4+UFngHAEIhQY+X/N6QRpj64U5jzFFbtbkaUpDDnjCEkaGoxa3ryovd1M/5U sWsXLSdKDIg+9n0TlP3cZibR2mzCUVtWXz7NjJhq/ygLCXms4Je41q+2Gi6ff7ZC rwKNgCYdv6erun0TDnnHkiSsC+3P/nPtd4d/LeWkYCrcRNhrUnI= =PbZV -END PGP SIGNATURE-
Accepted libseccomp 2.4.2-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 13 Nov 2019 00:00:49 +0100 Source: libseccomp Architecture: source Version: 2.4.2-1 Distribution: unstable Urgency: medium Maintainer: Kees Cook Changed-By: Felix Geyer Closes: 936917 Changes: libseccomp (2.4.2-1) unstable; urgency=medium . [ Christian Ehrhardt ] * New upstream release 2.4.2 for compatibility with newer kernels and fixing FTBFS (LP: #1849785). - drop d/p/python_install_dir.patch (now upstream) - d/rules: adapt to python 3.8 lacking the m modifier on includes see https://wiki.debian.org/Python/Python3.8 - d/p/tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch: fix build time test on arm64 . [ Felix Geyer ] * Drop Python 2 bindings. (Closes: #936917) - Add cython3.patch to use the Python 3 cython variant. Checksums-Sha1: 330c78f33f5cfd27ebb74e4696edc2e304f6b1ea 2438 libseccomp_2.4.2-1.dsc 10966d0d31eefd302710994e017aa14054640680 601014 libseccomp_2.4.2.orig.tar.gz 68ca85a5924e1e09289f20afb9f6ebe86b9a2985 6964 libseccomp_2.4.2-1.debian.tar.xz Checksums-Sha256: f2b6cef457a39382baeb552c23fe4bd6bafcd009c80fb0111976fea90e0d7a51 2438 libseccomp_2.4.2-1.dsc b54f27b53884caacc932e75e6b44304ac83586e2abe7a83eca6daecc5440585b 601014 libseccomp_2.4.2.orig.tar.gz fc345395b70c15540004bc2a1ee587343b7006c374949eef0fb891ec0192f502 6964 libseccomp_2.4.2-1.debian.tar.xz Files: 2049c61cddc75b7cd41761962c07d6b9 2438 libs optional libseccomp_2.4.2-1.dsc ee87fb68ae293883bde9e042c6bc324f 601014 libs optional libseccomp_2.4.2.orig.tar.gz 7b6b5d16f3aa5aa5f53500f791ab4134 6964 libs optional libseccomp_2.4.2-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEFkxwUS95KUdnZKtW/iLG/YMTXUUFAl3LOhgACgkQ/iLG/YMT XUUmag//aKI0miHy42KWq+x1VGrseXdHSqeV2Aj6HKiw4C1TIukSB7s8RyLMSebf KkFmq0HfIp6/hDu2L9jTYsjXfCgF2BipI4Ayh5/tMmaBnE0lTWIWlgD1dILXy9rY c3j7WRNW8nJtFYVGN5V877R7VOLVfsCv5Xl04Un3E+yYO/xuR7q6w+qqfOFmEmju fmU4HbGV15G2w11nQ0LjJAI2gs5ynSTKRSsG2dMIO+Ol83GvetI+APA7vZE4uUGz WYfLKHcjeCHLBiS1tf5XjriFJ5ghdHVoIGsdyz9O7P8QtZWqxVGIX/Jib3FCmq1d 5jAZGhtZqk+M9xdBrF9t5s5cYLUpa5jsGGrWNgUmVcBD0o9yJxd5AcKPaant42tU XxVyNU3wcQ/dPUnCxKI++umABCdRGu5VYeeEafDiSdvwL/hL2m7Cr2L/OluocQW1 lWYrtsHufd03/EApZWUu67SxV4HtnTloiMRG1HwJvpLrQ66Z3Epny0xK9Dr2mdY6 M/69G8BJZ7SV41iM6eF1/E/gTKSkvbFohcWWI+Bb/6Hb2TSA6MKxg64YDzoymUcQ QJoRAuETXWby5ooBuoEW68TBNummH+OPCFNFvdE3hay4bKqJkjMmDKfPm4mrtBo2 +or4yXK0+vubO/NsWU3nCo2golQX9RAT3MWrK8kxlGzoSuUU374= =bjFa -END PGP SIGNATURE-
Accepted cmake 3.15.4-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 12 Nov 2019 20:11:25 +0100 Source: cmake Architecture: source Version: 3.15.4-1 Distribution: unstable Urgency: medium Maintainer: Debian CMake Team Changed-By: Felix Geyer Closes: 944090 Changes: cmake (3.15.4-1) unstable; urgency=medium . * New upstream release. (Closes: #944090) * Disable FIleAPI json-extra test for now as it doesn't seem critical and fails with libjsoncpp 1.7.4. * Switch to debhelper compat level 12. * Pass --fail-missing to dh_missing. Checksums-Sha1: c6621032599f628894ac32c237e715f7741449ea 3046 cmake_3.15.4-1.dsc 0bef17d6067df2672edf63d20c8ec9289a82648d 9270648 cmake_3.15.4.orig.tar.gz 4f3f1855f7f6a9be532f750a03c6b7b74af260bd 28608 cmake_3.15.4-1.debian.tar.xz Checksums-Sha256: 4166e1529c63f5d175f5bd5b781dee4bac348d7360d11bb30fde0f586a94280c 3046 cmake_3.15.4-1.dsc 8a211589ea21374e49b25fc1fc170e2d5c7462b795f1b29c84dd0e984301ed7a 9270648 cmake_3.15.4.orig.tar.gz dac3ec109a38a975fed4859beb9c995b12f5e8908151bf96fbf36340ae2969d9 28608 cmake_3.15.4-1.debian.tar.xz Files: 3c08dabd0b07274606fadb2db32a7ba6 3046 devel optional cmake_3.15.4-1.dsc f63dff1021394b6e37e57d77d26066d1 9270648 devel optional cmake_3.15.4.orig.tar.gz fd30bf257d5bf7c2e827c6828863c202 28608 devel optional cmake_3.15.4-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEFkxwUS95KUdnZKtW/iLG/YMTXUUFAl3LBD0ACgkQ/iLG/YMT XUVxvg//RDzt+5MN1KBmifnj+DhDiDtqLjpe4ildfWX+AjSuLdIrJ9EayhkkMG2B yDESpyT4XITjYrL6fvj2K8K3aFBoAoKEFVxVjopikoPj3VjmG8HP6vQkblf3dHBb fgH0GKU8miZ+OWSZVfOC7di9u8KuXD7xVElC+iGQCXbjhXZGS9Y2QMgQ1xnaVtzD JAD2QOfyXhF9Umr6swmqp/+ZVxd9vEC1rNQUBdNpF7BOajOpV6d+qgzWdM91se1n ATjbJC5IhVUyXMQyMMe9YEjgXdSoQVEmk791SCAkiHUeApA+KAdbZ+TnBfswZVg8 em3+ZPcCgoqbmrVAaM5lEuAmi9+SpS6n8rq1nr+jucFA7MqKcxmrTmAvyAgmaMMQ 5ZnpnyXjE0CmbRXyZH01FFrmDnsnPTLPmwYhk/GSjxD+rF9CJL9UFAYUgoJKS+6H CEl6EukGFOPlhd8j6zHPhw4RRXGC1J1+zjrcUorasc9Oq/LAZVA1smO3A7ksnZXg pVK5H8d8Ca/MXTjHojV58/xdEHBOcQgUZdodvwtMXUvT4mMBYY31JDw41GQKdg3Y jXLySF1nTKNVEPh6K2FJjQsfas5S6sxzrIxc4HGKFBMTP77hFt40y+leSgGFr5EG p2HTgY3Eh9MYM+VPQbHlEIwKN6A/1bnRxbGt3OZVq6PUJuHRmW0= =P2mt -END PGP SIGNATURE-
Bug#943312: [Pkg-cmake-team] Bug#943312: cmake: FindMPI.cmake does not work during cross compilation
Hi Helmut, On 23.10.19 09:47, Helmut Grohne wrote: Package: cmake Version: 3.13.4-1 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs Control: affects -1 + src:flann src:hyphy src:liggghts src:sopt FindMPI.cmake uses compiler wrappers such as mpicc to discover the relevant compiler and linker flags. During cross compilation, these compiler wrappers do not work and they will not be supported on Debian. Beyond breaking cross compilation, you cannot easily combine multiple compiler wrappers (e.g. ccache/distcc/mpicc). It is best to avoid compiler wrappers entirely and for MPI, this is well supported as all major implementations ship pkg-config files since ages. I am asking to stop using mpicc and switch over to pkg-config. Unfortunately, FindMPI.cmake exposes MPI_*_COMPILER and a number of downstreams use these wrappers that cannot be used during cross compilation. Every downstream that wants to be cross buildable must stop using them and I've filed a relevant patch for liggghts. Avoiding MPI_*_COMPILER is easy enough in the majority of cases, because FindMPI.cmake also provides the relevant flags in via other variables. Still, we must maintain backwards compatibility and thus continue supplying MPI_*_COMPILER when it is available (i.e. during native compilation). The attached patch thus tries the wrappers first before falling back to pkg-config. I've tested it with flann, hyphy, liggghts and sopt. Of these, flann and sopt are fixed by this patch. hyphy and liggghts need further patches, which are submitted separately. Please consider applying the attached patch. Helmut Thanks for providing a patch. Have you submitted this upstream? I imagine there isn't anything Debian-specific there? Cheers, Felix
Bug#886758: fixed in libjsoncpp 1.8.4-1
Hi Peter, On Mon, 01 Oct 2018 14:10:30 + Peter Spiess-Knafl wrote: Source: libjsoncpp Source-Version: 1.8.4-1 We believe that the bug you reported is fixed in the latest version of libjsoncpp, which is due to be installed in the Debian FTP archive. A unit test of cmake 3.15 fails because the libjsoncpp version in unstable is too old. It would be great if you could push 1.8.4 to unstable. Cheers, Felix
Bug#943888: check_libs: ignores deleted mmaped files
Package: nagios-plugins-contrib Version: 17.20161211 check_libs doesn't report processes that have mmaped files which have been deleted in the meantime. Importantly that includes libraries that have been upgraded. To reproduce on buster with systemd (but obviously applies to other processes as well): apt install --reinstall libseccomp2 # /usr/lib/nagios/plugins/check_libs No upgraded libs linked in running processes This is caused by on overly aggressive optimization introduced in the lsof-speedup patch here: https://salsa.debian.org/nagios-team/pkg-nagios-plugins-contrib/commit/cd5eacf4faa9f81ec82d57befd44bf6d623c7e26#24f6022115d4e658ca493136b4c17be4fc7e0537_8_8 When reverting that patch to (removing -a +L1) > my $LSOF = '/usr/bin/lsof -nPF0'; it correctly reports systemd processes # /usr/lib/nagios/plugins/check_libs The following processes have libs linked that were upgraded: root: (sd-pam) (544), systemd (1, 543), [...] -- Felix Geyer Berater Tel.: +49 2166 9901-0 Fax:+49 2166 9901-100 E-Mail: felix.ge...@credativ.de PGP:D1DF 8149 7643 8822 7283 92DC 1004 DA1C FF6D B892 https://www.credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Accepted pyudev 0.21.0-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 15 Oct 2019 00:16:32 +0200 Source: pyudev Architecture: source Version: 0.21.0-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Felix Geyer Closes: 942179 Changes: pyudev (0.21.0-2) unstable; urgency=medium . [ Ondřej Nový ] * d/control: Set Vcs-* to salsa.debian.org * d/watch: Use https protocol * d/changelog: Remove trailing whitespaces * d/control: Remove ancient X-Python-Version field * d/control: Remove ancient X-Python3-Version field * Convert git repository from git-dpm to gbp layout * Use debhelper-compat instead of debian/compat. . [ Felix Geyer ] * Backport upstream patches to fix compatbility with pytest 4.6. - Add Use_tool_pytest_instead_of_pytest.diff - Add tests_fix_tests_for_pytest_4.0.diff - Closes: #942179 Checksums-Sha1: 64931ef4df20137f7fbdf502151c3f5c56db5c7e 2197 pyudev_0.21.0-2.dsc dd3ab69e3a5fb7acf7c24e5660a12b916cf0d374 8916 pyudev_0.21.0-2.debian.tar.xz Checksums-Sha256: 70d076fffad7c8257df5c4343f6fa9dd3e5dbf3cfc0faa07ac5d79a973cd5be0 2197 pyudev_0.21.0-2.dsc b150503c3d3ef13878694a69375680b9574e26620793885fc2fb336a12cb48c9 8916 pyudev_0.21.0-2.debian.tar.xz Files: 5e21872d4f504f91589822a3a49c6d97 2197 python optional pyudev_0.21.0-2.dsc afee3b0e74c3eaeb985797d7fa2bab38 8916 python optional pyudev_0.21.0-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEFkxwUS95KUdnZKtW/iLG/YMTXUUFAl2k9BgACgkQ/iLG/YMT XUX/bxAAq/9Iao6wGa970mjBUT+uTJeCXRBzfrmifor0Vc5CGyI65iIKrCJFi7ga ixtTagTGpeYRoRR/GmLN0LkY2cL91ncZjiAPENXExVSp81mfjPJ9dCPNACBknNRN R9npIVNzieIPkBum9bG3eg/OFNuOkWKRSfKtzylpIQRw5xx7sFVIE5W4I8K4BV9v h6lsQt+9a635Mua8pLycE9iaFdghU+fVzAEJ5TEmuQwZI6neDMTa32a91ZePlA+z 9P26bgWz083FnBphMdQlSU89HqH8ehABAYlNNARQiciJ7VdhSM/nGNvXCST1xnRm s5bvyxbp04Ggms+Q8OLA/gAPUZvho8pIM1OVKivzAL0QED4DnzS6sLpyD90Hoz8Y fbV4nA7VjxA9MhBeURgRut9uv+so6KDN1e/ZjW2k3cBOduROsh3vE1TcJHZN+M1w hB0QtuZcBlebpZd8mui8PuQjryw55xZTN6zeFUeBbmqYLXQDc4TkNncl7kV+j4t2 154xNAcLM0+dv1/7MNtORDn5g9ft1IU6weAP2ySHOR3IGD3OcUIsTmmJToCwtiPG flvY43CLA3V3OHt0gFZi4nY2GQZItvdTb5ZkMNmN4rW9G9I4rqiBxcQ2HhxWdKWX 7dtYhXVcCksl71DcdPYcj1WJIFDEgL3ASui3X/hfuop3LprbVeE= =zwdq -END PGP SIGNATURE-
Bug#942179: marked as pending in pyudev
Control: tag -1 pending Hello, Bug #942179 in pyudev reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/modules/pyudev/commit/23dfb71eb035b9ed2000217f485cbfd60f9eb0ea Backport upstream patches to fix compatbility with pytest 4.6. Closes: #942179 (this message was generated automatically) -- Greetings https://bugs.debian.org/942179
Accepted docker.io 18.09.1+dfsg1-7.1+deb10u1 (source) into proposed-updates->stable-new, proposed-updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 03 Sep 2019 19:59:35 +0200 Source: docker.io Architecture: source Version: 18.09.1+dfsg1-7.1+deb10u1 Distribution: buster-security Urgency: medium Maintainer: Dmitry Smirnov Changed-By: Felix Geyer Closes: 932673 933002 Changes: docker.io (18.09.1+dfsg1-7.1+deb10u1) buster-security; urgency=medium . [ Arnaud Rebillout ] * Add upstream patch for CVE-2019-13139 (Closes: #933002). * Add upstream patches for CVE-2019-13509 (Closes: #932673). . [ Felix Geyer ] * Add upstream patch for CVE-2019-14271 * Cherry-pick upstream commits to fix test failures with golang >= 1.11.6-1+deb10u1 Checksums-Sha1: 0a67945ac1d5e9c88d959cd7a44afda3d6f8bc7b 8971 docker.io_18.09.1+dfsg1-7.1+deb10u1.dsc b1ac3ab25cc574dcb5591da41523f58b7bf83ad2 1166180 docker.io_18.09.1+dfsg1.orig-containerd.tar.xz c5a4729ab46d9eab0f4946297be4204725c11a2c 339476 docker.io_18.09.1+dfsg1.orig-distribution.tar.xz 63cda92992cef6b6a348608a2e5389fcc9a6bbce 14356 docker.io_18.09.1+dfsg1.orig-go-events.tar.xz 92ab39b8d119516d6cb9433585b504addc82fff3 13800 docker.io_18.09.1+dfsg1.orig-go-metrics.tar.xz 1e57c0a3cf6b091f25b9240d2422dc27dc0d4f50 481536 docker.io_18.09.1+dfsg1.orig-libnetwork.tar.xz 1bca0b523077489693557a3169a8ea7a09b1568b 699492 docker.io_18.09.1+dfsg1.orig-swarmkit.tar.xz c2950f8af2ea09767abe12af5931bdca8d8f99e4 3971296 docker.io_18.09.1+dfsg1.orig.tar.xz 158a07d0c65e2e74cea73acdf3d5f66ca6ec5bf3 50908 docker.io_18.09.1+dfsg1-7.1+deb10u1.debian.tar.xz Checksums-Sha256: 22480f1863702e52c5dffce6f6c583ccea8a2c6c455e233581e8867ad55b7d67 8971 docker.io_18.09.1+dfsg1-7.1+deb10u1.dsc 7aff7ab4de77930c6aec27261ac321851ed46f46f887ecf9f22ed1edae936b4c 1166180 docker.io_18.09.1+dfsg1.orig-containerd.tar.xz 0cdd3a84b42130518281c09dfe266b4746ba599225df1f0e5755ed3048b876cf 339476 docker.io_18.09.1+dfsg1.orig-distribution.tar.xz 4a8b2b65dd67fcfa3e2e51ba7acb6aeca2f814a25b99c1650b1f7f2886b10dd3 14356 docker.io_18.09.1+dfsg1.orig-go-events.tar.xz 014b93866430d4fe96dd7fffb1f806e091567aca52ba2c090b1619fda21a7a60 13800 docker.io_18.09.1+dfsg1.orig-go-metrics.tar.xz 6d633e558a2a7011e4a0d390914b8d5e13b559313ed6ca6d3b6aad83eb67bda0 481536 docker.io_18.09.1+dfsg1.orig-libnetwork.tar.xz 62eaddd228af6fa5c84e44c8cc1b5be6b03dad57aeeedc32285bafe162cd2a69 699492 docker.io_18.09.1+dfsg1.orig-swarmkit.tar.xz 269e1d602600d4bfa40b4307294d2f93c49c604e5a6ed0fb7e82645c20a3e38f 3971296 docker.io_18.09.1+dfsg1.orig.tar.xz 2fcf0b0ee61554d5754bcc58464c7d04fe0f3e4c4b44c04c2d21e5d82242984c 50908 docker.io_18.09.1+dfsg1-7.1+deb10u1.debian.tar.xz Files: 79d8ed2ee3b098a3029885cedde00aac 8971 admin optional docker.io_18.09.1+dfsg1-7.1+deb10u1.dsc 08d09933a2ad1a584b28bf6e84c0f094 1166180 admin optional docker.io_18.09.1+dfsg1.orig-containerd.tar.xz 9f447ef7fe6c0d24a259d47b0cae4548 339476 admin optional docker.io_18.09.1+dfsg1.orig-distribution.tar.xz 6b86d559756ac9e75747abce8fec3308 14356 admin optional docker.io_18.09.1+dfsg1.orig-go-events.tar.xz 7c17b7a5d73ddaa096a70cd5f0125f3b 13800 admin optional docker.io_18.09.1+dfsg1.orig-go-metrics.tar.xz d2ce2b3e9e68db052981eb44a8d4251b 481536 admin optional docker.io_18.09.1+dfsg1.orig-libnetwork.tar.xz a73ee3f49a794d24f4e61733e17348ec 699492 admin optional docker.io_18.09.1+dfsg1.orig-swarmkit.tar.xz 281586d8c8fd55a39cc16111e00e38f3 3971296 admin optional docker.io_18.09.1+dfsg1.orig.tar.xz a577f3fdbfb794879936cb97dc63961d 50908 admin optional docker.io_18.09.1+dfsg1-7.1+deb10u1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEFkxwUS95KUdnZKtW/iLG/YMTXUUFAl1u1N8ACgkQ/iLG/YMT XUXfzw//WK8BCSovXp8suLCgO7sYEYub1NOoVd20EcsfbRP5/Fjoj3aIsXSCTT1u /20x4cNQ3lKZMWr7+Fr8+AfkCavPJMKKayuuIWLCLSDeJ7PYe92PaaeMJIuOJJDt lQVGYtREgHF3ySxLe27WfXyRzBbWgXZTHKXgXuAJRb22fJmlojI0AbCfYAgznCQ9 k086Yb10KfR0HfA4be7HcgqoZ112sLG3NwoKruaAF2MZ21xbATVco7pBmpy1DFJy g5pBuOwfFmgXZYvjsii8folAij3VidgFnktXyNmi8rw/pHWwc/Q2Z2lelVFH3EOY 0ZqXu3zfOv7ZGI4t6TPh6H+6Xeht89tCwGn9yYGfzaJD3taD1E3845EcMrIMIGBK eKp2+YODNooXDRMEEjFlBtt6KZcFR/+5FG9lM2ywNblzK9yc5utNpYsZHr4M/ptD UH1/pb1afqjifMxKhcXC7l9P7bLsxg6m5MRurF7WCLmZEhPkdUWdySEbx1GSp2CC bdBrXTZghcknWlyciXHj2EAfc4fWBmNU+KcsUM19HLM9igB0g3pmt/piTOSEUJjH iJiJ4YB2uf6MgCVKQGL1mj79CYnacbCwi2JtF5S81MD9JRqv0tiENkv51UHDKQRk iisFejIWFZgjQbXcMvbQy3MOmSXMp9bltoRW5AXalZm8pXOmjZs= =5U/W -END PGP SIGNATURE-
[Pkg-kde-extras] Bug#941994: quassel-core: do not require execmem
On 08.10.19 20:57, Christian Göttsche wrote: Package: quassel-core Version: 1:0.13.1-1 Severity: wishlist Currently quassel-core requires the SELinux process permission execmem. This is not a problem by itself, but for a 24/7 daemon hanging on the internet it would be nice to not require it. Maybe there is a way to disable jit/scripting/... at build time? I assume this is because quassel-core uses QtScript which is the WebKit JavaScript engine with JIT. Upstream has removed the QtScript dependency so execmem shouldn't be necessary anymore with the next upstream major release: https://github.com/quassel/quassel/pull/506 Felix ___ pkg-kde-extras mailing list pkg-kde-extras@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-kde-extras
Bug#941994: quassel-core: do not require execmem
On 08.10.19 20:57, Christian Göttsche wrote: Package: quassel-core Version: 1:0.13.1-1 Severity: wishlist Currently quassel-core requires the SELinux process permission execmem. This is not a problem by itself, but for a 24/7 daemon hanging on the internet it would be nice to not require it. Maybe there is a way to disable jit/scripting/... at build time? I assume this is because quassel-core uses QtScript which is the WebKit JavaScript engine with JIT. Upstream has removed the QtScript dependency so execmem shouldn't be necessary anymore with the next upstream major release: https://github.com/quassel/quassel/pull/506 Felix
Bug#941674: gnome-shell-extension-dashtodock: Not working
Control: tags -1 + fixed-upstream On Thu, 03 Oct 2019 19:10:50 +0200 Domenico Cufalo wrote: Package: gnome-shell-extension-dashtodock Version: 66-1 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Latest upgrade to Gnome 3.34 Upstream has released version 67 that is compatible with Gnome 3.34.
Bug#941674: gnome-shell-extension-dashtodock: Not working
Control: tags -1 + fixed-upstream On Thu, 03 Oct 2019 19:10:50 +0200 Domenico Cufalo wrote: Package: gnome-shell-extension-dashtodock Version: 66-1 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Latest upgrade to Gnome 3.34 Upstream has released version 67 that is compatible with Gnome 3.34.
Bug#941892: gnome-shell-extension-suspend-button: broken with gnome 3.34
Package: gnome-shell-extension-suspend-button Version: 0~git20180827-2 Severity: serious Tags: fixed-upstream The suspend button extension fails to load on Gnome 3.34, making it completely unusable: JS WARNING: [/usr/share/gnome-shell/extensions/suspend-button@laserb/extension.js 165]: reference to undefined property "_actionsItem" Extension "suspend-button@laserb" had error: TypeError: this.systemMenu._actionsItem is undefined This has already been fixed in the upstream git repo: https://github.com/laserb/gnome-shell-extension-suspend-button/commit/1c111de98b6caf87681e60e96ce22d32036ae002
Bug#941892: gnome-shell-extension-suspend-button: broken with gnome 3.34
Package: gnome-shell-extension-suspend-button Version: 0~git20180827-2 Severity: serious Tags: fixed-upstream The suspend button extension fails to load on Gnome 3.34, making it completely unusable: JS WARNING: [/usr/share/gnome-shell/extensions/suspend-button@laserb/extension.js 165]: reference to undefined property "_actionsItem" Extension "suspend-button@laserb" had error: TypeError: this.systemMenu._actionsItem is undefined This has already been fixed in the upstream git repo: https://github.com/laserb/gnome-shell-extension-suspend-button/commit/1c111de98b6caf87681e60e96ce22d32036ae002
Accepted libsdl2 2.0.10+dfsg1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 19 Sep 2019 23:50:39 +0200 Source: libsdl2 Architecture: source Version: 2.0.10+dfsg1-1 Distribution: unstable Urgency: medium Maintainer: Debian SDL packages maintainers Changed-By: Felix Geyer Closes: 892087 924610 939249 Changes: libsdl2 (2.0.10+dfsg1-1) unstable; urgency=medium . * New upstream release. (Closes: #939249) - Fixes warnings with -Wundef on non-x86 hosts. (Closes: #892087) - Fixes CVE-2019-7572, CVE-2019-7573, CVE-2019-7574, CVE-2019-7575, CVE-2019-7576, CVE-2019-7577, CVE-2019-7578, CVE-2019-7635, CVE-2019-7636, CVE-2019-7638 and CVE-2019-13626 (Closes: #924610) * Drop fix-cross-building-907711.patch, fixed upstream. * Bump SHLIBVER to 2.0.10. * Add support for nodoc build-profile. * Switch to debhelper compat level 12. * Cherry-pick upstream fix for CVE-2019-13616. * Mark autopkgtests as superficial. Checksums-Sha1: 0d8ad8c262f1f331083b19e06f4093cd72c00074 2823 libsdl2_2.0.10+dfsg1-1.dsc 36a22d420157c9dad291d8a2ce27065ac5e0213d 2550516 libsdl2_2.0.10+dfsg1.orig.tar.xz b4100b3207c9c7a67a9564a8dbfc474f6f95b7b3 17736 libsdl2_2.0.10+dfsg1-1.debian.tar.xz Checksums-Sha256: e2252a09f6831a1ce3d10b1d6174b0f0f3602b128916d4df490ec6d3fa898fe1 2823 libsdl2_2.0.10+dfsg1-1.dsc 8a425d050c492cd0c352b522beea2c379938c4be0d47607db5b1b68f2ddc7fee 2550516 libsdl2_2.0.10+dfsg1.orig.tar.xz 5a0dc089fda3d01d342f5f38cafb65954c863eadfe3f97259aa14535c0cb13c5 17736 libsdl2_2.0.10+dfsg1-1.debian.tar.xz Files: ba6a204a4b7d58b5e4198bdc5095fb09 2823 libs optional libsdl2_2.0.10+dfsg1-1.dsc 677763f073f2ce8e7600eabd0a938ef0 2550516 libs optional libsdl2_2.0.10+dfsg1.orig.tar.xz c69a3d75bb731e57bdce70645f1a67d6 17736 libs optional libsdl2_2.0.10+dfsg1-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEFkxwUS95KUdnZKtW/iLG/YMTXUUFAl2D+gcACgkQ/iLG/YMT XUUjFBAAhIFjOJs/jO4BG2r3L9g//MyLqrB9UesjEbxOpxOYOLpQpmvLRU1MdN0R MSF4445STPLN60s38xwWPVvpwFDvyDTll7cOaNyhU6RQbGqhbWq5d+GKoKZvVba6 +U/7DDCeilfs870FO6meHDCaMU8J4/5lMW3uXZi+hvicGkjCQUrG2RTOgk42a2GA dm7uBw2eXblntEsgi8+X0uCdkyFCfiKCGldqfTaF36D+/ooEOCRh3Ok+/elrTbOD sKP8+rnErZbjKVVBfHExy6REkWWc+piinPyf3lxtqxZPTg8d9z+MNaT26JNnGJb/ /BIbYXlDk015eQH64GYp+cQfukOdQHHdIc7/IUNKxTv2xWd7iBh3Pu8CcWXU9r+L frv8hyB7QnDEGgi3t3odY6OVB8BY8XaMVclm1f7t9IXFr0MzaNUhGE3/CS1dKkeV 9ivSR/qiRnaT3/ohQZwBb/nl8QTQ2yMaKuW4XyDozXepcPs0MqLaolMmdaSfVucV RVPE8H6foeBr/1FNzxr49WZu7JUZJfMOtKNgyZnR9QbcqEVgifjacYWBq1Vk77cy 6yraE11VbIWcDZG2392GeVpH7N6gbY4C2D3OsN6HiSe++A+UoKwgfQEcWLvoxFry lARS2t9IDvHmcg1MapaYL1PEb1taSWtVFJGt5+xYb523rEJQ5eQ= =bmmh -END PGP SIGNATURE-
[Git][security-tracker-team/security-tracker][master] 2 commits: Correct libsdl2 version of DLA-1714-1
Felix Geyer pushed to branch master at Debian Security Tracker /
security-tracker
Commits:
b1899cfb by Felix Geyer at 2019-09-19T20:16:33Z
Correct libsdl2 version of DLA-1714-1
- - - - -
b367d975 by Felix Geyer at 2019-09-19T20:16:34Z
CVE-2019-7637/libsdl2 already fixed in 2.0.6+dfsg1-4
See https://bugzilla.libsdl.org/show_bug.cgi?id=4497#c6
- - - - -
2 changed files:
- data/CVE/list
- data/DLA/list
Changes:
=
data/CVE/list
=
@@ -26307,8 +26307,7 @@ CVE-2019-7637 (SDL (Simple DirectMedia Layer) through
1.2.15 and 2.x through 2.0
- libsdl1.2 1.2.15+dfsg2-5 (bug #924609)
[buster] - libsdl1.2 (Minor issue)
[stretch] - libsdl1.2 (Minor issue)
- - libsdl2 (bug #924610)
- [buster] - libsdl2 (Minor issue)
+ - libsdl2 2.0.6+dfsg1-4 (bug #924610)
[stretch] - libsdl2 (Minor issue)
NOTE: https://bugzilla.libsdl.org/show_bug.cgi?id=4497
NOTE: https://hg.libsdl.org/SDL/rev/9b0e5c555c0f
=
data/DLA/list
=
@@ -664,7 +664,7 @@
[jessie] - linux-4.9 4.9.144-3.1~deb8u1
[13 Mar 2019] DLA-1714-1 libsdl2 - security update
{CVE-2019-7572 CVE-2019-7573 CVE-2019-7574 CVE-2019-7575 CVE-2019-7576
CVE-2019-7577 CVE-2019-7578 CVE-2019-7635 CVE-2019-7636 CVE-2019-7637
CVE-2019-7638}
- [jessie] - libsdl2 1.2.15-10+deb8u1
+ [jessie] - libsdl2 2.0.2+dfsg1-6+deb8u1
[13 Mar 2019] DLA-1713-1 libsdl1.2 - security update
{CVE-2019-7572 CVE-2019-7573 CVE-2019-7574 CVE-2019-7575 CVE-2019-7576
CVE-2019-7577 CVE-2019-7578 CVE-2019-7635 CVE-2019-7636 CVE-2019-7637
CVE-2019-7638}
[jessie] - libsdl1.2 1.2.15-10+deb8u1
View it on GitLab:
https://salsa.debian.org/security-tracker-team/security-tracker/compare/17ec9cb90c5b3058e1c20e245e79b3c57cf03622...b367d975ccc005be34928ea2da6b859fd1db7c08
--
View it on GitLab:
https://salsa.debian.org/security-tracker-team/security-tracker/compare/17ec9cb90c5b3058e1c20e245e79b3c57cf03622...b367d975ccc005be34928ea2da6b859fd1db7c08
You're receiving this email because of your account on salsa.debian.org.
___
debian-security-tracker-commits mailing list
debian-security-tracker-commits@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-security-tracker-commits
Accepted sdl-image1.2 1.2.12-12 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 18 Sep 2019 19:42:25 +0200 Source: sdl-image1.2 Architecture: source Version: 1.2.12-12 Distribution: unstable Urgency: medium Maintainer: Debian SDL packages maintainers Changed-By: Felix Geyer Changes: sdl-image1.2 (1.2.12-12) unstable; urgency=medium . * Backport upstream security fixes: - CVE-2019-5059 - CVE-2019-5060 - CVE-2019-13616 Checksums-Sha1: 13c93bd1adea445e7b723d242c08342bd4d38bd9 2206 sdl-image1.2_1.2.12-12.dsc 50e44520e9dbc7406e131853cedc679e6a9239d6 13760 sdl-image1.2_1.2.12-12.debian.tar.xz Checksums-Sha256: bc8f24f2ac364bf49cb4dc1aea0df9ffa7955c30ffc55fc328c4c4e98ee69fbf 2206 sdl-image1.2_1.2.12-12.dsc dbd3a7988778cbcb2cb97a9975a27068720330854a7f2a178575f1908d335a3a 13760 sdl-image1.2_1.2.12-12.debian.tar.xz Files: 45e5d6f961ff5dcc3fec130421ccc2bb 2206 libs optional sdl-image1.2_1.2.12-12.dsc 471aa05578c9f4254f5892ddf076247e 13760 libs optional sdl-image1.2_1.2.12-12.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEFkxwUS95KUdnZKtW/iLG/YMTXUUFAl2CbRwACgkQ/iLG/YMT XUXTdA/9GcZ/Eo8Xl9KmRyZNJdeigbiD+dVfP4Q3TcDL+tOZKe94oCAr1ToN6RFo bT2NY5qGBIFjedf4aMMdom3jxvYWCJarEuRVvDucdbLkSiVPlzTNIb6JaQTCBCl/ fXrHJZStglkqFjhxV3sYLdIYxW9CT+NuTeEqnLbv/Ulit+7thtCFew1F0L6Apfzb ue+Nn8I70XRYWKVaH6JjbXI0QjWX4NblqjjqFGN0ZGEIvq2ONLWt9RJ026cjjaq0 cRdJuMfdI2f8GFDj7ICj/KiUUC3tDShP0IDWvY1Nki8Jvtm3bm5AN5i8nhnZkohd +Z1pkU3k8Ui2NlLKIpPbG1+7WSDKLIwDJtbKDtasGBs3cJPjBB34KI11URYGD7vS 515u4XuLblNaYQa4EJgUSUsB4wjgMbMV8+3QnPsow0D1PlDEAI752FfW+3zXSsfp RIYKJeh744IbyjvKcW86/5ZDwZY0mvLFhR/UTJNpVc4hOqwAJUpV9xQSBSDaAp9d 5TEZLqRfFj0eb+rOdj1Rii0UXBgLdmisbudQbz8j4eCs22nashsAwW534PRWBfU3 mAIsITk/5jNl+52HOoPRwRXoiN5vE1wyhcOMSVh9sqUxQJz5EufvqmUHTbEW2KqI G4aiHpJF6QlztK3j6lRU03MKzsVTN9p2/6CHD654QYx/4e7C2Gg= =M90d -END PGP SIGNATURE-
Accepted libsdl1.2 1.2.15+dfsg2-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 17 Sep 2019 22:34:12 +0200 Source: libsdl1.2 Architecture: source Version: 1.2.15+dfsg2-5 Distribution: unstable Urgency: medium Maintainer: Debian SDL packages maintainers Changed-By: Felix Geyer Closes: 924609 Changes: libsdl1.2 (1.2.15+dfsg2-5) unstable; urgency=medium . [ Abhijith PA ] * Fix CVE-2019-7572, CVE-2019-7573, CVE-2019-7574, CVE-2019-7575 CVE-2019-7576, CVE-2019-7577, CVE-2019-7578, CVE-2019-7635, CVE-2019-7636 CVE-2019-7637, CVE-2019-7638 (Closes: #924609) . [ Felix Geyer ] * Fix CVE-2019-13616 Checksums-Sha1: f730f3c178824b681b094a74503204b32a0dd45b 2287 libsdl1.2_1.2.15+dfsg2-5.dsc 3bfa76807b28e4a8b393917ef9526a3ca51bbe65 52004 libsdl1.2_1.2.15+dfsg2-5.debian.tar.xz Checksums-Sha256: e4bf86e0c842b2826a457c358e048033abd54a69981aebbde44168e6e85b5b80 2287 libsdl1.2_1.2.15+dfsg2-5.dsc d2b8826095ac52cd6f776ed312fd58f85663925453be5e9a9524c2d8199a7d18 52004 libsdl1.2_1.2.15+dfsg2-5.debian.tar.xz Files: a67e9a04e6004ff3ba89f1c01f0d47b9 2287 libs optional libsdl1.2_1.2.15+dfsg2-5.dsc 7782b6763c68844f7d17e4bf80c83dbc 52004 libs optional libsdl1.2_1.2.15+dfsg2-5.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEFkxwUS95KUdnZKtW/iLG/YMTXUUFAl2BRCUACgkQ/iLG/YMT XUUIwBAAtY2zt2WqEtIFDp6Sm/C6tNhu/uZx+AZnzxOQZ1as22pPJnTjpdI0CfK4 /z8obUH78xM57DgNZ46XMfzDwTyOHjfx6EoM30vIQM4q8HmQbPB7fSPVynEiulVU RsGvUdY9+eGE24rsbKWYiIPAsi+lJVo+e1sioA8JdUqOwMfdlK3Wi6gYpIU5C2Lc O5SCnp2grfOLNkAPo69pyQfwRjIoY9y0V4J7pDbRiF7otvoGVF3oWSkLci2KMcp1 yCcUy60GE4HDmS8+vl5GCWEzge1qdbcBDilPsSKURnuaFLdWsaSvT4BxNchN+V2n Lha1ko5Nv6KffcZzMYd3bQGX5URL28kWg3Fnd1Pfumtm20IGDlAFjhariBSrPqBh 01TWEiYZvPh0EleZeeLBLrBnEGGtgBDi86QoLoT4D9l37T2dpDbjkOAAYJ26GM5j KbwwUfK7r/WcseibRYTbd7pQOZq1f09J2rwLrLs3MS3/7h1g7zDx2WGZHLfN2JbN 3QAMeHxdejtvYc1BZDU+WPglul05yNmwTjKxMYd1zfs3UqVpvn5FoKbnwFjfnB0C VQ7+dVXk8quiUPt/mZXzCQEEcihrHex0VhvQVGehtLKSnpBiwPkBbvA5MR6uxSCI 4IYnT/jAjp5y+t0q6LpJDv3cCPO13FdZhgRUNozWSi47zEfjmVA= =Wp41 -END PGP SIGNATURE-
