Bug#1054567: ocserv: Compilation error on the LoongArch architecture

[Aron Xu]

Hi,

> On Oct 26, 2023, at 10:54, wuruilong  wrote:
> 
> Source: ocserv
> Version: 1.2.1-1
> Severity: normal
> X-Debbugs-Cc: wuruil...@loongson.cn
> 
> Dear Maintainer,
> 
>  There is a compilation error for ocserv on the loongarch machine. 
> Tested the patch attached to the email on the LoongArch machine and it 
> resolved the issue.
> 

I see the patch is quite straightforward, would you mind submit it to upstream, 
too?

Cheers,
Aron

Bug#1053931: restinio: [src:restinio] Uses embedded code copies

[Amin Bandali]

Hi Tobi,

Thanks for the report. :-)

I just uploaded 0.6.19+ds-1 to unstable, repacking the
orig upstream tarball to remove several embedded copies;
namely:

- dev/asio/*
- dev/fmt/*
- dev/nodejs/http_parser/*
- dev/rapidjson/*
- dev/restinio/third_party/zlib/*

I believe none of these were actually being used, but
as you said, it's good to remove them to be sure of that.

dev/catch2/ is a bit more tricky, because restinio is currently only
compatible with the v2 series, whereas catch2 has released their v3
series (packaged in unstable as well), which appears to be backward
incompatible with v2.  Per restinio developers[1], adapting restinio
to catch2 v3 may be a non-trivial effort, and will have to wait until
they start work on their next major series.  As such, it seems we'll
have to continue including dev/catch2/ for a while longer until
restinio developers get around to porting restinio to catch v3.
So, I didn't close this bug in the changelog entry for 0.6.19+ds-1,
but will keep an eye on the situation for when restinio is ported to
catch2, at which point I'd make the change to exclude it from the
tarball as well and use the system package.

Best,
-a

[1] https://github.com/Stiffstream/restinio/issues/158

Bug#1054575: jffi: Add support for Loongarch

[yalingfang]

Package: jffi
Version:  1.3.9+ds-6
Severity: wishlist
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear maintainers,

   When I compiled jffi for  for loong64 in the Debian Package，

and found it should be added support for loongarch.

Now the patched had been merged in github and released in tag 1.3.10.

https://github.com/jnr/jffi/commit/f870ed046006dc90c33f1af338061f7a77bf51b5


We have added loongarch architecture support for jffi in local env. The 
patch


can be found in the attachment or got from github.

  If you have any questions, you can contact me at any time.


add-support-for-loongarch64.patch
Description: Binary data

Bug#1054574: adminer seems dead upstream, switch to adminerevo ?

[Rémi Letot]

Package: adminer
Severity: wishlist
X-Debbugs-Cc: hob...@poukram.net

Dear Maintainer,

according to git activity and comments in the issues, adminer seems dead 
upstream. 

Part of the community have forked it into adminerevo: 

https://docs.adminerevo.org/

Would you consider packaging that instead of adminer ?

Thanks

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

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

Versions of packages adminer depends on:
pn  libapache2-mod-php | php-cgi | php-fpm | php  
pn  php-mysql | php-sqlite3 | php-pgsql   

Versions of packages adminer recommends:
pn  apache2 | httpd   
ii  php-cli   2:8.2+93
pn  php-mysql 
pn  php-pgsql 
pn  php-sqlite3   
ii  php8.2-cli [php-cli]  8.2.10-2

Versions of packages adminer suggests:
ii  sqlite3  3.43.2-1

Bug#1054536: cyrus-sasl2 FTBFS: sphinx failure: AttributeError("'str' object has no attribute 'attributes'")

[Jochen Sprickerhof]

Hi Helmut,

* Helmut Grohne  [2023-10-25 11:47]:

Source: cyrus-sasl2
Version: 2.1.28+dfsg1-3
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

cyrus-sasl2 fails to build from source in unstable. A non-parallel build
ends as follows:

| /usr/bin/sphinx-build -d docsrc/.doctrees -n -q -D today=2023-08-03 -b html 
./docsrc ./doc/html
| WARNING: extlinks: Sphinx-6.0 will require a caption string to contain 
exactly one '%s' and all other '%' need to be escaped as '%%'.
| WARNING: extlinks: Sphinx-6.0 will require a caption string to contain 
exactly one '%s' and all other '%' need to be escaped as '%%'.
|
| Theme error:
| An error happened in rendering the page developer.
| Reason: AttributeError("'str' object has no attribute 'attributes'")
| make[2]: *** [Makefile:1165: doc/html/.sphinx-build.stamp] Error 2
| make[2]: Leaving directory '/<>/build-mit'
| dh_auto_build: error: cd build-mit && make -j1 
sasldir=/usr/lib/x86_64-linux-gnu/sasl2 all doc-html returned exit code 2
| make[1]: *** [debian/rules:166: override_dh_auto_build] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:127: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

I don't quit see the cause of this failure just yet, maybe someone else
does?


This is due to this line:

https://sources.debian.org/src/cyrus-sasl2/2.1.28%2Bdfsg1-3/docsrc/_templates/layout.html/#L2

and a simple workaround is to remove it.

I think a proper fix is to add 


html_css_files = ['cyrus.css']

to docsrc/conf.py instead, as per

https://docs.readthedocs.io/en/stable/guides/adding-custom-css.html

But I have not verified that it gives the same result.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1054573: RM: praat [s390x ppc64] -- ROM; buggy on big endian systems

[Rafael Laboissière]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: pr...@packages.debian.org
Control: affects -1 + src:praat

Since upstream version 6.3.18 of Praat, changes have been introduced that 
make praat segfault at startup and make the package FTBFS on big endian 
architectures. This issue has been reported upstream [1], but there is no 
sign of reaction for now.

In the meanwhile, would it be possible to remove the package for s390x 
and ppc64 ? This is blocking the migration of praat into testing.

Thanks,

Rafael Laboissière

[1] https://github.com/praat/praat/issues/2545#issuecomment-1774119930

Bug#1042048: python-ase: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[Lucas Nussbaum]

Hi Graham,

On 26/08/23 at 12:21 +, Graham Inggs wrote:
> Control: severity -1 important
> Control: tags -1 + unreproducible
> 
> Hi Lucas
> 
> I'm unable to reproduce this failure locally, also python-ase builds
> successfully on reproducible builds [1].

I just checked again, and can still reproduce this.

Lucas

Bug#1054572: ITP: libgraph-moreutils-perl -- utilities for Perl graphs

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: libgraph-moreutils-perl
  Version : 0.1.0
  Upstream Author : Andrius Merkys 
* URL : https://metacpan.org/release/Graph-MoreUtils
* License : LGPL-3
  Programming Lang: Perl
  Description : utilities for Perl graphs
 Graph::MoreUtils provides additional utilities for Perl graph handling.
 These utilities work with Perl Graph class objects.

This package is needed to update chemonomatopist (a new dependency).

Remark: This package is to be maintained with Debian Perl Group at

https://salsa.debian.org/perl-team/modules/packages/libgraph-moreutils-perl

Bug#1054570: webp-pixbuf-loader: renders black webp images in geeqie

[kent]

Package: webp-pixbuf-loader
Version: 0.2.4-2
Severity: important
Tags: upstream

The 0.2.4 build of webp-pixbuf-loader has an issue with GdkPixbufLoader which 
causes it not to render webp images or create accurate thumbnails in Geeqie.  
0.2.1 is unaffected but assumed to be compiled against a DSA-5497-1 vulnerable 
libwebp.

The current 0.2.5 upstream does not fix this but there is an active pull 
request which addresses this issue.
https://github.com/aruiz/webp-pixbuf-loader/pull/73

Geeqie seems to have merged a workaround which is refered to in the above pull 
request.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 webp-pixbuf-loader depends on:
ii  libc62.37-12
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.78.0-2
ii  libwebp7 1.3.2-0.3
ii  libwebpdemux21.3.2-0.3
ii  libwebpmux3  1.3.2-0.3

webp-pixbuf-loader recommends no packages.

webp-pixbuf-loader suggests no packages.

-- no debconf information

Bug#1051939: ubpm_1.9.0+20230923-1_amd64.changes REJECTED

[Steven Robbins]

On Monday, October 23, 2023 1:00:09 P.M. CDT Thorsten Alteholz wrote:
> Hi,
> 
> please ask upstream to add all licenses of embedded stuff like
> ./sources/plugins/shared/hidapi 

Could you expand on this request?  Each file notes "At the discretion of the 
user of this library,  this software may be licensed under the terms of the 
GNU General Public License v3, a BSD-Style license, ..."  The debian/copyright 
specifies GPL-3:

Files: sources/plugins/shared/hidapi/*
Copyright: 2022, 2023 libusb/hidapi Team
License: GPL-3

What are you asking to be added?

> As upstream didn't wrote the PDFs, please
> add their licenses as well. I doubt that Debian is allowed to distribute
> them but I am open to conviction.

Sorry, that is a clear miss on my part.  I will clarify the license or remove 
these before re-uploading.

Best,
-Steve


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

Bug#1054569: qtbase-opensource-src: FTBFS: Please add support for loongarch64

[zhangdandan]

Source: qtbase-opensource-src
Version: 5.15.10+dfsg-4
Severity: wishlist
Tags: ftbfs patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

We need to add architectural support for qtbase-opensource-src.
Otherwise it will cause test cases failures for other packages which 
depend qtbase-opensource-src.
For example, the kpackage now has a build status of Build-Attempted. 
Please see the detail message at [1].


BTW, A recent query revealed that LoongArch architecture is now 
supported by the upstream [2].
Please consider the patch I have attached. Or pull full support from 
upstream.
Would it be possible to include the support for LoongArch in the next 
upload?

If you have any questions, you can contact me at any time.

[1]:https://buildd.debian.org/status/package.php?p=kpackage&suite=sid
[2]:https://github.com/qt/qtbase

thanks,
Dandan Zhang
Description: Add support for loongarch64. 
---
Last-Update: 2023-10-07

--- qtbase-opensource-src-5.15.10+dfsg.orig/src/3rdparty/double-conversion/include/double-conversion/utils.h
+++ qtbase-opensource-src-5.15.10+dfsg/src/3rdparty/double-conversion/include/double-conversion/utils.h
@@ -93,6 +93,7 @@ int main(int argc, char** argv) {
 #if defined(_M_X64) || defined(__x86_64__) || \
 defined(__ARMEL__) || defined(__avr32__) || defined(_M_ARM) || defined(_M_ARM64) || \
 defined(__hppa__) || defined(__ia64__) || \
+defined(__loongarch__) || \
 defined(__mips__) || \
 defined(__powerpc__) || defined(__ppc__) || defined(__ppc64__) || \
 defined(_POWER) || defined(_ARCH_PPC) || defined(_ARCH_PPC64) || \
--- qtbase-opensource-src-5.15.10+dfsg.orig/src/3rdparty/forkfd/forkfd_linux.c
+++ qtbase-opensource-src-5.15.10+dfsg/src/3rdparty/forkfd/forkfd_linux.c
@@ -82,7 +82,7 @@ static int sys_clone(unsigned long clone
 return syscall(__NR_clone, cloneflags, child_stack, stack_size, ptid, newtls, ctid);
 #elif defined(__arc__) || defined(__arm__) || defined(__aarch64__) || defined(__mips__) || \
 defined(__nds32__) || defined(__hppa__) || defined(__powerpc__) || defined(__i386__) || \
-defined(__x86_64__) || defined(__xtensa__) || defined(__alpha__) || defined(__riscv)
+defined(__x86_64__) || defined(__xtensa__) || defined(__alpha__) || defined(__riscv) || defined(__loongarch__)
 /* ctid and newtls are inverted on CONFIG_CLONE_BACKWARDS architectures,
  * but since both values are 0, there's no harm. */
 return syscall(__NR_clone, cloneflags, child_stack, ptid, ctid, newtls);
--- qtbase-opensource-src-5.15.10+dfsg.orig/src/corelib/global/archdetect.cpp
+++ qtbase-opensource-src-5.15.10+dfsg/src/corelib/global/archdetect.cpp
@@ -71,6 +71,8 @@
 #  define ARCH_PROCESSOR "riscv32"
 #elif defined(Q_PROCESSOR_RISCV_64)
 #  define ARCH_PROCESSOR "riscv64"
+#elif defined(Q_PROCESSOR_LOONGARCH_64)
+#  define ARCH_PROCESSOR "loongarch64"
 #elif defined(Q_PROCESSOR_S390_X)
 #  define ARCH_PROCESSOR "s390x"
 #elif defined(Q_PROCESSOR_S390)
