Bug#1032057: pyproject-api: please make the build reproducible

[Chris Lamb]

Source: pyproject-api
Version: 1.5.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed
that pyproject-api could not be built reproducibly.

This is because the documentation embeds the current date in the
build system's current timezone. A patch is attached that uses
SOURCE_DATE_EPOCH [1] if available.

 [0] https://reproducible-builds.org/
 [1] https://reproducible-builds.org/specs/source-date-epoch/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2023-02-27 07:50:58.360366831 
+
@@ -0,0 +1,26 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2023-02-27
+
+--- pyproject-api-1.5.0.orig/docs/conf.py
 pyproject-api-1.5.0/docs/conf.py
+@@ -1,5 +1,7 @@
+ from __future__ import annotations
+ 
++import os
++import time
+ from datetime import datetime
+ 
+ from pyproject_api import __version__
+@@ -20,7 +22,10 @@ extensions = [
+ master_doc, source_suffix = "index", ".rst"
+ 
+ html_theme = "furo"
+-html_title, html_last_updated_fmt = "pyproject-api docs", 
datetime.now().isoformat()
++build_date = datetime.utcfromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
++)
++html_title, html_last_updated_fmt = "pyproject-api docs", 
build_date.isoformat()
+ pygments_style, pygments_dark_style = "sphinx", "monokai"
+ 
+ autoclass_content, autodoc_typehints = "both", "none"
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2023-02-27 07:50:56.832357814 +
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#1031701: python3-pandas: Pandas requires version '2.0.1' or newer of 'xlrd'

[Rebecca N. Palmer]

I don't consider the lack of .xls in pandas worth a freeze exception, 
but consider it reasonable for others to disagree with that.


As noted in the bug, there are some (possibly not-technically-valid) 
.xlsx files that xlrd 1 can open but openpyxl can't - _pandas_ won't be 
able to open those either way, but allowing other applications to do so 
is still worth something.


There also may be applications that could switch to openpyxl but simply 
haven't.  I don't know how much effort switching is / whether it would 
be reasonably possible for us to do it.


However, I wasn't aware of the security issues in xlrd 1 when I wrote 
that, and they may well be a reason to go to xlrd 2 and accept this 
breakage.  Are they the long-standing "denial of service via excessive 
XML entity expansion" or is there now (also) a risk of something worse?

Bug#1032056: dtrace -G generates unreproducible object files due to random temp file

[Gioele Barabucci]

Package: systemtap-sdt-dev
Version: 4.8-1
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness filesystem
Control: block 1032055 by -1

`dtrace -G` creates temporary files with random filenames. The name of 
these temporary files gets embedded in the ELF `.symtab` of the final 
object files, making them always slightly different.


This behavior makes all packages that use `dtrace`-produced object files 
inherently non reproducible.


Instead of being fully random, `dtrace` should employ some sort of 
controlled reproducible randomness, for example based on the value of 
`SOURCE_DATE_EPOCH`. See also 
.


To reproduce this issue:

```
$ git clone https://salsa.debian.org/sssd-team/sssd.git
$ cd sssd
$ mkdir -p build && cd build/

$ dtrace -C -G -s ../src/systemtap/sssd_probes.d -o stap_generated_probes.o
$ readelf --wide --symbols stap_generated_probes.o > sym1.txt

$ dtrace -C -G -s ../src/systemtap/sssd_probes.d -o stap_generated_probes.o
$ readelf --wide --symbols stap_generated_probes.o > sym2.txt

$ diff -u sym1.txt sym2.txt
--- sym1.txt2023-02-27 08:38:48.955299234 +0100
+++ sym2.txt2023-02-27 08:38:49.103303352 +0100
@@ -2,7 +2,7 @@
 Symbol table '.symtab' contains 59 entries:
 Num:Value  Size TypeBind   Vis  Ndx Name
   0: 00   0 NOTYPE  LOCAL  DEFAULT  UND
-  1: 00   0 FILELOCAL  DEFAULT  ABS .dtrace-temp.4f0bbdda.c
+  1: 00   0 FILELOCAL  DEFAULT  ABS .dtrace-temp.d20e76c7.c
   2: 00   0 SECTION LOCAL  DEFAULT1 .text
   3: 00   7 FUNCLOCAL  DEFAULT1 __dtrace
   4: 00   0 SECTION LOCAL  DEFAULT5 .debug_info
```

Regards,

--
Gioele Barabucci

Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.

[Rai]

Hi Otto,

below the information you requested from my system:

pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"
none

pgrep -af "mysql|mariadb"
1908 /usr/sbin/mysqld-akonadi 
--defaults-file=/home/rai/.local/share/akonadi/mysql.conf 
--datadir=/home/rai/.local/share/akonadi/db_data/ 
--socket=/tmp/akonadi-rai.bxYrSB/mysql.socket 
--pid-file=/tmp/akonadi-rai.bxYrSB/mysql.pid

The problem has been described here first:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770

I will give an overview:
kontact (kmail, kalendar) does not work anymore

the akonadi error file shows:

org.kde.pim.akonadiserver: DATABASE ERROR:
org.kde.pim.akonadiserver:   Error code: "1292"
org.kde.pim.akonadiserver:   DB error:  "Incorrect datetime value: 
'2023-02-22T12:00:36Z' for column `akonadi`.`pimitemtable`.`datetime` at row 1"
org.kde.pim.akonadiserver:   Error text: "Incorrect datetime value: 
'2023-02-22T12:00:36Z' for column `akonadi`.`pimitemtable`.`datetime` at row 1 
QMYSQL: Unable to execute query"
org.kde.pim.akonadiserver:   Query: "INSERT INTO PimItemTable (rev, remoteId, 
remoteRevision, gid, collectionId, mimeTypeId, datetime, atime, dirty, size) 
VALUES (:0, :1, :2, :3, :4, :5, :6, :7, :8, :9)"
org.kde.pim.akonadiserver: Error during insertion into table "PimItemTable" 
"Incorrect datetime value: '2023-02-22T12:00:36Z' for column 
`akonadi`.`pimitemtable`.`datetime` at row 1 QMYSQL: Unable to execute query"

The culprit seems to be:
libmariadb3_1%3a10.3.38-0+deb10u1_amd64.deb

which has been updated on my system last Tuesday:
2023-02-21 07:30:26 upgrade libmariadb3:amd64 1:10.3.36-0+deb10u2 
1:10.3.38-0+deb10u1

The next morning, kmail was broken.

If I understood it well, this was an upgrade from 10.3.36 to 10.3.38.

Paul did some research and it seems this commit to be the problem:

https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/773fb3e04ffae2b4868876be632fb7244329e7c3

Looking at the diff, I found the following change to 
libmariadb/libmariadb/mariadb_lib.c:

@@ -3879,7 +3881,7 @@ int STDCALL mysql_set_server_option(MYSQL *mysql,

 ulong STDCALL mysql_get_client_version(void)
 {
-  return MARIADB_VERSION_ID;
+  return MARIADB_PACKAGE_VERSION_ID;
 }

BTW, I'm not using any oldstable stuff.
My sources.list looks like:

deb http://ftp.de.debian.org/debian/ buster main contrib non-free
deb-src http://ftp.de.debian.org/debian/ buster main contrib non-free

deb http://security.debian.org/debian-security buster/updates main contrib 
non-free
deb-src http://security.debian.org/debian-security buster/updates main contrib 
non-free

deb http://ftp.de.debian.org/debian/ buster-updates main non-free
deb-src http://ftp.de.debian.org/debian/ buster-updates main non-free

So it looks to me that whith a security update a functional change came in.

If I can help more, let me know.

Regards
Rai

Am 27.02.2023 um 06:46 schrieb Otto Kekäläinen:

> Hi!
> 
> Thanks for reporting this. What does the exact process listing look
> like on a system that has the Akonadi server running?
> 
> What do these commands below yield on your system?
> 
> pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"
> pgrep -af "mysql|mariadb"
> 
> Indeed, the preinst has a section where it tries to stop any existing
> servers. This section has been there for years and years, this is
> nothing new in 10.11. Maybe it should have an extra check for Akonadi
> in particular, or maybe some trigger for Akonadi to restart the
> embedded MariaDB it has.

Bug#1030851: bullseye-pu: package symfony/4.4.19+dfsg-2+deb11u2

[David Prévot]

Hi Paul,

Le 26/02/2023 à 21:54, Paul Gevers a écrit :

On 08-02-2023 13:53, David Prévot wrote:

[ Tests ]
I didn’t test it thoroughly (I doubt to have much time for at least
another week), but it passes


There are issues with the installability of src:symfony packages as can 
be seen from the autopkgtests [1]:


Thank you for the heads up! Shame on me for not checking thoroughly the 
autotest result, but glad I enabled it and thank you again for pointing 
me the regression! I’ll look at it ASAP (IIRC, it should just be an 
unneeded version bump to get the patched version), and provide an 
updated version with an update to this bug report.


Regards

David

Bug#1032055: sssd: dtrace temp file makes build unreproducbile

[Gioele Barabucci]

Package: sssd
Version: 2.8.2-3
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness filesystem

sssd fails to build reproducibly because each binary embeds a different 
GNU build ID. In turn these different and unreproducible build IDs are 
due to the fact that `dtrace` generates a temporary file with a random 
component, for example `.dtrace-temp.5a8ef97b.c` or 
`.dtrace-temp.6cae9ff0.c`. These temporary dtrace files are then 
compiled in the final binary (for instance via 
`stap_generated_probes.o`) and contribute to the calculation of the 
(always different) build ID.


This bug should probably be fixed upstream (in systemtap/dtrace), but 
I'm filing this bug here so that the current source of unreproducibility 
of sssd is known.


Regards,

--
Gioele Barabucci

Bug#1031382: Re: Bug#1031382: RFS: libkysdk-base/1.0.1-1 [ITP] -- Kylin SDK basic library

[Kevin Duan]

Hi！


Thanks for receiving your letter! Based on your suggestion, I've reworked the 
changelog, control and package.install files in the debian directory, adjusted 
the version numbers, dependencies and installation paths of the binary 
packages, etc

I've re-uploaded the adjusted version to mentors, so thank you again for 
reviewing it!



Thanks,
KevinDuan






在2023年02月24 04时44分，"Boyuan Yang"写道：

Hi,

在 2023-02-22星期三的 17:25 +0800，Kevin Duan写道：
> HI!
> 
> Thanks for the heads up, I have fixed this issue in the latest version and
> have also uploaded the latest to mentors.
> URL: https://mentors.debian.net/package/libkysdk-base/
> Version:1.0.1-3
> 
> Thanks！
> KevinDuan


Several issues that need fix:

* Since your package has not entered Debian officially, please do not
increase the revision number. In your next source package provided, please
still use 1.0.1-1 as version number, not 1.0.1-4. Please only increase
revision numbers after your package is officially accepted into Debian
archive.

* For packages that only contains development headers (*-dev), they do not
include shared library files. As a result, the dependency substitution
${shlibs:Depends} is absolutely not needed. Please drop these lines from
debian/control file. However: please do not delete ${shlibs:Depends}
substitution from packages that actually contains shared library file.

* Compared with your previous 1.0.1-1 upload, the current packaging will
directly place header files under /usr/include/ instead of placing them
under subdirectories. While this behavior does not directly conflict with
packaging policy, I will have to let you know that your packaging is likely
to be problematic, buggy and will cause issues in the futures. For example
in the future libkysdk-system packaging
at https://mentors.debian.net/package/libkysdk-system/, some file (e.g.,
src/systeminfo/libkysisinfo.c) will look for header in , not /usr/include/cstring-extension.h. This means
that libkysdk-system will break when being built in the future. Please,
carefully review your packaging decision again; if you are sure that current
packaging is acceptable, I can upload it as-is. Otherwise I recommend you to
review the decision on header file path.

Thanks,
Boyuan Yang


