Bug#1071822: libseccomp2: missing support for newer syscalls like fchmodat2 in bookworm(-backports)

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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#1037420: bookworm-pu: package systemd/252.11-1~deb12u1

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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: internal 'getzoneinfofile_stream' method emits a warning message

[Felix Geyer]

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)

[Felix Geyer]

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)

[Felix Geyer]

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

[Felix Geyer]

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#1023959: python-crc32c ftbfs on arm64

[Felix Geyer]

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#1023105: bullseye-pu: package tinyxml/2.6.2-4+deb11u1

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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?

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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#976090: zfsutils-linux: trim script fails if a pool doesn't support it

[Felix Geyer]

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

[Felix Geyer]

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#970760: pipewire: PipeWire failing to open devices and loading libspa-alsa

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

Bug#949813: purple-plugin-pack: diff for NMU version 2.7.0-3.1

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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#944893: wslay: autopkgtest fails due to broken CMakeLists.txt

[Felix Geyer]

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

[Felix Geyer]

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#943312: [Pkg-cmake-team] Bug#943312: cmake: FindMPI.cmake does not work during cross compilation

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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

Bug#941994: quassel-core: do not require execmem

[Felix Geyer]

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

[Felix Geyer]

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

[Felix Geyer]

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#940136: aqbanking-tools: Transaction fails with 9075::Starke Kundenauthentifizierung notwendig.

[Felix Geyer]

On Thu, 12 Sep 2019 23:20:14 +0200 Paul Menzel  wrote:

Package: aqbanking-tools
Version: 5.8.2-0.1
Severity: important

Dear Debian folks,


Unfortunately, I am unable to do a transactions with abtransfers,
and get the error below from the Berlin Volksbank (hbci11.fiducia.de).

9050::Die Nachricht enthält Fehler.+9075::Starke Kundenauthentifizierung 
notwendig.+9800::Dialog abgebrochen+9340::Auftrag abgelehnt.

Other people report this issue with other banking software [1].

Do you know more what is going on? Reading bug #934905 [2], there is
European Payment Service Directive (PSD2). Is that the corresponding
error?


Most likely, yes.

Upstream seems to be working on supporting it but there's no stable release yet:
https://www.aquamaniac.de/rdm/news/10

Cheers,
Felix

Bug#935503: gnucash: HBCI/FinTS module not ready for PSD2, will not work after 14 September 2019

[Felix Geyer]

On Fri, 23 Aug 2019 12:08:10 +0200 Matthias Merz  wrote:

Package: gnucash
Version: 1:3.6-1
Severity: important

Dear Maintainer,

German legislation requires some changes to HBCI, rendering the HBCI
interface of gnucash 3.6-1 in Debian mostly useless due to missing
requirements.

As mentioned in #934905, libaqbanking provides support to pass a
registration code starting with versions 5.8.1 (and maybe 5.7.9) -
both not yet in debian.

Also upstream gnucash (git "maint" branch) provides necessary patches
to accomplish this. (see around
https://github.com/Gnucash/gnucash/commit/100ef2a01decda3ed54cf7204ae38bfd8766521d
for details)


Steps to silence the warnings in the HBCI dialog:

- Compile libaqbanking 5.8.1 (using the upstream tarball and the
  contents of libaqbanking_5.7.8-3.debian.tar.xz with small
  modifications to exported symbols), resulting in 5.8.1~matthias1

- build gnucash git maint branch against new libaqbanking-dev_5.8.1 -
  resulting in gnucash 1:3.6-2~matthias1 which is mentioned below.

Yet unknown: whether this allows the "strong authentication"
(two-factor with a TAN) probably required starting Sept. 14.
Legislation allows some exceptions, but still unclear, which German
bank will require which steps.


This bugreport is filed mostly to request - if possible - a solution
for buster, maybe via backports for a to-be-released 3.6.2, maybe via
stable-updates (if possible at all)?


I have already pushed libaqbanking 5.8.2 to unstable.
gnucash 3.7 has been released containing the mentioned commit.
It would be nice to get 3.7 into unstable soon since having the fix available
in testing is a perquisite to fixing it in stable.

Cheers,
Felix

Bug#934905: libaqbanking35: libaqbanking not ready for PSD2, will not work after 14 September 2019

[Felix Geyer]

On 25.08.19 13:33, Felix Geyer wrote:

Hi Micha,

On Mon, 19 Aug 2019 20:19:28 +0200 Micha Lenk  wrote:

Hi Christian,

I understand your bug report and confirm it to be an issue.

Unfortunately I don't have much capacity at the moment to work on an updated package in a timely 
manner. But I do appreciate and support any volunteer's help.


I've tested libaqbaking 5.8.1 in combination with gnucash 3.6 + patch for the 
registration key.
It seems to work fine, at least the unregistered software warning from the log 
is gone.

The only packaging changes are some new entries in the symbols file (diff 
attached).
Do you mind if I NMU 5.8.1 to unstable?


I've uploaded version 5.8.2 to DELAYED/2 now.

Cheers,
Felix

Bug#939042: RM: sdl-stretch -- ROM; dead upstream, no rdeps

[Felix Geyer]

Package: ftp.debian.org
Severity: normal

Please remove sdl-stretch from unstable.
The last upstream release is from 2011, there is no SDL2 version and there are 
no reverse dependencies.

Cheers,
Felix

Bug#934905: libaqbanking35: libaqbanking not ready for PSD2, will not work after 14 September 2019

[Felix Geyer]

Hi Micha,

On Mon, 19 Aug 2019 20:19:28 +0200 Micha Lenk  wrote:

Hi Christian,

I understand your bug report and confirm it to be an issue.

Unfortunately I don't have much capacity at the moment to work on an 
updated package in a timely manner. But I do appreciate and support any 
volunteer's help.


I've tested libaqbaking 5.8.1 in combination with gnucash 3.6 + patch for the 
registration key.
It seems to work fine, at least the unregistered software warning from the log 
is gone.

The only packaging changes are some new entries in the symbols file (diff 
attached).
Do you mind if I NMU 5.8.1 to unstable?

Cheers,
Felix
diff --color -Nur libaqbanking-5.7.8/debian/libaqbanking35.symbols aqbanking-5.8.1/debian/libaqbanking35.symbols
--- libaqbanking-5.7.8/debian/libaqbanking35.symbols	2019-01-01 16:17:58.0 +0100
+++ aqbanking-5.8.1/debian/libaqbanking35.symbols	2019-08-25 11:35:28.119248252 +0200
@@ -80,6 +80,8 @@
  AB_AccountStatus_fromDb@Base 4.0.0
  AB_AccountStatus_new@Base 4.0.0
  AB_AccountStatus_toDb@Base 4.0.0
+ AB_AccountType_fromChar@Base 5.8.1
+ AB_AccountType_toChar@Base 5.8.1
  AB_Account_GetAccountName@Base 4.0.0
  AB_Account_GetAccountNumber@Base 4.0.0
  AB_Account_GetAccountType@Base 4.0.0
@@ -480,6 +482,10 @@
  AB_Banking_MakeGermanIban@Base 5.2.0beta
  AB_Banking_OnlineFini@Base 4.0.0
  AB_Banking_OnlineInit@Base 4.0.0
+ AB_Banking_RuntimeConfig_GetCharValue@Base 5.8.1
+ AB_Banking_RuntimeConfig_GetIntValue@Base 5.8.1
+ AB_Banking_RuntimeConfig_SetCharValue@Base 5.8.1
+ AB_Banking_RuntimeConfig_SetIntValue@Base 5.8.1
  AB_Banking_SaveAccountConfig@Base 4.2.0
  AB_Banking_SaveAppConfig@Base 4.0.0
  AB_Banking_SaveLocalImExporterProfile@Base 4.2.6

