Bug#1073012: Automatically rewrite incoming entries from some CNAs as NFUs

[Moritz Muehlenhoff]

Package: security-tracker
Severity: wishlist

These days the scopes of CNAs are usually narrow and scoped to a specific 
vendor.
We should leverage this for pre-processing incoming data and to reduce toil.

We can do this by extending the "automatic update" job to automatically 
annotate CVEs assigned
by a given CNA as NFU entries. As an example all CVEs coming from the 
"Wordfence" CNA should
be automatically added as "NOT-FOR-US: WordPress plugin". This avoids 
cumbersome manual
triage (and review would still happen on the commited entries).

Same for many commercial software vendors, e.g. a company like SAP which has no 
ties to
FLOSS everything coming from their CNA should automatically be added as 
"NOT-FOR-US: SAP"
without human interaction. We should only extend this on a case-by-case basis. 
E.g. Oracle
has a lot of propietary software, but they also maintain mysql, Java and 
virtualbox, so
they need manual review still.

Cheers,
Moritz

Bug#1073011: nmu: cgal_5.6.1-1

[Steven Robbins]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: c...@packages.debian.org, Joachim Reichel 

Control: affects -1 + src:cgal
User: release.debian@packages.debian.org
Usertags: binnmu

New version of Ipe has been uploaded, which cgal uses.

nmu cgal_5.6.1-1 . ANY . unstable . -m "Rebuild against libipe 7.2.30"


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

Bug#1073010: Crash on every beamer pdf re-compilation

[julien . puydt]

Package: evince
Version: 46.3-1
Severity: important

Since a few days I noticed (but the problem could be weeks old before I
noticed), evince crashes when it displays a pdf that is being re-
compiled from latex.

It is a beamer in presentation view, in case it matters - but obviously
reproducing the issue would be more efficient.

Setting severity to important because a crash does impact the
usefulness of the software, even though it doesn't make it completely
useless.

Cheers,

J.Puydt

PS: I ran evince in gdb and tried to reproduce the crash ; here is what
the end of the log looks like:

[New Thread 0x7f1b492006c0 (LWP 830981)]

(evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: instance of
invalid non-instantiatable type 'GEnum'

(evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417:
g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE
(instance)' failed

(evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417:
g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: instance of
invalid non-instantiatable type '(null)'

(evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417:
g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE
(instance)' failed

(evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417:
g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: instance of
invalid non-instantiatable type ''

(evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417:
g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE
(instance)' failed

(evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417:
g_object_unref: assertion 'G_IS_OBJECT (object)' failed
[Thread 0x7f1b420006c0 (LWP 830967) exited]
[Thread 0x7f1b492006c0 (LWP 830981) exited]
[New Thread 0x7f1b492006c0 (LWP 830988)]
[New Thread 0x7f1b420006c0 (LWP 830989)]

Thread 1 "evince" received signal SIGSEGV, Segmentation fault.
0x7f1b581d2205 in g_type_check_instance () from /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
(gdb) bt
#0  0x7f1b581d2205 in g_type_check_instance () at /lib/x86_64-
linux-gnu/libgobject-2.0.so.0
#1  0x7f1b581c7788 in g_signal_handlers_disconnect_matched () at
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2  0x7f1b5829e0f5 in  () at /lib/x86_64-linux-gnu/libevview3.so.3
#3  0x7f1b5829e200 in  () at /lib/x86_64-linux-gnu/libevview3.so.3
#4  0x7f1b581b204b in g_object_unref () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#5  0x55cee218ba7f in  ()
#6  0x7f1b581ac730 in g_closure_invoke () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#7  0x7f1b581c087c in  () at /lib/x86_64-linux-gnu/libgobject-
2.0.so.0
#8  0x7f1b581c2281 in  () at /lib/x86_64-linux-gnu/libgobject-
2.0.so.0
#9  0x7f1b581c7f06 in g_signal_emit_valist () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#10 0x7f1b581c7fc3 in g_signal_emit () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#11 0x7f1b581b0924 in  () at /lib/x86_64-linux-gnu/libgobject-
2.0.so.0
#12 0x7f1b581b43b9 in g_object_notify () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#13 0x55cee2184231 in  ()
#14 0x7f1b581ac730 in g_closure_invoke () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#15 0x7f1b581c087c in  () at /lib/x86_64-linux-gnu/libgobject-
2.0.so.0
#16 0x7f1b581c2281 in  () at /lib/x86_64-linux-gnu/libgobject-
2.0.so.0
#17 0x7f1b581c7f06 in g_signal_emit_valist () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#18 0x7f1b581c7fc3 in g_signal_emit () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#19 0x7f1b582772db in  () at /lib/x86_64-linux-gnu/libevview3.so.3
#20 0x7f1b580a3dff in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x7f1b580a5e87 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x7f1b580a64a0 in g_main_context_iteration () at /lib/x86_64-
linux-gnu/libglib-2.0.so.0
#23 0x7f1b5741a43d in g_application_run () at /lib/x86_64-linux-
gnu/libgio-2.0.so.0
#24 0x55cee2173063 in main ()

Bug#1073009: doesn't work with SQLAlchemy 2.X

[Piotr Ożarowski]

Source: openstack-trove
Version: 1:21.0.1-2 
Severity: serious
Tags: ftbfs

Hi,

I uploaded SQLAlchemy 2.X to unstable and openstack-trove currently
FTBFS due to failing tests (tries to import sqlalchemy.databases which
is no longer available) so the code is definitely not ready for SA 2.X.

I gues you're well aware of this, reporting to keep track of what needs
to be done.

Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration

[Otto Kekäläinen]

Good, looks like you got the hang of it.

I will post my suggestion that involves having a config similar to
https://salsa.debian.org/debian/entr/-/blob/debian/latest/debian/gbp.conf
but upstream as 'main' and some other tweaks for easier long-term
maintainability, along with explanation why my suggestion is what it is.

Are you ok hosting the package in salsa.debian.org/debian namespace?
Or at least mirror it there?

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Hi Marc

Certainly. If you know those I'm happy to fix them.

I thought I had fixed them all already.

Cheers

// Ola

On Tue, 11 Jun 2024 at 15:52, Marc Haber  wrote:
>
> On Mon, Jun 10, 2024 at 11:02:30PM +0200, Ola Lundqvist wrote:
> > Sorry, I meant to run with dash -x. Or do dash not have that option?
>
> It has this option.
>
> But I see a problem in cron-apt using bashisms while using the /bin/sh
> shebang line. I don't know whether this have to do with this, bug, but
> it should be fixed anyway.
>
> Greetings
> Marc
>
> --
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#1058130: closed by Debian FTP Masters (reply to Ulises Vitulli ) (Bug#1058130: fixed in python-nmea2 1.19.0-1)

[Sergio Durigan Junior]

Control: tags -1 + patch

On Tuesday, May 14 2024, Adrian Bunk wrote:

> Control: reopen -1
>
> On Mon, Feb 12, 2024 at 10:57:03PM +, Debian Bug Tracking System wrote:
>>...
>>  python-nmea2 (1.19.0-1) unstable; urgency=medium
>>  .
>>* New upstream release (Closes: #1058130).
>>...
>> Relevant part (hopefully):
>> >  fakeroot debian/rules clean
>> > dh clean --with python3 --buildsystem=pybuild
>> >dh_auto_clean -O--buildsystem=pybuild
>> > I: pybuild base:310: python3.12 setup.py clean 
>> > Traceback (most recent call last):
>> >   File "/<>/setup.py", line 3, in 
>> > import imp
>> > ModuleNotFoundError: No module named 'imp'
>> > E: pybuild pybuild:395: clean: plugin distutils failed with: exit code=1: 
>> > python3.12 setup.py clean 
>> > dh_auto_clean: error: pybuild --clean -i python{version} -p "3.12 3.11" 
>> > returned exit code 13
>> > make: *** [debian/rules:7: clean] Error 25
>>...
>
> The fix is not included in 1.19.0-2:
> https://buildd.debian.org/status/fetch.php?pkg=python-nmea2=all=1.19.0-2=1715629490=0

Upstream has not made a proper release yet; the following debdiff fixes
the issue meanwhile.

Thanks,

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

diff -Nru 
python-nmea2-1.19.0/debian/patches/0001-Python-3.12-compatibility-164.patch 
python-nmea2-1.19.0/debian/patches/0001-Python-3.12-compatibility-164.patch
--- python-nmea2-1.19.0/debian/patches/0001-Python-3.12-compatibility-164.patch 
1969-12-31 19:00:00.0 -0500
+++ python-nmea2-1.19.0/debian/patches/0001-Python-3.12-compatibility-164.patch 
2024-06-11 13:55:12.0 -0400
@@ -0,0 +1,72 @@
+From: Simon H 
+Date: Sun, 11 Feb 2024 17:59:59 +
+Subject: Python 3.12 compatibility (#164)
+
+* Removed depreciated `imp` and replaced with `importlib`
+
+* Updated meta classifiers to include newer Python versions
+
+* Added Python3.12 into github workflow action
+
+* Updated workflow to test all versions we say we do
+
+* Tidied mixed markup styles
+
+* Assed Windows and MacOS to tests
+
+* Updated depreciated setup-python action to v5
+
+* Adding Python3.12 to Action
+
+* Removed my test branch from Actions
+
+Origin: backport, 
https://github.com/Knio/pynmea2/commit/802bfb627eb05a1ee655854dd261800061322b9a
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058130
+
+This patch has been adjusted to contain only the necessary bits from
+setup.py.  All the other changes were dropped.
+---
+ setup.py | 24 ++--
+ 1 file changed, 22 insertions(+), 2 deletions(-)
+
+diff --git a/setup.py b/setup.py
+index facd391..d9d3eb8 100644
+--- a/setup.py
 b/setup.py
+@@ -1,7 +1,24 @@
++import importlib.machinery
++import importlib.util
++
+ from setuptools import setup
+ 
+-import imp
+-_version = imp.load_source("pynmea2._version", "pynmea2/_version.py")
++
++def load_source(modname, filename):
++"""Load a source file and return its module object.
++
++From: https://docs.python.org/3.12/whatsnew/3.12.html#imp
++"""
++loader = importlib.machinery.SourceFileLoader(modname, filename)
++spec = importlib.util.spec_from_file_location(modname, filename, 
loader=loader)
++module = importlib.util.module_from_spec(spec)
++# The module is always executed and not cached in sys.modules.
++# Uncomment the following line to cache the module.
++# sys.modules[module.__name__] = module
++loader.exec_module(module)
++return module
++
++_version = load_source("pynmea2._version", "pynmea2/_version.py")
+ 
+ setup(
+ name='pynmea2',
+@@ -29,6 +46,9 @@ setup(
+ 'Programming Language :: Python :: 3.7',
+ 'Programming Language :: Python :: 3.8',
+ 'Programming Language :: Python :: 3.9',
++'Programming Language :: Python :: 3.10',
++'Programming Language :: Python :: 3.11',
++'Programming Language :: Python :: 3.12',
+ 'Programming Language :: Python :: Implementation :: PyPy',
+ 'Topic :: Scientific/Engineering :: GIS',
+ 'Topic :: Software Development :: Libraries :: Python Modules',
diff -Nru python-nmea2-1.19.0/debian/patches/series 
python-nmea2-1.19.0/debian/patches/series
--- python-nmea2-1.19.0/debian/patches/series   1969-12-31 19:00:00.0 
-0500
+++ python-nmea2-1.19.0/debian/patches/series   2024-06-11 13:55:12.0 
-0400
@@ -0,0 +1 @@
+0001-Python-3.12-compatibility-164.patch


signature.asc
Description: PGP signature

Bug#1073007: rust-object: please upgrade to v0.35

[Jonas Smedegaard]

Source: rust-object
Version: 0.32.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to, or separately provide, branch v0.35.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZokBwACgkQLHwxRsGg
ASEEzA//TFdb6wgvGKU5+NPvgttVSP6T2xEpU0/YKXgR93ibeKW+wmPCWbqNj+ul
V1Hji+5NwwMYmUxZgAQnH4BobxlYAlCKdEyaCgc4lbfuRjZ3bXSJjyKwMqvo5ocj
8Fv2zKcsTmUOUc0xqjYdspQgFR32foy3+DNTtLxIQQHQi9ZHo5ws6XWx2xAtu2Fv
ZaautU2Ya38+pfhSRMHpsLi9OYmE2Gpaooh7DUNXCAmeU9jPsmgylZOkeLABSVD9
GWeEo7JOIUXX6FgZaqwsHgE5ochV1eDDqvwesmZd91z/nhX9pwipDR6dcP/5h5AN
a+ulH/4ZfPDBUGMunj8CNs6FUmmIcZQcBPNdUYYbLJZLXF3atI49kHj+npLfPbWu
PW7vc27X+wb1NisWhFx7Eci5flCc6HzqGaEeJ1CLG5Za3cPpDVMoMxp+Mppoe4Ut
r/nlAmJbiljDfT2imk/6Iq24aZI3jkK36t7JA0zDnCouaT5hdxVJTk6jr7wOOtHI
Crc/L8GYqtybvNnbxsM5UB717tL+r2/jzcnO6hVORrneLVLsDRi4RLf+P3XCRpe3
0GVRfswWF6PmTWz7atVqWR27JwKqiZidGftpvqcFkj68i0+uVh0euJ1/lv5LW4je
rzGt/c68/rIklnJrErw9Wlp6+eacCBx8W0KRdjE0CnQYy4nwOw0=
=1y8t
-END PGP SIGNATURE-

Bug#1073006: rust-gimli: please upgrade to v0.29

[Jonas Smedegaard]

Source: rust-gimli
Version: 0.28.1-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to, or separately provide, v0.29.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZojh4ACgkQLHwxRsGg
ASFd6w/8CQvrJw8+BMlxRPF5Fs21xnsfXuDeA+m5HnQDHCII2KTziMVZHNniduxB
wMfVLOpxicNkFkgGa5oDl9jZmJPIutshmcaa/JpmkSBqA9hMTLJ5ld3C9Y07b362
4E3Gb714PT47odD6mo7qJyrkwlckncukVRUJXB/Gq9xIRi8fzYBVe1XBoa/1i/ge
AWYPmELImO+ce2CPkOPRmKkYzMW5PPWTFIGOIXMO4hC8y7WTImf4JuyiPJZTOc0J
1++c6umQyfyfCvwb9KBkFKYm67fpN6bK5a+hbkyobFG03w4mM8YrtJHmbBTGB4QZ
qN8YhWdJ+epKkrdFLAYIXE9HkRtu0AT7YtjGprBr3JZimj2sRz9HOEkW5oe53dUR
+UIrYGBwa8bX/g2AYFznwC6+ern4KFDtKY8WjgmubsgL6yFv2U7YyrV0RYWxp4JT
AbOG1jtP2tgZVpJiwVbOc/frCFz/zgyo+Oo7nXkv7D+yRCSPf2lpbCSMa/qKZJ54
p3YbR3RPOoGqZFz+JdIC0E+9pMS1n+jBDjso8OSRnDkCMzs8hrwG0nuAF5x8OMDg
klac/i+jhKdStGgVTV4VM1cfDY754r5QaBG3jUlUlKHuprVfV0Yy9RzhLtZNcE2L
nj221Kv2Lf5Ld+Ri9yQ2CCxhXgNWD6gvN4wOnZ1Rw6D2i0YfAiY=
=OYsQ
-END PGP SIGNATURE-

Bug#1073005: transmission: consider switching back to vendored libb64

[Jeremy Bícha]

Source: transmission
Version: 4.0.6+dfsg-1

transmission-gtk is included in Ubuntu Desktop's default install
(specifically the expanded install option). This means that
transmission-gtk is in Ubuntu main and all its dependencies must be in
Ubuntu main instead of in Ubuntu universe.

libb64 is in Ubuntu universe. After an initial review, I determined
that libb64 does not seem like a good candidate for Ubuntu's Main
Inclusion process [1]. Therefore, I will need to re-vendor libb64
inside the transmission package. If Debian does the same, then it
would be possible for Debian and Ubuntu to share the same packaging,
allowing package improvements to more quickly reach Ubuntu during the
part of Ubuntu's development cycle when automatic sync is enabled.

Specifically:
- libb64 has been unmaintained since 2013
https://sourceforge.net/p/libb64/git/commit_browser
- libb64 has several open bugs, some of which have security implications
https://sourceforge.net/p/libb64/bugs/
- libb64 is missing a pkgconfig file which is a relatively simple
standard way for other software to use libb64
https://launchpad.net/bugs/1534293
- The Debian packaging is not using simple dh rules. The packaging
seems to otherwise be fairly modern but it's more complicated than
typical Debian packages.
https://salsa.debian.org/alteholz/libb64/-/blob/master/debian/rules

Reference
--
[1] https://github.com/canonical/ubuntu-mir

Thank you,
Jeremy Bícha

Bug#1066608: dvbstreamer: diff for NMU version 2.1.0-5.7

[Francisco Vilmar Cardoso Ruviaro]

Control: tags 1066608 + patch
Control: tags 1066608 + pending


Dear maintainer,

I've prepared an NMU for dvbstreamer (versioned as 2.1.0-5.7) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer or cancel the NMU.

Regards.

diff -Nru dvbstreamer-2.1.0/debian/changelog dvbstreamer-2.1.0/debian/changelog
--- dvbstreamer-2.1.0/debian/changelog  2022-08-08 18:22:11.0 +
+++ dvbstreamer-2.1.0/debian/changelog  2024-06-11 16:44:11.0 +
@@ -1,3 +1,12 @@
+dvbstreamer (2.1.0-5.7) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/patches/no-implicit-declarations.patch,
+fix missing declaration of UTF8_nextchar() and typo.
+Thanks to Steve Langasek . (Closes: #1066608)
+
+ -- Francisco Vilmar Cardoso Ruviaro   Tue, 11 Jun 2024 
16:44:11 +
+
 dvbstreamer (2.1.0-5.6) unstable; urgency=medium
 
   * fix lintian  no-versioned-debhelper-prerequisite 10
diff -Nru dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch 
dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch
--- dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch 
1970-01-01 00:00:00.0 +
+++ dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch 
2024-06-11 16:43:40.0 +
@@ -0,0 +1,38 @@
+Description: fix missing declaration of UTF8_nextchar() and typo
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066608
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: dvbstreamer-2.1.0/src/standard/dvb/sdtprocessor.c
+===
+--- dvbstreamer-2.1.0.orig/src/standard/dvb/sdtprocessor.c
 dvbstreamer-2.1.0/src/standard/dvb/sdtprocessor.c
+@@ -46,6 +46,7 @@
+ #include "sdtprocessor.h"
+ #include "dvbtext.h"
+ #include "standard/dvb.h"
++#include "utf8.h"
+ 
+ 
/***
+ * Defines 
 *
+Index: dvbstreamer-2.1.0/src/plugins/cam.c
+===
+--- dvbstreamer-2.1.0.orig/src/plugins/cam.c
 dvbstreamer-2.1.0/src/plugins/cam.c
+@@ -97,7 +97,7 @@
+ 
+ if (pmt->i_program_number == service->id)
+ {
+-needs_decrypting = PMTDoesNeedDecypting(pmt);
++needs_decrypting = PMTDoesNeedDecrypting(pmt);
+ 
+ if (currentPMT)
+ {
+@@ -197,4 +197,4 @@
+ }
+ 
+ return false;
+-}
+\ No newline at end of file
++}
diff -Nru dvbstreamer-2.1.0/debian/patches/series 
dvbstreamer-2.1.0/debian/patches/series
--- dvbstreamer-2.1.0/debian/patches/series 2021-10-16 08:37:38.0 
+
+++ dvbstreamer-2.1.0/debian/patches/series 2024-06-11 16:43:48.0 
+
@@ -16,3 +16,4 @@
 
 ## does not apply, needs some care
 #svn_819.diff
+no-implicit-declarations.patch


-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00diff -Nru dvbstreamer-2.1.0/debian/changelog dvbstreamer-2.1.0/debian/changelog
--- dvbstreamer-2.1.0/debian/changelog	2022-08-08 18:22:11.0 +
+++ dvbstreamer-2.1.0/debian/changelog	2024-06-11 16:44:11.0 +
@@ -1,3 +1,12 @@
+dvbstreamer (2.1.0-5.7) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/patches/no-implicit-declarations.patch,
+fix missing declaration of UTF8_nextchar() and typo.
+Thanks to Steve Langasek . (Closes: #1066608)
+
+ -- Francisco Vilmar Cardoso Ruviaro   Tue, 11 Jun 2024 16:44:11 +
+
 dvbstreamer (2.1.0-5.6) unstable; urgency=medium
 
   * fix lintian  no-versioned-debhelper-prerequisite 10
diff -Nru dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch
--- dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch	1970-01-01 00:00:00.0 +
+++ dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch	2024-06-11 16:43:40.0 +
@@ -0,0 +1,38 @@
+Description: fix missing declaration of UTF8_nextchar() and typo
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066608
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: dvbstreamer-2.1.0/src/standard/dvb/sdtprocessor.c
+===
+--- dvbstreamer-2.1.0.orig/src/standard/dvb/sdtprocessor.c
 dvbstreamer-2.1.0/src/standard/dvb/sdtprocessor.c
+@@ -46,6 +46,7 @@
+ #include "sdtprocessor.h"
+ #include "dvbtext.h"
+ #include "standard/dvb.h"
++#include "utf8.h"
+ 
+ /***
+ * Defines  *
+Index: dvbstreamer-2.1.0/src/plugins/cam.c
+===
+--- dvbstreamer-2.1.0.orig/src/plugins/cam.c
 dvbstreamer-2.1.0/src/plugins/cam.c
+@@ -97,7 +97,7 @@
+ 
+ if 

Bug#1073004: transmission-qt: Switch to qt6

[Jeremy Bícha]

Package: transmission-qt
Version: 4.0.6+dfsg-1

Please consider switching transmission-qt to build with Qt6 instead of
Qt5. I think the Debian Qt/KDE team is going to try to switch to KDE 6
in time for the next major release of Debian (Debian 13 "Trixie").
Therefore, as long as the transmission qt6 build works reasonably
well, I think it would be a better fit than the qt5 build.

Thank you,
Jeremy Bícha

Bug#1064536: scribus: Please package 1.6.1

[Daniel Baumann]

Hi,

what's the status of getting 1.6 uploaded? Do you need any help?

Regards,
Daniel

Bug#1073003: ITP: python-django-structlog -- Structured Logging for Django

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-structlog
  Version : 8.1.0
  Upstream Contact: Michael Fladischer 
* URL : https://github.com/jrobichaud/django-structlog
* License : Expat
  Programming Lang: Python
  Description : Structured Logging for Django

 django-structlog is a structured logging integration for Django project using
 structlog. Logging will then produce additional cohesive metadata on each logs
 that makes it easier to track events or incidents.

I intend to maintain this as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmZogXwbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqXPoIAJC4pQVllONVB1tF0xZI
0bJ0HGSW9UHtAC3HlkirN5RNS2Ax8VCUGRQjBlXtfDh38CdHuMH6KodCRi0t0mqR
7lnUu7cvK/I//3FGutqKonRAO9RQGA5d+dqLGauATQ0CrRFSU05BMspRAdWWjWHA
4/iaVbl2crB2obgQnCxHFf3Wg/HowdchY2yyMQlgeQgt1SdIzu0ttt+LZKqUaYs/
zM+DHBVL0hRF92JcROvTD/iH5X3DCsCp7upkkvYZ45NyVMBza68lKwGUkIwQh9LJ
nrs5oibLlkupbhXPyGMJvcLPf1irbVae2Aw/icWAKAlelHorMqw1cwuBm6EhQbx8
Hvo=
=XYb0
-END PGP SIGNATURE-

Bug#1073002: cups: CVE-2024-35235

[Salvatore Bonaccorso]

Source: cups
Version: 2.4.7-1.2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cups.

CVE-2024-35235[0]:
| OpenPrinting CUPS is an open source printing system for Linux and
| other Unix-like operating systems. In versions 2.4.8 and earlier,
| when starting the cupsd server with a Listen configuration item
| pointing to a symbolic link, the cupsd process can be caused to
| perform an arbitrary chmod of the provided argument, providing
| world-writable access to the target. Given that cupsd is often
| running as root, this can result in the change of permission of any
| user or system files to be world writable. Given the aforementioned
| Ubuntu AppArmor context, on such systems this vulnerability is
| limited to those files modifiable by the cupsd process. In that
| specific case it was found to be possible to turn the configuration
| of the Listen argument into full control over the cupsd.conf and
| cups-files.conf configuration files. By later setting the User and
| Group arguments in cups-files.conf, and printing with a printer
| configured by PPD with a `FoomaticRIPCommandLine` argument,
| arbitrary user and group (not root) command execution could be
| achieved, which can further be used on Ubuntu systems to achieve
| full root command execution. Commit
| ff1f8a623e090dee8a8aadf12a6a4b25efac143d contains a patch for the
| issue.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-35235
https://www.cve.org/CVERecord?id=CVE-2024-35235
[1] https://www.openwall.com/lists/oss-security/2024/06/11/1
[2] 
https://github.com/OpenPrinting/cups/commit/a436956f374b0fd7f5da9df482e4f5840fa1c0d2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1072687: Re: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian

[pham...@bluewin.ch]

Hello,

Thank you, I will return the result to you as soon as the problem occurs again.

While I'm at it, do you know if there is a command that can be run to 
re-execute the automatic discovery of network hardware and devices connected to 
it, just like it happens at the beginning of the Debian installation process ? 
By analogy, tasksel allows this regarding the desktop configuration.

Best regards.

Philippe



Message d'origine
De : m...@dorfdsl.de
Date : 11/06/2024 - 09:49 (E)
À : pham...@bluewin.ch, 1072...@bugs.debian.org
Objet : Re: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when 
booting Debian

Am 11.06.2024 um 09:21:55 Uhr schrieb pham...@bluewin.ch:

> Tell me exactly which log you need to solve this problem ?

Please enable trace logging in NetworkManager.
The dmesg doesn't show anything unusual at the first view.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/introduction-to-networkmanager-debugging_configuring-and-managing-networking#temporarily-setting-log-levels-at-run-time-using-nmcli_introduction-to-networkmanager-debugging

nmcli general logging level TRACE domains ALL

Then use 
journalctl -u NetworkManager -b


-- 
Gruß
Marco

Send unsolicited bulk mail to 1718090515mu...@cartoonies.org

Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback

[Simon McVittie]

On Tue, 11 Jun 2024 at 18:05:21 +0200, Helmut Grohne wrote:
> I looked for other cases where there would be a versioned dependency on
> usr-is-merged and to my surprise dbus was literally the only one.

I suspect many of the other packages that migrated from shipping
systemd units in /lib/systemd to shipping them in /usr/lib/systemd
had less dramatically bad failure modes if the system is still in the
unmerged-/usr state - often the single service shipped in that package
would not start, but the system as a whole would still boot, leading
to a lower expectation that the maintainer must prioritize a response.

smcv

Bug#1052714: firmware-amd-graphics: Missing firmware for AMD Radeon RX 7000 series cards

[Andre Naujoks]

I'd like to ping this issue.

Just installed a RX 7700 XT and needed to manually download a bunch of 
firmware files from the upstream repo to get it to work. I am on unstable,


Is there anything a user (me) can do to help here? What is needed to get 
this package up to date? I saw a little update in the git repo, but it 
does not look like an update to a newer linux-firmware version?


Regards

  Andre

Bug#1072990: rsync error: error in rsync protocol data stream (code 12) at token.c(481) [sender=3.2.7]

[Norbert Schulz]

Yes, I am transferring a very large number of files. The curiosity is,
that it works until debian 12.4 or even with the last update of rsync
without these errors.

I can split the transfer into smaller parts. I will try and come back with the 
results.

Thanks,
Norbert


On Tue 11 Jun 2024, Norbert Schulz wrote:


If I run rsync without 'z' option the error is:

[receiver] exceeded --max-alloc=1073741824 setting (file=fileio.c, line=260)
rsync error: error allocating core memory buffers (code 22) at util2.c(80) 
[receiver=3.2.7]
rsync: [generator] write error: Broken pipe (32)
rsync: connection unexpectedly closed (18054825 bytes received so far) 
[generator]


Hmm, you could be running into a memory constraint, are you transferring
a very large number of files? If so, is it possible to split the
transfer up into smaller parts?


Thanks,
Paul

Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback

[Helmut Grohne]

On Tue, Jun 11, 2024 at 03:31:04PM +0100, Simon McVittie wrote:
> I don't think that is true. The (single!) change in usrmerge v38 was that
> it no longer implements the undocumented opt-out mechanism involving
> /etc/unsupported-skip-usrmerge-conversion, therefore any system with
> usrmerge (>= 38~) or usr-is-merged (>= 38~) is always going to be
> /usr-merged.

How could I have missed this! Sorry.

> Would the suggested versioned dependency on base-files offer the same?

Yes. base-files (>= 13.3~) will directly ship the aliasing links in its
data.tar and its preinst will fail if any of these links actually is a
real directory (rather than being a symlink or absent both of which mean
that after unpack there'll be a symlink).

I looked for other cases where there would be a versioned dependency on
usr-is-merged and to my surprise dbus was literally the only one.

So given that we do not want to duplicate the conflicts into base-files
and that dbus actually is the only package wanting to express this, I am
now convinced that the originally proposed solution of adding the
base-files alternative actually is a good solution for the problem at
hand.

Helmut

Bug#1073001: buildbot FTBFS: python3-sqlalchemy (<< 1.5) no longer satisfiable

[Helmut Grohne]

Source: buildbot
Version: 3.10.1-2
Severity: serious
Tags: ftbfs trixie sid

buildbot can no longer be built in unstable as the python3-sqlalchemy
package is too new to satisfy buildbot's build dependencies. It likely
needs an upload that establishes compatibility with newer sqlalchemy.

Helmut

Bug#1072993: please add OnlyShowIn=GNOME;Unity; in com.mattjakeman.ExtensionManager.desktop

[Jeremy Bícha]

On Tue, Jun 11, 2024 at 8:54 AM xiao sheng wen  wrote:
>   The gnome-shell-extension-manager is only use in GNOME, so add field:
>
> OnlyShowIn=GNOME;Unity;

While this could be done as a Debian specific patch, this could be
useful to people using other distros too. Could you report this
request to the upstream project at
https://github.com/mjakeman/extension-manager/issues ?

Also, you could try to submit your own git merge request there for
this if you want.

Note that Unity does not use GNOME Shell at all so you don't want
Unity in the OnlyShowIn field.

Thank you,
Jeremy Bícha

Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration

[GCS]

On Tue, Jun 11, 2024 at 1:39 PM Otto Kekäläinen  wrote:
> I am travelling and on slow internet. I will review and hopefully help
> you with feedback this weekend.
 To make the browsing easier for you, I've imported the v9.2.1 changes
and pushed the repository to GitHub located at:
https://github.com/gcsideal/rocksdb

Hope this helps,
Laszlo/GCS

Bug#1073000: ssh-askpass-gnome: No longer visually prompted to touch security key after upgrading to Bookworm

[Elias Batek]

Package: ssh-askpass-gnome
Version: 1:9.2p1-2+deb12u2
Severity: normal
X-Debbugs-Cc: e.batek+deb...@itkaufmann.at

Dear Maintainer,

After upgrading my system from Bullseye to Bookworm,
I’m no longer visually prompted to touch an attached security key (e.g.
YubiKey) to confirm SSH logins etc.
Instead the app just waits with no visual indicator that it expects user
interaction.

Luckily my YubiKey has an LED that blinks in this state, but apart from that
there’s nothing that distinguishes the situation from a hanging program.

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

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

Versions of packages ssh-askpass-gnome depends on:
ii  libc6   2.36-9+deb12u7
ii  libglib2.0-02.74.6-2+deb12u2
ii  libgtk-3-0  3.24.38-2~deb12u1
ii  openssh-client  1:9.2p1-2+deb12u2

ssh-askpass-gnome recommends no packages.

ssh-askpass-gnome suggests no packages.

-- no debconf information

Bug#1054367: cjs: Move to mozjs115

[Bastian Germann]

Am 11.06.24 um 17:33 schrieb Fabio Fantoni:

About autoconf2.13 I don't see it in cjs build-deps, I suppose you got confused 
with mozjs, or am I wrong?


You are right, I got confused.

Bug#1072689: can be closed

[Marijn Ophorst]

ne'er mind, turns out the mouse was FUBAR. never knew that could happen, 
but there ya go.

Bug#1054367: cjs: Move to mozjs115

[Fabio Fantoni]

Il 11/06/2024 17:01, Bastian Germann ha scritto:

Control: tags -1 fixed-upstream

Please import the latest release 6.2.0, which has this integrated.
Don't forget to remove autoconf2.13 from the Build-Depends.

Hi, when I'll have time I'll start to upload it to experimental, I don't 
have time to test it recently but if someone want start to test it will 
be available in experimental. I also not had time to check all cinnamon 
development recently (but only something), I don't know if it require 
also change in cinnamon (so will need also new cinnamon now in 
development, and probably will enter in beta shortly, or backports of 
some commits), is probable, like previous rebase that even if not big as 
previous required some changes in cinnamon. For now I did only a very 
fast look to cinnamon git history I didn't found commits that seems 
related to cjs.


About autoconf2.13 I don't see it in cjs build-deps, I suppose you got 
confused with mozjs, or am I wrong?




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072999: RM: gcc-3.3 -- RoQA; orphaned; leaf pkg; build-depends on autoconf2.13

[Bastian Germann]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:gcc-3.3

gcc-3.3 is an orphaned leaf package. It was kept around for old (non-free) 
binaries that depend on libstdc++5.
There is now a compelling reason to remove it, i.e., not to block autoconf2.13 removal. All other autoconf2.13 reverse 
build deps have at least one release with newer autoconf now and are going to move eventually.

Bug#1072998: Black screen on host during vbox manager startup

[debian-edid]

Package: virtualbox
Version: 7.0.18-dfsg-1+b1

Launching virtualbox manager causes host screen to blink black (like 
disabling monitor for a sec.). This behavior was observed under 
wayland/xwayland with kernel 6.7.12 with UHD Graphics 630 - i915 module.

Bug#1070815: libdrm-intel1 should be compiled for arm64

[Jeremy Bícha]

Control: reopen -1
Control: severity -1 serious
Control: tags -1 +ftbfs -patch

After this change, libdrm is failing to build on arm64.

Build log excerpt

dh_install: warning: Cannot find (any matches for)
"usr/lib/*/libdrm_intel.so.1*" (tried in ., debian/tmp)

dh_install: warning: libdrm-intel1 missing files: usr/lib/*/libdrm_intel.so.1*

Full build log
-
Click Build-Attempted at https://buildd.debian.org/status/package.php?p=libdrm

Thank you,
Jeremy Bícha

Bug#1033839: Packaging docker 24.0.9, update gotest.tools to 3.5.1-1

[Prusty, Badrikesh]

Hello Arnauld,

I created the changes for updating gotest.tools to 3.5.1. I created a fork and 
pushed to badrikesh/gotest-3.5.1 branch. Please review the above link:
https://salsa.debian.org/badrikesh/gotest.tools/-/tree/badrikesh/gotest-3.5.1?ref_type=heads

After the update I ran the ratt test as suggested, Here's the result:

```
trixie@debian:~/update-gotest-tools$ ~/go/bin/ratt 
gotest.tools_3.5.1-1_amd64.changes
13:49:59 [47/47]
2024/06/11 12:45:02 Loading changes file "gotest.tools_3.5.1-1_amd64.changes"
2024/06/11 12:45:02  - 1 binary packages: 
golang-github-gotestyourself-gotest.tools-dev
2024/06/11 12:45:02 Corresponding .debs (will be injected when building):
2024/06/11 12:45:02 
golang-github-gotestyourself-gotest.tools-dev_3.5.1-1_all.deb
2024/06/11 12:45:02 Setting -dist=sid (from .changes file)
2024/06/11 12:45:02 Figuring out reverse build dependencies using dose-ceve(1). 
This might take a while
2024/06/11 12:45:24 Found 40 reverse build dependencies
2024/06/11 12:45:24 Setting -sbuild_dist=unstable (from .changes file)
2024/06/11 12:45:24 Building package 1 of 40: go-containerregistry
2024/06/11 12:46:25 Building package 2 of 40: crowdsec
2024/06/11 12:49:01 Building package 3 of 40: distrobuilder
2024/06/11 12:50:17 Building package 4 of 40: golang-github-containers-storage
2024/06/11 12:52:46 Building package 5 of 40: 
golang-github-openshift-imagebuilder
2024/06/11 12:53:45 Building package 6 of 40: 
golang-github-containerd-stargz-snapshotter
2024/06/11 12:55:55 Building package 7 of 40: oci-seccomp-bpf-hook
2024/06/11 12:57:08 Building package 8 of 40: 
golang-github-mudler-docker-companion
2024/06/11 12:57:56 Building package 9 of 40: 
golang-github-crowdsecurity-go-cs-bouncer
2024/06/11 12:58:54 Building package 10 of 40: golang-github-containers-psgo
2024/06/11 12:59:38 Building package 11 of 40: golang-oras-oras-go
2024/06/11 13:00:32 Building package 12 of 40: libpod
2024/06/11 13:04:12 Building package 13 of 40: golang-github-moby-term
2024/06/11 13:04:38 Building package 14 of 40: 
golang-github-checkpoint-restore-checkpointctl
2024/06/11 13:05:29 Building package 15 of 40: gotestsum
2024/06/11 13:06:06 Building package 16 of 40: prometheus
2024/06/11 13:12:51 Building package 17 of 40: golang-github-optiopay-kafka
2024/06/11 13:13:44 Building package 18 of 40: singularity-container
2024/06/11 13:17:38 Building package 19 of 40: golang-github-sigstore-sigstore
2024/06/11 13:18:52 Building package 20 of 40: prometheus-postfix-exporter
2024/06/11 13:19:49 Building package 21 of 40: skopeo
2024/06/11 13:21:18 Building package 22 of 40: gitlab-ci-multi-runner
2024/06/11 13:22:18 building gitlab-ci-multi-runner failed: exit status 2
2024/06/11 13:22:18 Building package 23 of 40: rootlesskit
2024/06/11 13:23:05 Building package 24 of 40: containerd
2024/06/11 13:25:34 Building package 25 of 40: docker.io
2024/06/11 13:31:38 Building package 26 of 40: golang-github-containers-image
2024/06/11 13:33:13 Building package 27 of 40: crowdsec-firewall-bouncer
2024/06/11 13:34:17 Building package 28 of 40: golang-github-containers-buildah
2024/06/11 13:37:06 Building package 29 of 40: 
golang-github-samalba-dockerclient
2024/06/11 13:37:59 Building package 30 of 40: golang-k8s-sigs-release-utils
2024/06/11 13:38:47 Building package 31 of 40: crowdsec-custom-bouncer
2024/06/11 13:39:50 Building package 32 of 40: golang-github-crc-org-crc
2024/06/11 13:41:02 Building package 33 of 40: skeema
2024/06/11 13:41:55 Building package 34 of 40: 
golang-github-fsouza-go-dockerclient
2024/06/11 13:42:47 Building package 35 of 40: open-vm-tools
2024/06/11 13:45:55 Building package 36 of 40: golang-github-sylabs-sif
2024/06/11 13:46:57 Building package 37 of 40: golang-github-crewjam-saml
2024/06/11 13:47:35 Building package 38 of 40: golang-github-containers-common
2024/06/11 13:49:16 Building package 39 of 40: golang-github-tonistiigi-fsutil
2024/06/11 13:50:03 Building package 40 of 40: tty-share
2024/06/11 13:50:43 1 packages failed the first pass; you can rerun ratt only 
for them passing the option -include '^(gitlab-ci-multi-runner)$'
2024/06/11 13:50:43 Build results:
2024/06/11 13:50:43 PASSED: golang-github-containers-psgo
2024/06/11 13:50:43 PASSED: containerd
2024/06/11 13:50:43 PASSED: golang-github-crewjam-saml
2024/06/11 13:50:43 PASSED: golang-github-crc-org-crc
2024/06/11 13:50:43 PASSED: golang-github-containers-common
2024/06/11 13:50:43 PASSED: distrobuilder
2024/06/11 13:50:43 PASSED: golang-oras-oras-go
2024/06/11 13:50:43 PASSED: libpod
2024/06/11 13:50:43 PASSED: golang-github-containers-image
2024/06/11 13:50:43 PASSED: crowdsec-firewall-bouncer
2024/06/11 13:50:43 PASSED: tty-share
2024/06/11 13:50:43 PASSED: golang-github-containerd-stargz-snapshotter
2024/06/11 13:50:43 PASSED: oci-seccomp-bpf-hook
2024/06/11 13:50:43 PASSED: golang-github-optiopay-kafka
2024/06/11 13:50:43 PASSED: golang-github-sigstore-sigstore
2024/06/11 13:50:43 PASSED: rootlesskit
2024/06/11 

Bug#1054367: cjs: Move to mozjs115

[Bastian Germann]

Control: tags -1 fixed-upstream

Please import the latest release 6.2.0, which has this integrated.
Don't forget to remove autoconf2.13 from the Build-Depends.

Bug#1072183: fenics-dolfinx: FTBFS with nanobind 2.0

[Timo Röhling]

Hi,

* Francesco Ballarin  [2024-06-11 09:53]:

Hopefully there won't be future ABI breaks that aren't aligned with a
fenics-basix/fenics-dolfinx release, but if there will be we will look forward
to any suggestion from you on how to come up with a more elegant solution.
I gave it a bit of thought and tightened the dependency from 
python3-nanobind on nanobind-dev, so both packages will be installed 
with the same version. I also added a pydist override so that 
python3-nanobind will automatically emit a versioned dependency (>= 
2, << 3), so you do not have to do that downstream any more.


I'm not 100% certain that it is enough, but it should definitely 
help.


Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯

Bug#1030668: dinstall could run more often (every hour?)

[Johannes Schauer Marin Rodrigues]

Hi,

On Mon, 6 Feb 2023 12:45:17 +0100 Bastian Blank  wrote:
> > The bigger picture is: packages are not part of the Debian build
> > infrastructure (buildd, piuparts, etc) for hours and this blocks many
> > development activities.
> 
> They are.  The buildd use incoming.d.o with accepted packages as
> additional source.

maybe let me use this topic to ask a maybe a little bit tangential question.

For a few days I have been involved in fixing the autopkgtest of my package
mmdebstrap to make it work with Helmut's recent merged-/usr uploads of bash,
dash, util-linux and glibc. My workflow is: fix a thing, upload, see if ci.d.n
is happy, fix bug, repeat. This takes multiple dinstalls and thus multiple days
of work for me. This is not a nice experience for me as a contributor because
instead of being able to sit down and fix the thing, I have to spread my work
across multiple days. I'm aware that there are multiple possible fixes to this:

 1. add support for using incoming as a apt source to ci.d.n
 2. set up my own copy of ci.d.n (difficult as i'm on a slow arm cortex a53 
system with 3.7 GB ram)
 3. ask far a shell on ci.d.n from elbrus
 4. add support for apt pinning to autopkgtest on salsaci

I must admit I'm not that frustrated by the six hour dinstall time as while it
is not optimal, it is something I find myself having accepted as the way that
Debian just works. So whatever.

But here comes my tangential question: I have my package (mmdebstrap) which
seems to require overall 29 seconds to build on the builds. The buildd queues
are empty. I upload an hour before the next dinstall. Then it takes 20 minutes
for the ACCEPTED mail to arrive after my dput (why this long?) and then it
takes another half an hour before the buildds even register that there is a new
binary package to be built (why this long?), then it builds in 29 seconds, 10
minutes before the next dinstall it's finished. It still misses it.

So my question: for a package that takes 29 seconds to build and empty buildd
queues. How long before the official dinstall times do I have to upload so that
my package makes it? It is very frustrating to upload an hour in advance, plan
my time for the day accordingly, only to then see it fail. This waiting time
and unpredictability is what makes Debian development extremely frustrating for
me. I do not understand why processing such a tiny package is taking a full
hour. Maybe things would be a bit better if I would at least be able to predict
what is going on at a given time. I literally told my family: hey can I have
some free time later to work on Debian and now it's not going to happen. This
is not a problem of only 4 dinstalls per day but it's a problem of not knowing
what is going on and why. Maybe this can be improved?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback

[Simon McVittie]

On Tue, 11 Jun 2024 at 13:16:21 +0200, Helmut Grohne wrote:
> the only important features
> (from a client package pov) that usr-is-merged gained with higher
> versions are those Conflicts.

I don't think that is true. The (single!) change in usrmerge v38 was that
it no longer implements the undocumented opt-out mechanism involving
/etc/unsupported-skip-usrmerge-conversion, therefore any system with
usrmerge (>= 38~) or usr-is-merged (>= 38~) is always going to be
/usr-merged.

This means that any package with a dependency on usr-is-merged (>= 38~)
can safely assume that it will never be installable on systems where
/etc/unsupported-skip-usrmerge-conversion has been used to delay the
conversion to merged-/usr, even during a partial upgrade, and therefore
it does not need to be defensively programmed so that it will either
work as intended or fail cleanly with an obvious error message on
unmerged-/usr.

Specifically, either the system is already /usr-merged, or
usr-is-merged.preinst will have already failed (somewhat cleanly) and
the dependency will not be met. Either way, the new dbus will not get
configured and therefore any failure is somewhat clearly not a dbus bug.

Would the suggested versioned dependency on base-files offer the same?

I could have implemented this without an external dependency by
open-coding a check for merged /usr and graceful failure into dbus.preinst
or dbus.postinst, similar to the one in usr-is-merged.preinst; but this
didn't really seem like it should be my job, and I try to minimize the
amount of load-bearing shell script that I'm responsible for.

> For dbus, it was added via #1054650, but the bug log does not express
> why the version restriction was needed.

I had hoped that the extensive changelog entry justifying this change
would be sufficiently clear, but in case it wasn't:

The reporter of #1054650 was running in the unsupported configuration
of a post-bookworm system with unmerged /usr, presumably having used
/etc/unsupported-skip-usrmerge-conversion to suppress conversion from
unmerged to merged /usr.

Before dbus 1.14.10-2, even though this scenario was explicitly
unsupported, in practice it worked anyway. After dbus 1.14.10-2,
the unsupported scenario caused boot to fail, which was reported as
a Severity: critical bug in dbus ("breaks the entire system").

I considered #1054650 to be a non-bug, because it is an unsupported
scenario, and creating that scenario must have required acknowledging
this by creating a file with "unsupported" in its name; but I was not
willing to make myself responsible for closing a series of duplicate
high-severity bug reports, with an increased likelihood of being
flamed by angry unmerged-/usr users with each duplicate, and that's
what I expected would happen if I didn't add some sort of mitigation
promptly (especially if 1.14.10-2 had reached testing).

As a result of our dependency system being as elaborate as it is,
there tends to be a perception that if it has been possible to install
a package successfully, then any failure to work as intended after that
is automatically a high-severity bug that demands a priority response
from the maintainer, even if it involves scenarios that have been widely
publicized as unsupported. The addition of
Depends: usr-is-merged (>= 38~) in dbus was intended to ensure that the
unsupported scenario could not happen, instead of creating the perception
that dbus was irretrievably broken and it was my fault.

Being told that I am personally responsible for critically harming Debian
is not an aspect of the maintainer role that I enjoy, even if it isn't
actually true, and I try to minimize it if I can. I'm sorry if my attempts
to protect myself have caused additional work for others.

> it feels right to me that dbus pulls the physical
> usr-is-merged package whose purpose at this time is forcing other
> packages off the system

>From my point of view, forcing other packages broken by merged-/usr off
the system is only a side-effect, and the purpose of this dependency
was to redirect the blame for "package does not work on an unsupported
non-/usr-merged system" to whoever set up the unsupported situation and
is now continuing to rely on it.

smcv

Bug#1072142:

[Stuart]

Same issue here, fixed by installing libnvidia-egl-wayland1 and
rebooting, should some part of the driver depend on this package?

Bug#1072997: rust-csv: please update to v1.3

[Jonas Smedegaard]

Source: rust-csv
Version: 1.2.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v1.3.0.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZoV20ACgkQLHwxRsGg
ASEFCw//Vl76LTw0qYfs0mfzrzGIWU7YsiEKbEiAq5hEo5hyn+ANV2MKxrRKOVef
i9mp1iDOLhmDxo6IJOrzTJ1QsIcNMJtcTZWMFApqDbAJZoaEh/QRK7cp6CmTUcFK
tzjuEQehhy6xm4psGc3/CMSdl9vDd0b1ufGJJxalzEk920I8jtEyGzMHuWO2Fge4
HhH4lf/ETMdxpDAglNOe+TZJ3PYlgLBcGrOe7JCr/mdiXABVWWNiDub4ibC8Fuyy
NTqpGtINrX29DrsJ/P5prmOieonZm4B8at6ajN4A1LLnW51aAD3monlw5M6L2wzd
vvTBSx2wjuiuhPUV1Qrfla2zo4lKhmOVr9smgm74axl5UmVgwLSN5vt9wju+VSNp
8wTtB3s0DfZUmB+b7/ZYmc1O5Jy3vVOe35UEwZmCkAFmhi6byiJ+6e83dB7NYpEe
t817PpdE36sqVgQQj4wV8W3XUqNnDdzGXBRhkSK9FNYvXydWJzgsLZy67pItgPe/
o87ruOtriD0RME7Wbi4v2hw6BVH3HXah0jacOHBhiO97Pj3MNdxpm20QZL/88C+i
YPeW4QWOqJi5IWJj6FzdVkDuCd1XhBDwxBJchv/ClPhktW+dPDnoH5fJ02V+gTgp
exG+I9UIOMesVsIMy6tgxKNocloaZUHLGBnokVa41iut/VDAqUc=
=6uCz
-END PGP SIGNATURE-

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Marc Haber]

On Mon, Jun 10, 2024 at 11:02:30PM +0200, Ola Lundqvist wrote:
> Sorry, I meant to run with dash -x. Or do dash not have that option?

It has this option.

But I see a problem in cron-apt using bashisms while using the /bin/sh
shebang line. I don't know whether this have to do with this, bug, but
it should be fixed anyway.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#993308: firefox-esr: You might need to add a libpci3 dependency to ESR 91

[MichaIng]

Adding some context:

The function which throws the warning is here:
https://searchfox.org/mozilla-central/source/toolkit/xre/glxtest/glxtest.cpp#192

RHEL added libpci as dependency: 
https://bugzilla.redhat.com/show_bug.cgi?id=1955338


It was reported on BSD derivatives and Solaris, where libpci as well as 
the used sysfs nodes do not exist, hence for those, the function is now 
a dummy (see code):

- https://bugzilla.mozilla.org/show_bug.cgi?id=1868782
- https://misc.openbsd.narkive.com/XtvqpVLc/firefox-glxteset-libpci-missing

All the function does is storing PCI_VENDOR_ID and PCI_DEVICE_ID for the 
GPU.


I could find them being used only here:
https://searchfox.org/mozilla-central/source/widget/gtk/GfxInfo.cpp#209
And there are fallback mechanisms to derive those IDs.

Checking the linked bug report in the comments of this function and the 
top of glxtest.cpp: https://bugzilla.mozilla.org/show_bug.cgi?id=639842
So glxtest.cpp is only used to derive info for the Graphics section of 
about:support in X11 environments, and GfxInfo.cpp is used to generate 
this section.


I did a quick test on VM with X11 and Mesa drivers, and despite the fact 
that this warning is thrown, the Graphics section is identical with and 
without libpci, especially the "GPU #1" section does contain vendor and 
device ID and names in both cases, so the fallback mechanisms work. Only 
the end of the Graphics section contains and additional "Failure Log" 
entry, showing "glxtest: libpci missing" as well.


So libpci3 it is definitely not suites as dependency, IMO not as 
recommendation either, probably not even a suggestion. I would remove 
the startup warning, show it on about:support only, and extend the 
warning's text, stating that GPU vendor and device info may be 
inaccurate or missing. Not sure whether its worth a patch and upstream 
suggestion. I am no fans of pointless log entries above debug severity. 
Currently, some users/admins are wasting time to hunt down this warning 
when they face true issues with hardware acceleration or similar. And 
they may waste resources (marginal only, but in principle) installing 
the package, while it won't make any practical difference for hardware 
acceleration, or other issues they may experience.


Best regards,

Micha

Bug#1072996: cryptmount: No longer working with current sid (e2fsck error)

[Agustin Martin]

Package: cryptmount
Version: 6.2.0-2
Severity: normal

Dear Maintainer,

I have noticed that cryptmount is no longer working well with current
sid in my box. This happened recently, although I do not know where
this started to happen,

$ cryptmount LUKS-test
...
e2fsck 1.47.1 (20-May-2024)
Error determining size of the physical device: No such file or directory
unable to stat() device node
Failed to remove device-mapper target "LUKS-test"

If I add the noextfsck flag to cmtab, mount succeeds,

$ cryptmount LUKS-test

However, I have problems when unmounting,

$ cryptmount -u LUKS-test
Target "LUKS-test" does not appear to be mounted

although device is mounted and accesible,

I noticed that when using cryptmount /dev/mapper/LUKS-test seems not
present, although device is mounted. When using the normal cryptsetup close flow

# umount /media/luks-testdir
# /sbin/cryptsetup close LUKS-test

device is properly unmounted.

If I follow the cryptsetup flow for opening

# /sbin/cryptsetup open /dev/sdc1  LUKS-test
# mount /dev/mapper/LUKS-test /media/luks-testdir/

/dev/mapper/LUKS-test is present and 'cryptmount -u LUKS-test' works.

LUKS-test {
  keyformat=luks
  dev=/dev/sdc1
  keyfile=/dev/sdc1
  dir=/media/luks-testdir
  flags=nofsck
  fstype=ext4
}


Thanks for your work on cryptmount.

Regards,

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

Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 cryptmount depends on:
ii  libc6   2.38-13
ii  libcryptsetup12 2:2.7.2-2
ii  libdevmapper1.02.1  2:1.02.196-1+b1
ii  libgcrypt20 1.10.3-3
ii  libudev1256~rc4-1

Versions of packages cryptmount recommends:
ii  e2fsprogs  1.47.1-1
ii  udev   256~rc4-1

Versions of packages cryptmount suggests:
ii  dmsetup  2:1.02.196-1+b1

-- Configuration Files:
/etc/cryptmount/cmtab changed [not included]

-- no debconf information

Bug#1065973: kmod: FTBFS due to time64 transition

[Chris Hofstaedtler]

Control: tags -1 + fixed-upstream

On Thu, Mar 21, 2024 at 12:23:46PM +, Simon McVittie wrote:
> On Thu, 21 Mar 2024 at 15:45:13 +0500, Andrey Rakhmatullin wrote:
> > On Wed, Mar 13, 2024 at 08:23:07AM +0100, Helge Deller wrote:
> > > The patch below builds for me on the hppa platform.
> > Unfortunately tests fail here with it in an armhf chroot, I don't know if
> > it's generic or because the chroot is a qemu-based one on amd64.
> 
> I think the root cause (both for needing to unset _FILE_OFFSET_BITS, and
> for the tests failing) is that kmod's test suite is interposing
> mock/wrapped versions of the stat() family.
> 
> With the transition to 64-bit time_t, there are new members of the stat()
> family that will also need interposing on 32-bit architectures:
> __lstat64_time64() is the replacement for lstat(), and __stat64_time64()
> for stat().

Upstream merged this:
https://github.com/kmod-project/kmod/commit/68db6750788931da26018f2ee5c635cd58a4d809

Might be great to try this in Debian soon?

Bug#1072990: rsync error: error in rsync protocol data stream (code 12) at token.c(481) [sender=3.2.7]

[Paul Slootman]

On Tue 11 Jun 2024, Norbert Schulz wrote:
> 
> If I run rsync without 'z' option the error is:
> 
> [receiver] exceeded --max-alloc=1073741824 setting (file=fileio.c, line=260)
> rsync error: error allocating core memory buffers (code 22) at util2.c(80) 
> [receiver=3.2.7]
> rsync: [generator] write error: Broken pipe (32)
> rsync: connection unexpectedly closed (18054825 bytes received so far) 
> [generator]

Hmm, you could be running into a memory constraint, are you transferring
a very large number of files? If so, is it possible to split the
transfer up into smaller parts?


Thanks,
Paul

Bug#1072995: gnome-software: a method for disabling autostart should be documented, and perhaps made easier

[Philip Hands]

Package: gnome-software
Severity: wishlist

Some users do not actually benefit from gnome-software/packagekit, and
occasionally suffer as a result of it's presence.

A case in point is an elderly relative, who despite encouragement has never
found a reason to install a new package for themselves, so relies on me to do
upgrades, or suggest new packages.

However, occasionally they get bitten by what looks like #909804, where the
machine can become unresponsive immediately after boot or resume. Even without
that, if one is never going to use the functionality, the background downloads
are a waste of resources on both the local machine, and our mirror network.

That being the case, I think it might be useful to add something to the README
describing the best way to prevent gnome-software from autostarting.

An internet search turns up various suggestions (and reveals that I'm clearly
not alone in wanting a good answer to this question), the best of which seems to
be here:

  
https://www.reddit.com/r/gnome/comments/gn8rs4/how_to_disable_gnome_software_autostart/

=-=-=-=-
  All this can be done by pasting these lines into terminal:

mkdir -pv ~/.config/autostart && cp 
/etc/xdg/autostart/gnome-software-service.desktop ~/.config/autostart/
echo "X-GNOME-Autostart-enabled=false" >> 
~/.config/autostart/gnome-software-service.desktop
dconf write /org/gnome/desktop/search-providers/disabled 
"['org.gnome.Software.desktop']"

  If you want to also disable Gnome Software automatic updates:

dconf write /org/gnome/software/allow-updates false
dconf write /org/gnome/software/download-updates false

  These steps do not neuter Software completely - you can still use it to 
install/remove apps.
=-=-=-=-

I think preserving the ability to use gnome-software (as in this suggestion) is
quite useful for many users, so that should definitely be one of the options
offered.

I'm guessing that the alternative solution that I've seen (masking the
packagekit service) would not allow gnome-software to continue working. If I'm
wrong about that, that might instead be the right thing to suggest.

For people who are never going to want to install software via the GUI, it would
be easier if it were possible to do e.g. `apt remove gnome-software`. This
currently doesn't do what one wants, as the dependency from gnome-core to
gnome-software means that one ends up removing much of gnome along with
gnome-software.

Would it be possible to use a Recommends: there instead, to enable this?

Cheers, Phil.

Bug#1072977: bembo.debian.org TLS certificate is not signed by a well-known authority

[Antoine Le Gonidec]

While the update to apt-listbugs 0.1.42 does indeed trigger the
reported problem, its cause is not in apt-listbugs code itself.

This update uses https by default, but one of the servers answering to
bugs.debian.org (bembo.debian.org) uses a TLS certificate that is not
signed by a well-known authority, leading to the certificate
verification failure.

The other server answering to bugs.debian.org (buxtehude.debian.org)
does not have this problem, so people might not get this certificate
error when using apt-listbugs if they are lucky enough to contact the
server with the correct TLS configuration.

What should be fixed here is the TLS certificate served by
bembo.debian.org, not apt-listbugs itself.

Bug#1072977: bembo.debian.org TLS certificate is not signed by a well-known authority

[Antoine Le Gonidec]

> This update uses https by default, but one of the servers answering to
> bugs.debian.org (bembo.debian.org) uses a TLS certificate that is not
> signed by a well-known authority, leading to the certificate
> verification failure.

You can probably forget about that, further investigation seems to show
that I messed up during my tests and something else is amiss.

Sorry for the noise.

Bug#1072990: rsync error: error in rsync protocol data stream (code 12) at token.c(481) [sender=3.2.7]

[Norbert Schulz]

Hi Paul,

thanks for your quick answer.

If I run rsync without 'z' option the error is:

[receiver] exceeded --max-alloc=1073741824 setting (file=fileio.c, line=260)
rsync error: error allocating core memory buffers (code 22) at util2.c(80) 
[receiver=3.2.7]
rsync: [generator] write error: Broken pipe (32)
rsync: connection unexpectedly closed (18054825 bytes received so far) 
[generator]

Thanks for the hint '-e ssh'.


Regards
Norbert


Am 11.06.24 um 14:32 schrieb Paul Slootman:


On Tue 11 Jun 2024, Norbert Schulz wrote:


deflate on token returned 0 (6320 bytes left)

[...]


The rsync command is:
rsync  -avz --numeric-ids -e ssh --delete --delete-excluded   \

Could you try without the 'z' option?
There were issues with compression sometimes causing errors.

It's also possible that the compression is actually slowing the
transfer, if the network is fast enough.

Note that '-e ssh' is redundant, that has been default for a long time
now.


Thanks,
Paul

Bug#1029781: RFS: bandcamp-dl/0.0.13-1 [ITP] -- script to download bandcamp albums

[Phil Wyett]

Hi,

Are you still interested in pursuing the packaging of the application with the
goal of inclusion in Debian?

Regards

Phil

-- 

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1072992: pycryptodome: FTBFS: cannot find -lasan and -lubsan on loong64, sparc64 and other architectures

[zhangdandan]

Control: Severity -1 normal

Bug#1072994: Red and grey screens in some parts of applications/websites on Debian 12

[Pino Pasqualo]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20210115-1

When I was using different GNU/Linux distros (Trisquel, puppy linux, 
etc.) it has never happened to me.
But now, with Debian, I often see red screens on Brave homepage (not 
"Brave search"), Elisa, Duckduckgo AI Chat website, some of Debian 
popup, Discover, KDE Settings, grey screen around the search bar of 
Duckduckgo, red color around a youtube video etc. that suggest that I 
have graphic problems but not depending by me and my pc.

Can anyone explain how I can fix this problem?
Considering that I have had no such problems on kde and lxqt with other 
distributions, I think it is a problem that can be fixed and it is not 
up to my pc but Debian itself.
Also I don't think it's a ram problem, because with 4GB of swap memory I 
can have 1GB of ram free.


I opened a thread in this forum 
(https://forum.tuttosulinux.it/topic/24/schermate-rosse-in-alcune-parti-delle-applicazioni-siti-web-su-debian) 
and someone helped me to do some step to see if it was possible to fix 
this problem but failing. What they told me to do with no success is:


- trying to re-install mesa drivers and intel driver ones

- changing themes of LXQT and Desktop Environment (I tried XFCE, MATE, 
LXQT, IceWM, KDE x11 and KDE Wayland)


- uninstalling xserver-xorg-video-intel of Debian 12 and installing just 
xserver-xorg-video-vesa but after the GRUB interface it won't login and 
I had a black screen with a flashing dash so I re-installed 
xserver-xorg-video-intel of Debian 12 from the recovery mode and logged 
again.


- forcing to use modesetting without using "glamor" (because my graphic 
card is not compatible) doing: "sudoedit 
/etc/X11/xorg.conf.d/20-intel.conf" and putting inside one of these 2 
options:


1. Section "Device"
    Identifier "Intel Graphics"
    Driver  "modesetting"
    Option  "AccelMethod"    "none"
EndSection

2.  Section "Device"
    Identifier "Intel Graphics"
    Driver  "vesa"
EndSection

When I typed the first option (modesetting one) at the reboot the 
computer's performance drastically deteriorated to the point that no 
applications would open on kde, not even the "start" menu.

To turn off the computer I had to press the physical button.

When I typed the second option (vesa one) at the reboot I had, before 
the login, a black screen with this row: "[FAILED] Failed to start 
lightdm.service - Light Display Manager."


- Modifying sources.list to put Debian 11 repos in order to install the 
old xserver-xorg-video-intel driver. I removed from the synaptic: 
xserver-xorg-video-intel of Debian 12 and xserver-xorg-core of Debian 
12. Then I did a sudo apt update, and "sudo apt install -t bullseye 
xserver-xorg-video-intel xserver-xorg-core". This procedure removed xcvt 
too.
At the reboot I could see the login interface but my keyboard was off, 
my mouse was on but couldn't move and the input box was lightning but 
then freezed itself and I think all my pc.
So from the recovery mode I installed xserver-xorg-input-all of Debian 
12 with: "sudo apt install xserver-xorg-input-all" and I was in able to 
login from the past login interface at the reboot.

But the red and grey screen continued to be there.

Waiting for your updates and I'm here for all of your doubts about! 

Please if you want other details visit the thread of the forum too 
because it is difficult to me tell you everything in details and in a 
summary. 
(https://forum.tuttosulinux.it/topic/24/schermate-rosse-in-alcune-parti-delle-applicazioni-siti-web-su-debian/19)


My PC specifications according to neofetch are:/
/

/OS: Debian GNU/Linux 12 (bookworm) x86_64 /

/Host: NQ834AA-ABZ CQ2100IT IT920 03l0411RE101HPQ 00 /

/Kernel: 6.1.0-21-amd64 /

/Uptime: 1 hour, 22 mins /

/Packages: 2784 (dpkg) /

/Shell: bash 5.2.15 /

/Resolution: 1280x1024 /

/DE: Plasma 5.27.5 /

/WM: KWin /

/Theme: [Plasma], Adwaita [GTK2/3] /

/Icons: [Plasma], Adwaita [GTK2], breeze-dark [GTK3] /

/Terminal: konsole /

/CPU: Intel Atom 230 (2) @ 1.596GHz /

/GPU: Intel 82945G/GZ /

/Memory: 1374MiB / 1958MiB /

Bug#1072990: rsync error: error in rsync protocol data stream (code 12) at token.c(481) [sender=3.2.7]

[Paul Slootman]

On Tue 11 Jun 2024, Norbert Schulz wrote:

> deflate on token returned 0 (6320 bytes left)

[...]

> The rsync command is:
> rsync  -avz --numeric-ids -e ssh --delete --delete-excluded   \

Could you try without the 'z' option?
There were issues with compression sometimes causing errors.

It's also possible that the compression is actually slowing the
transfer, if the network is fast enough.

Note that '-e ssh' is redundant, that has been default for a long time
now.


Thanks,
Paul

Bug#1072993: please add OnlyShowIn=GNOME;Unity; in com.mattjakeman.ExtensionManager.desktop

[xiao sheng wen]

Package: gnome-shell-extension-manager
Version: 0.4.0-1
Severity: minor
Tags: upstream
X-Debbugs-Cc: atzli...@sina.com

Hi,

  The gnome-shell-extension-manager is only use in GNOME, so add field:

OnlyShowIn=GNOME;Unity;

in com.mattjakeman.ExtensionManager.desktop file is better.

After add this OnlyShowIn fielld, this desktop will not show in 
Xfce,Mate,KDE,etc,.

Thanks!
xiao sheng wen


-- System Information:
Release:12.5.0
Codename:   bookworm
Architecture: x86_64

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

Versions of packages gnome-shell-extension-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gjs  1.74.2-1+deb12u1
ii  gnome-shell  43.9-0+deb12u2
ii  libadwaita-1-0   1.2.2-1
ii  libc62.36-9+deb12u7
ii  libglib2.0-0 2.74.6-2+deb12u2
ii  libgtk-4-1   4.8.3+ds-2+deb12u1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libsoup-3.0-03.2.2-2
ii  libtext-engine-0.1-0 0.1.1-4

gnome-shell-extension-manager recommends no packages.

gnome-shell-extension-manager suggests no packages.

-- no debconf information

Bug#1072963: jpeg-xl: Failing autopkgtests on non-amd64

[Julian Wollrath]

Am Di, 11 Jun 2024 13:22:29 +0100
schrieb Simon McVittie :

> On Tue, 11 Jun 2024 at 13:28:52 +0200, Chris Hofstaedtler wrote:
> > Maybe smcv can chime in here.
>
> [...]
> > I think there is a better way than running a
> > postinst script in each individual package (triggers?).
>
> Yes, there is a better way, and it is triggers.
>
> libgdk-pixbuf-2.0-0 registers a trigger on
> /usr/lib/MULTIARCH/gdk-pixbuf-2.0/2.10.0/loaders which should result
> in it automatically running
> /usr/lib/MULTIARCH/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
> every time a package that provides a gdk-pixbuf loader is installed,
> removed or updated.
>
> As a result, a jpeg-xl loader for gdk-pixbuf should not need to do
> anything special in its postinst at all: it should install a loader
> that matches the naming convention set by gdk-pixbuf, and that should
> be enough for the gdk-pixbuf packaging to handle the rest. If the
> trigger is not sufficient, please report a bug with
> steps-to-reproduce.
>
> The naming convention is ${gdk_pixbuf_moduledir}/*.so, where
> ${gdk_pixbuf_moduledir} should be discovered at build-time from
> the gdk-pixbuf-2.0 pkgconf module. Hopefully the upstream build system
> already does this correctly.
>
> heif-gdk-pixbuf from src:libheif, librsvg2-common from src:rsvg, and
> webp-pixbuf-loader from src:webp-pixbuf-loader might be good examples
> of a working gdk-pixbuf loader.
>
> heif-gdk-pixbuf and webp-pixbuf-loader do not seem to have any
> hand-written code in their postinsts at all, so they completely rely
> on gdk-pixbuf's triggers, and that seems to work fine in practice.

Thank you for the explanation. Then the postinst/postrm scripts can be
dropped, since the trigger triggers.


Cheers,
Julian

--
 ()  ascii ribbon campaign - against html e-mail
 /\- against proprietary attachments

Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback

[Helmut Grohne]

Hi Jonas,

On Fri, Jun 07, 2024 at 05:00:44PM +0200, Jonas Smedegaard wrote:
> dbus depends versioned on usr-is-merged, which is now a transitional
> package depending on base-files.
> 
> Please change the dependency to be declared like this:
> 
>   Depends: base-files (>= 13.3~) | usr-is-merged (>= 38~)
> 
> That allows dropping the transitional package.

I think this request is not reasonable as is. Let's find out what we
really want here.

The semantics of base-files (>= 13.3~) and usr-is-merged (>= 38~)
actually differ and your proposed change weakens the promises. In
particular, usr-is-merged declares Conflicts for a fair number of
packages to ensure that certain bugs are not present. base-files does
not carry these conflicts, so by adding the alternative you are implying
that these conflicts would be no longer needed.

Then when you do not need the Conflicts, you might as well change the
dependency to unversioned usr-is-merged as the only important features
(from a client package pov) that usr-is-merged gained with higher
versions are those Conflicts. Once you weaken it to the unversioned
usr-is-merged, the provides from base-files actually suffices. It does
seem reasonable that someone added the version restriction by accident.
For dbus, it was added via #1054650, but the bug log does not express
why the version restriction was needed.

It would also be conceivable to have base-files do versioned provides of
usr-is-merged. I considered this and concluded that it was a bad idea,
because base-files would have to also carry all those Conflicts then. We
want base-files to be upgraded early and those Conflicts would cause it
to get upgraded late even though they are only really needed in some
cases such as dbus. Hence I intentionally opted for not copying the
Conflicts and thus not doing versioned provides.

Given the above, it feels right to me that dbus pulls the physical
usr-is-merged package whose purpose at this time is forcing other
packages off the system.

In the event that the Conflicts are not important to dbus, the obvious
solution is to drop the version. In this case, waiting for base-files to
migrate is not required. In no case is adding a base-files alternative a
good thing to do.

Helmut

Bug#1072992: pycryptodome: FTBFS: cannot find -lasan and -lubsan on loong64, sparc64 and other architectures

[zhangdandan]

Source: pycryptodome
Version: 3.20.0+dfsg-1
Severity: serious
Tags: ftbfs
User: debian-loonga...@lists.debian.org
Usertags: loong64

Compiling the pycryptodome failed for loong64 and others architectures 
in the Debian Package Auto-Building environment.

...
[  3%] Building C object CMakeFiles/test_mont.dir/test_mont.c.o
[  4%] Linking C executable test_mont
/usr/bin/ld: cannot find libasan_preinit.o: No such file or directory
/usr/bin/ld: cannot find -lasan: No such file or directory
/usr/bin/ld: cannot find -lubsan: No such file or directory
collect2: error: ld returned 1 exit status
make[4]: *** [CMakeFiles/test_mont.dir/build.make:99: test_mont] Error 1
make[4]: Leaving directory '/<>/src/test'
make[3]: *** [CMakeFiles/Makefile2:155: CMakeFiles/test_mont.dir/all] 
Error 2

make[3]: Leaving directory '/<>/src/test'

The full log can be found at 
https://buildd.debian.org/status/package.php?p=pycryptodome=sid.



Thanks,
Dandan Zhang

Bug#1072991: cifs-utils depends on python - need it?

[Jo King]

Package: cifs-utils
Version: 2:6.11-3.1+deb11u2

In debian 11 and 12 (oldstable and stable) python is a 'deps'. In debian 10 it 
isn't.

Suggested fix: cifs-utils package made to not depend on python.

Ramble:
Ideally all bits of samba would work without python (someone did provide a 
patch years ago...)
Debian USP is its ability to function as a desktop without depending on python.
Very different from Ubuntu/Fedora...

Thanks, jo

Bug#1072963: jpeg-xl: Failing autopkgtests on non-amd64

[Simon McVittie]

On Tue, 11 Jun 2024 at 13:28:52 +0200, Chris Hofstaedtler wrote:
> Maybe smcv can chime in here.

(I am not a maintainer of gdk-pixbuf and I do not intend to be any
sort of single point of failure for Debian's use of gdk-pixbuf; I have
sometimes done team uploads of it as part of the GNOME team, but please
don't rely on me to keep the distribution working. Please consider using
@packages.debian.org addresses if you want to get an opinion from the
uploaders of a related package without blocking on a named individual.)

On Tue, 11 Jun 2024 at 13:28:52 +0200, Chris Hofstaedtler wrote:
> On Tue, Jun 11, 2024 at 01:04:06PM +0200, Julian Wollrath wrote:
> > > > Specifically, the problem is that debian/libjxl-gdk-pixbuf.postinst
> > > > and debian/libjxl-gdk-pixbuf.postrm have hardcoded the amd64
> > > > architecture

If true (I have not checked) then that's clearly a bug.

> > in principle [gdk-pixbuf-query-loaders]
> > should be called, to make gdk-pixbuf
> > aware of the jpeg-xl loader.
>
> I think there is a better way than running a
> postinst script in each individual package (triggers?).

Yes, there is a better way, and it is triggers.

libgdk-pixbuf-2.0-0 registers a trigger on
/usr/lib/MULTIARCH/gdk-pixbuf-2.0/2.10.0/loaders which should result
in it automatically running
/usr/lib/MULTIARCH/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
every time a package that provides a gdk-pixbuf loader is installed,
removed or updated.

As a result, a jpeg-xl loader for gdk-pixbuf should not need to do
anything special in its postinst at all: it should install a loader
that matches the naming convention set by gdk-pixbuf, and that should be
enough for the gdk-pixbuf packaging to handle the rest. If the trigger
is not sufficient, please report a bug with steps-to-reproduce.

The naming convention is ${gdk_pixbuf_moduledir}/*.so, where
${gdk_pixbuf_moduledir} should be discovered at build-time from
the gdk-pixbuf-2.0 pkgconf module. Hopefully the upstream build system
already does this correctly.

heif-gdk-pixbuf from src:libheif, librsvg2-common from src:rsvg, and
webp-pixbuf-loader from src:webp-pixbuf-loader might be good examples of
a working gdk-pixbuf loader.

heif-gdk-pixbuf and webp-pixbuf-loader do not seem to have any
hand-written code in their postinsts at all, so they completely rely on
gdk-pixbuf's triggers, and that seems to work fine in practice.

librsvg2-common does have code in its postinst, but it seems to be a
workaround for an old bug
(https://bugs.launchpad.net/ubuntu/+source/librsvg/+bug/719861) and
is probably unnecessary now that gdk-pixbuf is using interest-noawait
triggers.

smcv

Bug#1072990: rsync error: error in rsync protocol data stream (code 12) at token.c(481) [sender=3.2.7]

[Norbert Schulz]

Package: rsync
Version: 3.2.7-1
Severity: normal

Dear Maintainer,

rsync faild to sync with the following error after syncing a few files:
receiving file list ... done
./
etc/cups/
etc/cups/printers.conf
etc/cups/printers.conf.O
etc/cups/subscriptions.conf
etc/cups/subscriptions.conf.O
etc/cups/ppd/
etc/cups/ppd/Brother_MFC_L2710DW_series.ppd
etc/cups/ppd/Brother_MFC_L2710DW_series_BRNB422000DB15D_local_barsch.ppd
etc/cups/ppd/Brother_MFC_L2710DW_series_barsch.ppd
etc/cups/ppd/Generic_PostScript_barsch.ppd
etc/cups/ppd/PDF_barsch.ppd
home/norbert/
home/norbert/.Xauthority
home/norbert/.bash_history
deflate on token returned 0 (6320 bytes left)
rsync error: error in rsync protocol data stream (code 12) at token.c(481) 
[sender=3.2.7]
rsync: connection unexpectedly closed (4847775 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(231) 
[receiver=3.2.7]
rsync: [generator] write error: Broken pipe (32)
rsync error: error in socket IO (code 10) at io.c(848) [generator=3.2.7]

The rsync command is:
rsync  -avz --numeric-ids -e ssh --delete --delete-excluded   \
--exclude-from="$EXCLUDES" --exclude="- *.LN*" \
$EXTRAOPT \
$SERVER:/ $DATA_PATH/$SERVER/daily.0

The $XXX variables are defined before in the backup script. 
This rsync script runs on the backup server and saves computers in the local 
network. In the network
there are also outdatet versions of rsynch (3.0.9-4+deb7u2 and 3.1.2-1+deb9u3) 
which runs without 
any errors. Errors occur only with version of 3.2.7-1. 

Any help would be great and thanksfull

Regards
Norbert Schulz  


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

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

Versions of packages rsync depends on:
ii  init-system-helpers1.65.2
ii  libacl12.3.1-3
ii  libc6  2.36-9+deb12u7
ii  liblz4-1   1.9.4-1
ii  libpopt0   1.19+dfsg-1
ii  libssl33.0.11-1~deb12u2
ii  libxxhash0 0.8.1-1
ii  libzstd1   1.5.4+dfsg2-5
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client   1:9.2p1-2+deb12u2
ii  openssh-server   1:9.2p1-2+deb12u2
ii  python3  3.11.2-1+b1
pn  python3-braceexpand  

-- no debconf information

Bug#1072989: libamazon-s3-perl: get_keys() method fails when retrieving keys with charset spec in content-type

[Matthias Bethke]

Package: libamazon-s3-perl
Version: 0.65-1
Severity: important
Tags: patch

Dear Maintainer,

I just made a very small but in some cases crucial fix for the above bug
in the upstream package:
https://github.com/rlauer6/perl-amazon-s3/pull/16

As far as I could see, the Debian package ist still built from CPAN
releases where it hasn't landed yet, but v2.0.2 is tagged on Github
already. It might make sense to change the upstream to
https://github.com/rlauer6/perl-amazon-s3 because the author hasn't
uploaded any of the post-0.65 versions to CPAN.

cheers,
Matthias

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 libamazon-s3-perl depends on:
pn  libclass-accessor-perl 
pn  libdigest-hmac-perl
pn  libdigest-md5-file-perl
pn  libhttp-date-perl  
pn  libio-stringy-perl 
pn  liblwp-protocol-https-perl 
pn  liblwp-useragent-determined-perl   
pn  libnet-amazon-signature-v4-perl
pn  libreadonly-perl   
pn  liburi-perl
pn  libwww-perl
pn  libxml-simple-perl 
ii  perl [libjson-pp-perl] 5.36.0-7+deb12u1
ii  perl-base [libscalar-list-utils-perl]  5.36.0-7+deb12u1

libamazon-s3-perl recommends no packages.

libamazon-s3-perl suggests no packages.

Bug#1069498: libx86emu: FTBFS on armhf: mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean ‘ins’? [-Werror=implicit-function-declaration]

[John Paul Adrian Glaubitz]

Hi Guillem,

On Tue, 2024-06-11 at 13:42 +0200, Guillem Jover wrote:
> > I had a look at this, and it seems like this package has never really
> > worked on ARM systems at all? And this was hidden due to the missing
> > declarations not being an error.
> > 
> > AFAIK, only x86 (i386 and amd64), ia64 and alpha have port I/O, other
> > systems have instead memory mapped I/O, but the code in mem.c is
> > unconditionally calling port I/O functions such as in*() and out*(),
> > provided by glibc.
> > 
> > Until the upstream code is ported to systems with memory mapper I/O, I
> > think the "best" way to resolve this would be to restrict the
> > architecture list to:
> > 
> >   any-amd64 any-i386 alpha ia64
> 
> The attached patch implements this. It should not affect reverse build
> depending packages (only hwinfo) which is already arch restricted to
> «amd64 i386».
> 
> I'm including the arm list to confirm the above, but also in case
> someone there feels like porting the library to support memory mapped
> I/O? (But perhaps that's not worth the effort.)

It's perfectly fine to disable libx86emu on ARM as it has already been
correctly stated, there are no I/O ports on ARM so the above code won't
work on ARM.

I also don't expect that to change in the future, so it's not worth bothering
about this in the future, especially since the upstream project hasn't been
very active lately [1].

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1072963: jpeg-xl: Failing autopkgtests on non-amd64

[Julian Wollrath]

Am Di, 11 Jun 2024 13:28:52 +0200
schrieb Chris Hofstaedtler :

> On Tue, Jun 11, 2024 at 01:04:06PM +0200, Julian Wollrath wrote:
> > > > Specifically, the problem is that
> > > > debian/libjxl-gdk-pixbuf.postinst and
> > > > debian/libjxl-gdk-pixbuf.postrm have hardcoded the amd64
> > > > architecture which means that libjxl-gdk-pixbuf is
> > > > uninstallable on architectures other than amd64.
> > >
> > > Could you comment on the above ?
> >
> > hmm, in principle that utility should be called, to make gdk-pixbuf
> > aware of the jpeg-xl loader. Maybe a workaround would be to have
> > $ cat libjxl-gdk-pixbuf.postinst
> > #!/bin/sh -e
> > for X in /usr/lib/*/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
> > do
> > if [ -x ${X} ]; then
> > ${X} --update-cache
> [..]
>
> > instead? And for libjxl-gdk-pixbuf.postrm this should also work. Or
> > is there a better way, to get the library triplet for the
> > architecture of the packet, that is being installed?
>
> https://manpages.debian.org/bookworm/debhelper/dh_installdeb.1.en.html#SUBSTITUTION_IN_MAINTAINER_SCRIPTS
> documents which tokens are available at build time to generate the
> maintscripts.

Thanks. So the path to the binary would be
/usr/lib/#DEB_TARGET_MULTIARCH#/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders

>
> I've CCed smcv@, as I think there is a better way than running a
> postinst script in each individual package (triggers?). Maybe smcv
> can chime in here.

Agreed, seeing, that this is not the only available loader, a more
generic way could be cleaner.


Cheers,
Julian

>
> Chris
>



--
 ()  ascii ribbon campaign - against html e-mail
 /\- against proprietary attachments

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

[Diederik de Haas]

On Tuesday, 11 June 2024 12:26:17 CEST Leith Bade wrote:
> For the record the issues I noticed are (comparing with U-boot and OpenWRTs
> versions of the device tree files):
> - mt7986a.dtsi is missing entry for the SNFI / SNAND interface to load
> https://github.com/torvalds/linux/blob/83a7eefedc9b56fe7bfeff13b6c7356688ffa
> 670/drivers/spi/spi-mtk-snfi.c this is not populated on the BPI-R3 but other
> boards might use this 

Generally, `*.dtsi` files get included into other files, usually `.dts` files.
The `mt7986a.dtsi` (likely) describes the SoC, not the full device. The device 
likely has the flash chip, not the SoC, so the dts file should have an entry 
for 
the flash chip (the dts file for OpenWrt One does f.e.).

> - in OpenWRT device tree there are a lot more entries in the efuse map
> related to the USB and PCIe ports - it seems the USB and PCIe device entries
> then use these efuse values

DeviceTree files describe the hardware, so *ideally* there should be no 
difference between what the Linux kernel has (which is generally considered the 
upstream project for DT files) and what OpenWrt has/uses.
Unfortunately, we don't live in an ideal world ;-)
If OpenWrt's DT are better (I don't know), then it would be great if they 
would upstream their improvements to the Linux kernel.
But AFAIK, OpenWrt has/manages their own kernel and DT files.

I know u-boot now has an OF_UPSTREAM (OF=OpenFirmware=DT) 'setting', which I 
*think* means they're (in the process of) switching to using the Linux 
kernel's DeviceTree files.

> - no hnat device - though maybe this is only usable with the proprietary
> Mediatek driver code

I have no idea what that is (for).

> - in OpenWRT device tree there is a different "compatible" string for spi0
> (quad) and spi1 (single) - I am not sure if that matters with the upstream
> driver, hopefully there is a way to check that the MTD device is using the
> quad SPI / SPIM mode

The "compatible" string is used to find the appropriate driver (IIUC), so if 
spi0 and spi1 have different "compatible"s, then they (apparently) need 
different drivers from them.
But as said before, (technically) OpenWrt is their own project, so it doesn't 
have to match what current upstream does/has. (OpenWrt doesn't track Linus'  
'master' branch but the most recent LTS version, which they then patch)

> - the BPI-R3 .dtso overlay files for the NAND and NOR flash options have
> partition definitions that don't match the device tree in U-boot and
> OpenWRT - ideally these should match the partitions on a factory fresh
> board which comes OpenWRT preloaded

It (generally) doesn't sound good if different projects use/assume different 
partition layouts. It could be one (or more) projects have incorrect and/or 
incomplete implementation. I don't know. It could be worth investigating what 
the correct values are and submitting patches to those projects to get that 
fixed.

> I noticed a few problems but I am not sure what normal protocol is - should
> I report it as a bug to Linux directly?

The best way to deal with it depends on the project (and could also depend on 
the subsystem of that project). AFAIK they all use Mailing Lists, but AFAIK 
OpenWrt also use Pull Requests on GH, which the (majority of the) Linux kernel 
does not. So you'll need to investigate how the project(s) you want to 
contribute too (generally) operates.

And learn/verify whether what you found is actually a bug and in which 
project(s) the problem is, and not f.e. that you were looking in the wrong 
place (dtsi vs dts).

HTH and have fun!
  Diederik

PS: this bug report is probably not the right place for these kind of 
discussions

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

Bug#1069498: libx86emu: FTBFS on armhf: mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean ‘ins’? [-Werror=implicit-function-declaration]

[Guillem Jover]

Control: tag -1 patch

[ CCing debian-arm list to loop them into the porting issue. ]

Hi!

On Fri, 2024-06-07 at 14:42:18 +0200, Guillem Jover wrote:
> On Sat, 2024-04-20 at 14:56:40 +0200, Lucas Nussbaum wrote:
> > Source: libx86emu
> > Version: 3.5-1
> > Severity: serious
> > Justification: FTBFS
> > Tags: trixie sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf
> 
> > During a rebuild of all packages in sid, your package failed to build
> > on armhf.

> > Relevant part (hopefully):
> > > cc -g -O2 -Werror=implicit-function-declaration 
> > > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > > -fstack-clash-protection -Wformat -Werror=format-security -g -O2 -fPIC 
> > > -fvisibility=hidden -fomit-frame-pointer -Wall -D_LARGEFILE_SOURCE 
> > > -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
> > > -Wl,-z,relro -Wl,-z,now -c ops.c
> > > mem.c: In function ‘vm_i_byte’:
> > > mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean 
> > > ‘ins’? [-Werror=implicit-function-declaration]
> > >   581 | return inb(addr);
> > >   |^~~
> > >   |ins
> > > mem.c: In function ‘vm_i_word’:
> > > mem.c:619:10: error: implicit declaration of function ‘inw’; did you mean 
> > > ‘ins’? [-Werror=implicit-function-declaration]
> > >   619 |   return inw(addr);
> > >   |  ^~~
> > >   |  ins
> > > mem.c: In function ‘vm_i_dword’:
> > > mem.c:657:10: error: implicit declaration of function ‘inl’; did you mean 
> > > ‘ins’? [-Werror=implicit-function-declaration]
> > >   657 |   return inl(addr);
> > >   |  ^~~
> > >   |  ins
> > > mem.c: In function ‘vm_o_byte’:
> > > mem.c:676:5: error: implicit declaration of function ‘outb’; did you mean 
> > > ‘outs’? [-Werror=implicit-function-declaration]
> > >   676 | outb(val, addr);
> > >   | ^~~~
> > >   | outs
> > > mem.c: In function ‘vm_o_word’:
> > > mem.c:711:3: error: implicit declaration of function ‘outw’; did you mean 
> > > ‘outs’? [-Werror=implicit-function-declaration]
> > >   711 |   outw(val, addr);
> > >   |   ^~~~
> > >   |   outs
> > > mem.c: In function ‘vm_o_dword’:
> > > mem.c:748:3: error: implicit declaration of function ‘outl’; did you mean 
> > > ‘outs’? [-Werror=implicit-function-declaration]
> > >   748 |   outl(val, addr);
> > >   |   ^~~~
> > >   |   outs
> > > cc1: some warnings being treated as errors
> > > make[1]: *** [Makefile:22: mem.o] Error 1
> 
> I had a look at this, and it seems like this package has never really
> worked on ARM systems at all? And this was hidden due to the missing
> declarations not being an error.
> 
> AFAIK, only x86 (i386 and amd64), ia64 and alpha have port I/O, other
> systems have instead memory mapped I/O, but the code in mem.c is
> unconditionally calling port I/O functions such as in*() and out*(),
> provided by glibc.
> 
> Until the upstream code is ported to systems with memory mapper I/O, I
> think the "best" way to resolve this would be to restrict the
> architecture list to:
> 
>   any-amd64 any-i386 alpha ia64

The attached patch implements this. It should not affect reverse build
depending packages (only hwinfo) which is already arch restricted to
«amd64 i386».

I'm including the arm list to confirm the above, but also in case
someone there feels like porting the library to support memory mapped
I/O? (But perhaps that's not worth the effort.)

Thanks,
Guillem
From bafb0ddee8942c60b17745547854b3ed53ca4545 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 11 Jun 2024 13:30:40 +0200
Subject: [PATCH] Do not build on ARM architectures where there is no port I/O

Only x86 (i386 and amd64), ia64 and alpha have port I/O, other systems
have instead memory mapped I/O, but the code in mem.c is unconditionally
calling port I/O functions such as in*() and out*(), provided by glibc.

Until the upstream code is ported to systems with memory mapped I/O, the
best way forward is to restrict to systems that are supported right now.

(The only current package build depending on libx86emu-dev is already
arch restricted to amd64 and i386.)
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index f10e3e2..e8c974b 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Homepage: https://github.com/wfeldt/libx86emu
 Rules-Requires-Root: no
 
 Package: libx86emu3
-Architecture: any-amd64 any-i386 alpha armel armhf ia64
+Architecture: any-amd64 any-i386 alpha ia64
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -23,7 +23,7 @@ Description: x86 emulation library
  This package contains the library.
 
 Package: libx86emu-dev
-Architecture: any-amd64 any-i386 alpha armel armhf ia64
+Architecture: any-amd64 any-i386 alpha ia64
 Multi-Arch: same
 Section: libdevel
 Depends: libx86emu3 (= 

Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration

[Otto Kekäläinen]

Hi!

I am travelling and on slow internet. I will review and hopefully help
you with feedback this weekend.

Bug#1052660: gst-plugins-bad1.0: Fails to build: netsim build test failing

[Jeremy Bícha]

On Tue, Jun 11, 2024 at 7:02 AM Emilio Pozuelo Monfort  wrote:
> On Mon, 25 Sep 2023 15:52:57 -0400 Jeremy Bicha  
> wrote:
> > Forwarded: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3000
> >
> > gst-plugins-bad1.0's elements_netsim build test began failing sometime
> > after July 6 but before August 15 because of a change in its build
> > depends.
> >
> > Also reported as https://launchpad.net/bugs/2037323
>
> I don't see this happening on the Debian buildds from looking at a few old 
> logs.
> Not sure if it's fixed or if it was specific to some buildd configuration, but
> for now let's downgrade the bug.

We simply ignore the test failure. Thank you for downgrading!

https://salsa.debian.org/gstreamer-team/gst-plugins-bad1.0/-/blob/master/debian/patches/Skip-failing-tests.patch

Jeremy Bícha

Bug#1072963: jpeg-xl: Failing autopkgtests on non-amd64

[Chris Hofstaedtler]

On Tue, Jun 11, 2024 at 01:04:06PM +0200, Julian Wollrath wrote:
> > > Specifically, the problem is that debian/libjxl-gdk-pixbuf.postinst
> > > and debian/libjxl-gdk-pixbuf.postrm have hardcoded the amd64
> > > architecture which means that libjxl-gdk-pixbuf is uninstallable on
> > > architectures other than amd64.
> > 
> > Could you comment on the above ?
> 
> hmm, in principle that utility should be called, to make gdk-pixbuf
> aware of the jpeg-xl loader. Maybe a workaround would be to have
> $ cat libjxl-gdk-pixbuf.postinst
> #!/bin/sh -e
> for X in /usr/lib/*/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
> do
>   if [ -x ${X} ]; then
>   ${X} --update-cache
[..]
 
> instead? And for libjxl-gdk-pixbuf.postrm this should also work. Or is
> there a better way, to get the library triplet for the architecture of
> the packet, that is being installed?

https://manpages.debian.org/bookworm/debhelper/dh_installdeb.1.en.html#SUBSTITUTION_IN_MAINTAINER_SCRIPTS
documents which tokens are available at build time to generate the
maintscripts.

I've CCed smcv@, as I think there is a better way than running a
postinst script in each individual package (triggers?). Maybe smcv
can chime in here.

Chris

Bug#1069426: nocache: FTBFS on armhf: ccsSPzHW.s:3650: Error: symbol `fopen64' is already defined

[Guillem Jover]

Control: tag -1 patch

Hi!

On Sat, 2024-04-20 at 15:01:27 +0200, Lucas Nussbaum wrote:
> Source: nocache
> Version: 1.1-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf

> During a rebuild of all packages in sid, your package failed to build
> on armhf.
> 
> 
> Relevant part (hopefully):
> > cc -g -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > -fstack-clash-protection -Wformat -Werror=format-security -Wall 
> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time 
> > -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -fPIC -c -o pageinfo.o 
> > pageinfo.c
> > sed 's!##libdir##!$(dirname "$0")!' nocache
> > chmod a+x nocache
> > /tmp/ccsSPzHW.s: Assembler messages:
> > /tmp/ccsSPzHW.s:3650: Error: symbol `fopen64' is already defined
> > make[1]: *** [Makefile:27: nocache.o] Error 1

I've provided a PR upstream to fix this at:

  https://github.com/Feh/nocache/pull/55

Thanks,
Guillem

Bug#1072979: [Debian-med-packaging] Bug#1072979: beast-mcmc - build-dependencies unsatisfiable on i386.

[Charles Plessy]

Control: retitle -1 RM: beast-mmc [i386] -- RoM ; dependency not available 
anymore
Control: reassign -1 ftp.debian.org

Hi all,

> On 11 June 2024 at 10:05, Peter Green wrote:
> | 
> | beast-mcmc build-depends on r-cran-rjava, which is no longer available
> | on i386. It appears that the package failed to build, and the old
> | binaries were then removed.

Le Tue, Jun 11, 2024 at 05:38:53AM -0500, Dirk Eddelbuettel a écrit :
> 
> I do not think there is much we can do besides not building beast-mcmc on
> i386.

ditto,

and I think that it would be great if these arch-specific removals were
handled automatically.  That would save everybody a lot of work!

Cheers,

Charles
-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1072831: getting memory info fails when running under lxc

[Paul Slootman]

On Tue 11 Jun 2024, Paul Slootman wrote:

> This works for me. Patch attached.

I see I missed the case lseek() fails with another errno.
Updated patch attached.


Paul
--- library/meminfo.c.orig	2023-07-11 11:09:18.436786212 +0200
+++ library/meminfo.c	2024-06-11 13:11:12.878627527 +0200
@@ -646,12 +646,20 @@
 // clear out the soon to be 'current' values
 memset(>hist.new, 0, sizeof(struct meminfo_data));
 
-if (-1 == info->meminfo_fd
-&& (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY
-return 1;
-
-if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
-return 1;
+if (-1 == info->meminfo_fd) {
+	if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+	return 1;
+}
+else {
+	if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
+	if (ESPIPE == errno) {
+		close(info->meminfo_fd);
+		if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+		return 1;
+	}
+	else
+		return 1;
+}
 
 for (;;) {
 if ((size = read(info->meminfo_fd, buf, sizeof(buf)-1)) < 0) {

Bug#1072963: jpeg-xl: Failing autopkgtests on non-amd64

[Julian Wollrath]

Hi,

Am Di, 11 Jun 2024 08:19:54 +0200
schrieb Mathieu Malaterre :

> Julian,
> 
> On Tue, Jun 11, 2024 at 1:06 AM Jeremy Bícha
>  wrote:
> >
> > Source: jpeg-xl
> > Version: 0.9.2-6
> > Severity: serious
> > Tags: experimental
> >
> > jpeg-xl in experimental has autopkgtests that are failing on all
> > architectures except for amd64.
> >
> > Specifically, the problem is that debian/libjxl-gdk-pixbuf.postinst
> > and debian/libjxl-gdk-pixbuf.postrm have hardcoded the amd64
> > architecture which means that libjxl-gdk-pixbuf is uninstallable on
> > architectures other than amd64.
> >
> > https://ci.debian.net/packages/j/jpeg-xl/unstable/arm64/
> >
> > https://salsa.debian.org/debian-phototools-team/libjxl/-/blob/debian/experimental/debian/libjxl-gdk-pixbuf.postinst
> >   
> 
> Could you comment on the above ?

hmm, in principle that utility should be called, to make gdk-pixbuf
aware of the jpeg-xl loader. Maybe a workaround would be to have
$ cat libjxl-gdk-pixbuf.postinst
#!/bin/sh -e
for X in /usr/lib/*/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
do
if [ -x ${X} ]; then
${X} --update-cache
fi
done
#DEBHELPER#

instead? And for libjxl-gdk-pixbuf.postrm this should also work. Or is
there a better way, to get the library triplet for the architecture of
the packet, that is being installed?


Cheers,
Julian

> 
> Thanks



-- 
 ()  ascii ribbon campaign - against html e-mail 
 /\- against proprietary attachments

Bug#1052660: gst-plugins-bad1.0: Fails to build: netsim build test failing

[Emilio Pozuelo Monfort]

Control: severity -1 important

On Mon, 25 Sep 2023 15:52:57 -0400 Jeremy Bicha  
wrote:

Source: gst-plugins-bad1.0
Version: 1.22.4-1
Severity: serious
Tags: ftbfs trixie sid
Forwarded: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3000

gst-plugins-bad1.0's elements_netsim build test began failing sometime
after July 6 but before August 15 because of a change in its build
depends.

Also reported as https://launchpad.net/bugs/2037323


I don't see this happening on the Debian buildds from looking at a few old logs. 
Not sure if it's fixed or if it was specific to some buildd configuration, but 
for now let's downgrade the bug.


Cheers,
Emilio

Bug#1072979: beast-mcmc - build-dependencies unsatisfiable on i386.

[Dirk Eddelbuettel]

On 11 June 2024 at 10:05, Peter Green wrote:
| Package: beast-mcmc
| Version: 1.10.4+dfsg-5
| Severity: serious
| x-debbugs-cc: r-cran-rj...@packages.debian.org
| 
| beast-mcmc build-depends on r-cran-rjava, which is no longer available
| on i386. It appears that the package failed to build, and the old
| binaries were then removed.

That can happen. It is the summer of 2024 and many upstream projects, R
included, stopped supporting i386.

I do not think there is much we can do besides not building beast-mcmc on
i386.

Dirk

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

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"

[David Bremner]

Axel Beckert  writes:

> Hi David,
>
> David Bremner wrote:
>> swaks -t brem...@debian.org --pipe 'gdb -batch -ex run -ex bt --args 
>> /usr/lib/sendmail -bs'
>> 
>> This actually runs without segfaulting, which made me think it might be
>> a memory error.
>
> There's one memory fix commit upstream in the master branch:
> https://github.com/bruceg/nullmailer/commit/834e2eb6b7eac2648fc371c432a46e98d5966bb4
>
> Could it be this one? At least "fdbuf.c" sounds as if it might be
> involved in file descriptor thingies.
>

We're actually running a snapshot of master, so that commit is in
testing and unstable.

d

Bug#1072962: efibootguard kernel stub fails to boot

[Christopher Obbard]

Hi again,

On Tue, 2024-06-11 at 09:17 +0100, Christopher Obbard wrote:
> Hi Jan,
> 
> On Tue, 2024-06-11 at 07:10 +0200, Jan Kiszka wrote:
> > Chris, you could check if already the vanilla stub fails to run as EFI
> > binary. It should at least print "Unified kernel stub (EFI Boot Guard
> > v0.17)" and "Missing .kernel section" when there is no kernel linked to
> > it. This is to rule out potential problems of the bg_gen_unified_kernel
> > script.
> 
> Launching the kernel stub binary directly in qemu (v8.2.4) using the command
> in my original message, the stub seems to attempt to print something to the
> EFI console, but it ends up showing as many characters of whitespace and
> simply quitting after 5s.
> 
> I guess this shows the bg_gen_unified_kernel script is OK and the issue
> falls
> in the stub?
> 
> For the record, the efibootguard binary itself seems to work just fine.

I also built efibootguard v0.13 (e.g the version which works in bookworm) in
my local debian unstable environment. The built kernel stub fails in the same
way I reported.

So I believe this narrows things down to the cross-compiler, some library or
something else in the environment.


Thanks!

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

[Leith Bade]

What should I do with issues related to the Linux upstream device tree
files?

I noticed a few problems but I am not sure what normal protocol is - should
I report it as a bug to Linux directly?

For the record the issues I noticed are (comparing with U-boot and OpenWRTs
versions of the device tree files):
- mt7986a.dtsi is missing entry for the SNFI / SNAND interface to load
https://github.com/torvalds/linux/blob/83a7eefedc9b56fe7bfeff13b6c7356688ffa670/drivers/spi/spi-mtk-snfi.c
  this is not populated on the BPI-R3 but other boards might use this
- in OpenWRT device tree there are a lot more entries in the efuse map
related to the USB and PCIe ports - it seems the USB and PCIe device
entries then use these efuse values
- no hnat device - though maybe this is only usable with the proprietary
Mediatek driver code
- in OpenWRT device tree there is a different "compatible" string for spi0
(quad) and spi1 (single) - I am not sure if that matters with the upstream
driver, hopefully there is a way to check that the MTD device is using the
quad SPI / SPIM mode
- the BPI-R3 .dtso overlay files for the NAND and NOR flash options have
partition definitions that don't match the device tree in U-boot and
OpenWRT - ideally these should match the partitions on a factory fresh
board which comes OpenWRT preloaded

Additionally I managed to get Ubuntu 24.04 installed for testing and I will
recompile the kernel to add Ethernet device support. This will provide me
with a useful reference to test against a Debian install to make sure all
devices are showing up.

Thanks,
Leith Bade
le...@bade.nz


On Tue, 11 Jun 2024 at 17:01, Diederik de Haas 
wrote:

> Hi,
>
> On Tuesday, 11 June 2024 08:02:41 CEST Leith Bade wrote:
> > I have a Bananapi BPI-R3 board which uses the Mediatek MT7986 ARM64 SoC
> for
> > its CPU. This is a router focussed board and currently has good support
> in
> > the OpenWRT distribution and in the upstream Linux for a few years. The
> > device tree for this board is
> >
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/m
> > t7986a-bananapi- bpi-r3.dts (as well as some .dtso files to enable
> specific
> > flash chip options).
>
> I already have a local branch to add preliminary support for the OpenWrt
> One
> router [1] [2] which uses the same SoC :-)
>
> [1]
> https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684
> [2]
> https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684/331
>
> > There is a relevant discussion in https://salsa.debian.org/kernel-
> > team/linux/-/merge_requests/906#note_483427 which was the code change
> that
> > added the MT8xxx support about the various MT6xxx and MT7xxx modules
> being
> > disabled. This is a shame as it seems that without explicitly disabling
> them
> > then this code change would have added the modules I need.
> >
> > I am happy to do any testing required to get this board supported.
>
> And that was precisely about adding support for the OpenWrt One ;-)
>
> Happy to update my local branch and add support for the BPi R-3.
> I'm waiting for some (unrelated) other changes, but when that's posted
> I intend to build a 6.10-rcX based kernel with it and I can 'merge' my
> router branch into that. With that you could verify if it indeed works.
>
> HTH,
>   Diederik

Bug#1072986: test empty-sources.list fails because it overwrites sources.list

[Johannes Schauer Marin Rodrigues]

Source: mmdebstrap
Version: 1.5.1-2
Severity: normal

Hi,

the test empty-sources.list, as part of the test, overwrites
/etc/apt/sources.list in a setup-hook, thus removing the setup done by
debian/tests/sourcesfilter which runs before. This effect can be seen in
autopkgtest results with this diff:

5194s + diff -u tar1.txt -
5194s --- tar1.txt  2024-06-11 07:56:55.297824379 +
5194s +++ - 2024-06-11 09:05:51.096355647 +
5194s @@ -2353,8 +2353,6 @@
5194s  ./usr/share/info/diffutils.info.gz
5194s  ./usr/share/info/dir
5194s  ./usr/share/info/find-maint.info.gz
5194s -./usr/share/info/find.info-1.gz
5194s -./usr/share/info/find.info-2.gz
5194s  ./usr/share/info/find.info.gz
5194s  ./usr/share/info/grep.info.gz
5194s  ./usr/share/info/gzip.info.gz
5194s @@ -2815,6 +2813,7 @@
5194s  ./usr/share/locale/ka/LC_MESSAGES/Linux-PAM.mo
5194s  ./usr/share/locale/ka/LC_MESSAGES/coreutils.mo
5194s  ./usr/share/locale/ka/LC_MESSAGES/diffutils.mo
5194s +./usr/share/locale/ka/LC_MESSAGES/findutils.mo
5194s  ./usr/share/locale/ka/LC_MESSAGES/gnutls30.mo
5194s  ./usr/share/locale/ka/LC_MESSAGES/grep.mo
5194s  ./usr/share/locale/ka/LC_MESSAGES/libidn2.mo

Which exactly matches the difference between testing and unstable of findutils
right now:

diff -u <(curl --silent 
http://ftp.de.debian.org/debian/pool/main/f/findutils/findutils_4.9.0-6_arm64.deb
 | dpkg-deb --fsys-tarfile - | tar tv | awk '{print $6}' | sort) <(curl 
--silent 
http://ftp.de.debian.org/debian/pool/main/f/findutils/findutils_4.10.0-2_arm64.deb
  | dpkg-deb --fsys-tarfile - | tar tv | awk '{print $6}' | sort)
--- /dev/fd/63  2024-06-11 12:16:24.925627829 +0200
+++ /dev/fd/62  2024-06-11 12:16:24.925627829 +0200
@@ -15,8 +15,6 @@
 ./usr/share/doc/findutils/README.gz
 ./usr/share/doc/findutils/TODO
 ./usr/share/info/
-./usr/share/info/find.info-1.gz
-./usr/share/info/find.info-2.gz
 ./usr/share/info/find.info.gz
 ./usr/share/info/find-maint.info.gz
 ./usr/share/locale/
@@ -77,6 +75,9 @@
 ./usr/share/locale/ja/
 ./usr/share/locale/ja/LC_MESSAGES/
 ./usr/share/locale/ja/LC_MESSAGES/findutils.mo
+./usr/share/locale/ka/
+./usr/share/locale/ka/LC_MESSAGES/
+./usr/share/locale/ka/LC_MESSAGES/findutils.mo
 ./usr/share/locale/ko/
 ./usr/share/locale/ko/LC_MESSAGES/
 ./usr/share/locale/ko/LC_MESSAGES/findutils.mo

Thanks!

cheers, josch

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

[Leith Bade]

Hi Diederik,

Thanks for the update - I noticed you have popped up in a few places
related to the Mediatek SoCs.

That's great to hear things are progressing on the Debian kernel front.

Thanks,
Leith Bade
le...@bade.nz

Bug#1068119: Solution for 1068119 - compile error for s390-tools 2.16.0-2

[Johannes Schauer Marin Rodrigues]

Control: affects -1 + mmdebstrap

Hi,

On Mon, 27 May 2024 12:07:11 +0200 Steffen Eiden  wrote:
> this issue is already fixed upstream since v2.22.0.
> 
> Do one of:
> - apply the upstream fix [1,2]
> - update your package to at least v2.22.0
> 
> 
> The upstream fix disables the warning similar to the kernel[3] (see 
> commit description) as there is no better solution for this as of now.
> 
> I can ensure the code is correct and does no weird things (see lkml).
> There is also a s390-tools upstream discussion regarding this issue.[4]
> 
> 
> Steffen Eiden
> s390-tools upstream-maintainer

based on Steffen's input, I just did a 0-day NMU of s390-tools as this RC bug
is older than 7 days and there was no maintainer activity on the bug for 7 days
and there does not seem to be a packaging VCS where a fix could maybe be found
already.

I also had to cherry-pick another commit from upstream fixing another build
failure with OpenSSL 3.0, namely 8723dbce048add87ce10fe8c72eea75c4f828ef8

This package affects the /usr-move transition because due to this FTBFS, it is
not possible to rebuild s390-tools on unstable with new packages for the 64-bit
time_t transition and that in turn makes apt select the wrong packages in the
mmmdebstrap autopkgtest which we need to succeed to transition util-linux,
bash, dash, glibc and base-files to testing.

The debdiff is attached.

Thanks!

cheers, joschdiff -Nru s390-tools-2.16.0/debian/changelog s390-tools-2.16.0/debian/changelog
--- s390-tools-2.16.0/debian/changelog	2021-08-18 09:26:50.0 +0200
+++ s390-tools-2.16.0/debian/changelog	2024-06-11 11:15:24.0 +0200
@@ -1,3 +1,12 @@
+s390-tools (2.16.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patches from upstream to fix FTBFS (closes: #1068119)
+ - 0001-genprotimg-boot-disable-Warray-bounds-for-now.patch
+ - 0001-genprotimg-add-OpenSSL-3.0-support.patch
+
+ -- Johannes Schauer Marin Rodrigues   Tue, 11 Jun 2024 11:15:24 +0200
+
 s390-tools (2.16.0-2) unstable; urgency=medium
 
   * Add missing build-dependency on libglib2.0-dev. (Closes: #992249)
diff -Nru s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch
--- s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch	1970-01-01 01:00:00.0 +0100
+++ s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch	2024-06-11 11:15:06.0 +0200
@@ -0,0 +1,151 @@
+From 8723dbce048add87ce10fe8c72eea75c4f828ef8 Mon Sep 17 00:00:00 2001
+From: Marc Hartmayer 
+Date: Wed, 23 Jun 2021 13:16:25 +
+Subject: [PATCH] genprotimg: add OpenSSL 3.0 support
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Add OpenSSL 3.0 support while still supporting OpenSSL 1.1.0 and newer. For this
+set the OPENSSL_API_COMPAT user defined macro to OpenSSL 1.1.0 (see
+https://www.openssl.org/docs/manmaster/man7/OPENSSL_API_COMPAT.html) so we don't
+see any deprecation warnings when using OpenSSL 3.0. In addition, add an
+compatibility layer for OpenSSL since some OpenSSL API functions were constified
+with OpenSSL 3.0.
+
+Fixes: https://github.com/ibm-s390-linux/s390-tools/issues/112
+Reviewed-by: Patrick Steuer 
+Signed-off-by: Marc Hartmayer 
+Signed-off-by: Jan Höppner 
+---
+ genprotimg/src/Makefile   |  1 +
+ genprotimg/src/utils/crypto.c | 15 ++--
+ genprotimg/src/utils/openssl_compat.h | 33 +++
+ 4 files changed, 43 insertions(+), 7 deletions(-)
+ create mode 100644 genprotimg/src/utils/openssl_compat.h
+
+diff --git a/genprotimg/src/Makefile b/genprotimg/src/Makefile
+index a71bb1e..0e811d6 100644
+--- a/genprotimg/src/Makefile
 b/genprotimg/src/Makefile
+@@ -29,6 +29,7 @@ $(bin_PROGRAM)_OBJS := $($(bin_PROGRAM)_SRCS:.c=.o)
+ 
+ ALL_CFLAGS += -std=gnu11 -DPKGDATADIR=$(PKGDATADIR) \
+ 	$(GLIB2_CFLAGS) $(LIBCRYPTO_CFLAGS) $(LIBCURL_CFLAGS) \
++	-DOPENSSL_API_COMPAT=0x1010L \
+ 	$(WARNINGS) \
+ 	$(NULL)
+ ALL_CPPFLAGS += $(INCLUDE_PARMS)
+diff --git a/genprotimg/src/utils/crypto.c b/genprotimg/src/utils/crypto.c
+index 2e4750b..087de37 100644
+--- a/genprotimg/src/utils/crypto.c
 b/genprotimg/src/utils/crypto.c
+@@ -31,6 +31,7 @@
+ 
+ #include "buffer.h"
+ #include "curl.h"
++#include "openssl_compat.h"
+ #include "crypto.h"
+ 
+ #define DEFINE_GSLIST_MAP(t2, t1)	\
+@@ -1438,7 +1439,7 @@ static const char *get_first_dp_url(DIST_POINT *dp)
+ 	return NULL;
+ }
+ 
+-static gboolean insert_crl(X509_NAME *name, X509_CRL *crl)
++static gboolean insert_crl(const X509_NAME *name, X509_CRL *crl)
+ {
+ 	g_autofree gchar *key = NULL;
+ 
+@@ -1453,7 +1454,7 @@ static gboolean insert_crl(X509_NAME *name, X509_CRL *crl)
+ }
+ 
+ /* Caller is responsible for free'ing */
+-static X509_CRL *lookup_crl(X509_NAME *name)
++static X509_CRL *lookup_crl(const X509_NAME *name)
+ {
+ 	g_autoptr(X509_CRL) crl = 

Bug#1072933: bfs: ftbfs on riscv64 due to unrecognized opcode `pause', extension `zihintpause' required

[Chris Lamb]

tags 1072933 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lamby/pkg-bfs/commit/7c2928a7ffe71655a016e909caf19862fce737db

  ...PATCH-atomic-Fix-RISC-V-build-with-GCC-14.patch | 58 ++
  debian/patches/series  |  1 +
  2 files changed, 59 insertions(+)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1072183: fenics-dolfinx: FTBFS with nanobind 2.0

[Francesco Ballarin]

Source: fenics-dolfinx
Followup-For: Bug #1072183
X-Debbugs-Cc: francesco.balla...@unicatt.it, roehl...@debian.org, 
dpars...@debian.org

Thanks Timo. I confirm that nanobind, fenics-basix and fenics-dolfinx migrated
yesterday to testing.
Hopefully there won't be future ABI breaks that aren't aligned with a
fenics-basix/fenics-dolfinx release, but if there will be we will look forward
to any suggestion from you on how to come up with a more elegant solution.

Thanks,
Francesco

Bug#1072985: RFS: sdpa/7.3.18-1 -- High-performance package for SemiDefinite Programs

[Makoto Yamashita]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : sdpa
   Version  : 7.3.18-1
   Upstream contact : SDPA developers 
 * URL  : http://sdpa.sourceforge.net/
 * License  : GPL-2+
   Section  : math

The source builds the following binary packages:

  sdpa - High-performance package for SemiDefinite Programs
  libsdpa-dev - Callable library and examples of SDPA
  sdpam - Matlab/Octave interface of SDPA

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/s/sdpa/sdpa_7.3.18-1.dsc

Changes since the last upload:

 sdpa (7.3.18-1) unstable; urgency=low
 .
   * New upstream
 + Change MUMPS from 5.5.1 to 5.6.2 (Closes: 1070447)
   * Update Standards-Version to 4.7.0

Regards,
-- 
  Makoto Yamashita

Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:

[Christoph Berg]

Re: Martin-Éric Racine
> Incorrect delayed argument: ValueError: delayed days value must be a decimal 
> integer:

`dput -e 0` works around that part of the problem. I then ran into
another problem though:

Uploading to ssh-upload [DELAYED/0-day] (via scp to ssh.upload.debian.org):
Traceback (most recent call last):
  File "/usr/bin/dput", line 33, in 
sys.exit(load_entry_point('dput==1.2', 'console_scripts', 'execute-dput')())
 ^^
  File "/usr/share/dput/dput/dput.py", line 1548, in main
upload_files(
  File "/usr/share/dput/dput/dput.py", line 1267, in upload_files
upload_func(
  File "/usr/share/dput/dput/dput.py", line 1152, in upload_files_via_method_scp
line.strip() for line in ssh_config_options.split("\n"))
 
AttributeError: 'list' object has no attribute 'split'

Christoph

Bug#1072984: bookworm-pu: package crowdsec-firewall-bouncer/0.0.25-4~deb12u1

[Cyril Brulebois]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: crowdsec-firewall-boun...@packages.debian.org
Control: affects -1 + src:crowdsec-firewall-bouncer

Hi,

[ Reason ]

I'd like to fix the #1071247/#1071248 pair in bookworm, which results in
crowdsec-firewall-bouncer's being broken on little-endian architectures
(addresses are getting logged just fine, but they're not passed over
correctly to the firewall layer).

I've checked with the security team, this doesn't warrant a DSA.

This is the daemon part (crowdsec-firewall-bouncer).

[ Impact ]

If the fix doesn't make it into stable, crowdsec-firewall-bouncer 
remains broken on little-endian architectures.

[ Tests ]

Same checks as for unstable when I uploaded the fixes there:
 - amd64 (LE, baremetal) before: KO
 - amd64 (LE, baremetal) after: OK
 - s390x (BE, debvm) before: OK
 - s390x (BE, debvm) after: OK

[ Risks ]

Except for a possible regression on s390x (which isn't the case, see
previous section), it cannot be worse than it currently is.

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

Additionally, that reached testing.

[ Changes ]

Since there were already binNMUs for this package in p-u, with different
versions, I decided to err on the side of caution, and to propose a new
revision with a versioned build-dep on golang-github-google-nftables's
binary package; alternatively this package could be binNMU'd within p-u
once golang-github-google-nftables is available in p-u.

[ Other info ]

Previous bug report is the golang-github-google-nftables part.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
diff -Nru crowdsec-firewall-bouncer-0.0.25/debian/changelog 
crowdsec-firewall-bouncer-0.0.25/debian/changelog
--- crowdsec-firewall-bouncer-0.0.25/debian/changelog   2023-05-31 
18:57:41.0 +0200
+++ crowdsec-firewall-bouncer-0.0.25/debian/changelog   2024-06-11 
10:20:58.0 +0200
@@ -1,3 +1,18 @@
+crowdsec-firewall-bouncer (0.0.25-4~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm.
+
+ -- Cyril Brulebois   Tue, 11 Jun 2024 10:20:58 +0200
+
+crowdsec-firewall-bouncer (0.0.25-4) unstable; urgency=high
+
+  * Set minimal version for the golang-github-google-nftables-dev build
+dependency to ensure a working AddSet() function, i.e. no longer
+reversing byte order for IPv4 and IPv6 addresses at the nftables level
+on little-endian architectures (Closes: #1071248, See: #1071247).
+
+ -- Cyril Brulebois   Tue, 21 May 2024 10:15:36 +0200
+
 crowdsec-firewall-bouncer (0.0.25-3) unstable; urgency=medium
 
   * Fix failure to install if crowdsec is unpacked but not configured
diff -Nru crowdsec-firewall-bouncer-0.0.25/debian/control 
crowdsec-firewall-bouncer-0.0.25/debian/control
--- crowdsec-firewall-bouncer-0.0.25/debian/control 2023-03-21 
01:03:29.0 +0100
+++ crowdsec-firewall-bouncer-0.0.25/debian/control 2024-05-21 
09:53:53.0 +0200
@@ -10,7 +10,7 @@
golang-github-coreos-go-systemd-dev,
golang-github-crowdsecurity-crowdsec-dev,
golang-github-crowdsecurity-go-cs-bouncer-dev,
-   golang-github-google-nftables-dev,
+   golang-github-google-nftables-dev (>= 0.1.0-4~),
golang-golang-x-sys-dev,
golang-gopkg-natefinch-lumberjack.v2-dev,
golang-gopkg-tomb.v2-dev,

Bug#1072983: bookworm-pu: package golang-github-google-nftables/0.1.0-4~deb12u1

[Cyril Brulebois]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: golang-github-google-nftab...@packages.debian.org
Control: affects -1 + src:golang-github-google-nftables

Hi,

[ Reason ]

I'd like to fix the #1071247/#1071248 pair in bookworm, which results in
crowdsec-firewall-bouncer's being broken on little-endian architectures
(addresses are getting logged just fine, but they're not passed over
correctly to the firewall layer). 

I've checked with the security team, this doesn't warrant a DSA.

This is the library part (golang-github-google-nftables).

[ Impact ]

If the fix doesn't make it into stable, crowdsec-firewall-bouncer
remains broken on little-endian architectures.

[ Tests ]

Same checks as for unstable when I uploaded the fixes there:
 - amd64 (LE, baremetal) before: KO
 - amd64 (LE, baremetal) after: OK
 - s390x (BE, debvm) before: OK
 - s390x (BE, debvm) after: OK

[ Risks ]

Except for a possible regression on s390x (which isn't the case, see
previous section), it cannot be worse than it currently is.

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

Additionally, that reached testing.

[ Changes ]

The fix is a direct backport from upstream, which adds byte order
information to the function used by crowdsec-firewall-bouncer
(AddSet).

[ Other info ]

Next bug report is the crowdsec-firewall-bouncer part.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
diff -Nru golang-github-google-nftables-0.1.0/debian/changelog 
golang-github-google-nftables-0.1.0/debian/changelog
--- golang-github-google-nftables-0.1.0/debian/changelog2022-12-12 
05:07:14.0 +0100
+++ golang-github-google-nftables-0.1.0/debian/changelog2024-06-11 
10:22:28.0 +0200
@@ -1,3 +1,18 @@
+golang-github-google-nftables (0.1.0-4~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm.
+
+ -- Cyril Brulebois   Tue, 11 Jun 2024 10:22:28 +0200
+
+golang-github-google-nftables (0.1.0-4) unstable; urgency=high
+
+  * Backport upstream fix for the AddSet() function that's been reversing
+byte order on all little-endian architectures (Closes: #1071247),
+breaking crowdsec-firewall-bouncer (See: #1071248):
+ - 0002-Implement-set-KeyByteOrder-226.patch
+
+ -- Cyril Brulebois   Tue, 21 May 2024 09:42:17 +0200
+
 golang-github-google-nftables (0.1.0-3) unstable; urgency=medium
 
   * Backport fix from upstream to fix the test suite on 32-bit archs (the
diff -Nru 
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
 
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
--- 
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
1970-01-01 01:00:00.0 +0100
+++ 
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
2024-05-15 13:08:54.0 +0200
@@ -0,0 +1,42 @@
+From d746ecb0e494e7200180c3886fde9664d9100729 Mon Sep 17 00:00:00 2001
+From: turekt <32360115+tur...@users.noreply.github.com>
+Date: Thu, 18 May 2023 18:05:49 +0200
+Subject: [PATCH] Implement set KeyByteOrder (#226)
+
+Fixes https://github.com/google/nftables/issues/225
+Introduced KeyByteOrder in sets which fills UDATA with endianess information
+---
+ set.go | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/set.go b/set.go
+index 1ef8e89..b1f63e8 100644
+--- a/set.go
 b/set.go
+@@ -261,6 +261,9 @@ type Set struct {
+   Timeout   time.Duration
+   KeyType   SetDatatype
+   DataType  SetDatatype
++  // Either host (binaryutil.NativeEndian) or big (binaryutil.BigEndian) 
endian as per
++  // 
https://git.netfilter.org/nftables/tree/include/datatype.h?id=d486c9e626405e829221b82d738005b26d8a#n109
++  KeyByteOrder binaryutil.ByteOrder
+ }
+ 
+ // SetElement represents a data point within a set.
+@@ -560,11 +563,11 @@ func (cc *Conn) AddSet(s *Set, vals []SetElement) error {
+   // Marshal concat size description as set description
+   tableInfo = append(tableInfo, netlink.Attribute{Type: 
unix.NLA_F_NESTED | unix.NFTA_SET_DESC, Data: concatBytes})
+   }
+-  if s.Anonymous || s.Constant || s.Interval {
++  if s.Anonymous || s.Constant || s.Interval || s.KeyByteOrder == 
binaryutil.BigEndian {
+   tableInfo = append(tableInfo,
+   // Semantically useless - kept for binary compatability 
with nft
+   netlink.Attribute{Type: unix.NFTA_SET_USERDATA, Data: 
[]byte("\x00\x04\x02\x00\x00\x00")})
+-  } else if !s.IsMap {
++  } else if s.KeyByteOrder == binaryutil.NativeEndian {
+   // Per 

Bug#1072982: lime - build-depends on package that is not in testing.

[Peter Green]

Package: lime
Version: 5.2.0+dfsg-3
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable

lime build-depends on boost1.74, which is no longer in testing. It seems that
lime was removed from testing at the same time as boost1.74, but for some
reason it then re-migrated.

Please update your package to use the current version of boost.

Bug#1072831: getting memory info fails when running under lxc

[Paul Slootman]

tags 1072831 patch
thanks

On Tue 11 Jun 2024, Craig Small wrote:

> Could you check to see if in the container that lxcfs has overwritten
> the /proc/meminfo file? They sometimes do this for /proc/uptime. They
> might have messed one of the lines up and choked procps; I'm thinking
> like a tab/space at the end of the line or something that looks right
> to a human but not a computer.

The /proc/meminfo in the lxc container is basically the same as that of
the host, except the total memory reflects the limit imposed on the
container. So

-MemTotal:7914164 kB$
+MemTotal:2097152 kB$

and the Slab / SReclaimable / SUnreclaim lines show 0 kB.

> I think we'll need to either run a strace on free or a debugger to see
> where exactly the issue is.

I've been doing this.
Apparently the /proc/meminfo inside the lxc container is not seekable,
errno is ESPIPE.
The code does some seeks to reset to the beginning in preparation for
rereading the file.

I've changed the code to not do an lseek() just after opening the file
(as we should be at the start of the file then anyway), and if the file
is already open, try lseek() and if that returns errno == ESPIPE, then
close and reopen the file.

This works for me. Patch attached.

I don't know whether configure needs to test for existence of ESPIPE;
I do believe it's POSIX.


Paul
--- library/meminfo.c.orig	2023-07-11 11:09:18.436786212 +0200
+++ library/meminfo.c	2024-06-11 10:41:41.643438234 +0200
@@ -646,12 +646,18 @@
 // clear out the soon to be 'current' values
 memset(>hist.new, 0, sizeof(struct meminfo_data));
 
-if (-1 == info->meminfo_fd
-&& (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY
-return 1;
-
-if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
-return 1;
+if (-1 == info->meminfo_fd) {
+	if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+	return 1;
+}
+else {
+	if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
+	if (ESPIPE == errno) {
+		close(info->meminfo_fd);
+		if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+		return 1;
+	}
+}
 
 for (;;) {
 if ((size = read(info->meminfo_fd, buf, sizeof(buf)-1)) < 0) {

Bug#1072979: beast-mcmc - build-dependencies unsatisfiable on i386.

[Peter Green]

Package: beast-mcmc
Version: 1.10.4+dfsg-5
Severity: serious
x-debbugs-cc: r-cran-rj...@packages.debian.org

beast-mcmc build-depends on r-cran-rjava, which is no longer available
on i386. It appears that the package failed to build, and the old
binaries were then removed.

Bug#1072981: tinyows: FTBFS in sid: error: implicit declaration of function 'atoi'

[Andreas Beckmann]

Source: tinyows
Version: 1.2.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

tinyows FTBFS in a minimal sid pbuilder chroot:

   dh_auto_build
make -j3
make[1]: Entering directory '/build/tinyows-1.2.1'
gcc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/build/tinyows-1.2.1=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wl,-z,relro -Wl,-z,now -Wdate-time -D_FORTIFY_SOURCE=2 -std=c99 -pedantic 
-Wall -I/usr/include/postgresql -I/usr/include/libxml2   
src/fe/fe_comparison_ops.c src/fe/fe_error.c src/fe/fe_filter.c 
src/fe/fe_filter_capabilities.c src/fe/fe_function.c src/fe/fe_logical_ops.c 
src/fe/fe_spatial_ops.c src/mapfile/mapfile.c src/ows/ows_bbox.c src/ows/ows.c 
src/ows/ows_config.c src/ows/ows_error.c src/ows/ows_geobbox.c 
src/ows/ows_get_capabilities.c src/ows/ows_layer.c src/ows/ows_metadata.c 
src/ows/ows_psql.c src/ows/ows_request.c src/ows/ows_srs.c 
src/ows/ows_storage.c src/ows/ows_version.c src/struct/alist.c 
src/struct/array.c src/struct/buffer.c src/struct/cgi_request.c 
src/struct/list.c src/struct/mlist.c src/struct/regexp.c src/wfs/wfs_describe.c 
src/wfs/wfs_error.c src/wfs/wfs_get_capabilities.c src/wfs/wfs_get_feature.c 
src/wfs/wfs_request.c src/wfs/wfs_transaction.c src/ows/ows_libxml.c -o tinyows 
-lfl -L/usr/lib/x86_64-linux-gnu -lpq -lxml2 -lfcgi
src/ows/ows_config.c: In function 'ows_parse_config_tinyows':
src/ows/ows_config.c:64:17: error: implicit declaration of function 'atoi'; did 
you mean 'atooid'? [-Werror=implicit-function-declaration]
   64 | log_level = atoi((char *) a);
  | ^~~~
  | atooid
cc1: some warnings being treated as errors
src/ows/ows_request.c: In function 'ows_generate_schema':
src/ows/ows_request.c:143:5: warning: 'xmlSchemaCleanupTypes' is deprecated 
[-Wdeprecated-declarations]
  143 | xmlSchemaCleanupTypes();
  | ^
In file included from src/ows/ows_request.c:30:
/usr/include/libxml2/libxml/xmlschemastypes.h:37:17: note: declared here
   37 | xmlSchemaCleanupTypes   (void);
  | ^
make[1]: *** [Makefile:28: all] Error 1
make[1]: Leaving directory '/build/tinyows-1.2.1'


Andreas


tinyows_1.2.1-1.log.gz
Description: application/gzip

Bug#1072917: Cannot generate a certificate request for a RSA-PSS key

[Luca Boccassi]

Control: tags -1 upstream
Control: close -1

On Mon, 10 Jun 2024 11:04:50 +0100 Anton Ivanov
 wrote:
> Package: tpm2-openssl
> Version: 1.1.1-1
> Severity: important
> 
> In order to use tpm to store TLS keys, the key type must be usable
for TLS. If,
> the ecc algo family cannot be used, this has to be RSA-PSS. RSA-PSS
keys can be
> created with tpm2-tools and appear to function correctly outside
openssl. Trying
> to generate an openssl cert request with invalid padding.
> 
> How to reproduce:
> 
> tpm2_createek -G rsa -c ek_pss.ctx
> tpm2_createak -C ek_pss.ctx -G rsa -g sha256 -s pss -c ak_ecc.ctx
> tpm2_evictcontrol -c ak_ecc.ctx 0x8101
> OPENSSL_CONF=./openssl.cnf openssl req -provider tpm2 -provider
default \
> -propquery '?provider=tpm2' -key handle:0x8101 -out
testcsr.pem -new
> 
> The resulting csr has invalid padding (200+ bytes instead of 32) and
is rejected
> if passed to a CA

There are no patches in Debian, please test this again in
unstable/testing, and if it is still a problem report this upstream:

https://github.com/tpm2-software/tpm2-openssl/issues

-- 
Kind regards,
Luca Boccassi


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

Bug#1072980: guestfs-tools - build-depends unsatisfiable on armel

[Peter Green]

Package: guestfs-tools
Version: 1.52.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: edos-uninstallable

guestfs-tools on armel build-depends on linux-image-marvell:armel | 
linux-image-versatile:armel
neither of which is available anymore.

It looks like the only kernel now available on armel is linux-image-rpi, I do 
not know
if this is suitable for your purposes.

Bug#1072769: libvirt-daemon: Cannot connect to hypervisor with user session after upgrade

[Simon John]

Actually adding /usr/sbin to $PATH doesn't fix this in all cases.

If you run virt-manager from Gnome on Wayland for instance, it doesn't 
connect.


You have to run it from the console or run virsh first to get it to use 
your new $PATH


I guess you could also set it in ~/.config/environment.d/*.conf instead 
of just ~/.bashrc but that's really getting ugly, seems this needs a 
proper fix not a workaround.


--
Simon John

Bug#1072978: rdate: please implement ifup script

[Martin-Éric Racine]

Package: rdate
Version: 1:1.11-3
Severity: normal

The Hurd port still depends on the deprecated reference 'ntpdate' to sync 
clocks at bootup. That reference NTP implementation was replaced by ntpsec in 
Debian a long time ago.

The only NTP client that still builds for Hurd is rdate. What is missing is an 
ifup script to issue the following command whenever the network is up:

rdate -n debian.pool.ntp.org

You may want to use an /etc/default/rdate to source the command options and the 
server.

You may check 

 for ideas on how to implement this.

Once rdate has implemented such an ifup script, the Hurd port will finally be 
able to retire its obsolete fork of ntpdate.

Thanks!
Martin-Éric

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hurd-i386 (i686-AT386)

Kernel: GNU-Mach 1.8+git20240406-up-486/Hurd-0.9
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages rdate depends on:
ii  libbsd0  0.12.2-1
ii  libc0.3  2.38-13

rdate recommends no packages.

rdate suggests no packages.

-- no debconf information

Bug#1072977: apt-listbugs 0.1.42 is broken

[Karine Crèvecœur]

Package: apt-listbugs
Version: 0.1.42
Severity: grave


Hi,

Since the upgrade to version 0.1.42, apt-listbugs doesn't work anymore.

As examplen the command
apt-listbugs list apt-lisbugs
gave the error:

Retrieving bug reports... 0% Fail
Error retrieving bug reports from the server with the following error message:
E: SSL_connect returned=1 errno=0 
peeraddr=[2605:bc80:3010:b00:0:deb:166:212]:443 state=error: certificate verify 
failed (unable to get local issuer certificate)
It could be because your network is down, or because of broken proxy servers, 
or the BTS server itself is down. Check network configuration and try again


I downgrade apt-listbugs to the version 0.1.41-nmu1, it works just fine.

System: debian/sid

apt-listbugs depends on:

apt (2.9.4)
ruby (any, installed version 1:3.1+nmu1)
ruby-debian (0.3.10+b10)
ruby-gettex (3.3.3-2)
ruby-soap4r (2.0.5-6)
ruby-unicode (0.4.4.4-1+b6)
ruby-xmlparser (0.7.3-4+b5)

recommends:
ruby-httpclient (2.8.3+git20211122.4658227-1)

I don't figure out why this issue occurs.

Cheers.

--
Karine Crévecœur

Bug#1072962: efibootguard kernel stub fails to boot

[Gylstorff Quirin]

Hi,

i build it isar-cip-core on bookworm as build enviroment
and efibootguard boots. will test it on trixie.

Best regards
Quirin

On 6/11/24 10:17 AM, Christopher Obbard wrote:

Hi Jan,

On Tue, 2024-06-11 at 07:10 +0200, Jan Kiszka wrote:

Chris, you could check if already the vanilla stub fails to run as EFI
binary. It should at least print "Unified kernel stub (EFI Boot Guard
v0.17)" and "Missing .kernel section" when there is no kernel linked to
it. This is to rule out potential problems of the bg_gen_unified_kernel
script.


Launching the kernel stub binary directly in qemu (v8.2.4) using the command
in my original message, the stub seems to attempt to print something to the
EFI console, but it ends up showing as many characters of whitespace and
simply quitting after 5s.

I guess this shows the bg_gen_unified_kernel script is OK and the issue falls
in the stub?

For the record, the efibootguard binary itself seems to work just fine.





Thanks

Chris

Bug#1072962: efibootguard kernel stub fails to boot

[Christopher Obbard]

Hi Jan,

On Tue, 2024-06-11 at 07:10 +0200, Jan Kiszka wrote:
> Chris, you could check if already the vanilla stub fails to run as EFI
> binary. It should at least print "Unified kernel stub (EFI Boot Guard
> v0.17)" and "Missing .kernel section" when there is no kernel linked to
> it. This is to rule out potential problems of the bg_gen_unified_kernel
> script.

Launching the kernel stub binary directly in qemu (v8.2.4) using the command
in my original message, the stub seems to attempt to print something to the
EFI console, but it ends up showing as many characters of whitespace and
simply quitting after 5s.

I guess this shows the bg_gen_unified_kernel script is OK and the issue falls
in the stub?

For the record, the efibootguard binary itself seems to work just fine.


Thanks

Chris

Bug#1070411: containerd fails to build as a normal user due to sysctl

[Sebastian Ramacher]

Hi

On 2024-06-11 10:18:14 +0200, Jochen Sprickerhof wrote:
> Hi Reinhard,
> 
> * Reinhard Tartler  [2024-06-10 22:26]:
> > Are you sure that the test is actually executing a sysctl(2) command?
> > Looking at the code, it seems to me that this is code is assembling a
> > runtime spec that the CRI implementation will then carry out.
> > Forthermore, the output above indicates that the assertion on line 123
> > actually holds, but the one on line 124 does not:
> > 
> > https://sources.debian.org/src/containerd/1.6.24~ds1-1/pkg/cri/server/sandbox_run_linux_test.go/#L124
> > 
> > The cause for this is most likely in 
> > https://sources.debian.org/src/containerd/1.6.24~ds1-1/pkg/cri/server/sandbox_run_linux.go/#L147.
> >  Here the code is explicitly checking whether it is running in in a 
> > usernamespace, which is exactly what 'unshare' is doing.
> 
> That makes more sense, thanks for looking into it.
> 
> > Can you please help me understand whether, and if so since when, we have
> > the requirement that all packages must be buildable inside a
> > usernamespace and where was this announced to be release-critical?
> > (CC'ed debian-release for input).
> 
> Afaik the buildd team started deploying The sbuild unshare setup in April:
> 
> https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/commit/6a050f889
> 
> So unrelated to the severity discussion you may want to look into fixing
> this bug so that the package continues to build.

This change makes those bugs automatically RC:

Packages must autobuild without failure on all architectures on
which they are supported.

(from https://release.debian.org/testing/rc_policy.txt, 4. Autobuilding)

Cheers
-- 
Sebastian Ramacher

Bug#1072976: 'cmdline-tools: command not found > after running sdkmanager --install "cmdline-tools;latest"'

[Ahmed Hassan Younes Hassan]

Package: sdkmanager
Version: 0.6.7-1
Severity: important
X-Debbugs-Cc: ahmedsat...@gmail.com

Dear Maintainer,

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

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

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


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

Kernel: Linux 6.8.12-amd64 (SMP w/8 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 sdkmanager depends on:
ii  python3   3.11.8-1
ii  python3-requests  2.31.0+dfsg-2
ii  python3-urllib3   1.26.18-2

Versions of packages sdkmanager recommends:
ii  python3-argcomplete  3.3.0-1

sdkmanager suggests no packages.

-- no debconf information

Bug#1070411: containerd fails to build as a normal user due to sysctl

[Jochen Sprickerhof]

Hi Reinhard,

* Reinhard Tartler  [2024-06-10 22:26]:

Are you sure that the test is actually executing a sysctl(2) command?
Looking at the code, it seems to me that this is code is assembling a
runtime spec that the CRI implementation will then carry out.
Forthermore, the output above indicates that the assertion on line 123
actually holds, but the one on line 124 does not:

https://sources.debian.org/src/containerd/1.6.24~ds1-1/pkg/cri/server/sandbox_run_linux_test.go/#L124

The cause for this is most likely in 
https://sources.debian.org/src/containerd/1.6.24~ds1-1/pkg/cri/server/sandbox_run_linux.go/#L147.
 Here the code is explicitly checking whether it is running in in a 
usernamespace, which is exactly what 'unshare' is doing.


That makes more sense, thanks for looking into it.


Can you please help me understand whether, and if so since when, we have
the requirement that all packages must be buildable inside a
usernamespace and where was this announced to be release-critical?
(CC'ed debian-release for input).


Afaik the buildd team started deploying The sbuild unshare setup in 
April:


https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/commit/6a050f889

So unrelated to the severity discussion you may want to look into fixing 
this bug so that the package continues to build.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1072975: ITP: edlin -- Standard line editor

[Gürkan Myczko]

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

* Package name: edlin
  Version : 2.17
  Upstream Authors: Gregory Pietsch
  URL : https://github.com/FDOS/edlin
* License : GPL-2+
  Description : Standard line editor
 This is a small line editor, written for FreeDOS as a functional
 clone of the old MS-DOS program edlin. It differs from MS edlin in that
 first, it's free software, and second, the user interface is slightly
 different in a few places. The reason for the difference is so that the 
user
 does not have to type in control characters mandated by MS edlin's 
syntax.

Bug#1072974: ITP: kilo -- Small text editor

[Gürkan Myczko]

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

* Package name: kilo
  Version : 0.0.1
  Upstream Authors: Salvatore Sanfilippo
  URL : https://github.com/antirez/kilo
* License : BSD-2
  Description : Small text editor
 This is a text editor in less than 1000 LOC with syntax highlighting
 and search.

Bug#1072687: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian

[Marco Moock]

Am 11.06.2024 um 09:21:55 Uhr schrieb pham...@bluewin.ch:

> Tell me exactly which log you need to solve this problem ?

Please enable trace logging in NetworkManager.
The dmesg doesn't show anything unusual at the first view.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/introduction-to-networkmanager-debugging_configuring-and-managing-networking#temporarily-setting-log-levels-at-run-time-using-nmcli_introduction-to-networkmanager-debugging

nmcli general logging level TRACE domains ALL

Then use 
journalctl -u NetworkManager -b


-- 
Gruß
Marco

Send unsolicited bulk mail to 1718090515mu...@cartoonies.org