> 在2023年02月22 06时34分，"Boyuan Yang"写道：
> > 
> > Control: tags -1 +moreinfo
> > 
> > Indeed, please fix the error listed below before we can proceed.
> > 
> > Thanks,
> > Boyuan Yang
> > 
> > On Thu, 16 Feb 2023 19:55:44 +0100 Adam Borowski 
> > wrote:
> > > On Thu, Feb 16, 2023 at 11:05:42AM +0800, kevin wrote:
> > > >   * Package name : libkysdk-base
> > > > Version  : 1.0.1-1
> > > 
> > > >   libkysdk-base (1.0.1-1) unstable; urgency=medium
> > > >   .
> > > > * Initial release. (Closes: #1031344)
> > > 
> > > Hi!
> > > Alas, the package fails to build:
> > > 
> > > .
> > > dh_missing: warning: etc/kysdk/kysdk-base/kylog-rotate-default exists
> > > in
> > debian/tmp but is not installed to anywhere (related file:
> > "src/log/kylog-
> > rotate-default")
> > > dh_missing: warning: usr/include/kysdk/kysdk-base/libkylog.h exists in
> > debian/tmp but is not installed to anywhere (related file:
> > "src/log/libkylog.h")
> > > dh_missing: warning: usr/include/kysdk/kysdk-base/listdata.h exists in
> > debian/tmp but is not installed to anywhere (related file:
> > "src/utils/data-
> > structure/linklist/listdata.h")
> > > dh_missing: warning: usr/include/kysdk/kysdk-base/skip_linklist.h
> > > exists
> > in debian/tmp but is not installed to anywhere (related file:
> > "src/utils/data-structure/linklist/skip_linklist/skip_linklist.h")
> > > dh_missing: error: missing files, aborting
> > > 
> > >While detecting missing files, dh_missing noted some files with
> > > a
> > similar name to those
> > >that were missing.  This error /might/ be resolved by replacing
> > references to the
> > >missing files with the similarly named ones that dh_missing
> > > found -
> > assuming the content
> > >is identical.
> > > 
> > >As an example, you might want to replace:
> > > * src/log/kylog-rotate-default
> > >with:
> > > * etc/kysdk/kysdk-base/kylog-rotate-default
> > >in a file in debian/ or as argument to one of the dh_* tools
> > > called
> > from debian/rules.
> > >(Note it is possible the paths are not used verbatim but
> > > instead
> > directories 
> > >containing or globs matching them are used instead)
> > > 
> > >Alternatively, add the missing file to debian/not-installed if
> > > it
> > cannot and should not
> > >be used.
> > > 
> > >The following debhelper tools have reported what they installed
> > (with files per package)
> > > * dh_install: libkysdk-base (0), libkysdk-base-dev (1),
> > > libkysdk-
> > config (2), libkysdk-config-dev (3), libkysdk-log (5), libkysdk-log-dev
> > (3),
> > libkysdk-timer (2), libkysdk-timer-dev (3), libkysdk-utils (4),
> > 

Bug#1032054: darktable: AVIF support is missing in Darktable

[Guy Rutenberg]

Package: darktable
Version: 4.2.0-2+b1
Severity: wishlist
X-Debbugs-Cc: guyrutenb...@gmail.com

Dear Maintainer,

Darktable isn't compiled against libavif, resulting in no AVIF support.
libavif15 is available in the repos, so there should be no problem to depend on
it.

Thanks for you work,
Guy


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

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

Versions of packages darktable depends on:
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libcolord-gtk1   0.3.0-3
ii  libcolord2   1.4.6-2.1
ii  libcups2 2.4.2-1+b2
ii  libcurl3-gnutls  7.87.0-2
ii  libexiv2-27  0.27.6-1
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.5-1
ii  libgomp1 12.2.0-14
ii  libgphoto2-6 2.5.30-1
ii  libgphoto2-port122.5.30-1
ii  libgraphicsmagick-q16-3  1.4+really1.3.40-2
ii  libgtk-3-0   3.24.36-4
ii  libheif1 1.14.2-1
ii  libicu72 72.1-3
ii  libimath-3-1-29  3.1.6-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libjxl0.70.7.0-10
ii  liblcms2-2   2.14-2
ii  liblensfun1  0.3.3-1
ii  liblua5.4-0  5.4.4-3
ii  libopenexr-3-1-303.1.5-4
ii  libopenjp2-7 2.5.0-1+b1
ii  libosmgpsmap-1.0-1   1.2.0-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpng16-16  1.6.39-2
ii  libportmidi0 1:217-6.1
ii  libpugixml1v51.13-0.2
ii  librsvg2-2   2.54.5+dfsg-1
ii  libsdl2-2.0-02.26.3+dfsg-1
ii  libsecret-1-00.20.5-3
ii  libsoup2.4-1 2.74.3-1
ii  libsqlite3-0 3.40.1-1
ii  libstdc++6   12.2.0-14
ii  libtiff6 4.5.0-5
ii  libwebp7 1.2.4-0.1
ii  libwebpmux3  1.2.4-0.1
ii  libx11-6 2:1.8.3-3
ii  libxml2  2.9.14+dfsg-1.1+b3
ii  libxrandr2   2:1.5.2-2+b1
ii  zlib1g   1:1.2.13.dfsg-1

darktable recommends no packages.

darktable suggests no packages.

-- no debconf information

Bug#1032053: mariadb: FTBFS on sh4:

[Otto Kekäläinen]

Source: mariadb
Version: 1:10.11.2-1
Tags: help, ftbfs
User: debian-sup...@lists.debian.org
Usertags: sh4

Several previous builds on sh4 passed on both MariaDB 10.11 and 10.6.
Recent example 1:10.11.1-4:
https://buildd.debian.org/status/fetch.php?pkg=mariadb=sh4=1%3A10.11.1-3=1675695708=0

Most recent version 1:10.11.2-1 however fails despite several retries:
https://buildd.debian.org/status/fetch.php?pkg=mariadb=sh4=1%3A10.11.2-1=1677371742=0

The build log looks quite different from previous runs. The latest one
is filled with errors like:

./builddir/CMakeFiles/CMakeScratch/TryCompile-vbob7S/./builddir/CMakeFiles/CMakeScratch/TryCompile-vbob7S/CheckFunctionExists.c:22:
undefined reference to `floor'
collect2: error: ld returned 1 exit status

/usr/bin/cc -g -O2 -ffile-prefix-map=/<>=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector
--param=ssp-buffer-size=4 -DCHECK_FUNCTION_EXISTS=crypt
-specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,now
-rdynamic CMakeFiles/cmTC_5d0a9.dir/CheckFunctionExists.c.o -o
cmTC_5d0a9
/usr/bin/ld: CMakeFiles/cmTC_5d0a9.dir/CheckFunctionExists.c.o: in
function `main':
./builddir/CMakeFiles/CMakeScratch/TryCompile-PjQ7gO/./builddir/CMakeFiles/CMakeScratch/TryCompile-PjQ7gO/CheckFunctionExists.c:22:
undefined reference to `crypt'
collect2: error: ld returned 1 exit sta

/<>/builddir/CMakeFiles/CMakeScratch/TryCompile-lnltIo/HAVE_IEEEFP_H.c:2:10:
fatal error: ieeefp.h: No such file or directory
2 | #include 
  |  ^~
compilation terminated.


I also noticed the configure stage has errors like:

-- Looking for mmap64 - not found
CMake Error: Generator: execution of make failed. Make command was:
/usr/bin/gmake -f Makefile cmTC_fa600/fast &&
-- Looking for lzma_easy_encoder in /usr/lib/sh4-linux-gnu/liblzma.so
- not found
CMake Error: Generator: execution of make failed. Make command was:
/usr/bin/gmake -f Makefile cmTC_a81fc/fast &&

While comparing the build logs I noticed that a previous passing build
installed 'libmpdec3' as a build dependency. Also in successful log
configure includes passing '-- Looking for mmap64 - found'.

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Otto Kekäläinen]

Hi!

> > reassign 1031863 libmariadb3 1:10.3.34-0+deb10u1
> > thanks

Why did you run into this issue now? The version above has been in
Debian oldstable since almost a year, are you sure you diagnosed this
for the correct package version?

> > This is a bug in oldstable! If mariadb maintainers pushed a new version
> > there then they need to undo the change you mention above. This is not a Qt
> > issue for oldstable.
>
> It was an open question as to whether Debian packaging would adopt the same
> strategy as Qt upstream, introducing the workaround in Qt, or mitigate the
> problem in the libmariadb3 packaging. I wonder, then, if the severity should
> be elevated since this regression potentially breaks numerous other packages.

This is the first bug report on this. It might affect other packages,
but there is no evidence of that yet. Also I am a little bit confused
on what is the actual error here.

Could you provide me the exact commands I should run in e.g. a Docker
container with Debian Buster to reproduce the bug? If I can reproduce
it, I should be able to get to the bottom of it.

Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.

[Otto Kekäläinen]

Hi!

Thanks for reporting this. What does the exact process listing look
like on a system that has the Akonadi server running?

What do these commands below yield on your system?

pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"
pgrep -af "mysql|mariadb"

Indeed, the preinst has a section where it tries to stop any existing
servers. This section has been there for years and years, this is
nothing new in 10.11. Maybe it should have an extra check for Akonadi
in particular, or maybe some trigger for Akonadi to restart the
embedded MariaDB it has.

Bug#1032052: python-apt: diff for NMU version 2.5.2+nmu1

[aristo . chen]

Package: python-apt
Version: 2.5.2
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for python-apt (versioned as 2.5.2+nmu1). The diff
is attached to this message.

Regards.

diff -Nru python-apt-2.5.2/apt/package.py python-apt-2.5.2+nmu1/apt/package.py
--- python-apt-2.5.2/apt/package.py 2023-01-23 09:51:16.0 +
+++ python-apt-2.5.2+nmu1/apt/package.py2023-02-20 12:21:39.0 
+
@@ -878,7 +878,7 @@
 % (
 self.package.name,
 self.version,
-getattr(index, "describe", ""),
+getattr(index, "describe", ""),
 )
 )
 if not self.uri:
diff -Nru python-apt-2.5.2/debian/changelog 
python-apt-2.5.2+nmu1/debian/changelog
--- python-apt-2.5.2/debian/changelog   2023-01-23 09:51:16.0 +
+++ python-apt-2.5.2+nmu1/debian/changelog  2023-02-20 12:48:12.0 
+
@@ -1,3 +1,10 @@
+python-apt (2.5.2+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix typo from "unkown" to "unknown"
+
+ -- Aristo Chen   Mon, 20 Feb 2023 12:48:12 +
+
 python-apt (2.5.2) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff -Nru python-apt-2.5.2/po/python-apt.pot 
python-apt-2.5.2+nmu1/po/python-apt.pot
--- python-apt-2.5.2/po/python-apt.pot  2023-01-23 09:51:16.0 +
+++ python-apt-2.5.2+nmu1/po/python-apt.pot 2023-02-20 12:44:57.0 
+
@@ -8,7 +8,7 @@
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2022-11-30 17:37+0100\n"
+"POT-Creation-Date: 2023-02-20 12:44+\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME \n"
 "Language-Team: LANGUAGE \n"
@@ -74,7 +74,7 @@
 msgstr ""
 
 #. CompDescription
-#: ../data/templates/Ubuntu.info.in:140 ../data/templates/Debian.info.in:90
+#: ../data/templates/Ubuntu.info.in:140 ../data/templates/Debian.info.in:113
 msgid "Officially supported"
 msgstr ""
 
@@ -119,7 +119,7 @@
 msgstr ""
 
 #. Description
-#: ../data/templates/Ubuntu.info.in:195 ../data/templates/Debian.info.in:36
+#: ../data/templates/Ubuntu.info.in:195 ../data/templates/Debian.info.in:53
 msgid "Recommended updates"
 msgstr ""
 
@@ -136,51 +136,57 @@
 #. ChangelogURI
 #: ../data/templates/Debian.info.in.h:4
 #, no-c-format
-msgid "http://packages.debian.org/changelogs/pool/%s/%s/%s/%s_%s/changelog;
+msgid ""
+"https://metadata.ftp-master.debian.org/changelogs/%s/%s/%s/%s_%s_changelog;
 msgstr ""
 
 #. Description
-#: ../data/templates/Debian.info.in:9
+#: ../data/templates/Debian.info.in:25
 msgid "Debian {version} '{codename}'"
 msgstr ""
 
 #. Description
-#: ../data/templates/Debian.info.in:30
+#: ../data/templates/Debian.info.in:47
 msgid "Security updates"
 msgstr ""
 
 #. Description
-#: ../data/templates/Debian.info.in:42
+#: ../data/templates/Debian.info.in:59
 msgid "Proposed updates"
 msgstr ""
 
 #. Description
-#: ../data/templates/Debian.info.in:49
+#: ../data/templates/Debian.info.in:66
 msgid "Debian current stable release"
 msgstr ""
 
 #. Description
-#: ../data/templates/Debian.info.in:62
+#: ../data/templates/Debian.info.in:81
 msgid "Debian testing"
 msgstr ""
 
 #. Description
-#: ../data/templates/Debian.info.in:88
+#: ../data/templates/Debian.info.in:111
 msgid "Debian 'Sid' (unstable)"
 msgstr ""
 
 #. CompDescription
-#: ../data/templates/Debian.info.in:92
+#: ../data/templates/Debian.info.in:115
 msgid "DFSG-compatible Software with Non-Free Dependencies"
 msgstr ""
 
 #. CompDescription
-#: ../data/templates/Debian.info.in:94
+#: ../data/templates/Debian.info.in:117
+msgid "Non-DFSG-compatible Firmware for Hardware Support"
+msgstr ""
+
+#. CompDescription
+#: ../data/templates/Debian.info.in:119
 msgid "Non-DFSG-compatible Software"
 msgstr ""
 
 #. TRANSLATORS: %s is a country
-#: ../aptsources/distro.py:215 ../aptsources/distro.py:446
+#: ../aptsources/distro.py:206 ../aptsources/distro.py:461
 #, python-format
 msgid "Server for %s"
 msgstr ""
@@ -188,31 +194,31 @@
 #. More than one server is used. Since we don't handle this case
 #. in the user interface we set "custom servers" to true and
 #. append a list of all used servers
-#: ../aptsources/distro.py:233 ../aptsources/distro.py:239
-#: ../aptsources/distro.py:255
+#: ../aptsources/distro.py:225 ../aptsources/distro.py:237
+#: ../aptsources/distro.py:258
 msgid "Main server"
 msgstr ""
 
-#: ../aptsources/distro.py:259
+#: ../aptsources/distro.py:267
 msgid "Custom servers"
 msgstr ""
 
-#: ../apt/package.py:592
+#: ../apt/package.py:619
 #, python-format
 msgid "Missing description for '%s'.Please report."
 msgstr ""
 
-#: ../apt/package.py:600
+#: ../apt/package.py:629
 #, python-format
 msgid "Invalid unicode in description for '%s' (%s). Please report."
 msgstr ""
 
-#: ../apt/package.py:1276 ../apt/package.py:1288 ../apt/package.py:1397
-#: ../apt/package.py:1411
+#: ../apt/package.py:1330 ../apt/package.py:1346 

Bug#1031780: tracker.debian.org: add information about patches

[Paul Wise]

On Sun, 2023-02-26 at 17:02 +0100, Raphael Hertzog wrote:

> I added the required support in tracker.debian.org

Personally I think we should replace the Ubuntu panel with a patches
panel, as I have done for the old PTS some years ago:

https://packages.qa.debian.org/g/glibc.html

This bug lists some ideas for doing that on the tracker:

https://bugs.debian.org/779400

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1007923: maven-*-helper JAR placement seems to contradict Java policy

[tony mancill]

On Sun, Feb 12, 2023 at 11:36:46AM -0800, tony mancill wrote:
> On Mon, Feb 06, 2023 at 08:03:06AM +0100, Alexandre Rossi wrote:
> > Hi,
> > 
> > > I'm +1 for the change, but at this point I propose we wait for bookworm
> > > to release.  I'm not sure what could go wrong, but it seems late in the
> > > release cycle for this change.  How about an upload to experimental?
> > 
> > An upload to experimental would be great.
> 
> I will do this as soon once the FTBFS is addressed [1].

I conduced a few test builds with and without the patch and the
resulting debdiffs look as expected.  I just uploaded this to
experimental as 2.6.3~exp1 and pushed the patched sources to the Salsa
in the debian/experimental branch.  Once bookworm releases, I will merge
back to the master branch and upload for trixie.

Thank you for the patch Alexandre, and to Jochen Sprickerhof for fixing
the FTBFS.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1020460: xdaliclock: New version ignores Xresource settings and can't be made transparent

[ydld1pw02]

Any progress on making version xdaliclock 2.44 available as a separate package?

Bug#1032051: linphone-cli: configuration file, manual and /usr/share/doc/linphone-cli/README.

[peter]

Package: linphone-cli
Version: 4.4.21-2
Severity: important
X-Debbugs-Cc: pe...@easthope.ca

Dear Maintainer,

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

   * What led up to the situation?
 Attempted to use linphone-cli.  Command linphonec.
 
   * What exactly did you do (or not do) that was effective (or ineffective)?
   Checked to find ~/.linphonerc .
   
   * What was the outcome of this action?
   ~/.linphonerc is not present before executing linphonec and still not 
present 
   after executing linphonec.
   
   * What outcome did you expect instead?
   According to man linphonec, ~/.linphonerc should be created at the first 
   execution of linphonec.  In fact there is a ~/.config/linphone/linphonerc.
   Probably created by the graphical version linphone-desktop.
   
   man linphonec and /usr/share/doc/linphone-cli/README should be 
   consistent with reality.  Ie. should state that linphone-cli doesn't create 
   the configuration but it can be created with the desktop version.
   Then the configuration can be invoked using the -c parameter. 
   linphonec -c ~/.config/linphone/linphonerc

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


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

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
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 linphone-cli depends on:
ii  bind9-host [host]   1:9.16.37-1~deb11u1
ii  libbctoolbox1   4.4.13-2
ii  libc6   2.31-13+deb11u5
ii  libgcc-s1   10.2.1-6
ii  liblinphone10   4.4.21-2
ii  libmediastreamer11  1:4.4.21-3
ii  libortp15   1:4.4.13-2
ii  libstdc++6  10.2.1-6
ii  linphone-common 4.4.21-2

linphone-cli recommends no packages.

linphone-cli suggests no packages.

-- no debconf information

- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
https://en.wikibooks.org/wiki/User:PeterEasthope

Bug#1032050: ITP: cryptacular -- high level, general purpose Java cryptographic library

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org, 
j...@nahmias.net, cryptacu...@googlegroups.com
Control: -1 blocks 1031807

* Package name: cryptacular
  Version : 1.2.5
  Upstream Authors: Daniel Fisher , Marvin S. Addison 

* URL : https://www.cryptacular.org/
* License : Apache-2.0 OR LGPL-3.0
  Programming Lang: Java
  Description : high level, general purpose Java cryptographic library

 General-purpose Java cryptograhic library, which complements the Bouncy
 Castle libraries, that has the following design goals:
 .
  * Flexible JCE provider. Prefers the Bouncy Castle Java Provider, but
can fall back to other providers defined in the environment for
algorithms not implemented by BC.
  * Ease of use for common cryptographic operations. A one liner
highlights this well; the following prints the MD5 hash of a password
as a string of HEX characters:
System.out.println(new MD5().digest(passBytes, new HexConverter()));
  * Convenient and performant handling of cryptographic operations on
large data streams.
  * Support for base-64 and hexadecimal encoding of ciphertext input/output.
  * Support for I/O operations on cryptographic primitives including
generating and writing symmetric encryption keys, public/private key
pairs, and X.509 certificates. Both PEM and DER encoding is handled
conveniently.
  * Command line interface for each class of cryptographic operation
(digest, symmetric encryption, public-key encryption, message signing,
etc). A command line interface for keystore operations is also
included, which is notable as it supports features above and beyond
the the Java keytool utility.
 .
 It is important to note that no cryptographic algorithms are implemented;
 Bouncy Castle provides all cryptographic algorithms where required.

Bug#1032049: knot-resolver: Unable to enable HTTP module

[Andrew]

Package: knot-resolver
Version: 5.3.1-1+deb11u1
Severity: normal
X-Debbugs-Cc: and...@lists.savchenko.net

Dear Maintainer,

HTTP module in knot-resolver can't be enabled by adding `http` directive
in its config file.

I have  tried the separate `modules.load('http')` statement via
config and control socket / `kresc`, but to no avail.

`kresd.conf` attached below. While `kresc` reports that the module is
loaded, no new port is opened and stats can't be fetched via `curl`.

`stats.list()` works as expected, this confirms that there is a valid
data to expose via http.


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-20-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages knot-resolver depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  dns-root-data  2021011101
ii  libc6  2.31-13+deb11u5
ii  libdnssec8 3.0.5-1+deb11u1
ii  libedit2   3.1-20191231-2+b1
ii  libfstrm0  0.6.0-1+b1
ii  libgcc-s1  10.2.1-6
ii  libgnutls303.7.1-5+deb11u3
ii  libknot11  3.0.5-1+deb11u1
ii  liblmdb0   0.9.24-1
ii  libluajit-5.1-22.1.0~beta3+dfsg-5.3
ii  libnghttp2-14  1.43.0-1
ii  libprotobuf-c1 1.3.3-1+b2
ii  libstdc++6 10.2.1-6
ii  libsystemd0247.3-7+deb11u1
ii  libuv1 1.40.0-2
ii  libzscanner3   3.0.5-1+deb11u1
ii  lua-sec1.0-1
ii  lua-socket 3.0~rc1+git+ac3201d-4

Versions of packages knot-resolver recommends:
ii  knot-resolver-module-http  5.3.1-1+deb11u1
ii  lua-basexx 0.3-2.1
ii  lua-cqueues20200726-1

knot-resolver suggests no packages.

-- Configuration Files:
/etc/default/kresd [Errno 13] Permission denied: '/etc/default/kresd'
/etc/knot-resolver/kresd.conf changed:
-- Listen locally, ipv4-only
net = { '127.0.0.1' }
net.ipv6 = false

-- Enable optional modules
modules = {
  'policy',  -- NXDOMAIN "bad" queries
  'hints',   -- read /etc/hosts and whatever is defined below
  'stats',   -- internal statistics
  'serve_stale < cache', -- serve stale record if parent NS is unreachable
  'rebinding < iterate', -- prevent rebinding attack, TODO: Remove?..
  'prefill',
  'predict',
  'view',
  http = {
host = '127.0.0.1',
port = 8053
  }
}

-- Accept exclusively from localhost
view:addr('127.0.0.1/8', function (req, qry) return policy.PASS end)
view:addr('0.0.0.0/0', function (req, qry) return policy.DROP end)

-- Block Firefox DoH
policy.add(policy.suffix(policy.DENY, {todname('use-application-dns.net')}))

-- Add blocked hosts, reload on file change
-- MUST be in a special .RPZ format
-- https://knot-resolver.readthedocs.io/en/stable/modules-policy.html#policy.rpz
policy.add(policy.rpz(policy.DENY, '/etc/knot-resolver/black.rpz'))
policy.add(policy.rpz(policy.DENY, '/etc/knot-resolver/blacklist-fgs.txt'))

-- DNS-over-TLS
policy.add(policy.all(policy.TLS_FORWARD({
  {'9.9.9.9', hostname='dns.quad9.net'},
  {'149.112.112.112', hostname='dns.quad9.net'},
  {'1.1.1.1', hostname='1dot1dot1dot1.cloudflare-dns.com'},
  {'1.0.0.1', hostname='one.one.one.one'}
})))

-- DNS-over-UDP
-- policy.add(policy.all(policy.FORWARD({'9.9.9.9', '1.1.1.1'})))

--- Root zone preload
prefill.config({
  ['.'] = {
url = 'https://www.internic.net/domain/root.zone',
ca_file = '/etc/ssl/certs/ca-certificates.crt',
interval = 86400  -- 24h
  }
})

-- Cache config
cache.size = 32 * MB
cache.max_ttl(172800) -- 48h
cache.min_ttl(60) -- 1m

--- Prefetch learning (15-minute blocks over 24 hours)
predict.config({
  window = 15, -- 15 minutes sampling window
  period = 24*(60/15)  -- track last 24 hours
})

-- debconf-show failed

Bug#1028725: flycheck: FTBFS: make: *** [debian/rules:4: binary] Error 25

[Sergio Durigan Junior]

On Sunday, February 26 2023, I wrote:

> On Sunday, February 26 2023, I wrote:
>
>> On Saturday, February 25 2023, I wrote:
>>
>>> On Monday, February 20 2023, David Bremner wrote:
>>>
 David Bremner  writes:

> I don't think these are the same as previously encountered
> native-compilation related failures. I get the same / similar failures
> when running
>
> EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t emacs -q -batch -L . -l 
> buttercup -f buttercup-run-discover
>
> as a non-root user with a defined home directory. Log is attached (there
> is one more failure in the log, iiuc related to gpg missing in the
> chroot).

 With the latest upstream master (32-182-g5561440) which contains the
 merge of PR 2002, this is down to 2 failures, both trampoline related.
>>>
>>> Very similar failures are also affecting emacs-web-server:
>>>
>>>   
>>> https://ci.debian.net/data/autopkgtest/unstable/amd64/e/emacs-web-server/31076037/log.gz
>>>
>>> I suspected the problem could be related to emacs-buttercup, so I
>>> updated it locally to the latest upstream version and rebuilt flycheck
>>> with it, to no avail.
>>
>> I spent some more time investigating this problem and was able to
>> pinpoint it to the fact that, for some reason, this problem happens when
>> you have two (spy-on) calls and the first one uses :and-return-value,
>> which is the case here.
>>
>> I'm not sure this is a bug with buttercup, but I filed an upstream bug
>> with them just in case:
>>
>>   https://github.com/jorgenschaefer/emacs-buttercup/issues/230
>
> The following incantation makes the testsuite pass for me:
>
>   buttercup --eval "(setq native-comp-enable-subr-trampolines nil)" -L .

I was testing with an upstream build.  For Debian's Emacs, we should
use:

  buttercup --eval "(setq comp-enable-subr-trampolines nil)" -L .

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1028725: flycheck: FTBFS: make: *** [debian/rules:4: binary] Error 25

[Sergio Durigan Junior]

On Sunday, February 26 2023, I wrote:

> On Saturday, February 25 2023, I wrote:
>
>> On Monday, February 20 2023, David Bremner wrote:
>>
>>> David Bremner  writes:
>>>
 I don't think these are the same as previously encountered
 native-compilation related failures. I get the same / similar failures
 when running

 EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t emacs -q -batch -L . -l 
 buttercup -f buttercup-run-discover

 as a non-root user with a defined home directory. Log is attached (there
 is one more failure in the log, iiuc related to gpg missing in the
 chroot).
>>>
>>> With the latest upstream master (32-182-g5561440) which contains the
>>> merge of PR 2002, this is down to 2 failures, both trampoline related.
>>
>> Very similar failures are also affecting emacs-web-server:
>>
>>   
>> https://ci.debian.net/data/autopkgtest/unstable/amd64/e/emacs-web-server/31076037/log.gz
>>
>> I suspected the problem could be related to emacs-buttercup, so I
>> updated it locally to the latest upstream version and rebuilt flycheck
>> with it, to no avail.
>
> I spent some more time investigating this problem and was able to
> pinpoint it to the fact that, for some reason, this problem happens when
> you have two (spy-on) calls and the first one uses :and-return-value,
> which is the case here.
>
> I'm not sure this is a bug with buttercup, but I filed an upstream bug
> with them just in case:
>
>   https://github.com/jorgenschaefer/emacs-buttercup/issues/230

The following incantation makes the testsuite pass for me:

  buttercup --eval "(setq native-comp-enable-subr-trampolines nil)" -L .

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

[Jussi Pakkanen]

On Sun, 26 Feb 2023 at 21:39, Helmut Grohne  wrote:

> Given that, I think you can move forward with the change post bookworm.
> Thanks for bearing with me and sorry for the inadequate remarks.

I filed an MR upstream with all changes that should go in the next
release (which is to say they won't make it to bookworm):

https://github.com/mesonbuild/meson/pull/11464

I also uploaded a new version to experimental that removes the test
patch and adds the ppc64 patch to debcrossgen. If people want to do
test it, go ahead, but after a few days I'll reupload that to
unstable. That will be the final version in bookworm unless major bugs
are found.

Bug#981156: dkimpy-milter: issues in sign-vs-verify logic (and documentation)

[Scott Kitterman]

On Tue, 26 Jan 2021 21:47:42 -0800 Michel Lespinasse  
wrote:
> Package: dkimpy-milter
> Version: 1.2.1-1~bpo10+1
> Severity: normal
> 
> 
> I have been encountering issues trying to configure the sign-vs-verify
> logic in dkimpy-milter. Some of it comes down to confusing documentation,
> but it also appears that the behavior I want can not be configured.
> 
> I would like the sign-vs-verify logic to behave similarly to the
> smtpd_relay_restrictions rules in my postfix configuration:
> - any email coming from local networks (local sendmail, localhost smtpd,
> or 10.0.0.0/8 smtpd) should be signed,
> - any email coming from other sources should be verified.
> 
> 
> Reading the documentation, it seems that setting InternalHosts should work,
> but this doesn't seem to be the case:
> 
> In dkimMilter.connect(),
> - self.internal_connection is set if the connection comes from an address 
matching InternalHosts, or if the milter macros match MacroList.
> - self.external_connection is set if the milter macros match MacroListVerify
> 
> In dkimMilter.eom():
> - self.external_connection disables signing
> - self.internal_connection disables verifying
> 
> Therefore, MacroListVerify ends up controllinjg signing (despite what
> the name implies!), and MacroList ends up controlling verifying
> (despite what the documentation says about it). Additionally, for a
> smtpd milter receiving mail from both internal and external
> connections, it is not possible to control signing based on the
> InternalHosts value.
> 
> 
> My wishes for resolving this bug are:
> 1- There should be a way to control signing based on the originating
> connection's IP address;
> 2- It would be nice for the documentation to explain how the
> MacroList, MacroListVerify and InternalHosts values interact to
> determine wether we are dealing with an internal/trusted or
> external/untrusted connection (right now the values are only described
> separately and the interactions are not documented in any way);
> 3- I am not sure if there are any reasons for connections to be marked as
> both internal and external at once, or to have neither markings - if there
> are valid reasons for that, the documentation should explain them; if not
> maybe the milter should emit a warning when incorrectly configured...
> 4- The interaction between Mode and internal vs external connections
> should be documented (i.e. that Mode=s still only signs internal
> connections, and Mode=v still only verifies external connections).
> 
> 
> Sorry for the long winded report, hope it is at least clear enough :)

Thanks.  I agree it's a bit of a mess.

The theory is that a connection identified as "internal" should only sign, not 
verify and a connection that's identified as "external" should only verify and 
not sign.

Currently the code will identify a connection as "internal" if it is in 
IntHosts or libmilter provides the macro in "MacroList".  

The code will identify a connection as "external" if the MacroListVerify macro 
is provided.

If it's not an "external" connection and the mode is s or sv, it will sign.

If it's not an "internal" connection and the mode is v or sv, DKIM will be 
verified.

If it's not "internal" or "external" (i.e.IntHosts not set and neither 
MacroLIst or MacroLIstVerify provided), then the Mode (v, s, or sv) controls 
exclusively.

I agree this could be better documented and I had to look at the code to try t 
figure it out again.  I don't think both internal and external would every be 
set, but neither being set is appropriate if there aren't any macros provided 
and it's not covered by IntHosts.

Scott K

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

Bug#987008: grub2: diff for NMU version 2.06-8.1

[anarcat]

Control: tags 987008 + pending

Dear maintainer,

I've prepared an NMU for grub2 (versioned as 2.06-8.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Note that the package was uploaded to *experimental*, not unstable, as
an extra precaution. Let me know if you will followup with an unstable
update or I should.

A copy of the package is also available at:

https://people.debian.org/~anarcat/debian/sid/grub2_2.06-8.1_amd64.changes

(and yes, I am aware this makes it possible to bypass the DELAYED queue,
which is partly why it's targeting experimental.)

Regards.

a.
diff -Nru grub2-2.06/debian/changelog grub2-2.06/debian/changelog
--- grub2-2.06/debian/changelog	2023-02-08 20:09:00.0 -0500
+++ grub2-2.06/debian/changelog	2023-02-25 15:16:55.0 -0500
@@ -1,3 +1,11 @@
+grub2 (2.06-8.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix an issue where a logical volume rename would lead grub to fail to
+boot (Closes: #987008)
+
+ -- Antoine Beaupré   Sat, 25 Feb 2023 15:16:55 -0500
+
 grub2 (2.06-8) unstable; urgency=medium
 
   [ Steve McIntyre ]
diff -Nru grub2-2.06/debian/patches/987008-lvrename-boot-fail.patch grub2-2.06/debian/patches/987008-lvrename-boot-fail.patch
--- grub2-2.06/debian/patches/987008-lvrename-boot-fail.patch	1969-12-31 19:00:00.0 -0500
+++ grub2-2.06/debian/patches/987008-lvrename-boot-fail.patch	2023-02-25 15:16:55.0 -0500
@@ -0,0 +1,35 @@
+Description: fix renamed LV detection
+  It looks like the detection of the LVM logical volumes fails in
+  certain edge conditions. In particular, it was reported that
+  renaming an LV will make grub fail to boot from the system as it
+  cannot properly detect it anymore.
+  .
+  I have looked at the code surrounding the patch and cannot claim to
+  understand the entire function here, as it is huge and quite
+  cryptic. But it seems sane: the `ptr` we're inspecting here starts
+  at the `rlocn->offset`, but we were adding `mda_size` to the
+  (somewhat) unrelated metadatabuf instead. Now we're marking the
+  `mda_end` correctly, based on the rlocn->offsite and ->size.
+  .
+  I have not tested this myself as the test setup is quite involved,
+  but it seems others (e.g. "Hoyer, David" )
+  have tested the patch and confirmed it worked.
+Author: Rogier 
+Origin: other
+Bug: https://savannah.gnu.org/bugs/index.php?61620
+Bug-Debian: https://bugs.debian.org/987008
+Forwarded: https://savannah.gnu.org/bugs/index.php?61620
+Reviewed-By: Antoine Beaupré
+Last-Update: 2023-02-25
+
+--- grub2-2.06.orig/grub-core/disk/lvm.c
 grub2-2.06/grub-core/disk/lvm.c
+@@ -290,7 +290,7 @@ grub_lvm_detect (grub_disk_t disk,
+ 
+   p = q = (char *)ptr;
+ 
+-  if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_size, ))
++  if (grub_add (ptr, (grub_size_t)grub_le_to_cpu64 (rlocn->size), ))
+ goto error_parsing_metadata;
+ 
+   mda_end = (char *)ptr;
diff -Nru grub2-2.06/debian/patches/series grub2-2.06/debian/patches/series
--- grub2-2.06/debian/patches/series	2023-02-08 20:09:00.0 -0500
+++ grub2-2.06/debian/patches/series	2023-02-25 15:09:36.0 -0500
@@ -114,3 +114,4 @@
 grub_mkconfig_restore_umask.patch
 ignore_checksum_seed_incompat_feature.patch
 ignore_the_large_dir_incompat_feature.patch
+987008-lvrename-boot-fail.patch


signature.asc
Description: PGP signature

Bug#987008: grub LVM bug #987008: experimental package available, please test

[Antoine Beaupré]

Hi everyone,

I have uploaded a NMU of this package in experimental, with a 2-days
delayed to give the maintainers here time to respond... Considering the
importance of grub, i figured it was safer that way.

A copy of the package is also available here:

https://people.debian.org/~anarcat/debian/sid/

You should be able to get a cryptographically verified binary package using:

dget https://people.debian.org/~anarcat/debian/sid/grub2_2.06-8.1_amd64.changes

I would be grateful if someone could test the resulting package in their
environments and do some smoke tests on the conditions of this bug
report. I haven't had the leisure to reproduce the test harness nor the
bug, so I rely on you to confirm the package actually fixes this
properly.

Once I get confirmation, this can be re-uploaded into unstable directly,
which should fix the bug in bookworm (eventually).

Thank you for your time,

a.

-- 
It is better to sit alone than in company with the bad; and it is better
still to sit with the good than alone. It better to speak to a seeker of
knowledge than to remain silent; but silence is better than idle words.
- Imam Bukhari


signature.asc
Description: PGP signature

Bug#1032048: d3-dsv-tools: Dangling symlinks in /usr/bin/

[Axel Beckert]

Package: d3-dsv-tools
Version: 1.1.1-8
Severity: grave
Justification: renders package unusable

$ symlinks -tv /usr/bin* | fgrep dangling
dangling: /usr/bin/csv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js
dangling: /usr/bin/csv2tsv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js
dangling: /usr/bin/dsv2dsv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js
dangling: /usr/bin/json2csv -> ../share/nodejs/d3-dsv/bin/json2dsv.js
dangling: /usr/bin/json2dsv -> ../share/nodejs/d3-dsv/bin/json2dsv.js
dangling: /usr/bin/tsv2csv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js
dangling: /usr/bin/json2tsv -> ../share/nodejs/d3-dsv/bin/json2dsv.js
dangling: /usr/bin/dsv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js
dangling: /usr/bin/tsv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js

Looking at where those files actually might be, I figured that the
symlinks probably should point to the same target without the .js
suffix — or that those files need to be renamed:

/usr/share/nodejs/d3-dsv/bin/dsv2dsv
/usr/share/nodejs/d3-dsv/bin/dsv2json
/usr/share/nodejs/d3-dsv/bin/json2dsv

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (600, 'testing')
merged-usr: yes
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages d3-dsv-tools depends on:
ii  node-d3-dsv  1.1.1-8
ii  nodejs   18.13.0+dfsg1-1

d3-dsv-tools recommends no packages.

d3-dsv-tools suggests no packages.

-- no debconf information

Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.

[Steven]

Package: mariadb-server
Version: 1:10.11.2-1
Severity: normal
X-Debbugs-Cc: steven.dehe...@gmail.com

Dear Maintainer,

I tried to upgrade mariadb-server-10.6 to mariadb-server 10.11.2-1, but it
failed with these errors (part of aptitude's output):

"""
Preparing to unpack .../mysql-common_5.8+1.1.0_all.deb ...
Unpacking mysql-common (5.8+1.1.0) over (5.8+1.0.8) ...
Preparing to unpack .../mariadb-common_1%3a10.11.2-1_all.deb ...
Unpacking mariadb-common (1:10.11.2-1) over (1:10.6.11-2) ...
Preparing to unpack .../default-mysql-server_1.1.0_all.deb ...
Unpacking default-mysql-server (1.1.0) over (1.0.8) ...
(Reading database ... 331692 files and directories currently installed.)
Removing mariadb-server-10.6 (1:10.6.11-2) ...
dpkg: mariadb-server-core-10.6: dependency problems, but removing anyway as you 
requested:
 akonadi-backend-mysql depends on default-mysql-server-core | 
virtual-mysql-server-core; however:
  Package default-mysql-server-core is not installed.
  Package virtual-mysql-server-core is not installed.
  Package mariadb-server-core-10.6 which provides virtual-mysql-server-core is 
to be removed.

Removing mariadb-server-core-10.6 (1:10.6.11-2) ...
dpkg: warning: while removing mariadb-server-core-10.6, directory 
'/usr/share/mysql' not empty so not removed
Selecting previously unselected package mariadb-server-core.
(Reading database ... 331482 files and directories currently installed.)
Preparing to unpack .../mariadb-server-core_1%3a10.11.2-1_amd64.deb ...
Unpacking mariadb-server-core (1:10.11.2-1) ...
Preparing to unpack .../libmariadb3_1%3a10.11.2-1_amd64.deb ...
Unpacking libmariadb3:amd64 (1:10.11.2-1) over (1:10.6.11-2) ...
Preparing to unpack .../default-mysql-client_1.1.0_all.deb ...
Unpacking default-mysql-client (1.1.0) over (1.0.8) ...
dpkg: mariadb-client-10.6: dependency problems, but removing anyway as you 
requested:
 wordpress depends on default-mysql-client | virtual-mysql-client; however:
  Package default-mysql-client is not configured yet.
  Package virtual-mysql-client is not installed.
  Package mariadb-client-10.6 which provides virtual-mysql-client is to be 
removed.
  Package mariadb-client-10.5 which provides virtual-mysql-client is not 
installed.
  Package mariadb-client-10.3 which provides virtual-mysql-client is not 
installed.
 dbconfig-mysql depends on default-mysql-client | virtual-mysql-client; however:
  Package default-mysql-client is not configured yet.
  Package virtual-mysql-client is not installed.
  Package mariadb-client-10.6 which provides virtual-mysql-client is to be 
removed.
  Package mariadb-client-10.5 which provides virtual-mysql-client is not 
installed.
  Package mariadb-client-10.3 which provides virtual-mysql-client is not 
installed.

(Reading database ... 331590 files and directories currently installed.)
Removing mariadb-client-10.6 (1:10.6.11-2) ...
dpkg: mariadb-client-core-10.6: dependency problems, but removing anyway as you 
requested:
 default-mysql-client-core depends on mariadb-client-core-10.6.

Removing mariadb-client-core-10.6 (1:10.6.11-2) ...
Selecting previously unselected package mariadb-client-core.
(Reading database ... 331476 files and directories currently installed.)
Preparing to unpack .../mariadb-client-core_1%3a10.11.2-1_amd64.deb ...
Unpacking mariadb-client-core (1:10.11.2-1) ...
Preparing to unpack .../default-mysql-client-core_1.1.0_all.deb ...
Unpacking default-mysql-client-core (1.1.0) over (1.0.8) ...
Selecting previously unselected package mariadb-client.
Preparing to unpack .../mariadb-client_1%3a10.11.2-1_amd64.deb ...
Unpacking mariadb-client (1:10.11.2-1) ...
Setting up mysql-common (5.8+1.1.0) ...
Setting up mariadb-common (1:10.11.2-1) ...
Selecting previously unselected package mariadb-server.
(Reading database ... 331590 files and directories currently installed.)
Preparing to unpack .../00-mariadb-server_1%3a10.11.2-1_amd64.deb ...
/var/lib/mysql: found previous version 10.6
Failed to stop mariadb.service: Unit mariadb.service not loaded.
invoke-rc.d: initscript mariadb, action "stop" failed.
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
Attempt to stop MariaDB/MySQL server returned exitcode 5
There is a MariaDB/MySQL server running, but we failed in our attempts to stop 
it.
Stop it yourself and try again!
dpkg: error processing archive 
/tmp/apt-dpkg-install-qINyMU/00-mariadb-server_1%3a10.11.2-1_amd64.deb 
(--unpack):
 new mariadb-server package pre-installation script subprocess returned error 
exit status 1
"""

So if I understand correctly, at the moment of unpacking the new mariadb-server,
there is no system-wide mariadb.service running or indeed any *.service file 
present, but I did have akonadiserver running which spawns its own mysqld 
process.  Thus the stop_server function in preinst fails as it does detect a 
mysql process but 'invoke-rc.d mariadb stop' gives an error.

When I manually stopped akonadi's mariadb 

Bug#1029720: [Pkg-nagios-devel] Bug#1029720: monitoring-plugins-contrib: false positive w bookworm kernel: "running kernel does not match on-disk kernel image'

[Hilmar Preuße]

Am 26.01.2023 um 17:41 teilte Holger Levsen mit:

Hi,


on a system running bookworm and the latest amd64 kernel
/usr/lib/nagios/plugins/check_running_kernel warns me that the running kernel 
doesnt
match the on-disk kernel, while it *is* running the latest kernel.
(line breaks added for better readability.)


In the moment I'm trying to understand how the script works. My current
state is: it checks, which compression mode is used, for the kernel
images in /boot/ (which seems to be xz for bookworm), then it
decompresses the xz compressed part of the kernel images and searches
for "Linux version". The part after "Linux version" is compared to the
content of /proc/version. Unfortunately there is a difference:

/boot/vmlinuz:

Linux version 6.1.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-12
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP
PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15)

/proc/version

Linux version 6.1.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-12
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP
PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15)

So it could be a bug in the kernel configuration too. All this worked
fine on Debian stable. I did not check if there was another compression
method in use.

I could not dig further, I failed to extract the xz compressed part of
the kernel correctly. Not sure if this is useful.

Hilmar
--
sigfault

Bug#1032042: linux: gpio in falling-edge mode returns both falling /and/ rising edge events and /both/ are tagged as falling [Raspberry Pi Zero W, usb-host]

[наб]

Control: found -1 6.0.12-1~bpo11+1
Control: found -1 6.1.12-1

Tried both of the above (bullseye-backports and sid) to the same effect.

Journals from both attached, but I don't really see anything in there.

I can, naturally, work around this in software, but this is either a
linux or BCM2835 bug, presumably, so idk. Please advise :)

Best,
наб
-- Journal begins at Sun 2022-08-07 15:25:18 CEST, ends at Sun 2023-02-26 
23:52:38 CET. --
Aug 07 15:25:18 ciastko-malinowe kernel: Booting Linux on physical CPU 0x0
Aug 07 15:25:18 ciastko-malinowe kernel: Linux version 6.0.0-0.deb11.6-rpi 
(debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU 
ld (GNU Binutils for Debian) 2.35.2) #1 Debian 6.0.12-1~bpo11+1 (2022-12-19)
Aug 07 15:25:18 ciastko-malinowe kernel: CPU: ARMv6-compatible processor 
[410fb767] revision 7 (ARMv7), cr=00c5387d
Aug 07 15:25:18 ciastko-malinowe kernel: CPU: PIPT / VIPT nonaliasing data 
cache, VIPT nonaliasing instruction cache
Aug 07 15:25:18 ciastko-malinowe kernel: OF: fdt: Machine model: Raspberry Pi 
Zero W Rev 1.1
Aug 07 15:25:18 ciastko-malinowe kernel: Memory policy: Data cache writeback
Aug 07 15:25:18 ciastko-malinowe kernel: Reserved memory: bypass linux,cma 
node, using cmdline CMA params instead
Aug 07 15:25:18 ciastko-malinowe kernel: OF: reserved mem: node linux,cma 
compatible matching fail
Aug 07 15:25:18 ciastko-malinowe kernel: cma: Reserved 64 MiB at 0x1740
Aug 07 15:25:18 ciastko-malinowe kernel: Zone ranges:
Aug 07 15:25:18 ciastko-malinowe kernel:   Normal   [mem 
0x-0x1bff]
Aug 07 15:25:18 ciastko-malinowe kernel: Movable zone start for each node
Aug 07 15:25:18 ciastko-malinowe kernel: Early memory node ranges
Aug 07 15:25:18 ciastko-malinowe kernel:   node   0: [mem 
0x-0x1bff]
Aug 07 15:25:18 ciastko-malinowe kernel: Initmem setup node 0 [mem 
0x-0x1bff]
Aug 07 15:25:18 ciastko-malinowe kernel: pcpu-alloc: s0 r0 d32768 u32768 
alloc=1*32768
Aug 07 15:25:18 ciastko-malinowe kernel: pcpu-alloc: [0] 0 
Aug 07 15:25:18 ciastko-malinowe kernel: Built 1 zonelists, mobility grouping 
on.  Total pages: 113680
Aug 07 15:25:18 ciastko-malinowe kernel: Kernel command line: 
video=Composite-1:720x480@60i,margin_left=32,margin_right=32,margin_top=32,margin_bottom=32
 dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x10797d77 
bcm2708.uart_clock=4800 bcm2708.disk_led_gpio=47 
smsc95xx.macaddr=B8:27:EB:79:7D:77 vc_mem.mem_base=0x1ec0 
vc_mem.mem_size=0x2000  console=tty0 root=LABEL=RASPIROOT ro 
fsck.repair=yes net.ifnames=0 cma=64M rootwait
Aug 07 15:25:18 ciastko-malinowe kernel: Dentry cache hash table entries: 65536 
(order: 6, 262144 bytes, linear)
Aug 07 15:25:18 ciastko-malinowe kernel: Inode-cache hash table entries: 32768 
(order: 5, 131072 bytes, linear)
Aug 07 15:25:18 ciastko-malinowe kernel: mem auto-init: stack:off, heap 
alloc:on, heap free:off
Aug 07 15:25:18 ciastko-malinowe kernel: Memory: 363196K/458752K available 
(8192K kernel code, 1017K rwdata, 2272K rodata, 1024K init, 315K bss, 30020K 
reserved, 65536K cma-reserved)
Aug 07 15:25:18 ciastko-malinowe kernel: SLUB: HWalign=32, Order=0-3, 
MinObjects=0, CPUs=1, Nodes=1
Aug 07 15:25:18 ciastko-malinowe kernel: ftrace: allocating 29066 entries in 86 
pages
Aug 07 15:25:18 ciastko-malinowe kernel: ftrace: allocated 86 pages with 4 
groups
Aug 07 15:25:18 ciastko-malinowe kernel: trace event string verifier disabled
Aug 07 15:25:18 ciastko-malinowe kernel: NR_IRQS: 16, nr_irqs: 16, preallocated 
irqs: 16
Aug 07 15:25:18 ciastko-malinowe kernel: sched_clock: 32 bits at 1000kHz, 
resolution 1000ns, wraps every 2147483647500ns
Aug 07 15:25:18 ciastko-malinowe kernel: clocksource: timer: mask: 0x 
max_cycles: 0x, max_idle_ns: 1911260446275 ns
Aug 07 15:25:18 ciastko-malinowe kernel: bcm2835: system timer (irq = 27)
Aug 07 15:25:18 ciastko-malinowe kernel: Console: colour dummy device 80x30
Aug 07 15:25:18 ciastko-malinowe kernel: printk: console [tty0] enabled
Aug 07 15:25:18 ciastko-malinowe kernel: Calibrating delay loop... 697.34 
BogoMIPS (lpj=1394688)
Aug 07 15:25:18 ciastko-malinowe kernel: pid_max: default: 32768 minimum: 301
Aug 07 15:25:18 ciastko-malinowe kernel: LSM: Security Framework initializing
Aug 07 15:25:18 ciastko-malinowe kernel: landlock: Up and running.
Aug 07 15:25:18 ciastko-malinowe kernel: Yama: disabled by default; enable with 
sysctl kernel.yama.*
Aug 07 15:25:18 ciastko-malinowe kernel: AppArmor: AppArmor initialized
Aug 07 15:25:18 ciastko-malinowe kernel: LSM support for eBPF active
Aug 07 15:25:18 ciastko-malinowe kernel: Mount-cache hash table entries: 1024 
(order: 0, 4096 bytes, linear)
Aug 07 15:25:18 ciastko-malinowe kernel: Mountpoint-cache hash table entries: 
1024 (order: 0, 4096 bytes, linear)
Aug 07 15:25:18 ciastko-malinowe kernel: CPU: Testing write buffer coherency: ok
Aug 07 15:25:18 ciastko-malinowe kernel: 

Bug#1030638: cp -a fails to preserve ownership information on 32-bit arches

[James Addison]

Package: fakeroot
Followup-For: Bug #1030638

Hi josch,

Are you able to confirm whether the repro environment(s) for this bugreport
used emulated and/or native (non-emulated) 32-bit systems?

To explain my question: a qemu bug[1] that I was reading about a while ago
highlights that there are some challenges emulating file-related system calls
for a 32-bit guest from a 64-bit host.

(in the situation I was looking at, that caused directory listing functions to
appear to return empty results, despite directory contents being visible on
the host.  it may not be relevant here - if repro was found on non-emulated
systems then we can ignore this theory)

Thanks,
James

[1] - https://gitlab.com/qemu-project/qemu/-/issues/263

Bug#1032046: sbuild: unshare mode uses wrong user for "Check disk space" commands when $build_user is set

[Vagrant Cascadian]

Package: sbuild
Version: 0.85.0
Severity: normal
X-Debbugs-Cc: vagr...@reproducible-builds.org

Using the following sbuild.conf:

  $chroot_mode = 'unshare';
  $build_user = 'user';

Results in this error:

  Check disk space
  

  runuser: user vagrant does not exist or the user entry does not contain all 
the required fields
  E: read_command failed to execute du
  Use of uninitialized value $current_usage in scalar chomp at 
/usr/share/perl5/Sbuild/Build.pm line 2271.
  E: du exited with non-zero exit status 256
  runuser: user vagrant does not exist or the user entry does not contain all 
the required fields
  E: read_command failed to execute du
  E: Cannot determine space needed for /<> (du failed)

If I add the following to sbuild.conf:

  $external_commands = {
"chroot-setup-commands" => [
   ['useradd', '--uid', '1000', '--user-group', '--shell', '/bin/bash', 
'--groups', 'sbuild', 'vagrant' ],
  ]};

Then it works for me, and actually builds as the user specified with
$build_user.

Seems like it should also use $build_user for the check disk space
command as well!

live well,
  vagrant

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

Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
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 sbuild depends on:
ii  adduser 3.131
ii  libsbuild-perl  0.85.0
ii  perl5.36.0-7

Versions of packages sbuild recommends:
pn  autopkgtest  
pn  debootstrap  
pn  schroot  
ii  uidmap   1:4.13+dfsg1-1

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.46.6-1
ii  kmod   30+20221128-1
ii  wget   1.21.3-1+b2

-- no debconf information

Bug#969215: dkimpy-milter: doesn't sign header fields containing Unicode

[Scott Kitterman]

On Sat, 29 Aug 2020 14:20:01 +0200 Ansgar  wrote:
> Package: dkimpy-milter
> Version: 1.2.1-1~bpo10+1
> Severity: normal
> Tags: upstream
> 
> I tried sending a mail with "From: @43-1.org", "To: @43-1.org",
> but dkimpy-milter didn't sign the message (it signs other mails) and
> the following error appeared in the log:
> 
> +---
> | dkimpy-milter[454]: DKIM: The From header field MUST be signed
> +---
> 
> If I use "From: {us-ascii-only}@43-1.org", "To: @43-1.org", then the
> DKIM-Signature exists, but doesn't cover the "To" field:
> 
> +---
> | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=43-1.org;
> |  i=@43-1.org; q=dns/txt; s=2019; t=1598699673; h=subject : mime-version
> |  : content-type : content-transfer-encoding : message-id : from : date
> |  : from; bh=UjN96cC7omIGsgVag4PTJFDc2e+vxauhwCLS/rjCqvg=;
> +---
> 
> It looks like dkimpy-milter silently discards header fields containing
> Unicode when signing.
> 
> The same might happen when verifying mails (dkimpy-milter couldn't
> verify a signature where the signed "To" field contained unicode,
> while Spamassassin's DKIM check reported DKIM_VALID; not including the
> header when verifying the signature might be a possible explaination).

This should be fixed in the next dkimpy-milter release.

Scott K

Bug#958388: dkimpy-milter: `UnicodeDecodeError` for some spam mail

[Scott Kitterman]

On Thu, 28 Oct 2021 22:51:36 -0400 David Mandelberg  
wrote:
> With dkimpy-milter 1.2.2-1, I get the same error, and I managed to 
> capture one of the emails that triggered it, see attached.
> 
> I think these are the log messages that correspond to the attached 
> email, but there were some other similar messages nearby so it's 
> possible these are for a different email:
> 
> Oct 29 01:32:00 mail-inbound-119b7863 dkimpy-milter[642]: 
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 1: 
> invalid start byte
> Oct 29 01:32:00 mail-inbound-119b7863 dkimpy-milter[642]: dkimpy-filter: 
> milter claimed not to reply in state 7 but did anyway 4

It looks like these were caused by a combination of failures in the Python 
milter binding (pymitler) and this package.  As of pymilter 1.0.5, it's fixed 
and this will at least not have failures like this in the next dkimpy-mitler 
release.

Scott K

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

Bug#1032045: tomopy: autopkgtest failure on s390x

[Adrian Bunk]

Source: tomopy
Version: 1.10.4+ds1-9
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/s390x/t/tomopy/31694525/log.gz

...
==
FAIL: test_bart 
(test_tomopy.test_recon.test_algorithm.ReconstructionAlgorithmTestCase.test_bart)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.usbhl2tu/downtmp/build.j1Q/src/test/test_tomopy/test_recon/test_algorithm.py",
 line 92, in test_bart
assert_allclose(
  File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
1592, in assert_allclose
assert_array_compare(compare, actual, desired, err_msg=str(err_msg),
  File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
   ^^^
  File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
862, in assert_array_compare
raise AssertionError(msg)
AssertionError: 
Not equal to tolerance rtol=0.01, atol=0

Mismatched elements: 16 / 18432 (0.0868%)
Max absolute difference: 6.0796738e-06
Max relative difference: 0.26425964
 x: array([[[-0.344939, -0.277677, -0.166536, ...,  0.051406, -0.012136,
 -0.053158],
[-0.259402, -0.219799, -0.031947, ...,  0.150905, -0.017446,...
 y: array([[[-0.344939, -0.277679, -0.166535, ...,  0.051409, -0.012139,
 -0.053158],
[-0.259402, -0.219799, -0.031947, ...,  0.150904, -0.017445,...
 >> begin captured logging << 
tomopy.recon.algorithm: INFO: Reconstructing 8 slice groups with 8 master 
threads...
- >> end captured logging << -

==
FAIL: test_ospml_hybrid 
(test_tomopy.test_recon.test_algorithm.ReconstructionAlgorithmTestCase.test_ospml_hybrid)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.usbhl2tu/downtmp/build.j1Q/src/test/test_tomopy/test_recon/test_algorithm.py",
 line 220, in test_ospml_hybrid
assert_allclose(
  File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
1592, in assert_allclose
assert_array_compare(compare, actual, desired, err_msg=str(err_msg),
  File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
   ^^^
  File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
862, in assert_array_compare
raise AssertionError(msg)
AssertionError: 
Not equal to tolerance rtol=0.01, atol=0

Mismatched elements: 40 / 18432 (0.217%)
Max absolute difference: 2.3543835e-06
Max relative difference: 1.0744988
 x: array([[[5.263694e-05, 1.943827e-03, 6.817912e-03, ..., 2.017710e-02,
 1.339560e-02, 8.127209e-03],
[9.065618e-05, 3.251776e-03, 1.258464e-02, ..., 3.958699e-02,...
 y: array([[[5.263694e-05, 1.943812e-03, 6.817927e-03, ..., 2.017727e-02,
 1.339539e-02, 8.127220e-03],
[9.065603e-05, 3.251777e-03, 1.258466e-02, ..., 3.958680e-02,...
 >> begin captured logging << 
tomopy.recon.algorithm: INFO: Reconstructing 8 slice groups with 8 master 
threads...
- >> end captured logging << -

==
FAIL: test_ospml_quad 
(test_tomopy.test_recon.test_algorithm.ReconstructionAlgorithmTestCase.test_ospml_quad)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.usbhl2tu/downtmp/build.j1Q/src/test/test_tomopy/test_recon/test_algorithm.py",
 line 237, in test_ospml_quad
assert_allclose(
  File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
1592, in assert_allclose
assert_array_compare(compare, actual, desired, err_msg=str(err_msg),
  File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
   ^^^
  File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
862, in assert_array_compare
raise AssertionError(msg)
AssertionError: 
Not equal to tolerance rtol=0.01, atol=0

Mismatched elements: 40 / 18432 (0.217%)
Max absolute difference: 1.8775463e-06
Max relative difference: 2.4697225
 x: array([[[5.205292e-05, 1.983037e-03, 6.971959e-03, ..., 2.034622e-02,
 1.350102e-02, 8.103064e-03],
[9.189637e-05, 3.351238e-03, 1.287083e-02, ..., 3.999370e-02,...
 y: array([[[5.206773e-05, 1.983023e-03, 6.971974e-03, ..., 2.034638e-02,
 1.350077e-02, 8.103047e-03],
[9.191120e-05, 3.351238e-03, 1.287086e-02, ..., 3.999353e-02,...
 >> begin captured logging << 
tomopy.recon.algorithm: INFO: Reconstructing 8 slice groups with 8 master 
threads...

Bug#1032044: python-fastjsonschema: autopkgtest regression

[Adrian Bunk]

Source: python-fastjsonschema
Version: 2.16.3-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-fastjsonschema/31711896/log.gz

...
 ERRORS 
__ ERROR at setup of test_benchmark_ok_values[value0] __
file 
/tmp/autopkgtest-lxc.xpfahx0d/downtmp/autopkgtest_tmp/tests/benchmarks/test_benchmark.py,
 line 50
  @pytest.mark.benchmark(min_rounds=20)
  @pytest.mark.parametrize('value', (
  [9, 'hello', [1, 'a', True], {'a': 'a', 'b': 'b', 'd': 'd'}, 42, 3],
  [9, 'world', [1, 'a', True], {'a': 'a', 'b': 'b', 'd': 'd'}, 42, 3],
  [9, 'world', [1, 'a', True], {'a': 'a', 'b': 'b', 'c': 'xy'}, 42, 3],
  [9, 'world', [1, 'a', True], {'a': 'a', 'b': 'b', 'c': 'xy'}, 'str', 5],
  ))
  def test_benchmark_ok_values(benchmark, value):
E   fixture 'benchmark' not found
>   available fixtures: asserter, cache, capfd, capfdbinary, caplog, 
> capsys, capsysbinary, doctest_namespace, monkeypatch, pytestconfig, 
> record_property, record_testsuite_property, record_xml_attribute, recwarn, 
> tmp_path, tmp_path_factory, tmpdir, tmpdir_factory
>   use 'pytest --fixtures [testpath]' for help on them.

/tmp/autopkgtest-lxc.xpfahx0d/downtmp/autopkgtest_tmp/tests/benchmarks/test_benchmark.py:50
...
=== short test summary info 
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_ok_values[value0]
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_ok_values[value1]
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_ok_values[value2]
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_ok_values[value3]
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_bad_values[value0]
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_bad_values[value1]
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_bad_values[value2]
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_bad_values[value3]
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_bad_values[value4]
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_bad_values[value5]
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_bad_values[value6]
ERROR tests/benchmarks/test_benchmark.py::test_benchmark_bad_values[value7]
= 1830 passed, 8 xfailed, 20 xpassed, 2 warnings, 12 errors in 17.96s ==
autopkgtest [15:22:21]: test smoke: ---]
autopkgtest [15:22:21]: test smoke:  - - - - - - - - - - results - - - - - - - 
- - -
smokeFAIL non-zero exit status 1
...
autopkgtest [15:22:48]:  summary
smokeFAIL non-zero exit status 1
autodep8-python3 PASS (superficial)

Bug#1032043: pylint: autopkgtest regression

[Adrian Bunk]

Source: pylint
Version: 2.16.2-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pylint/31703963/log.gz

...
=== FAILURES ===
___ test_functional[alternative_union_syntax_regession_8119] ___

self = 

def runTest(self) -> None:
>   self._runTest()
E   AssertionError: Wrong results for file 
"alternative_union_syntax_regession_8119":
E 
E Unexpected in testdata:
E   20: non-parent-init-called
E   23: access-member-before-definition
E   24: attribute-defined-outside-init
E 
E Actual pylint output for this file:
E OutputLine(symbol='non-parent-init-called', lineno=20, column=8, 
end_lineno=20, end_column=28, object='Child.__init__', msg="__init__ method 
from a non direct base class 'Coordinator' is called", confidence='UNDEFINED')
E OutputLine(symbol='access-member-before-definition', lineno=23, 
column=15, end_lineno=23, end_column=35, object='Child._async_update_data', 
msg="Access to member 'update_interval' before its definition line 24", 
confidence='UNDEFINED')
E OutputLine(symbol='attribute-defined-outside-init', lineno=24, 
column=8, end_lineno=24, end_column=28, object='Child._async_update_data', 
msg="Attribute 'update_interval' defined outside __init__", 
confidence='UNDEFINED')
E   assert Counter() == Counter({(20, 'non-parent-init-called'): 1, (23, 
'access-member-before-definition'): 1, (24, 'attribute-defined-outside-init'): 
1})
E Right contains 3 more items:
E {(20, 'non-parent-init-called'): 1,
E  (23, 'access-member-before-definition'): 1,
E  (24, 'attribute-defined-outside-init'): 1}
E Full diff:
E + Counter(,
E - Counter({(20, 'non-parent-init-called'): 1,
E -  (23, 'access-member-before-definition'): 1,
E -  (24, 'attribute-defined-outside-init'): 1},
E   )

/usr/lib/python3/dist-packages/pylint/testutils/lint_module_test.py:145: 
AssertionError
__ test_functional[wrong_exception_operation] __

self = 

def runTest(self) -> None:
>   self._runTest()
E   AssertionError: Wrong results for file "wrong_exception_operation":
E 
E Expected in testdata:
E6: catching-non-exception
E 
E Actual pylint output for this file:
E OutputLine(symbol='wrong-exception-operation', lineno=6, column=8, 
end_lineno=6, end_column=30, object='', msg="Invalid exception operation. Did 
you mean '(ValueError, TypeError)' instead?", confidence='UNDEFINED')
E OutputLine(symbol='wrong-exception-operation', lineno=11, column=8, 
end_lineno=11, end_column=30, object='', msg="Invalid exception operation. Did 
you mean '(ValueError, TypeError)' instead?", confidence='UNDEFINED')
E OutputLine(symbol='wrong-exception-operation', lineno=17, column=8, 
end_lineno=17, end_column=30, object='', msg="Invalid exception operation. Did 
you mean '(ValueError, TypeError)' instead?", confidence='UNDEFINED')
E   assert Counter({(6, 'catching-non-exception'): 1, (6, 
'wrong-exception-operation'): 1, (11, 'wrong-exception-operation'): 1, (17, 
'wrong-exception-operation'): 1}) == Counter({(6, 'wrong-exception-operation'): 
1, (11, 'wrong-exception-operation'): 1, (17, 'wrong-exception-operation'): 1})
E Common items:
E {(6, 'wrong-exception-operation'): 1,
E  (11, 'wrong-exception-operation'): 1,
E  (17, 'wrong-exception-operation'): 1}
E Left contains 1 more item:
E {(6, 'catching-non-exception'): 1}
E Full diff:
E + Counter({(6, 'catching-non-exception'): 1,
E - Counter({(6, 'wrong-exception-operation'): 1,
E ? ^
E +  (6, 'wrong-exception-operation'): 1,
E ? ^
E(11, 'wrong-exception-operation'): 1,
E(17, 'wrong-exception-operation'): 1},
E   )

/usr/lib/python3/dist-packages/pylint/testutils/lint_module_test.py:145: 
AssertionError
...
=== short test summary info 
FAILED 
tests/test_functional.py::test_functional[alternative_union_syntax_regession_8119]
FAILED tests/test_functional.py::test_functional[wrong_exception_operation]
= 2 failed, 1301 passed, 235 skipped, 18 deselected, 2 xfailed, 13 warnings in 
125.87s (0:02:05) =
E: pybuild pybuild:388: test: plugin pyproject failed with: exit code=1: cd 
/tmp/autopkgtest-lxc.95wzdhnm/downtmp/autopkgtest_tmp/build; python3.11 -m 
pytest - -k 'not test_pkginfo and not 
test_do_not_import_files_from_local_directory and not 
test_import_plugin_from_local_directory_if_pythonpath_cwd and not 
test_can_list_directories_without_dunder_init and not test_fail_on_exit_code 
and not test__test_environ_pythonpath_no_arg and not 

Bug#1031943: [pkg-netfilter-team] Bug#1031943: ebtables: symlink removal removal code in the postinst does not seem to be working

[Alberto Molina Coballes]

Hi Adrian and Jeremy,

I was trying to reproduce the bug when I've read the reply from
Jeremy, but like Jeremy I've not been able to reproduce it in sid
(with or without merged usr).

The change you propose is perfect (I agree it should be "-h" instead
of "-e" for the test to check if the symlink exists), but it'd be good
to have additional information to reproduce the bug and fix it
properly.

Can you please provide more information about the bug?

Thanks!
Alberto

Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.

[Andres Salomon]

Hi,

I'm a bit confused by this bug report, as chromium doesn't include any 
apparmor profiles.


Please run the following commands to hopefully figure out what package 
is actually providing the profile:


find /etc/apparmor* -name "*hromium*" | xargs dpkg -S

Thanks,
Andres

On Sun, Feb 26 2023 at 05:48:38 PM +0100, Will B.  
wrote:

Package: chromium
Version: 110.0.5481.177-1
Severity: important
Tags: upstream
X-Debbugs-Cc: ksu...@gmail.com

Dear Maintainer,

Before I begin, the Chromium AppArmor profile in Sid was updated 
after apt-get

update && apt-get upgrade.
Please redirect to relevant authority if Chromium reportbug is not 
the right

source.

   ///

* What led up to the situation? -> Chromium AppArmor profile update 
after apt-

get update && apt-get upgrade.
* What exactly did you do (or not do) that was effective (or 
ineffective)? ->

fixed the issue by adding a missing "/" to the profile.
* What was the outcome of this action? -> The Chromium AppArmor 
profile

restricted access as it should have done.
* What outcome did you expect instead? -> None, fix fixed it.

  ///

Hi,

After a Chromium Sid update in which the AppArmor profile was updated 
(last

date -> 02/07/2023),
a missing "/" opened up browsing to the whole system i.e. -> "/** r," 
instead

of "/**/ r,".
Switching to the "enclosed" stars symbol fixes the issue.

Regards


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

Kernel: Linux 6.1.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

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

Versions of packages chromium depends on:
ii  chromium-common  
110.0.5481.177-1

ii  libasound2   1.2.8-1+b1
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libatomic1   12.2.0-14
ii  libatspi2.0-02.46.0-5
ii  libbrotli1   1.0.9-2+b6
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libcups2 2.4.2-1+b2
ii  libdbus-1-3  1.14.6-1
ii  libdouble-conversion33.2.1-1
ii  libdrm2  2.4.114-1
ii  libevent-2.1-7   
2.1.12-stable-5+b1

ii  libexpat12.5.0-1
ii  libflac121.4.2+ds-2
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libgbm1  22.3.3-1
ii  libgcc-s112.2.0-14
ii  libglib2.0-0 2.74.5-1
ii  libgtk-3-0   3.24.36-4
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjsoncpp25 1.9.5-4
ii  liblcms2-2   2.14-1+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libopenjp2-7 2.5.0-1+b1
ii  libopus0 1.3.1-3
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpng16-16  1.6.39-2
ii  libpulse0
16.1+dfsg1-2+b1
ii  libre2-9 
20220601+dfsg-1+b1

ii  libsnappy1v5 1.1.9-2
ii  libstdc++6   12.2.0-14
ii  libwebp7 1.2.4-0.1
ii  libwebpdemux21.2.4-0.1
ii  libwebpmux3  1.2.4-0.1
ii  libwoff1 1.0.2-2
ii  libx11-6 2:1.8.3-3
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxkbcommon0

Bug#1032042: linux: gpio in falling-edge mode returns both falling /and/ rising edge events and /both/ are tagged as falling [Raspberry Pi Zero W, usb-host]

[наб]

Package: linux-image-5.10.0-18-rpi
Version: 5.10.140-1
Severity: normal
Tags: upstream

Dear Maintainer,

In my application, I have hard-wired a USB device,
and would like to run the USB controller in host mode
to avoid needing the OTG ID pin.

On Foundation systems this is the default, and OTG mode is only enabled
with dtoverlay=dwc2 in config.txt; the upstream device trees, which
Debian uses, use OTG by default since
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bcc76c4014dce4e3834dbd5b7f6593cbcfbfebe0

To that end, I applied the following, effectively reverting that:
-- >8 --
$ diff -u ./arch/arm/boot/dts/bcm2835-rpi-zero-w.dts{.orig,}
--- ./arch/arm/boot/dts/bcm2835-rpi-zero-w.dts.orig 2023-02-26 
21:44:40.206721896 +0100
+++ ./arch/arm/boot/dts/bcm2835-rpi-zero-w.dts  2023-02-26 21:44:50.919200574 
+0100
@@ -6,7 +6,7 @@
 /dts-v1/;
 #include "bcm2835.dtsi"
 #include "bcm2835-rpi.dtsi"
-#include "bcm283x-rpi-usb-otg.dtsi"
+#include "bcm283x-rpi-usb-host.dtsi"

 / {
compatible = "raspberrypi,model-zero-w", "brcm,bcm2835";
-- >8 --
and built the device tree.
(I also did that to the 6.2-rc1 device tree as a test,
 and they function identically.)

This does work, inasmuch as the device is enumerated, but in my
application I also use GPIO in GPIO_V2_LINE_FLAG_INPUT |
GPIO_V2_LINE_FLAG_BIAS_PULL_UP | GPIO_V2_LINE_FLAG_EDGE_FALLING mode
(or, per lsgpio
line  5: "GPIO5" "ORNO-OR-WE-505-gpio.c" [used, input, pull-up, 
falling-edge]
line  6: "GPIO6" "ORNO-OR-WE-505-gpio.c" [used, input, pull-up, 
falling-edge]
 ).

The GPIO lines are shorted to ground temporarily, then are let float.
Please consult the following diagram w.r.t. what happens
(for simplicity, I described the pulses as 1Hz/36ms, that doesn't matter).

timelinecorrect hostboth
0s  3.3V
1s  0   falling falling falling
1s36ms  3.3Vfalling rising
2s  0   falling falling falling
2s36ms  3.3Vfalling rising

Wherein "correct" is what I observe with the upstream firmware (usb-otg),
"host"  with the usb-hostised firmware,
and "both"  with either firmware if I subscribe
to GPIO_V2_LINE_FLAG_INPUT |
GPIO_V2_LINE_FLAG_BIAS_PULL_UP |
GPIO_V2_LINE_FLAG_EDGE_FALLING |
GPIO_V2_LINE_FLAG_EDGE_RISING
("[used, input, pull-up,
   both-edges]" in lsgpio parlance)

So, in short, "in usb-host mode, when subscribed to falling edges,
both edges are returned, but labelled as falling" I guess?

Will try to update to a sid kernel and see what falls out.

Best,
наб

-- System Information:
/etc/raspi-image-id:
image based on revision: 7dcbdbc (Drop the builds for Buster, 
2021-12-06) and build on 2022-10-12 12:35 (UTC)

Raspberry Pi Zero W


signature.asc
Description: PGP signature

Bug#1032040: Acknowledgement (picard: PIcard needs authorization to import metadata from MusicBrainz server.)

[Bartek]

> Picard version 2.8.5-1_amd64 worked as intended without extra step such as
requirement to login to the service and necessity of authorization code.

Correction: should be picard version 2.8.4-1_amd64.

Regards?

Bartek

Bug#1030991: lintian: checking intel-mkl takes 18 hours

[Axel Beckert]

Control: tag -1 + confirmed

Hi Andreas,

Andreas Beckmann wrote:
> Checking intel-mkl (pre-built binaries in non-free) with lintian is very
> slow. A full build (i.e. source+all+any) on amd64 takes nearly 18 hours
> to check with
>   lintian -i -E -L ">=pedantic" -v intel-mkl_2020.4.304-4_amd64.changes
> on my local machine (8 cores, 64 GB, tmpfs on /tmp, storage on nvme).

Thanks for that bug report. Knowing such examples to test is always
good to know. Performance is one thing we managed to get much better
in the past ¾ year or so, especially thanks to Bastien. But there is
obviously (and not only known since this bug report) place for
improvement. :-)

> I don't know where all the time is spent ...

Well, 549 MB of source package... :-)

I'll check if --perf-debug brings up anything helpful. Well, yes, but
I would have gathered that otherwise, too:

Warning in processable ../libmkl-threading-dev_2020.4.304-4_amd64.deb:
MLDBM error: Second level tie failed, "No space left on device" at
/usr/share/perl5/MLDBM.pm line 144.

So, new try.

>From the output I already see that these checks took quite a while
(that's where output stopped for quite a while:

Running check: debian/control/field/rules-requires-root on 
source:intel-mkl_2020.4.304-4  ...

Running check: documentation/manual on 
binary:libmkl-meta-threading_2020.4.304-4_amd64  ...

Anyway, will wait what I get at the end. Everything with "done (0."
can be ignored. :-)

Anyway, tagging as confirmed as I can already see now that it will
take a while. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1032041: FTBFS: error: ‘size_t’ does not name a type

[Adam Borowski]

Source: arm-compute-library
Version: 20.08+dfsg-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid your package fails to build, with:

In file included from src/core/ITensorPack.cpp:24:
./arm_compute/core/ITensorPack.h:89:5: error: ‘size_t’ does not name a type
   89 | size_t size() const;
  | ^~
./arm_compute/core/ITensorPack.h:29:1: note: ‘size_t’ is defined in header 
‘’; did you forget to ‘#include ’?
   28 | #include 
  +++ |+#include 
   29 | 

Full log attached.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (490, 'testing'), (250, 'unstable'), (201, 'experimental')
merged-usr: no
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.0-3-arm64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.85.0 (04 January 2023) on rhun

+==+
| arm-compute-library (arm64)  Sat, 25 Feb 2023 23:54:14 + |
+==+

Package: arm-compute-library
Distribution: unstable
Machine Architecture: arm64
Host Architecture: arm64
Build Architecture: arm64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-arm64-sbuild-edf3fc6f-42f6-4973-91ef-878c3886c3bc'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/arm-compute-library-q3qKDi/resolver-psabH1' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'arm-compute-library' packaging is maintained in the 'Git' version 
control system at:
https://salsa.debian.org/wookey/arm-compute-library
Please use:
git clone https://salsa.debian.org/wookey/arm-compute-library
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 1941 kB of source archives.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main arm-compute-library 
20.08+dfsg-5 (dsc) [2339 B]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main arm-compute-library 
20.08+dfsg-5 (tar) [1924 kB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main arm-compute-library 
20.08+dfsg-5 (diff) [14.7 kB]
Fetched 1941 kB in 0s (27.9 MB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 
'build/arm-compute-library-q3qKDi/arm-compute-library-20.08+dfsg' with 
'<>'
I: NOTICE: Log filtering will replace 'build/arm-compute-library-q3qKDi' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 12), dh-exec (>= 0.3), scons (>= 
2.4), doxygen, graphviz, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 12), dh-exec (>= 0.3), scons (>= 
2.4), doxygen, graphviz, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [609 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [670 B]
Get:5 copy:/<>/apt_archive ./ Packages [702 B]
Fetched 1981 B in 0s (57.8 kB/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  dh-exec doxygen fontconfig fontconfig-config fonts-dejavu-core graphviz
  libabsl20220623 libann0 libaom3 libavif15 libbrotli1 libbsd0 libcairo2
  libcdt5 libcgraph6 libclang-cpp14 libclang1-14 libdatrie1 libdav1d6
  libde265-0 libdeflate0 libedit2 

Bug#1028725: flycheck: FTBFS: make: *** [debian/rules:4: binary] Error 25

[Sergio Durigan Junior]

On Saturday, February 25 2023, I wrote:

> On Monday, February 20 2023, David Bremner wrote:
>
>> David Bremner  writes:
>>
>>> I don't think these are the same as previously encountered
>>> native-compilation related failures. I get the same / similar failures
>>> when running
>>>
>>> EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t emacs -q -batch -L . -l 
>>> buttercup -f buttercup-run-discover
>>>
>>> as a non-root user with a defined home directory. Log is attached (there
>>> is one more failure in the log, iiuc related to gpg missing in the
>>> chroot).
>>
>> With the latest upstream master (32-182-g5561440) which contains the
>> merge of PR 2002, this is down to 2 failures, both trampoline related.
>
> Very similar failures are also affecting emacs-web-server:
>
>   
> https://ci.debian.net/data/autopkgtest/unstable/amd64/e/emacs-web-server/31076037/log.gz
>
> I suspected the problem could be related to emacs-buttercup, so I
> updated it locally to the latest upstream version and rebuilt flycheck
> with it, to no avail.

I spent some more time investigating this problem and was able to
pinpoint it to the fact that, for some reason, this problem happens when
you have two (spy-on) calls and the first one uses :and-return-value,
which is the case here.

I'm not sure this is a bug with buttercup, but I filed an upstream bug
with them just in case:

  https://github.com/jorgenschaefer/emacs-buttercup/issues/230

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1032040: picard: PIcard needs authorization to import metadata from MusicBrainz server.

[Bartek]

Package: picard
Version: 2.8.5-1+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: poem...@gmail.com

Dear Maintainer,

   * What led up to the situation?
While trying to tag audio files with data from MusicBrainz.org it asks for its
account authorization code.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I do not have MusicBrainz.org account to generate such code so files tagging
does not work.

   * What was the outcome of this action?
Audio files not tagged.

   * What outcome did you expect instead?
Import metadata from musicbrainz.org

Picard version 2.8.5-1_amd64 worked as intended without extra step such as
requirement to login to the service and necessity of authorization code.
Downgrading to the older version (build from source) requires python3 (< 3.11).
Both packages are not available in testing and sid repositories any more.

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

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

Versions of packages picard depends on:
ii  libc6 2.36-8
ii  libchromaprint-tools  1.5.1-2+b1
ii  python3   3.11.2-1
ii  python3-dateutil  2.8.2-1
ii  python3-fasteners 0.17.3-2
ii  python3-jwt   2.6.0-1
ii  python3-libdiscid 2.0.2-1+b2
ii  python3-markdown  3.4.1-2
ii  python3-mutagen   1.46.0-1
ii  python3-pyqt5 5.15.9+dfsg-1
ii  python3-yaml  6.0-3+b2

Versions of packages picard recommends:
ii  libqt5multimedia5-plugins   5.15.8-2
ii  python3-pyqt5.qtmultimedia  5.15.9+dfsg-1

Versions of packages picard suggests:
ii  hicolor-icon-theme  0.17-2

-- no debconf information


Regards,

Bartek

Bug#1028743: python-bottle: diff for NMU version 0.12.23-1.1

[Louis-Philippe Véronneau]

Control: tags 1028743 + pending


Dear maintainer,

I've prepared an NMU for python-bottle (versioned as 0.12.23-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

I've attached the debdiff to this message, but I've also opened a MR on 
Salsa, if you prefer to merge this.


https://salsa.debian.org/debian/python-bottle/-/merge_requests/1

Regards.

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄diff -Nru python-bottle-0.12.23/debian/changelog 
python-bottle-0.12.23/debian/changelog
--- python-bottle-0.12.23/debian/changelog  2022-09-17 06:37:25.0 
-0400
+++ python-bottle-0.12.23/debian/changelog  2023-02-26 15:59:44.0 
-0500
@@ -1,3 +1,13 @@
+python-bottle (0.12.23-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ James Addison ]
+  * d/patches: add 0004 to disable the local proxy for the tests. (Closes:
+#1028743)
+
+ -- Louis-Philippe Véronneau   Sun, 26 Feb 2023 15:59:44 
-0500
+
 python-bottle (0.12.23-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
python-bottle-0.12.23/debian/patches/0004-Localhost-request-no-proxy.patch 
python-bottle-0.12.23/debian/patches/0004-Localhost-request-no-proxy.patch
--- python-bottle-0.12.23/debian/patches/0004-Localhost-request-no-proxy.patch  
1969-12-31 19:00:00.0 -0500
+++ python-bottle-0.12.23/debian/patches/0004-Localhost-request-no-proxy.patch  
2023-02-26 15:59:44.0 -0500
@@ -0,0 +1,30 @@
+Description: Fix the test_server 'fetch' method to disable proxying within
+ tests cases where it is used. This resolve the connection refused errors due 
to
+ the HTTP proxy enabled by default during autopkgtests.
+Author: James Addison 
+--- a/test/test_server.py
 b/test/test_server.py
+@@ -11,9 +11,9 @@
+ from bottle import _e
+ 
+ try:
+-from urllib.request import urlopen
++from urllib.request import ProxyHandler, build_opener
+ except:
+-from urllib2 import urlopen
++from urllib2 import ProxyHandler, build_opener
+ 
+ serverscript = os.path.join(os.path.dirname(__file__), 'servertest.py')
+ 
+@@ -77,8 +77,10 @@
+ raise AssertionError(line.strip().decode('utf8'))
+ 
+ def fetch(self, url):
++proxy_handler = ProxyHandler(proxies={})
++url_opener = build_opener(proxy_handler)
+ try:
+-return urlopen('http://127.0.0.1:%d/%s' % (self.port, url)).read()
++return url_opener.open('http://127.0.0.1:%d/%s' % (self.port, 
url)).read()
+ except Exception:
+ return repr(_e())
+ 
diff -Nru python-bottle-0.12.23/debian/patches/series 
python-bottle-0.12.23/debian/patches/series
--- python-bottle-0.12.23/debian/patches/series 2022-09-17 06:37:25.0 
-0400
+++ python-bottle-0.12.23/debian/patches/series 2023-02-26 15:50:45.0 
-0500
@@ -1,3 +1,4 @@
 0001-Remove-bottle.py-from-scripts.patch
 0002-Add-CLI-manpage.patch
 0003-Disable-failing-tests.patch
+0004-Localhost-request-no-proxy.patch

Bug#1032039: xorg: xserver fails to recover session after locking (xfce4 / lightdm)

[Dimitri Chausson]

Package: xorg
Version: 1:7.7+23
Severity: important

Dear Maintainer,

Xfce is set up to lock the screen after a while. When I want to login again to
get back to the opened session,  I am prompted to type my password (the username
 is already filled). When the enter key is pressed down, a kind of "re-init"
takes place I see the login screen again, but this time, I have to enter my
username + password. I get logged in, but it is a new session.. None of the
applications left open before is active.

I did a diff between both Xorg.*.log file before locking takes place and after,
and the server crashes in-between: the trace is as follows:

begin
[  5346.907] (II) VESA(0): Setting up VESA Mode 0x1D4 (1920x1200)
[  5346.908] (EE)
[  5346.908] (EE) Backtrace:
[  5346.908] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x556f389e2cf9]
[  5346.908] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) 
[0x7f382885af90]
[  5346.909] (EE) 2: /lib/x86_64-linux-gnu/libpciaccess.so.0 
(pci_device_vgaarb_get_info+0x2ad) [0x7f38292cffdd]
[  5346.909] (EE) 3: /usr/lib/xorg/modules/libint10.so (xf86int10Addr+0x72a) 
[0x7f38281a0f1a]
[  5346.909] (EE) 4: /usr/lib/xorg/modules/libint10.so (xf86int10Addr+0x7834) 
[0x7f38281a8024]
[  5346.909] (EE) 5: /usr/lib/xorg/modules/libint10.so (xf86ExecX86int10+0x45) 
[0x7f382819f995]
[  5346.909] (EE) 6: /usr/lib/xorg/modules/libint10.so (VBESetVBEMode+0x76) 
[0x7f382819c486]
[  5346.909] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  5346.909] (EE) 7: /usr/lib/xorg/modules/drivers/vesa_drv.so (?+0x0) 
[0x7f3828592200]
[  5346.910] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  5346.910] (EE) 8: /usr/lib/xorg/modules/drivers/vesa_drv.so (?+0x0) 
[0x7f3828592405]
[  5346.910] (EE) 9: /usr/lib/xorg/Xorg 
(xf86AllocateLinearOffscreenArea+0x1497) [0x556f388b6127]
[  5346.910] (EE) 10: /usr/lib/xorg/Xorg (xf86VTEnter+0x81) [0x556f388aee31]
[  5346.910] (EE) 11: /usr/lib/xorg/Xorg (WakeupHandler+0xb3) [0x556f38874243]
[  5346.910] (EE) 12: /usr/lib/xorg/Xorg (WaitForSomething+0x198) 
[0x556f389dc6b8]
[  5346.910] (EE) 13: /usr/lib/xorg/Xorg (SendErrorToClient+0x113) 
[0x556f3886f473]
[  5346.910] (EE) 14: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x556f388736cc]
[  5346.910] (EE) 15: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) 
[0x7f382884618a]
[  5346.911] (EE) 16: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) 
[0x7f3828846245]
[  5346.911] (EE) 17: /usr/lib/xorg/Xorg (_start+0x21) [0x556f3885cb71]
[  5346.911] (EE)
[  5346.911] (EE) Segmentation fault at address 0x0
[  5346.911] (EE)
Fatal server error:
[  5346.911] (EE) Caught signal 11 (Segmentation fault). Server aborting
[  5346.911] (EE)
[  5346.911] (EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
[  5346.911] (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
additional information.
[  5346.911] (EE)
end--

Hopefully, you can help me, I can provide more information if needed,

Thanks for your work,

Dimitri


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Apr 22  2013 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Feb  7 14:15 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
29:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Picasso/Raven 2 [Radeon Vega Series / Radeon Vega Mobile Series] 
[1002:15d8] (rev c8)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 0 May  7  2013 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---

Contents of /etc/X11/xorg.conf.d:
-
total 0

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-19)) #1 SMP Debian 4.19.37-6 (2019-07-18)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 71134 Feb 26 16:14 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 70392 Feb 26 21:41 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 6.584]
X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
[ 6.584] Current Operating System: Linux keats 4.19.0-5-amd64 #1 SMP Debian 
4.19.37-6 (2019-07-18) x86_64
[ 6.584] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=5d41cc9b-817f-44a6-82c9-75898ef11f11 ro vsyscall=emulate quiet
[ 6.584] xorg-server 2:21.1.7-1 (https://www.debian.org/support)
[ 6.584] Current version of pixman: 0.42.2
[ 6.584]Before reporting problems, check 

Bug#1032038: picocom FTBFS on mips64el/mipsel/sparc64

[Adrian Bunk]

Source: picocom
Version: 3.1-2
Severity: serious
Tags: ftbfs patch
X-Debbugs-Cc: Martin 

https://buildd.debian.org/status/logs.php?pkg=picocom=3.1-3

...
In file included from term.c:73:
term.c: In function ‘term_get_baudrate’:
termios2.h:41:41: error: ‘struct termios’ has no member named ‘c_ispeed’
   41 | #define cfgetispeed_custom(tiop) ((tiop)->c_ispeed)
  | ^~
term.c:862:27: note: in expansion of macro ‘cfgetispeed_custom’
  862 | *ispeed = cfgetispeed_custom([i]);
  |   ^~
termios2.h:40:41: error: ‘struct termios’ has no member named ‘c_ospeed’
   40 | #define cfgetospeed_custom(tiop) ((tiop)->c_ospeed)
  | ^~
term.c:870:22: note: in expansion of macro ‘cfgetospeed_custom’
  870 | ospeed = cfgetospeed_custom([i]);
  |  ^~
make[2]: *** [Makefile:64: term.o] Error 1


This is due to:

/usr/include/mips64el-linux-gnuabi64/bits/termios-struct.h
...
#define _HAVE_STRUCT_TERMIOS_C_ISPEED 0
#define _HAVE_STRUCT_TERMIOS_C_OSPEED 0
...


An updated use-custom-baud patch is attached.
Description: support custom baudrate on architectures with c_ispeed/c_ospeed
Author: W. Martin Borgert 
Origin: vendor
Last-Update: 2018-03-21
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/custbaud.h
+++ b/custbaud.h
@@ -33,7 +33,8 @@
 /* Enable by-default for kernels > 2.6.0 on x86 and x86_64 only */
 #include 
 #if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,0)
-#if defined (__i386__) || defined (__x86_64__) || defined (USE_CUSTOM_BAUD)
+#include 
+#if defined (_HAVE_STRUCT_TERMIOS_C_ISPEED) && defined 
(_HAVE_STRUCT_TERMIOS_C_OSPEED) && _HAVE_STRUCT_TERMIOS_C_ISPEED && 
_HAVE_STRUCT_TERMIOS_C_OSPEED
 #ifndef USE_CUSTOM_BAUD
 #define USE_CUSTOM_BAUD
 #endif

Bug#1032037: unblock: linux/6.1.12-1

[Luna Jernberg]

Yeah worked good on my old Packard Bell laptop with a Pentium T4400
for some weeks, thanks for your job with new kernels for Debian :)

On 2/26/23, Salvatore Bonaccorso  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: li...@packages.debian.org, car...@debian.org
> Control: affects -1 + src:linux
>
> Hi,
>
> Please unblock package linux
>
> As we follow the 6.1.y stable series aimed for bookworm, 6.1.12-1 is
> ready to move further to testing. I has been in unstable for at least
> ten days without regression reported from the 6.1.8-1 version.
>
> So moving that version to testing would be welcome, 6.1.14 or later is
> already beeing prepared in the packaging repository to be followed.
>
> Please consider letting 6.1.12-1 to testing for bookworm.
>
> unblock linux/6.1.12-1
>
> Regards,
> Salvatore
>
>

Bug#1030851: bullseye-pu: package symfony/4.4.19+dfsg-2+deb11u2

[Paul Gevers]

Dear David,

On 08-02-2023 13:53, David Prévot wrote:

[ Tests ]
I didn’t test it thoroughly (I doubt to have much time for at least
another week), but it passes


There are issues with the installability of src:symfony packages as can 
be seen from the autopkgtests [1]:


php-symfony-security-bundle : Depends: php-symfony-security-http (>= 
4.4.50) but 4.4.19+dfsg-2+deb11u2 is to be installed


Paul

[1] 
https://ci.debian.net/data/autopkgtest/stable/armel/s/symfony/31720374/log.gz


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032037: unblock: linux/6.1.12-1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: li...@packages.debian.org, car...@debian.org
Control: affects -1 + src:linux

Hi,

Please unblock package linux

As we follow the 6.1.y stable series aimed for bookworm, 6.1.12-1 is
ready to move further to testing. I has been in unstable for at least
ten days without regression reported from the 6.1.8-1 version.

So moving that version to testing would be welcome, 6.1.14 or later is
already beeing prepared in the packaging repository to be followed.

Please consider letting 6.1.12-1 to testing for bookworm.

unblock linux/6.1.12-1

Regards,
Salvatore

Bug#1031943: ebtables: symlink removal removal code in the postinst does not seem to be working

[Jeremy Sowden]

On 2023-02-25, at 20:17:34 +0200, Adrian Bunk wrote:
> Package: ebtables
> Version: 2.0.11-5
> Severity: serious
> 
> ...
> Setting up ebtables (2.0.11-5) ...
> update-alternatives: using /usr/sbin/ebtables-legacy to provide 
> /usr/sbin/ebtables (ebtables) in auto mode
> update-alternatives: error: cannot stat file '/usr/sbin/ebtables': Too many 
> levels of symbolic links
> dpkg: error processing package ebtables (--configure):
> ...
> 
> 
> This is due to (with merged /usr):
> lrwxrwxrwx 1 root root 18 Apr  6  2022 /sbin/ebtables -> /usr/sbin/ebtables
> lrwxrwxrwx 1 root root 26 Apr  6  2022 /sbin/ebtables-restore -> 
> /usr/sbin/ebtables-restore
> lrwxrwxrwx 1 root root 23 Apr  6  2022 /sbin/ebtables-save -> 
> /usr/sbin/ebtables-save
> 
> 
> Adding "set -x" in /var/lib/dpkg/info/ebtables.postinst shows:
> ...
> + LIST=ebtables ebtables-save ebtables-restore
> + [ -e /sbin/ebtables ]
> + [ -e /sbin/ebtables-save ]
> + [ -e /sbin/ebtables-restore ]
> + [ configure = configure ]
> ...
> 
> Using -h instead of -e works:
> ...
> + LIST=ebtables ebtables-save ebtables-restore
> + [ -h /sbin/ebtables ]
> + readlink /sbin/ebtables
> + [ /usr/sbin/ebtables = /usr/sbin/ebtables ]
> + rm /sbin/ebtables
> + [ -h /sbin/ebtables-save ]
> + readlink /sbin/ebtables-save
> + [ /usr/sbin/ebtables-save = /usr/sbin/ebtables-save ]
> + rm /sbin/ebtables-save
> + [ -h /sbin/ebtables-restore ]
> + readlink /sbin/ebtables-restore
> + [ /usr/sbin/ebtables-restore = /usr/sbin/ebtables-restore ]
> + rm /sbin/ebtables-restore
> + [ configure = configure ]
> ...

Thanks for the report.  I've no objection to changing the `-e` test to
`-h`, but I should like to understand what is going wrong, and I haven't
been able to reproduce it.  I believe that the postinst `-e` tests ought
only to fail if the sym-links are broken.  In conjunction with the fact
that update-alternatives was complaining about not being able to stat
/usr/sbin/ebtables, this suggests to me that the failing tests are
symptomatic of another underlying problem.

Given that the postinst script was trying and failing to remove existing
sym-links, I take it that you already had ebtables installed and were
upgrading to 2.0.11-5.

Here's what I see in after initially installing ebtables (2.0.11-4+b1)
in a Bullseye chroot without merged /usr:

  $ ls -l /etc/alternatives/ebtables* /sbin/ebtables* /usr/sbin/ebtables*
  lrwxrwxrwx 1 root root25 Feb 26 09:14 /etc/alternatives/ebtables -> 
/usr/sbin/ebtables-legacy*
  lrwxrwxrwx 1 root root33 Feb 26 09:14 /etc/alternatives/ebtables-restore 
-> /usr/sbin/ebtables-legacy-restore*
  lrwxrwxrwx 1 root root30 Feb 26 09:14 /etc/alternatives/ebtables-save -> 
/usr/sbin/ebtables-legacy-save*
  lrwxrwxrwx 1 root root18 Feb 26 09:14 /sbin/ebtables -> 
/usr/sbin/ebtables*
  lrwxrwxrwx 1 root root26 Feb 26 09:14 /sbin/ebtables-restore -> 
/usr/sbin/ebtables-restore*
  lrwxrwxrwx 1 root root23 Feb 26 09:14 /sbin/ebtables-save -> 
/usr/sbin/ebtables-save*
  lrwxrwxrwx 1 root root26 Feb 26 09:14 /usr/sbin/ebtables -> 
/etc/alternatives/ebtables*
  -rwxr-xr-x 1 root root 14600 Jun  6  2020 /usr/sbin/ebtables-legacy*
  -rwxr-xr-x 1 root root 14784 Jun  6  2020 /usr/sbin/ebtables-legacy-restore*
  -rwxr-xr-x 1 root root  1677 Jun  6  2020 /usr/sbin/ebtables-legacy-save*
  lrwxrwxrwx 1 root root34 Feb 26 09:14 /usr/sbin/ebtables-restore -> 
/etc/alternatives/ebtables-restore*
  lrwxrwxrwx 1 root root31 Feb 26 09:14 /usr/sbin/ebtables-save -> 
/etc/alternatives/ebtables-save*
  -rwxr-xr-x 1 root root 14800 Jun  6  2020 /usr/sbin/ebtablesd*
  -rwxr-xr-x 1 root root 14672 Jun  6  2020 /usr/sbin/ebtablesu*

This includes the three sym-links from /sbin to /usr/sbin you list
above and they resolve correctly.  For example:

  * /sbin/ebtables -> /usr/sbin/ebtables
  * /usr/sbin/ebtables -> /etc/alternatives/ebtables
  * /etc/alternatives/ebtables -> /usr/sbin/ebtables-legacy

With merged /usr (whether by creating the chroot with `debootstrap
--merged-usr`, installing the usrmerge package before installing
ebtables, or installing usrmerge after ebtables), I see the following:

  $ ls -l /etc/alternatives/ebtables* /sbin /sbin/ebtables* /usr/sbin/ebtables*
  lrwxrwxrwx 1 root root25 Feb 26 09:14 /etc/alternatives/ebtables -> 
/usr/sbin/ebtables-legacy*
  lrwxrwxrwx 1 root root33 Feb 26 09:14 /etc/alternatives/ebtables-restore 
-> /usr/sbin/ebtables-legacy-restore*
  lrwxrwxrwx 1 root root30 Feb 26 09:14 /etc/alternatives/ebtables-save -> 
/usr/sbin/ebtables-legacy-save*
  lrwxrwxrwx 1 root root 8 Feb 26 09:17 /sbin -> usr/sbin/
  lrwxrwxrwx 1 root root26 Feb 26 09:14 /sbin/ebtables -> 
/etc/alternatives/ebtables*
  -rwxr-xr-x 1 root root 14600 Jun  6  2020 /sbin/ebtables-legacy*
  -rwxr-xr-x 1 root root 14784 Jun  6  2020 /sbin/ebtables-legacy-restore*
  -rwxr-xr-x 1 root root  1677 Jun  6  2020 /sbin/ebtables-legacy-save*
  lrwxrwxrwx 1 root root34 Feb 26 09:14 

Bug#1031880: Downgrade u-u bug

[Louis-Philippe Véronneau]

user debian-rele...@lists.debian.org 


usertag 1031880 + bsp-2023-02-ca-montreal
severity 1031880 normal
thank you

Hi,

Although this seems like a real bug, I feel like the conditions to 
reproduce it are very specific and do not justify the current severity.


As such, I'm downgrading it to severity: normal.

Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1032035: hashcat-nvidia doesn't respect nvidia-tesla-470-opencl-icd

[martin.westerkamp]

Package: hashcat-nvidia
Version: 20210201

I work with Debian GNU/Linux testing (Bookworm) at the moment.

Debian GNU/Linux is providing this metapackage to make it easy for users of 
NVIDIA cards to install hashcat with all it's dependencies and make use of 
OpenCL

In Debian Bullseye the dependencies were either nvidia-opencl-icd (newest 
nvidia-driver) or nvidia-legacy-390xx-opencl-icd (the legacy version for older 
cards). The same was done for the recommended nvidia-smi or 
nvidia-legacy-390xx-smi package.

Meanwhile NVIDIA dropped support for the pre-maxwell cards (kepler and so on) 
from it's latest driver, so it is not included anymore with latest 
nvidia-opencl-icd and is instead provided by the in Debian GNU/Linux testing 
already existing package nvidia-tesla-470-opencl-icd, like it was done in the 
past with the nvidia-legacy-390xx-opencl-icd package.

Same goes for the fitting nvidia-tesla-470-smi package. The 470 driver is still 
supported by NVIDIA.

To complicate things further, it seems that neither the old 
nvidia-legacy-390xx-opencl-icd package nor the nvidia-legacy-390xx-smi package 
isn't existing in Debian GNU/Linux testing anymore.

From my understanding the fix would be to add nvidia-tesla-470-opencl-icd and 
nvidia-tesla-470-smi in addition to the hashcat-nvidia package to make users of 
these cards happy again or replace (the not existing at the moment) 390 
dependencies with the 470 dependencies.

This way the whole range of supported NVIDIA cards will be included in the 
hashcat-nvidia package and it's full usefullnes would be restored again.
I hope, this message is useful for you.

With best regards,
Martin

Bug#1032036: chromhmm: broken package on non arm64/amd64 architectures

[Vladimir Petko]

Source: chromhmm
X-Debbugs-Cc: vladimir.pe...@canonical.com
Version:  1.24+dfsg-1
Severity: normal

$sudo apt install chromhmm
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libhtsjdk-java : Depends: libngs-java but it is not installable
E: Unable to correct problems, you have held broken packages.

The root cause is sra-sdk dependency which is only available for amd64
and arm64 architectures.

Bug#1032034: beagle: broken package on non arm64/amd64 architectures

[Vladimir Petko]

Source: beagle
X-Debbugs-Cc: vladimir.pe...@canonical.com
Version: 220722-1
Severity: normal

Dear Maintainer,

When installing beagle package on non amd64/arm64 architecture, the
following error is generated:

$sudo apt install beagle
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libhtsjdk-java : Depends: libngs-java but it is not installable
E: Unable to correct problems, you have held broken packages.

The root cause is sra-sdk dependency which is only available for amd64
and arm64 architectures.

Bug#1032032: FTBFS: error: AM_INIT_AUTOMAKE expanded multiple times

[Adam Borowski]

Source: fenix-plugins
Version: 0.0.20070803-8
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid your package fails to build; I see a lot of autoconf warnings,
then they get fatal:

Makefile.am: installing './depcomp'
configure.ac:12: error: AM_INIT_AUTOMAKE expanded multiple times
/usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
configure.ac:11: the top level
/usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
configure.ac:12: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
aclocal: error: /usr/bin/autom4te failed with exit status: 1
autoreconf: error: aclocal failed with exit status: 1
dh_autoreconf: error: autoreconf -f -i agua-1.0 exec-0.4a fgfx-1.0 fire-1.0 
fsock-1.0 image-1.0 mixer-1.0 mpeg-1.0 net-1.0 tcpsock-2.0 ttf-1.0 returned 
exit code 1

It appears the package is not compatible with new autotools; they have
been updated quite a while ago but as the package is 32-bit only the
failure wasn't noticed during usual QA efforts.

I've verified the fail on i386 and armhf.

Full log attached.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.2.0-00034-g2ff294a21c8d (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.85.0 (04 January 2023) on valinor.angband.pl

+==+
| fenix-plugins (i386) Sun, 26 Feb 2023 01:31:02 + |
+==+

Package: fenix-plugins
Distribution: unstable
Machine Architecture: amd64
Host Architecture: i386
Build Architecture: i386
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-i386-sbuild-f27f2fb3-5a2c-41fa-94ad-2023f47260fb'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/fenix-plugins-gpzT6Q/resolver-zNf5Pt' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'fenix-plugins' packaging is maintained in the 'Git' version control 
system at:
https://salsa.debian.org/games-team/fenix-plugins.git
Please use:
git clone https://salsa.debian.org/games-team/fenix-plugins.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 7775 kB of source archives.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main fenix-plugins 
0.0.20070803-8 (dsc) [2749 B]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main fenix-plugins 
0.0.20070803-8 (tar) [7766 kB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main fenix-plugins 
0.0.20070803-8 (diff) [6336 B]
Fetched 7775 kB in 0s (262 MB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 
'build/fenix-plugins-gpzT6Q/fenix-plugins-0.0.20070803' with '<>'
I: NOTICE: Log filtering will replace 'build/fenix-plugins-gpzT6Q' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 12), zlib1g-dev, libsdl1.2-dev, 
libsdl-image1.2-dev, libsdl-net1.2-dev, libsdl-mixer1.2-dev, libsmpeg-dev, 
libfreetype6-dev, fenix, fenix-dev, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 12), zlib1g-dev, libsdl1.2-dev, 
libsdl-image1.2-dev, libsdl-net1.2-dev, libsdl-mixer1.2-dev, libsmpeg-dev, 
libfreetype6-dev, fenix, fenix-dev, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ 

Bug#1032033: ITP: tfk8s -- Tool for converting Kubernetes YAML manifests to Terraform HCL

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: tfk8s
  Version : 0.1.10-1
  Upstream Author : John Houston
* URL : https://github.com/jrhouston/tfk8s
* License : Expat
  Programming Lang: Go
  Description : Tool for converting Kubernetes YAML manifests to Terraform 
HCL

 tfk8s is a tool that makes it easier to work with the Terraform
 Kubernetes Provider (https://github.com/hashicorp/terraform-provider-
 kubernetes).

Bug#1032031: python3-zstandard also needs Depends: libzstd1 (<< 1.5.5)

[Adrian Bunk]

Package: python3-zstandard
Version: 0.20.0-2
Severity: serious

This is not just an autopkgtest issue, it would break the package
for users if the dependencies of python3-zstandard in bookworm
would permit installing python3-zstandard/bookworm together
with a more recent version of libzstd1 from trixie (expecially
when upgrading from bookworm to trixie) or bookworm-backports.

Bug#843552: Replace signal by sigaction.

[Marcos Marado]

found 843552 0.17.40+0.2-2
notfound 843552 0.17.41+0.2-1
thanks

This was fixed on netkit-telnet (see #835977 ), and netkit-telnet-ssl
then inherited the fix (see changelog).

Best regards,
-- 
Marcos Marado

Bug#1019273: apt: diff for NMU version 2.5.6+nmu1

[Louis-Philippe Véronneau]

Control: tags 1019273 + pending

Dear maintainer,

I've prepared an NMU for apt (versioned as 2.5.6+nmu1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Attached is the actual debdiff.

Regards.

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄diff -Nru apt-2.5.6/COPYING apt-2.5.6+nmu1/COPYING
--- apt-2.5.6/COPYING   2023-02-08 11:07:38.0 -0500
+++ apt-2.5.6+nmu1/COPYING  2023-02-26 13:17:23.0 -0500
@@ -1,22 +1,174 @@
-Apt is copyright 1997, 1998, 1999 Jason Gunthorpe and others.
-Apt is currently developed by APT Development Team .
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: apt
+Upstream-Contact: APT Development Team 
+Source: https://salsa.debian.org/apt-team/apt
 
-License: GPLv2+
+Files: *
+Copyright: 1997-1999 Jason Gunthorpe and others
+License: GPL-2+
 
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
-
-See /usr/share/common-licenses/GPL-2, or
- for the terms of the latest version
-of the GNU General Public License.
+Files: apt-pkg/cachefilter-patterns.*
+   apt-private/private-json-hooks.*
+   test/libapt/pattern_test.cc
+Copyright: 2018, 2019 Canonical Ltd
+License: GPL-2+
+
+Files: po/lt.po
+Copyright: 2006 Canonical Ltd, and Rosetta Contributors 2006
+License: GPL-2+
+
+Files: apt-pkg/contrib/weakptr.h
+   apt-pkg/contrib/string_view.h
+   CMakeLists.txt
+Copyright: 2009, 2010, 2015, 2016 Julian Andres Klode 
+License: GPL-2+
+
+Files: debian/apt.postrm
+Copyright: 1998, Ben Gertzfield 
+License: GPL-2+
+
+Files: doc/po/pt.po
+   po/bg.po
+   po/it.po
+   po/sv.po
+   po/th.po
+Copyright: 2002-2019 Free Software Foundation, Inc.
+License: GPL-2+
+
+Files: doc/po/es.po
+   po/tl.po
+Copyright: 2003, 2004, 2005, 2009, 2010, 2012 Software in the Public Interest
+License: GPL-2+
+
+Files: po/nb.po
+Copyright: 2002-2003 Lars Bahner 
+   2003-2004 Axel Bojer 
+   2004 Klaus Ade Johnstad 
+   2004 Bjorn Steensrud 
+   2003, 2005-2010 Hans Fredrik Nordhaug 
+   2016, 2018 Petter Reinholdtsen 
+License: GPL-2
+
+Files: po/tr.po
+Copyright: 2009 Rosetta Contributors and Canonical Ltd 2009
+   2013 Debian L10n Turkish 2013
+   2013-2018 Mert Dirik 
+License: GPL-2+
+
+Files: doc/po/pl.po
+Copyright: 2004 Krzysztof Fiertek 
+   2000-2004, 2010, 2012  Robert Luberda 
+License: GPL-2+
+
+Files: doc/po/it.po
+Copyright: 2000-2017 Debian Italian l10n team 

+License: GPL-2+
+
+Files: doc/po/ja.po
+Copyright: 2003-2017 Debian Japanese List 
+License: GPL-2+
+
+Files: doc/po/fr.po
+Copyright: 2000-2018 Debian French l10n team 

+License: GPL-2+
+
+Files: doc/design.dbk
+Copyright: 1997 Manoj Srivastava
+License: GPL-2+
+
+Files: doc/dpkg-tech.dbk
+Copyright: 1997 Tom Lees
+License: GPL-2+
+
+Files: methods/rred.cc
+Copyright: 2014 Anthony Towns
+License: GPL-2+
+
+Files: methods/rsh.cc
+Copyright: 2000 Ben Collins 
+License: GPL-2
+
+Files: CMake/FindBerkeley.cmake
+Copyright: 2006, Alexander Dymo, 
+   2016, Julian Andres Klode 
+License: BSD-3-clause
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+ .
+ 1. Redistributions of source code must retain the copyright
+notice, this list of conditions and the following disclaimer.
+ 2. Redistributions in binary form must reproduce the copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+ 3. The name of the author may not be used to endorse or promote products
+derived from this software without specific prior written permission.
+ .
+ THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ DATA, OR PROFITS; 

Bug#1031859: false positive of embedded expat library leads to ftp-master rejection

[Axel Beckert]

Control: severity -1 minor

Hi Matthias,

Matthias Klose wrote:
> > > The packages are confiured --with-system-expat, and all have proper 
> > > dependencies
> > > on libexpat1.
> > > 
> > > The same bogus messages can be found for python3.11 at
> > > https://udd.debian.org/lintian/?packages=python3.11
> 
> yes, see https://github.com/python/cpython/blob/main/Modules/pyexpat.c

Thanks for that hint. So Python upstream copied a bunch of error
messages verbatim from libexpat since Python 3.11. 奈 (I verified that
this got added in 3.11 and that 3.10.0 and 3.10.10 doesn't emit these
tags.)

So this means that this test works as it should and detected that fact.

In that case:

1) this is by no means an RC-critical as it only affects a single
   package (well, actually pypy, too, probably for similar reasons)
   and does not mean that the check itself is broken. In contrary!

   Hence downgrading the severity to minor, as there's a small chance
   that we can find an libexpat string that the Python upstream devs
   haven't copied verbatim into their code. 郎

   (If we don't find one occasionally, I will close this bug report as
   wontfix.)

2) You should just add a lintian override as this is a very special
   circumstance only appearing in two python-related packages and
   nowhere else and the cause is a very weird behaviour of the
   upstream developers.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1030857: Testing

[Sandro Tosi]

> Unless morph vetoes it, I'd merge your 3 salsa MRs [0][1][2] and if no 
> obvious problems pop up during testing I'd just upload it. WDYT?

no issues here

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1030857: Testing

[Leo Antunes]

Hi,

On Fri, 24 Feb 2023 21:28:18 + "Barak A. Pearlmutter" wrote:
> The upgraded daemon invalidates all downloaded data and wants to
> verify them, which is a local operation, but is still taking forever.
> I think that's supposed to be a feature not a bug.

Yeah, that makes sense.

> If someone were to test the clients that would be great!

Unless morph vetoes it, I'd merge your 3 salsa MRs [0][1][2] and if no obvious 
problems pop up during testing I'd just upload it. WDYT?


Cheers
Leo Antunes


[0] https://salsa.debian.org/debian/transmission/-/merge_requests/11
[1] https://salsa.debian.org/debian/transmission/-/merge_requests/12
[2] https://salsa.debian.org/debian/transmission/-/merge_requests/13

Bug#1031888: emacs-nox: bullseye-security update fails to install on mips64el

[Salvatore Bonaccorso]

Hi Adrian,

On Sun, Feb 26, 2023 at 09:41:31PM +0200, Adrian Bunk wrote:
> On Sun, Feb 26, 2023 at 08:31:00PM +0100, Salvatore Bonaccorso wrote:
> >...
> > On Sun, Feb 26, 2023 at 08:43:11PM +0200, Adrian Bunk wrote:
> > > On Sun, Feb 26, 2023 at 07:47:21PM +0200, Adrian Bunk wrote:
> > > > On Sun, Feb 26, 2023 at 04:12:35AM +0200, Adrian Bunk wrote:
> > > > >...
> > > > > In the upstream bug for CVE-2022-48337 there was originally[1]
> > > > > +  free (new_real_name);
> > > > > +  free (new_tmp_name);
> > > > > in the fix that later disappeared (by accident?).
> > > > > 
> > > > > I would say the CVE-2022-48337 fix introduced a memory leak,
> > > > > which might or might not be related to the mips64el problem.
> > > > >...
> > > > 
> > > > I've reported this upstream as https://debbugs.gnu.org/61819
> > > 
> > > This is now fixed upstream with
> > > http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0fde314f6f6e6664cddab1b2f0fe20629cd39d14
> > 
> > So this would affect as well the current unstable version, adding the
> > found version for that as well.
> 
> The memory leak fixed upstream does.
> 
> While I suspect they are the same, there is no proof that this leak is 
> actually the same as the mips64el installation issue.

Ok right; you are correct we have no proof yet that it is the same, so
we cannot directly close right now this bug with a potential pending
regression update. 

Thanks for taking it upstream.

Regards,
Salvatore

Bug#1030919: xserver-xorg-video-intel: The server crashes when the mouse pointer hovers over a gtk button

[Bernhard Übelacker]

Dear Maintainer,
I tried to add line information using the dbgsym packages.
That led me to libc trying to print the
message "double free or corruption (out)".

Kind regards,
Bernhard


https://sources.debian.org/src/glibc/2.36-8/malloc/malloc.c/
4584malloc_printerr ("double free or corruption (out)");


0:  Xorg (OsLookupColor+0x139)  [0x55e578a89cc9] in 
OsSigHandler at ../../../../os/osinit.c:138
1:  libc.so.6(__sigaction+0x40) [0x7fee08244f90]
2:  libc.so.6(pthread_key_delete+0x14c) [0x7fee08293ccc] in 
__pthread_kill_implementation at ./nptl/pthread_kill.c:43
3:  libc.so.6(gsignal+0x12) [0x7fee08244ef2] in __GI_raise 
at ../sysdeps/posix/raise.c:26
4:  libc.so.6(abort+0xd3)   [0x7fee0822f472] in __GI_abort 
at ./stdlib/abort.c:79
5:  libc.so.6(__fsetlocking+0x290)  [0x7fee082882d0] in 
__libc_message at ../sysdeps/posix/libc_fatal.c:155
6:  libc.so.6(timer_settime+0x37a)  [0x7fee0829d64a] in 
malloc_printerr at ./malloc/malloc.c:5660
7:  libc.so.6(__default_morecore+0x8a0) [0x7fee0829f6b0] in _int_free 
at ./malloc/malloc.c:4584
8:  libc.so.6(__libc_free+0x6f) [0x7fee082a1d2f] in 
__GI___libc_free at ./malloc/malloc.c:3385
9:  intel_drv.so (?+0x0)[0x7fee075d8a0f] in 
I810SetPortAttribute / RegionUninit at /usr/include/xorg/regionstr.h:166
10: Xorg (DamageDestroy+0x23e)  [0x55e5789f627e] in 
damageDestroyPixmap at ../../../../../miext/damage/damage.c:1504
11: Xorg (ShmRegisterFbFuncs+0x80e) [0x55e5789b084e] in 
XvDestroyPixmap at ../../../../Xext/xvmain.c:369
12: Xorg (SyncVerifyFence+0x3354)   [0x55e5789af214] in 
ShmDestroyPixmap at ../../../../Xext/shm.c:260
13: Xorg (RegisterExtensionNames+0x1dd) [0x55e57893d22d] in 
doFreeResource at ../../../../dix/resource.c:885
14: Xorg (FreeResource+0xe9)[0x55e57893de19] in 
FreeResource at ../../../../dix/resource.c:915
15: Xorg (dixDestroyPixmap+0x27e)   [0x55e57891196e] in 
ProcFreePixmap at ../../../../dix/dispatch.c:1538
16: Xorg (SendErrorToClient+0x3d4)  [0x55e578916734] in Dispatch at 
../../../../dix/dispatch.c:550
17: Xorg (InitFonts+0x3bc)  [0x55e57891a6cc] in dix_main at 
../../../../dix/main.c:272

Bug#1031888: emacs-nox: bullseye-security update fails to install on mips64el

[Adrian Bunk]

On Sun, Feb 26, 2023 at 08:31:00PM +0100, Salvatore Bonaccorso wrote:
>...
> On Sun, Feb 26, 2023 at 08:43:11PM +0200, Adrian Bunk wrote:
> > On Sun, Feb 26, 2023 at 07:47:21PM +0200, Adrian Bunk wrote:
> > > On Sun, Feb 26, 2023 at 04:12:35AM +0200, Adrian Bunk wrote:
> > > >...
> > > > In the upstream bug for CVE-2022-48337 there was originally[1]
> > > > +  free (new_real_name);
> > > > +  free (new_tmp_name);
> > > > in the fix that later disappeared (by accident?).
> > > > 
> > > > I would say the CVE-2022-48337 fix introduced a memory leak,
> > > > which might or might not be related to the mips64el problem.
> > > >...
> > > 
> > > I've reported this upstream as https://debbugs.gnu.org/61819
> > 
> > This is now fixed upstream with
> > http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0fde314f6f6e6664cddab1b2f0fe20629cd39d14
> 
> So this would affect as well the current unstable version, adding the
> found version for that as well.

The memory leak fixed upstream does.

While I suspect they are the same, there is no proof that this leak is 
actually the same as the mips64el installation issue.

> Regards,
> Salvatore

cu
Adrian

Bug#1032030: ITP: czkawka-gui -- Multi functional app to find duplicates, empty folders, similar images etc

[Fab Stz]

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

* Package name: czkawka-gui
  Version : 5.1.0
  Upstream Author : Rafał Mikrut 
* URL : https://github.com/qarmin/czkawka
* License : MIT
  Programming Lang: rust
  Description : Multi functional app to find duplicates, empty folders,
similar images etc

There is a GUI and a cli package:
- czkawka-gui
- czkawka-cli

Czkawka (tch-kav-ka, hiccup) is a simple, fast and free app to remove
unnecessary files from your computer.

Features:
- Written in memory safe Rust
- Amazingly fast - due to using more or less advanced algorithms and
  multithreading
- Free, Open Source without ads
- Multiplatform - works on Linux, Windows and macOS
- Cache support - second and further scans should be a lot faster than
  the first one
- CLI frontend - for easy automation
- GUI frontend - uses modern GTK 3 and looks similar to FSlint
- Rich search option - allows setting absolute included and excluded
  directories, set of allowed file extensions or excluded items with
  the * wildcard
- Multiple tools to use:
  - Duplicates - Finds duplicates basing on file name, size, hash,
first 1 MB of hash
  - Empty Folders - Finds empty folders with the help of an advanced
algorithm
  - Big Files - Finds the provided number of the biggest files in
given location
  - Empty Files - Looks for empty files across the drive
  - Temporary Files - Finds temporary files
  - Similar Images - Finds images which are not exactly the same
(different resolution, watermarks)
  - Zeroed Files - Finds files which are filled with zeros (usually
corrupted)
  - Same Music - Searches for music with same artist, album etc.
  - Invalid Symbolic Links - Shows symbolic links which points to
non-existent files/directories
  - Broken Files - Finds files with an invalid extension or that are
corrupted


This should close RFP: #1006181

fslint which did a similar job was removed from bullseye because it required
python2. This is a alternative/replacement.

Should be maintained by rust team.

Bug#1032029: mosquitto ignores ip address for websocket listeners

[Helmut Grohne]

Package: mosquitto
Version: 2.0.11-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

If you configure a websocket listener for mosquitto with an IP address
to bind to, mosquitto will instead bind the wildcard address. This
renders a secure configuration insecure.

A simple configuration producing this behaviour is a default
installation together with one config update:

$ cat /etc/mosquitto/conf.d/listen.conf
bind_address localhost
listener 9001 127.0.0.1
protocol websockets
$

If you (re)start mosquitto, you can see the insecure bind:

$ ss -tlp
...
LISTEN0 4096 *:9001   *:*   
 users:(("mosquitto",pid=269,fd=7))
...
$

The mosquitto.conf manual page in section 5 says that for websockets,
you can only give an IP address as bind address, which kinda implies
that you can given an IP address there. I think it is a reasonable
expectation that binding to 127.0.0.1 should be secure.

I am filing this as severity serious, because normally a security
vulnerability would be grave, but this vulnerability only surfaces in a
(possibly common) non-default configuration. Hence lowering to serious.

I note (mostly for myself) that the following invocation reproduces the
problem:

debvm-create -- --include iproute2,mosquitto --customize-hook='printf 
"bind_address localhost\\nlistener 9001 127.0.0.1\\nprotocol websockets\\n" > 
"$1/etc/mosquitto/conf.d/listen.conf"'

Helmut

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

[Helmut Grohne]

Hi Jussi,

On Sun, Feb 26, 2023 at 05:40:06PM +0200, Jussi Pakkanen wrote:
> I find this a bit confusing. As far as I can tell those are in the file:
> 
> https://github.com/mesonbuild/meson/blob/master/mesonbuild/scripts/env2mfile.py#L134

Mea culpa. My look into it was too brief. you're entirely right here.

> The "deb" part of this script is basically the debcrossgen script
> copypasted and slightly tweaked. I can see that there is no special
> handling for "ppc64el", but that does not exist in debcrossgen either
> and seems like a bug.

That bug has a number, it is #1019413 and has a patch.

> I also tried generating an armhf cross file and the output file had
> cpu family set to "arm" and cpu to "arm7hlf" which is the same thing
> that debcrossgen does. Even environment variables set via e.g.
> CPPFLAGS get written in the cross file.

My source review was not up to the task. I did not attempt to run it
this time as my patches got stuck in the bts for quite long.

> If this is not happening to you then it is very puzzling. Could you
> give a few more details, like the exact command you are running and
> how the generated cross file differs from what you expect?

Given that, I think you can move forward with the change post bookworm.
Thanks for bearing with me and sorry for the inadequate remarks.

Helmut

Bug#1019273: package built and lintian passed

[Louis-Philippe Véronneau]

I've had a look at this, and I'm planning on making an NMU to patch this 
package's copyright file with the proposed patch today.


Although this is an RC bug and has been open for a while, I'll make it 
DELAYED 5, so if the maintainers disagree for some reason, they should 
have plenty of time to cancel the upload.


I'll make a Merge Request on Salsa to make sure the git repo is up to 
date with the archive.


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1031888: emacs-nox: bullseye-security update fails to install on mips64el

[Salvatore Bonaccorso]

Control: found -1 1:28.2+1-11

Hi,

On Sun, Feb 26, 2023 at 08:43:11PM +0200, Adrian Bunk wrote:
> On Sun, Feb 26, 2023 at 07:47:21PM +0200, Adrian Bunk wrote:
> > On Sun, Feb 26, 2023 at 04:12:35AM +0200, Adrian Bunk wrote:
> > >...
> > > In the upstream bug for CVE-2022-48337 there was originally[1]
> > > +  free (new_real_name);
> > > +  free (new_tmp_name);
> > > in the fix that later disappeared (by accident?).
> > > 
> > > I would say the CVE-2022-48337 fix introduced a memory leak,
> > > which might or might not be related to the mips64el problem.
> > >...
> > 
> > I've reported this upstream as https://debbugs.gnu.org/61819
> 
> This is now fixed upstream with
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0fde314f6f6e6664cddab1b2f0fe20629cd39d14

So this would affect as well the current unstable version, adding the
found version for that as well.

Regards,
Salvatore

Bug#1031049: python-cryptography: diff for NMU version 38.0.4-2.1

[Salvatore Bonaccorso]

Ciao Sandro,

On Sun, Feb 26, 2023 at 01:14:28PM -0500, Sandro Tosi wrote:
> > I've prepared an NMU for python-cryptography (versioned as 38.0.4-2.1) and
> > uploaded it to DELAYED/5. Please feel free to tell me if I
> > should delay it longer.
> 
> Would you like to open an MR on salsa? that way i can merge and upload
> it - thanks

I noticed that you have on master branch imported the new upstream
version fixing it as well. If that can make it to bookworm then it
would be equally well.

But maybe a more targeted fix is better at this stage of the freeze:

https://salsa.debian.org/python-team/packages/python-cryptography/-/merge_requests/13

(note it cannot be merged cleanly though).

Regards,
Salvatore

Bug#1027551: golang-github-hashicorp-go-plugin: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/hashicorp/go-plugin github.com/hashicorp/go-plugin/internal/p

[Cyril Brulebois]

Hi,

Shengjing Zhu  (2023-01-01):
> This failure in golang-github-hashicorp-go-plugin seems to be caused
> by flaky tests. Could you try again? At least it succeeds on my
> computer currently. If it fails too frequently, I probably need to
> disable them.

This is a very elusive issue, and I've only managed to produce it once
in several dozens, then hundreds of attempts… (and all that only in a
VM).

Seeing how some other tests have been disabled already, I don't think
it's unreasonable to call this one flakky as well, and to get it out of
the way. I've just done so in the -4 upload.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1032028: gnome-text-editor: Document type overrides user selected tab-width.

[birch]

Package: gnome-text-editor
Version: 43.2-1
Severity: normal

Dear Maintainer,

When a document type is not defined setting tab-width in the drop-down 
configuration behaves as expected, but when the file is saved and identified as 
a document type or when a document type is specified manually, a pre-defined 
tab-width is used and the user selected tab-width is ignored.

Example: with Javascript selected as language tab-width is 4 spaces, regradless 
of whether the user selects "2" or "8".

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
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 gnome-text-editor depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libadwaita-1-0   1.2.2-1
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libeditorconfig0 0.12.6-0.1
ii  libenchant-2-2   2.3.3-2
ii  libglib2.0-0 2.74.5-1
ii  libgtk-4-1   4.8.3+ds-2
ii  libgtksourceview-5-0 5.6.2-1
ii  libicu72 72.1-3
ii  libpango-1.0-0   1.50.12+ds-1

gnome-text-editor recommends no packages.

gnome-text-editor suggests no packages.

-- no debconf information

Bug#538100: dash makes strange things during command substitution

[Ali Delldarr]

On Thu, 23 Jul 2009 03:25:56 +0200 Christoph Anton Mitterer
 wrote:
> Package: dash
> Version: 0.5.5.1-2
> Severity: normal
>
> Hi.
>
> I've made some scripts where I pre-process an arbitrary file name for
> some sed- and grep expressions.
> As e.g. . and / (which can occur in filenames) may have special
> meaning to sed and grep, I quote the each character of the filename
> with \ before using it further.
>
> I do about this:
> file='./data/image.oga'
> echo $file
> echo "$file"
>
> file_entry_quoted="$( printf "${file}" | sed --regexp-extended
> 's/(.)/\\\1/g' )"
> echo $file_entry_quoted
> echo "$file_entry_quoted"
>
> under bash this gives me:
> ./data/image.oga
> ./data/image.oga
> \.\/\d\a\t\a\/\i\m\a\g\e\.\o\g\a
> \.\/\d\a\t\a\/\i\m\a\g\e\.\o\g\a
>
> under dash I get:
> ./data/image.oga
> ./data/image.oga
> \.\/\d \/\i\m\g\e\.\o\g
> \.\/\d \/\i\m\g\e\.\o\g
> (that's a tab after the d, the \a seem to be replaced by 0x7)
>
>
> With the `` style of command substitution it's even "worse" in dash,...
> file_entry_quoted="` printf "${file}" | sed --regexp-extended
> 's/(.)/\\\1/g' `"
> In that case,.. each character is replaced by 0x1.
>
> The \a and 0x1 thingy is strange anyway, isn't it?
> But I'd even haven't expected that \t would be replaced as POSIX says
> (
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03
):
> "The results of command substitution shall not be processed for
> further tilde expansion, parameter expansion, command substitution, or
> arithmetic expansion. If a command substitution occurs inside
> double-quotes, field splitting and pathname expansion shall not be
> performed on the results of the substitution."
>
> Or do I misunderstand something?
>
>
> Another thing where bash and dash behave differently is:
> fo='\\'
> echo $fo
> echo "$fo"
>
> gives in bash:
> \\

Bug#1031888: emacs-nox: bullseye-security update fails to install on mips64el

[Adrian Bunk]

On Sun, Feb 26, 2023 at 07:47:21PM +0200, Adrian Bunk wrote:
> On Sun, Feb 26, 2023 at 04:12:35AM +0200, Adrian Bunk wrote:
> >...
> > In the upstream bug for CVE-2022-48337 there was originally[1]
> > +  free (new_real_name);
> > +  free (new_tmp_name);
> > in the fix that later disappeared (by accident?).
> > 
> > I would say the CVE-2022-48337 fix introduced a memory leak,
> > which might or might not be related to the mips64el problem.
> >...
> 
> I've reported this upstream as https://debbugs.gnu.org/61819

This is now fixed upstream with
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0fde314f6f6e6664cddab1b2f0fe20629cd39d14

cu
Adrian

Bug#990271: policykit-1-gnome: unmaintained upstream

[Michael Biebl]

On Thu, 24 Jun 2021 11:43:50 +0100 Simon McVittie  wrote:

Package: policykit-1-gnome
Severity: important
Tags: upstream wontfix
X-Debbugs-Cc: cinna...@packages.debian.org

As discussed on #990259, PolicyKit-gnome is no longer maintained upstream
and was archived: https://gitlab.gnome.org/Archive/policykit-gnome

The most recent non-translation change appears to have been 2011. This seems
bad for a security-sensitive component.

smcv




Let's bump this to RC in trixie so it is removed from testing then.
This should give rdeps ample notice and once all are updated, we should 
consider RMing the package.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031847: gnome-shell: Gnome crashes when laptop connected to ThinkPad Universal Thunderbolt 4 Dock (40B0), Oh no! Something has gone wrong error appears.

[Simon McVittie]

Control: tags -1 - patch

On Sat, 25 Feb 2023 at 23:33:03 +0100, Kuba wrote:
[Simon McVittie wrote:]
> > Kuba, please could you try the packages from here?
> > https://people.debian.org/~smcv/bug1031847/
> 
> Just tested colord version you linked, the issue still occurs (did not paste
> stack trace but it looks the same as one I posted originally).

That's unfortunate. Either I applied the upstream change incorrectly
(always possible!), or this is not actually the same bug that was fixed
recently in lcms2 and colord upstream.

The stack trace that you quoted looks like it could be memory corruption,
so it's not necessarily entirely obvious how to link a stack trace to
a root cause, and there might be more than one situation that leads to a
similar stack trace.

I think I've reached the limits of what I can do here, unless my
employer-provided docking station and screen happen to be able to
trigger this crash: please can someone with better knowledge of lcms2
and/or colord, or someone with hardware where this can be reproduced,
take a look?

It might still be worthwhile to get
https://github.com/hughsie/colord/pull/146 into colord even though it
doesn't resolve Kuba's crash report.

> the steps I used : 1) installed downloaded packages with `dpkg -i`, 2)
> rebooted machine, 3) logged in and connected dock station

Thanks, yes, rebooting after installing an attempt at a fix is the most
reliable way to make sure you're using the new package.

smcv

Bug#1031049: python-cryptography: diff for NMU version 38.0.4-2.1

[Sandro Tosi]

> I've prepared an NMU for python-cryptography (versioned as 38.0.4-2.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

Would you like to open an MR on salsa? that way i can merge and upload
it - thanks

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1032027: linux: i_reserved_data_blocks (2) not cleared

[Sergey Aleynikov]

Source: linux
Severity: normal
X-Debbugs-Cc: sergey.aleynikov+...@gmail.com

Dear Maintainer,

I have the following disk configuration:

sda  8:00 14.6T  0 disk
└─disk6254:00 14.6T  0 crypt
  └─disk6-part1254:10 14.6T  0 part
└─md09:00 58.2T  0 raid6
  ├─md0p1  259:70  128G  0 part  /
  └─md0p2  259:80 58.1T  0 part
sdb  8:16   0 14.6T  0 disk
└─disk2254:80 14.6T  0 crypt
  └─disk2-part1254:90 14.6T  0 part
└─md09:00 58.2T  0 raid6
  ├─md0p1  259:70  128G  0 part  /
  └─md0p2  259:80 58.1T  0 part
sdc  8:32   0 14.6T  0 disk
└─disk3254:60 14.6T  0 crypt
  └─disk3-part1254:70 14.6T  0 part
└─md09:00 58.2T  0 raid6
  ├─md0p1  259:70  128G  0 part  /
  └─md0p2  259:80 58.1T  0 part
sdd  8:48   0 14.6T  0 disk
└─disk1254:10   0 14.6T  0 crypt
  └─disk1-part1254:11   0 14.6T  0 part
└─md09:00 58.2T  0 raid6
  ├─md0p1  259:70  128G  0 part  /
  └─md0p2  259:80 58.1T  0 part
sde  8:64   0 14.6T  0 disk
└─disk4254:40 14.6T  0 crypt
  └─disk4-part1254:50 14.6T  0 part
└─md09:00 58.2T  0 raid6
  ├─md0p1  259:70  128G  0 part  /
  └─md0p2  259:80 58.1T  0 part
sdf  8:80   0 14.6T  0 disk
└─disk5254:20 14.6T  0 crypt
  └─disk5-part1254:30 14.6T  0 part
└─md09:00 58.2T  0 raid6
  ├─md0p1  259:70  128G  0 part  /
  └─md0p2  259:80 58.1T  0 part

Device md0 is constructed on top of 6x cryptsetup disks as following:

md0 : active raid6 dm-11[6] dm-9[4] dm-7[3] dm-5[2] dm-3[7] dm-1[0]
  62499463424 blocks super 1.2 level 6, 64k chunk, algorithm 2 [6/6] 
[UU]

Root filesystem is mounted from md0p1 with the following options:

UUID=bff1f017-bca2-4acc-9b97-170474c5e198 /  ext4
noatime,nodelalloc,barrier=1,data=ordered 0   1

I've recently observed the following error in dmesg:

[163925.493694] EXT4-fs (md0p1): Inode 6562253 (b30df460): 
i_reserved_data_blocks (2) not cleared!

It haven't repeated since. Messages preceeding it are from kvm, like this one:

[163814.292207] kvm [31458]: ignored rdmsr: 0x1a2 data 0x0

Does this mean a filesystem corruption? Do I need to take any additional steps 
(like force fsck), or would it recover silently?

-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-21-amd64 (SMP w/56 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#1032026: ITP: heart -- Card game about avoiding having to take tricks

[Benedikt Straub]

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

* Package name    : heart
  Version : 0.1
  Upstream Contact: Benedikt Straub 
* URL : https://github.com/Noordfrees/Heart
* License : GPL-3
  Programming Lang: Java
  Description : Card game about avoiding having to take tricks

Heart (also known as Hearts) is a popular card game for four players
with the aim of gaining as few points as possible. The game is played
over several rounds until one or more players reach 100 points.
In my implementation a single human player plays against 3 computer players.

There used to be a similar game in the Debian and Ubuntu repos,
but it was removed long ago due (iirc) to being defunctional.
This is a reasonably well-known, small-ish game concept that is
a great way of wasting time, so having a Hearts-like game in
the repos again would be much appreciated.

I added a basic, functional debian packaging dir to my lightweight
Java-based Heart implementation (see GitHub link above).
I am also prepared to perform all maintenance that may be
needed for this package in the future.

I would be honored if my game were accepted into the official repos.

Best regards,
Benedikt Straub

Bug#1031966: python-pydata-sphinx-theme-doc is empty

[Sandro Tosi]

> It seems this is the result of the doc not being built in Debian, since
> it requires ipywidgets 7 and we have version 6.
>
> The fix for this is probably to stop building
> python-pydata-sphinx-theme-doc altogether, but I'll let Sandro have a go
> at this :)

given this package is part of the sphinx documentation ecosystem, i
dont think it's appropriate to drop entirely its -doc package (as i've
done for other projects before), it's a way to showcase what hte
package can do.

OTOH i am not going to attempt to package ipywidgets 7 just for this package.

What should i do to not make it RC? just ship some dummy files in the
package? TBH I'd just downgrade this bug report to important and move
on to something more interesting (after all, it's been like this since
Oct 2021)

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1031888: emacs-nox: bullseye-security update fails to install on mips64el

[Adrian Bunk]

On Sun, Feb 26, 2023 at 04:12:35AM +0200, Adrian Bunk wrote:
>...
> In the upstream bug for CVE-2022-48337 there was originally[1]
> +  free (new_real_name);
> +  free (new_tmp_name);
> in the fix that later disappeared (by accident?).
> 
> I would say the CVE-2022-48337 fix introduced a memory leak,
> which might or might not be related to the mips64el problem.
>...

I've reported this upstream as https://debbugs.gnu.org/61819

cu
Adrian

Bug#1031548: FTBFS with ruby-jekyll-github-metadata 2.15.0

[Adrian Bunk]

On Sun, Feb 26, 2023 at 04:32:59PM +0100, Daniel Leidert wrote:
> Am Sonntag, dem 26.02.2023 um 16:57 +0200 schrieb Adrian Bunk:
> > On Sun, Feb 26, 2023 at 03:47:49PM +0100, Daniel Leidert wrote:
> > > Am Samstag, dem 25.02.2023 um 16:15 +0200 schrieb Adrian Bunk:
> > > 
> > > [..]
> > > > FYI:
> > > > 
> > > > The package in bookworm builds with jekyll-github-metadata
> > > > 2.15.0:
> > > > https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/ruby-jekyll-remote-theme.html
> > > > (the buildinfo link has the complete package list)
> > > 
> > > That is due to this environments not running the failing test. The
> > > test-file checks if there is an internet connection and adds or
> > > removes
> > > tests depending on the outcome). The test in question is one that
> > > requires an internet connection.
> > > ...
> > 
> > Accessing the internet during the build is an RC bug.
> 
> It would be pretty stupid to generally disable tests for a *remote
> theme* plugin (or any other package) that by defition relies on the
> internet. This would disable the majority of tests here. We (as in "the
> Ruby team") instead handle the tests if there is no internet, and
> whenever possible, run them via autopkgtest (needs-internet
> restriction) at least.
> 
> IMHO this is a valid approach and in this case spotted a regression. To
> my understanding, builds must not fail due to access attempts and the
> build itself must not rely on downloaded resources. However, this is
> the test stage, not the build stage. But if you feel that strongly
> about that, please show me the exact ruling.
>...

Debian Policy §4.9 says that *attempting* to access the internet
is forbidden:

  For packages in the main archive, required targets must not attempt 
  network access, except, via the loopback interface, to services on the 
  build host that have been started by the build.

Your additional approach via autopkgtest with the needs-internet 
restriction is a good way to test such packages.

I am adding debian-devel to Cc, where other people have more knowledge 
on that topic than I have.

> Daniel

cu
Adrian

Bug#1031966: python-pydata-sphinx-theme-doc is empty

[Louis-Philippe Véronneau]

block 1031966 by 896460
user debian-rele...@lists.debian.org 


usertag 1031966 + bsp-2023-02-ca-montreal
thanks

It seems this is the result of the doc not being built in Debian, since 
it requires ipywidgets 7 and we have version 6.


The fix for this is probably to stop building 
python-pydata-sphinx-theme-doc altogether, but I'll let Sandro have a go 
at this :)


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1027321: lxd init run as non-root fails to find LVM thin provisioning tools

[Mathias Gibbens]

Control: forwarded -1 https://github.com/lxc/lxd/issues/11411


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

Bug#1032004: nmu: packages built by golang-1.15

[Sebastian Ramacher]

On 2023-02-26 20:56:21 +0800, Shengjing Zhu wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> X-Debbugs-Cc: z...@debian.org
> 
> Hi,
> 
> Maybe there's bug in the scripts to rebuild for outdated Built-Using.
> There are still packages built by golang-1.15.
> 
> $ grep-dctrl -r -s Package -F Built-Using 'golang-1.1[0-8]' 
> /var/lib/apt/lists/*debian_dists_testing_main_binary-amd64_Packages
> Package: codesearch
> Package: ffuf
> Package: tmpl
> Package: fernet-go
> Package: blueprint-tools
> Package: cli-spinner
> Package: ripper
> Package: golang-statik
> Package: golang-github-rsc-devweb
> Package: goxkcdpwgen
> Package: heartbleeder
> Package: hellfire
> Package: opensmtpd-filter-rspamd
> Package: opensmtpd-filter-senderscore

Interestingly, those packages do not appear on
https://ftp-master.debian.org/users/ansgar/outdated-built-using.txt. I
suppose the reason is that for those packages the new_version column
cannot be filed.

Unless somebody beats me to it, I'll schedule binNMUs for those above
the next time I do outdated-ESO rebuilds.

Best
Sebastian
-- 
Sebastian Ramacher

Bug#1032025: python-vispy: add autopkgtest

[Étienne Mollier]

Source: python-vispy
Version: 0.6.6-2
Severity: wishlist
Tags: newcomer

It might be worth adding some self test to the python-vispy
package.  When python3-pytest is installed, vispy allows one to
run some self-tests using python3 commands:

import vispy
vispy.test()

Careful: a few of these tests require Internet connectivity, so
it will be preferable to identify and disable them first; tests
requiring Internet tend to become flaky or non-functional when
time passes.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-on air: I Am The Manic Whale - Celebrity


signature.asc
Description: PGP signature

Bug#1032024: amd64-microcode: Use non-native package format

[Bastian Germann]

Source: amd64-microcode
Version: 3.20220411.2

amd64-microcode uses source format 3.0 (native) even though it has an upstream.
It should use 3.0 (quilt) instead, using "-" instead of "." to separate the 
Debian revision.

Bug#1032023: intel-microcode: Use non-native package format

[Bastian Germann]

Source: intel-microcode
Version: 3.20221108.2

autotools-dev uses source format 3.0 (native) even though it has an upstream.
It should use 3.0 (quilt) instead, using "-" instead of "." to separate the 
Debian revision.

Bug#1032022: autotools-dev: Use non-native package format

[Bastian Germann]

Source: autotools-dev
Version: 20220109.1

autotools-dev uses source format 3.0 (native) even though it has an upstream.
It should use 3.0 (quilt) instead, using "-" instead of "." to separate the 
Debian revision.

Bug#1032021: RM: microcode.ctl -- RoQA; transitional package in several releases

[Bastian Germann]

Package: ftp.debian.org

Please remove microcode.ctl from unstable/testing. It has been a transitional 
package for over a decade.

Bug#1031950: libgeo-distance-perl should add Breaks and Replaces on libgeo-distance-xs-perl

[gregor herrmann]

On Sat, 25 Feb 2023 23:08:52 +0100, gregor herrmann wrote:

> I just don't understand the "Replaces" part in the subject, as
> Geo::Distance::XS is not shipped (or is this need for the removal?
> This part tends to confuse me).

Seem to work:

Breaks: libgeo-distance-xs-perl
Replaces: libgeo-distance-xs-perl


The following packages will be REMOVED:
  libgeo-distance-xs-perl
The following packages will be upgraded:
  libgeo-distance-perl
1 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B/16.5 kB of archives.
After this operation, 66.6 kB disk space will be freed.
Do you want to continue? [Y/n] y
Get:1 
/home/gregoa/src/git-pkg-perl/meta/packages/build-area/libgeo-distance-perl_0.25-3_all.deb
 libgeo-distance-perl all 0.25-3 [16.5 kB]
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 11009 files and directories currently installed.)
Removing libgeo-distance-xs-perl (0.13-3+b1) ...
(Reading database ... 10991 files and directories currently installed.)
Preparing to unpack .../libgeo-distance-perl_0.25-3_all.deb ...
Unpacking libgeo-distance-perl (0.25-3) over (0.25-2) ...
Setting up libgeo-distance-perl (0.25-3) ...



Cheers,
gregor


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1032011: Fwd: Bug#1032011: gettext: Private library should go to private subdir under lib

[Bastien Roucariès]

Le dimanche 26 février 2023, 15:49:52 UTC Bruno Haible a écrit :
> Santiago Vila wrote:
> >  Mensaje reenviado 
> > Asunto: Bug#1032011: gettext: Private library should go to private subdir 
> > under lib
> > Fecha: Sun, 26 Feb 2023 14:57:45 +
> > De: Bastien Roucariès 
> > Responder a: Bastien Roucariès , 1032...@bugs.debian.org
> > Para: Debian Bug Tracking System 
> > 
> > Package: gettext
> > Version: 0.21-11
> > Severity: minor
> > Tags: upstream
> > 
> > Dear Maintainer,
> > 
> > Private library /libgettextsrc-0.21.so and libgettextlib-0.21.so should go 
> > to
> > private sudbir aka:
> > usr/lib/x86_64-linux-gnu/gettext/libgettextsrc-0.21.so
> > and
> > usr/lib/x86_64-linux-gnu/gettext/libgettextlib-0.21.so
> > 
> > This is an upstream bug that should be reported
> 
> Summary:
> 
> - Doing so upstream would violate both the GNU Coding Standards and the
>   File system Hierarchy Standard.
> 
> - You can do such things at the distro level, if you make sure that the
>   dynamic linker will find the libraries there.
> 
> Details:
> 
> Upstream, I have to respect two standards:
> 
>   * The GNU Coding Standards [1] say that ${libdir) is "The directory for
> object files and libraries of object code." Very simple and unambiguous.
> 
>   * The File system Hierarchy Standard [2] gives me the choice between
> installing in /usr/lib or /usr/lib/gettext.
> But what you proposed is not /usr/lib/gettext, it is a subdirectory of
> /usr/lib/x86_64-linux-gnu !

Please install at usr/lib/gettext not /usr/lib ... The arch stuff is distro 
stuff I agree

Bastien
> 
> At the distro level, the distro decides where to put things. But if you
> put shared libraries in /usr/lib/x86_64-linux-gnu/gettext/ you will
> either have to make sure that this directory is known to ld.so (via
> ld.so.conf, I guess), or use RPATH headers in the binaries (which many
> distributions don't like to do).
> 
> Note that in future gettext versions, libgettextlib may be integrated
> into libgettextsrc. So, we would be talking about a subdirectory for just
> a single library.
> 
> Bruno
> 
> [1] https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
> [2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html
> 
> 
> 
> 



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

Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.

[Will B.]

Package: chromium
Version: 110.0.5481.177-1
Severity: important
Tags: upstream
X-Debbugs-Cc: ksu...@gmail.com

Dear Maintainer,

Before I begin, the Chromium AppArmor profile in Sid was updated after apt-get
update && apt-get upgrade.
Please redirect to relevant authority if Chromium reportbug is not the right
source.

   ///

* What led up to the situation? -> Chromium AppArmor profile update after apt-
get update && apt-get upgrade.
* What exactly did you do (or not do) that was effective (or ineffective)? ->
fixed the issue by adding a missing "/" to the profile.
* What was the outcome of this action? -> The Chromium AppArmor profile
restricted access as it should have done.
* What outcome did you expect instead? -> None, fix fixed it.

  ///

Hi,

After a Chromium Sid update in which the AppArmor profile was updated (last
date -> 02/07/2023),
a missing "/" opened up browsing to the whole system i.e. -> "/** r," instead
of "/**/ r,".
Switching to the "enclosed" stars symbol fixes the issue.

Regards


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

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

Versions of packages chromium depends on:
ii  chromium-common  110.0.5481.177-1
ii  libasound2   1.2.8-1+b1
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libatomic1   12.2.0-14
ii  libatspi2.0-02.46.0-5
ii  libbrotli1   1.0.9-2+b6
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libcups2 2.4.2-1+b2
ii  libdbus-1-3  1.14.6-1
ii  libdouble-conversion33.2.1-1
ii  libdrm2  2.4.114-1
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libexpat12.5.0-1
ii  libflac121.4.2+ds-2
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libgbm1  22.3.3-1
ii  libgcc-s112.2.0-14
ii  libglib2.0-0 2.74.5-1
ii  libgtk-3-0   3.24.36-4
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjsoncpp25 1.9.5-4
ii  liblcms2-2   2.14-1+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libopenjp2-7 2.5.0-1+b1
ii  libopus0 1.3.1-3
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpng16-16  1.6.39-2
ii  libpulse016.1+dfsg1-2+b1
ii  libre2-9 20220601+dfsg-1+b1
ii  libsnappy1v5 1.1.9-2
ii  libstdc++6   12.2.0-14
ii  libwebp7 1.2.4-0.1
ii  libwebpdemux21.2.4-0.1
ii  libwebpmux3  1.2.4-0.1
ii  libwoff1 1.0.2-2
ii  libx11-6 2:1.8.3-3
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxkbcommon01.5.0-1
ii  libxml2  2.9.14+dfsg-1.1+b3
ii  libxnvctrl0  525.85.05-1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxslt1.1   1.1.35-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  

Bug#1032019: python3.11: deadlock on interpreter shutdown waiting for threads

[Dominik George]

Package: python3.11
Version: 3.11.2-4
Severity: important
Tags: upstream fixed-upstream
Forwarded: https://github.com/python/cpython/issues/102126

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Python 3.11.2 introduced a deadlock on interpreter shutdown
when using threads, causing quite a few libraries and tools
to hang on exit.

  https://github.com/python/cpython/issues/102126

Fixed upstream; reporting here to track for bookworm.


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3.11 depends on:
ii  libpython3.11-stdlib  3.11.1-2
ii  media-types   9.0.0
ii  mime-support  3.66
ii  python3.11-minimal3.11.1-2

python3.11 recommends no packages.

Versions of packages python3.11 suggests:
ii  binutils 2.40-2
pn  python3.11-doc   
ii  python3.11-venv  3.11.1-2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iMAEARYKAGgWIQSk6zxRYJYchegBkTEK5VTlRg4b3QUCY/uJxjEaaHR0cHM6Ly93
d3cuZG9taW5pay1nZW9yZ2UuZGUvZ3BnLXBvbGljeS50eHQuYXNjGBxuYXR1cmVz
aGFkb3dAZGViaWFuLm9yZwAKCRAK5VTlRg4b3Qr9AQC6ZJlTqYQ02kLfhD2oblIV
2yPkIEDk5Mbqu2pTG/eCbAD+MGLRKuibJkB6EFwcP7O8C6NgV00iGcKxGqzBp/ok
IAg=
=JbNH
-END PGP SIGNATURE-

Bug#1032013: terminator retitle bugs

[Louis-Philippe Véronneau]

retitle 901245 terminator: x-terminal-emulator -c stumbles upon shell oneliner
severity 901245 normal
found 901245 2.1.2-1
retitle 1032013 terminator: --execute flag is broken
thanks

I've split this bug in two, since it's actually two different bugs.

The original bug about "-c " is different from the one John reported about
the --execute flag being broken.

I'll upload a patch for 1032013 today, but I won't be fixing the original bug.
In my opinion, it's not as severe as 1032013, as it's not a policy violation.

Cheers,

--
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
   ⠈⠳⣄

Bug#1030300: intel-microcode: move package from non-free to non-free-firmware

[Bastian Germann]

Control: fixed 1030300 3.20221108.2

As far as I can see this was solved.

Bug#1032018: accounts-daemon: enable full hardening flags

[Christian Göttsche]

Source: accountsservice
Version: 22.08.8-6
Tags: security,patch

Dear Maintaner,

please enable full hardening flags for accounts-daemon; in particular
currently the link feature BINDNOW[1] is missing.
As accounts-daemon is a long running daemon any potential startup
costs are negligible.


[1]: 
https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_BINDNOW_.28ld_-z_now.29


--- rules.bak   2023-02-26 17:22:41.371721516 +0100
+++ rules   2023-02-26 17:22:52.163547706 +0100
@@ -1,6 +1,7 @@
#!/usr/bin/make -f
# -*- makefile -*-

+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed

binaries := $(shell dh_listpackages)

Bug#1032017: UDD/dmd: Lists non-merged bug counts

[Guillem Jover]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

Hi!

In the "Bugs, security issues and Quality Assurance Checks" table, the
bug counts seem to be including duplicate bugs, which seems unexpected.
I'd say it should preferably only list merged bug counts. But if there's
any reason for the non-merged counts then perhaps make it configurable
like in DDPO?

Thanks,
Guillem

Bug#1032016: RFS: vnstat/2.10-2 -- console-based network traffic monitor

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : vnstat
   Version  : 2.10-2
   Upstream contact : Teemu Toivola 
 * URL  : https://humdi.net/vnstat/
 * License  : GPL-any, GPL-2
 * Vcs  : https://salsa.debian.org/debian/vnstat
   Section  : net

The source builds the following binary packages:

  vnstat - console-based network traffic monitor
  vnstati - image output support for vnStat

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.10-2.dsc

Changes since the last upload:

 vnstat (2.10-2) unstable; urgency=medium
 .
   [ Alexandre Detiste ]
   * register volative files with dh-cruft
   * remove obsolete dependency on lsb-base
 .
   [ Christian Göttsche ]
   * d/control:
 - sort build depends
 - minimize nocheck build depends
 - bump to std version 4.6.2 (no further changes)
   * d/copyright: update year

Regards,
   Christian Göttsche