Bug#1050649: bookworm-pu: package nx-libs/2:3.5.99.26-5+deb12u1

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: nx-l...@packages.debian.org
Control: affects -1 + src:nx-libs

We received a report about font problems with nxagent/x2goagent
in Debian that occur with the official DEB packages but not
with the upstream-provided DEB packages.

See:
https://github.com/ArcticaProject/nx-libs/issues/1039
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006662

[ Reason ]
Users of X2Go shall not see application complaints about missing
fonts. This requires placing a symlink /usr/share/nx/fonts
pointing to /usr/share/fonts/X11 into one of the nx-libs-provided
packages (i.e. nx-x11-common).

[ Impact ]
xterm and other applications expecting fonts from
/usr/share/fonts/X11/misc being available will continue complaining.

[ Tests ]
Manual test on Debian bookworm and testing/unstable.

[ Risks ]
Minimal. No code change, only the symlink has been added.

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

+  * debian/nx-x11-common.{dir,links}:
++ Assure that a symlink from from /usr/share/nx/fonts to
+  /usr/share/fonts/X11 gets provided by the nx-x11-common bin:pkg.
+  (Closes: #1006662).

-> explanation, see above

+  * debian/patches:
++ Add 0008_nx-X11-programs-Xserver-hw-nxagent-man-nxagent.1-Fix.patch. Fix
+  groff error in man page, properly show all text in the keystrokes.cfg
+  passage. Thanks, lintian.

-> explanation, see under [ Other info ]

[ Other info ]
Also a groff error in the nxagent.1 man page gets resolved with this.
diff -Nru nx-libs-3.5.99.26/debian/changelog nx-libs-3.5.99.26/debian/changelog
--- nx-libs-3.5.99.26/debian/changelog  2021-10-30 13:38:02.0 +0200
+++ nx-libs-3.5.99.26/debian/changelog  2023-08-27 14:45:11.0 +0200
@@ -1,3 +1,16 @@
+nx-libs (2:3.5.99.26-5+deb12u1) bookworm; urgency=medium
+
+  * debian/nx-x11-common.{dir,links}:
++ Assure that a symlink from from /usr/share/nx/fonts to
+  /usr/share/fonts/X11 gets provided by the nx-x11-common bin:pkg.
+  (Closes: #1006662).
+  * debian/patches:
++ Add 0008_nx-X11-programs-Xserver-hw-nxagent-man-nxagent.1-Fix.patch. Fix
+  groff error in man page, properly show all text in the keystrokes.cfg
+  passage. Thanks, lintian.
+
+ -- Mike Gabriel   Sun, 27 Aug 2023 14:45:11 +0200
+
 nx-libs (2:3.5.99.26-5) unstable; urgency=medium
 
   * debian/patches:
diff -Nru nx-libs-3.5.99.26/debian/nx-x11-common.dirs 
nx-libs-3.5.99.26/debian/nx-x11-common.dirs
--- nx-libs-3.5.99.26/debian/nx-x11-common.dirs 1970-01-01 01:00:00.0 
+0100
+++ nx-libs-3.5.99.26/debian/nx-x11-common.dirs 2023-08-27 14:44:03.0 
+0200
@@ -0,0 +1,2 @@
+# we symlink to this dir, so make sure it exists
+usr/share/fonts/X11
diff -Nru nx-libs-3.5.99.26/debian/nx-x11-common.links 
nx-libs-3.5.99.26/debian/nx-x11-common.links
--- nx-libs-3.5.99.26/debian/nx-x11-common.links1970-01-01 
01:00:00.0 +0100
+++ nx-libs-3.5.99.26/debian/nx-x11-common.links2023-08-27 
14:44:03.0 +0200
@@ -0,0 +1 @@
+usr/share/fonts/X11 usr/share/nx/fonts
diff -Nru 
nx-libs-3.5.99.26/debian/patches/0008_nx-X11-programs-Xserver-hw-nxagent-man-nxagent.1-Fix.patch
 
nx-libs-3.5.99.26/debian/patches/0008_nx-X11-programs-Xserver-hw-nxagent-man-nxagent.1-Fix.patch
--- 
nx-libs-3.5.99.26/debian/patches/0008_nx-X11-programs-Xserver-hw-nxagent-man-nxagent.1-Fix.patch
1970-01-01 01:00:00.0 +0100
+++ 
nx-libs-3.5.99.26/debian/patches/0008_nx-X11-programs-Xserver-hw-nxagent-man-nxagent.1-Fix.patch
2023-08-27 14:44:24.0 +0200
@@ -0,0 +1,27 @@
+From bdb4eefb6224f2146a0bcc43459651a4d3b2a22f Mon Sep 17 00:00:00 2001
+From: Mike Gabriel 
+Date: Sun, 27 Aug 2023 12:19:34 +0200
+Subject: [PATCH] nx-X11/programs/Xserver/hw/nxagent/man/nxagent.1: Fix groff
+ error reported by lintian in nxagent man page.
+
+Signed-off-by: Mike Gabriel 
+---
+ nx-X11/programs/Xserver/hw/nxagent/man/nxagent.1 | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/nx-X11/programs/Xserver/hw/nxagent/man/nxagent.1 
b/nx-X11/programs/Xserver/hw/nxagent/man/nxagent.1
+index 5f87fa8d4..0f57c3dcf 100644
+--- a/nx-X11/programs/Xserver/hw/nxagent/man/nxagent.1
 b/nx-X11/programs/Xserver/hw/nxagent/man/nxagent.1
+@@ -575,7 +575,7 @@ file is taken). If \fBnxagent\fR is run as \fBx2goagent\fR 
the defaults are
+ .IR ~/.x2go/keystrokes.cfg
+ and
+ .IR /etc/x2go/keystrokes.cfg
+-. Any keystrokes
++Any keystrokes
+ \fBnxagent\fR knows about that are not defined in this file are
+ ignored. (Only) if no file is found built-in defaults are used. The
+ keystroke file can be re-read by a keystroke (ctrl-alt-k by default).
+-- 
+2.39.2
+
diff -Nru nx-libs-3.5.99.26/debian/patches/series 

Bug#1050335: bookworm-pu: package sitesummary/0.1.55~deb12u1

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Wed, Aug 23, 2023 at 01:16:11PM +0200, Mike Gabriel wrote:
> While working on the initial Debian Edu release, Guido Berhöster has
> worked on the sitesummary package. All changes target Debian Edu 12, so
> we want to release the current version (0.1.55) to Debian bookworm (as
> 0.1.55~deb12u1).

I haven't looked at the diff in detail (it's quite a lot of changes) but I
notice the equivalent version in sid is failing to migrate because it is
uninstallable. Might this package be affected in the same way?


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1043585: AMD64 Kernel update prevents an emulated TPM working correctly inside Windows 11 KVM guest OS

[Salvatore Bonaccorso]

Hi Martin,

On Sun, Aug 13, 2023 at 11:27:57AM +0100, Martin Johnson wrote:
> Package: linux-image
> 
> Version: 6.1.0-11-amd64
> 
> When latest Debian kernel is installed it is causing a problem with KVM
> virtual machine and the current version of QEMU on Bookworm. This is when
> swtpm is used to provide an emulated TPM for the guest OS. The guest OS is
> windows 11. swtpm does not receive commands from the host OS, something has
> been broken in KVM side I suspect this could be caused by recent CPU
> security patches or patches to KVM itself.
> 
> The guest OS reports a code 10 on the TPM driver, and the TPM device is
> unusable. Trying a slightly older kernel the TPM is working as expected.
> 
> I also noticed the same issue with vanilla kernels built from kernel.org for
> example kernel-6.1.44 and kernel-6.1.45 has this issue and kernel 6.1.42
> does not. So its some recent patch is likely causing it.
> 
> I have two AMD64 machines with Ryzen processors and both exhibit this issue,
> I hope that it should be easily reproducible with a Ryzen CPU.
> 
> One Machine has this CPU:
> 
> AMD Ryzen 9 3950X 16-Core Processor
> 
> The other machine has this CPU:
> 
> AMD Ryzen 7 1800X 8-Core Processor

After picking the fix from upstream into unstable, this is as well
pending for bookworm and will land latest on the 12.2 point release.

Regards,
Salvatore

Bug#1050648: 0xffff: update d/watch file

[Patrice Duroux]

Source: 0x
Version: 0.9-1
Severity: minor

Dear Maintainer,

Here is a patch for.

Thanks,
Patrice


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/watch b/debian/watch
index 51f5737..db2eca4 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,3 @@
 version=4
-
-https://github.com/pali/0x/releases 
.*/0x[Ff][Ff][Ff][Ff][-_](\d\S+?)\.(?:orig\.tar\.gz|tar\.gz)
+opts="filenamemangle=s%(?:.*?)?v?@ANY_VERSION@(@ARCHIVE_EXT@)%@PACKAGE@-$1$2%" 
\
+https://github.com/pali/0x/tags (?:.*?/)?v?@ANY_VERSION@@ARCHIVE_EXT@

Bug#1050647: Updating the luasocket Uploaders list

[Mattia Rizzolo]

Source: luasocket
Version: 3.1.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Daniel Silverstone  has retired, so can't work on
the luasocket package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1050646: Updating the ekeyd Uploaders list

[Mattia Rizzolo]

Source: ekeyd
Version: 1.1.5-6.2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Daniel Silverstone  has retired, so can't work on
the ekeyd package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1050645: Updating the netsurf Uploaders list

[Mattia Rizzolo]

Source: netsurf
Version: 3.10-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Daniel Silverstone  has retired, so can't work on
the netsurf package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1050644: libapache2-mod-apreq2: Stops parsing input after empty file name in POST

[Raymond Field]

Package: libapache2-mod-apreq2
Version: 2.17-3
Severity: important
Tags: upstream

Dear Maintainer,

When POSTing a form to the server that includes a file upload input element,
libapache2-mod-apreq2 stops parsing the input if the file name is empty, i.e.
the user didn't select a file to upload, but the rest of the form is populated.

For example when submitting this form without selecting a file to upload,




Blank PDF Title
 
 

only id=211 is available to the code, new_doc_title and add_submit_button are 
not set.