Bug#932755: sdl-image1.2: multiple security issues

[Felix Geyer]

Hi Hugo,

On 27.07.19 19:39, Hugo Lefeuvre wrote:

Dear SDL packages maintainers,

I have uploaded the jessie LTS update.

I will coordinate with the security team for stretch and buster fixes via
point release.

Concerning testing: can I upload the NMU?


Sure, please go ahead!

Cheers,
Felix

Bug#932882: python3-pyroute2: /usr/bin/ss2 shipped in both packages

[Felix Geyer]

Package: python3-pyroute2
Version: 0.5.4-1
Severity: serious

/usr/bin/ss2 is shipped in python-pyroute2 and python3-pyroute2 without any
kind of Conflicts/Replaces resulting in an error when trying to install
both packages:

> Preparing to unpack .../10-python-pyroute2_0.5.4-1_all.deb ...
> Unpacking python-pyroute2 (0.5.4-1) over (0.5.2-1) ...
> Preparing to unpack .../11-python3-pyroute2_0.5.4-1_all.deb ...
> Unpacking python3-pyroute2 (0.5.4-1) over (0.5.2-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-0jYnUK/11-python3-pyroute2_0.5.4-1_all.deb (--unpack):
>  trying to overwrite '/usr/bin/ss2', which is also in package python-pyroute2 
> 0.5.4-1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

Cheers,
Felix

Bug#931739: quassel-core: key too small error after upgrade to buster

[Felix Geyer]

Hi,

On 09.07.19 22:09, Red Omen wrote:

Package: quassel-core
Version: 1:0.13.1-1
Severity: normal

Dear Maintainer,

After upgrading to buster and restarting quassel-core whenever a client 
attempts to connect it fails and the log shows:

Socket error 21: Error loading local certificate, error:140AB18F:SSL 
routines:SSL_CTX_use_certificate:ee key too small


Your quassel-core instance likely has a 1024 bit RSA key which OpenSSL now 
rejects as too weak.
The key is located at /var/lib/quassel/quasselCert.pem You'd want to replace it with at least a 
2048 bit key.


Cheers,
Felix

Bug#923545: Offer to prepare Ninja 1.9.0 package

[Felix Geyer]

Hi Gregor,

On 24.06.19 08:52, Gregor Jasny wrote:

Hello Felix,

I'd like to help you with Ninja 1.9.0 packaging. Would you agree to me preparing ninja 1.9.0 on 
salsa?


Right now I'm taking care of of two packages: v4l-utils (10+ years) and c-ares.


I've imported 1.9.0 into the Git repo. If you have any additional changes 
please open a merge request.
Once buster is released I'll upload it to unstable.

Cheers,
Felix

Bug#924609: Bug#924610: Bug#924609: Ports of CVE patches from Debian LTS for libsdl1.2

[Felix Geyer]

Hi,

On 24.04.19 21:33, Salvatore Bonaccorso wrote:

Hi Kari,

On Wed, Apr 24, 2019 at 07:15:44PM +0300, Kari Pahula wrote:

Hi.

I've ported the CVE patches from Debian LTS for libsdl1.2 in unstable.

First thanks for working on the issues!

I have not reviewed your patches, but just a remark. Never just
forward-port a patchset from an older suite to newer (although the
version is identical here).

Furthermore as Moritz pointed out, at time of writing the bugreport,
only some of the bugs got patches, but not all were merged upstream,
several of the CVEs got later on upstream patches rather then
previously linked ones from the bugzilla.  We should base the upload
based on the current upstream patches which by now should be complete
(but double check the updated references in the security-tracker).



Unfortunately there are still some bug reports without merged fixes.
I've kept the Debian security tracker up-to-date in this regard
(the CVEs with committed patches have a link to them).

Felix

Bug#924270: O: keepassx -- Cross Platform Password Manager

[Felix Geyer]

Hi,

On 11.03.19 04:29, Shengjing Zhu wrote:
> Hi,
> 
> On Mon, Mar 11, 2019 at 3:15 AM Reinhard Tartler  wrote:
>>
>> Package: wnpp
>> Severity: normal
>>
>> Keepassx is a graphical password manager, using the Qt4 toolkit. I'm no
>> longer using this package and have personally switched to
>> 'password-store'.  Unfortunately, I've also failed to get a response
>> from upstream from
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920616 - which
>> recommends to replace keepassx with keepassxc, a community fork,
>> possibly because of unresponsive upstream.
>>
>> I am undecided whether or not this package should be included in Debian
>> 10 (aka buster). It clearly is useful to many people, but its long-term
>> maintenance is unclear.
>>
>> I'd encourage people interested in picking up this package to coordinate
>> with Julian Klode (CC'ed), the Debian keepassxc maintainer.

I've replied to you but unfortunately your mail provider / filter seems to
discard my mails.

I will continue maintaining KeePassX for the time being but likely only do
important bugfixes and other necessary changes (like the port to Qt5).

> I'm also long-time user of keepassx.
> 
> I checked the upstream. In surprise, I found the master version has
> switched to Qt-5. And the upstream author is Felix Geyer, who is DD as
> well.
> 
> Felix, could you have some inputs here?
> 
> In person, I hope keepassx is in buster. I can help uploading the
> master version(with Qt-5) if Qt-4 is really needed to be removed from
> buster. However I'm unsure if RT is fine with this big change(I assume
> it's not ok).

Qt 4 won't be removed from buster. There are still lots of packages using it
in the archive.

Switching keepassx to Qt5 this late (essentially after the freeze) seems
inappropriate to me. I don't see the release team unblocking this.

Cheers,
Felix

Bug#923420: coreutils: mv broken when file system doesn't support RENAME_NOREPLACE

[Felix Geyer]

Package: coreutils
Version: 8.30-2
Severity: serious

Hi,

With those distro patches from version 8.30-2 mv fails on filesystems that don't
support the renameat2 RENAME_NOREPLACE flag.
I noticed this because coreutils 8.30-2 breaks autopkgtest with the qemu runner
which calls mv on a 9p filesystem.

renameatu.patch is the offender as it only changes renameat2() calls to 
renameatu()
in lib/ but not in src/.
As a result some tools call the glibc renameat2() instead of the gnulib one 
which
has appropriate fallbacks.
I haven't checked what other tools are exactly affected (calls are in mv.c, 
shred.c
and copy.c).

After an extended debugging session,
Felix

Bug#923310: ITS: ninja-build

[Felix Geyer]

Hi,

On 2019-02-26 08:09, Mo Zhou wrote:

Source: ninja-build
X-Debbugs-CC: fge...@debian.org

Hi Felix,

The last upload for ninja-build dates back to more than 1 year ago.


There are some changes lined up but nothing that warranted an upload:
https://salsa.debian.org/debian/ninja-build/commits/master

Just because a package hasn't been uploaded in a while doesn't mean it 
has been abandoned.

It might just continue to work without problems.


The package looks quite old since it has an ancient std-ver.


I'm sorry but that's a really bad criteria. In the end it's just a 
number in a control field.
Is there anything in the package that you think needs improving besides 
bumping a number?



I intend to help update the package and import the latest upstream
version 1.9.0 then upload it to unstable, does that sound good to you?
This could be either an ITS or an NMU, at your preference.


At this stage in the release I consider it a very bad idea since many 
packages use ninja to build.
I don't want to potentially break those in the freeze by uploading a new 
major upstream release.



I wanted to fix [1] but clearly we cannot do that at this stage.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849513


As mentioned in the bug report I don't see a reason to "fix" this.
I should just close that bug.

Felix

Bug#921618: virt-manager: Unnecessary dependency on python-requests

[Felix Geyer]

Package: virt-manager
Version: 1:2.0.0-3

virt-manager depends on python-requests but doesn't actually use it 
(it's Python 3 now anyway).


'requests' is only imported from virtinst/urlfetcher.py which is 
installed into the virtinst package and already has the correct 
python3-requests dependency.


Felix

--
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

Bug#916487: [Pkg-cmake-team] Bug#911400: Bug#916487: cmake: Please add small workaround for m68k

[Felix Geyer]

Hi Adrian,

On 15.12.18 14:43, John Paul Adrian Glaubitz wrote:
> Control: forcemerge 911400 916487
>
> Just realized that I already reported the issue as #911400, thus merging
> with #916487. Re-attaching the patch just to make sure the patch lands
> in the visible bug report.

I'm not really happy about the part of the patch that just removes
all CFLAGS and CXXFLAGS. Which flag(s) actually cause the problem?
I'm guessing -O2? It would be better to use DEB_*_MAINT_STRIP.

Cheers,
Felix

Bug#896811: stretch-pu: package icinga2/2.6.0-2+deb9u1

[Felix Geyer]

Hi Julien,

On 03.12.18 08:16, Julien Cristau wrote:

Looks fine to upload, go ahead.


Thanks, uploaded.

Cheers,
Felix

Bug#916058: chromium: Widevine not working in chromium 71

[Felix Geyer]

Package: chromium
Version: 71.0.3578.80-1
Tags: patch

Hi,

In chromium 71 the widevine adapter stopped working.

The widevine_cdm_version.h include seems to be hidden behind
#ifs that are only enabled when the Widevine CDM is bundled.

Attached is a debdiff that fixes this (adapted from the Arch Linux package).

Cheers,
Felix
--- a/debian/patches/fixes/widevine-revision.patch
+++ b/debian/patches/fixes/widevine-revision.patch
@@ -10,3 +10,14 @@
 +#define WIDEVINE_CDM_VERSION_STRING "undefined"
  
  #endif  // WIDEVINE_CDM_VERSION_H_
+--- a/chrome/common/chrome_content_client.cc
 b/chrome/common/chrome_content_client.cc
+@@ -99,7 +99,7 @@
+ // Registers Widevine CDM if Widevine is enabled, the Widevine CDM is
+ // bundled and not a component. When the Widevine CDM is a component, it is
+ // registered in widevine_cdm_component_installer.cc.
+-#if BUILDFLAG(BUNDLE_WIDEVINE_CDM) && 
!BUILDFLAG(ENABLE_WIDEVINE_CDM_COMPONENT)
++#if BUILDFLAG(ENABLE_WIDEVINE) && !BUILDFLAG(ENABLE_WIDEVINE_CDM_COMPONENT)
+ #define REGISTER_BUNDLED_WIDEVINE_CDM
+ #include "third_party/widevine/cdm/widevine_cdm_common.h"  // nogncheck
+ // TODO(crbug.com/663554): Needed for WIDEVINE_CDM_VERSION_STRING. Support

Bug#915148: [Pkg-cmake-team] Bug#915148: cmake: regression in ros-ros-comm build

[Felix Geyer]

Hi,

On 01.12.18 06:31, Gianfranco Costamagna wrote:

Package: cmake
Version: 3.13.1-1
Severity: serious
Affects: ros-ros-comm

A simple ros-ros-comm rebuild now fails with the new cmake in unstable,
due to lpthread not being found as target.
I don't know if catkin is to blame, or something else, but clearly the
old cmake in testing is not having issues.

I'm opening this bug to prevent testing migration, until the problem is
sorted out (in one way or the other)
snip of the failure:

-- Using CATKIN_TEST_RESULTS_DIR: 
/<>/ros-ros-comm-1.14.3+ds1/obj-x86_64-linux-gnu/test_results
-- Found gtest: gtests will be built
-- nosetests not found, Python tests can not be run (try installing package 
'python-nose')
-- catkin 0.7.14
-- Boost version: 1.67.0
-- Found the following Boost libraries:
--   system
--   thread
--   chrono
--   date_time
--   atomic
CMake Error at 
obj-x86_64-linux-gnu/devel/share/rostest/cmake/rostestConfig.cmake:146 
(message):
   Project 'rostest' tried to find library '-lpthread'.  The library is
   neither a target nor built/installed properly.  Did you compile project
   'rostest'? Did you find_package() it before the subdirectory containing its
   code is included?
Call Stack (most recent call first):
   /usr/share/catkin/cmake/catkinConfig.cmake:87 (find_package)
   tools/rostest/CMakeLists.txt:23 (find_package)


-- Configuring incomplete, errors occurred!
See also 
"/<>/ros-ros-comm-1.14.3+ds1/obj-x86_64-linux-gnu/CMakeFiles/CMakeOutput.log".
See also 
"/<>/ros-ros-comm-1.14.3+ds1/obj-x86_64-linux-gnu/CMakeFiles/CMakeError.log".
cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
==> CMakeCache.txt <==


This problem occurs since my commit adds ${CMAKE_THREAD_LIBS_INIT} 
("-lpthread") to
Boost_LIBRARIES when needed:
https://gitlab.kitware.com/cmake/cmake/commit/bd831ed0948a1e99f573f0056f2bee5d3b21009e

ros-catkin iterates over dependency libraries (Boost_LIBRARIES among other 
things) and does this:
https://sources.debian.org/src/ros-catkin/0.7.14-7/cmake/templates/pkgConfig.cmake.in/#L118

Until my commit Boost_LIBRARIES only contained absolute paths to boost 
libraries so that code
just passes them on. For the "-lpthread" case it calls find_library(... 
"-lpthread") which fails.

Adding something like this would probably fix it:
>   elseif(${library} MATCHES "^-l")
>     list(APPEND @PROJECT_NAME@_LIBRARIES ${library})

CCing Brad, maybe you could comment if ros-catkin should expect -l... entries 
there or FindBoost
needs to be changed?

Cheers,
Felix

Bug#849513: d/control: Conflicts can be removed

[Felix Geyer]

Hi,

On Mon, 19 Nov 2018 21:40:46 +0100 Mathieu Malaterre  wrote:

While the binary name is a long story, I believe it does not make
sense to continue keeping:

$ cat d/control
...
Conflicts: ninja


Indeed, I'll remove it with the next upload.


With regard to renaming the package:
I really don't think it's worth the trouble of going through NEW, doing the 
transitional
package dance and having all reverse (build-)dependencies updated.

The upstream domain is ninja-build.org, other distros also call it ninja-build 
so
it's not really a surprising name that is hard to find.

Felix

Bug#915039: CVE-2018-19516: HTML email can open browser window automatically

[Felix Geyer]

Source: kf5-messagelib
Version: 4:18.08.1-1
Severity: grave
Tags: upstream security

Hi,

KDE published the following security advisory (CVE-2018-19516):

> messagelib by default displays emails as plain text, but gives the user
> an option to "Prefer HTML to plain text" in the settings and if that option
> is not enabled there is way to enable HTML display when an email contains 
> HTML.
>
> Some HTML emails can trick messagelib into opening a new browser window when
> displaying said email as HTML.
>
> This happens even if the option to allow the HTML emails to access
> remote servers is disabled in KMail settings.
>
> This means that the owners of the servers referred in the email can see
> in their access logs your IP address.

https://www.kde.org/info/security/advisory-20181128-1.txt

Cheers,
Felix

Bug#908357: stretch-pu: package libseccomp/2.3.1-2.1+deb9u1

[Felix Geyer]

On 01.11.18 21:24, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2018-09-09 at 00:15 +0200, Felix Geyer wrote:
>> libseccomp in stretch doesn't support some Linux 4.9 syscalls and
>> statx so whitelisting/blacklisting them is not possible.
>>
>> While statx is not supported in 4.9 it's still important to support
>> it in libseccomp as there is some software that calls statx() and
>> checks the error code for ENOSYS. Killing the process or returning
>> EACCES in response to statx by the seccomp filter breaks this of
>> course.
>>
> 
> Please go ahead; sorry for the delay.

Thanks, uploaded.

Cheers,
Felix

Bug#912475: [Pkg-cmake-team] Bug#912475: qtmultimedia-opensource-src: FTBFS on hurd: no qtaudioengine

[Felix Geyer]

Hi,

On 01.11.18 00:38, Samuel Thibault wrote:
> The link line contains /usr/lib/i386-gnu/libsndio.so in one case, and
> -lsndio in the other case. I don't know why cmake makes a difference. In
> both cases we have absolute paths in
>
> ./build-tree/CMakeFiles/OpenAL.dir/build.make:libopenal.so.1.19.1: 
> /usr/lib/i386-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:OpenAL_LIB_DEPENDS:STATIC=general;-pthread;general;common;general;/usr/lib/i386-gnu/libsndio.so;general;rt;general;pthread;general;dl;general;atomic;general;m;
> ./build-tree/CMakeCache.txt:SOUNDIO_LIBRARY:FILEPATH=/usr/lib/i386-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_SoundIO:INTERNAL=[/usr/lib/i386-gnu/libsndio.so][/usr/include][v()]
>
>
> ./build-tree/CMakeFiles/OpenAL.dir/build.make:libopenal.so.1.19.1: 
> /usr/lib/x86_64-linux-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:OpenAL_LIB_DEPENDS:STATIC=general;-pthread;general;common;general;/usr/lib/x86_64-linux-gnu/libsndio.so;general;rt;general;pthread;general;dl;general;atomic;general;m;
> ./build-tree/CMakeCache.txt:SOUNDIO_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libsndio.so
> ./build-tree/CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_SoundIO:INTERNAL=[/usr/lib/x86_64-linux-gnu/libsndio.so][/usr/include][v()]
>
> cmake maintainers, do you have any idea why
> /usr/lib/i386-gnu/libsndio.so does not get turned into -lsndio while
> /usr/lib/x86_64-linux-gnu/libsndio.so does?

The build failure is most likely caused by a bug in sndio, see #912443 and 
#912453

Felix

Bug#908290: [zfs-linux] Please package 0.7.10

[Felix Geyer]

Control: severity -1 serious

On Sat, 8 Sep 2018 00:33:57 -0400 Antonio Russo  
wrote:

The recent release of zfsonlinux 0.7.10 adds support for Linux kernel 4.18.


Bumping severity as Linux 4.18 has reached testing.

Felix

Bug#906794: quassel-core: postinst script fails on Debian testing

[Felix Geyer]

Hi,

On 21.08.18 08:15, Joseph Nuthalapati wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: quassel-core
Version: 1:0.12.5-2
Severity: important

Dear maintainer,

Installation of quassel-core fails on Debian testing. When "dpkg
- --configure -a" is run, the following error is shown.

root@computer:~# dpkg --configure -a
Setting up quassel-core (1:0.12.5-2) ...
Creating quassel group ...
Creating quasselcore user ...
Generating SSL certificate as /var/lib/quassel/quasselCert.pem
... su: Permission denied dpkg: error processing package
quassel-core (--configure):
  installed quassel-core package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
  quassel-core


It looks like you have some PAM configuration that disallows root to switch users with 
"su".

I'll change the postinst script to "runuser" which is more appropriate for this 
anyway.

Cheers,
Felix

Bug#908357: stretch-pu: package libseccomp/2.3.1-2.1+deb9u1

[Felix Geyer]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

libseccomp in stretch doesn't support some Linux 4.9 syscalls and statx so
whitelisting/blacklisting them is not possible.

While statx is not supported in 4.9 it's still important to support it in
libseccomp as there is some software that calls statx() and checks the error
code for ENOSYS. Killing the process or returning EACCES in response to statx
by the seccomp filter breaks this of course.

A concrete example: Qt >= 5.10 in a Docker container is completely broken as
it tries to use statx() and Docker employs syscall whitelisting by default.

debdiff is attached. While the patches are somewhat large they really only
add entries to the syscall structs.

Cheers,
Felix
diff -Nru libseccomp-2.3.1/debian/changelog libseccomp-2.3.1/debian/changelog
--- libseccomp-2.3.1/debian/changelog   2016-11-17 10:16:44.0 +0100
+++ libseccomp-2.3.1/debian/changelog   2018-09-08 21:34:13.0 +0200
@@ -1,3 +1,11 @@
+libseccomp (2.3.1-2.1+deb9u1) stretch; urgency=medium
+
+  * Add support for Linux 4.9 syscalls:
+preadv2, pwritev2, pkey_mprotect, pkey_alloc and pkey_free
+  * Add support for the statx syscall.
+
+ -- Felix Geyer   Sat, 08 Sep 2018 21:34:13 +0200
+
 libseccomp (2.3.1-2.1) unstable; urgency=medium
 
   [ Martin Pitt ]
diff -Nru libseccomp-2.3.1/debian/patches/29-syscalls-linux4.9.patch 
libseccomp-2.3.1/debian/patches/29-syscalls-linux4.9.patch
--- libseccomp-2.3.1/debian/patches/29-syscalls-linux4.9.patch  1970-01-01 
01:00:00.0 +0100
+++ libseccomp-2.3.1/debian/patches/29-syscalls-linux4.9.patch  2018-09-08 
21:34:13.0 +0200
@@ -0,0 +1,528 @@
+From e8ef0f9a32e33bd5ec78eae9e3bf91684ce91e0a Mon Sep 17 00:00:00 2001
+From: Justin Cormack 
+Date: Thu, 2 Feb 2017 19:19:27 -0500
+Subject: [PATCH] arch: update syscalls for Linux 4.9
+
+Add support for the following syscalls added in Linux v4.9:
+
+- preadv2 and pwritev2
+- pkey_mprotect, pkey_alloc, pkey_free
+
+Signed-off-by: Justin Cormack 
+[PM: update subject line, description, and some whitespace]
+Signed-off-by: Paul Moore 
+(imported from commit d9102f12fd39bd77151a1f630fcfc8c80f86c55c)
+---
+ include/seccomp.h.in  | 15 +++
+ src/arch-aarch64-syscalls.c   |  7 ++-
+ src/arch-arm-syscalls.c   |  7 ++-
+ src/arch-mips-syscalls.c  |  7 ++-
+ src/arch-mips64-syscalls.c|  7 ++-
+ src/arch-mips64n32-syscalls.c |  7 ++-
+ src/arch-ppc-syscalls.c   |  7 ++-
+ src/arch-ppc64-syscalls.c |  7 ++-
+ src/arch-s390-syscalls.c  |  7 ++-
+ src/arch-s390x-syscalls.c |  7 ++-
+ src/arch-x32-syscalls.c   |  5 +
+ src/arch-x86-syscalls.c   |  7 ++-
+ src/arch-x86_64-syscalls.c|  7 ++-
+ 13 files changed, 86 insertions(+), 11 deletions(-)
+
+diff --git a/include/seccomp.h.in b/include/seccomp.h.in
+index 6bf6751..70f1e20 100644
+--- a/include/seccomp.h.in
 b/include/seccomp.h.in
+@@ -1603,6 +1603,21 @@ int seccomp_export_bpf(const scmp_filter_ctx ctx, int 
fd);
+ #define __NR_userfaultfd  __PNR_userfaultfd
+ #endif /* __NR_userfaultfd */
+ 
++#define __PNR_pkey_mprotect   -10201
++#ifndef __NR_pkey_mprotect
++#define __NR_pkey_mprotect__PNR_pkey_mprotect
++#endif /* __NR_pkey_mprotect */
++
++#define __PNR_pkey_alloc  -10202
++#ifndef __NR_pkey_alloc
++#define __NR_pkey_alloc   __PNR_pkey_alloc
++#endif /* __NR_pkey_alloc */
++
++#define __PNR_pkey_free   -10203
++#ifndef __NR_pkey_free
++#define __NR_pkey_free__PNR_pkey_free
++#endif /* __NR_pkey_free */
++
+ #ifdef __cplusplus
+ }
+ #endif
+diff --git a/src/arch-aarch64-syscalls.c b/src/arch-aarch64-syscalls.c
+index 357f290..6c04ad5 100644
+--- a/src/arch-aarch64-syscalls.c
 b/src/arch-aarch64-syscalls.c
+@@ -26,7 +26,7 @@
+ #include "arch.h"
+ #include "arch-aarch64.h"
+ 
+-/* NOTE: based on Linux 4.5-rc4 */
++/* NOTE: based on Linux 4.9 */
+ const struct arch_syscall_def aarch64_syscall_table[] = { \
+   { "_llseek", __PNR__llseek },
+   { "_newselect", __PNR__newselect },
+@@ -254,11 +254,15 @@ const struct arch_syscall_def aarch64_syscall_table[] = 
{ \
+   { "pipe", __PNR_pipe },
+   { "pipe2", 59 },
+   { "pivot_root", 41 },
++  { "pkey_alloc", __PNR_pkey_alloc },
++  { "pkey_free", __PNR_pkey_free },
++  { "pkey_mprotect", __PNR_pkey_mprotect },
+   { "poll", __PNR_poll },
+   { "ppoll", 73 },
+   { "prctl", 167 },
+   { "pread64", 67 },
+   { "preadv", 69 },
++  { "preadv2", 392 },
+   { "prlimit64", 261 },
+   { "process_vm_readv", 270 },
+   { "process_vm_writev", 271 },
+@@ -269,6 +273,7 @@ const struct arch_syscall_def aarch64_syscall_table[] = 

Bug#903261: ITA: libapache2-mod-fcgid

[Felix Geyer]

Hi Xavier,

On 18.08.2018 13:56, Xavier wrote:

Hello Felix,

I'm going to adopt libapache2-mod-fcgid.


That's great!


I'm DM for now but approved for
DD (https://nm.debian.org/process/495).  Package is ready with the
following changes:

   * Taken (Closes: #903261)
   * debian/copyright:
 - update format using packaging-manuals/copyright-format/1.0/
 - add Debian files copyright
   * Add myself to maintainer
   * Bump debhelper compatibility to 10
   * Remove --parallel option for dh
   * Add upstream/metadata file
   * Drop --dbgsym-migration (stable is > 2.3.9)


I've only added it in the last upload so it needs to be kept for buster.


   * Add doc-base entry
   * debian/rules: remove useless options
   * Declare compliance with policy 4.2.0
   * Add NOTICE-FCGID and STATUS-FCGID in docs
   * autopkgtest:
 - don't use systemd to start apache2
 - add "allow-stderr" to ignore apache2 warnings

Could you give me some rights on
https://salsa.debian.org/debian/libapache2-mod-fcgid to push this on git
? So you could review my changes before adoption.


Sure, done.

Cheers,
Felix

Bug#905140: [Pkg-cmake-team] Bug#905140: Bug #905140 in cmake marked as pending

[Felix Geyer]

Hi,

On 09.08.2018 22:38, Svante Signell wrote:

Hello,

What about the bugs with patches, e.g. for Hurd and kFreeBSD. Still
somebody needs to NMU this package... You don't seem interested in
fixing bugs to your package, except RC ones.

Not the ideal way Debian maintainers should work with their packages...


Instead of making wild accusations I suggest that instead you respond
to questions on bugs you opened.
I'm not interested in maintaining patches for things that clearly belong 
upstream.
Once upstream has reviewed the changes I'm happy to cherry-pick them.

#905138 on 2018-08-01:

Have you forwarded your non-packaging changes upstream to cmake / libuv
(#905140 is already fixed in 3.12)?
I really don't want to carry those as patches.


The same applies to #900240

Cheers,
Felix

Bug#887809: RFP: borgmatic -- A wrapper script for Borg backup software that creates and prunes backups

[Felix Geyer]

Hi,

On Tue, 31 Jul 2018 11:17:46 +0200 Andrej Shadura  wrote:
> Hi Olivier,
> 
> On Mon, 30 Jul 2018, 13:03 Olivier Berger,
>  wrote:
> > Out of curiosity, have you made any progress towards packaging borgmatic ?>
> 
> Unfortunately, I have not. I figured I don’t really need it myself,
> since I’m just running a one-liner from a systemd timer. I may package
> it one day though, but feel free to take it over.

FWIW the borgmatic dependency pykwalify is considered non-free by Debian because
its license contains the "The Software shall be used for Good, not Evil." 
clause.

https://github.com/Grokzen/pykwalify/blob/master/LICENSE
https://wiki.debian.org/qa.debian.org/jsonevil

Felix

Bug#905138: [Pkg-cmake-team] Bug#905138: cmake: FTBFS on kfreebsd-any

[Felix Geyer]

Hi,

On 31.07.2018 17:01, Svante Signell wrote:
> Source: cmake
> Version: 3.11.2-1
> Severity: important
> Tags: patch
> Usertags: linux-any, freebsd-any, hurd-any
>
> Hello,
>
> Currently cmake does FTBFs on kfreebsd-any due to a missing dependency
> on libfreebsd-glue-0 and a missing dependency on freebsd-glue,
> providing the link:
> /usr/lib/libfreebsd-glue.so -> /lib/libfreebsd-glue.so.0
>
> Ideally a library libfreebsd-glue-dev should be split out of the
> package freebsd-glue. Until that happens, the added dependency will do,
> see the attached file debian_control.diff.
>
> With the attached patches bootstrap.patch, debian_control.diff, and the
> upcoming bug report on linux-any,providing
> Source_Modules_FindLibUV.cmake.diff cmake builds fine. 

Have you forwarded your non-packaging changes upstream to cmake / libuv
(#905140 is already fixed in 3.12)?
I really don't want to carry those as patches.

Cheers,
Felix

Bug#864755: Bash completion missing in 2.15

[Felix Geyer]

Control: tags -1 - unreproducible moreinfo
Control: severity -1 minor

Hi,

On Wed, 2 Aug 2017 21:55:14 -0400 Apollon Oikonomopoulos 
 wrote:

Control: severity -1 wishlist
Control: tags -1 unreproducible moreinfo

Hi,

On 12:40 Wed 14 Jun , Christian Balzer wrote:
> Unlike with 2.12 there is no longer a /etc/bash_completion.d/ganeti
> provided by this package.

Thanks for the report. Bash completions are now being installed under 
/usr/share/bash-completion/completion and should work out of the box.  
Can you please check if this is the case?


The completions in /usr/share/bash-completion/completion are dynamically 
loaded so the name of the file there has to match the command.


Either the file needs to be moved back to /etc/bash_completion.d/ganeti 
or symlinks for all covered gnt-* created in 
/usr/share/bash-completion/completion (gnt-instance -> ganeti, gnt-node 
-> ganeti etc).



The completion still works after a jessie->stretch upgrade because 
ganeti lacks the maintainer script to remove the 
/etc/bash_completion.d/ganeti config file. So the old version of the 
completion stays there.


Felix

--
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

Bug#903261: O: libapache2-mod-fcgid -- FastCGI interface module for Apache 2

[Felix Geyer]

Package: wnpp

I'm orphaning libapache2-mod-fcgid because I haven't used it for a long time
and for most use cases better alternatives exist.

The package is in a reasonable shape however upstream has been mostly inactive
for the last couple of years.

Felix

Bug#897568: zfs-dkms 0.7.6 fails to build on 4.16.0-1-amd64

[Felix Geyer]

Control: severity -1 grave

On Wed, 2 May 2018 17:13:03 -0700 Sohum Banerjea  wrote:
> zfs-dkms fails to build on installing linux kernel 4.16.0-1-amd64, with the
> following error.

Bumping the severity since it makes the package unusable with the
testing/unstable kernel.

Felix

Bug#897560: [Pkg-cmake-team] Bug#897560: cmake: CHECK_FUNCTION_EXISTS is broken

[Felix Geyer]

Hi,

On 02.05.2018 23:45, Nicolas Braud-Santoni wrote:
> Package: cmake
> Version: 3.11.1-1
> Severity: important
>
> Dear cmake maintainers,
>
> CMake's CHECK_FUNCTION_EXISTS was seemingly broken in the last upload, 
> resulting
> in configure failures when the function exists in headers but cannot be found 
> by
> the linker:
>
>> Determining if the pthread_create exist failed with the following output:
>> Change Dir: 
>> /<>/libgit2-0.27.0+dfsg.1/build-debian-release/CMakeFiles/CMakeTmp
>>
>> Run Build Command:"/usr/bin/make" "cmTC_78338/fast"
>> make[2]: Entering directory 
>> '/<>/libgit2-0.27.0+dfsg.1/build-debian-release/CMakeFiles/CMakeTmp'
>> /usr/bin/make -f CMakeFiles/cmTC_78338.dir/build.make 
>> CMakeFiles/cmTC_78338.dir/build
>> make[3]: Entering directory 
>> '/<>/libgit2-0.27.0+dfsg.1/build-debian-release/CMakeFiles/CMakeTmp'
>> Building C object CMakeFiles/cmTC_78338.dir/CheckSymbolExists.c.o
>> /usr/bin/cc   -g -O2 
>> -fdebug-prefix-map=/<>/libgit2-0.27.0+dfsg.1=. 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>> -D_FORTIFY_SOURCE=2-o CMakeFiles/cmTC_78338.dir/CheckSymbolExists.c.o   
>> -c 
>> /<>/libgit2-0.27.0+dfsg.1/build-debian-release/CMakeFiles/CMakeTmp/CheckSymbolExists.c
>> Linking C executable cmTC_78338
>> /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_78338.dir/link.txt 
>> --verbose=1
>> /usr/bin/cc -g -O2 -fdebug-prefix-map=/<>/libgit2-0.27.0+dfsg.1=. 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>> -D_FORTIFY_SOURCE=2   -Wl,-z,relro -Wl,-z,now  -rdynamic 
>> CMakeFiles/cmTC_78338.dir/CheckSymbolExists.c.o  -o cmTC_78338 
>> CMakeFiles/cmTC_78338.dir/CheckSymbolExists.c.o: In function `main':
>> ./build-debian-release/CMakeFiles/CMakeTmp/./build-debian-release/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:
>>  undefined reference to `pthread_create'
>> collect2: error: ld returned 1 exit status
>> make[3]: *** [CMakeFiles/cmTC_78338.dir/build.make:87: cmTC_78338] Error 1
>> make[3]: Leaving directory 
>> '/<>/libgit2-0.27.0+dfsg.1/build-debian-release/CMakeFiles/CMakeTmp'
>> make[2]: *** [Makefile:126: cmTC_78338/fast] Error 2
>> make[2]: Leaving directory 
>> '/<>/libgit2-0.27.0+dfsg.1/build-debian-release/CMakeFiles/CMakeTmp'
>>
>> File 
>> /<>/libgit2-0.27.0+dfsg.1/build-debian-release/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
>> /* */
>> #include 
>>
>> int main(int argc, char** argv)
>> {
>>   (void)argv;
>> #ifndef pthread_create
>>   return ((int*)(_create))[argc];
>> #else
>>   (void)argc;
>>   return 0;
>> #endif
>> }

I guess you are taking about check_symbol_exists()?
Access to the source and a full error log (what's the check_symbol_exists() 
call that failed?)
would help a lot.

From a first glance though this looks like expected behavior.
You are testing for a library function so you need to set 
CMAKE_REQUIRED_LIBRARIES accordingly.

> As this results in other packages failing to build, please consider fixing 
> ASAP.

Which packages? Can you give some examples?

Cheers,
Felix

Bug#896811: [Pkg-nagios-devel] Bug#896811: stretch-pu: package icinga2/2.6.0-2+deb9u1

[Felix Geyer]

Hi Bas,

On 24.04.2018 15:08, Bas Couwenberg wrote:
> Hi Felix,
> 
> Thanks for caring about icinga2.
> 
> Please help maintain the package withing the Nagios team.
> 
> On 2018-04-24 14:59, Felix Geyer wrote:
>> I'd like to upload this fix to stretch, debdiff is attached.
> 
> Please push your changes to the (to be created) stretch branch of the git 
> repository:
> 
>  https://salsa.debian.org/nagios-team/pkg-icinga2

Sure thing.
Since I don't have write access to the Git repo I opened
https://salsa.debian.org/nagios-team/pkg-icinga2/merge_requests/1

Cheers,
Felix

Bug#896914: quassel: Implement custom deserializer to add our own sanity checks

[Felix Geyer]

Hi,

On Wed, 25 Apr 2018 20:58:52 +0200 Salvatore Bonaccorso  
wrote:
> Source: quassel
> Version: 1:0.12.4-1
> Severity: normal
> Tags: patch security upstream
> Control: fixed -1 1:0.12.5-1
> 
> Hi Felix,
> 
> Filling this as bug to have an identifier, since no CVE has been
> assigned.
> 
> https://www.quassel-irc.org/node/130
> 
> Commit "Implement custom deserializer to add our own sanity checks":
> 
> https://github.com/quassel/quassel/commit/18389a713a6810f57ab237b945e8ee03df857b8b

I'm working on updates for jessie and stretch.

Backporting to stretch is easy.
jessie requires a bit more work as the patch uses quite some C++11 features 
which
isn't enabled in 0.10.

Felix

Bug#896811: stretch-pu: package icinga2/2.6.0-2+deb9u1

[Felix Geyer]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

Icinga2 2.6.0 stores timestamps as local time instead of UTC in the
database when the PostgreSQL IDO backend is used.

The result is that Icinga Web 2 displays all date/times with an offset
(unless system time is UTC of course).
While you could argue that this is only a cosmetic problem I think it's
important for a monitoring system to display the correct time.

This has been fixed upstream in 2.6.1.
Bug report is at https://github.com/Icinga/icinga2/issues/4874

I'd like to upload this fix to stretch, debdiff is attached.

Felix 
diff -Nru icinga2-2.6.0/debian/changelog icinga2-2.6.0/debian/changelog
--- icinga2-2.6.0/debian/changelog  2016-12-19 16:13:45.0 +0100
+++ icinga2-2.6.0/debian/changelog  2018-04-23 15:47:44.0 +0200
@@ -1,3 +1,9 @@
+icinga2 (2.6.0-2+deb9u1) stretch; urgency=medium
+
+  * Fix timestamps being stored as local time in PostgreSQL.
+
+ -- Felix Geyer <felix.ge...@credativ.de>  Mon, 23 Apr 2018 15:47:44 +0200
+
 icinga2 (2.6.0-2) unstable; urgency=medium
 
   * [e0f34e4] Add patch 41_ido_mysql57 - for compatibility with MySQL 5.7
diff -Nru icinga2-2.6.0/debian/patches/43_postgres_timezone 
icinga2-2.6.0/debian/patches/43_postgres_timezone
--- icinga2-2.6.0/debian/patches/43_postgres_timezone   1970-01-01 
01:00:00.0 +0100
+++ icinga2-2.6.0/debian/patches/43_postgres_timezone   2018-04-18 
08:17:02.0 +0200
@@ -0,0 +1,23 @@
+From e9db716b26e49a36d733d5e224280fb63943fb9f Mon Sep 17 00:00:00 2001
+From: Michael Friedrich <michael.friedr...@netways.de>
+Date: Wed, 11 Jan 2017 17:34:09 +0100
+Subject: [PATCH] Ensure that PostgreSQL timestamps are UTC
+
+fixes #13617
+---
+ lib/db_ido_pgsql/idopgsqlconnection.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/db_ido_pgsql/idopgsqlconnection.cpp 
b/lib/db_ido_pgsql/idopgsqlconnection.cpp
+index f398fda50..c16f9f50f 100644
+--- a/lib/db_ido_pgsql/idopgsqlconnection.cpp
 b/lib/db_ido_pgsql/idopgsqlconnection.cpp
+@@ -636,7 +636,7 @@ bool IdoPgsqlConnection::FieldToEscapedString(const 
String& key, const Value& va
+   } else if (DbValue::IsTimestamp(value)) {
+   long ts = rawvalue;
+   std::ostringstream msgbuf;
+-  msgbuf << "TO_TIMESTAMP(" << ts << ")";
++  msgbuf << "TO_TIMESTAMP(" << ts << ") AT TIME ZONE 'UTC'";
+   *result = Value(msgbuf.str());
+   } else if (DbValue::IsTimestampNow(value)) {
+   *result = "NOW()";
diff -Nru icinga2-2.6.0/debian/patches/series 
icinga2-2.6.0/debian/patches/series
--- icinga2-2.6.0/debian/patches/series 2016-12-16 18:28:37.0 +0100
+++ icinga2-2.6.0/debian/patches/series 2018-04-18 08:56:34.0 +0200
@@ -1,3 +1,4 @@
 21_config_changes
 41_ido_mysql57
 42_mips_boost_bind_workaround
+43_postgres_timezone

Bug#895518: libsdl2-dev is not Multi-Arch compatible

[Felix Geyer]

Hi,


On 12.04.2018 11:28, Francois Gouget wrote:
> Package: libsdl2-dev
> Version: 2.0.8+dfsg1-1
> Severity: normal
>
> Dear Maintainer,
>
> The development package is not multiarch aware which causes the amd64
> version to conflict with the i386 one, thus making it impossible to
> install both.

libsdl2-dev itself is marked as Multi-Arch: same so it could be co-installed
across multiple architectures,
However some of its dependencies maybe not be co-installable breaking
this for libsdl2-dev.

This can't be fixed in the libsdl2 package.
Could you please file bugs against those package instead?
apt will tell you which package prevents the installation.

Felix

Bug#895241: ITP: snapcast -- multi-room client-server audio player

[Felix Geyer]

Package: wnpp
Severity: wishlist
Owner: Felix Geyer <fge...@debian.org>

* Package name: snapcast
  Version : 0.13.0
  Upstream Author : Johannes Pohl
* URL : https://github.com/badaix/snapcast
* License : GPL
  Description : multi-room client-server audio player

Snapcast is a multi-room client-server audio player, where all clients are
time synchronized with the server to play perfectly synced audio. It's not a
standalone player, but an extension that turns your existing audio player into
a Sonos-like multi-room solution.

Bug#878233: check_running_kernel: find: ‘/boot/efi’: Permission denied

[Felix Geyer]

Control: tags -1 patch

On Wed, 11 Oct 2017 13:15:12 +0200 Stefan Wendler <stefan.wend...@tngtech.com> 
wrote:
> Package: nagios-plugins-contrib
> Version: 21.20170222
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> running 'check_running_kernel' as nagios-user
>* What was the outcome of this action?
> find: ‘/boot/efi’: Permission denied
>* What outcome did you expect instead?
> Does /boot/efi have to be read? If not, please exclude reading the /boot/efi 
> directory

The same thing happens when /boot is an own filesystem and /boot/lost+found is 
only root readable.

Adding a -maxdepth 1 to the offending find calls does the trick.
A patch is attached.

Felix

-- 
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
-- 
Felix Geyer
Berater
Tel.:   +49 2166 9901-125
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

**
Jetzt neu:
Elephant Shed - PostgreSQL Appliance
PostgreSQL und alles was dazugehört

Von Backup über Monitoring bis Reporting:
https://elephant-shed.io/de/
**--- a/debian/patches/dsa/check_running_kernel_jessie_centos_fix
+++ b/debian/patches/dsa/check_running_kernel_jessie_centos_fix
@@ -19,8 +19,8 @@
 -	"/boot/vmlinuz-`uname -r`"\
 -	"/boot/vmlinux-`uname -r`"\
 -	"/boot/kfreebsd-`uname -r`.gz"; do
-+	$([ -f "/boot/vmlinuz-$(uname -r)" ] && find /boot/ -name 'vmlinuz*' -and -name "vmlinuz-$(uname -r)" -or -name 'vmlinuz*' -and -newer "/boot/vmlinuz-$(uname -r)" | sort) \
-+	$([ -f "/boot/kfreebsd-$(uname -r).gz" ] && find /boot/ -name 'kfreebsd*' -and -name "kfreebsd-$(uname -r).gz" -or -name 'kfreebsd*' -and -newer "/boot/kfreebsd-$(uname -r).gz" | sort); do
++	$([ -f "/boot/vmlinuz-$(uname -r)" ] && find /boot/ -maxdepth 1 -name 'vmlinuz*' -and -name "vmlinuz-$(uname -r)" -or -name 'vmlinuz*' -and -newer "/boot/vmlinuz-$(uname -r)" | sort) \
++	$([ -f "/boot/kfreebsd-$(uname -r).gz" ] && find /boot/ -maxdepth 1 -name 'kfreebsd*' -and -name "kfreebsd-$(uname -r).gz" -or -name 'kfreebsd*' -and -newer "/boot/kfreebsd-$(uname -r).gz" | sort); do
  
  	if [ -e "$on_disk" ]; then
  		if [ -z "$STRINGS" ]; then

Bug#889728: stretch-pu: package bareos/16.2.4-3+deb9u2

[Felix Geyer]

On 23.02.2018 18:30, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2018-02-06 at 13:45 +0100, Felix Geyer wrote:
>> I'd like to fix bug #889040 in stretch:
>>
>> * Fix backups failing with "No Volume name given".
>>   - Backport upstream commit: Don't return empty volname if volume is
>> on
>> unwanted vols list.
>>
> 
> Please go ahead.

Thanks, uploaded.

Felix

Bug#891026: zfs-dkms: Incompatible with kernel 4.15

[Felix Geyer]

Package: zfs-dkms
Version: 0.7.5-1
Severity: serious

Hi,

Kernel 4.15 has just landed in unstable.
THe zfs-linux 0.7.5 module fails to build against 4.15 and thus needs
to be updated to 0.7.6.

Please let me know if you need help updating the package.

Cheers,
Felix

Bug#889728: stretch-pu: package bareos/16.2.4-3+deb9u2

[Felix Geyer]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I'd like to fix bug #889040 in stretch:

* Fix backups failing with "No Volume name given".
  - Backport upstream commit: Don't return empty volname if volume is on
unwanted vols list.

The bug doesn't affect jessie and is already fixed in testing/unstable.
A debdiff is attached.

Felix
diff -Nru bareos-16.2.4/debian/changelog bareos-16.2.4/debian/changelog
--- bareos-16.2.4/debian/changelog  2017-07-27 20:58:49.0 +0200
+++ bareos-16.2.4/debian/changelog  2018-02-02 10:58:25.0 +0100
@@ -1,3 +1,11 @@
+bareos (16.2.4-3+deb9u2) stretch; urgency=medium
+
+  * Fix backups failing with "No Volume name given". (Closes: #889040)
+- Backport upstream commit: Don't return empty volname if volume is on
+  unwanted vols list.
+
+ -- Felix Geyer <felix.ge...@credativ.de>  Fri, 02 Feb 2018 10:58:25 +0100
+
 bareos (16.2.4-3+deb9u1) stretch; urgency=medium
 
   * Fix permissions of bareos-dir logrotate config on upgrade. (Closes: 
#864926)
diff -Nru bareos-16.2.4/debian/patches/fix-no-volume-name-given 
bareos-16.2.4/debian/patches/fix-no-volume-name-given
--- bareos-16.2.4/debian/patches/fix-no-volume-name-given   1970-01-01 
01:00:00.0 +0100
+++ bareos-16.2.4/debian/patches/fix-no-volume-name-given   2018-01-30 
10:02:18.0 +0100
@@ -0,0 +1,38 @@
+From d1ff29b3988a7c0aed3c0394ccfb3904f0588ddf Mon Sep 17 00:00:00 2001
+From: Philipp Storz <philipp.st...@bareos.com>
+Date: Tue, 25 Apr 2017 10:50:44 +0200
+Subject: [PATCH] Don't return empty volname if volume is on unwanted vols list
+
+When the volume was on the unwanted_list, the loop was
+continued but the number of sql rows was not checked, so that
+the code continued and returned an empty volumename.
+
+Fixes #691: Backup job fails with "No Volume name given."
+---
+ src/cats/sql_find.c | 11 ++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/src/cats/sql_find.c b/src/cats/sql_find.c
+index ef716b820..c354c8a98 100644
+--- a/src/cats/sql_find.c
 b/src/cats/sql_find.c
+@@ -435,9 +435,18 @@ int db_find_next_volume(JCR *jcr, B_DB *mdb, int item, 
bool InChanger, MEDIA_DBR
+   }
+ 
+   /*
+-   * See if this is not on the unwanted volumes list.
++   * Skip if volume is on unwanted volumes list.
++   * We need to reduce the number of rows by one
++   * and jump out if no more rows are available
+*/
+   if (unwanted_volumes && is_on_unwanted_volumes_list(row[1], 
unwanted_volumes)) {
++ Dmsg1(50, "Volume %s is on unwanted_volume_list, skipping\n", 
row[1]);
++ num_rows-- ;
++ if ( num_rows <= 0) {
++Dmsg1(50, "No more volumes in result, bailing out\n", row[1]);
++sql_free_result(mdb);
++goto bail_out;
++ }
+  continue;
+   }
+ 
diff -Nru bareos-16.2.4/debian/patches/series 
bareos-16.2.4/debian/patches/series
--- bareos-16.2.4/debian/patches/series 2017-07-27 20:58:49.0 +0200
+++ bareos-16.2.4/debian/patches/series 2018-01-30 10:02:41.0 +0100
@@ -1,3 +1,4 @@
 dont-generate-debian-files
 disable-fstype-test
 fix-sha1-file-corruption
+fix-no-volume-name-given

Bug#889040: bareos-director: Backups sometimes fail with "No Volume name given"

[Felix Geyer]

Package: bareos-director
Version: 16.2.4-3+deb9u1

Backups sometimes (more likely with concurrent backups on mutiple
devices) fail when sd requests a new volume from the director.

Error message:
> 28-Jan 01:05 X-sd JobId 71734: Warning: mount.c:248 Open device "X" (/X/) 
> Volume "" failed: ERR=Could not open file device "X" (/X/). No Volume name 
> given.

Felix

-- 
Felix Geyer
Berater
Tel.:   +49 2166 9901-125
Fax:+49 2166 9901-100
E-
Mail: felix.ge...@credativ.de
PGP:D1DF 8149 7643 8822 7283 92DC 1004
DA1C FF6D B892
http://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

Bug#888228: [Pkg-cmake-team] Bug#888228: cmake: ignores linker scripts on the Hurd (and kFreeBSD?)

[Felix Geyer]

Hi,


On 24.01.2018 03:47, Aaron M. Ucko wrote:
> Package: cmake
> Version: 3.9.5-1
> Severity: important
> Tags: upstream
> User: debian-h...@lists.debian.org
> Usertags: hurd-i386
> Control: affects -1 src:mariadb-connector-c
>
> The build of mariadb-connector-c for hurd-i386 (admittedly not a
> release architecture) [1] failed because the symbols came out
> unversioned, whereas the .symbols file expects version annotations.
> By my reading of [2], CMake encounters the version script on line 378
> but evidently neglects to pass it along to the linker.  I suspect
> kFreeBSD builds may wind up failing in the same fashion if and when
> their autobuilders are back in commission.
>
> Could you please take a look?

It seems like cmake ignores mariadbclient.def in the ADD_LIBRARY()
call on all architectures since it's not an actual source file.

The mariadbclient.def argument you see in the build log comes from
the TARGET_LINK_LIBRARIES() call in line 398.
That one is wrapped in a IF(LINUX) clause so that's why !Linux builds
are broken.

You might want to change that IF to:
CMAKE_SYSTEM_NAME MATCHES "^(Linux|kFreeBSD|GNU)$"

I'm inclined to call this "works as intended".

Felix

Bug#886680: choqok: Depends on transitional package libqca2-plugin-ossl

[Felix Geyer]

On 11.01.2018 13:35, Lisandro Damián Nicanor Pérez Meyer wrote:
> Or Team upload if you feel like it too.

Ok sure, I'll do an NMU (it's not team maintained).

Felix

Bug#886681: qgis-providers: (Build-)Depends on transitional package libqca2-plugin-ossl

[Felix Geyer]

Package: qgis-providers
Version: 2.14.21+dfsg-2

Hi,

qgis build-depends and qgis-providers depends on the transitional package
libqca2-plugin-ossl.
I intend to remove it in the buster cycle.

Please change the (build-)dependency to libqca2-plugins.

Thanks,
Felix