--- qtbase-opensource-src-5.15.10+dfsg.orig/src/corelib/global/qglobal.cpp
+++ qtbase-opensource-src-5.15.10+dfsg/src/corelib/global/qglobal.cpp
@@ -1967,6 +1967,29 @@ bool qSharedBuild() noexcept
 */
 
 /*!
+\macro Q_PROCESSOR_LOONGARCH
+\relates 
+\since 5.13
+
+Defined if the application is compiled for LoongArch processors. Qt currently
+supports one LoongArch variants: \l Q_PROCESSOR_LOONGARCH_64.
+
+\sa QSysInfo::buildCpuArchitecture()
+*/
+
+/*!
+\macro Q_PROCESSOR_LOONGARCH_64
+\relates 
+\since 5.13
+
+Defined if the application is compiled for 64-bit LoongArch processors. The \l
+Q_PROCESSOR_LOONGARCH macro is also defined when Q_PROCESSOR_LOONGARCH_64 is
+defined.
+
+\sa QSysInfo::buildCpuArchitecture()
+*/
+
+/*!
 \macro Q_PROCESSOR_S390
 \relates 
 
--- qtbase-opensource-src-5.15.10+dfsg.orig/src/corelib/global/qprocessordetection.h
+++ qtbase-opensource-src-5.15.10+dfsg/src/corelib/global/qprocessordetection.h
@@ -300,6 +300,15 @@
 #  endif
 #  define Q_BYTE_ORDER Q_LITTLE_ENDIAN
 
+#elif defined(__loongarch__)
+#  define Q_PROCESSOR_LOONGARCH
+#  if __loongarch_grlen == 64
+#define Q_PROCESSOR_LOONGARCH_64
+#  else
+#define Q_PROCESSOR_LOONGARCH_32
+#  endif
+#  define Q_BYTE_ORDER Q_LITTLE_ENDIAN
+
 /*
 S390 family, known variant: S390X (64-bit)
 

Bug#1054568: breezy - broken rust regex build-dependency

[Peter Green]

Package: breezy
Version: 3.3.4-1
Severity: serious
Tags: patch

Breezy build-depends on librust-regex+aho-corasick-dev which is no longer
provided (in either physical or virtual form) by rust-regex.

Looking at the Cargo.toml files I belive the correct build-dependency is
librust-regex-1+default-dev (>= 1.5.4), after changing the build-dependency
I was able to get a succesful build.

If there are no objections I will likely NMU this in the not too distant
future.diff -Nru breezy-3.3.4/debian/changelog breezy-3.3.4/debian/changelog
--- breezy-3.3.4/debian/changelog   2023-09-04 17:39:38.0 +
+++ breezy-3.3.4/debian/changelog   2023-10-26 02:55:52.0 +
@@ -1,3 +1,12 @@
+breezy (3.3.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace broken build-dependency on "librust-regex+aho-corasick-dev"
+with build-dependency on "librust-regex-1+default-dev (>= 1.5.4)"
+based on the contents of Cargo.toml.
+
+ -- Peter Michael Green   Thu, 26 Oct 2023 02:55:52 +
+
 breezy (3.3.4-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru breezy-3.3.4/debian/control breezy-3.3.4/debian/control
--- breezy-3.3.4/debian/control 2023-09-04 17:39:38.0 +
+++ breezy-3.3.4/debian/control 2023-10-26 02:55:40.0 +
@@ -31,7 +31,7 @@
debhelper-compat (= 13),
librust-pkg-version-dev,
librust-pyo3-dev,
-   librust-regex+aho-corasick-dev,
+   librust-regex-1+default-dev (>= 1.5.4),
rustc
 Standards-Version: 4.6.2
 Rules-Requires-Root: no

Bug#1054567: ocserv: Compilation error on the LoongArch architecture

[wuruilong]

Source: ocserv
Version: 1.2.1-1
Severity: normal
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

  There is a compilation error for ocserv on the loongarch machine. 
Tested the patch attached to the email on the LoongArch machine and it resolved 
the issue.

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 ocserv (1.2.1-1) unstable; urgency=medium
 .
   * New upstream version 1.2.1
   * Replace nuttcp with iperf3 from B-D
Author: Aron Xu 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2023-10-26

--- ocserv-1.2.1.orig/src/worker-privs.c
+++ ocserv-1.2.1/src/worker-privs.c
@@ -182,7 +182,9 @@ int disable_system_calls(struct worker_s
 
ADD_SYSCALL(open, 0);
ADD_SYSCALL(openat, 0);
+#if defined(SYS_fstat) || defined(__NR_fstat)
ADD_SYSCALL(fstat, 0);
+#endif
 #if defined(SYS_fstat64) || defined(__NR_fstat64)
ADD_SYSCALL(fstat64, 0);
 #endif

Bug#1054566: twinkle-uri-handler script missing. Please update to release 1.10.3

[Jason Lewis]

Package: twinkle
Version: 1:1.10.2+dfsg-2
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Twinkle requires helper script so you can dial out by clicking tel links in
Firefox. Current 1.10.2 does not include this script

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



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

Kernel: Linux 6.1.0-13-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 twinkle depends on:
ii  libasound2   1.2.8-1+b1
ii  libc62.36-9+deb12u3
ii  libccrtp2v5  2.0.9-2.3
ii  libgcc-s112.2.0-14
ii  libgsm1  1.0.22-1
ii  libmagic11:5.44-3
ii  libqt5core5a 5.15.8+dfsg-11
ii  libqt5gui5   5.15.8+dfsg-11
ii  libqt5qml5   5.15.8+dfsg-3
ii  libqt5quick5 5.15.8+dfsg-3
ii  libqt5widgets5   5.15.8+dfsg-11
ii  libreadline8 8.2-1.3
ii  libsndfile1  1.2.0-1
ii  libspeex11.2.1-2
ii  libspeexdsp1 1.2.1-1
ii  libstdc++6   12.2.0-14
ii  libucommon8  7.0.1-0.1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  qml-module-qtquick2  5.15.8+dfsg-3
ii  twinkle-common   1:1.10.2+dfsg-2

twinkle recommends no packages.

twinkle suggests no packages.

-- no debconf information

Bug#1040996: Davical defines a Content-Security-Policy without scoping it to its own resources

[Andrew Ruthven]

Hi Alain,

Thanks for the bug report. I have added a fix to DAViCal so the CSP is only
applied to the Directory as suggested.

I'm looking at your .well-known request, but I don't think DAViCal and
NextCloud can co-exist so easily as it looks like they both have overlapping
well-known paths. I would expect they need to go into their own vhost.

And while I could limit the rewrites, we still have:

  RewriteRule ^(.*)$ /caldav.php$1  [NC,L]

I think there'll be far too many different options to want to split that
out.

Cheers,
Andrew

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud:   | This space intentionally left blank
 https://catalystcloud.nz |

Bug#1054565: RFP: golang-github-zeebo-xxh3 -- XXH3 algorithm in Go

[James McCoy]

Package: wnpp
Severity: wishlist
Control: block 1037440 by -1

* Package name: golang-github-zeebo-xxh3
  Version : 1.0.2-1
  Upstream Author : Jeff Wendling
* URL : https://github.com/zeebo/xxh3
* License : BSD-2-clause
  Programming Lang: Go
  Description : XXH3 algorithm in Go

 XXH3
 .
 GoDoc (https://godoc.org/github.com/zeebo/xxh3) Sourcegraph
 (https://sourcegraph.com/github.com/zeebo/xxh3?badge) Go Report Card
 (https://goreportcard.com/report/github.com/zeebo/xxh3)
 .
 This package is a port of the xxh3 (https://github.com/Cyan4973/xxHash)
 library to Go.
 .
 Upstream has fixed the output as of v0.8.0, and this package matches
 that.

This is needed to package a new upstream version of kitty.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1054564: apache2: mod_proxy_connect insecure default server-wide AllowCONNECT value

[Raphaël Droz]

Package: apache2
Version: 2.4.56-1~deb11u2
Severity: normal
X-Debbugs-Cc: raphael.d...@gmail.com

Dear Maintainer,

# Context

For years, one of my SSL vhost (on :443) has been relying mod_proxy_http to 
(safely)
 forward some requests to a backend, acting as a reverse-proxy.
```
# Something like
ProxyRequests   On
SSLProxyEngine  On
RewriteRule ^/.well-known/.*$ "https://gitlab-foobar/%{REQUEST_URI}"; [P,L]
```


Recently, I experienced the need to (safely) forward some requests (from 
another server I own)
 through this server (because of some network/geoblocking problem).
I enabled `mod_proxy_connect` and (safely) configured a forward-proxy on :80 
(using `Require valid-user / ip`).
```
# Something like
ProxyRequests On
Authtype Basic
AuthUserFile ...

p  Require valid-user
  Require ip ...

```


# Problem

While this :80 forward-proxy vhost was secure, I later discovered, that 
 the original (and almost forgotten) vhost had incidentally become an 
open-proxy (!)

The reasons are:
- mod_proxy_connect is globally enabled (affects all vhosts)
- AllowCONNECT defaults to "443 563" (affects all vhosts)


Said otherwise, *any* secure reverse-proxy vhost configuration become de-facto
 an insecure open forward-proxy vhost as soon as `mod_proxy_connect` is 
globally enabled.

This sounds contrary to best security practices.
(and I bet more than one server out there is silently affected by this 
insecure-by-default
configuration)


# Proposed solution

I suggest to add a server-wide `AllowCONNECT 0` directive inside
`/etc/apache2/mods-available/proxy_connect.load` (virtually disabling CONNECT)
so that individual vhosts relying on it would have to explicitely set the value 
at the vhost-level.

It would be more logical (scope/side-effects) and avoid holes being punched 
into existing
 (and otherwise secure) reverse-proxy vhosts.


# Additional notes
To cap it all my proxy-enabled vhost was the first one (lexicographically
speaking) making it the destination of all the random internet SSL traffic 
scanners.


Google-friendly list of typical log messages that should raise flags:
> AH00898: Connect to remote machine blocked returned by...
> AH00939: CONNECT: attempt to connect to ...:443 (...) failed
> AH10221: proxy: CONNECT: client flushing failed (-102)
> AH10221: proxy: CONNECT: origin flushing failed (-102)


-- Package-specific info:

-- System Information:
Debian Release: bullseye
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.2.0-35-generic (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 apache2 depends on:
ii  apache2-bin  2.4.56-1~deb11u2
ii  apache2-data 2.4.56-1~deb11u2
ii  apache2-utils2.4.56-1~deb11u2

Versions of packages apache2 recommends:
pn  ssl-cert  

Versions of packages apache2 suggests:
pn  apache2-doc   
pn  apache2-suexec-pristine | apache2-suexec  

Versions of packages apache2 is related to:
ii  apache2  2.4.56-1~deb11u2
ii  apache2-bin  2.4.56-1~deb11u2

-- Configuration Files:
/etc/apache2/apache2.conf changed [not included]

-- no debconf information

-- 
GPG id: 0xF41572CEBD4218F4

Bug#1053481: libdpkg-perl: dpkg-source fails to generate (complete) Testsuite-Triggers if test deps have :native qualifier

[James McCoy]

On Thu, Oct 05, 2023 at 07:11:32AM +0200, Guillem Jover wrote:
> Right, nice catch! Given that these fields are based on what might
> appear on build dependencies, I think it does make sense to consider
> them an overlay on top of those. So I'll make them allow anything that
> is allowed for build dependencies.

Would that just be the below patch?

diff --git i/scripts/Dpkg/Deps/Simple.pm w/scripts/Dpkg/Deps/Simple.pm
index 431c93bb9..da7aedbd8 100644
--- i/scripts/Dpkg/Deps/Simple.pm
+++ w/scripts/Dpkg/Deps/Simple.pm
@@ -194,7 +194,6 @@ sub parse_string {
   \s*$  # trailing spaces at end
 }x;
 if (defined $2) {
-return if $2 eq 'native' and not $self->{build_dep};
 $self->{archqual} = $2;
 }
 $self->{package} = $1;

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1054563: gnome-shell-extension-trash: New version

[Carlo Stemberger]

Package: gnome-shell-extension-trash
Version: 0.2.0-git20200326.3425fcf1-1
Severity: wishlist

Hi,
the GitHub repository seems to be abandoned since 2017.

You can find the new versione here:

https://gitlab.com/bertoldia/gnome-shell-trash-extension

Best regards,
Carlo


-- System Information:
Debian Release: 12.2
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-13-rt-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 gnome-shell-extension-trash depends on:
ii  gnome-shell  43.6-1~deb12u2

gnome-shell-extension-trash recommends no packages.

gnome-shell-extension-trash suggests no packages.

-- no debconf information

Bug#1004066: groestlcoin: FTBFS pubkey.cpp:181:96: error: invalid conversion from 'secp256k1_xonly_pubkey*' to 'size_t'

[Bastian Germann]

This should be fixed with v25 which contains the following commit:
https://github.com/Groestlcoin/groestlcoin/commit/4462cb04986d77eddcfc6e8f75e04dc278a8147a

Bug#1054562: apache2ctl: add new one-word command: list-vhosts

[Thorsten Glaser]

Package: apache2
Version: 2.4.56-1~deb11u2
Severity: wishlist
X-Debbugs-Cc: t...@mirbsd.de, report...@stoffels.it

Please add a new “apache2ctl list-vhosts” command that can
be discovered using the apache2ctl(8) manual page, so that
people don’t have to “remember” the full command:

sudo apache2ctl -t -D DUMP_VHOSTS


-- Package-specific info:

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

Kernel: Linux 5.10.0-26-amd64 (SMP w/1 CPU thread)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.56-1~deb11u2
ii  apache2-data 2.4.56-1~deb11u2
ii  apache2-utils2.4.56-1~deb11u2
ii  dpkg 1.20.13
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  mime-support 3.66
ii  perl 5.32.1-4+deb11u2
ii  procps   2:3.3.17-5

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.0+nmu1

Versions of packages apache2 suggests:
ii  apache2-doc  2.4.56-1~deb11u2
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-6+deb11u2
ii  libaprutil1  1.6.1-5+deb11u1
ii  libaprutil1-dbd-sqlite3  1.6.1-5+deb11u1
ii  libaprutil1-ldap 1.6.1-5+deb11u1
ii  libbrotli1   1.0.9-2+b2
ii  libc62.31-13+deb11u7
ii  libcrypt11:4.4.18-4
ii  libcurl4 7.88.1-10+deb12u4~bpo11+0wtf1
ii  libjansson4  2.13.1-1.1
ii  libldap-2.4-22.4.57+dfsg-3+deb11u1
ii  liblua5.3-0  5.3.3-1.1+deb11u1
ii  libnghttp2-141.43.0-1
ii  libpcre3 2:8.39-13
ii  libssl1.11.1.1w-0+deb11u1
ii  libxml2  2.9.10+dfsg-6.7+deb11u4
ii  perl 5.32.1-4+deb11u2
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages apache2-bin suggests:
ii  apache2-doc  2.4.56-1~deb11u2
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2 is related to:
ii  apache2  2.4.56-1~deb11u2
ii  apache2-bin  2.4.56-1~deb11u2

-- Configuration Files:
/etc/apache2/apache2.conf changed [not included]
/etc/apache2/sites-available/000-default.conf changed [not included]
/etc/apache2/sites-available/default-ssl.conf changed [not included]
/etc/logrotate.d/apache2 changed [not included]

-- no debconf information

Bug#1054559: numfmt: --to lakh ?

[Pádraig Brady]

On 25/10/2023 22:57, Trent W. Buck wrote:

Package: coreutils
Version: 9.1-1
Severity: wishlist
File: /usr/bin/numfmt
Tags: upstream

In India it is common to write large numbers using combinations of
"lakh" / "L" (10⁷) and "crore" / "cr" (10⁵).

 https://en.wikipedia.org/wiki/Lakh
 https://en.wikipedia.org/wiki/Crore

For example,

 According to […] ₹15.3 lakh crore of the ₹15.41 lakh crore in demonetised 
bank notes, […]

 — https://en.wikipedia.org/wiki/2016_Indian_banknote_demonetisation

When I try to convert these to SI units in my head, I always mess up.

Could numfmt handle this for me?
Something like this (my maths might be wrong!):

 $ numfmt --from=auto --to=लाख 15.3T
 15.3 lakh crore

 $ numfmt --from=auto --to=लाख 1.2G
 120 crore

 $ numfmt --from=auto --to=लाख 1.2M
 12 lakh

 $ numfmt --from=लाख --to=si 12 lakh
 1.2M

 $ numfmt --from=लाख --to=si 15.3 lakh crore
 15.3T


Noted in upstream todo.
This is something that would be nice to have in numfmt.
The designator might be better as "indic" rather than "लाख".
The space between number and suffixes would be hard to support.
So I;m thinking something like this would be more achievable:

  $ numfmt --from=auto --to=indic 15.3T
  15.3Lcr

thanks,
Pádraig

Bug#1015871: Enabling PCI_P2PDMA for distro kernels?

[Simon Richter]

Hi,

On 10/26/23 02:11, Lukas Wunner wrote:


This has recently been brought up internally at Intel and nobody could
understand why there's a whitelist in the first place.  A long-time PCI
architect told me that Intel silicon validation has been testing P2PDMA
at least since the Lindenhurst days, i.e. since 2005.


My PCIe test box generates URE completions in the root complex when I 
try to address iGPU BARs from an FPGA, and texture fetches from the iGPU 
that use BAR addresses on the FPGA do not get forwarded (so I venture 
that is an URE as well).


CPU:  i3-3225 CPU @ 3.30GHz (fam: 06, model: 3a, stepping: 09)

pci :00:00.0: [8086:0150] type 00 class 0x06
pci :00:01.0: [8086:0151] type 01 class 0x060400
pci :00:02.0: [8086:0162] type 00 class 0x03
pci :00:14.0: [8086:1e31] type 00 class 0x0c0330
pci :00:16.0: [8086:1e3a] type 00 class 0x078000
pci :00:1a.0: [8086:1e2d] type 00 class 0x0c0320
pci :00:1b.0: [8086:1e20] type 00 class 0x040300
pci :00:1c.0: [8086:1e10] type 01 class 0x060400
pci :00:1c.4: [8086:1e18] type 01 class 0x060400
pci :00:1d.0: [8086:1e26] type 00 class 0x0c0320
pci :00:1f.0: [8086:1e4a] type 00 class 0x060100
pci :00:1f.2: [8086:1e00] type 00 class 0x01018f
pci :00:1f.3: [8086:1e22] type 00 class 0x0c0500
pci :00:1f.5: [8086:1e08] type 00 class 0x010185
pci :01:00.0: [1172:1337] type 00 class 0xff
pci :03:00.0: [10ec:8168] type 00 class 0x02

So there is at least one configuration that doesn't work. :P

   Simon

Bug#1054561: closing

[Carles Pina i Estany]

I closed it as duplicated of #1053682

-- 
Carles Pina i Estany
https://carles.pina.cat


signature.asc
Description: PGP signature

Bug#1054561: RFS: qnetload/1.3.6-1 [ITP] -- Graphically display network speed and usage

[Carles Pina i Estany]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "qnetload":

 * Package name : qnetload
   Version  : 1.3.6-1
   Upstream contact : Carles Pina i Estany 
 * URL  : https://github.com/cpina/qnetload
 * License  : GPL-3, CC-BY-3.0
 * Vcs  : https://salsa.debian.org/carlespina/qnetload
   Section  : net

The source builds the following binary packages:

  qnetload - Graphically display network speed and usage

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/qnetload/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/q/qnetload/qnetload_1.3.6-1.dsc

Changes for the initial release:

 qnetload (1.3.6-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1053480)

Regards,-- 
Carles Pina i Estany
https://carles.pina.cat


signature.asc
Description: PGP signature

Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol

[Xiyue Deng]

Hi Arto, Bo,

Xiyue Deng  writes:

> Hi Bo,
>
> Bo YU  writes:
>
>> Hi!
>>
>> On Wed, Oct 25, 2023 at 5:06 PM Arto Jantunen  wrote:
>>>
>>> Xiyue Deng  writes:
>>>
>>> > Arto Jantunen  writes:
>>> >
>>> >> Xiyue Deng  writes:
>>> >>
>>> >>> Hi Arto,
>>> >>>
>>> >>> Arto Jantunen  writes:
>>> >>>
>>>  Xiyue Deng  writes:
>>> > Package: sponsorship-requests
>>> > Severity: important
>>> > X-Debbugs-CC: debian-emac...@lists.debian.org
>>> >
>>> > Dear mentors,
>>> >
>>> > I am looking for a sponsor for my package "lsp-mode":
>>> >
>>> >  * Package name : lsp-mode
>>> >Version  : 8.0.0-6
>>> >Upstream contact : Vibhav Pant 
>>> >  * URL  : https://github.com/emacs-lsp/lsp-mode
>>> >  * License  : GPL-3+
>>> >  * Vcs  : https://salsa.debian.org/emacsen-team/lsp-mode
>>> >Section  : lisp
>>> >
>>> > The source builds the following binary packages:
>>> >
>>> >   elpa-lsp-mode - Emacs client/library for the Language Server 
>>> > Protocol
>>> >
>>> > To access further information about this package, please visit the 
>>> > following URL:
>>> >
>>> >   https://mentors.debian.net/package/lsp-mode/
>>> >
>>> > Alternatively, you can download the package with 'dget' using this 
>>> > command:
>>> >
>>> >   dget -x 
>>> > https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>>> >
>>> > Changes since the last upload:
>>> >
>>> >  lsp-mode (8.0.0-6) unstable; urgency=medium
>>> >  .
>>> >* Add patch to fix test failures (Closes: #1052939).
>>> >* Update Standards-Version to 4.6.2.  No change needed.
>>> >* Add myself as uploader (Closes: #1042568).
>>> >* Add signing key verification to d/watch.
>>> >* Add d/upstream/metadata.
>>> >* Add Upstream-Contact and update year in d/copyright.
>>> >* Add patch to fix non-UTF-8 encoding.
>>> >* Drop unused lintian overrides.
>>> 
>>>  Thanks for taking over this package.
>>> 
>>>  When I try to build this (under sbuild) I get the following build
>>>  failure:
>>> 
>>>  Test ‘lsp-text-document-hover-request’ redefined
>>> 
>>>  Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
>>>    mapbacktrace(#f(compiled-function (evald func args flags) #>>  -0x187de6214517952>))
>>>    debug-early-backtrace()
>>>    debug-early(error (error "Test ‘lsp-text-document-hover-request’ 
>>>  redefined"))
>>>    error("Test `%s' redefined" lsp-text-document-hover-request)
>>>    ert-set-test(lsp-text-document-hover-request #s(ert-test :name
>>>  lsp-text-document-hover-request :documentation nil :body (closure (t) 
>>>  nil
>>>  (lsp-workspace-folders-add (f-join lsp-test-location "fixtures")) 
>>>  (find-file
>>>  (f-join lsp-test-location "fixtures/pyls/test.py")) (lsp) 
>>>  (deferred:sync!
>>>  (deferred:nextc (deferred:nextc (lsp-test--wait-for '(progn (eq 
>>>  'initialized
>>>  (lsp--workspace-status (cl-first (lsp-workspaces)) #'(lambda (_) 
>>>  (goto-char
>>>  (point-min)) (search-forward "fn1") (lsp-def-request-async 
>>>  "textDocument/hover"
>>>  (lsp--text-document-position-params #'(lambda (contents) (let* 
>>>  ((fn-566
>>>  #'lsp-hover?) (args-567 (condition-case err (let ((signal-hook-function
>>>  #'ert--should-signal-hook)) (list contents)) (error (progn (setq fn-566
>>>  #'signal) (list (car err) (cdr err))) (let ((value-568
>>>  'ert-form-evaluation-aborted-569)) (let (form-description-570) (if
>>>  (unwind-protect (setq value-568 (apply fn-566 args-567)) (setq
>>>  form-description-570 (nconc (list '(should (lsp-hover? contents))) 
>>>  (list :form
>>>  (cons fn-566 args-567)) (if (eql value-568 
>>>  'ert-form-evaluation-aborted-569) nil
>>>  (list :value value-568)) (if (eql value-568 
>>>  'ert-form-evaluation-aborted-569)
>>>  nil (let* ((-explainer- (and t (ert--get-explainer 'lsp-hover? (if
>>>  -explainer- (list :explanation (apply -explainer- args-567)) nil)
>>>  (ert--signal-should-execution form-description-570)) nil (ert-fail
>>>  form-description-570))) value-568) (kill-buffer)
>>>  (lsp-workspace-folders-remove (f-join lsp-test-location "fixtures")))
>>>  :most-recent-result nil :expected-result-type :passed :tags nil 
>>>  :file-name
>>>  "/<>/test/lsp-integration-test.el"))
>>>    
>>>  load-with-code-conversion("/<>/test/lsp-integration-test.el"
>>>   "/<>/test/lsp-integration-test.el" nil t)
>>>    command-line-1(("-l" "package" "--eval" "(add-to-list 
>>>  'package-directory-list
>>>  \"/usr/share/emacs/site-lisp/elpa\")" "--eval" "(add-to-list
>>>  'package-directory-list \"/usr/share/emacs/site-lisp/elpa-

Bug#1042087: Please replace libdb++-dev with libdb5.3++-dev

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is included.diff -Nru animals-201207131226/debian/changelog 
animals-201207131226/debian/changelog
--- animals-201207131226/debian/changelog   2018-04-16 19:21:27.0 
+0200
+++ animals-201207131226/debian/changelog   2023-10-26 00:57:51.0 
+0200
@@ -1,3 +1,10 @@
+animals (201207131226-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace libdb++-dev with libdb5.3++-dev. (Closes: #1042087)
+
+ -- Bastian Germann   Thu, 26 Oct 2023 00:57:51 +0200
+
 animals (201207131226-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru animals-201207131226/debian/control 
animals-201207131226/debian/control
--- animals-201207131226/debian/control 2018-04-16 19:21:27.0 +0200
+++ animals-201207131226/debian/control 2023-10-26 00:57:51.0 +0200
@@ -2,7 +2,7 @@
 Priority: optional
 Maintainer: Alberto Fuentes 
 Build-Depends: debhelper (>= 9),
- libdb++-dev,
+ libdb5.3++-dev,
 Standards-Version: 3.9.3
 Section: games
 Homepage: http://software.keep-cool.org/animals.html

Bug#1042086: Please replace libdb++-dev with libdb5.3++-dev

[Bastian Germann]

I am uploading a NMU to fix this. The changes are included in the git repo.

Bug#1054560: python3-validators: regex DoS

[David Weinehall]

Package: python3-validators
Version: 0.20.0-2
Severity: normal
Tags: upstream security
X-Debbugs-Cc: t...@debian.org, Debian Security Team 

The version in Debian suffers from a regex vulnerability. The issue has been
fixed in python3-validators 0.21.0.

Latest available upstream version is 0.22.0.


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

Kernel: Linux 6.4.0-4-amd64 (SMP w/20 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 python3-validators depends on:
ii  python33.11.4-5+b1
ii  python3-decorator  5.1.1-5

python3-validators recommends no packages.

python3-validators suggests no packages.

-- no debconf information

Bug#1054552: glibc: stat fails when access time is bogus

[Simon McVittie]

Control: reassign -1 libc6

On Wed, 25 Oct 2023 at 20:53:57 +0200, Jarek Czekalski wrote:
> I tried to upgrade system (apt-get upgrade), but it failed in dpkg:
> 
> Unpacking initscripts (3.06-4) over (2.96-7+deb11u1) ...
> dpkg: error processing archive
> /var/cache/apt/archives/initscripts_3.06-4_all.deb (--unpack):
>  unable to stat './var/log' (which was about to be installed): Value too
> large for defined data type

This is nothing to do with GLib (libglib2.0-0), but I assume you meant
glibc (libc6)? Quoting the rest of the bug report below for glibc
maintainers:

> stat /var/log
> 
>   File: /var/log
>   Size: 4096    Blocks: 8  IO Block: 4096 directory
> Device: 8,1 Inode: 2752691 Links: 12
> Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/ root)
> Access: 2040-05-10 23:31:40.285032309 +0200
> Modify: 2023-10-25 16:03:42.313742411 +0200
> Change: 2023-10-25 16:03:42.313742411 +0200
>  Birth: 2017-02-27 09:46:56.739719147 +0100
> 
> This date (2040) causes dpkg to fail. The workaround is correcting it by
> touch /var/log.
> 
> Running system with bogus date (2040).
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> touch /var/log
>    * What was the outcome of this action?
> dpkg started working
>    * What outcome did you expect instead?
> dpkg should work with strange date or give a better message. Maybe just
> documentation (for stat) should be fixed and suggest problems with dates.
> 
> Current outcome is as follows: apt-get suddenly fails with a cryptic message
> (initially it was "unable to stat '.'" instead of /var/log). It may be
> extremely difficult to diagnose the issue.

It is not possible for 32-bit stat() to work correctly on 32-bit systems
with dates beyond 2038, because the timestamp will not fit in the data
type used. The only solution would be for the program in question (in
this case, dpkg) to be compiled with support for 64-bit timestamps.

Your bug report seems to be from an upgrade from Debian 11 to Debian 12,
and Debian 11's glibc version did not support APIs that provide 64-bit
timestamps on 32-bit systems, so Debian 11's dpkg cannot support that
either.

Debian 12's glibc does, but that will only help you after fully upgrading
to Debian 12, at which point you will have Debian 12 versions of glibc
and dpkg.

Unfortunately, I don't think there's necessarily anything that can be done
here, beyond the general move towards supporting 64-bit timestamps
distribution-wide that is already in progress.

smcv

Bug#1054559: numfmt: --to lakh ?

[Trent W. Buck]

Package: coreutils
Version: 9.1-1
Severity: wishlist
File: /usr/bin/numfmt
Tags: upstream

In India it is common to write large numbers using combinations of
"lakh" / "L" (10⁷) and "crore" / "cr" (10⁵).

https://en.wikipedia.org/wiki/Lakh
https://en.wikipedia.org/wiki/Crore

For example,

According to […] ₹15.3 lakh crore of the ₹15.41 lakh crore in demonetised 
bank notes, […]

— https://en.wikipedia.org/wiki/2016_Indian_banknote_demonetisation

When I try to convert these to SI units in my head, I always mess up.

Could numfmt handle this for me?
Something like this (my maths might be wrong!):

$ numfmt --from=auto --to=लाख 15.3T
15.3 lakh crore

$ numfmt --from=auto --to=लाख 1.2G
120 crore

$ numfmt --from=auto --to=लाख 1.2M
12 lakh

$ numfmt --from=लाख --to=si 12 lakh
1.2M

$ numfmt --from=लाख --to=si 15.3 lakh crore
15.3T




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

Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9+deb12u3
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b6

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#1020358: libmagickcore-6.q16-7: transition gsfonts/gsfonts-x11 --> fonts-urw-base35

[Vincent Lefevre]

On 2023-10-23 14:07:36 +0200, Bastien ROUCARIES wrote:
> Le lun. 23 oct. 2023 à 11:45, Vincent Lefevre  a écrit :
> 
> > Control: found -1 8:6.9.12.98+dfsg1-2
> >
> > On 2022-09-20 18:18:23 +0200, fab...@debian.org wrote:
> > > you are receiving this bug report, because your package declares a
> > > relationship with the gsfonts and/or gsfonts-x11 packages. Both
> > > packages have been replaced by fonts-urw-base35 since version
> > > 20200910-2 and are now merely transitional dummy packages. In order
> > > to make it possible to remove these transitional packages, please
> > > adjust the relationships for your package accordingly.
> >
> > Any news?
> >
> > This is annoying, because on imagemagick upgrade, aptitude wants
> > to reinstall gsfonts, which I had removed.
> 
> Patch welcome hère. Will apply asap

I've attached a patch.

First, the change of gsfonts to a transitional package is bogus as
it potentially breaks (silently or not) the build of packages that
expect a normal gsfonts package. The current imagemagick version
has

--with-gs-font-dir=/usr/share/fonts/type1/gsfonts \

in its debian/rules file while the fonts were replaced by those in
the /usr/share/fonts/type1/urw-base35 directory.

That said, I don't know the consequences in practice. Apparently,
this affects the ghostscript_font_dir variable, which is used only
by config/type-ghostscript.xml.in (a typemap file).

Anyway, in the attached patch, I've replaced this line by

   --with-urw-base35-font-dir=/usr/share/fonts/type1/urw-base35 \

The other changes are the replacement of the gsfonts package by
fonts-urw-base35 in control and the control.d directory.

I don't know what to do with the tests and tests.d directories,
as rebuilding the package with this patch doesn't fail.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -aurd imagemagick-6.9.12.98+dfsg1-a/debian/control imagemagick-6.9.12.98+dfsg1-b/debian/control
--- imagemagick-6.9.12.98+dfsg1-a/debian/control	2023-10-21 16:00:53.0 +0200
+++ imagemagick-6.9.12.98+dfsg1-b/debian/control	2023-10-25 22:05:51.710331333 +0200
@@ -19,7 +19,7 @@
 # for special function
  libfftw3-dev, liblcms2-dev, liblqr-1-0-dev,
 # for fonts
- libfreetype-dev, libfontconfig-dev, gsfonts,
+ libfreetype-dev, libfontconfig-dev, fonts-urw-base35,
 # for compression
  zlib1g-dev, liblzma-dev, libbz2-dev,
 # for X
@@ -227,7 +227,7 @@
 Pre-Depends: ${misc:Pre-Depends}, dpkg (>= 1.17.6)
 Depends: ${shlibs:Depends}, ${misc:Depends},
  imagemagick-6-common (>= 8:6.9.6.2+dfsg-3)
-Recommends: ghostscript, gsfonts
+Recommends: ghostscript, fonts-urw-base35
 Suggests: libmagickcore-6.q16-7-extra
 Description: low-level image manipulation library -- quantum depth Q16
  The MagickCore API is a low-level interface between the C programming language
@@ -437,7 +437,7 @@
 Pre-Depends: ${misc:Pre-Depends}, dpkg (>= 1.17.6)
 Depends: ${shlibs:Depends}, ${misc:Depends},
  imagemagick-6-common (>= 8:6.9.6.2+dfsg-3)
-Recommends: ghostscript, gsfonts
+Recommends: ghostscript, fonts-urw-base35
 Suggests: libmagickcore-6.q16hdri-7-extra
 Description: low-level image manipulation library -- quantum depth Q16HDRI
  The MagickCore API is a low-level interface between the C programming language
diff -aurd imagemagick-6.9.12.98+dfsg1-a/debian/control.d/noquantum.in imagemagick-6.9.12.98+dfsg1-b/debian/control.d/noquantum.in
--- imagemagick-6.9.12.98+dfsg1-a/debian/control.d/noquantum.in	2023-10-12 11:08:33.0 +0200
+++ imagemagick-6.9.12.98+dfsg1-b/debian/control.d/noquantum.in	2023-10-25 22:03:05.422726491 +0200
@@ -18,7 +18,7 @@
 # for special function
  libfftw3-dev, liblcms2-dev, liblqr-1-0-dev,
 # for fonts
- libfreetype-dev, libfontconfig-dev, gsfonts,
+ libfreetype-dev, libfontconfig-dev, fonts-urw-base35,
 # for compression
  zlib1g-dev, liblzma-dev, libbz2-dev,
 # for X
diff -aurd imagemagick-6.9.12.98+dfsg1-a/debian/control.d/quantum.in imagemagick-6.9.12.98+dfsg1-b/debian/control.d/quantum.in
--- imagemagick-6.9.12.98+dfsg1-a/debian/control.d/quantum.in	2023-10-12 11:08:33.0 +0200
+++ imagemagick-6.9.12.98+dfsg1-b/debian/control.d/quantum.in	2023-10-25 22:03:05.422726491 +0200
@@ -38,7 +38,7 @@
 Pre-Depends: ${misc:Pre-Depends}, dpkg (>= 1.17.6)
 Depends: ${shlibs:Depends}, ${misc:Depends},
  imagemagick-${IMVERSION}-common (>= ${COMMONMINVERSION})
-Recommends: ghostscript, gsfonts
+Recommends: ghostscript, fonts-urw-base35
 Suggests: libmagickcore-${IMVERSION}.${QUANTUMDEPTH}-${CORESOVERSION}-extra
 Description: low-level image manipulation library -- quantum depth ${UCQUANTUMDEPTH}
  The MagickCore API is a low-level interface between the C programming language
diff -aurd imagemagick-6.9.12.98+dfsg1-a/debian/rules imagemagick-6.9.12.98+dfsg1-b/debian/rules
--- imagemagick-6.9.12.98+dfsg1-a/debian/rules	2023-10-21 16:39:53.0 +0200
+++ 

Bug#1054557: Suggest home.arpa instead of "make something up" during installation if no dedicated domain name

[Holger Levsen]

On Wed, Oct 25, 2023 at 09:22:04PM +, Michael Kjörling wrote:
> Proposed replacement text:
> 
> "If you are setting up or joining a network for which you do not have
> another domain name to use, you should enter 'home.arpa' here."
> 
> It may even be beneficial if this is also reflected by the field being
> pre-populated with "home.arpa".

thanks, fwiw, I agree.

It would also be great if this question would be asked with lower priority,
especially in rescue-mode, when one is eager to have ones system booting
again...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If it feels like we’re breaking climate records every year, it’s because we are.


signature.asc
Description: PGP signature

Bug#1054558: iotop: crashes on non-utf8 characters

[Marc Lehmann]

Package: iotop
Version: 0.6-42-ga14256a-0.1+b2
Severity: normal

Dear Maintainer,

independent of locale (or the fatc that locales are per-process), if
iotop finds a command line argument that is not utf-8 encoded, it simply
crashes. regardless of how it handles encodings it does not understand, it
should not simply crash:

   File "/usr/lib/python3/dist-packages/iotop/data.py", line 311, in get_cmdline
   cmdline = proc_cmdline.read(4096)
 ^^^
 File "", line 322, in decode
   UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 2259: 
invalid continuation byte

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 6.1.55-schmorp (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 iotop depends on:
ii  python3  3.11.2-1+b1

iotop recommends no packages.

iotop suggests no packages.

-- no debconf information

Bug#1053936: python3-distro-info: packaging lacks a py.typed flag file

[Benjamin Drung]

On Sat, 2023-10-14 at 17:53 +0200, Alexandre Detiste wrote:
> Package: python3-distro-info
> Version: 1.5
> Severity: normal
> 
> Dear Maintainer,
> 
> While trying to validate game-data-packager's annotations, mypy complains:
> 
> $ mypy --strict tools/ppa.py'
> tools/ppa.py:11: error: Skipping analyzing "distro_info": module is 
> installed, but missing library stubs or py.typed marker  [import-untyped]
> tools/ppa.py:11: note: See 
> https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
> 
> 
> After creating some py.typed - the locations _feels_ wrong,
> but I don't know better - mypy will stop complaining:
> 
> ~# mkdir /usr/lib/python3/dist-packages/distro_info
> ~# touch /usr/lib/python3/dist-packages/distro_info/py.typed
> 
> $ mypy --strict tools/ppa.py 
> Success: no issues found in 1 source file

Thanks for the report. https://peps.python.org/pep-0561/ does not really
tell how to work with py_modules. Since /usr/lib/python3/dist-
packages/distro_info/py.typed works, I'll put the marker there.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1054557: Suggest home.arpa instead of "make something up" during installation if no dedicated domain name

[Michael Kjörling]

Package: debian-installer
Version: 20230607+deb12u2

As a part of the network configuration during the system installation,
the Debian installer prompts the user for a host name and a domain
name.

The domain name prompt includes the text:

"If you are setting up a home network, you can make something up, but
make sure you use the same domain name on all your computers."

It is generally undesirable to "make something up" with regards to a
domain name, as anything a user is likely to come up with can easily
cause DNS name conflicts either now or in the future, itself leading
to hard-to-diagnose connectivity issues and nonintuitive error
responses. It should be expected that any system installed today
likely will be connected to the Internet; therefore, where possible,
defaults and suggestions should encourage the use of settings which
make conflicts with other hosts on the global Internet less likely.

RFC 8375 of May 2018 (with a current status of Proposed Standard)
specifically reserves a special-use domain name for "non-unique use in
residential home networks". This is similar to the IPv4 address
reservations for "private Internets" in RFC 1918 (192.168.0.0/16,
172.16.0.0/12, 10.0.0.0/8).

The domain name reserved by RFC 8375 for this purpose is "home.arpa.".

The Debian installer should suggest to use that as the domain name
unless the user has specific cause to use a different domain name.

Proposed replacement text:

"If you are setting up or joining a network for which you do not have
another domain name to use, you should enter 'home.arpa' here."

It may even be beneficial if this is also reflected by the field being
pre-populated with "home.arpa".

-- 
Michael Kjörling

Bug#1002056: Fedora plans to transition to Zlib-ng

[Guillem Jover]

Hi!

On Wed, 2023-10-25 at 14:13:54 -0300, Nelson A. de Oliveira wrote:
> JFTR, Fedora is planning to transition to Zlib-ng
> 
> https://fedoraproject.org/wiki/Changes/ZlibNGTransition

Ah, thanks! I had in my mind getting back to this ITP, given that the
zlib-ng project has continued to gain traction and seems to have
consolidated most of the other forks around it.

So I'll draft another mail to Mark and probably to debian-devel to
discuss this.

Thanks,
Guillem

Bug#1054554: RFS: streamlink/6.3.0-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 6.3.0.

  * Package name: streamlink
Version : 6.3.0-1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs  : https://github.com/wxMaxima-developers/wxmaxima
Section : python

It builds those binary packages:

   python3-streamlink - Python module for extracting video streams from
various websites
   python3-streamlink-doc - CLI for extracting video streams from
various websites (documentation)
   streamlink - CLI for extracting video streams from various websites
to a video player

To access further information about this package, please visit the
following URL:

   https://mentors.debian.net/package/streamlink/

Alternatively, you can download the package with 'dget' using this command:

   dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.3.0-1.dsc

Changes since the last upload to unstable:
streamlink (6.3.0-1) unstable; urgency=medium

  * d/README: update backport instructions
  * d/README: update readme for building backported package
  * New upstream version 6.3.0
  * d/patches: remove now unneeded patch that was removing versioningit

 -- Alexis Murzeau   Wed, 25 Oct 2023 21:37:25 +0200


Regards,
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F




OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054267: RM: fltk1.1 -- RoQA; leaf library

[Bastian Germann]

Control: severity -1 normal
Control: reassign -1 ftp.debian.org

As the maintainer agreed on the removal and the last reverse dependency has 
upgraded to 1.3,
I am filing the removal request now.

Bug#1054323: fixed in r-cran-tmb 1.9.6-2

[Paul Gevers]

Hi

On 25-10-2023 09:31, Andreas Tille wrote:

This leaves one failing test with

  48s > library('TMB')
  48s Error: package or namespace load failed for ‘TMB’ in loadNamespace(j <- 
i[[1L]], c(lib.loc, .libPaths()), versionCheck = vI[[j]]):
  48s  namespace ‘Matrix’ 1.6-1 is being loaded, but >= 1.6.1.1 is required

which is to be expected if I understand things correctly.


rmatrix is at 1.6-1.1-1, I think you have the version wrong because of 
the double hyphen.


paul@mulciber ~ $ dpkg --compare-versions 1.6-1-1 ge 1.6-1.1 ; echo $?
0

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054553: python-werkzeug: CVE-2023-46136

[Salvatore Bonaccorso]

Source: python-werkzeug
Version: 2.2.2-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-werkzeug.

CVE-2023-46136[0]:
| Werkzeug is a comprehensive WSGI web application library. If an
| upload of a file that starts with CR or LF and then is followed by
| megabytes of data without these characters: all of these bytes are
| appended chunk by chunk into internal bytearray and lookup for
| boundary is performed on growing buffer. This allows an attacker to
| cause a denial of service by sending crafted multipart data to an
| endpoint that will parse it. The amount of CPU time required can
| block worker processes from handling legitimate requests. This
| vulnerability has been patched in version 3.0.1.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-46136
https://www.cve.org/CVERecord?id=CVE-2023-46136
[1] https://github.com/pallets/werkzeug/security/advisories/GHSA-hrfv-mqp8-q5rw
[2] 
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1042947: UDD: create a duck importer

[Lucas Nussbaum]

On 08/08/23 at 06:42 +0200, Lucas Nussbaum wrote:
> Hi Baptiste,
> 
> On 07/08/23 at 22:07 +0200, Baptiste Beauplat wrote:
> > Hi Lucas,
> > 
> > On 2023-08-03 10:30, Lucas Nussbaum wrote:
> > > duck-as-a-service (duck.debian.net) has been broken for a long time,
> > > and
> > > the corresponding UDD importer is broken as well (see #949009,
> > > #963887).
> > > In the meantime, duck continued evolving (was rewritten?) and is now
> > > checking a lot more places for URLs.
> > > 
> > > It would probably be useful to re-create a way to provide duck
> > > results
> > > as a service, based on UDD, similarly to what is done for upstream or
> > > lintian data.
> > > 
> > > Ideally, this would be done in cooperation with the duck maintainer
> > > to
> > > do the following changes:
> > > - in duck, separate the logic to get URLs from sources, from the
> > > logic
> > >   to check those URLs (for example, allow dumping a list of URLs, and
> > >   also using a list of URLs as source)
> > > - in duck, provide machine-readable outputs (JSON?)
> > 
> > Currently duck has two features which can help us:
> > 
> > - The `-n` switch, which gets all URLs and prints them to stdout
> > - The `-l filename` switch, which takes a file with one URL per line
> > and checks them
> > 
> > Theoretically, what's missing in only a `--json` switch, which would
> > change the output from console/text to JSON.
> > 
> > But, as I see it, the `-l` argument is limited in two aspects:
> > 
> > - It provides only the URL, loosing the checker type which is used to
> > select what kind of validation will be performed.
> > 
> >   For instance, a https://salsa.debian.org/rfrancoise/tmux.git of type
> > VCS-Git would be tested as a standard URL in the `-l` context, instead
> > of a git repository.
> > 
> > - It requires a file
> > 
> > I'm thinking of implementing a new JSON specific input format
> > (`--input-json`?), including the two information, which would read from
> > stdout instead of a file.
> > 
> > The format would be as simple as:
> > 
> > ```json
> > [
> >    {"type": "VCS-Git",
> >     "url": "https://salsa.debian.org/rfrancoise/tmux.git";,
> >     "filename": "debian/control",  # optional key
> >     "line_number": 10},    # optional key
> >    ...
> > ]
> > ```
> > 
> > Following this logic, the output format for checking URLs would be the
> > same, as to have `duck --json -n | duck --input-json` working.
> > 
> > The JSON result would hold an additional dictionary for each URL
> > entries
> > named "result", described as follows:
> > 
> > ```json
> > [
> >    {"type": "VCS-Git",
> >     "url": "https://salsa.debian.org/rfrancoise/tmux.git";,
> >     "filename": "debian/control",  # optional key
> >     "line_number": 10, # optional key
> >     "result": {
> >    "state": 0,  # 0 for OK, 1 for Error, 2 for Information
> >    "detail": "Informative message",
> >    "certainty": "possible" # optional key
> >    }},
> >    ...
> > ]
> > ```
> > 
> > Let me know what you think of it.
> 
> That would be perfect!
> 
> In the context of UDD, I will probably implement that as two tables:
> - one to store the mapping between source packages and urls
>   (source, version, url, type, filename, line_number)
>   which would be updated when a new source version gets uploaded
> - one to store the status of urls
>   (url, type, result, timestamp of last check)
>   which would be updated with a retry policy to be defined
> 
> I would not use (filename, line_number) in the input of the URL
> testing part.
> The reason for that design is that it will easily allow to gather the
> status for several versions of the package (testing + unstable +
> experimental for example), while not duplicating the checks for URLs.

Hi Baptiste,

Just checking: did you make progress on this?

Lucas

Bug#1031062: rclone: FTBFS randomly (autobuilder hangs)

[Santiago Vila]

Hello.

I've checked and this seems to be enough to reproduce the hang on any system:

taskset -c 0 dpkg-buildpackage -uc -us -b

My proposal to fix the FTBFS bug, since the exit status for
dh_auto_test is already ignored, would be not to run the tests
at all on systems on which we know the build hangs.

The attached patch would do that.

Please tell me what do you think about this, as I'd like to see
the FTBFS bug eventually fixed in stable.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,8 @@ export DH_GOLANG_INSTALL_EXTRA := \
 
 export BUILDTESTDIR=$(CURDIR)/buildtest
 
+NUM_CPUS := $(shell nproc)
+
 # some arches need more than 10 min to run TestTestsToRegexpLive
 ARCHES_SLOW_TEST := mips64el mipsel
 ifneq ($(findstring $(DEB_BUILD_ARCH),$(ARCHES_SLOW_TEST)),)
@@ -51,8 +53,11 @@ override_dh_auto_clean:
 # build-time tests for github.com/ncw/rclone/vfs access the config file
 # so provide a null config
 override_dh_auto_test:
-   -export RCLONE_CONFIG="/notfound"; \
-   dh_auto_test -- $(EXTRA_TESTFLAGS)
+ifeq ($(NUM_CPUS),1)
+   @echo "Skipping dh_auto_test, known to hang autobuilder when there is 
only one CPU."
+else
+   -export RCLONE_CONFIG="/notfound"; dh_auto_test -- $(EXTRA_TESTFLAGS)
+endif
 
 override_dh_fixperms:
dh_fixperms

Bug#1054552: glibc: stat fails when access time is bogus

[Jarek Czekalski]

Package: libglib2.0-0:i386
Severity: normal
X-Debbugs-Cc: jarekc...@poczta.onet.pl

Dear Maintainer,

*** Reporter, please consider answering these questions, where 
appropriate ***


   * What led up to the situation?
I tried to upgrade system (apt-get upgrade), but it failed in dpkg:

Unpacking initscripts (3.06-4) over (2.96-7+deb11u1) ...
dpkg: error processing archive 
/var/cache/apt/archives/initscripts_3.06-4_all.deb (--unpack):
 unable to stat './var/log' (which was about to be installed): Value 
too large for defined data type


stat /var/log

  File: /var/log
  Size: 4096    Blocks: 8  IO Block: 4096 directory
Device: 8,1 Inode: 2752691 Links: 12
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/ root)
Access: 2040-05-10 23:31:40.285032309 +0200
Modify: 2023-10-25 16:03:42.313742411 +0200
Change: 2023-10-25 16:03:42.313742411 +0200
 Birth: 2017-02-27 09:46:56.739719147 +0100

This date (2040) causes dpkg to fail. The workaround is correcting it by 
touch /var/log.


Running system with bogus date (2040).
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
touch /var/log
   * What was the outcome of this action?
dpkg started working
   * What outcome did you expect instead?
dpkg should work with strange date or give a better message. Maybe just 
documentation (for stat) should be fixed and suggest problems with dates.


Current outcome is as follows: apt-get suddenly fails with a cryptic 
message (initially it was "unable to stat '.'" instead of /var/log). It 
may be extremely difficult to diagnose the issue.


*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: i386 (i686)

Kernel: Linux 5.10.0-20-686-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1051298: RFS: kildclient/3.2.1-1 -- powerful MUD client with a built-in Perl interpreter

[Eduardo M KALINOWSKI]

Control: tags -1 - moreinfo

On 25/10/2023 15:39, Bastian Germann wrote:

Am 25.10.23 um 19:24 schrieb Eduardo M KALINOWSKI:
All that being said, while the next version of the upstream tarball 
will probably not include the kildclient.gresource.c file, I'd rather 
not release an upstream version just for that. So for the moment, I 
intend to fix the packaging to rm this file so that it's regenerated 
from the sources. Would this be acceptable, Bastian?


Yes.


I've uploaded a new version to mentors with this change. I've also 
simplified the regeneration of the html docs. Let me know if you spot 
any further changes to be made.


--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Bug#1054551: scilab: Xcos palette browser does not open: Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: org/apache/lucene/store/Directory

[Amr Ibrahim]

Package: scilab
Version: 6.1.1+dfsg2-9
Severity: normal

Dear Maintainer,

Xcos palette browser does not open.

Steps:

1. Start Xcos in a terminal
2. View → Palette Browser


Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError:
org/apache/lucene/store/Directory
at
org.scilab.modules.xcos.palette.view.PaletteManagerView.(Unknown Source)
at
org.scilab.modules.xcos.palette.view.PaletteManagerView.restore(Unknown Source)
at org.scilab.modules.xcos.Xcos$XcosTabFactory.getTab(Unknown Source)
at org.scilab.modules.gui.tabfactory.ScilabTabFactory.getTab(Unknown
Source)
at
org.scilab.modules.gui.utils.WindowsConfigurationManager.createDescendantTabs(Unknown
Source)
at
org.scilab.modules.gui.utils.WindowsConfigurationManager.startRestoration(Unknown
Source)
at
org.scilab.modules.gui.utils.WindowsConfigurationManager.restoreUUID(Unknown
Source)
at org.scilab.modules.xcos.palette.PaletteManager.setVisible(Unknown
Source)
at
org.scilab.modules.xcos.palette.actions.ViewPaletteBrowserAction.actionPerformed(Unknown
Source)
at
java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1972)
at
java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2313)
at
java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
at
java.desktop/javax.swing.JToggleButton$ToggleButtonModel.setPressed(JToggleButton.java:411)
at
java.desktop/javax.swing.AbstractButton.doClick(AbstractButton.java:374)
at
java.desktop/javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1028)
at
java.desktop/javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1072)
at
java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
at
java.desktop/java.awt.Component.processMouseEvent(Component.java:6626)
at
java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3389)
at java.desktop/java.awt.Component.processEvent(Component.java:6391)
at java.desktop/java.awt.Container.processEvent(Container.java:2266)
at
java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5001)
at
java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2324)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4833)
at
java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4948)
at
java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4575)
at
java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4516)
at
java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2310)
at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2780)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4833)
at
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:775)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:97)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:747)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:744)
at
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at
java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Caused by: java.lang.ClassNotFoundException: org.apache.lucene.store.Directory
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)


Best,
Amr


-- System Information:
Debian Release: trixie/

Bug#1054419: RFS: go-mode.el/3:1.6.0+git202300823.8dce1e3-1 [RC] [Team] -- Emacs mode for editing Go code

[Xiyue Deng]

Xiyue Deng  writes:

> Package: sponsorship-requests
> Severity: important
> X-Debbugs-CC: debian-emac...@lists.debian.org
>
> Dear mentors,
>
> I am looking for a sponsor for my package "go-mode.el":
>
>  * Package name : go-mode.el
>Version  : 3:1.6.0+git202300823.8dce1e3-1
>Upstream contact : Dominik Honnef 
>  * URL  : https://github.com/dominikh/go-mode.el
>  * License  : BSD-3-clasue
>  * Vcs  : https://salsa.debian.org/emacsen-team/go-mode.el
>Section  : lisp
>
> The source builds the following binary packages:
>
>   elpa-go-mode - Emacs mode for editing Go code
>
> To access further information about this package, please visit the following 
> URL:
>
>   https://mentors.debian.net/package/go-mode.el/
>
> Alternatively, you can download the package with 'dget' using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/g/go-mode.el/go-mode.el_1.6.0+git202300823.8dce1e3-1.dsc
>
> Changes since the last upload:
>
>  go-mode.el (3:1.6.0+git202300823.8dce1e3-1) unstable; urgency=medium
>  .
>* Team upload.
>* Sync to latest upstream head (8dce1e3).
>* Apply patch to drop duplicated test (Closes: #1052922).
>* Drop Built-Using which should not be used on an "arch:all" package.
>* Add DEP5 headers for fix-test-path.patch.
>* Update year and add Upstream-Contact in d/copyright.
>* Use git mode and fix lintian warnings in d/watch.
>
> Regards,

The previous uploads had a typo in the version number.  This has been
fixed in the latest upload.

-- 
Xiyue Deng

Bug#1054550: RM: libauthen-sasl-cyrus-perl -- ROM; obsolete, RC-buggy, superceded

[gregor herrmann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: libauthen-sasl-cyrus-p...@packages.debian.org, 
debian-p...@lists.debian.org
Control: affects -1 + src:libauthen-sasl-cyrus-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please remove libauthen-sasl-cyrus-perl from the archive.

It's long obsolete, broken with the upload of libauthen-sasl-perl 2.1700-1
(cf. #1052871), and I'm about to upload its replacement
libauthen-sasl-xs-perl.

Cheers,
gregor



-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmU5Y75fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgY/LRAAgC5WZb/4C/xusIJqig5tJyGfLE0UWMwo7ZQp9v/PmYuRTjbkF5UMo7TE
L9uWyzxaKAmoCFZCMrKdrgYP4btlNNWrQEU9ew879DaUdA9pX6t2yHInr848foLG
2reTkANG+9IE1dgmgaFFMu+b7NGIgWPD626IqSrqdh/EMFbHpctGz12zXt5WfQNr
S27ZVU1xpfmOCqKoKQoKqj4rJKVuLRl8YP38uoFyDB89QZNFaJdwsj7QuA9wEuZr
iK4GS0jxoSwijhzggv4jMp0j84VRclSUm5r80fP0okwCPf7VRbYhHf4KsdezzM+v
+xTaNb+EAJVNrCj0GEdLLEbAyfEQujOQeqUkwF1duLDJEXg8L+zuYxXYsybJjORz
uT5yXvoeV3m2OeKXrxnTJ4nVXfefbUCJWpvnmM0jZIpg1PGFC/7i30TLLRCj5Tn4
uOETO9/OA8EwulDRlcnh6q/lYfYr41a0qewzz5DD/pWj8rP2roONAEpDJ0nqh0VO
8QrHMueeGWydM2V757Q7bHyi0TTvC9IeT+DZ6WwXTWIIvj8ZgO75jquu0PDLQXD6
qCy2gA2G74+09mGHxPPP9KSoNrIdzSH99+6ZFqR+vP86Kc1eJ2+A7Mztxy6y+kyz
gKemhRw1Vcr/yb5S8FpJgUOAgudo8GG2ZCjPGu6CdQai0KbRbV8=
=ms3D
-END PGP SIGNATURE-

Bug#1054549: cmus: Segmentation fault when trying to open directory with 444 permission mask

[Krzysztof Aleksander Pyrkosz]

Package: cmus
Severity: normal

Dear Maintainer,

I've encountered a reporoducible segfault. When trying to enter a directory 
with 444 permissions owned by root
(lanuch cmus, press "5" to switch to directory selection, and select this
directory) the program segfaults.

Bug#1051298: RFS: kildclient/3.2.1-1 -- powerful MUD client with a built-in Perl interpreter

[Bastian Germann]

Am 25.10.23 um 19:24 schrieb Eduardo M KALINOWSKI:
All that being said, while the next version of the upstream tarball will probably not include the kildclient.gresource.c 
file, I'd rather not release an upstream version just for that. So for the moment, I intend to fix the packaging to rm 
this file so that it's regenerated from the sources. Would this be acceptable, Bastian?


Yes.

Bug#1054548: ITP: libauthen-sasl-xs-perl -- Perl XS extension to glue Perl SASL to Cyrus SASL

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libauthen-sasl-xs-perl
  Version : 1.00
  Upstream Author : Graham Barr 
* URL : https://metacpan.org/release/Authen-SASL-XS
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl XS extension to glue Perl SASL to Cyrus SASL

SASL is a generic mechanism for authentication used by several network
protocols. Authen::SASL::XS provides an implementation framework that all
protocols should be able to share.

The XS framework makes calls into the existing libsasl.so resp. libsasl2
shared library to perform SASL client connection functionality, including
loading existing shared library mechanisms.

libauthen-sasl-xs-perl is the successor of libauthen-sasl-cyrus-perl.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#1053281: issue fixed

[Kazimierz Uromski]

Hi,
In most recent kernel [linux-image-6.5.0-3-amd64 (6.5.8-1)] the issue no 
longer occurs.


Thanks
Kazimierz Uromski

Bug#967764: sylpheed: depends on deprecated GTK 2

[Bastian Germann]

With claws-mail, there is a sylpheed fork available in Debian that has the 
porting to GTK 3 done.
sylpheed upstream development seems to have stalled.
Please consider to have a good migration story for users and get rid of 
sylpheed for trixie.

Bug#1051837: dh-python: Cannot exclude deliberately embedded .egg-info from the clean step

[Stefano Rivera]

Hi Simon (2023.09.13_11:53:34_+0200)

I think I've fixed the majority of the fallout from cleaning egg-info in
https://salsa.debian.org/python-team/tools/dh-python/-/commit/7970b4d559da66858f0ae7a25e03aef40013c5da

This particular case is harder, because we need to have a cleaning
blocklist and pass it through to the build module. I'll come back to
this one, later.

Stefano

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

Bug#1015871: Enabling PCI_P2PDMA for distro kernels?

[Logan Gunthorpe]

On 2023-10-25 11:35, Bjorn Helgaas wrote:
> On Wed, Oct 25, 2023 at 07:11:26PM +0200, Lukas Wunner wrote:
>> On Wed, Oct 25, 2023 at 10:30:07AM -0600, Logan Gunthorpe wrote:
>>> In addition to the above, P2PDMA transfers are only allowed by the
>>> kernel for traffic that flows through certain host bridges that are
>>> known to work. For AMD, all modern CPUs are on this list, but for Intel,
>>> the list is very patchy.
>>
>> This has recently been brought up internally at Intel and nobody could
>> understand why there's a whitelist in the first place.  A long-time PCI
>> architect told me that Intel silicon validation has been testing P2PDMA
>> at least since the Lindenhurst days, i.e. since 2005.
>>
>> What's the reason for the whitelist?  Was there Intel hardware which
>> didn't support it or turned out to be broken?
>>
>> I imagine (but am not certain) that the feature might only be enabled
>> for server SKUs, is that the reason?
> 
> No, the reason is that the PCIe spec doesn't require routing of
> peer-to-peer transactions between Root Ports:
> https://git.kernel.org/linus/0f97da831026
> 
> I think there was a little discussion about adding a firmware
> interface to advertise this capability, but I guess nobody cared
> enough to advance it.

Yes, I remember someone advancing that in the PCI spec, but I don't know
that it got anywhere.

I definitely remember also testing Intel hardware several years ago
where P2PDMA "worked" but the performance was so awful there was no point.

I vaguely remember this not working on non-server machines in the past
(circa 2015). That's why we had to buy a Xeon. Though this was a long
time ago and my memory is fuzzy.

I'd love it if someone from Intel can give us a reasonable check on the
CPU that guarantees P2PDMA will work for everything that passes the
check (like AMD has done.) But in the absence of Intel telling us this
we can't easily make these assumptions.

Logan

Bug#1015871: Enabling PCI_P2PDMA for distro kernels?

[Deucher, Alexander]

[Public]

> -Original Message-
> From: Logan Gunthorpe 
> Sent: Wednesday, October 25, 2023 12:30 PM
> To: Uwe Kleine-König ; Bjorn Helgaas
> 
> Cc: Simon Richter ; 1015...@bugs.debian.org; linux-
> p...@vger.kernel.org; Deucher, Alexander ;
> Krzysztof Wilczyński ; Emanuele Rocca 
> Subject: Re: Enabling PCI_P2PDMA for distro kernels?
>
>
>
> On 2023-10-25 00:19, Uwe Kleine-König wrote:
> > Hello,
> >
> > in https://bugs.debian.org/1015871 the Debian kernel team got a
> > request to enable PCI_P2PDMA. Given the description of the feature and
> > also the "If unsure, say N." I wonder if you consider it safe to
> > enable this option.
>
> I don't know. Not being a security expert, I'd say the attack surface exposed 
> is
> fairly minimal. Most of what goes on is internal to the kernel. So the main 
> risk
> is the same rough risk that goes with enabling any feature: there may be bugs.
>
> My opinion is that 'No' is recommended because the feature is still very
> nascent and advanced. Right now it enables two user visible niche
> features: p2p transfers in nvme-target between an NVMe device and an
> RDMA NIC and transferring buffers between two NVMe devices through the
> CMB via O_DIRECT. Both uses require an NVMe device with CMB memory,
> which is rare.
>
> Anyone using this option to do GPU P2PDMA transfers are certainly using out
> of tree (and likely proprietary) modules as the upstream kernel does not yet
> appear to support anything like that at this time. Thus it's not clear how 
> such
> code is using the P2PDMA subsystem or what implications there may be.
>

AMD GPUs can use P2PDMA for resource sharing between GPUs using upstream 
kernels and mesa and also ROCm.  E.g., if you have multiple GPUs in a system 
you can render on one and display on the other without an extra trip through 
system memory.  This is common on laptops and desktops with multiple GPUs.  
Enabling P2PDMA provides a nice perf boost on these systems due to reduced 
copies.  Or with ROCm, GPUs can directly access local memory on other GPUs.  
It's also possible between at least AMD GPUs and some RDMA NICs.  There are 
also a lot of use cases for P2PDMA between devices and NVME devices, but due to 
differences in memory sharing APIs there is no simple path to move forward 
here.  I think it's something is a chicken and an egg problem for wider 
adoption.


> It's not commonly the case that using these features increases throughput as
> CMB memory is usually much slower than system memory. It's use makes
> more sense in smaller/cheaper boutique systems where the system memory
> or bus bandwidth to the CPU is limited. Typically with a PCIe switch involved.
>
> In addition to the above, P2PDMA transfers are only allowed by the kernel for
> traffic that flows through certain host bridges that are known to work. For
> AMD, all modern CPUs are on this list, but for Intel, the list is very patchy.
> When using a PCIe switch (also uncommon) this restriction is not present
> seeing the traffic can avoid the host bridge.

The older pre-Zen AMD CPUs support it too, but only for writes.

Alex

>
> Thus, my contention is anyone experimenting with this stuff ought to be
> capable of installing a custom kernel with the feature enabled.
>
> Logan

Bug#851725: rclone: FTBFS randomly (failing tests)

[Santiago Vila]

Version: 1.53.3-1

Hello.

I'm closing this bug with the version in bullseye because the
random FTBFS failures I experienced at the time do not happen
anymore in bullseye.

Unfortunately, there is now a different FTBFS problem
in bookworm and trixie which I still would like to address:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031062

I've recently become member of this team, so if anybody
finds a good fix for this problem, I will gladly take care
of the bureaucratic work that derives from it (doing git
commits, making uploads, backporting to proposed-updates,
asking release managers to accept in stable, etc).

Thanks.

Bug#1051298: RFS: kildclient/3.2.1-1 -- powerful MUD client with a built-in Perl interpreter

[Eduardo M KALINOWSKI]

On 25/10/2023 01:10, Paul Wise wrote:

On Tue, 2023-10-24 at 17:57 -0300, Eduardo M KALINOWSKI wrote:


Isn't it a bit extreme to repack the source because of a file that is
automatically generated, but is still distributable?


Indeed, it isn't necessary to repack source to remove generated files.

https://wiki.debian.org/AutoGeneratedFiles

The best option is to send upstream a patch removing the file from
their VCS and tarballs so that it is always built from source.


I am also the upstream. In the case of this file 
(kildclient.gresource.c) I agree that it can be removed from the 
upstream tarball. Even though an extra tool is required to generate the 
file, if someone that is building from source has the glib development 
package (which is a requirement), they're likely to have the necessary tool.


As I mentioned, the tarball also has automatically generated html files 
for the manual (and the xml source). Bastian did not raise an issue 
about these files, but those I think should not be removed from the 
upstream tarball, because rebuilding them requires a whole other set of 
tools (docbook and a xlst processor), and this seems like an unnecessary 
complication for an end user that is building from source.


But the packages files are ignored, and they're rebuilt from the source 
when the package is built.


All that being said, while the next version of the upstream tarball will 
probably not include the kildclient.gresource.c file, I'd rather not 
release an upstream version just for that. So for the moment, I intend 
to fix the packaging to rm this file so that it's regenerated from the 
sources. Would this be acceptable, Bastian?


(And when there's a new upstream release, I can remove this special 
treatment of the file.)



--
It's lucky you're going so slowly, because you're going in the wrong 
direction.


Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Bug#1015871: Enabling PCI_P2PDMA for distro kernels?

[Bjorn Helgaas]

On Wed, Oct 25, 2023 at 07:11:26PM +0200, Lukas Wunner wrote:
> On Wed, Oct 25, 2023 at 10:30:07AM -0600, Logan Gunthorpe wrote:
> > In addition to the above, P2PDMA transfers are only allowed by the
> > kernel for traffic that flows through certain host bridges that are
> > known to work. For AMD, all modern CPUs are on this list, but for Intel,
> > the list is very patchy.
> 
> This has recently been brought up internally at Intel and nobody could
> understand why there's a whitelist in the first place.  A long-time PCI
> architect told me that Intel silicon validation has been testing P2PDMA
> at least since the Lindenhurst days, i.e. since 2005.
> 
> What's the reason for the whitelist?  Was there Intel hardware which
> didn't support it or turned out to be broken?
> 
> I imagine (but am not certain) that the feature might only be enabled
> for server SKUs, is that the reason?

No, the reason is that the PCIe spec doesn't require routing of
peer-to-peer transactions between Root Ports:
https://git.kernel.org/linus/0f97da831026

I think there was a little discussion about adding a firmware
interface to advertise this capability, but I guess nobody cared
enough to advance it.

Bjorn

Bug#1054547: apitrace diff script needs Python 3.8, but 3.9 is installed

[Nils Dagsson Moskopp]

Package: apitrace
Version: 9.0+repack-1+b3
Severity: normal
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

I wanted to see the help text for the apitrace “--diff-state” option:

; apitrace --diff-state --help
error: failed to execute: /usr/bin/python3.8 
/usr/bin/../lib/apitrace/scripts/jsondiff.py --help

I expected to see some help text, not an error.

My python version is 3.9.2, reported by “python --version”.
Using Python 3.9 to execute the script shows the help text:

; python3.9 /usr/bin/../lib/apitrace/scripts/jsondiff.py --hel
Usage: 
jsondiff.py [options]  

Options:
  -h, --help  show this help message and exit
  --ignore-added  ignore added state
  --keep-images   compare images


-- System Information:
Debian Release: 11.7
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-10-686 (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apitrace depends on:
ii  apitrace-tracers  9.0+repack-1+b3
ii  libbsd0   0.11.3-1
ii  libc6 2.31-13+deb11u6
ii  libgcc-s1 10.2.1-6
ii  libpng16-16   1.6.37-3
ii  libprocps82:3.3.17-5
ii  libsnappy1v5  1.1.8-1
ii  libstdc++610.2.1-6
ii  libwaffle-1-0 1.6.3-3
ii  libx11-6  2:1.7.2-1
ii  python3   3.9.2-3
ii  python3-pil   8.1.2+dfsg-0.3+deb11u1
ii  zlib1g1:1.2.11.dfsg-2+deb11u2

apitrace recommends no packages.

apitrace suggests no packages.

-- no debconf information

Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol

[Xiyue Deng]

Hi Bo,

Bo YU  writes:

> Hi!
>
> On Wed, Oct 25, 2023 at 5:06 PM Arto Jantunen  wrote:
>>
>> Xiyue Deng  writes:
>>
>> > Arto Jantunen  writes:
>> >
>> >> Xiyue Deng  writes:
>> >>
>> >>> Hi Arto,
>> >>>
>> >>> Arto Jantunen  writes:
>> >>>
>>  Xiyue Deng  writes:
>> > Package: sponsorship-requests
>> > Severity: important
>> > X-Debbugs-CC: debian-emac...@lists.debian.org
>> >
>> > Dear mentors,
>> >
>> > I am looking for a sponsor for my package "lsp-mode":
>> >
>> >  * Package name : lsp-mode
>> >Version  : 8.0.0-6
>> >Upstream contact : Vibhav Pant 
>> >  * URL  : https://github.com/emacs-lsp/lsp-mode
>> >  * License  : GPL-3+
>> >  * Vcs  : https://salsa.debian.org/emacsen-team/lsp-mode
>> >Section  : lisp
>> >
>> > The source builds the following binary packages:
>> >
>> >   elpa-lsp-mode - Emacs client/library for the Language Server Protocol
>> >
>> > To access further information about this package, please visit the 
>> > following URL:
>> >
>> >   https://mentors.debian.net/package/lsp-mode/
>> >
>> > Alternatively, you can download the package with 'dget' using this 
>> > command:
>> >
>> >   dget -x 
>> > https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>> >
>> > Changes since the last upload:
>> >
>> >  lsp-mode (8.0.0-6) unstable; urgency=medium
>> >  .
>> >* Add patch to fix test failures (Closes: #1052939).
>> >* Update Standards-Version to 4.6.2.  No change needed.
>> >* Add myself as uploader (Closes: #1042568).
>> >* Add signing key verification to d/watch.
>> >* Add d/upstream/metadata.
>> >* Add Upstream-Contact and update year in d/copyright.
>> >* Add patch to fix non-UTF-8 encoding.
>> >* Drop unused lintian overrides.
>> 
>>  Thanks for taking over this package.
>> 
>>  When I try to build this (under sbuild) I get the following build
>>  failure:
>> 
>>  Test ‘lsp-text-document-hover-request’ redefined
>> 
>>  Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
>>    mapbacktrace(#f(compiled-function (evald func args flags) #>  -0x187de6214517952>))
>>    debug-early-backtrace()
>>    debug-early(error (error "Test ‘lsp-text-document-hover-request’ 
>>  redefined"))
>>    error("Test `%s' redefined" lsp-text-document-hover-request)
>>    ert-set-test(lsp-text-document-hover-request #s(ert-test :name
>>  lsp-text-document-hover-request :documentation nil :body (closure (t) 
>>  nil
>>  (lsp-workspace-folders-add (f-join lsp-test-location "fixtures")) 
>>  (find-file
>>  (f-join lsp-test-location "fixtures/pyls/test.py")) (lsp) 
>>  (deferred:sync!
>>  (deferred:nextc (deferred:nextc (lsp-test--wait-for '(progn (eq 
>>  'initialized
>>  (lsp--workspace-status (cl-first (lsp-workspaces)) #'(lambda (_) 
>>  (goto-char
>>  (point-min)) (search-forward "fn1") (lsp-def-request-async 
>>  "textDocument/hover"
>>  (lsp--text-document-position-params #'(lambda (contents) (let* 
>>  ((fn-566
>>  #'lsp-hover?) (args-567 (condition-case err (let ((signal-hook-function
>>  #'ert--should-signal-hook)) (list contents)) (error (progn (setq fn-566
>>  #'signal) (list (car err) (cdr err))) (let ((value-568
>>  'ert-form-evaluation-aborted-569)) (let (form-description-570) (if
>>  (unwind-protect (setq value-568 (apply fn-566 args-567)) (setq
>>  form-description-570 (nconc (list '(should (lsp-hover? contents))) 
>>  (list :form
>>  (cons fn-566 args-567)) (if (eql value-568 
>>  'ert-form-evaluation-aborted-569) nil
>>  (list :value value-568)) (if (eql value-568 
>>  'ert-form-evaluation-aborted-569)
>>  nil (let* ((-explainer- (and t (ert--get-explainer 'lsp-hover? (if
>>  -explainer- (list :explanation (apply -explainer- args-567)) nil)
>>  (ert--signal-should-execution form-description-570)) nil (ert-fail
>>  form-description-570))) value-568) (kill-buffer)
>>  (lsp-workspace-folders-remove (f-join lsp-test-location "fixtures")))
>>  :most-recent-result nil :expected-result-type :passed :tags nil 
>>  :file-name
>>  "/<>/test/lsp-integration-test.el"))
>>    
>>  load-with-code-conversion("/<>/test/lsp-integration-test.el"
>>   "/<>/test/lsp-integration-test.el" nil t)
>>    command-line-1(("-l" "package" "--eval" "(add-to-list 
>>  'package-directory-list
>>  \"/usr/share/emacs/site-lisp/elpa\")" "--eval" "(add-to-list
>>  'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" "-f"
>>  "package-initialize" "-L" "clients/" "-L" "." "-L" "test" "-l"
>>  "test/lsp-clangd-test.el" "-l" "test/lsp-completion-test.el" "-l"
>>  

Bug#1054368: debhelper: Does not support double build (possible violation of Policy 4.9)

[Helge Kreutzmann]

Hello Niels,
thanks for your reply.

Am Wed, Oct 25, 2023 at 03:32:47PM +0200 schrieb Niels Thykier:
> Control: tags -1 wontfix
> 
> Helge Kreutzmann:
> > Package: debhelper
> > Version: 13.11.4
> > Severity: minor
> > User: debian...@lists.debian.org
> > Usertags: qa-doublebuild
> > 
> > [...]
> > 
> > I first checked (my) upstream build system. Except for one stamp file
> > (which is *much* less than done by debhelper) the build is idempotent,
> > i.e.:
> > 
> > ./configure && make && make clean
> > 
> > returns the sources into the state as shipped.
> > 
> > [...]
> > 
> > dh seems to delete quite a few files shipped in the package.
> > 
> 
> Deleting files shipped in the package is a non-issue (dpkg ignores that with
> a warning).

Ok, so then #1047898 is "just" about the gmo files.

> > For me, this is a clear bug in dh, as linuxinfo just uses it plain and
> > there is no "manipulation" of build files happening (on purpose).
> > 
> 
> The root cause seems to be that the upstream tarball contains binary ".gmo"
> files that will be regenerated when you build with dh and are not
> reset/deleted when you clean.

Thanks. Then I check how to deal with them (possibly upstream).

> Most likely this is a consequence of dh_autoreconf (which is not debhelper
> but a separate package that debhelper depends on) or `dh_auto_clean` using
> `make distclean` rather than `make clean` (as you tested with).

Thanks for your pointer.

> > I checked dh_clean(1) and dh(1), but could not find any mention of how
> > to modify this (which I would not have expected anyhow).
> > 
> 
> Both `dh_clean` and `dh` are red herrings in this case.

Well, I'm trying to find the root cause, and as stated I just use
plain dh, so I don't know where I should have looked at. Maybe you
could introduce a pointer to better / correct documentation then?

> > If the severity of 1047898 is changed, then I will change this one (as
> > it is the root cause). In linuxinfo I probably could work around this,
> > by backing up all affected files before clean and restoring them after
> > clean (using an override). But this is a band aid, not a solution.
> > 
> 
> From my point of view, running an upstream build system is running arbitrary
> code. There is no way debhelper can reliably detect and manage all possible
> variations of upstreams and how they implement "./configure" vs. whether
> they include binary .gmo files in their source tarball that may or may not
> be regenerated during build and how they structure their source code
> internally.

This is a plain autconf system. When I took it over (as upstream), I
tried to keep as close to the (info) documentation as possible on any
extension.

Though, I admit, that I only "understand" a small part of it.

>   As a consequence, it is my view that the root cause is not solely
> debhelper and that you will have to work around this in your package
> somehow. This could be by:
> 
>   * Disabling dh features that cause this problem, OR by

Which I don't know, but 

>   * Telling dh_clean to purge the `*.gmo` files
> (`echo 'po/*.gmo' > debian/clean` should do), OR by

Thanks, this is a good hint!

>   * Repacking the upstream tarball to not include the binary files being
> mutated in the first place.

As I'm upstream as well, I can update the upstream system to do this.

> As the maintainer of debhelper, this is my principle stance on this matter.
> If you disagree, you are welcome to either:
> 
>  * provide a "small non-intrusive" patch that solves your problem
>without causing a significant number of regressions. Onus is on
>you (whoever providing the patch) to research alternatives, and, if
>the patch is controversial/likely to break other packages, provide
>archive-wide test results and as necessary show project wide
>consensus on debian-devel, OR

Sorry, I'm not a "real" programmer. I just respond to #1047898 where I
was informed that an RC bug might come in. I'm currently just learning
where the problem is and I have no idae of the inner working of dh.

>  * raise this issue to the tech-ctte according to constitution 6.1.1
>(AFAICT). However, if you do put this before the tech-ctte, be
>advised that they cannot do detailed design work (constitution
>6.3.5). This means for them to make a decision someone else has to
>come up with a practical technical solution that they can vote in
>over the status quo. And by doing that, that someone might as well
>provide a patch per the first bullet point because the tech-ctte
>will probably have the same questions/requirements as I laid out
>above.

Well, I want to fix #1047898. And until now I (mis)understood that the
best package guidance is to use dh, as it encodes policy. If you say
this is not the case, then I mainly learned that this is not the case.

And again, thanks for the pointers.

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.

Bug#1015871: Enabling PCI_P2PDMA for distro kernels?

[Lukas Wunner]

On Wed, Oct 25, 2023 at 10:30:07AM -0600, Logan Gunthorpe wrote:
> In addition to the above, P2PDMA transfers are only allowed by the
> kernel for traffic that flows through certain host bridges that are
> known to work. For AMD, all modern CPUs are on this list, but for Intel,
> the list is very patchy.

This has recently been brought up internally at Intel and nobody could
understand why there's a whitelist in the first place.  A long-time PCI
architect told me that Intel silicon validation has been testing P2PDMA
at least since the Lindenhurst days, i.e. since 2005.

What's the reason for the whitelist?  Was there Intel hardware which
didn't support it or turned out to be broken?

I imagine (but am not certain) that the feature might only be enabled
for server SKUs, is that the reason?

Thanks,

Lukas

Bug#1002056: Fedora plans to transition to Zlib-ng

[Nelson A. de Oliveira]

JFTR, Fedora is planning to transition to Zlib-ng

https://fedoraproject.org/wiki/Changes/ZlibNGTransition

Best regards,
Nelson

Bug#1054443: node-graphql: website is build with Docusaurus not packaged for debian

[Yadd]

Control: severity -1 wishlist

On 10/23/23 23:21, Bastien Roucariès wrote:

Source:  node-graphql
Version: 16.8.1-1
Severity: serious
Tags: ftbfs
Justification: FTBFS
Control: block -1 by 1054426

Dear Maintainer,

The documentation is build with docusaurus.

See website directory
https://sources.debian.org/src/node-graphql/16.8.1-1/website/src/pages/index.jsx/?hl=2#L2

You should repack or package docusaurus and rebuild

Bastien


No unreadable files here

Bug#1054435: [Pkg-javascript-devel] Bug#1054435: node-react-redux: website is build with Docusaurus not packaged for debian

[Yadd]

Control: severity -1 wishlist

On 10/23/23 23:08, Bastien Roucariès wrote:

Source:  node-react-redux
Version: 8.1.2+dfsg1+~cs1.2.3-1
Severity: serious
Tags: ftbfs
Justification: FTBFS
Control: block -1 by 1054426

Dear Maintainer,

The documentation is build with docusaurus.

See website directory

You should repack or package docusaurus and rebuild

Bastien


No unreadable file here

Bug#1054439: [Pkg-javascript-devel] Bug#1054439: node-rjsf: website is build with Docusaurus not packaged for debian

[Yadd]

Control: severity -1 wishlist

On 10/23/23 23:15, Bastien Roucariès wrote:

Source:  node-rjsf
Version: 5.6.2+~5.0.1-1
Severity: serious
Tags: ftbfs
Justification: FTBFS
Control: block -1 by 1054426

Dear Maintainer,

The documentation is build with docusaurus.

See website directory
https://sources.debian.org/src/node-rjsf/5.6.2+~5.0.1-1/packages/docs/docusaurus.config.js/?hl=54#L54

You should repack or package docusaurus and rebuild

Bastien


No unreadable files here

Bug#1054439: node-rjsf: website is build with Docusaurus not packaged for debian

[Yadd]

Control: severity -1 wishlist

On 10/23/23 23:15, Bastien Roucariès wrote:

Source:  node-rjsf
Version: 5.6.2+~5.0.1-1
Severity: serious
Tags: ftbfs
Justification: FTBFS
Control: block -1 by 1054426

Dear Maintainer,

The documentation is build with docusaurus.

See website directory
https://sources.debian.org/src/node-rjsf/5.6.2+~5.0.1-1/packages/docs/docusaurus.config.js/?hl=54#L54

You should repack or package docusaurus and rebuild

Bastien


No unreadable file here

Bug#1054441: node-ts-jest: website is build with Docusaurus not packaged for debian

[Yadd]

Control: severity -1 wishlist

On 10/23/23 23:18, Bastien Roucariès wrote:

Source:  node-ts-jest
Version: 29.1.1+~cs0.2.6-2
Severity: serious
Tags: ftbfs
Justification: FTBFS
Control: block -1 by 1054426

Dear Maintainer,

The documentation is build with docusaurus.

See website directory
https://sources.debian.org/data/main/n/node-ts-jest/29.1.1%2B~cs0.2.6-2/website/

You should repack or package docusaurus and rebuild

Bastien


No unreadable file here

Bug#947078: git-buildpackage: Need to make gbp clone pseudo protocols confgirable

[Nicolas Boulenguez]

Package: git-buildpackage
Followup-For: Bug #947078

Hello.

Does the solution suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947078
solve your problem?

If so, may we close this bug?

Thanks.

Bug#1015871: Enabling PCI_P2PDMA for distro kernels?

[Logan Gunthorpe]

On 2023-10-25 00:19, Uwe Kleine-König wrote:
> Hello,
> 
> in https://bugs.debian.org/1015871 the Debian kernel team got a request
> to enable PCI_P2PDMA. Given the description of the feature and also the
> "If unsure, say N." I wonder if you consider it safe to enable this
> option.

I don't know. Not being a security expert, I'd say the attack surface
exposed is fairly minimal. Most of what goes on is internal to the
kernel. So the main risk is the same rough risk that goes with enabling
any feature: there may be bugs.

My opinion is that 'No' is recommended because the feature is still very
nascent and advanced. Right now it enables two user visible niche
features: p2p transfers in nvme-target between an NVMe device and an
RDMA NIC and transferring buffers between two NVMe devices through the
CMB via O_DIRECT. Both uses require an NVMe device with CMB memory,
which is rare.

Anyone using this option to do GPU P2PDMA transfers are certainly using
out of tree (and likely proprietary) modules as the upstream kernel does
not yet appear to support anything like that at this time. Thus it's not
clear how such code is using the P2PDMA subsystem or what implications
there may be.

It's not commonly the case that using these features increases
throughput as CMB memory is usually much slower than system memory. It's
use makes more sense in smaller/cheaper boutique systems where the
system memory or bus bandwidth to the CPU is limited. Typically with a
PCIe switch involved.

In addition to the above, P2PDMA transfers are only allowed by the
kernel for traffic that flows through certain host bridges that are
known to work. For AMD, all modern CPUs are on this list, but for Intel,
the list is very patchy. When using a PCIe switch (also uncommon) this
restriction is not present seeing the traffic can avoid the host bridge.

Thus, my contention is anyone experimenting with this stuff ought to be
capable of installing a custom kernel with the feature enabled.

Logan

Bug#1054546: openssl: The engine interface seems to be broken.

[Sebastian Andrzej Siewior]

Package: openssl
Version: 3.0.12-1
Severity: serious
Control: affects -1 + src:libp11
Control: forwarded -1 https://github.com/openssl/openssl/issues/22508

At least for libp11 the engine interface seems to be broken.

Sebastian

Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol

[Xiyue Deng]

Arto Jantunen  writes:

> Xiyue Deng  writes:
>
>> Arto Jantunen  writes:
>>
>>> Xiyue Deng  writes:
>>>
 Hi Arto,

 Arto Jantunen  writes:

> Xiyue Deng  writes:
>> Package: sponsorship-requests
>> Severity: important
>> X-Debbugs-CC: debian-emac...@lists.debian.org
>>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "lsp-mode":
>>
>>  * Package name : lsp-mode
>>Version  : 8.0.0-6
>>Upstream contact : Vibhav Pant 
>>  * URL  : https://github.com/emacs-lsp/lsp-mode
>>  * License  : GPL-3+
>>  * Vcs  : https://salsa.debian.org/emacsen-team/lsp-mode
>>Section  : lisp
>>
>> The source builds the following binary packages:
>>
>>   elpa-lsp-mode - Emacs client/library for the Language Server Protocol
>>
>> To access further information about this package, please visit the 
>> following URL:
>>
>>   https://mentors.debian.net/package/lsp-mode/
>>
>> Alternatively, you can download the package with 'dget' using this 
>> command:
>>
>>   dget -x 
>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>>
>> Changes since the last upload:
>>
>>  lsp-mode (8.0.0-6) unstable; urgency=medium
>>  .
>>* Add patch to fix test failures (Closes: #1052939).
>>* Update Standards-Version to 4.6.2.  No change needed.
>>* Add myself as uploader (Closes: #1042568).
>>* Add signing key verification to d/watch.
>>* Add d/upstream/metadata.
>>* Add Upstream-Contact and update year in d/copyright.
>>* Add patch to fix non-UTF-8 encoding.
>>* Drop unused lintian overrides.
>
> Thanks for taking over this package.
>
> When I try to build this (under sbuild) I get the following build
> failure:
>
> Test ‘lsp-text-document-hover-request’ redefined
>
> Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
>   mapbacktrace(#f(compiled-function (evald func args flags) # -0x187de6214517952>))
>   debug-early-backtrace()
>   debug-early(error (error "Test ‘lsp-text-document-hover-request’ 
> redefined"))
>   error("Test `%s' redefined" lsp-text-document-hover-request)
>   ert-set-test(lsp-text-document-hover-request #s(ert-test :name
> lsp-text-document-hover-request :documentation nil :body (closure (t) nil
> (lsp-workspace-folders-add (f-join lsp-test-location "fixtures")) 
> (find-file
> (f-join lsp-test-location "fixtures/pyls/test.py")) (lsp) (deferred:sync!
> (deferred:nextc (deferred:nextc (lsp-test--wait-for '(progn (eq 
> 'initialized
> (lsp--workspace-status (cl-first (lsp-workspaces)) #'(lambda (_) 
> (goto-char
> (point-min)) (search-forward "fn1") (lsp-def-request-async 
> "textDocument/hover"
> (lsp--text-document-position-params #'(lambda (contents) (let* 
> ((fn-566
> #'lsp-hover?) (args-567 (condition-case err (let ((signal-hook-function
> #'ert--should-signal-hook)) (list contents)) (error (progn (setq fn-566
> #'signal) (list (car err) (cdr err))) (let ((value-568
> 'ert-form-evaluation-aborted-569)) (let (form-description-570) (if
> (unwind-protect (setq value-568 (apply fn-566 args-567)) (setq
> form-description-570 (nconc (list '(should (lsp-hover? contents))) (list 
> :form
> (cons fn-566 args-567)) (if (eql value-568 
> 'ert-form-evaluation-aborted-569) nil
> (list :value value-568)) (if (eql value-568 
> 'ert-form-evaluation-aborted-569)
> nil (let* ((-explainer- (and t (ert--get-explainer 'lsp-hover? (if
> -explainer- (list :explanation (apply -explainer- args-567)) nil)
> (ert--signal-should-execution form-description-570)) nil (ert-fail
> form-description-570))) value-568) (kill-buffer)
> (lsp-workspace-folders-remove (f-join lsp-test-location "fixtures")))
> :most-recent-result nil :expected-result-type :passed :tags nil :file-name
> "/<>/test/lsp-integration-test.el"))
>   
> load-with-code-conversion("/<>/test/lsp-integration-test.el" 
> "/<>/test/lsp-integration-test.el" nil t)
>   command-line-1(("-l" "package" "--eval" "(add-to-list 
> 'package-directory-list
> \"/usr/share/emacs/site-lisp/elpa\")" "--eval" "(add-to-list
> 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" "-f"
> "package-initialize" "-L" "clients/" "-L" "." "-L" "test" "-l"
> "test/lsp-clangd-test.el" "-l" "test/lsp-completion-test.el" "-l"
> "test/lsp-file-watch-test.el" "-l" "test/lsp-integration-test.el" "-l"
> "test/lsp-io-test.el" "-l" "test/lsp-javascript-test.el" "-l"
> "test/lsp-methods-test.el" "-l" "test/lsp-mode-test.el" "-l"
> "test/lsp-protocol-test.el" "-l" "test/lsp-common-test.el" "-l"
> "debian/ert-helper.el"))
>

Bug#1054545: libfuture-xs-perl: Needs to Build-Depends on libdevel-mat-dumper-perl

[Paul "LeoNerd" Evans]

Package: libfuture-xs-perl
Version: 0.10-2
Severity: normal

Future::XS detects at compiletime if Devel::MAT::Dumper is available. If
so, it builds in extra code that is essential for uding the Devel::MAT
memory tracing tools with XS-based Future instances. If that is not
available at build time, it doesn't matter if it's later installed on
the user's machine. It won't work.

Thus, libfuture-xs-perl needs to Build-Depends on
libdevel-mat-dumper-perl.


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

Kernel: Linux 6.4.0-4-amd64 (SMP w/4 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 libfuture-xs-perl depends on:
ii  libc6   2.37-8
ii  libfuture-perl  0.50-1
ii  perl5.36.0-7
ii  perl-base [perlapi-5.36.0]  5.36.0-7

libfuture-xs-perl recommends no packages.

libfuture-xs-perl suggests no packages.

-- no debconf information

Bug#1053353: dacite: please make the build reproducible

[Valentin Vidic]

On Wed, Oct 25, 2023 at 08:00:43AM +0100, Chris Lamb wrote:
> Hm, after fiddling for a few minutes I can't quite work it out. What
> happens when you build it locally?

Locally I also don't see these files being created, so the updated
package has the same contents as version in unstable.

-- 
Valentin

Bug#1054544: community.zabbix plugin misses bookworm support and fails with error dict object' has no attribute 'bookworm'

[Pirate Praveen]

package: anisble
severity: important
version: 7.3.0+dfsg-1

: FAILED! => {"msg": "The task includes an option with an undefined 
variable. The error was: 'dict object' has no attribute 'bookworm'. 
'dict object' has no attribute 'bookworm'\n\nThe error appears to be in 
'/usr/lib/python3/dist-packages/ansible_collections/community/zabbix/roles/zabbix_server/tasks/Debian.yml': 
line 86, column 3, but may\nbe elsewhere in the file depending on the 
exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: 
\"Debian | Install gpg key\"\n  ^ here\n"}


I can see a newer commit adding support

https://github.com/ansible-collections/community.zabbix/commit/9856769381625c7994c33a07b7e27a277f8bea86#diff-c1a1a767b71f8dcff0bb354327aba87b4b1885711f107a2b8ecb58fce7992697

It is kind of a chicken and egg problem to include bookworm support in 
bookworm first release. But I think we can include a patch in a stable 
update.


I managed to fix this by installing with ansible-galaxy (2.1.0) but 
would be nice to fix the packaged version.

Bug#1052831: python-agate: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13

[Santiago Vila]

El 25/10/23 a las 16:22, tony mancill escribió:

I have prepared an NMU to address this test failure; debdiff attached.
Please let me know if you have any concerns about an upload to address
this build failure.


Hi. I've just requested to be in Python team to work on QA issues,
and this would be my ideal first task to work on it (so, I would
do a "Team upload" instead of an NMU).

Thanks.

Bug#1052831: python-agate: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13

[tony mancill]

On Tue, Sep 26, 2023 at 02:44:16PM +0200, Lucas Nussbaum wrote:
> Source: python-agate
> Version: 1.6.3-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230925 ftbfs-trixie

> > Traceback (most recent call last):
> >   File 
> > "/<>/.pybuild/cpython3_3.11_agate/build/tests/test_data_types.py",
> >  line 364, in test_cast_parser_timezone
> > tzinfo = pytz.timezone('US/Pacific')
> >  ^^^
> >   File "/usr/lib/python3/dist-packages/pytz/__init__.py", line 202, in 
> > timezone
> > raise UnknownTimeZoneError(zone)
> > pytz.exceptions.UnknownTimeZoneError: 'US/Pacific'

Hi,

I have prepared an NMU to address this test failure; debdiff attached.
Please let me know if you have any concerns about an upload to address
this build failure.

Thank you,
tony
diff -Nru python-agate-1.6.3/debian/changelog 
python-agate-1.6.3/debian/changelog
--- python-agate-1.6.3/debian/changelog 2022-10-14 03:16:54.0 -0700
+++ python-agate-1.6.3/debian/changelog 2023-10-25 06:41:55.0 -0700
@@ -1,3 +1,10 @@
+python-agate (1.6.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update TZ used in tests for tzdata 2023c-8 (Closes: #1052831)
+
+ -- tony mancill   Wed, 25 Oct 2023 06:41:55 -0700
+
 python-agate (1.6.3-2) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru python-agate-1.6.3/debian/patches/1052831-pytz.patch 
python-agate-1.6.3/debian/patches/1052831-pytz.patch
--- python-agate-1.6.3/debian/patches/1052831-pytz.patch1969-12-31 
16:00:00.0 -0800
+++ python-agate-1.6.3/debian/patches/1052831-pytz.patch2023-10-25 
06:41:55.0 -0700
@@ -0,0 +1,16 @@
+Description: update for tzdata (2023c-8) (see Debian: #1040997)
+Author: tony mancill 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052831
+Forwarded: no
+
+--- a/tests/test_data_types.py
 b/tests/test_data_types.py
+@@ -361,7 +361,7 @@
+ ))
+ 
+ def test_cast_parser_timezone(self):
+-tzinfo = pytz.timezone('US/Pacific')
++tzinfo = pytz.timezone('America/Los_Angeles')
+ datetime_type = DateTime(timezone=tzinfo)
+ 
+ values = ('3/1/1994 12:30 PM', '2/17/2011 06:30', None, 'January 5th, 
1984 22:37', 'n/a')
diff -Nru python-agate-1.6.3/debian/patches/series 
python-agate-1.6.3/debian/patches/series
--- python-agate-1.6.3/debian/patches/series2022-10-14 03:16:54.0 
-0700
+++ python-agate-1.6.3/debian/patches/series2023-10-25 06:41:55.0 
-0700
@@ -1,2 +1,3 @@
 Use-packaged-docs.patch
 No-privacy-breach.patch
+1052831-pytz.patch


signature.asc
Description: PGP signature

Bug#1025420: exim4: ${run}expansion fail Bug stiill open [TT#2568022]

[Andreas Metzler]

On 2023-10-23 SerNet Support Kevin Ivory  wrote:
[...]
> That binary does not fix the problem of quote with space included:

> # /usr/sbin/exim4 -be '${run{/usr/bin/echo ${quote:hello world}}}'
> Failed: Expansion of "${quote:hello" from command "/usr/bin/echo 
> ${quote:hello world}" in ${run} expansion failed: missing } at end of string
[...]

${run expansion changed in 4.96:
"If the option preexpand is not used, the command string is split into
individual arguments by spaces and then each argument is expanded."

i.e.
/usr/bin/echo ${quote:hello world}
is split into
/usr/bin/echo
${quote:hello
world}
and the second string yields an expansion error.
Use
/usr/sbin/exim4 -be '${run,preexpand{/usr/bin/echo ${quote:hello world}}}'
to get the old behavior.

cu Andreas

Bug#1054543: ITP: golang-github-microsoft-go-winio -- Win32 IO-related utilities for Go

[Ramūnas Keliuotis]

Package: wnpp
Severity: wishlist
Owner: Ramunas Keliuotis 

* Package name: golang-github-microsoft-go-winio
  Version : 0.6.1-1
  Upstream Author : Microsoft
* URL : https://github.com/Microsoft/go-winio
* License : Expat
  Programming Lang: Go
  Description : Win32 IO-related utilities for Go



I am not an owner nor a maintainer of this golang library.
This golang package is dependency to my program I am packaging for Debian.
Need to wrap this golang library into a Debian package and upload it to SID.

I am not sure about the golang packaging into Debian, I submitted a
request to get
access to go-team Salsa area. Then I can work with `dh-make-golang` and upload
to salsa. But again - what is the sequence of how to proceed?



Best regards,
Ramunas Keliuotis

-- 
The content of this email, including all attachments, is confidential. If 
you are not the intended recipient of this e-mail, please notify us 
immediately and delete this email. Any disclosure, copying, distribution or 
any other use of its content is strictly prohibited.

Bug#1054541: the problem was apparmor

[John Comeau]

Fixed by:

# ln -s /etc/apparmor.d/usr.sbin.privoxy /etc/apparmor.d/disable/
# apparmor_parser -R /etc/apparmor.d/disable/usr.sbin.privoxy

Sorry for the spurious report. I didn't remember about apparmor, only
noticed it when bugreport pointed it out.
-- 
John Comeau KE5TFZ j...@unternet.net http://jc.unternet.net/
"A place for everything, and everything all over the place"

Bug#1054368: debhelper: Does not support double build (possible violation of Policy 4.9)

[Niels Thykier]

Control: tags -1 wontfix

Helge Kreutzmann:

Package: debhelper
Version: 13.11.4
Severity: minor
User: debian...@lists.debian.org
Usertags: qa-doublebuild

[...]

I first checked (my) upstream build system. Except for one stamp file
(which is *much* less than done by debhelper) the build is idempotent,
i.e.:

./configure && make && make clean

returns the sources into the state as shipped.

[...]

dh seems to delete quite a few files shipped in the package.



Deleting files shipped in the package is a non-issue (dpkg ignores that 
with a warning).



For me, this is a clear bug in dh, as linuxinfo just uses it plain and
there is no "manipulation" of build files happening (on purpose).



The root cause seems to be that the upstream tarball contains binary 
".gmo" files that will be regenerated when you build with dh and are not 
reset/deleted when you clean.


Most likely this is a consequence of dh_autoreconf (which is not 
debhelper but a separate package that debhelper depends on) or 
`dh_auto_clean` using `make distclean` rather than `make clean` (as you 
tested with).



I checked dh_clean(1) and dh(1), but could not find any mention of how
to modify this (which I would not have expected anyhow).



Both `dh_clean` and `dh` are red herrings in this case.


If the severity of 1047898 is changed, then I will change this one (as
it is the root cause). In linuxinfo I probably could work around this,
by backing up all affected files before clean and restoring them after
clean (using an override). But this is a band aid, not a solution.



From my point of view, running an upstream build system is running 
arbitrary code. There is no way debhelper can reliably detect and manage 
all possible variations of upstreams and how they implement 
"./configure" vs. whether they include binary .gmo files in their source 
tarball that may or may not be regenerated during build and how they 
structure their source code internally.
  As a consequence, it is my view that the root cause is not solely 
debhelper and that you will have to work around this in your package 
somehow. This could be by:


  * Disabling dh features that cause this problem, OR by

  * Telling dh_clean to purge the `*.gmo` files
(`echo 'po/*.gmo' > debian/clean` should do), OR by

  * Repacking the upstream tarball to not include the binary files being
mutated in the first place.

As the maintainer of debhelper, this is my principle stance on this 
matter. If you disagree, you are welcome to either:


 * provide a "small non-intrusive" patch that solves your problem
   without causing a significant number of regressions. Onus is on
   you (whoever providing the patch) to research alternatives, and, if
   the patch is controversial/likely to break other packages, provide
   archive-wide test results and as necessary show project wide
   consensus on debian-devel, OR

 * raise this issue to the tech-ctte according to constitution 6.1.1
   (AFAICT). However, if you do put this before the tech-ctte, be
   advised that they cannot do detailed design work (constitution
   6.3.5). This means for them to make a decision someone else has to
   come up with a practical technical solution that they can vote in
   over the status quo. And by doing that, that someone might as well
   provide a patch per the first bullet point because the tech-ctte
   will probably have the same questions/requirements as I laid out
   above.

Best regards,
Niels

Bug#1054542: dqlite FTBFS with raft 0.17.7

[Adrian Bunk]

Source: dqlite
Version: 1.11.1-1
Severity: serious
Tags: ftbfs trixie sid
X-Debbugs-Cc: Free Ekanayaka 

https://buildd.debian.org/status/logs.php?pkg=dqlite&ver=1.11.1-1%2Bb1

...
171 of 186 (92%) tests successful, 4 (2%) test skipped.
FAIL unit-test (exit status: 1)

FAIL: integration-test
==

Running test suite with seed 0xac33d156...
client/exec [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
client/query[ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
cluster/restart 
  num_records=0 [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=1 [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=256   [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=993   [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=2200  [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
cluster/dataOnNewNode   
  num_records=0 [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=1 [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=256   [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=993   [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=2200  [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
fsm/snapshotFreshDb [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
fsm/snapshotWrittenDb   [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
fsm/snapshotHeapFaultSingleDB   [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
fsm/snapshotHeapFaultTwoDB  [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
fsm/snapshotNewDbAddedBeforeFinalize[ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
fsm/snapshotWritesBeforeFinalize[ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
fsm/snapshotRestore 
  num_records=0 [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=1 [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=256   [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=993   [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
  num_records=2200  [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
fsm/concurrentSnapshots [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
fsm/snapshotRestoreMultipleDBs  [ ERROR ]
Error: test/lib/server.c:58: assertion failed: rv == 0 (1 == 0)
Error: child killed by signal 6 (Aborted)
membership/join 

Bug#1054541: privoxy: Using custom configuration fails with EACCES at openat syscall

[John Comeau]

Package: privoxy
Version: 3.0.34-3
Severity: important

Dear Maintainer,

   What led up to the situation?

The final arg for `privoxy` is the path (relative or absolute) of the
configuration file. Specifying anything other than files under
/etc/privoxy fails with "Fatal error: can't open configuration file"

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

`privoxy --no-daemon config` fails
`cp config /tmp; privoxy --no-daemon /tmp/config` fails
The above with `sudo` likewise fails.
`cat config | privoxy --no-daemon /proc/self/fd/0` works
`privoxy --no-daemon /etc/ld.so.conf` gives (obviously) a
"Ignoring unrecognized directive" warning and fails at binding to the
default port, because the system copy is running, but no EACCES error.
`sudo cp config /etc/privoxy/jc.conf; privoxy --no-daemon
/etc/privoxy/jc.conf` works

   * What was the outcome of this action?

As above. My best workaround so far is using /proc/self/fd/0

   * What outcome did you expect instead?

I'd expect it to work with a file protected 644 in the current
working directory.

-- System Information:
Debian Release: 12.1
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'oldstable'), (600, 'testing'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 
'oldstable-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 privoxy depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.36-9+deb12u3
ii  libmbedcrypto7 2.28.3-1
ii  libmbedtls14   2.28.3-1
ii  libmbedx509-1  2.28.3-1
ii  libpcre2-8-0   10.42-1
ii  logrotate  3.21.0-1
ii  ucf3.0043+nmu1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages privoxy recommends:
ii  doc-base  0.11.1

Versions of packages privoxy suggests:
ii  apparmor  3.0.8-3

-- debconf information:
  privoxy/listen-address: 127.0.0.1:8118 [::1]:8118

Bug#1005644: Intent to NMU pillow (Re: Bug#1005644: python3-pil: should depend on "media-types | mime-support")

[Charles Plessy]

Le Sun, Feb 13, 2022 at 11:38:24AM +0100, Jörg-Volker Peetz a écrit :
> 
> since package mime-support is a transitional package, please change the
> dependency on "mime-support | python3-pil.imagetk" to "media-types |
> mime-support | python3-pil.imagetk".

Dear Matthias,

I intend to NMU pillow to DELAYED/15 soon, unless you plan to remove the
dependency on mime-support by yourself in a reasonable delay.

Cheers,

Charles, maintainer of the media-types, mailcap and mime-support
packages.

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1052875: borgbackup2: FTBFS: E FileNotFoundError: [Errno 2] No such file or directory: '/<>/.pybuild/cpython3_3.11/build/borg/testsuite/archiver/repo12.tar.gz'

[Santiago Ruano Rincón]

Control: tag -1 + patch

On Mon, 16 Oct 2023 11:25:12 +0200 Simon Chopin  wrote:
> Source: borgbackup2
> Version: 2.0.0b5-1
> Followup-For: Bug #1052875
> X-Debbugs-Cc: scho...@ubuntu.com
> 
> I fixed this in 
> https://salsa.debian.org/schopin/borgbackup2/-/commit/8f02b24dc022ad26c7d78b5efe80b9e933a3ebc8
> but wasn't able to open a PR against the original Salsa repo, so here's
> the commit attached as a patch if you prefer it that way.

Thanks!


signature.asc
Description: PGP signature

Bug#1026091: zstd only

[Alexey Kuznetsov]

Issues is only zstd related. lzo /boot compression works / boots.

-- AK

Bug#1030835: ITP: ruff -- linter for Python, written in Rust

[Jelmer Vernooij]

On Wed, Oct 25, 2023 at 02:05:39PM +0200, Matthias Urlichs wrote:
> Hello,
> > Package: wnpp
> > Severity: wishlist
> > Owner: James Addison 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> > 
> > * Package name: ruff
> >Version : 0.0.243
> >Upstream Contact: Charlie Marsh
> > * URL : https://github.com/charliermarsh/ruff/
> > * License : MIT
> >Programming Lang: Rust
> >Description : linter for Python, written in Rust
> > 
> > Ruff is a linter for Python that includes implementations of many common
> > checks implemented by flake8, flake8 plugins, and pylint.
> > 
> Any progress with this?

See my recent posts to the bug report. We're waiting on various dependencies of 
ruff to
pass through NEW.

Jelmer

Bug#1030835: ITP: ruff -- linter for Python, written in Rust

[Matthias Urlichs]

Hello,

Package: wnpp
Severity: wishlist
Owner: James Addison 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ruff
   Version : 0.0.243
   Upstream Contact: Charlie Marsh
* URL : https://github.com/charliermarsh/ruff/
* License : MIT
   Programming Lang: Rust
   Description : linter for Python, written in Rust

Ruff is a linter for Python that includes implementations of many common
checks implemented by flake8, flake8 plugins, and pylint.


Any progress with this?

--
-- mit freundlichen Grüßen
--
-- Matthias Urlichs



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1054540: cups-filters: Does not automatically find proper liblouis braille tables

[Samuel Thibault]

Package: cups-filters
Version: 1.28.17-3
Severity: normal
Tags: l10n patch upstream
Forwarded: https://github.com/OpenPrinting/cups-filters/pull/555

Hello,

Since bookworm, cups-filter does not automatically find the proper
liblouis braille tables, ending up with messages such as:

"Could not find LibLouis table with locale de_DE"

This is because liblouis changed their table format in version 3.21. The
attached patch was forwarded to upstream to accomodate for this.

Could this also be backported to bookworm? Otherwise people cannot
easily emboss documents on braille printers with bookworm.

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Versions of packages cups-filters depends on:
ii  bc 1.07.1-3+b1
ii  cups-filters-core-drivers  1.28.17-3
ii  ghostscript10.02.0~dfsg-2
ii  libc6  2.37-12
ii  libcups2   2.4.7-1
ii  libcupsfilters11.28.17-3
ii  libfontconfig1 2.14.2-6
ii  libfontembed1  1.28.17-3
ii  libgcc-s1  13.2.0-5
ii  libqpdf29  11.6.3-1
ii  libstdc++6 13.2.0-5
ii  poppler-utils  22.12.0-2+b1

Versions of packages cups-filters recommends:
ii  colord 1.4.6-3
ii  liblouis-bin   3.27.0-1
ii  liblouisutdml-bin  2.11.0-4
ii  lynx   2.9.0dev.12-1

Versions of packages cups-filters suggests:
ii  antiword   0.37-16
ii  docx2txt   1.4-5
ii  foomatic-db-compressed-ppds [foomatic-db]  20230202-1
ii  imagemagick8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1.6

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
commit 0707c9645039ed872dd0a1cc970388f1ee4aa8a5
Author: Samuel Thibault 
Date:   Wed Oct 25 14:20:38 2023 +0200

braille: Fix finding tables from liblouis ≥3.21

Since 3.21 (more precisely, commit e18fe140e2f1), liblouis uses language:
and region: rather than locale:

diff --git a/filter/braille/filters/cups-braille.sh.in 
b/filter/braille/filters/cups-braille.sh.in
index 47fda21a8..0ce341aff 100644
--- a/filter/braille/filters/cups-braille.sh.in
+++ b/filter/braille/filters/cups-braille.sh.in
@@ -1,5 +1,5 @@
 #
-# Copyright (c) 2015-2018 Samuel Thibault 
+# Copyright (c) 2015-2018, 2023 Samuel Thibault 
 # 
 # Permission is hereby granted, free of charge, to any person obtaining a copy
 # of this software and associated documentation files (the "Software"), to deal
@@ -353,10 +353,12 @@ getOptionLibLouis () {
   score=0
   name=${table#$TABLESDIR/}
 
-  if grep -q "^#+locale:$LOUIS_LOCALE$" $table; then
+  if grep -q "^#+locale: *$LOUIS_LOCALE$" $table || \
+ grep -q "^#+region: *$LOUIS_LOCALE$" $table ; then
printf "DEBUG: %s has correct locale %s\n" "$name" "$LOUIS_LOCALE" >&2
score=$((score + 15))
-  elif grep -q "^#+locale:$LANGUAGE$" $table; then
+  elif grep -q "^#+locale: *$LANGUAGE$" $table || \
+   grep -q "^#+language: *$LANGUAGE$" $table; then
printf "DEBUG: %s has correct language %s\n" "$name" "$LANGUAGE" >&2
score=$((score + 10))
   else

Bug#1052750: r-cran-stanheaders seems to use old tbb interface instead of onetbb

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/stan-dev/rstan/issues/1101

Hi,

I opened an issue on StanHeaders upstream about an issue with rstan and
rstanarm.  Any help (patch) to port StanHeaders to the new onetbb
interface would be welcome.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1015871: Please enable CONFIG_PCI_P2PDMA

[Simon Richter]

Hi,

On 10/25/23 03:29, Emanuele Rocca wrote:


I hesitate to actually enable it because I don't understand PCI good
enough to judge it's a safe choice for the Debian kernel.


There is a kernel API for "return the physical address of a BAR mapping 
on another PCI device, as seen from the point of view of this device."


With the P2PDMA option disabled, that API always returns "no 
peer-to-peer capable path exists", which requires drivers to fall back 
to allocating a buffer.


If the option is enabled, a driver exporting a DMA buffer (such as a 
video capture device or a GPU) can provide an address that is part of 
one of its BAR mappings. The driver importing the DMA buffer will then 
use the physical address it was given in DMA requests, which routes the 
requests directly and avoids passing through the root complex.


I have successfully used this to make an nVidia GPU generate PCIe 
requests for textures that were answered by an FPGA card. :> The driver 
importing the buffer needs no special support.


There is no generic mechanism to use peer-to-peer transfers if not at 
least one side is aware of that mechanism, as it essentially requires 
the exporting device to implement full support for prefetchable BAR 
mappings.


Im principle, all platforms that support PCIe can benefit from this, as 
it allows peer-to-peer transfers even when the root complex does not 
support this, as long as all bridges on the path between the involved 
devices do. In practice, most transfers will happen between a GPU (in a 
slot directly connected to a root bridge) and some data capture device, 
so the benefit on platforms other than amd64 and ppc64le will be limited 
-- although these will just fall back to the current behaviour, and the 
only code paths affected are slow paths that usually end in TLB flushes 
for CPU and IO MMUs.


   Simon

Bug#1054539: RFP: gtk4-layer-shell -- library to create panels and widgets for wayland

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: bir...@debian.org, sunwea...@debian.org, werdah...@riseup.net, 
team+swa...@tracker.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: gtk4-layer-shell
  Version : 1.0.1
  Upstream Contact: Sophie Winter 
* URL : https://github.com/wmww/gtk4-layer-shell
* License : MIT
  Programming Lang: C
  Description : library to create panels and widgets for wayland

gtk4-layer-shell is the new layer-shell library using GTK4. While most
wayland-related programs like waybar still use gtk-layer-shell they
might switch in the near future. I could be convinced to comaintain this
library but I'd rather see someone else take it on as I maintain quite a
bit. Maybe this should be maintained under the Deabian sway team.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmU4/C0VHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1B4MP/2kLRM0jRwmgO/SCzxNo+LfPqc5a
O5PgBuu+FHFiUtpOCvCISgNaL1yLrjFuadJEIjooe7IAziIu4rPytCiZyf6tilL/
J2L2wp9AgAIg+3v5Dh1jfgUFz6/+mkbrPpoSp4oiLXQmCty334nv/ASzQ59Bph3j
Eh4RztNGIUITEfyt/pybuAYXKHvBSSKYwWHJlq834aht3OQB0DmVbtiNpAHrFket
oIdeyjQkDymqeimt9Ve0EDzDpXnBySEVjGCqKNkZF8LNCXNurJgR16DV43y/apj/
We8dQOH35q2QhOg8kfx8dkecWdSXhA4nSuLrXuLzlKl3gwl3d8wa/7uLRG9t1+NI
KiOSipJjKgV4NBrnQThn7E1SCylRtPcAZ6K0C8BZkyynSVgv7ApRSK/BcjztjrSK
KJVmvXDs0Fy636fTLOcFZMQZUOKhfk06uNvNISsErP5tGMjwCQUHVLX2vImHrrkS
y+0ca5QV793pDoF1knPfT4B2AiV8aLCKq6Q6b1SH+Xi6bFeGcOFF+GIUNR/Ls7D5
63IyueDLpZBDDbji6YvvgwpfzbvgaIfzcwSkrLPCVeRyNRwCzQEywywxUayLrTTV
nwLyDdgBb+TSflFKbEBqc7G9D/7kCWZytZxhHHW/0r4mCc4opwW4C9Zym4rVnrlQ
VIwPpjEWc5F2S3un
=Qalj
-END PGP SIGNATURE-

Bug#1038807: codeblocks: Depends on unmaintained gamin

[David Prévot]

Hi,

Le 24/10/2023 à 19:55, Bastian Germann a écrit :
I am uploading a NMU to DELAYED/10 in order to fix this. The changes are 
in the git repo and atttached as debdiff.


Thanks a lot! Feel free to reschedule your upload to DELAYED/0.

Regards

taffit

Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol

[Bo YU]

Hi!

On Wed, Oct 25, 2023 at 5:06 PM Arto Jantunen  wrote:
>
> Xiyue Deng  writes:
>
> > Arto Jantunen  writes:
> >
> >> Xiyue Deng  writes:
> >>
> >>> Hi Arto,
> >>>
> >>> Arto Jantunen  writes:
> >>>
>  Xiyue Deng  writes:
> > Package: sponsorship-requests
> > Severity: important
> > X-Debbugs-CC: debian-emac...@lists.debian.org
> >
> > Dear mentors,
> >
> > I am looking for a sponsor for my package "lsp-mode":
> >
> >  * Package name : lsp-mode
> >Version  : 8.0.0-6
> >Upstream contact : Vibhav Pant 
> >  * URL  : https://github.com/emacs-lsp/lsp-mode
> >  * License  : GPL-3+
> >  * Vcs  : https://salsa.debian.org/emacsen-team/lsp-mode
> >Section  : lisp
> >
> > The source builds the following binary packages:
> >
> >   elpa-lsp-mode - Emacs client/library for the Language Server Protocol
> >
> > To access further information about this package, please visit the 
> > following URL:
> >
> >   https://mentors.debian.net/package/lsp-mode/
> >
> > Alternatively, you can download the package with 'dget' using this 
> > command:
> >
> >   dget -x 
> > https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
> >
> > Changes since the last upload:
> >
> >  lsp-mode (8.0.0-6) unstable; urgency=medium
> >  .
> >* Add patch to fix test failures (Closes: #1052939).
> >* Update Standards-Version to 4.6.2.  No change needed.
> >* Add myself as uploader (Closes: #1042568).
> >* Add signing key verification to d/watch.
> >* Add d/upstream/metadata.
> >* Add Upstream-Contact and update year in d/copyright.
> >* Add patch to fix non-UTF-8 encoding.
> >* Drop unused lintian overrides.
> 
>  Thanks for taking over this package.
> 
>  When I try to build this (under sbuild) I get the following build
>  failure:
> 
>  Test ‘lsp-text-document-hover-request’ redefined
> 
>  Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
>    mapbacktrace(#f(compiled-function (evald func args flags) #  -0x187de6214517952>))
>    debug-early-backtrace()
>    debug-early(error (error "Test ‘lsp-text-document-hover-request’ 
>  redefined"))
>    error("Test `%s' redefined" lsp-text-document-hover-request)
>    ert-set-test(lsp-text-document-hover-request #s(ert-test :name
>  lsp-text-document-hover-request :documentation nil :body (closure (t) nil
>  (lsp-workspace-folders-add (f-join lsp-test-location "fixtures")) 
>  (find-file
>  (f-join lsp-test-location "fixtures/pyls/test.py")) (lsp) (deferred:sync!
>  (deferred:nextc (deferred:nextc (lsp-test--wait-for '(progn (eq 
>  'initialized
>  (lsp--workspace-status (cl-first (lsp-workspaces)) #'(lambda (_) 
>  (goto-char
>  (point-min)) (search-forward "fn1") (lsp-def-request-async 
>  "textDocument/hover"
>  (lsp--text-document-position-params #'(lambda (contents) (let* 
>  ((fn-566
>  #'lsp-hover?) (args-567 (condition-case err (let ((signal-hook-function
>  #'ert--should-signal-hook)) (list contents)) (error (progn (setq fn-566
>  #'signal) (list (car err) (cdr err))) (let ((value-568
>  'ert-form-evaluation-aborted-569)) (let (form-description-570) (if
>  (unwind-protect (setq value-568 (apply fn-566 args-567)) (setq
>  form-description-570 (nconc (list '(should (lsp-hover? contents))) (list 
>  :form
>  (cons fn-566 args-567)) (if (eql value-568 
>  'ert-form-evaluation-aborted-569) nil
>  (list :value value-568)) (if (eql value-568 
>  'ert-form-evaluation-aborted-569)
>  nil (let* ((-explainer- (and t (ert--get-explainer 'lsp-hover? (if
>  -explainer- (list :explanation (apply -explainer- args-567)) nil)
>  (ert--signal-should-execution form-description-570)) nil (ert-fail
>  form-description-570))) value-568) (kill-buffer)
>  (lsp-workspace-folders-remove (f-join lsp-test-location "fixtures")))
>  :most-recent-result nil :expected-result-type :passed :tags nil 
>  :file-name
>  "/<>/test/lsp-integration-test.el"))
>    
>  load-with-code-conversion("/<>/test/lsp-integration-test.el"
>   "/<>/test/lsp-integration-test.el" nil t)
>    command-line-1(("-l" "package" "--eval" "(add-to-list 
>  'package-directory-list
>  \"/usr/share/emacs/site-lisp/elpa\")" "--eval" "(add-to-list
>  'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" "-f"
>  "package-initialize" "-L" "clients/" "-L" "." "-L" "test" "-l"
>  "test/lsp-clangd-test.el" "-l" "test/lsp-completion-test.el" "-l"
>  "test/lsp-file-watch-test.el" "-l" "test/lsp-integration-test.el" "-l"
>  "test/lsp-io-test.el" "-l" "test/lsp-javascript-test.el" "-l"
>  "test/lsp-me

Bug#1054538: libboost-regex-dev: the static library should be compile with -PIC

[Frantisek Boranek]

Package: libboost-regex-dev
Version: 1.74.0.3
Severity: normal
X-Debbugs-Cc: fbora...@gmail.com

Dear Maintainer,

I wanted compile fat dynamic library with all its dependencies linked static 
and hidden symbols.

Let demonstrate on example:

```CMake
set(Boost_VERBOSE ON)
set(Boost_USE_STATIC_LIBS ON)
find_package(Boost REQUIRED COMPONENTS regex)

# library
add_library(lib_r SHARED lib_r.cc)
target_link_libraries(lib_r PRIVATE Boost::regex)

# executable
add_executable(test_r main_r.cc)
target_link_libraries(test_r PRIVATE lib_r)
```

with `set(Boost_USE_STATIC_LIBS ON)` is find static version of library

```
-- Found boost_regex 1.74.0 at 
/usr/lib/x86_64-linux-gnu/cmake/boost_regex-1.74.0
--   [ ] libboost_regex.so.1.74.0
--   [x] libboost_regex.a
```

and linking of shared library fails on:
```
[ 50%] Linking CXX shared library liblib_r.so
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libboost_regex.a(regex.o): warning: 
relocation against `_ZTVN5boost10wrapexceptISt11logic_errorEE' in read-only 
section `.text.unlikely'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libboost_regex.a(instances.o): 
relocation R_X86_64_PC32 against symbol 
`_ZTVSt15basic_streambufIcSt11char_traitsIcEE@@GLIBCXX_3.4' can not be used 
when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
```

full example: https://github.com/fboranek/boost-static

I think that even static library `libboost_regex.a` should be built with 
position independent code flag `-PIC`. I try the same for `Boost::thread` with 
the same result, so it apply probably on whole boost.

I try compile boost directly
```
./bootstrap.sh --with-libraries=regex
./b2 link=static runtime-link=shared
```

and replace `Boost::regex` by `boost/stage/lib/libboost_regex.a` and library 
and executable is liked witout issue. In light of this it seems the problem 
with packaging. I clone latest boost repo.

BR,
Frantisek

-- 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 5.10.0-25-amd64 (SMP w/24 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libboost-regex-dev depends on:
ii  libboost-regex1.74-dev  1.74.0+ds1-21

libboost-regex-dev recommends no packages.

libboost-regex-dev suggests no packages.

-- no debconf information

Bug#1054537: Squid 6.3: multiple vulnerabilities, patches available

[Andras Korn]

Package: squid
Version: 6.3-1
Severity: grave
Tags: security patch
X-Debbugs-Cc: Debian Security Team 

Hi,

https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2023-2725 
links to a bunch of squid advisories, three of which have CVSS scores of 9+:

https://github.com/squid-cache/squid/security/advisories/GHSA-2g3c-pg7q-g59w
https://github.com/squid-cache/squid/security/advisories/GHSA-phqj-m8gv-cq4g
https://github.com/squid-cache/squid/security/advisories/GHSA-543m-w2m2-g255
https://github.com/squid-cache/squid/security/advisories/GHSA-j83v-w3p4-5cqh

Squid 6.4 includes the fix; patches for 6.3 are provided, but don't apply 
cleanly to the Debian sources.

Please package a non-vulnerable version ASAP.

Thanks!

András

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

Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

-- 
   Computers are not intelligent. They only think they are.

Bug#1039668: apparmor: prompting due to modified conffiles which were not modified by the user: /etc/apparmor.d/abstractions/ubuntu-browsers.d/chromium-browser

[intrigeri]

Hi,

Andreas Beckmann (2023-06-28):
> This bug only manifests if the test system originated in jessie and had
> apparmor-profiles from jessie installed before it got upgraded release
> by release until bookworm.

Indeed, before 3.0.0-1, apparmor-profiles.postinst did that:

if [ ! -e 
/etc/apparmor.d/abstractions/ubuntu-browsers.d/chromium-browser ]; then
cp 
/usr/share/apparmor/extra-profiles/abstractions/ubuntu-browsers.d/chromium-browser
 /etc/apparmor.d/abstractions/ubuntu-browsers.d || true
fi

This code snippet was removed in 3.0.0-1 but at the same time,
upstream changed made it so we started shipping
/etc/apparmor.d/abstractions/ubuntu-browsers.d/chromium-browser in the
apparmor binary package, which causes the conflict.

This abstraction is only used by the upstream chromium_browser
profile, which we don't ship.

So I'm going to solve this bug in the simplest possible way: stop
shipping the offending
/etc/apparmor.d/abstractions/ubuntu-browsers.d/chromium-browser.

(Ideally, on top of this apparmor-profile should remove its own copy
on upgrades, but that's much less important, so I'm not going to
fiddle with this right now.)

For additional context, all this stuff has never been really
maintained in Debian proper; it was once used by Ubuntu, together with
their own AppArmor profile for Chromium, but since they moved to
shipping Chromium as a Snap and don't use this AppArmor
policy anymore.

Cheers,
-- 
intrigeri

Bug#1050237: transition: mutter/gnome-shell 45

[Simon McVittie]

I don't think this was cc'd to the release team when it was reassigned,
so quoting full text below for the release team's reference:

On Tue, 24 Oct 2023 at 14:09:06 -0400, Jeremy Bícha wrote:
> We will be ready to do the GNOME Shell/Mutter 45 transition once
> magpie is accepted from Debian NEW and budgie-desktop switches to it.
> I'm setting the moreinfo tag until that happens.
> 
> The remaining sourceful re-uploads from Experimental are:
> 
> * mutter
> * gnome-shell
> * gnome-shell-extensions
> * gnome-remote-desktop
> 
> And these extensions, so far:
> * gnome-shell-extension-appindicator
> * gnome-shell-extension-arc-menu
> * gnome-shell-extension-caffeine
> * gnome-shell-extension-dash-to-panel
> * gnome-shell-extension-dashtodock
> * gnome-shell-extension-desktop-icons-ng
> * gnome-shell-extension-espresso
> * gnome-shell-extension-gsconnect
> * gnome-shell-extension-hide-activities
> * gnome-shell-extension-kimpanel
> * gnome-shell-extension-runcat
> * gnome-shell-extension-shortcuts
> * gnome-shell-extension-tiling-assistant
> * gnome-shell-pomodoro
> * gpaste
> * workrave
> * yaru-theme
> 
> And then any remaining extensions in
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org&tag=gnome-shell-45
> will need to be either fixed or temporarily kicked out of testing
> to let the transition through.
> 
> We can provide a specific list of extensions to remove from Testing
> when we get to that point in the transition.
> 
> Notably, every GNOME Shell extension needs to be adjusted for the new
> ESM import style. It is not possible for extensions to be compatible
> with both GNOME Shell >=45 and <=44 without some source code changes.
> For more details of required changes, see
> https://gjs.guide/extensions/upgrading/gnome-shell-45.html
> 
> The tracker for this transition is
> https://release.debian.org/transitions/html/gnome-shell-45.html

Bug#1054536: cyrus-sasl2 FTBFS: sphinx failure: AttributeError("'str' object has no attribute 'attributes'")

[Helmut Grohne]

Source: cyrus-sasl2
Version: 2.1.28+dfsg1-3
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

cyrus-sasl2 fails to build from source in unstable. A non-parallel build
ends as follows:

| /usr/bin/sphinx-build -d docsrc/.doctrees -n -q -D today=2023-08-03 -b html 
./docsrc ./doc/html
| WARNING: extlinks: Sphinx-6.0 will require a caption string to contain 
exactly one '%s' and all other '%' need to be escaped as '%%'.
| WARNING: extlinks: Sphinx-6.0 will require a caption string to contain 
exactly one '%s' and all other '%' need to be escaped as '%%'.
| 
| Theme error:
| An error happened in rendering the page developer.
| Reason: AttributeError("'str' object has no attribute 'attributes'")
| make[2]: *** [Makefile:1165: doc/html/.sphinx-build.stamp] Error 2
| make[2]: Leaving directory '/<>/build-mit'
| dh_auto_build: error: cd build-mit && make -j1 
sasldir=/usr/lib/x86_64-linux-gnu/sasl2 all doc-html returned exit code 2
| make[1]: *** [debian/rules:166: override_dh_auto_build] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:127: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

I don't quit see the cause of this failure just yet, maybe someone else
does?

Helmut