This bug is fixed in the latest upstream source code.

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-11-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libapache2-mod-apreq2 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.57-2
ii  libapr1 1.7.2-3
ii  libapreq2-3 2.17-3
ii  libaprutil1 1.6.3-1
ii  libc6   2.36-9+deb12u1

libapache2-mod-apreq2 recommends no packages.

libapache2-mod-apreq2 suggests no packages.

-- no debconf information

Bug#1050604: Acknowledgement (python3-binwalk: Fails to extract cramfs)

[Shorrer]

I've looked a bit into it and found some interesting things.

First, there is an upstream (as I've understood) "deps.sh" file, which
pulls "cramfs-tools" and installs "cramfsck" as well as "mkcramfs" 
(haven't found mentions of mkcramfs being used anywhere).

I'm not understanding the Debian's package system at all, but at least
in the package's source repo that I've checked out there is no mention 
of "deps.sh" anywhere else except the "Dockerfile" that is also provided 
by upstream.


I've attached a patch. It is not to be forwarded upstream as it really
is a fix for how the package is in Debian repository. I could've added 
those lines so that binwalk would try to use one tool and then the 
other, spamming the console with warnings as it goes, but it does not 
seem like a good approach to me.


Please note that there is a difference in how fsck.cramfs extracts
the file compared to cramfsck: cramfsck keeps all symlinks as they are 
while fsck.cramfs replaces symlinks that point out of extraction dir to 
point to /dev/null.


If you want to go down "fsck.cramfs" route then it is also required to 
deal with it not being available in /usr/bin as well as adding 
dependency to util-linux. I'm sorry but I've experienced enough of 
package buildsystem for today so I hope that someone who knows it better 
could do it. Modifying "debian/control" file just didn't work for 
whatever reason. I will also note that in case of failure the "clean" 
target at "dpkg-buildpackage" does not clean the leftover "__pycache__" 
directories as well as:

 - testing/tests/.coverage
 - testing/tests/.config/
 - src/binwalk.egg-info/
which results in errors while trying to rebuild package once more, but 
it is very likely that I'm just using wrong tools for the job.


Maybe a better approach would be to actually do what "deps.sh" file 
wants to do -- download the cramfs-tools and compile cramfsck. It's a 
small binary after all, which does exactly what the original author 
intended (bad symlinks are more descriptive than /dev/null, if a bit 
dangerous).


If you need any additional info/tests/whatnot then feel free to write 
back. Sorry if I'm doing something wrong, the intention is to help with 
the problem I've found but I'm new to the Debian processes.
Description: Use fsck.cramfs instead of cramfsck
 As cramfs-tools is not installed in Debian the cramfsck is
 unavailable, but we have util-linux and fsck.cramfs from it which
 can serve the same purpose.
 The util-linux is added as a recommended dependency.
Author: Shorrer 
Bug: https://github.com/ReFirmLabs/binwalk/issues/623
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050604
Forwarded: no
Last-Update: 2023-08-27
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: python3-binwalk/src/binwalk/config/extract.conf
===
--- python3-binwalk.orig/src/binwalk/config/extract.conf
+++ python3-binwalk/src/binwalk/config/extract.conf
@@ -59,9 +59,9 @@
 ^squashfs filesystem:squashfs:sasquatch -p 1 -le -d '%%squashfs-root%%' 
'%e':0:False
 ^squashfs filesystem:squashfs:sasquatch -p 1 -be -d '%%squashfs-root%%' 
'%e':0:False
 
-# Try cramfsck first; if that fails, swap the file system and try again
-^cramfs filesystem:cramfs:cramfsck -x '%%cramfs-root%%' '%e':0:False
-^cramfs filesystem:cramfs:cramfsswap '%e' '%e.swap' && cramfsck -x 
'%%cramfs-root%%' '%e.swap':0:False
+# Try fsck.cramfs first; if that fails, swap the file system and try again
+^cramfs filesystem:cramfs:fsck.cramfs --extract='%%cramfs-root%%' '%e':0:False
+^cramfs filesystem:cramfs:cramfsswap '%e' '%e.swap' && fsck.cramfs 
--extract='%%cramfs-root%%' '%e.swap':0:False
 
 # Extract EXT filesystems using sleuth kit
 ^linux ext:ext:tsk_recover -i raw -f ext -a -v '%e' '%%ext-root%%':0:False

Bug#1050643: cairosvg: Embedded images using data URIs no longer work without unsafe flag (after original fix for CVE-2023-27586)

[Salvatore Bonaccorso]

Source: cairosvg
Version: 2.5.2-1.1
Severity: important
Tags: upstream fixed-upstream
Forwarded: https://github.com/Kozea/CairoSVG/issues/383
X-Debbugs-Cc: Joe Burmeister , car...@debian.org
Control: done -1 2.7.1-1
Control: found -1 2.5.0-1.1+deb11u1
Control: affects + release.debian.org,security.debian.org

As reported in https://github.com/Kozea/CairoSVG/issues/383 and as
well asked privately by Joe Burmeister, after the (original) upstream
fix for CVE-2023-27586, data URIs. Admittely the aim was to disallow
loading of external files.

This was addressed upstream with a followup and fixed in 2.7.1
upstream.

https://github.com/Kozea/CairoSVG/commit/2cbe3066e604af67c31d6651aa3acafe4ae0749d

Given we picked the orignal upstream patch for the cairosvg releases
in 2.5.2-1.1 and 2.5.0-1.1+deb11u1 this should be fixed in bookworm
and bullseye (though a point release update is enough I believe
instead of ra regression security advisory).

Regards,
Salvatore



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1050432: rpy2: FTBFS on mips64el

[Dirk Eddelbuettel]

On 27 August 2023 at 18:44, YunQiang Su wrote:
| Maybe there is something wrong with ffi. (In fact the complex support of mips
| was added by me. ;)

Hah.
 
| I am looking for a way to use debug to debug the extensions.
| If you have any documents, can you point it to me.

I can help you with R, I think here the issue is more on the Python side.

But to the best of my knowledge, the applications languages generally just
call into the C library 'and assume things work'.  But maybe here we need
another compile-time / link-time option to turn ffi on?

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl

[Niko Tyni]

(full quote for the benefit of the Aurelien and other glibc maintainers)

On Sat, Aug 26, 2023 at 09:07:38PM +0300, Niko Tyni wrote:
> Package: perl
> Version: 5.36.0-8
> Severity: serious
> X-Debbugs-Cc: debian-powe...@lists.debian.org
> Control: affects -1 libfile-fcntllock-perl
> 
> Hi,
> 
> debugging an unexpected autopkgtest failure of
> libfile-fcntllock-perl_0.22-4+b1 with perl_5.36.0-8 on ppc64el [1] I found
> it's because the old perl binary (5.36.0-7) was built with the fcntl(2)
> constant F_GETLK == 12, but the new one with F_GETLK == 5 [2].
> 
> There are no source or build system changes in perl that would have caused
> this change. The failure is currently blocking perl testing migration,
> so filing at 'serious'.
> 
> Perl is built with -D_FILE_OFFSET_BITS=64, and I see that on bullseye
> this causes F_GETLK == F_GETLK64 == 12, but on bookworm and later
> F_GETLK == 5 while F_GETLK64 == 12 [3]. I didn't find the exact
> change that caused this yet.
> 
> As can be expected from the above, building libfile-fcntllock-perl on
> bookworm against perl_5.36.0-7 makes it fail its test suite in a similar
> way. And rebuilding it on sid against perl_5.36.0-8 makes it pass.
> 
> On amd64 the constants have stayed equal (== 5) from bullseye to sid,
> and _FILE_OFFSET_BITS=64 doesn't affect them. What's the deal on ppc64el?
> 
> Copying the powerpc porters list. Could you please look into this?
> 
> [1] 
> https://ci.debian.net/data/autopkgtest/unstable/ppc64el/libf/libfile-fcntllock-perl/34669085/log.gz
> [2] perl -MPOSIX -E 'say F_GETLK'
> [3] printf '#include \nF_GETLK\nF_GETLK64\n' | cpp 
> -D_FILE_OFFSET_BITS=64 | tail -2

I think the relevant change here is this in libc6-dev_2.36-9+deb12u1 for 
bookworm:

--- libc6-dev_2.36-9/usr/include/powerpc64le-linux-gnu/bits/fcntl.h 
2023-04-10 09:35:16.0 +0100
+++ libc6-dev_2.36-9+deb12u1/usr/include/powerpc64le-linux-gnu/bits/fcntl.h 
2023-07-13 19:07:47.0 +0100
@@ -33,6 +33,12 @@
 # define __O_LARGEFILE 020
 #endif
 
+#if __WORDSIZE == 64
+# define F_GETLK   5
+# define F_SETLK   6
+# define F_SETLKW  7
+#endif
+

and a similar one in 2.37-2 for trixie/sid.

The applicable changelog entry is presumably

   [ Aurelien Jarno ]
   * debian/patches/git-updates.diff: update from upstream stable branch:
 [...]
 - Not affecting bookworm release architectures:
   - Fix LFS POSIX lock constants for powerpc64.

Aurelien, it seems that there's an oversight as ppc64el is a release 
architecture?

I can see that this changed for the better, but what should I do with the above
breakage? Rebuild perl and libfcntl-fcntllock-perl and declare some Breaks?
Do we want to do that for stable too?
-- 
Niko Tyni   nt...@debian.org

Bug#1050642: mutter: Xwaylands crashes due to `(EE) Unrecognized option: -byteswappedclients`

[Paul Menzel]

Package: mutter
Version: 44.3-7
Severity: normal


Dear Debian folks,


After upgrading *mutter* from 43.6-1 to 44.3-7, Firefox does not start 
anymore as Xwayland terminates with SIGABRT. The journal contains


gnome-shell[3416]: (EE) Unrecognized option: -byteswappedclients

Starting Firefox with `MOZ_ENABLE_WAYLAND=1` [1]  works around the issue.


Kind regards,

Paul


PS: Journal excerpt:

```
Aug 27 10:34:45 tokeiihto systemd[629]: Started 
app-gnome-firefox-3411.scope - Application launched by gnome-shell.
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: Unrecognized option: 
-byteswappedclients

Aug 27 10:34:45 tokeiihto gnome-shell[3416]: use: X [:] [option]
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -a # 
default pointer acceleration (factor)
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -ac 
disable access control restrictions
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -audit int set 
audit trail level
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -auth file 
select authorization file
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -br 
create root window with black background
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: +bs 
enable any backing store support
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -bs 
disable any backing store support
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -c 
turns off key-click
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: c # 
key-click volume (0-100)
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -cc int 
default color visual class
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -nocursor 
disable the cursor
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -core 
generate core dump on fatal error
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -displayfd fd  file 
descriptor to write display number to when ready to connect
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -dpi int 
screen resolution in dots per inch
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -dpms 
disables VESA DPMS monitor control
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -deferglyphs [none|all|16] 
defer loading of [no|all|16-bit] glyphs
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -f #   bell 
base (0-100)
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -fakescreenfps #   fake 
screen default fps (1-600)
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -fp string 
default font path
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -help 
prints message with these options
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: +iglx 
Allow creating indirect GLX contexts
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -iglx 
Prohibit creating indirect GLX contexts (default)
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -I 
ignore all remaining arguments
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -ld int 
limit data space to N Kb
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -lf int 
limit number of open files to N
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -ls int 
limit stack space to N Kb
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -nolock 
disable the locking mechanism
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -maxclients n  set 
maximum number of clients (power of two)
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -nolisten string 
don't listen on protocol
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -listen string 
listen on protocol
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -noreset 
don't reset after last client exists
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -background [none] 
create root window with no background
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -reset 
reset after last client exists
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -p # 
screen-saver pattern duration (minutes)
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -pn 
accept failure to listen on all ports
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -nopn 
reject failure to listen on all ports
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -r 
turns off auto-repeat
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: r 
turns on auto-repeat
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -render 
[default|mono|gray|color] set render color alloc policy
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -retro 
start with classic stipple and cursor
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -s # 
screen-saver timeout (minutes)
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -seat string   seat 
to run on
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -t # 
default pointer threshold (pixels/t)
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -terminate [delay] 
terminate at server reset (optional delay in sec)
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -tst 
disable testing extensions
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: ttyxx 
server started from init on /dev/ttyxx
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: v 
video blanking for screen-saver
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -v 
screen-saver without video blanking
Aug 27 10:34:45 tokeiihto gnome-shell[3416]: -wr 
create root window with white 

Bug#1050641: gcl: FTBFS on riscv64: Unknown reloc type 57

[Aurelien Jarno]

Source: gcl
Version: 2.6.14-4
Severity: important
Tags: ftbfs
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear maintainer,

gcl fails to build from source on riscv64 while it was building in the
past. This is the relevant part of the build log:

| echo '(load "../tkl.o")(TK::GET-AUTOLOADS (directory "*.lisp"))' | 
../../unixport/saved_gcl) 
| GCL (GNU Common Lisp)  2.6.14 Fri Jan 13 10:47:56 AM EST 2023  CLtL1  
profiling  git: Version_2_6_15pre3
| Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
| Binary License:  GPL due to GPL'ed components: (XGCL UNEXEC)
| Modifications of this banner must retain notice of a compatible license
| Dedicated to the memory of W. Schelter
| 
| Use (help) to get some basic information on how to use GCL.
| Temporary directory for compiler files:
| /tmp/
| 
| >;; Loading "../tkl.o"
| Unknown reloc type 57
| 
| Error: ERROR "The assertion !emsg(\"Unknown reloc type %lu\\n\", tp) on line 
186 of sfaslelf.c in function relocate failed: Success"
| Fast links are on: do (si::use-fast-links nil) for debugging
| Signalled by LOAD.
| ERROR "The assertion !emsg(\"Unknown reloc type %lu\\n\", tp) on line 186 of 
sfaslelf.c in function relocate failed: Success"
| 
| Broken at LOAD.  Type :H for Help.
| 1  Return to top level. 
| >>
| Error: UNDEFINED-FUNCTION :NAME TK::GET-AUTOLOADS
| Fast links are on: do (si::use-fast-links nil) for debugging
| Signalled by LOAD.
| 
| UNDEFINED-FUNCTION :NAME TK::GET-AUTOLOADS
| 
| Broken at LOAD.
| 1 (abort) Return to debug level 1. 
| 2  Return to top level. 
| >>>make[2]: *** [makefile:24: all] Error 255
| make[2]: Leaving directory '/<>/gcl-tk'
| make[1]: *** [makefile:114: do-gcl-tk] Error 2
| rm h/mcompdefs.h
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:122: build-gprof-stamp] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=gcl=riscv64=2.6.14-4=1692963268=0

I have tracked down the issue to the switch to gcc-13, which enabled
-fasynchronous-unwind-tables by default at the upstream level. This
causes a new section .rela.eh_frame to be added, using various type of
relocations that are not handled by GCL.

As a first test I have tried just ignore those relocations with the
following patch, which allowed me to build GCL successfully:

--- gcl-2.6.14.orig/h/elf64_riscv64_reloc.h
+++ gcl-2.6.14/h/elf64_riscv64_reloc.h
@@ -28,3 +28,15 @@
 case R_RISCV_32:
   store_val(where,MASK(32),(s+a));
   break;
+
+/* Relocations for .rela.eh_frame */
+case R_RISCV_32_PCREL:
+case R_RISCV_ADD32:
+case R_RISCV_SET6:
+case R_RISCV_SET8:
+case R_RISCV_SET16:
+case R_RISCV_SUB6:
+case R_RISCV_SUB8:
+case R_RISCV_SUB16:
+case R_RISCV_SUB32:
+  break;

It's not clear to me if it is safe to do so, or if we should add the
code for these relocations. Or maybe just ignore the .rela.eh_frame
section.

Regards
Aurelien

Bug#1050636: graphviz: Update to lua5.3

[Bastian Germann]

Am 27.08.23 um 13:30 schrieb László Böszörményi (GCS):

Control: tags -1 +pending

On Sun, Aug 27, 2023 at 1:09 PM Bastian Germann  wrote:

Please update your package to build with lua5.3 so we can drop v5.2 from the 
archive.
The build system supports lua5.3 as well.

  I can build it with Lua 5.4 even, any reason not to use that?


That is even better.

Bug#1050636: graphviz: Update to lua5.3

[GCS]

Control: tags -1 +pending

On Sun, Aug 27, 2023 at 1:09 PM Bastian Germann  wrote:
> Please update your package to build with lua5.3 so we can drop v5.2 from the 
> archive.
> The build system supports lua5.3 as well.
 I can build it with Lua 5.4 even, any reason not to use that?

Regards,
Laszlo/GCS

Bug#1003724: Minor repo cleanup ready to push

[Teus Benschop]

Hello Marcin,

There were nice updates ready in the repository at
https://salsa.debian.org/debian/libpqxx, all created by you, and thank you
for that. The changes were, among other things, related to an update to
libpqxx version, upstream, 7.2.1.

When I tried to build the package, it appeared that the branch
"pristine-tar" did not have the tag related to that new upstream version.

In an attempt to help a bit, I updated the branch "pristine-tar" in a local
clone of this repository.

So I am willing and ready to push this commit to the public repository at
Salsa.

Please let me know what you think, whether this is acceptable to you.

I think I'll wait a while on any comments from you and other developers,
and in case no objection is there, I would then feel free to push this.

Guys, have a good Sunday!

Teus Benschop, DD

Bug#1050640: lua5.2: remove as soon as all reverse dependencies are gone

[Bastian Germann]

Source: lua5.2
Severity: wishlist
Control: block -1 by 1050599 1050598 1050597 1050596 1050540 1050543 1050624 
1050625 1050626 1050627
Control: block -1 by 1050628 1050629 1050630 1050631 1050632 1050633 1050634 
1050635 1050636 1050637

The last lua5.2 release was on 07 Mar 2015. As upstream will not release any other version, we should get lua5.2 out of 
Debian as the least-used lua version that is still in the archive. I have filed "low-hanging fruit" bugs for the 
packages that support other lua versions as well and have blocked this issue on them.


The packages that need more investigation are:
dnsmasq
kyua
lutok
lcm
qosmic
tolua
uwsgi

The rest of the reverse dependencies are depending on "lua5.2 | lua5.x" (OR 
depends), so they should not be a problem.

Bug#1033167: usrmerge: messes with /etc/shells

[Luca Boccassi]

On Thu, 22 Jun 2023 22:52:53 +0200 Andreas Beckmann 
wrote:
> Hi Marco,
> 
> two questions about convert-etc-shells:
> 
> 1.) why does usrmerge.postinst call /usr/lib/usrmerge/convert-etc-
shells 
> (nearly) unconditionally (i.e. on every upgrade of the usrmerge 
> package)? Shouldn't that be a one-shot update and therefore be called
at 
> the end of maybe_convert (from within maybe_convert, not after), s.t.
it 
> is skipped if the system is already converted?
> 
> 2.) can you call update-shells from within convert-etc-shells (or
from 
> usrmerge.postinst directly before calling convert-etc-shells), s.t.
most 
> of the /etc/shells modifications are performed by update-shells and
the 
> state file /var/lib/shells.state gets updated properly?
> 
> I have just uploaded a NMU for debianutils to DELAYED/10 that fixes
some 
> issues (#1035820) and maybe makes convert-etc-shells superfluous.

Hello Andreas and Helmut,

Is there anything left to do here after Andreas' NMU fixing
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035820 last month,
or can we close this?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1050638: bullseye-pu: package clamav/0.103.9+dfsg-0+deb11u1

[Sebastian Andrzej Siewior]

Package: release.debian.org
Control: affects -1 + src:clamav
User: release.debian@packages.debian.org
Usertags: pu
Tags: bullseye
Severity: normal

This is a stable update from clamav upstream in the 0.103.x series.
It fixes the following CVE
- CVE-2023-20197 (Possible DoS in HFS+ file parser).

I excluded the docs update from the attached diff. The resulting diff
ist mostly the mentioned CVE plus compiler warnings.

[ 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

Sebastian
diff -Nru clamav-0.103.8+dfsg/clamonacc/clamonacc.c clamav-0.103.9+dfsg/clamonacc/clamonacc.c
--- clamav-0.103.8+dfsg/clamonacc/clamonacc.c	2023-02-13 01:03:33.0 +0100
+++ clamav-0.103.9+dfsg/clamonacc/clamonacc.c	2023-08-16 08:21:10.0 +0200
@@ -61,7 +61,7 @@
 pthread_t ddd_pid= 0;
 pthread_t scan_queue_pid = 0;
 
-static void onas_handle_signals();
+static void onas_handle_signals(void);
 static int startup_checks(struct onas_context *ctx);
 static struct onas_context *g_ctx = NULL;
 
diff -Nru clamav-0.103.8+dfsg/clamonacc/client/socket.h clamav-0.103.9+dfsg/clamonacc/client/socket.h
--- clamav-0.103.8+dfsg/clamonacc/client/socket.h	2023-02-13 01:03:33.0 +0100
+++ clamav-0.103.9+dfsg/clamonacc/client/socket.h	2023-08-16 08:21:10.0 +0200
@@ -31,4 +31,4 @@
 };
 
 cl_error_t onas_set_sock_only_once(struct onas_context *ctx);
-int onas_get_sockd();
+int onas_get_sockd(void);
diff -Nru clamav-0.103.8+dfsg/clamonacc/c-thread-pool/thpool.c clamav-0.103.9+dfsg/clamonacc/c-thread-pool/thpool.c
--- clamav-0.103.8+dfsg/clamonacc/c-thread-pool/thpool.c	2023-02-13 01:03:33.0 +0100
+++ clamav-0.103.9+dfsg/clamonacc/c-thread-pool/thpool.c	2023-08-16 08:21:10.0 +0200
@@ -8,7 +8,7 @@
  *
  /
 
-#define _POSIX_C_SOURCE 200809L
+#define _GNU_SOURCE
 #include 
 #include 
 #include 
diff -Nru clamav-0.103.8+dfsg/clamonacc/inotif/hash.c clamav-0.103.9+dfsg/clamonacc/inotif/hash.c
--- clamav-0.103.8+dfsg/clamonacc/inotif/hash.c	2023-02-13 01:03:33.0 +0100
+++ clamav-0.103.9+dfsg/clamonacc/inotif/hash.c	2023-08-16 08:21:10.0 +0200
@@ -58,7 +58,7 @@
 
 #if defined(HAVE_SYS_FANOTIFY_H)
 
-static struct onas_bucket *onas_bucket_init();
+static struct onas_bucket *onas_bucket_init(void);
 static void onas_free_bucket(struct onas_bucket *bckt);
 static int onas_bucket_insert(struct onas_bucket *bckt, struct onas_element *elem);
 static int onas_bucket_remove(struct onas_bucket *bckt, struct onas_element *elem);
diff -Nru clamav-0.103.8+dfsg/clamonacc/inotif/inotif.c clamav-0.103.9+dfsg/clamonacc/inotif/inotif.c
--- clamav-0.103.8+dfsg/clamonacc/inotif/inotif.c	2023-02-13 01:03:33.0 +0100
+++ clamav-0.103.9+dfsg/clamonacc/inotif/inotif.c	2023-08-16 08:21:10.0 +0200
@@ -66,7 +66,7 @@
 
 static int onas_ddd_init_ht(uint32_t ht_size);
 static int onas_ddd_init_wdlt(uint64_t nwatches);
-static int onas_ddd_grow_wdlt();
+static int onas_ddd_grow_wdlt(void);
 
 static int onas_ddd_watch(const char *pathname, int fan_fd, uint64_t fan_mask, int in_fd, uint64_t in_mask);
 static int onas_ddd_watch_hierarchy(const char *pathname, size_t len, int fd, uint64_t mask, uint32_t type);
diff -Nru clamav-0.103.8+dfsg/clamonacc/scan/onas_queue.c clamav-0.103.9+dfsg/clamonacc/scan/onas_queue.c
--- clamav-0.103.8+dfsg/clamonacc/scan/onas_queue.c	2023-02-13 01:03:33.0 +0100
+++ clamav-0.103.9+dfsg/clamonacc/scan/onas_queue.c	2023-08-16 08:21:10.0 +0200
@@ -82,7 +82,7 @@
 return CL_SUCCESS;
 }
 
-static void *onas_init_event_queue()
+static void *onas_init_event_queue(void)
 {
 
 if (CL_EMEM == onas_new_event_queue_node(_onas_event_queue_head)) {
@@ -122,7 +122,7 @@
 return;
 }
 
-static void onas_destroy_event_queue()
+static void onas_destroy_event_queue(void)
 {
 
 if (NULL == g_onas_event_queue_head) {
@@ -200,7 +200,7 @@
 pthread_cleanup_pop(1);
 }
 
-static int onas_queue_is_b_empty()
+static int onas_queue_is_b_empty(void)
 {
 
 if (g_onas_event_queue.head->next == g_onas_event_queue.tail) {
diff -Nru clamav-0.103.8+dfsg/CMakeLists.txt clamav-0.103.9+dfsg/CMakeLists.txt
--- clamav-0.103.8+dfsg/CMakeLists.txt	2023-02-13 01:03:33.0 +0100
+++ clamav-0.103.9+dfsg/CMakeLists.txt	2023-08-16 08:21:10.0 +0200
@@ -15,7 +15,7 @@
 set(VERSION_SUFFIX "")
 
 project( ClamAV
- VERSION "0.103.8"
+ VERSION "0.103.9"
  DESCRIPTION "ClamAV open source email, web, and end-point anti-virus toolkit." )
 
 set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake" ${CMAKE_MODULE_PATH})
diff -Nru clamav-0.103.8+dfsg/configure clamav-0.103.9+dfsg/configure
--- clamav-0.103.8+dfsg/configure	2023-02-13 01:03:59.0 +0100
+++ clamav-0.103.9+dfsg/configure	2023-08-16 08:21:37.0 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess 

Bug#1041552: HFS/HFS+ are insecure

[Diederik de Haas]

On Sunday, 27 August 2023 12:39:11 CEST Marco d'Itri wrote:
> > Previously not knowing about that status, I looked up the commits where
> > the
> > status was set to "odd fixes" and found that for some the reason was that
> > the maintainer didn't have the hardware to test it themselves.
> > I do not think that's the same as 'unmaintained'.
> 
> It means that they are not tested enough...

I consider that a too broad and blanked statement, which was why I replied.

I started explaining further (but removed it again), but I don't think that'll 
have any effect, so I'll leave it at this.

o/

signature.asc
Description: This is a digitally signed message part.

Bug#1050001: Unwinding directory aliasing [and 3 more messages]

[Ansgar]

Hi Matthew,

On Sun, 2023-08-27 at 11:30 +0100, Matthew Vernon wrote:
> Any such consideration must be mindful of the fact that the majority of 
> Debian installs are now /usr-merged, which means that the complexity of 
> unwinding such installs has to be a heavy factor in thinking about 
> alternative approaches.

Yes, I think there are many technical challenges required before Debian
would be in a position to adopt the proposed Jackson filesystem layout.
If Debian would choose to adopt it at all (an open question).

Besides conversion, there is also the telemetry service that seems to
be required to safely move to the proposed layout (AFAIK no alternative
to this has been proposed yet).  I'm not sure if there is already any
work done on the path by the proposers?

I'm also still missing an overview what the Jackson layout's advantages
over the existing filesystem layout (merged-/usr) or the 2000's layout
is (split-/usr).  As far as I can tell it combines the disadvantages of
both with much additional work required to get to it; I don't really
see any advantage so far (besides "our tools can't handle anything
else", but in practice it seems to work fine, and of course avoiding
stuff associated with a certain company which I understand is a goal in
itself for some people)...

I would appreciate a list of technical and ideological reasons why
switching to the Jackson layout is important for Debian.

Ansgar

Bug#1050637: vim: Update to lua5.4

[Bastian Germann]

Source: vim
Severity: wishlist
Version: 2:9.0.1672-1

Please update your package to build with lua5.4 so we can drop v5.2 from the 
archive.
The build system supports lua5.4 as well.

Bug#1050636: graphviz: Update to lua5.3

[Bastian Germann]

Source: graphviz
Severity: wishlist
Version: 2.42.2-7

Please update your package to build with lua5.3 so we can drop v5.2 from the 
archive.
The build system supports lua5.3 as well.

Bug#1050635: fityk: Update to lua5.3

[Bastian Germann]

Source: fityk
Severity: wishlist
Version: 1.3.2-2

Please update your package to build with lua5.3 so we can drop v5.2 from the 
archive.
The build system supports lua5.3 as well.

Bug#1050634: worker: Downgrade to lua5.1

[Bastian Germann]

Source: worker
Severity: wishlist
Version: 4.11.0-1

Please build your package with lua5.1 so we can drop v5.2 from the archive.
The build system supports it as fallback but you can certainly also try 
patching to a more up to date lua version.

Bug#1050633: wireshark: Downgrade to lua5.1

[Bastian Germann]

Source: wireshark
Severity: wishlist
Version: 4.0.8-1

Please build your package with lua5.1 so we can drop v5.2 from the archive.
The build system supports it as fallback but you can certainly also try 
patching to a more up to date lua version.

Bug#1050632: vlc: Downgrade to lua5.1

[Bastian Germann]

Source: vlc
Severity: wishlist
Version: 3.0.18-4

Please build your package with lua5.1 so we can drop v5.2 from the archive.
The build system supports it as fallback but you can certainly also try 
patching to a more up to date lua version.

Bug#1050631: telegram-cli: Downgrade to lua5.1

[Bastian Germann]

Source: telegram-cli
Severity: wishlist
Version: 1.3.1+git20160323.6547c0b21-3.1

Please build your package with lua5.1 so we can drop v5.2 from the archive.
The build system supports it as fallback but you can certainly also try 
patching to a more up to date lua version.

Bug#1050630: onscripter: Downgrade to lua5.1

[Bastian Germann]

Source: onscripter
Severity: wishlist
Version: 20220816-1

Please build your package with lua5.1 so we can drop v5.2 from the archive.
The build system supports it as fallback but you can certainly also try 
patching to a more up to date lua version.

Bug#1050629: mpv: Downgrade to lua5.1

[Bastian Germann]

Source: mpv
Severity: wishlist
Version: 0.36.0-1

Please build your package with lua5.1 so we can drop v5.2 from the archive.
The build system supports it as fallback but you can certainly also try 
patching to a more up to date lua version.

Bug#1050628: lua-lxc: Downgrade to lua5.1

[Bastian Germann]

Source: lua-lxc
Severity: wishlist
Version: 1:3.0.2-2

Please build your package with lua5.1 so we can drop v5.2 from the archive.
The build system supports it as fallback but you can certainly also try 
patching to a more up to date lua version.

Bug#1021292: Enabling branch protection on amd64 and arm64

[Guillem Jover]

Hi!

On Tue, 2023-06-27 at 16:09:40 +0100, Wookey wrote:
> On 2023-06-27 16:58 +0200, Moritz Mühlenhoff wrote:
> > Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca:
> > > On 2022-10-26 08:20, Moritz Mühlenhoff wrote:
> > > > I think this should rather be applied early after the Bookworm
> > > > release (and ideally we can also finish off the necessary testing
> > > > and add -fstack-clash-protection at least for amd64 and other archs
> > > > which are ready for it (#918914)).
> > > 
> > > Can we go ahead with the dpkg patch now, any specific tests you had in
> > > mind before applying it?
> > 
> > Note that I'm not the one driving this change (I'll start a separate
> > thread for -fstack-clash-protection in the next days), but the original
> > request was from Wookey.
> 
> > Personally I think now at the beginning of the new development cycle
> > is the ideal time to start this.
> 
> OK. We're all agreed on that then. Guillem can stick it in the next
> dpkg upload.

Right, I've queued the patch for 1.22.0, which I'm planning to upload
around today/tomorrow.

> I've not yet grokked James' comments above either which maybe imply
> adjustments to the patch? That's x86 stuff which is not my area of
> expertise. 

From a quick skim this seems most relevant for code that controls the
CPU state such as the kernel. I think we can go as is, and can amend
the flags if needed.

Thanks,
Guillem

Bug#1050627: eiskaltdcpp: Downgrade to lua5.1

[Bastian Germann]

Source: eiskaltdcpp
Severity: wishlist
Version: 2.4.2-1

Please build your package with lua5.1 so we can drop v5.2 from the archive.
The build system supports it as fallback but you can certainly also try 
patching to a more up to date lua version.

Bug#1049950: dh-python: Pybuild runs tests with tox but fails to clean up

[Stefano Rivera]

Control: tag -1 -moreinfo

Hi Arto (2023.08.26_06:24:29_+0100)
> > It has code to do this, can you point to an example of it not happening?
> >
> > https://salsa.debian.org/python-team/tools/dh-python/-/blob/a5068b6de912dee00415e3ed8af13b75ef29994c/dhpython/build/base.py#L164-172

Aha, I figured out the obvious:

The logic that automatically configures which test runner is in use is
only run for the test step, not the clean step.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1050626: efl: Downgrade to lua5.1

[Bastian Germann]

Source: efl
Severity: wishlist
Version: 1.26.3-1

Please build your package with lua5.1 so we can drop v5.2 from the archive.
The build system supports it as fallback but you can certainly also try 
patching to a more up to date lua version.

Bug#1050625: asterisk: Downgrade to lua5.1

[Bastian Germann]

Source: asterisk
Severity: wishlist
Version: 1:20.4.0~dfsg+~cs6.13.40431414-1

Please build your package with lua5.1 so we can drop v5.2 from the archive.
The build system supports it as fallback but you can certainly also try 
patching to a more up to date lua version.

Bug#1050624: aghermann: Downgrade to lua5.1

[Bastian Germann]

Source: aghermann
Severity: wishlist
Version: 1.1.2-4

Please build your package with lua5.1 so we can drop v5.2 from the archive.
The build system supports it as fallback but you can certainly also try 
patching to a more up to date lua version.

Bug#1050432: rpy2: FTBFS on mips64el

[YunQiang Su]

Dirk Eddelbuettel  于2023年8月27日周日 16:52写道：
>
>
> On 27 August 2023 at 14:09, YunQiang Su wrote:
> | Dirk Eddelbuettel  于2023年8月27日周日 00:15写道：
> | >
> | >
> | > Hi all,
> | >
> | > As the test failures for complex valued variables appeared to be systemic 
> on
> | > the 'mips64el' platform, I buckled down, taught myself some Python ==:-) 
> and
> | > conditioned the number of failing tests away via
> | >
> | >   @pytest.mark.skipif(platform.machine() == 'mips64' and sys.byteorder == 
> 'little',
> | >   reason="Complex tests fails for 'mips64el'.")
> | >
> | > Maybe the porters team can shed some light on why we needed it, and if 
> this
> | > worked (the autobuilders will tell us soon enough) I can pass the patch 
> on to
> | > Laurent for a possible inclusion upstream.
> | >
> |
> | Sorry for the late reply. I can work on it.
>
> Appreciate that!
>
> (While my fix corrected the build, it is a stop-gap as it avoids the issue. A
> real fix would be good.)
>
> | Do you knwo any way to run a single testcase?
>
> Can you start from the unit tests I conditioned out?  Each of those has
> simple expression with a complex in it. Those should be executable directly
> in the Python interpreter. You probably need all the build-deps (python, R,
> rpy2, numpy, ...) installed.
>

Maybe there is something wrong with ffi. (In fact the complex support of mips
was added by me. ;)

I am looking for a way to use debug to debug the extensions.
If you have any documents, can you point it to me.

> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



-- 
YunQiang Su

Bug#1050623: intake: autopkgtest needs update for dask 2023.8.0

[Graham Inggs]

Source: intake
Version: 0.6.6-1
Severity: serious
Tags: ftbfs
User: debian...@lists.debian.org
Usertags: needs-update

Hi Maintainer

Since the upload of dask 2023.8.0+dfsg-1, the autopkgtests of intake
are failing [1].  I've copied what I hope is the relevant part of the
log below.  This same failure causes intake to FTBFS in unstable.

Regards
Graham


[1] https://ci.debian.net/packages/i/intake/testing/amd64/


103s === FAILURES
===
103s ___ test_remote_env

103s
103s intake_server = 'intake://localhost:7483'
103s
103s def test_remote_env(intake_server):
103s import os
103s os.environ['INTAKE_TEST'] = 'client'
103s catalog = open_catalog(intake_server)
103s catalog.remote_env
103s with pytest.raises(Exception) as e:
103s catalog.remote_env.read()
103s
103s with pytest.raises(Exception) as e:
103s catalog.local_env
103s >   assert 'path-client' in str(e.value)
103s E   assert 'path-client' in "('Connection aborted.',
RemoteDisconnected('Remote end closed connection without response'))"
103s E+  where "('Connection aborted.',
RemoteDisconnected('Remote end closed connection without response'))"
= str(ConnectionError(ProtocolError('Connection aborted.',
RemoteDisconnected('Remote end closed connection without response'
103s E+where ConnectionError(ProtocolError('Connection
aborted.', RemoteDisconnected('Remote end closed connection without
response'))) = .value
103s
103s intake/catalog/tests/test_remote_integration.py:247: AssertionError

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

[Jon Westgate]

Dear Marco and others,

I will do a test build using ZSTD and see if that works. - I think the 
first thing I did was to switch back to XZ when this first happened 
Yesterday.


I've been using XZ for module compression since it was available, I just 
select it using make menuconfig I'm not using anything other than a 
slight tweek to the debian build.
I don't use signing as my UEFI allows me not to, the only other thing I 
do different to Debian is to build in USB support, filesystem support 
for ext4 and BTRFS and build in SCSI, LIBATA so that should my initrd 
fail for any reason I'm not left high and dry with no keyboard support 
and no access to a filesystem. I used to build in networking support, 
but I only do that systems that I use for firewalling as systemd won't 
allow networking unless everything else is mostly perfect.


I started using module compression for net boot thin clients as it made 
the resulting initrd way quicker to load over TFTP. Later on I switched 
to using it on all my systems as it made the boot process much quicker.


Finally I found that on recent 6.x kernels it was required due to a size 
limit that seemed to appear initrd. I'm not sure what makes this limit, 
it's there in grub and refind.


If what you say is true then kmod might have been masking a kernel bug 
for the last year.


I'm not doing anything clever here, I just get my source from 
cdn.kernel.org, use make menuconfig or vim to edit the .config and make 
-j8 && make -j8 modules_install && make install then reboot.

I'm not applying any patches, I do used the NVIDIA drivers on some boxes.

Jon


On 27/08/2023 02:10, Marco d'Itri wrote:

On Aug 26, Jon Westgate <0...@fsck.tv> wrote:


The error message it gave was "decompresson failed with status 6"

Status 6 is XZ_OPTIONS_ERROR, which means "Input was encoded with
settings that are not supported by this XZ decoder".
So it looks like you have compressed the modules (how?) with XZ settings
which are supported by the userspace loader but not by the kernel one.





OpenPGP_0x420652A8C309A3B2.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

[Marco d'Itri]

Control: retitle -1 kmod does not work with XZ in-kernel module decompression

On Aug 27, Jon Westgate  wrote:

> Note that I already had "Support in-kernel module decompression" selected
> when the compression method was XZ.
> 
> Would you like me to try without it?
No need to: we know that everything works fine without in-kernel 
decompression, because this is how the Debian kernel is configured.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

[Jon Westgate]

All,
To confirm that switching to ZSTD works.

I ran make menuconfig,
   [*] Enable loadable module support  --->

        Module compression mode (ZSTD) --->
        [*]   Support in-kernel module decompression
Note that I already had "Support in-kernel module decompression" 
selected when the compression method was XZ.


Would you like me to try without it?

On a side note switching module compression mode did not require a full 
recompile.
I presume it just linked in a different module decompressor, then 
compressed the modules using ZSTD on the fly when I ran make modules_install


Jon

On 27/08/2023 11:24, Jon Westgate wrote:

Dear Marco and others,

I will do a test build using ZSTD and see if that works. - I think the 
first thing I did was to switch back to XZ when this first happened 
Yesterday.


I've been using XZ for module compression since it was available, I 
just select it using make menuconfig I'm not using anything other than 
a slight tweek to the debian build.
I don't use signing as my UEFI allows me not to, the only other thing 
I do different to Debian is to build in USB support, filesystem 
support for ext4 and BTRFS and build in SCSI, LIBATA so that should my 
initrd fail for any reason I'm not left high and dry with no keyboard 
support and no access to a filesystem. I used to build in networking 
support, but I only do that systems that I use for firewalling as 
systemd won't allow networking unless everything else is mostly perfect.


I started using module compression for net boot thin clients as it 
made the resulting initrd way quicker to load over TFTP. Later on I 
switched to using it on all my systems as it made the boot process 
much quicker.


Finally I found that on recent 6.x kernels it was required due to a 
size limit that seemed to appear initrd. I'm not sure what makes this 
limit, it's there in grub and refind.


If what you say is true then kmod might have been masking a kernel bug 
for the last year.


I'm not doing anything clever here, I just get my source from 
cdn.kernel.org, use make menuconfig or vim to edit the .config and 
make -j8 && make -j8 modules_install && make install then reboot.

I'm not applying any patches, I do used the NVIDIA drivers on some boxes.

Jon


On 27/08/2023 02:10, Marco d'Itri wrote:

On Aug 26, Jon Westgate <0...@fsck.tv> wrote:


The error message it gave was "decompresson failed with status 6"

Status 6 is XZ_OPTIONS_ERROR, which means "Input was encoded with
settings that are not supported by this XZ decoder".
So it looks like you have compressed the modules (how?) with XZ settings
which are supported by the userspace loader but not by the kernel one.







OpenPGP_0x420652A8C309A3B2.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1041552: HFS/HFS+ are insecure

[Marco d'Itri]

On Aug 27, Diederik de Haas  wrote:

> While I agree that "orphan" does mean that it is NOT actively maintained, 
> AFAICT the situation is a bit more blurry for "odd fixes".
All these file systems are either rare enough and/or not used on 
removable media, so I do not believe that it is unreasonable to ask the
few users that want them to be mounted automatically to disable this 
policy with a symlink like
ln -s /dev/null /etc/udev/rules.d/75-insecure-fs.rules .

> Previously not knowing about that status, I looked up the commits where the 
> status was set to "odd fixes" and found that for some the reason was that the 
> maintainer didn't have the hardware to test it themselves.
> I do not think that's the same as 'unmaintained'.
It means that they are not tested enough...

> I'm not sure if it would actually result in unbootable systems, but I do think
> a bit more care should be taken before blacklisting modules.
Did you actually read the thread? No modules are being blacklisted, the 
plan is just to stop udisks2 from automatically mounting such removable 
media.
I am quite sure that routers file systems are not mounted with udisks2.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1050117: The patch has been applied to the Linux kernel repository.

[Diederik de Haas]

Control: tag -1 fixed-upstream

On Sunday, 27 August 2023 03:29:08 CEST Takashi Yano wrote:
> I have been notified that the patch has been applied to
> 5.15-stable tree, 6.1-stable tree and 6.4-stable tree.
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summ
> ary
> 
> I hope it will be incorporated into the Debian kernel.
> Thanks in advance.

Excellent, thanks for reporting back.
Upstream commit ID: 1d0eb6143c1e85d3f9a3f5a616ee7e5dc351d33b

signature.asc
Description: This is a digitally signed message part.

Bug#1050001: Unwinding directory aliasing [and 3 more messages]

[Matthew Vernon]

Dear Luca,

On 27/08/2023 03:16, Luca Boccassi wrote:

[things]

You've already been asked by a couple of people to moderate your tone in 
this thread. I appreciate there is a lot of frustration around 
/usr-merge, but your contributions are not helping with that at all. Nor 
do they help us have a constructive discussion.


The DEP-17 work continues whilst this discussion is ongoing; this 
discussion is not delaying that work.


I think it is fair to say that when ctte decided on /usr-merge it was 
expected that a) the process would be reasonably straightforward and b) 
dpkg could be taught to understand directory aliasing, so we would not 
have to be doing things "behind dpkg's back", as it were.


I think the need for a releases-long moratorium on moving files and the 
volume and depth of technical work represented by DEP17 demonstrate that 
those expectations turned out not to be met.


Given that, it seems to me that a) warnings that "it's not that simple & 
easy" were not FUD and describing them thus is unhelpful b) it's 
reasonable to at least ask the question "given what we know now, are we 
still sure this is the correct approach?"


Any such consideration must be mindful of the fact that the majority of 
Debian installs are now /usr-merged, which means that the complexity of 
unwinding such installs has to be a heavy factor in thinking about 
alternative approaches.


I'm hopeful, but not certain, that the DEP17 work will get us to a 
coherent state again by foxy (which still feels a long time off); I 
don't think we should underestimate the work to be done in properly 
completing /usr-merge.


This discussion has, I think, been broadly useful in clarifying some 
folks' thinking in this area. I would very much like if we could keep it 
focused on the technical matters.


Regards,

Matthew

Bug#1041552: HFS/HFS+ are insecure

[Diederik de Haas]

On Sunday, 27 August 2023 02:34:04 CEST Marco d'Itri wrote:
> So I propose this content for a file like
> /usr/lib/udev/rules.d/75-insecure-fs.rules:
> 
> # Do not automatically mount these file systems because their drivers are
> # marked as "orphan" or "odd fixes" in the kernel MAINTAINERS file and so

On Sunday, 23 July 2023 02:38:41 CEST Ben Hutchings wrote:
> I agree we should not have UDisks probing for any of the (many) kernel
> filesystems that aren't being actively maintained including responding
> to security issues.

While I agree that "orphan" does mean that it is NOT actively maintained, 
AFAICT the situation is a bit more blurry for "odd fixes".

Previously not knowing about that status, I looked up the commits where the 
status was set to "odd fixes" and found that for some the reason was that the 
maintainer didn't have the hardware to test it themselves.
I do not think that's the same as 'unmaintained'.

The main reason I looked into this was the "jffs2" entry and for that there was 
no reason given. But I know it is used in routers and SBCs and I saw recently 
a patch come by related to that, which was accepted so should be part of the 
6.6 kernel. Doing `gitk -- fs/jffs2/` also revealed that there were commits in 
6.5, 6.4 and 6.3 at which point I stopped investigating that as it was clear 
to me that it was anything but unmaintained.

Looking into MAINTAINERS, I also saw that `drivers/char/hw_random/` has the 
"Odd fixes" status...

I'm not sure if it would actually result in unbootable systems, but I do think 
a bit more care should be taken before blacklisting modules.

signature.asc
Description: This is a digitally signed message part.

Bug#1042343: binutils-msp430: FTBFS: make[1]: *** [debian/rules:36: override_dh_auto_build] Error 1

[Bastian Germann]

The stuff that is currently in debian/patches should be patched at the binutils-source package (if the files were 
available, which they are not). Please hand in your patches there and only maintain binutils patches that are 
platform-specific.


Thanks!

Bug#1043114: Please remove mipsel port from testing and sid

[Aurelien Jarno]

Hi Ansgar,

On 2023-08-27 08:32, Ansgar wrote:
> Hi,
> 
> On Sun, 2023-08-06 at 16:50 +0800, YunQiang Su wrote:
> > Since the Y2038 problem, 2G user space memory limit,
> > and some lack of manpower,  It's time for us to drop mipsel support
> > from the list of official release architectures.
> > 
> > Note: please keep mips64el for now.
> 
> Please stop building packages for mipsel for unstable/experimental so
> we can proceed here.

That should be done now. Now new packages will be built for unstable or
experimental, and I think I have killed all the running ones.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Bug#661454: O: mazeofgalious -- The Maze of Galious

[Bastian Germann]

Control: retitle -1 O: mazeofgalious -- The Maze of Galious
Control: noowner -1

The adoption failed.

Bug#1050622: linux-source-6.4: regression found upstream making AVX instructions unusable

[Alex Volkov]

Package: linux-source-6.4
Version: 6.4.4-3~bpo12+1
Severity: normal

Dear Maintainer,

a certain patch leads to a significant regression making AVX instructions
unusable in the CPUs having them:
https://lore.kernel.org/lkml/202307192135.203ac24e-oliver.s...@intel.com/

a fix is available upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/x86/kernel/fpu/xstate.c?id=2c66ca3949dc701da7f4c9407f2140ae425683a5

Of course, this fix will be included in the upstream kernel eventually, but
knowing Debian's long release cycle, I think including it as a distribution
patch would make sense.


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 
'stable'), (99, 'testing'), (90, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.4-bootes2-p-1000 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages linux-source-6.4 depends on:
ii  binutils  2.40-2
ii  xz-utils  5.4.1-0.2

Versions of packages linux-source-6.4 recommends:
ii  bc1.07.1-3+b1
ii  bison 2:3.8.2+dfsg-1+b1
ii  build-essential   12.9
ii  cpio  2.13+dfsg-7.1
ii  flex  2.6.4-8.2
ii  kmod  30+20221128-1
ii  libelf-dev0.188-2.1
ii  libssl-dev3.0.9-1
ii  linux-config-6.4  6.4.4-3~bpo12+1
ii  rsync 3.2.7-1

Versions of packages linux-source-6.4 suggests:
ii  libncurses-dev [ncurses-dev]  6.4-4
ii  pkgconf [pkg-config]  1.8.1-1
ii  qtbase5-dev   5.15.8+dfsg-11

-- no debconf information

Bug#1050621: blends-dev: Support conflicts and breaks relations in meta-packages

[Dominik George]

Package: blends-dev
Version: 0.7.5
Severity: wishlist

As discussed in [1], I would like to request addition of Conflicts and
Breaks relationships in tasks meta-package descriptions.

I ahve already started to scan the sources of blends-dev and to
implement the basics for the feature in [2], which works as I want it.

However, there are a few missing parts:

 * Packages in Conflicts or Breaks on some meta-package, but not
   in Requires, Recommends, Suggests or Ignore on others should
   be added to Avoid
 * The generated web pages should probably get a section for
   listed Conflcits and Breaks

Happy to receive advice on these two or any other missing parts.


[1] https://lists.debian.org/debian-blends/2023/08/msg0.html
[2] https://salsa.debian.org/blends-team/blends/-/merge_requests/14

Bug#1050620: coccinelle: Drop pcre

[Bastian Germann]

Source: coccinelle
Severity: important
Version: 0.2.5.deb-3

coccinelle build-depends on libpcre-ocaml-dev, which is optional.
Please drop it, so the package is not autoremoved.

Bug#1050069: RM: llvm-toolchain-14 -- ROM; Too many version of llvm

[Ilias Tsitsimpis]

On Sun, Aug 20, 2023 at 03:15PM, Ilias Tsitsimpis wrote:
> Can we please keep llvm-toolchain-14 in unstable? GHC 9.4.6 (which is
> the latest version used in stackage LTS, see https://www.stackage.org/)
> uses LLVM-14. I tried using LLVM-16 and it failed (see version
> 9.4.6-1~exp2 in experimental).

We ended up using LLVM 15 for GHC 9.4.6, which is now available in
unstable. Unfortunately, LLVM 16 is not yet supported by GHC.

-- 
Ilias

Bug#1050606: Acknowledgement (find: ‘/lib/systemd/system-sleep’: No such file or directory)

[Michael Biebl]

Control: tags -1 + patch

Please find attached a patch which should be sufficient to address this 
issue. I can offer to NMU, in case you are busy.



Regards,
Michael
diff --git a/debian/scripts/suspend/cryptsetup-suspend-wrapper b/debian/scripts/suspend/cryptsetup-suspend-wrapper
index 52e09dd1..953196c0 100644
--- a/debian/scripts/suspend/cryptsetup-suspend-wrapper
+++ b/debian/scripts/suspend/cryptsetup-suspend-wrapper
@@ -46,6 +46,7 @@ read_config() {
 # Run all executable scripts in directory SYSTEM_SLEEP_PATH with arguments ARGS
 # mimic systemd behavior
 run_dir() {
+[ -d "$SYSTEM_SLEEP_PATH" ] || return 0
 find "$SYSTEM_SLEEP_PATH" -type f -executable -execdir {} "$@" \;
 }
 


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050619: nbclient: unreproducible output - iopub.* timestamps

[Rebecca N. Palmer]

Package: python3-nbclient
Version: 0.8.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

By default, nbclient includes timestamps in its output, which makes 
packages built with it (e.g. python-pandas-doc) unreproducible.


It provides a record_timing option to turn this off, but this didn't 
work when I tried to use it (possibly it got dropped somewhere in the 
chain between the source notebook and nbclient?)

https://salsa.debian.org/science-team/pandas/-/commit/b89ff25fee3b67f2149c266068295b4875ea5e07#72770524feb6622ddedb14db1cf0160322cb455a_115_123
https://salsa.debian.org/science-team/pandas/-/jobs/4613211
and we also generally prefer modifying the tool to accept the standard 
"be reproducible" setting, instead of modifying every package that uses 
that tool to set tool-specific "be reproducible" settings.


This might fix it, but has NOT been tested.  (I chose to disable the 
timestamps when SOURCE_DATE_EPOCH is set, instead of setting them to 
SOURCE_DATE_EPOCH, because they are plausibly intended for measuring how 
long the code took to run, for which I'd rather have no answer than a 
wrong answer of 0.)


--- a/nbclient/client.py
+++ b/nbclient/client.py
@@ -4,6 +4,7 @@ import atexit
 import base64
 import collections
 import datetime
+import os
 import re
 import signal
 import typing as t
@@ -222,7 +223,7 @@ class NotebookClient(LoggingConfigurable
 ).tag(config=True)

 record_timing: bool = Bool(
-True,
+False if os.getenv("SOURCE_DATE_EPOCH") else True,
 help=dedent(
 """
 If ``True`` (default), then the execution timings of each 
cell will

Bug#1034356: gnome-shell: Frozen UI and massive log flodding

[H.-Dirk Schmitt]

Am Sonntag, dem 20.08.2023 um 12:17 +0100 schrieb Simon McVittie:
> Control: tags -1 + moreinfo
> 
> On Thu, 17 Aug 2023 at 09:58:42 +0100, Simon McVittie wrote:
> > The key change in gjs seems to be the second commit of
> >  so I'll
> > try to
> > build a package with that change for testing.
> 
> Please could you try installing the libgjs0g from here:
> 
> and then do whatever is necessary to reproduce the issue?


I have installed the update on my machine and will distribute the
update to other maintained machines. 

I don't know a simple reproduction of the problem. Sometimes it appears
shortly after login – sometimes it take days. 

Best regards and thanks,

H.-Dirk Schmitt

Bug#1050618: rocrand: failing autopkgtests on gfx1030

[Christian Kastner]

Source: rocrand
Version: 5.5.1-1
Severity: serious

The tests from ci.rocm.debian.net failed on gfx1030 [1]. I'm filing this
RC bug to prevent migration to testing.

[1] 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1030/r/rocrand/83/log.gz

Bug#1050432: rpy2: FTBFS on mips64el

[Dirk Eddelbuettel]

On 27 August 2023 at 14:09, YunQiang Su wrote:
| Dirk Eddelbuettel  于2023年8月27日周日 00:15写道：
| >
| >
| > Hi all,
| >
| > As the test failures for complex valued variables appeared to be systemic on
| > the 'mips64el' platform, I buckled down, taught myself some Python ==:-) and
| > conditioned the number of failing tests away via
| >
| >   @pytest.mark.skipif(platform.machine() == 'mips64' and sys.byteorder == 
'little',
| >   reason="Complex tests fails for 'mips64el'.")
| >
| > Maybe the porters team can shed some light on why we needed it, and if this
| > worked (the autobuilders will tell us soon enough) I can pass the patch on 
to
| > Laurent for a possible inclusion upstream.
| >
| 
| Sorry for the late reply. I can work on it.

Appreciate that!

(While my fix corrected the build, it is a stop-gap as it avoids the issue. A
real fix would be good.)

| Do you knwo any way to run a single testcase?

Can you start from the unit tests I conditioned out?  Each of those has
simple expression with a complex in it. Those should be executable directly
in the Python interpreter. You probably need all the build-deps (python, R,
rpy2, numpy, ...) installed.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1049952: csh: maintained by ubuntu-devel-disc...@lists.ubuntu.com

[Bastian Germann]

X-Debbugs-Cc: mckins...@debian.org

On Thu, 17 Aug 2023 11:34:56 +0200 Lucas Nussbaum  wrote:

Hi,

this package is maintained by ubuntu-devel-disc...@lists.ubuntu.com,
which is not a suitable contact point for Debian packages maintenance
according to https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

This is most likely due to generating the source package on an Ubuntu
machine. I think there's some magic that replaces the Maintainer field
in the Ubuntu tooling.


Alastair, as you are the owner of the Vcs-Git and the uploader of the last 
years,
would you please make yourself the Maintainer of csh? Otherwise I will orphan 
the package.

Thanks,
Bastian

Bug#1041524: logcheck: badly handles "rsyslog + journalctl" checking

[Stefan Froehlich]

Package: logcheck
Version: 1.4.2
Followup-For: Bug #1041524

Dear Maintainer,

I also had the problem of duplicated journalctl/rsyslogd messages with
different time formatting, but otherwise than suggested in this bug I'd
like to move to the precision format - and thus came up with a patch to
specify journalctl options before I even found this bug.

So perhaps you'd like to use (or adapt) my simple path which allowes to
add this to the configuration, if desired:

JOURNALCTL_OPTS="-oshort-iso-precise"




-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages logcheck depends on:
ii  adduser  3.134
ii  cron [cron-daemon]   3.0pl1-162
ii  lockfile-progs   0.1.19
ii  logtail  1.4.2
ii  mime-construct   1.12+really1.11-1
ii  sendmail-bin [mail-transport-agent]  8.17.1.9-2

Versions of packages logcheck recommends:
ii  logcheck-database  1.4.2

Versions of packages logcheck suggests:
ii  rsyslog [system-log-daemon]  8.2302.0-1

-- Configuration Files:
/etc/logcheck/header.txt [Errno 13] Permission denied: 
'/etc/logcheck/header.txt'
/etc/logcheck/logcheck.conf [Errno 13] Permission denied: 
'/etc/logcheck/logcheck.conf'
/etc/logcheck/logcheck.logfiles [Errno 13] Permission denied: 
'/etc/logcheck/logcheck.logfiles'
/etc/logcheck/logcheck.logfiles.d/journal.logfiles [Errno 13] Permission 
denied: '/etc/logcheck/logcheck.logfiles.d/journal.logfiles'
/etc/logcheck/logcheck.logfiles.d/syslog.logfiles [Errno 13] Permission denied: 
'/etc/logcheck/logcheck.logfiles.d/syslog.logfiles'

-- no debconf information
# The following variable settings are the initial default values,
# which can be uncommented and modified to alter logcheck's behaviour

# Controls the format of date-/time-stamps in subject lines:
# Alternatively, set the format to suit your locale

#DATE="$(date +'%Y-%m-%d %H:%M')"

# Controls the presence of boilerplate at the top of each message:
# Alternatively, set to "0" to disable the introduction.
#
# If the files /etc/logcheck/header.txt and /etc/logcheck/footer.txt
# are present their contents will be read and used as the header and
# footer of any generated mails.

#INTRO=1

# Controls the level of filtering:
# Can be Set to "workstation", "server" or "paranoid" for different
# levels of filtering. Defaults to server if not set.

REPORTLEVEL="server"

# Controls the address mail goes to:
# *NOTE* the script does not set a default value for this variable!
# Should be set to an offsite "emailaddr...@some.domain.tld"

SENDMAILTO="logcheck"

# Send the results as attachment or not.
# 0=not as attachment; 1=as attachment; 2=as gzip attachment
# Default is 0

MAILASATTACH=0

# Should the hostname in the subject of generated mails be fully qualified?

FQDN=1

# Controls whether "sort -u" is used on log entries (which will
# eliminate duplicates but destroy the original ordering); the
# default is to use "sort -k 1,3 -s":
# Alternatively, set to "1" to enable unique sorting

#SORTUNIQ=0

# Controls whether /etc/logcheck/cracking.ignore.d is scanned for
# exceptions to the rules in /etc/logcheck/cracking.d:
# Alternatively, set to "1" to enable cracking.ignore support

#SUPPORT_CRACKING_IGNORE=0

# Controls the base directory for rules file location
# This must be an absolute path

#RULEDIR="/etc/logcheck"

# Controls if syslog-summary is run over each section.
# Alternatively, set to "1" to enable extra summary.
# HINT: syslog-summary needs to be installed.

#SYSLOGSUMMARY=0

# Controls Subject: lines on logcheck reports:

#ATTACKSUBJECT="Security Alerts"
#SECURITYSUBJECT="Security Events"
#EVENTSSUBJECT="System Events"

# Controls [logcheck] prefix on Subject: lines

#ADDTAG="no"

# Previous versions of logcheck always sent messages in 7bit encoding,
# even if that resulted in RFC-violating messages. For example, really
# long syslog lines would generate too-long SMTP lines, which are
# rejected at least by Debian's default exim configuration. The new
# default is to let mime-construct pick an appropriate encoding, but you
# can override it by setting the below (to any of the encodings
# supported by mime-construct). You may need to do this if you have
# tools handling logcheck emails that don't understand MIME encoding.

#MIMEENCODING=

# Set a different location for temporary files than /tmp
# this is useful if your /tmp is small and you are getting
# errors such as:
# cp: writing `/tmp/logcheck.y12449/checked': No space left 

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

[Antonio]

ticket:

https://techpatterns.com/forums/about3040.html

Bug#1050616: apt-secure(8) points to non-existing page

[Jörg Sommer]

Package: apt
Version: 2.7.3
Severity: normal

Hi,

the manualpage apt-secure points to
https://www.debian.org/doc/manuals/securing‐debian‐howto/ch7 which doesn't
exist:

```
% curl -sI https://www.debian.org/doc/manuals/securing‐debian‐howto/ch7
HTTP/2 404 
content-location: 404.en.html
…
```

Regards Jörg


-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/anydesk.list present, but not submitted) --


-- (/etc/apt/sources.list.d/mozilla.list present, but not submitted) --


-- (/etc/apt/sources.list.d/skype-stable.list present, but not submitted) --


-- (/etc/apt/sources.list.d/waydroid.list present, but not submitted) --


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-0-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.137
ii  base-passwd 3.6.1
ii  debian-archive-keyring  2023.4
ii  gpgv2.2.40-1.1
ii  libapt-pkg6.0   2.7.3
ii  libc6   2.37-7
ii  libgcc-s1   13.2.0-2
ii  libgnutls30 3.8.1-4
ii  libseccomp2 2.5.4-1+b3
ii  libstdc++6  13.2.0-2
ii  libsystemd0 254.1-3

Versions of packages apt recommends:
ii  ca-certificates  20230311

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.21.22
ii  gnupg2.2.40-1.1
ii  powermgmt-base   1.37

-- no debconf information


signature.asc
Description: PGP signature

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

[Antonio]

I don't build kernel from source, I use binary packages installed from 
liquorix repositories https://liquorix.net/.


I opened a ticket to their forum, maybe a recompilation of the kernel is 
enough.


We await your reply...


Il 27/08/23 03:10, Marco d'Itri ha scritto:

On Aug 26, Jon Westgate <0...@fsck.tv> wrote:


The error message it gave was "decompresson failed with status 6"

Status 6 is XZ_OPTIONS_ERROR, which means "Input was encoded with
settings that are not supported by this XZ decoder".
So it looks like you have compressed the modules (how?) with XZ settings
which are supported by the userspace loader but not by the kernel one.

Bug#1050615: Crash: Illegal instruction / invalid opcode in libxul.so on Pentium M

[Daniel Richard G.]

Package: firefox-esr
Version: 102.14.0esr-1~deb12u1
Severity: important

Loading certain sites in Firefox ESR causes the tab to crash, and on
occasion, the browser as a whole. A reliable cause of this is the Google
account login page, which this crash makes impossible to traverse.

I had to start the browser with MOZ_CRASHREPORTER_DISABLE=1 set in
the environment to disable BreakPad, or else I would not get useful
telemetry from the system logs.

The terminal output shows

Illegal instruction

and syslog shows these entries:

2023-08-27T02:31:20.899434-04:00 darkstar kernel: [  713.633343] traps: 
Isolated Web Co[2454] trap invalid opcode ip:b0af8174 sp:bff0c340 error:0 in 
libxul.so[ab957000+5c91000]
2023-08-27T02:33:48.231483-04:00 darkstar kernel: [  860.962987] traps: 
Isolated Web Co[2843] trap invalid opcode ip:b0af8abc sp:bfcd35b0 error:0 in 
libxul.so[ab957000+5c91000]

This is on a Pentium M laptop running the i386 build of Debian bookworm.
CPU information:

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 13
model name  : Intel(R) Pentium(R) M processor 1.80GHz
stepping: 6
microcode   : 0x17
cpu MHz : 800.000
cache size  : 2048 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov clflush 
dts acpi mmx fxsr sse sse2 ss tm pbe bts cpuid est tm2 pti
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit mmio_unknown
bogomips: 3588.46
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 32 bits virtual
power management:


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1048895: john: Fails to build source after successful build

[Peter Wienemann]

Control: tags -1 + patch

See https://salsa.debian.org/pkg-security-team/john/-/merge_requests/2

Bug#1043114: Please remove mipsel port from testing and sid

[Ansgar]

Hi,

On Sun, 2023-08-06 at 16:50 +0800, YunQiang Su wrote:
> Since the Y2038 problem, 2G user space memory limit,
> and some lack of manpower,  It's time for us to drop mipsel support
> from the list of official release architectures.
> 
> Note: please keep mips64el for now.

Please stop building packages for mipsel for unstable/experimental so
we can proceed here.

Ansgar

Bug#1050530: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#1050530: fixed in python3.11 3.11.5-2)

[Jochen Sprickerhof]

Hi Matthias,

I think it would be enough to add the tzdata-legacy dependency to 
libpython3.11-testsuite.


I've also send a patch upstream to switch to the normal name:

https://github.com/python/cpython/pull/108533

Cheers Jochen

* Debian Bug Tracking System  [2023-08-26 19:09]:

This is an automatic notification regarding your Bug report
which was filed against the src:python3.11 package:

#1050530: python3.11: autopkgtest needs update for new version of tzdata

It has been closed by Debian FTP Masters  (reply to 
Matthias Klose ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to Matthias Klose ) by
replying to this email.


--
1050530: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050530
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Date: Sat, 26 Aug 2023 19:05:36 +
To: 1050530-cl...@bugs.debian.org
Reply-To: Matthias Klose 
From: Debian FTP Masters 
Subject: Bug#1050530: fixed in python3.11 3.11.5-2




Date: Fri, 25 Aug 2023 21:08:52 +0200
To: sub...@bugs.debian.org
User-Agent: Mozilla Thunderbird
From: Paul Gevers 
Subject: python3.11: autopkgtest needs update for new version of tzdata

Source: python3.11
Version: 3.11.4-1
Severity: serious
X-Debbugs-CC: tzd...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:tzdata

Dear maintainer(s),

With a recent upload of tzdata the autopkgtest of python3.11 fails in 
testing when that autopkgtest is run with the binary packages of 
tzdata from unstable. It passes when run with only packages from 
testing. In tabular form:


  passfail
tzdata from testing2023c-10
python3.11 from testing3.11.4-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. I note that 
src:tzdata recently introduced a tzdata-legacy package although I 
don't know if that has to do with the failure.


Currently this regression is blocking the migration of tzdata to 
testing [1]. Of course, tzdata shouldn't just break your autopkgtest 
(or even worse, your package), but it seems to me that the change in 
tzdata was intended and your package needs to update to the new 
situation.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=tzdata

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python3.11/37127326/log.gz

1107s ==
1107s FAIL: test_variable_tzname 
(test.test_email.test_utils.LocaltimeTests.test_variable_tzname)

1107s --
1107s Traceback (most recent call last):
1107s   File "/usr/lib/python3.11/test/support/__init__.py", line 847, 
in inner

1107s return func(*args, **kwds)
1107s^^^
1107s   File "/usr/lib/python3.11/test/test_email/test_utils.py", line 
155, in test_variable_tzname

1107s self.assertEqual(t1.tzname(), 'MSK')
1107s AssertionError: 'Europe' != 'MSK'
1107s - Europe
1107s + MSK








signature.asc
Description: PGP signature

Bug#1050614: src:dpf-plugins: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: dpf-plugins
Version: 1.6+ds-2
Severity: serious
Control: close -1 1.7+ds-1
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:dpf-plugins has been trying to migrate for 
31 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=dpf-plugins



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050613: src:numba: fails to migrate to testing for too long: triggers autopkgtest failure

[Paul Gevers]

Source: numba
Version: 0.56.4+dfsg-2
Severity: serious
Control: close -1 0.57.1+dfsg-1
X-Debbugs-CC: python-spa...@packages.debian.org
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: affects -1 src:python-sparse

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:numba has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable triggers 
failures in python-sparse on amd64 and ppc64el (the rest regressed 
already last year).


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=numba



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050044: bullseye-pu: package rar/2:5.5.0-1

[Markus Koschany]

There was another vulnerability, CVE-2023-40477, fixed in version 2:6.23-
1~deb11u1 now.


signature.asc
Description: This is a digitally signed message part

Bug#1050612: bookworm-pu: package rar/2:6.20.0.1

[Markus Koschany]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org

Please see Debian bug #1050044. Same reasoning applies to Bookworm.
Here rar is only affected by CVE-2023-40477 though.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

rar is a binary blob which is why I cannot provide a useful debdiff.

Regards,

Markus

Bug#1050432: rpy2: FTBFS on mips64el

[YunQiang Su]

Dirk Eddelbuettel  于2023年8月27日周日 00:15写道：
>
>
> Hi all,
>
> As the test failures for complex valued variables appeared to be systemic on
> the 'mips64el' platform, I buckled down, taught myself some Python ==:-) and
> conditioned the number of failing tests away via
>
>   @pytest.mark.skipif(platform.machine() == 'mips64' and sys.byteorder == 
> 'little',
>   reason="Complex tests fails for 'mips64el'.")
>
> Maybe the porters team can shed some light on why we needed it, and if this
> worked (the autobuilders will tell us soon enough) I can pass the patch on to
> Laurent for a possible inclusion upstream.
>

Sorry for the late reply. I can work on it.
Do you knwo any way to run a single testcase?

> Cheers,  Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>


-- 
YunQiang Su