Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile

[Xiyue Deng]

Xiyue Deng  writes:

> Hi Sean,
>
> Thanks for the review!  I initially thought d/changelog should mainly be
> about user-facing changes.  But looks like it's better to be thorough.
> Please see replies inline below.
>
> Sean Whitton  writes:
>
>> control: tag -1 + moreinfo
>> control: owner -1 !
>>
>> Hello Xiyue,
>>
>> Thank you for working on this.
>> A review of 2ea5e050fe78c7a382a613bc60ce5f14da4f130a:
>>
>> I'm wondering why you've updated git watch to check for the git HEAD,
>> since upstream seems to now be tagging releases?
>>
>
> I could have mixed the impression with other repos that don't have it.
> Now tracking tags and slightly modernize it using "@ANY_VERSION@".
>
>> The changelog should mention the switch d/compat -> debhelper-compat.
>>
>
> Done.
>
>> The typo fix in d/control should be mentioned in d/changelog.
>>
>
> Done.
>
>> You should say that it's --parallel that you dropped from d/rules.
>>
>
> Done.
>
>> Your justification for dropping the Built-Using should not be that
>> Lintian suggested dropping it.  Please determine the real reason :)
>
> I thought mentioning dropping Built-Using from arch:all package could be
> an acceptable reason, which in turn also follows Lintian's suggestion :)
> But do let me know if I should further clarify.
>
> New updates pushed to team repo and reuploaded to mentors.  PTAL.  TIA!

Friendly ping :)

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#1054411: libopenni2-0: move udev rules to /usr

[Helmut Grohne]

Control: tags -1 - moreinfo

On Mon, Oct 23, 2023 at 04:04:50PM +0200, Helmut Grohne wrote:
> So I think this is how it works best, but maybe this is not the final
> solution and hence I'm tagging it moreinfo. What do you think?

Chris Hofstaedler kindly reviewed this patch we have since applied the
very same approach to quite some packages in unstable without having run
into problems just yet. I am hence updating a new patch. Changes:
 * In postinst check for the reference count. This missing check may
   render the mitigation ineffective in some cases. Thanks Chris.
 * Add lintian-brush markup for getting rid of this again.
 * Remove the version check. In case someone backports this anyway, the
   version check would break the mitigation.

Helmut
diff -Nru openni2-2.2.0.33+dfsg/debian/changelog 
openni2-2.2.0.33+dfsg/debian/changelog
--- openni2-2.2.0.33+dfsg/debian/changelog  2021-02-05 20:15:35.0 
+0100
+++ openni2-2.2.0.33+dfsg/debian/changelog  2023-10-23 14:41:21.0 
+0200
@@ -1,3 +1,9 @@
+openni2 (2.2.0.33+dfsg-16) UNRELEASED; urgency=medium
+
+  * Move files to /usr. (Closes: #1054411)
+
+ -- Helmut Grohne   Mon, 23 Oct 2023 14:41:21 +0200
+
 openni2 (2.2.0.33+dfsg-15) unstable; urgency=medium
 
   * Add patch for Java 17 (Closes: #982019)
diff -Nru openni2-2.2.0.33+dfsg/debian/control 
openni2-2.2.0.33+dfsg/debian/control
--- openni2-2.2.0.33+dfsg/debian/control2020-12-03 19:21:15.0 
+0100
+++ openni2-2.2.0.33+dfsg/debian/control2023-10-23 14:41:21.0 
+0200
@@ -7,7 +7,7 @@
 Build-Depends: debhelper-compat (= 13),
freeglut3-dev,
libusb-1.0-0-dev,
-   python3,
+   python3:any,
doxygen,
graphviz,
libjpeg-dev,
diff -Nru openni2-2.2.0.33+dfsg/debian/libopenni2-0.lintian-overrides 
openni2-2.2.0.33+dfsg/debian/libopenni2-0.lintian-overrides
--- openni2-2.2.0.33+dfsg/debian/libopenni2-0.lintian-overrides 1970-01-01 
01:00:00.0 +0100
+++ openni2-2.2.0.33+dfsg/debian/libopenni2-0.lintian-overrides 2023-10-23 
14:41:21.0 +0200
@@ -0,0 +1,4 @@
+# begin-remove-after: released:forky
+# DEP17P7 mitigation
+diversion-for-unknown-file lib/udev/rules.d/60-libopenni2-0.rules [*]
+# end-remove-after
diff -Nru openni2-2.2.0.33+dfsg/debian/libopenni2-0.postinst 
openni2-2.2.0.33+dfsg/debian/libopenni2-0.postinst
--- openni2-2.2.0.33+dfsg/debian/libopenni2-0.postinst  1970-01-01 
01:00:00.0 +0100
+++ openni2-2.2.0.33+dfsg/debian/libopenni2-0.postinst  2023-10-23 
14:41:21.0 +0200
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:forky
+if test "$1" = configure && test "$DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT" = "1" && 
test -n "$(dpkg-divert --list /lib/udev/rules.d/60-libopenni2-0.rules)"; then
+   rm -f /lib/udev/rules.d/60-libopenni2-0.rules.usr-is-merged
+   dpkg-divert --no-rename --package usr-is-merged --remove 
/lib/udev/rules.d/60-libopenni2-0.rules
+fi
+# end-remove-after
+
+#DEBHELPER#
diff -Nru openni2-2.2.0.33+dfsg/debian/libopenni2-0.postrm 
openni2-2.2.0.33+dfsg/debian/libopenni2-0.postrm
--- openni2-2.2.0.33+dfsg/debian/libopenni2-0.postrm1970-01-01 
01:00:00.0 +0100
+++ openni2-2.2.0.33+dfsg/debian/libopenni2-0.postrm2023-10-23 
14:41:21.0 +0200
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:forky
+if test "$1" = abort-upgrade -o "$1" = upgrade-failed -o "$1" = remove && test 
-n "$(dpkg-divert --list /lib/udev/rules.d/60-libopenni2-0.rules)"; then
+   rm -f /lib/udev/rules.d/60-libopenni2-0.rules.usr-is-merged
+   dpkg-divert --no-rename --package usr-is-merged --remove 
/lib/udev/rules.d/60-libopenni2-0.rules
+fi
+# end-remove-after
+
+#DEBHELPER#
diff -Nru openni2-2.2.0.33+dfsg/debian/libopenni2-0.preinst 
openni2-2.2.0.33+dfsg/debian/libopenni2-0.preinst
--- openni2-2.2.0.33+dfsg/debian/libopenni2-0.preinst   1970-01-01 
01:00:00.0 +0100
+++ openni2-2.2.0.33+dfsg/debian/libopenni2-0.preinst   2023-10-23 
14:41:21.0 +0200
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:forky
+if test "$1" = upgrade; then
+   dpkg-divert --no-rename --package usr-is-merged --divert 
/lib/udev/rules.d/60-libopenni2-0.rules.usr-is-merged --add 
/lib/udev/rules.d/60-libopenni2-0.rules
+fi
+# end-remove-after
+
+#DEBHELPER#
diff -Nru openni2-2.2.0.33+dfsg/debian/rules openni2-2.2.0.33+dfsg/debian/rules
--- openni2-2.2.0.33+dfsg/debian/rules  2020-12-03 19:11:13.0 +0100
+++ openni2-2.2.0.33+dfsg/debian/rules  2023-10-23 14:41:21.0 +0200
@@ -8,5 +8,8 @@
cd Source/Documentation && python3 ./Runme.py
cd Bin/*-Release/ && mv NiViewer NiViewer2
 
+execute_after_dh_installudev:
+   set -e; if test -d debian/libopenni2-0/lib/udev/rules.d; then mv 
debian/libopenni2-0/lib/udev debian/libopenni2-0/usr/lib; fi
+
 override_dh_shlibdeps:
dh_shlibdeps -- --ignore-missing-info

Bug#1053700: xarray test failure on s390x

[Rebecca N. Palmer]

I retried the arm64 test and it passed, so it's probably just a random 
hang (I've seen those before in pytest).  Hence, I now _do_ suggest 
uploading current Salsa.

Bug#1056782: findutils: VCS repo breaks dpkg-source/gbp-buildpackage

[Gioele Barabucci]

Package: src:findutils
Tags: patch

Dear findutils maintainers,

the VCS repo at https://salsa.debian.org/debian/findutils/ contains two 
issues that make it incompatible as-is with dpkg-souce and with 
gbp-buildpackage (used, among others, by Salsa-CI), making it impossible 
to buuild without manual (undocumented) interventions:


1. dpkg-source blindly copies the top-level README.md file and the 
detects it as a local change, aborting the build process


2. The fact that this a non-standard, non-DEP-14 repository is not 
documented in gbp.conf.


These issues are fixed by the following MR:

https://salsa.debian.org/debian/findutils/-/merge_requests/1

Regards,

--
Gioele Barabucci

Bug#1056781: cython3-legacy has an undeclared file conflict

[Helmut Grohne]

Package: cython3-legacy
Version: 0.29.36-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + cython3-dbg

cython3-legacy has an undeclared file conflict. This may result in an
unpack error from dpkg.

The files
 * 
/usr/lib/python3/dist-packages/Cython/Compiler/FlowControl.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Compiler/FusedNode.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Compiler/Scanning.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Compiler/Visitor.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Plex/Actions.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Plex/Scanners.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Runtime/refnanny.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Tempita/_tempita.cpython-311d-x86_64-linux-gnu.so
are contained in the packages
 * cython3-dbg
   * 0.29.32-2+b1 as present in bookworm
   * 0.29.36-1 as present in trixie
 * cython3-legacy/0.29.36-1~exp1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)

[Aaron Rainbolt]

Uh... ok so apparently either Gmail or the Debian BTS ate my patch, so 
here's a second attempt, this time as a file attachment.


Also, it appears that the openMSX maintainer's debian.org email address 
must be pointing to an Apple support address since I've now gotten two 
"Thank you for contacting us" emails from apple.com.


--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3
Binary files /tmp/phkMJNskDj/openmsx-19.1/Contrib/codec/Win32/zmbv.dll and /tmp/Cd74GNmEnl/openmsx-19.1+dfsg/Contrib/codec/Win32/zmbv.dll differ
diff -Nru openmsx-19.1/debian/changelog openmsx-19.1+dfsg/debian/changelog
--- openmsx-19.1/debian/changelog	2023-09-01 01:39:39.0 -0500
+++ openmsx-19.1+dfsg/debian/changelog	2023-11-24 13:47:59.0 -0600
@@ -1,3 +1,25 @@
+openmsx (19.1+dfsg-2) unstable; urgency=medium
+
+  * Override spurious source-is-missing Lintian errors.
+  * Don't build-depend on dpkg-dev, it's guaranteed to be installed in a
+Debian build environment.
+  * Repack the upstream tarball to remove a prebuilt Windows binary.
+(Closes: #1056780)
+  * Set 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' in debian/rules.
+  * Remove debian/source/include-binaries, every file listed in it doesn't
+exist.
+  * Make debian/copyright point to more specific license files in
+/usr/share/common-licenses.
+  * Set 'Rules-Requires-Root: no' in debian/control.
+  * Use debhelper 13 rather than debhelper 10.
+  * Override spurious package-contains-documentation-outside-usr-share-doc
+Lintian gripes.
+  * Created debian/upstream/metadata file.
+  * Switch back to using vendored catch2, the catch2 Debian package now ships
+catch2 v3 whereas openMSX uses catch2 v2.
+
+ -- Aaron Rainbolt   Fri, 24 Nov 2023 13:47:59 -0600
+
 openmsx (19.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru openmsx-19.1/debian/compat openmsx-19.1+dfsg/debian/compat
--- openmsx-19.1/debian/compat	2017-08-06 07:57:22.0 -0500
+++ openmsx-19.1+dfsg/debian/compat	1969-12-31 18:00:00.0 -0600
@@ -1 +0,0 @@
-10
diff -Nru openmsx-19.1/debian/control openmsx-19.1+dfsg/debian/control
--- openmsx-19.1/debian/control	2023-08-03 02:11:39.0 -0500
+++ openmsx-19.1+dfsg/debian/control	2023-11-24 13:47:59.0 -0600
@@ -2,9 +2,10 @@
 Section: otherosfs
 Priority: optional
 Maintainer: Bas Wijnen 
-Build-Depends: debhelper (>= 10), dpkg-dev, docbook-to-man, libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev, catch2
+Build-Depends: debhelper-compat (= 13), docbook-to-man, libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev
 Standards-Version: 4.6.2
 Homepage: https://openmsx.org
+Rules-Requires-Root: no
 
 Package: openmsx
 Architecture: any
diff -Nru openmsx-19.1/debian/copyright openmsx-19.1+dfsg/debian/copyright
--- openmsx-19.1/debian/copyright	2021-06-17 06:21:11.0 -0500
+++ openmsx-19.1+dfsg/debian/copyright	2023-11-24 13:47:59.0 -0600
@@ -2,29 +2,31 @@
 Upstream-Name: openMSX
 Upstream-Contact: https://web.libera.chat/#openMSX
 Source: https://github.com/openMSX/openMSX/
+Files-Excluded: Contrib/codec/Win32/zmbv.dll
 
 Files: *
 Copyright: copyright © 2001-2021 by the openMSX developers.
-License: GPL
+License: GPL-2
  This program is free software: you can redistribute it and/or modify
  it under the terms of any version of the GNU General Public License as
  published by the Free Software Foundation.
  .
- The latest version of the GPL can be found in
- /usr/share/common-licenses/GPL.
+ Version 2 of the GPL can be found in
+ /usr/share/common-licenses/GPL-2.
 
 Files: debian/*
 Copyright:
 	© 2004-2009, Joost Yervante Damad 
 	Copyright 2012-2021, Bas Wijnen 
+	Copyright 2023, Aaron Rainbolt 
 License: GPL-3+
  This program is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.
  .
- The latest version of the GPL can be found in
- /usr/share/common-licenses/GPL.
+ On Debian systems, the GPL version 3 can be found in
+ /usr/share/common-licenses/GPL-3.
 
 
 Files: src/serial/Midi_w32.*
diff -Nru openmsx-19.1/debian/openmsx-data.lintian-overrides openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides
--- openmsx-19.1/debian/openmsx-data.lintian-overrides	1969-12-31 18:00:00.0 -0600
+++ openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides	2023-11-24 13:47:59.0 -0600
@@ -0,0 +1,22 @@
+# All of these are either false positives or they describe what should go in the directories they are in.
+openmsx-data: package-contains-documentation-outside-usr-share-doc [usr/share/openmsx/extensions/README]

Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)

[Aaron Rainbolt]

Here's a debdiff between the current version of the openMSX package and 
a proposed new version that fixes this bug. **Note**: It is necessary to 
also delete the Contrib/codec/Win32/zmbv.dll file in the source package 
tree (debdiffs don't seem to communicate deleted binary files very well).



--



Binary files /tmp/phkMJNskDj/openmsx-19.1/Contrib/codec/Win32/zmbv.dll 
and /tmp/Cd74GNmEnl/openmsx-19.1+dfsg/Contrib/codec/Win32/zmbv.dll differ

diff -Nru openmsx-19.1/debian/changelog openmsx-19.1+dfsg/debian/changelog
--- openmsx-19.1/debian/changelog    2023-09-01 01:39:39.0 -0500
+++ openmsx-19.1+dfsg/debian/changelog    2023-11-24 13:47:59.0 
-0600

@@ -1,3 +1,25 @@
+openmsx (19.1+dfsg-2) unstable; urgency=medium
+
+  * Override spurious source-is-missing Lintian errors.
+  * Don't build-depend on dpkg-dev, it's guaranteed to be installed in a
+    Debian build environment.
+  * Repack the upstream tarball to remove a prebuilt Windows binary.
+    (Closes: #1056780)
+  * Set 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' in debian/rules.
+  * Remove debian/source/include-binaries, every file listed in it doesn't
+    exist.
+  * Make debian/copyright point to more specific license files in
+    /usr/share/common-licenses.
+  * Set 'Rules-Requires-Root: no' in debian/control.
+  * Use debhelper 13 rather than debhelper 10.
+  * Override spurious package-contains-documentation-outside-usr-share-doc
+    Lintian gripes.
+  * Created debian/upstream/metadata file.
+  * Switch back to using vendored catch2, the catch2 Debian package now 
ships

+    catch2 v3 whereas openMSX uses catch2 v2.
+
+ -- Aaron Rainbolt   Fri, 24 Nov 2023 13:47:59 -0600
+
 openmsx (19.1-1) unstable; urgency=medium

   * New upstream release.
diff -Nru openmsx-19.1/debian/compat openmsx-19.1+dfsg/debian/compat
--- openmsx-19.1/debian/compat    2017-08-06 07:57:22.0 -0500
+++ openmsx-19.1+dfsg/debian/compat    1969-12-31 18:00:00.0 -0600
@@ -1 +0,0 @@
-10
diff -Nru openmsx-19.1/debian/control openmsx-19.1+dfsg/debian/control
--- openmsx-19.1/debian/control    2023-08-03 02:11:39.0 -0500
+++ openmsx-19.1+dfsg/debian/control    2023-11-24 13:47:59.0 -0600
@@ -2,9 +2,10 @@
 Section: otherosfs
 Priority: optional
 Maintainer: Bas Wijnen 
-Build-Depends: debhelper (>= 10), dpkg-dev, docbook-to-man, 
libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, 
libsdl2-ttf-dev, python3, libvorbis-dev, libtheora-dev, libogg-dev, 
libao-dev, libfreetype-dev, catch2
+Build-Depends: debhelper-compat (= 13), docbook-to-man, libsdl2-dev, 
libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, 
libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev

 Standards-Version: 4.6.2
 Homepage: https://openmsx.org
+Rules-Requires-Root: no

 Package: openmsx
 Architecture: any
diff -Nru openmsx-19.1/debian/copyright openmsx-19.1+dfsg/debian/copyright
--- openmsx-19.1/debian/copyright    2021-06-17 06:21:11.0 -0500
+++ openmsx-19.1+dfsg/debian/copyright    2023-11-24 13:47:59.0 
-0600

@@ -2,29 +2,31 @@
 Upstream-Name: openMSX
 Upstream-Contact: https://web.libera.chat/#openMSX
 Source: https://github.com/openMSX/openMSX/
+Files-Excluded: Contrib/codec/Win32/zmbv.dll

 Files: *
 Copyright: copyright © 2001-2021 by the openMSX developers.
-License: GPL
+License: GPL-2
  This program is free software: you can redistribute it and/or modify
  it under the terms of any version of the GNU General Public License as
  published by the Free Software Foundation.
  .
- The latest version of the GPL can be found in
- /usr/share/common-licenses/GPL.
+ Version 2 of the GPL can be found in
+ /usr/share/common-licenses/GPL-2.

 Files: debian/*
 Copyright:
 © 2004-2009, Joost Yervante Damad 
 Copyright 2012-2021, Bas Wijnen 
+    Copyright 2023, Aaron Rainbolt 
 License: GPL-3+
  This program is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.
  .
- The latest version of the GPL can be found in
- /usr/share/common-licenses/GPL.
+ On Debian systems, the GPL version 3 can be found in
+ /usr/share/common-licenses/GPL-3.


 Files: src/serial/Midi_w32.*
diff -Nru openmsx-19.1/debian/openmsx-data.lintian-overrides 
openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides
--- openmsx-19.1/debian/openmsx-data.lintian-overrides 1969-12-31 
18:00:00.0 -0600
+++ openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides 2023-11-24 
13:47:59.0 -0600

@@ -0,0 +1,22 @@
+# All of these are either false positives or they describe what should 
go in the directories they are in.
+openmsx-data: package-contains-documentation-outside-usr-share-doc 
[usr/share/openmsx/extensions/README]
+openmsx-data: package-contains-documentation-outside-usr-share-doc 
[usr/share/openmsx/machines/Boosted_MSX2+_JP.txt]

Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)

[Aaron Rainbolt]

Package: openmsx
Version: 19.1-1
Severity: serious
Justification: Policy 2.2.1
X-Debbugs-Cc: arraybo...@ubuntu.com

Packages in the Debian `main` archive area *must* comply with the DFSG, of
which section 2 states "The program must include source code, and must allow
distribution in source code as well as compiled form." The openMSX package
currently ships a Windows library (Contrib/codec/Win32/zmbv.dll) allegedly
built from code that is part of DOSBox. The source code of the library is not
included, and the library is fairly useless in Debian for obvious reasons.

On top of this, there are a number of packaging issues that could be improved
but that aren't so serious - the most problematic of these is an autopkgtest
failure caused by catch2 (Debian currently ships catch2 v3, but openMSX's
tests are only designed for catch2 v2 - thankfully there's a vendored version
of catch2 in openMSX that builds successfully on Debian Sid now). As there
does not appear to be a VCS link to the openMSX packaging in
tracker.debian.org, I'm assuming openMSX isn't in Debian Salsa yet, and will
provide a debdiff in this bug report.


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

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

Versions of packages openmsx depends on:
ii  cbios  0.29a-1
ii  libasound2 1.2.10-1
ii  libc6  2.37-12
ii  libgcc-s1  13.2.0-7
ii  libgl1 1.7.0-1
ii  libglew2.2 2.2.0-4+b1
ii  libogg01.3.5-3
ii  libpng16-161.6.40-2
ii  libsdl2-2.0-0  2.28.5+dfsg-2
ii  libsdl2-ttf-2.0-0  2.20.2+dfsg-1
ii  libstdc++6 13.2.0-7
ii  libtcl8.6  8.6.13+dfsg-2
ii  libtheora0 1.1.1+dfsg.1-16.1+b1
ii  libvorbis0a1.3.7-1
ii  openmsx-data   19.1-1
ii  zlib1g 1:1.3.dfsg-3

openmsx recommends no packages.

Versions of packages openmsx suggests:
pn  dmktools  
pn  openmsx-catapult  
pn  openmsx-debugger  

-- no debconf information

Bug#1056779: derby-doc: some javadoc missing from derby-doc

[tony mancill]

Package: derby-doc
Severity: normal

I noticed during the preparation of 10.14.2.0-3 that the javadoc
installed in the derby-doc binary package is much less than what is
provided in 10.14.2.0-2.

This must be due to some change in the toolchain, since rebuilding
10.14.2.0-2 against sid, trixie, or bookworm results in the same
discrepancy.

Bug#1056384: X server shuts down and doesn't return during upgrade.

[Adam Dane]

On 2023-11-25 06:31, Andreas Beckmann wrote:
May I take the lack of comment on nvidia-suspend-common 525.147.05-3 
that it now behaves normally? ;-)


Yes, all is well.

PS: It would be great if someone could confirm that also suspend/resume 
and hibernate/resume cycles work properly with these new services 
enabled.


I just tried both suspend and hibernate, and both worked correctly.

Thanks,

Adam

Bug#1056778: gnome-shell: Leaks memory using Wayland

[Adrian Immanuel Kiess]

Package: gnome-shell
Version: 44.5-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 Upgrading gnome-shell on Debian/testing
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 apt -u dist-upgrade
   * What was the outcome of this action?
 gnome-shell process leaks memory on Debian/testing
   * What outcome did you expect instead?
 gnome-shell process not leaking memory

currently, since a while, the gnome-shell process leaks memory using gnome
shell with Wayland. I am using gnome-shell as Wayland process, and under
current Debian/testing environment, the process leaks memory and can get
several gigabyte large.

Output from 'top':

14237 adrian20   0 9525320   1,3g 764448 S  15,9   8,6  35:33.41 gnome-
shell

As you can see in above example, the gnome-shell process uses 1,3GB random
access memory. Please bear in mind, that several gigabyte of memory usage are
already swapped out to the Linux swap partition.

% grep --color VmSwap /proc/14237/status
VmSwap:  2938064 kB

As in above example, ~3 gigabyte of memory are swapped out.

In conjunction with above recognition, the gnome shell (user interface)
'freezes' several seconds, from time to time.

Thank you very much for your kind attention,

Adrian Kieß


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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gconf-gsettings-backend [gsettings-backend]  3.2.6-8
ii  gir1.2-accountsservice-1.0   23.13.9-4
ii  gir1.2-adw-1 1.4.0-2
ii  gir1.2-atk-1.0   2.50.0-1
ii  gir1.2-atspi-2.0 2.50.0-1
ii  gir1.2-freedesktop   1.78.1-5
ii  gir1.2-gcr-3 3.41.1-3
ii  gir1.2-gdesktopenums-3.0 45.0-2
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-3
ii  gir1.2-gdm-1.0   45.0.1-1
ii  gir1.2-geoclue-2.0   2.7.1-1
ii  gir1.2-glib-2.0  1.78.1-5
ii  gir1.2-gnomebg-4.0   44.0-2
ii  gir1.2-gnomebluetooth-3.042.6-1
ii  gir1.2-gnomedesktop-4.0  44.0-2
ii  gir1.2-graphene-1.0  1.10.8-2
ii  gir1.2-gstreamer-1.0 1.22.6-1
ii  gir1.2-gtk-4.0   4.12.3+ds-2
ii  gir1.2-gweather-4.0  4.4.0-1
ii  gir1.2-ibus-1.0  1.5.29~rc2-1
ii  gir1.2-mutter-12 44.5-2
ii  gir1.2-nm-1.01.44.2-3
ii  gir1.2-nma4-1.0  1.10.6-1
ii  gir1.2-pango-1.0 1.51.0+ds-3
ii  gir1.2-polkit-1.0123-3
ii  gir1.2-rsvg-2.0  2.54.7+dfsg-2
ii  gir1.2-soup-3.0  3.4.4-2
ii  gir1.2-upowerglib-1.01.90.2-6
ii  gir1.2-webkit2-4.1   2.42.2-1
ii  gnome-backgrounds45.0-1
ii  gnome-settings-daemon45.0-1
ii  gnome-shell-common   44.5-2
ii  gsettings-desktop-schemas45.0-2
ii  gstreamer1.0-pipewire0.3.85-1
ii  libatk-bridge2.0-0   2.50.0-1
ii  libatk1.0-0  2.50.0-1
ii  libc62.37-12
ii  libcairo21.18.0-1
ii  libecal-2.0-23.50.1-1
ii  libedataserver-1.2-273.50.1-1
ii  libgcr-base-3-1  3.41.1-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libgirepository-1.0-11.78.1-5
ii  libgjs0g 1.78.0-1
ii  libgles2 1.7.0-1
ii  libglib2.0-0 2.78.1-4
ii  libglib2.0-bin   2.78.1-4
ii  libgnome-autoar-0-0  0.4.4-2
ii  libgnome-desktop-4-2 44.0-2
ii  libgraphene-1.0-01.10.8-2
ii  libgtk-3-0   3.24.38-6
ii  libgtk-4-1   4.12.3+ds-2
ii  libical3 3.0.17-1
ii  libjson-glib-1.0-0   1.8.0-2
ii  libmutter-12-0

Bug#1056736: smartmontools: please do not force people to use update-smart-drivedb and install foreign code

[Dmitry Smirnov]

On Sunday, 26 November 2023 12:39:09 PM AEDT Christoph Anton Mitterer wrote:
> Nevertheless, do you think it would possible to adapt it to check
> whether update-smart-drivedb is executable and if not fall back to the
> old code?
> 
> Background is that at the university cluster I administrate we have set
> dpkg-statoverrides for various "code downloader" commands like update-
> smart-drivedb, update-ieee-data or update-pciids, which removes their
> executeable bit, so that they're at least not accidentally run.
> 
> Would be nice if it could be kept that way.

Done: 

  https://salsa.debian.org/debian/smartmontools/-/commit/625f38bc

Thanks for suggestion and feedback.

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Just as everyone in a tribe praying to a volcano god would reinforce the
idea that there is a volcano god, so begging politicians for favors
reinforces the idea that there is a rightful ruling class, that their
commands are "law," and that obedience to such "laws" is a moral
imperative.
 -- Larken Rose, The Most Dangerous Superstition


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

Bug#1056777: firefox: Audio accelerated, popping and crackling

[Alexandre Lymberopoulos]

Package: firefox
Version: 120.0-2
Severity: normal

Dear Maintainer,

Everytime I open any video content (eg Youtube) the audio is extremely
accelerated, with popping and crackling. Two curious things:

1) when I open speech-dispatcher the audio gets normal.
2) when I open pavucontrol (using pipewire here) the audio also gets normal.
3) chromium plays audio perfectly no matter pavucontrol or speechdispatcher is 
open or not.

I can provide any further information required to help here (maybe
I'll need some help to produce it)

Best, Alexandre

-- Package-specific info:


-- Addons package information

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/4 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)

Versions of packages firefox depends on:
ii  debianutils  5.14
ii  fontconfig   2.14.2-6
ii  libasound2   1.2.10-1
ii  libatk1.0-0  2.50.0-1
ii  libc62.37-12
ii  libcairo-gobject21.18.0-1
ii  libcairo21.18.0-1
ii  libdbus-1-3  1.14.10-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.2-6
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s113.2.0-5
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.1-4
ii  libgtk-3-0   3.24.38-6
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.94-1
ii  libpango-1.0-0   1.51.0+ds-3
ii  libstdc++6   13.2.0-5
ii  libvpx8  1.13.1-2
ii  libx11-6 2:1.8.7-1
ii  libx11-xcb1  2:1.8.7-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  procps   2:4.0.4-2
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages firefox recommends:
ii  libavcodec60  7:6.1-3

Versions of packages firefox suggests:
ii  fonts-lmodern  2.005-1
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-11
ii  libgssapi-krb5-2   1.20.1-5
pn  pulseaudio 

-- no debconf information

Bug#1056776: RFS: iotop-c/1.25-1~bpo12+1 -- simple top-like I/O monitor (implemented in C)

[Boian Bonev]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "iotop-c":

 * Package name : iotop-c
   Version  : 1.25-1~bpo12+1
   Upstream contact : Boian Bonev 
 * URL  : https://github.com/Tomas-M/iotop
 * License  : GPL-2.0+
 * Vcs  : https://github.com/Tomas-M/iotop
   Section  : admin

The source builds the following binary packages:

  iotop-c - simple top-like I/O monitor (implemented in C)

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

  https://mentors.debian.net/package/iotop-c/

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

  dget -x
https://mentors.debian.net/debian/pool/main/i/iotop-c/iotop-c_1.25-1~bpo12+1.dsc

Changes since the last upload:

 iotop-c (1.25-1~bpo12+1) bookworm-backports; urgency=medium
 .
   * Rebuild for bookworm-backports.

Regards,
-- 
  Boian Bonev



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

Bug#1056775: debian-archive-keyring: trusted.gpg.d asc fragments not minimal

[Dimitri John Ledkov]

Package: debian-archive-keyring
Version: 2021.1.1ubuntu2
Severity: wishlist

Dear Maintainer,

In a sid chroot,

# apt-key export 2>/dev/null | wc
   11511158   74594

# export GNUPGHOME=$(mktemp -d)
# apt-key export 2>/dev/null | gpg --import &>/dev/null
# gpg --export --armor --export-options export-minimal | wc
790 797   51161

As if the .asc key fragments are not minimal.

Given that "full" .gpg keyrings exist in keyrings locations, maybe
.asc fragments could be minimized?

Also the .asc fragments seemed to have some sort of revocations on them - the 
`sigR` stanzas:

pub   rsa4096 2019-04-14 [SC] [expires: 2027-04-12]
  5E61B217265DA9807A23C5FF4DFAB270CAA96DFA
sigR 4DFAB270CAA96DFA 2019-04-14  Debian Security Archive Automatic 
Signing Key (10/buster) 
sigR 4DFAB270CAA96DFA 2019-04-14  Debian Security Archive Automatic 
Signing Key (10/buster) 
sigR 4DFAB270CAA96DFA 2019-04-14  Debian Security Archive Automatic 
Signing Key (10/buster) 
sigR 4DFAB270CAA96DFA 2019-04-14  Debian Security Archive Automatic 
Signing Key (10/buster) 
sigR 4DFAB270CAA96DFA 2019-04-14  Debian Security Archive Automatic 
Signing Key (10/buster) 
uid   [ unknown] Debian Security Archive Automatic Signing Key 
(10/buster) 
sig 34DFAB270CAA96DFA 2019-04-14  Debian Security Archive Automatic 
Signing Key (10/buster) 
sig  E0B11894F66AEC98 2019-04-14  [User ID not found]
sig  EDA0D2388AE22BA9 2019-04-14  [User ID not found]
sig  BC372252CA1CF964 2019-04-14  [User ID not found]
sig PDB16CF5BB12525C4 2019-04-14  [User ID not found]
sub   rsa4096 2019-04-14 [S] [expires: 2027-04-12]
sig  4DFAB270CAA96DFA 2019-04-14  Debian Security Archive Automatic 
Signing Key (10/buster) 

What are these `sigR` things, and are they really needed in the .asc 
fragment?

Regards,

Dimitri.

Bug#1056736: smartmontools: please do not force people to use update-smart-drivedb and install foreign code

[Paul Wise]

On Sun, 2023-11-26 at 12:23 +1100, Dmitry Smirnov wrote:
> On Sunday, 26 November 2023 4:56:03 AM AEDT Christoph Anton Mitterer wrote:
> > Even if the downloader tool does everything right (which is actually quite
> > difficult if one assumes things like replay or blocking attacks), there's
> > still code introduced which is not in the control of Debian and especially
> > also outside security support.
> 
> IMHO this is a valid concern ... What do you think, Paul?

As far as I can tell from parse_drive_database in knowndrives.cpp there
is no code being loaded, it just parses drivedb.h as a text file. There
could still of course be security issues in the approach but since
upstream is signing the file and the downloader verifies signatures,
only upstream could exploit any security issues in their own code,
but those could be target specific while their released code isn't.
Probably those who are concerned about this should talk to upstream
about switching to a more common format with more robust parsers.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1056319: RFP: avis-imgv -- Fast and Configurable Rust Image Viewer

[Maytham Alsudany]

Control: owner -1 maytha8the...@gmail.com
Control: retitle -1 ITP: avis-imgv -- Fast and Configurable Rust Image Viewer

Hi,

I'm happy to package avis-imgv, it looks like a very useful piece of software.

I've let the upstream maintainer know that this RFP exists, and that they should
publish their package to crates.io in order to get this packaged[1].

When that happens, I'll submit a PR to the rust-team/debcargo-conf repo.

Kind regards,
Maytham

[1]: https://github.com/hats-np/avis-imgv/issues/8


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

Bug#1056763: gdb: Remove references to obsolete dpkg m32r arch

[Guillem Jover]

Hi!

On Sun, 2023-11-26 at 02:43:34 +0100, Héctor Orón Martínez wrote:
>   Thanks for the patch, however, I think we can keep support for this
> architecture in the multiarch package, therefore drop the snippet
> below from your patch.

> diff --git a/debian/rules b/debian/rules
> index 27b3f9d0e1b..1c0a55fa447 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -190,7 +190,7 @@ MULTIARCH_TARGETS := \
>  sparc64-linux-gnu \
>  x86_64-linux-gnu \
>  x86_64-linux-gnux32 \
> -m32r-linux-gnu
> +# EOL
> 
>  # broken, see https://launchpad.net/bugs/1233185
>  #MULTIARCH_TARGETS := all

I pondered about this, and should have given more context, but just to
note that, Linux dropped support for m32r in 4.16, and gcc dropped
support for it in 12.1, I don't think the glibc support was ever
upstreamed, so it seems pretty dead at this point, and that was the
reason I deemed it safe to drop support for it from dpkg.

> I have applied your patch to the git tree and this is queued for the
> upcoming GDB release. I have added a changelog entry for it.

Thanks!

Regards,
Guillem

Bug#1056736: smartmontools: please do not force people to use update-smart-drivedb and install foreign code

[Paul Wise]

On Sun, 2023-11-26 at 02:39 +0100, Christoph Anton Mitterer wrote:

> Nevertheless, do you think it would possible to adapt it to check
> whether update-smart-drivedb is executable and if not fall back to the
> old code?

This seems reasonable to me.

I would also suggest using --quiet in the postinst, because there isn't
much point to having anything printed for just a cp and the message
"NOT VERIFIED" printed when --quiet is missing is unnecessarily scary
in the context of copying a file that is shipped with the package.
Perhaps also talk to upstream about making that less scary?

BTW Chris, I imagine you might have some issues for this page:

https://wiki.debian.org/PrivacyIssues

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1056774: Blank space on copyright page

[Dan Jacobson]

Package: viking

In /usr/share/doc/viking/copyright it says

It was downloaded from

and there is a blank space.

Bug#1053950: openttd: diff for NMU version 13.4-0.1

[Maytham Alsudany]

Hi Matthijs,

On Sat, 2023-11-25 at 18:00 +0100, Matthijs Kooijman wrote:
> 
> I'll go through my normal git-based workflow rather than using your NMU
> though,
nmudiff (from devscripts) did that gigantic diff, but I've followed
your workflow in my fork of the repo at [1], if you want to just copy
the commits over (and change the Debian revision from -0.1 to -1).

> AFAICS you've made no changes to the packaging except import the
> upstream tarball, right?

That's correct. 
I've built it on my computer, and have ran it through the usual tests,
and the only issue is that Lintian says the override for the missing
man page is unnecessary.

Thanks for your work! Looking forward to the new version.

Kind regards,
Maytham

[1]: http://salsa.debian.org/Maytha8/openttd


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

Bug#1056763: gdb: Remove references to obsolete dpkg m32r arch

[Héctor Orón Martínez]

Hello Guillem,

  Thanks for the patch, however, I think we can keep support for this
architecture in the multiarch package, therefore drop the snippet
below from your patch.

diff --git a/debian/rules b/debian/rules
index 27b3f9d0e1b..1c0a55fa447 100755
--- a/debian/rules
+++ b/debian/rules
@@ -190,7 +190,7 @@ MULTIARCH_TARGETS := \
 sparc64-linux-gnu \
 x86_64-linux-gnu \
 x86_64-linux-gnux32 \
-m32r-linux-gnu
+# EOL

 # broken, see https://launchpad.net/bugs/1233185
 #MULTIARCH_TARGETS := all

I have applied your patch to the git tree and this is queued for the
upcoming GDB release. I have added a changelog entry for it.

Thanks for your support.

On Sat, 25 Nov 2023 at 23:45, Guillem Jover  wrote:
>
> Source: gdb
> Source-Version: 13.2-1
> Severity: important
> Tags: patch
>
> Hi!
>
> Support for this arch got removed in dpkg 1.22.0, which means that
> once the host running dak gets its dpkg upgraded to that version it
> might start being unhappy about the unknown architecture.
>
> Attached an untested patch that removes references to this obsolete arch.
>
> Thanks,
> Guillem



-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#1056736: smartmontools: please do not force people to use update-smart-drivedb and install foreign code

[Christoph Anton Mitterer]

Control: severity -1 normal
Control: tags - security


Hey.

On Sun, 2023-11-26 at 12:23 +1100, Dmitry Smirnov wrote:
> I think you misunderstood that invocation of `update-smart-drivedb`
> in postinst is an equivalent of 
> 
> ```
> cp -f /usr/share/smartmontools/drivedb.h 
> /var/lib/smartmontools/drivedb/
> ```

Indeed. At least from the documentation (only had a short glance now
what it actually does if file= is set... but seems you're right).

Sorry for that, I had wrongly in mind that --install would also
download.


Nevertheless, do you think it would possible to adapt it to check
whether update-smart-drivedb is executable and if not fall back to the
old code?

Background is that at the university cluster I administrate we have set
dpkg-statoverrides for various "code downloader" commands like update-
smart-drivedb, update-ieee-data or update-pciids, which removes their
executeable bit, so that they're at least not accidentally run.

Would be nice if it could be kept that way.


Thanks,
Chris.

Bug#932617: fixed in fwupd 1.9.9-2

[Paul Wise]

Control: reopen -1

On Sat, 2023-11-25 at 14:40 +, Mario Limonciello wrote:

>    * Remove extra confffiles (Closes: #1040350)

This didn't work because the wrong version number was used, it should
be the version number of the upload you added the removal postinst in,
not the version that dropped the conffiles.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1056736: smartmontools: please do not force people to use update-smart-drivedb and install foreign code

[Dmitry Smirnov]

On Sunday, 26 November 2023 4:56:03 AM AEDT Christoph Anton Mitterer wrote:
> The most recent upgrade forces people to use
> update-smart-drivedb by doing it already in the postinst and not leaving it
> up to the user whether he wants to use such a tool.
> 
> Security-wise this is really a bad idea.

I think you misunderstood that invocation of `update-smart-drivedb`
in postinst is an equivalent of 

```
cp -f /usr/share/smartmontools/drivedb.h  /var/lib/smartmontools/drivedb/
```

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006019#17
as well as 
https://salsa.debian.org/debian/smartmontools/-/commit/5b1fd114a

Of course I would not recommend to download drivedb from postinst
and this is not what's happening.


> Even if the downloader tool does everything right (which is actually quite
> difficult if one assumes things like replay or blocking attacks), there's
> still code introduced which is not in the control of Debian and especially
> also outside security support.

IMHO this is a valid concern, however this tool is not used as downloader
in postinst.
What do you think, Paul?


> Now you may argue that Debian doesn't audit the drivedb.h it ships either
> and that thus security wouldn't be any better if Debian would just ship
> the upstream file.
> But there's still a difference:
> If Debian ships the package, then all installations are guaranteed to get
> the same file.

Debian ships the file. Merely installation method has changed, nothing else.


> If however the package is downloaded from some remote server, an attacker
> can choose based on IP whether the "good" or the "evil" file is delivered.

File is NOT downloaded from postinst.


> And this is not to say that I'd assume smartmontools upstream would be
> evil. But even their GPG keys or systemd can be compromised.

A lot of things can be compromised. Far-fetched paranoid speculations hardly
make the case stronger.


> But please don't force it on everyone by unconditionally calling it from
> postinst (or from anywhere else).

I read your concerns, but reality of what you've described is not what
actually happening.

-- 
Kind regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

It is strange that many believe they cannot control themselves, but they
can control others.
 -- Robert LeFevre, "A Way to Be Free: The Autobiography of Robert LeFevre, 
Volume I" (1999)


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

Bug#1056773: ftp.debian.org: Hash mismatch of files in FTP master server in two weeks

[Takahide Nojima]

Package: ftp.debian.org
Severity: important
X-Debbugs-Cc: nozzy123no...@gmail.com

Dear ftp-master,

 I have encountered a problem with apt reporting a hash mismatch in two
weeks,

- here -
Error: http://deb.debian.org/debian sid/contrib DEP-11 48x48 Icons
  Hash Sum mismatch
Hashes of expected file:
 - Filesize:95744 [weak]
 -
SHA256:41b502bb3a63ebf92017c002a097c42213c0f696091e3def404062ff4d684d73
 - MD5Sum:3c00352a046675360f792e59ef180f15 [weak]
Hashes of received file:
 -
SHA256:9c28263e7552f7c09da711f5f37a677585fbe758f5a098c523e0eb9464c9edfc
 - MD5Sum:ed7f3fde497250ae3e55ff8885e5c911 [weak]
 - Filesize:81920 [weak]
Release file created at: Sat, 25 Nov 2023 20:18:11 +
Error: http://deb.debian.org/debian sid/contrib DEP-11 64x64 Icons
-


 I have contacted debian-mirrors@l.d.o,
https://lists.debian.org/debian-mirrors/2023/11/msg4.html

and they have confirmed that the sync to the mirror servers is working
fine.

Could you please check the files on the ftp master and see if there is
any issue?

I appreciate your feedback and assistance.

Takahide Nojima

Bug#1056772: apt-listchanges: [INTL:pt_BR] Brazilian Portuguese translation

[Carlos Henrique Lima Melara]

Package: apt-listchanges
Version: 3.27
Severity: wishlist
Tags: l10n patch
X-Debbugs-Cc: charlesmel...@riseup.net

Hi,

Please, find attached the updated Brazilian Portuguese translation.
It is UTF-8 encoded, tested with msgfmt.

Best regards,
Charles
# apt-listchanges Brazilian Portuguese translation
# Copyright (c) 2003-2008 apt-listchanges's COPYRIGHT HOLDER
# This file is distributed under the same license as the apt-listchanges.
# André Luís Lopes , 2003.
# Felipe Augusto van de Wiel (faw) , 2008.
# Paulo Henrique de Lima Santana (phls) , 2022.
# Carlos Henrique Lima Melara , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: apt-listchanges-3.24\n"
"Report-Msgid-Bugs-To: apt-listchan...@packages.debian.org\n"
"POT-Creation-Date: 2023-10-23 20:10-0400\n"
"PO-Revision-Date: 2023-11-15 22:30-0300\n"
"Last-Translator: Carlos Henrique Lima Melara \n"
"Language-Team: Brazilian Portuguese \n"
"Language: pt_BR\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 3.4.1\n"

#: ../apt_listchanges/ALCApt.py:57
msgid "APT pipeline messages:"
msgstr "Mensagens do pipeline APT:"

#: ../apt_listchanges/ALCApt.py:64
msgid "Packages list:"
msgstr "Lista de pacotes:"

#: ../apt_listchanges/ALCApt.py:74
msgid ""
"APT_HOOK_INFO_FD environment variable is not defined\n"
"(is Dpkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD set to 20?)"
msgstr ""
"A variável de ambiente APT_HOOK_INFO_FD não está definida\n"
"(o Dpkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD está definido como "
"20?)"

#: ../apt_listchanges/ALCApt.py:82
msgid "Invalid (non-numeric) value of APT_HOOK_INFO_FD environment variable"
msgstr "Valor inválido (não numérico) da variável de ambiente APT_HOOK_INFO_FD"

#: ../apt_listchanges/ALCApt.py:85
#, python-format
msgid "Will read apt pipeline messages from file descriptor %d"
msgstr "Irá ler mensagens do pipeline apt do descritor de arquivo %d"

#: ../apt_listchanges/ALCApt.py:90
msgid ""
"APT_HOOK_INFO_FD environment variable is incorrectly defined\n"
"(Dpkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD should be greater "
"than 2)."
msgstr ""
"A variável de ambiente APT_HOOK_INFO_FD está definida incorretamente\n"
"(Dpkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD deve ser maior que "
"2)."

#: ../apt_listchanges/ALCApt.py:98
#, python-format
msgid "Cannot read from file descriptor %(fd)d: %(errmsg)s"
msgstr "Não é possível ler do descritor de arquivo %(fd)d: %(errmsg)s"

#: ../apt_listchanges/ALCApt.py:105
msgid ""
"Wrong or missing VERSION from apt pipeline\n"
"(is Dpkg::Tools::Options::/usr/bin/apt-listchanges::Version set to 2?)"
msgstr ""
"Versão (\"VERSION\") incorreta ou faltando a partir do pipeline apt\n"
"(o Dpkg::Tools::Options::/usr/bin/apt-listchanges::Version está como 2?)"

#: ../apt_listchanges/ALCConfig.py:164
#, python-format
msgid "Unknown configuration file option: %s"
msgstr "Opção do arquivo de configuração desconhecida: %s"

#: ../apt_listchanges/ALCConfig.py:179
msgid "Usage: apt-listchanges [options] {--apt | filename.deb ...}\n"
msgstr "Uso: apt-listchanges [opções] {--apt | arquivo.deb ...}\n"

#: ../apt_listchanges/ALCConfig.py:186
#, python-format
msgid "Unknown argument %(arg)s for option %(opt)s.  Allowed are: %(allowed)s."
msgstr ""
"Argumento desconhecido %(arg)s para a opção %(opt)s. São permitidos: "
"%(allowed)s."

#: ../apt_listchanges/ALCConfig.py:200
#, python-format
msgid "%(deb)s does not have '.deb' extension"
msgstr "%(deb)s não tem extensão '.deb'"

#: ../apt_listchanges/ALCConfig.py:204
#, python-format
msgid "%(deb)s does not exist or is not a file"
msgstr "%(deb)s não existe ou não é um arquivo"

#: ../apt_listchanges/ALCConfig.py:208
#, python-format
msgid "%(deb)s is not readable"
msgstr "%(deb)s não pode ser lido"

#: ../apt_listchanges/ALCConfig.py:315
msgid "--since= and --show-all are mutually exclusive"
msgstr "--since= e --show-all são mutuamente exclusivos"

#: ../apt_listchanges/ALCConfig.py:325
msgid "--since= expects a path to exactly one .deb archive"
msgstr "--since= espera um caminho para exatamente um arquivo .deb"

#: ../apt_listchanges/ALCConfig.py:333
msgid "--latest= and --show-all are mutually exclusive"
msgstr "--latest= e --show-all são mutuamente exclusivos"

#: ../apt_listchanges/ALCLog.py:37 ../apt_listchanges/ALCLog.py:46
#, python-format
msgid "apt-listchanges: %(msg)s"
msgstr "apt-listchanges: %(msg)s"

#: ../apt_listchanges/ALCLog.py:41
#, python-format
msgid "apt-listchanges warning: %(msg)s"
msgstr "aviso do apt-listchanges: %(msg)s"

#: ../apt_listchanges/ALCSeenDb.py:154
#, python-format
msgid "Database %(db)s failed to load: %(errmsg)s"
msgstr "Falha ao carregar o banco de dados %(db)s: %(errmsg)s"

#: ../apt_listchanges/AptListChangesGtk.py:51
msgid "apt-listchanges: Reading changelogs"
msgstr "apt-listchanges: Lendo logs de mudanças"

#: ../apt_listchanges/AptListChangesGtk.py:53
msgid "Reading changelogs. Please wait."
msgstr 

Bug#1056771: braillefont command line options

[Carles Pina i Estany]

Package: braillefont
Version: 1.0-6
Severity: wishlist
Tags: upstream

Dear Maintainer,

With "braillefont --help" I expected to see some help, but it just waits
for the input text.

Related: "braillefont /etc/hosts" (or, just a file): I expected to read
the file and print it but just waits for the input text.

Perhaps upstream could implement it.

Thanks!

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_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 braillefont depends on:
ii  libc6  2.36-9+deb12u3

braillefont recommends no packages.

braillefont suggests no packages.

-- no debconf information

Bug#1056770: braillefont: Description in debian/control has a new line in the middle of a sentence

[Carles Pina i Estany]

Package: braillefont
Version: 1.0-6
Severity: minor

Dear Maintainer,

Doing:
apt show braillentfont

It shows:
-
Description: Prints a bitmapped version of a text using Unicode Braille symbols
 braillefont runs interactively on the console - one can enter a (short) text,
 that will be converted into a bitmapped version
 and printed using the Braille range of Unicode.
-

There is a new line after "version" that should not be there.

Thanks!

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_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 braillefont depends on:
ii  libc6  2.36-9+deb12u3

braillefont recommends no packages.

braillefont suggests no packages.

-- no debconf information

Bug#1056736: smartmontools: please do not force people to use update-smart-drivedb and install foreign code

[Paul Wise]

On Sat, 25 Nov 2023 18:56:03 +0100 Christoph Anton Mitterer wrote:

> The most recent upgrade forces people to use
> update-smart-drivedb by doing it already in the postinst and not leaving it
> up to the user whether he wants to use such a tool.
> 
> Security-wise this is really a bad idea.
> 
> Downloader packages (i.e. packages that install further code from
> outside Debian) - and this effectively just that - are generally questionable.

You have missed the documentation of the --install option that the
postinst uses, it just copies the file from /usr to /var when the
/usr file is newer than the /var file, it does not download any files.

Previously the postinst was always force copying from /usr to /var,
now it only does the copying when the /usr file is newer.

I suggest that this bug be closed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1056769: gcc-13: Remove references to obsolete dpkg m32r and tilegx arches

[Guillem Jover]

Source: gcc-13
Source-Version: 13.2.0-7
Severity: important
Tags: patch

Hi!

Support for these arches got removed in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architectures.

Attached an untested patch that removes references to these obsolete
arches.

Thanks,
Guillem
From 6a26179c55840f1bcd494b302cd3d213c4d85cfa Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 26 Nov 2023 00:16:51 +0100
Subject: [PATCH] Remove references to obsolete m32r and tilegx arches

Support for these arches got removed in dpkg 1.22.0, which means
that once the host running dak gets its dpkg upgraded to that version
it might start being unhappy about the unknown architectures.
---
 debian/control| 2 +-
 debian/rules.defs | 2 +-
 debian/rules2 | 4 
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index 9b89a24..0d63582 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends: debhelper (>= 9.20141010), dpkg-dev (>= 1.17.14), g++-multilib [a
   gperf (>= 3.0.1), bison (>= 1:2.3), flex, gettext, 
   gdb:native [!riscv64 !mipsel !mips64el], nvptx-tools [amd64 ppc64el], amdgcn-tools [amd64], 
   texinfo (>= 4.3), locales-all, sharutils, 
-  procps, gnat-12:native [!arc !ia64 !loong64 !m32r !sh3 !sh3eb !sh4eb], g++-12:native, netbase, gdc-12:native [!arc !ia64 !loong64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386 !hurd-alpha !kfreebsd-amd64 !kfreebsd-i386 !kfreebsd-alpha], python3:any, 
+  procps, gnat-12:native [!arc !ia64 !loong64 !sh3 !sh3eb !sh4eb], g++-12:native, netbase, gdc-12:native [!arc !ia64 !loong64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386 !hurd-alpha !kfreebsd-amd64 !kfreebsd-i386 !kfreebsd-alpha], python3:any, 
   libisl-dev (>= 0.20), libmpc-dev (>= 1.0), libmpfr-dev (>= 3.0.0-9~), libgmp-dev (>= 2:5.0.1~), lib32z1-dev [amd64 kfreebsd-amd64], lib64z1-dev [i386], unzip , 
   dejagnu , coreutils (>= 2.26) | realpath (>= 1.9.12), chrpath, lsb-release, quilt, time, 
   pkg-config, libgc-dev, 
diff --git a/debian/rules.defs b/debian/rules.defs
index 4e02bf5..768fc24 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -847,7 +847,7 @@ endif
 
 ifeq (,$(filter $(DEB_STAGE),stage1 stage2))
 # Ada 
-ada_no_cpus	:= arc ia64 loong64 m32r sh3 sh3eb sh4eb
+ada_no_cpus	:= arc ia64 loong64 sh3 sh3eb sh4eb
 ada_no_systems	:= 
 ada_no_cross	:= no
 ada_no_snap	:= no
diff --git a/debian/rules2 b/debian/rules2
index 59f8991..c83cede 100644
--- a/debian/rules2
+++ b/debian/rules2
@@ -563,10 +563,6 @@ ifneq (,$(findstring m68k-linux,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --disable-multilib
 endif
 
-ifneq (,$(filter tilegx,$(DEB_TARGET_GNU_CPU)))
-  CONFARGS += --disable-multilib
-endif
-
 ifneq (,$(findstring riscv64-linux,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --disable-multilib
   CONFARGS += --with-arch=rv64gc --with-abi=lp64d
-- 
2.42.0

Bug#1056768: gcc-12: Remove references to obsolete dpkg m32r and tilegx arches

[Guillem Jover]

Source: gcc-12
Source-Version: 12.3.0-11
Severity: important
Tags: patch

Hi!

Support for these arches got removed in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architectures.

Attached an untested patch that removes references to these obsolete
arches.

Thanks,
Guillem
From c3ce5e819640376b2728077257383bce9de6d55a Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 26 Nov 2023 00:16:51 +0100
Subject: [PATCH] Remove references to obsolete m32r and tilegx arches

Support for these arches got removed in dpkg 1.22.0, which means
that once the host running dak gets its dpkg upgraded to that version
it might start being unhappy about the unknown architectures.
---
 debian/control| 2 +-
 debian/rules.defs | 2 +-
 debian/rules2 | 4 
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index a9fb081..ba9fc88 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends: debhelper (>= 9.20141010), dpkg-dev (>= 1.17.14), g++-multilib [a
   gperf (>= 3.0.1), bison (>= 1:2.3), flex, gettext, 
   gdb:native [!riscv64 !mipsel !mips64el], nvptx-tools [amd64 ppc64el], amdgcn-tools [amd64], 
   texinfo (>= 4.3), locales-all, sharutils, 
-  procps, gnat-12:native [!arc !ia64 !loong64 !m32r !sh3 !sh3eb !sh4eb], g++-12:native, netbase, gdc-12:native [!arc !ia64 !loong64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386 !hurd-alpha !kfreebsd-amd64 !kfreebsd-i386 !kfreebsd-alpha], python3:any, 
+  procps, gnat-12:native [!arc !ia64 !loong64 !sh3 !sh3eb !sh4eb], g++-12:native, netbase, gdc-12:native [!arc !ia64 !loong64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386 !hurd-alpha !kfreebsd-amd64 !kfreebsd-i386 !kfreebsd-alpha], python3:any, 
   libisl-dev (>= 0.20), libmpc-dev (>= 1.0), libmpfr-dev (>= 3.0.0-9~), libgmp-dev (>= 2:5.0.1~), lib32z1-dev [amd64 kfreebsd-amd64], lib64z1-dev [i386], unzip , 
   dejagnu , coreutils (>= 2.26) | realpath (>= 1.9.12), chrpath, lsb-release, quilt, time, 
   pkg-config, libgc-dev, 
diff --git a/debian/rules.defs b/debian/rules.defs
index 6559414..9532bc5 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -847,7 +847,7 @@ endif
 
 ifeq (,$(filter $(DEB_STAGE),stage1 stage2))
 # Ada 
-ada_no_cpus	:= arc ia64 loong64 m32r sh3 sh3eb sh4eb
+ada_no_cpus	:= arc ia64 loong64 sh3 sh3eb sh4eb
 ada_no_systems	:= 
 ada_no_cross	:= no
 ada_no_snap	:= no
diff --git a/debian/rules2 b/debian/rules2
index c37e266..3aa408d 100644
--- a/debian/rules2
+++ b/debian/rules2
@@ -559,10 +559,6 @@ ifneq (,$(findstring m68k-linux,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --disable-multilib
 endif
 
-ifneq (,$(filter tilegx,$(DEB_TARGET_GNU_CPU)))
-  CONFARGS += --disable-multilib
-endif
-
 ifneq (,$(findstring riscv64-linux,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --disable-multilib
   CONFARGS += --with-arch=rv64gc --with-abi=lp64d
-- 
2.42.0

Bug#1056767: gcc-11: Remove references to obsolete dpkg m32r and tilegx arches

[Guillem Jover]

Source: gcc-11
Source-Version: 11.4.0-5
Severity: important
Tags: patch

Hi!

Support for these arches got removed in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architectures.

Attached an untested patch that removes references to these obsolete
arches.

Thanks,
Guillem
From 774a10b382999154a50710417e1721805fea0fd0 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 26 Nov 2023 00:16:51 +0100
Subject: [PATCH] Remove references to obsolete m32r and tilegx arches

Support for these arches got removed in dpkg 1.22.0, which means
that once the host running dak gets its dpkg upgraded to that version
it might start being unhappy about the unknown architectures.
---
 debian/control| 2 +-
 debian/rules.defs | 2 +-
 debian/rules2 | 4 
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index cc329cd..d751261 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends: debhelper (>= 9.20141010), dpkg-dev (>= 1.17.14), g++-multilib [a
   gperf (>= 3.0.1), bison (>= 1:2.3), flex, gettext, 
   gdb:native [!riscv64 !mipsel !mips64el], nvptx-tools [amd64 ppc64el], amdgcn-tools [amd64], 
   texinfo (>= 4.3), locales-all, sharutils, 
-  procps, gnat-11:native [!arc !ia64 !loong64 !m32r !sh3 !sh3eb !sh4eb !m68k], g++-11:native, netbase, python3:any, 
+  procps, gnat-11:native [!arc !ia64 !loong64 !sh3 !sh3eb !sh4eb !m68k], g++-11:native, netbase, python3:any, 
   libisl-dev (>= 0.20), libmpc-dev (>= 1.0), libmpfr-dev (>= 3.0.0-9~), libgmp-dev (>= 2:5.0.1~), lib32z1-dev [amd64 kfreebsd-amd64], lib64z1-dev [i386], unzip , 
   dejagnu  [!alpha !hurd-alpha] , coreutils (>= 2.26) | realpath (>= 1.9.12), chrpath, lsb-release, quilt, time, 
   pkg-config, libgc-dev, 
diff --git a/debian/rules.defs b/debian/rules.defs
index 494cfd1..4291a83 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -845,7 +845,7 @@ endif
 
 ifeq (,$(filter $(DEB_STAGE),stage1 stage2))
 # Ada 
-ada_no_cpus	:= arc ia64 loong64 m32r sh3 sh3eb sh4eb
+ada_no_cpus	:= arc ia64 loong64 sh3 sh3eb sh4eb
 ada_no_cpus	+= m68k   # https://gcc.gnu.org/PR98341
 ada_no_systems	:= 
 ada_no_cross	:= no
diff --git a/debian/rules2 b/debian/rules2
index 1a151c1..6b5f77a 100644
--- a/debian/rules2
+++ b/debian/rules2
@@ -545,10 +545,6 @@ ifneq (,$(findstring m68k-linux,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --disable-multilib
 endif
 
-ifneq (,$(filter tilegx,$(DEB_TARGET_GNU_CPU)))
-  CONFARGS += --disable-multilib
-endif
-
 ifneq (,$(findstring riscv64-linux,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --disable-multilib
   CONFARGS += --with-arch=rv64gc --with-abi=lp64d
-- 
2.42.0

Bug#1056766: gcc-10: Remove references to obsolete dpkg m32r and tilegx arches

[Guillem Jover]

Source: gcc-10
Source-Version: 10.5.0-2
Severity: important
Tags: patch

Hi!

Support for these arches got removed in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architectures.

Attached an untested patch that removes references to these obsolete
arches.

Thanks,
Guillem
From 7e46f4375d3aeb2a386edfd6b87c2c4f328016f6 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 26 Nov 2023 00:16:51 +0100
Subject: [PATCH] Remove references to obsolete m32r and tilegx arches

Support for these arches got removed in dpkg 1.22.0, which means
that once the host running dak gets its dpkg upgraded to that version
it might start being unhappy about the unknown architectures.
---
 debian/control| 2 +-
 debian/rules.defs | 2 +-
 debian/rules2 | 4 
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index 59c0109..d249777 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends: debhelper (>= 9.20141010), dpkg-dev (>= 1.17.14), g++-multilib [a
   gperf (>= 3.0.1), bison (>= 1:2.3), flex, gettext, 
   gdb:native [!riscv64], nvptx-tools [amd64 ppc64el], 
   texinfo (>= 4.3), locales-all, sharutils, 
-  procps, gnat-10:native [!m32r !sh3 !sh3eb !sh4eb], g++-10:native, netbase, python3:any, 
+  procps, gnat-10:native [!sh3 !sh3eb !sh4eb], g++-10:native, netbase, python3:any, 
   libisl-dev (>= 0.20), libmpc-dev (>= 1.0), libmpfr-dev (>= 3.0.0-9~), libgmp-dev (>= 2:5.0.1~), lib32z1-dev [amd64 kfreebsd-amd64], lib64z1-dev [i386], unzip , 
   dejagnu , coreutils (>= 2.26) | realpath (>= 1.9.12), chrpath, lsb-release, quilt, time, 
   pkg-config, libgc-dev, 
diff --git a/debian/rules.defs b/debian/rules.defs
index 88c1d4d..c4f92a9 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -848,7 +848,7 @@ endif
 
 ifeq (,$(filter $(DEB_STAGE),stage1 stage2))
 # Ada 
-ada_no_cpus	:= m32r sh3 sh3eb sh4eb
+ada_no_cpus	:= sh3 sh3eb sh4eb
 ada_no_systems	:= 
 ada_no_cross	:= no
 ada_no_snap	:= no
diff --git a/debian/rules2 b/debian/rules2
index e13fae2..2691b76 100644
--- a/debian/rules2
+++ b/debian/rules2
@@ -530,10 +530,6 @@ ifneq (,$(findstring m68k-linux,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --disable-multilib
 endif
 
-ifneq (,$(filter tilegx,$(DEB_TARGET_GNU_CPU)))
-  CONFARGS += --disable-multilib
-endif
-
 ifneq (,$(findstring riscv64-linux,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --disable-multilib
   CONFARGS += --with-arch=rv64imafdc --with-abi=lp64d
-- 
2.42.0

Bug#1056765: gcc-9: Remove references to obsolete dpkg m32r and tilegx arches

[Guillem Jover]

Source: gcc-9
Source-Version: 9.5.0-4
Severity: important
Tags: patch

Hi!

Support for these arches got removed in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architectures.

Attached an untested patch that removes references to these obsolete
arches.

Thanks,
Guillem
From 4374a74a6f4f48d2bdf59561a8dfbf751bc0d629 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 25 Nov 2023 23:44:48 +0100
Subject: [PATCH] Remove references to obsolete m32r and tilegx arches

Support for these arches got removed from in dpkg 1.22.0, which means
that once the host running dak gets its dpkg upgraded to that version
it might start being unhappy about the unknown architectures.
---
 debian/control| 2 +-
 debian/rules.defs | 2 +-
 debian/rules2 | 4 
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index ef2254d..12dec06 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends: debhelper (>= 9.20141010), dpkg-dev (>= 1.17.14), g++-multilib [a
   gperf (>= 3.0.1), bison (>= 1:2.3), flex, gettext, 
   gdb:native [!riscv64], nvptx-tools [amd64 ppc64el], 
   texinfo (>= 4.3), locales-all, sharutils, 
-  procps, gnat-9:native [!m32r !sh3 !sh3eb !sh4eb !m68k], g++-9:native, netbase, libpth-dev, python3:any, 
+  procps, gnat-9:native [!sh3 !sh3eb !sh4eb !m68k], g++-9:native, netbase, libpth-dev, python3:any, 
   libisl-dev (>= 0.20), libmpc-dev (>= 1.0), libmpfr-dev (>= 3.0.0-9~), libgmp-dev (>= 2:5.0.1~), lib32z1-dev [amd64 kfreebsd-amd64], lib64z1-dev [i386], 
   dejagnu [!m68k] , coreutils (>= 2.26) | realpath (>= 1.9.12), chrpath, lsb-release, quilt, 
   pkg-config, libgc-dev, 
diff --git a/debian/rules.defs b/debian/rules.defs
index c9689c4..2041d75 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -809,7 +809,7 @@ endif
 
 ifeq (,$(filter $(DEB_STAGE),stage1 stage2))
 # Ada 
-ada_no_cpus	:= m32r sh3 sh3eb sh4eb
+ada_no_cpus	:= sh3 sh3eb sh4eb
 # no Debian builds ... some of these should exist
 # ... cross-build-native cross-builds a non-working compiler ...
 ifneq (,$(filter $(build_type), build-native))
diff --git a/debian/rules2 b/debian/rules2
index 41b65ac..1389cc3 100644
--- a/debian/rules2
+++ b/debian/rules2
@@ -533,10 +533,6 @@ ifneq (,$(findstring m68k-linux,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --disable-multilib
 endif
 
-ifneq (,$(filter tilegx,$(DEB_TARGET_GNU_CPU)))
-  CONFARGS += --disable-multilib
-endif
-
 ifneq (,$(findstring riscv64-linux,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --disable-multilib
   CONFARGS += --with-arch=rv64imafdc --with-abi=lp64d
-- 
2.42.0

Bug#1042845: libembperl-perl: FTBFS with Perl 5.38: test failures

[gregor herrmann]

On Tue, 01 Aug 2023 22:41:12 +0200, Axel Beckert wrote:

> > I assume the diagnostics have changed again and it's just the tests that
> > need adjusting, but I haven't checked properly.
> Will look into it, but may take a while.

Now would be a good time :)

As the perl 5.38 transition is immanent, the bug's severity has been
raised to serious; and bot dam and me failed to understand the test
system so I guess this is now your turn :)


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1056757: ITP: solanum -- simple pomodoro time tracking app for GNOME

[Jeremy Bícha]

On Sat, Nov 25, 2023 at 5:51 PM David Bremner  wrote:
>
> Jeremy Bícha  writes:
> >
> > Package Name: solanum
> > Version: 5.0.0
> > Upstream Author: Christopher Davis
> > License: GPL-3+
> > Programming Lang: Rust
> >
> > Description: simple pomodoro time tracking app for GNOME
> >  Solanum is a time tracking app using the pomodoro technique.
> >  Work in four sessions, with breaks in between each session and
> >  one long break after all four.
>
> I note that solanum-ircd is a thing (although not yet in Debian).  I
> guess first come first serve for the name, but it does turn out to be
> surprisingly generic (at least a scan of github reveals several other
> projects with the same name).

Solanum is a GNOME Circle app so we could perhaps use gnome-solanum
for the source and binary package names . I don't think it's necessary
to rename /usr/bin/solanum though.

Repology also notes the name conflict and suggests "solanum-pomodoro";
however, it looks like no other distro has adopted the name
gnome-solanum or solanum-pomodoro. The AUR has at least used
solanum-ircd.

https://repology.org/project/solanum/versions

Thank you,
Jeremy Bícha

Bug#1056757: ITP: solanum -- simple pomodoro time tracking app for GNOME

[David Bremner]

Jeremy Bícha  writes:
>
> Package Name: solanum
> Version: 5.0.0
> Upstream Author: Christopher Davis
> License: GPL-3+
> Programming Lang: Rust
>
> Description: simple pomodoro time tracking app for GNOME
>  Solanum is a time tracking app using the pomodoro technique.
>  Work in four sessions, with breaks in between each session and
>  one long break after all four.

I note that solanum-ircd is a thing (although not yet in Debian).  I
guess first come first serve for the name, but it does turn out to be
surprisingly generic (at least a scan of github reveals several other
projects with the same name).

d

Bug#1050547: Similar stacktrace for this issue.

[Mark Bryars]

I've not been able to start gdm3 for quite a while now.

I've tried upgrading to the latest nvidia driver in experimental
(535.43.02-1) ,
and WaylandEnable=false in /etc/gdm3/daemon.conf

Swapping to the nouveau driver didn't seem to fix it, but then I removed
the WaylandEnable=false and it started to work. I sadly have reasons to use
the Nvidia drivers.


systemd-coredump[101602]: Process 101572 (gnome-shell) of user 112 dumped
core.

Module libzstd.so.1
from deb libzstd-1.5.5+dfsg2-2.amd64
Module libudev.so.1
from deb systemd-255~rc3-2.amd64
Module libsystemd.so.0
from deb systemd-255~rc3-2.amd64
Stack trace of thread
101572:
#0  0x7fa966eced34
meta_display_get_x11_display (libmutter-12.so.0 + 0xced34)
#1  0x7fa966ef9aeb
meta_cursor_sprite_xfixes_initable_init (libmutter-12.so.0 + 0xf9aeb)
#2  0x7fa9674923f3
g_initable_new_valist (libgio-2.0.so.0 + 0x7f3f3)
#3  0x7fa9674924dd
g_initable_new (libgio-2.0.so.0 + 0x7f4dd)
#4  0x7fa966ef9e8a
meta_cursor_sprite_xfixes_new (libmutter-12.so.0 + 0xf9e8a)
#5  0x7fa966efd69e
ensure_xfixes_cursor (libmutter-12.so.0 + 0xfd69e)
#6  0x7fa966efd6fd
meta_cursor_tracker_x11_get_sprite (libmutter-12.so.0 + 0xfd6fd)
#7  0x7fa966e8b05e
meta_cursor_tracker_get_sprite (libmutter-12.so.0 + 0x8b05e)
#8  0x7fa96706640e
ffi_call_unix64 (libffi.so.8 + 0x740e)
#9  0x7fa96706571d
ffi_call_int (libffi.so.8 + 0x671d)
#10 0x7fa967065ef3
ffi_call (libffi.so.8 + 0x6ef3)
#11 0x7fa9671d46c7
_ZN3Gjs8Function6invokeEP9JSContextRKN2JS8CallArgsENS3_6HandleIP8JSObjectEEP11_GIArgument
(libgjs.so.0 + 0x4c6c7)
#12 0x7fa9671d4f87
_ZN3Gjs8Function4callEP9JSContextjPN2JS5ValueE (libgjs.so.0 + 0x4cf87)
#13 0x7fa96437eb0e
_Z12CallJSNativeP9JSContextPFbS0_jPN2JS5ValueEEN2js10CallReasonERKNS1_8CallArgsE
(libmozjs-115.so.0 + 0x17eb0e)
#14 0x7fa964370860
InternalCall (libmozjs-115.so.0 + 0x170860)
#15 0x7fa96437e843
MaybeEnterInterpreterTrampoline (libmozjs-115.so.0 + 0x17e843)
#16 0x7fa964380c81
_ZN2js13ExecuteKernelEP9JSContextN2JS6HandleIP8JSScriptEENS3_IP8JSObjectEENS_16AbstractFramePtrENS2_13MutableHand
leINS2_5ValueEEE (libmozjs-115.so.0 + 0x180c81)
#17 0x7fa9643e013d
_ZN2js12ModuleObject7executeEP9JSContextN2JS6HandleIPS0_EE
(libmozjs-115.so.0 + 0x1e013d)
#18 0x7fa9644c1deb
InnerModuleEvaluation (libmozjs-115.so.0 + 0x2c1deb)
#19 0x7fa9644c21a3
_ZN2js14ModuleEvaluateEP9JSContextN2JS6HandleIPNS_12ModuleObjectEEENS2_13MutableHandleINS2_5ValueEEE
(libmozjs-11
5.so.0 + 0x2c21a3)
#20 0x7fa96720ae08
_ZN17GjsContextPrivate11eval_moduleEPKcPhPP7_GError (libgjs.so.0 + 0x82e08)
#21 0x7fa96720b2e2
gjs_context_eval_module (libgjs.so.0 + 0x832e2)
#22 0x7fa96720b401
gjs_context_eval_module_file (libgjs.so.0 + 0x83401)
#23 0x7fa96761f7c9
n/a (libshell-12.so + 0x1f7c9)
#24 0x7fa966eaf048
meta_compositor_do_manage (libmutter-12.so.0 + 0xaf048)
#25 0x7fa966ece606
meta_display_new (libmutter-12.so.0 + 0xce606)
#26 0x7fa966ed9f60
meta_context_start (libmutter-12.so.0 + 0xd9f60)
#27 0x55ed5de2298e
n/a (gnome-shell + 0x398e)
#28 0x7fa966c456ca
__libc_start_call_main (libc.so.6 + 0x276ca)
#29 0x7fa966c45785
__libc_start_main_impl (libc.so.6 + 0x27785)

Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12

[Nicolas Haller]

Package: grub-efi-amd64
Version: 2.06-13
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

My old laptop (Lenovo 11e) runs Sid and all was right before I updated
it the other day (I don't do that very often). After that upgrade, GRUB
wasn't able to load any kernel with the pretty much generic error
"Error: can't load image". The version of GRUB was 2.12~rc1-12.
If I try to boot again, GRUB tells me that I need to load the image
first (I guess it somehow ignores the linux command and sends that when
trying to load the initrd).

I tried to reinstall grub, grub-install /dev/sda, update-grub, reinstall
the kernel, update-initramfs from the rescue mode but nothing worked.
The "file" command was able to read the vmlinuz file and none seemed
truncated. The system has one partition with both / and /boot and isn't
running out of space.
I did not see any error message during those operation besides GRUB
saying it wasn't able to update EFI parameters.

I don't know if there is a way to get more logs or error message during
the boot explaining why it wasn't able to load the image.

I tried to get the last version of GRUB from Bookworm, that is
2.06-13, and now I'm able to boot. The kernel version did not change,
  the only change I did is to downgrade GRUB (and dependencies apt was
  asking for).

I'm not sure which GRUB package I should use for reporting so I took the
one that seems the most specific to my system. Apologies if it is not
correct.

Let me know if you need more info.

Thanks,

-- 
Nicolas Haller

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


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda2 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
7d9badd3-db30-4b48-901f-cedca15e9902
else
  search --no-floppy --fs-uuid --set=root 7d9badd3-db30-4b48-901f-cedca15e9902
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=C
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
7d9badd3-db30-4b48-901f-cedca15e9902
else
  search --no-floppy --fs-uuid --set=root 7d9badd3-db30-4b48-901f-cedca15e9902
fi
insmod png
if background_image /usr/share/desktop-base/emerald-theme/grub/grub-16x9.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=

Bug#1056763: gdb: Remove references to obsolete dpkg m32r arch

[Guillem Jover]

Source: gdb
Source-Version: 13.2-1
Severity: important
Tags: patch

Hi!

Support for this arch got removed in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architecture.

Attached an untested patch that removes references to this obsolete arch.

Thanks,
Guillem
From 579b5525be1fd188730b1bac888018629d0f2de7 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 25 Nov 2023 23:36:55 +0100
Subject: [PATCH] Remove references to obsolete m32r arch

Support for this arch got removed from in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architecture.
---
 debian/control| 2 +-
 debian/control.in | 2 +-
 debian/rules  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 99a445e0856..ee84545b5c1 100644
--- a/debian/control
+++ b/debian/control
@@ -83,7 +83,7 @@ Description: GNU Debugger (with support for multiple architectures)
  target architectures.
 
 Package: gdbserver
-Architecture: amd64 armel armhf arm64 i386 ia64 m32r m68k mips mipsel mips64el powerpc powerpcspe ppc64 ppc64el riscv64 s390 s390x x32
+Architecture: amd64 armel armhf arm64 i386 ia64 m68k mips mipsel mips64el powerpc powerpcspe ppc64 ppc64el riscv64 s390 s390x x32
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Replaces: gdb (<< 7.0.1-1)
 Description: GNU Debugger (remote server)
diff --git a/debian/control.in b/debian/control.in
index 001358a3ad0..7a1a494f293 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -83,7 +83,7 @@ Description: GNU Debugger (with support for multiple architectures)
  target architectures.
 
 Package: gdbserver
-Architecture: amd64 armel armhf arm64 i386 ia64 m32r m68k mips mipsel mips64el powerpc powerpcspe ppc64 ppc64el riscv64 s390 s390x x32
+Architecture: amd64 armel armhf arm64 i386 ia64 m68k mips mipsel mips64el powerpc powerpcspe ppc64 ppc64el riscv64 s390 s390x x32
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Replaces: gdb (<< 7.0.1-1)
 Description: GNU Debugger (remote server)
diff --git a/debian/rules b/debian/rules
index 27b3f9d0e1b..1c0a55fa447 100755
--- a/debian/rules
+++ b/debian/rules
@@ -190,7 +190,7 @@ MULTIARCH_TARGETS := \
 	sparc64-linux-gnu \
 	x86_64-linux-gnu \
 	x86_64-linux-gnux32 \
-	m32r-linux-gnu
+	# EOL
 
 # broken, see https://launchpad.net/bugs/1233185
 #MULTIARCH_TARGETS := all
-- 
2.42.0

Bug#1056762: RFS: srcpd/2.1.6-1 [ITP] -- SRCP server daemon to control digital model railroads

[Hilmar Preusse]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : srcpd
   Version  : 2.1.6-1
   Upstream contact : Guido Scholz 
 * URL  : https://srcpd.sourceforge.net/srcpd/index.html
 * License  : GPL-2+, GPL-2, MIT/X11
 * Vcs  : https://salsa.debian.org/hilmar-guest/srcpd
   Section  : electronics

The source builds the following binary packages:

  srcpd - SRCP server daemon to control digital model railroads

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/s/srcpd/srcpd_2.1.6-1.dsc

Changes for the initial release:

 srcpd (2.1.6-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1032354)

Regards,
--
  Hilmar Preusse


signature.asc
Description: PGP signature

Bug#1053700: xarray test failure on s390x

[Rebecca N. Palmer]

This fix worked but the new upstream version added another similar 
issue, so s390x failed again.


I have pushed a fix for this, and enabled allow-stderr to fix armel 
(error output from an already-xfailed test).  I don't know what's 
causing the hang on arm64, so please do _not_ upload this just yet.

Bug#1056761: python3.12: Remove references to obsolete dpkg avr32 arch

[Guillem Jover]

Source: python3.12
Source-Version: 3.12.0-5
Severity: important
Tags: patch

Hi!

Support for this arch got removed from in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architecture.

Attached a patch that removes references to this obsolete arch.

Thanks,
Guillem
From 9285d636afb9de383345fb5457c4ff17bbfe8ea4 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 25 Nov 2023 23:08:52 +0100
Subject: [PATCH] Remove references to obsolete avr32 arch

Support for this arch got removed from in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architecture.
---
 debian/control| 2 +-
 debian/control.in | 2 +-
 debian/rules  | 8 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index 165856c..1c54f45 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.17.11),
   libexpat1-dev,
   libbluetooth-dev [linux-any] ,
   locales-all,
-  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k !avr32],
+  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k],
   libgpm2 [linux-any],
   media-types | mime-support, netbase, bzip2, time, python3:any, python3.12:any ,
   net-tools, xvfb , xauth , tzdata ,
diff --git a/debian/control.in b/debian/control.in
index 692cdbf..d118553 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -13,7 +13,7 @@ Build-Depends: debhelper (>= 11), @bd_dpkgdev@
   libexpat1-dev,
   libbluetooth-dev [linux-any] ,
   locales-all,
-  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k !avr32],
+  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k],
   libgpm2 [linux-any],
   media-types | mime-support, netbase, bzip2, time, python3@bd_qual@, @PVER@@bd_qual@ ,
   net-tools, xvfb , xauth , tzdata ,
diff --git a/debian/rules b/debian/rules
index 550898a..791bce8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -444,7 +444,7 @@ common_configure_args = \
 #common_configure_args += \
 #		--without-builtin-hashlib-hashes
 
-ifneq (,$(filter $(DEB_HOST_ARCH), avr32 or1k))
+ifneq (,$(filter $(DEB_HOST_ARCH), or1k))
   common_configure_args += --without-ffi
 else
   common_configure_args += --with-system-ffi
@@ -601,11 +601,11 @@ endif
 ifneq (,$(filter $(DEB_HOST_ARCH),arm64))
   TEST_EXCLUDES += test_faulthandler
 endif
-ifneq (,$(filter $(DEB_HOST_ARCH), arm avr32))
+ifneq (,$(filter $(DEB_HOST_ARCH), arm))
   TEST_EXCLUDES += test_ctypes
 endif
 TEST_EXCLUDES += test_socket
-ifneq (,$(filter $(DEB_HOST_ARCH), arm armel avr32 m68k))
+ifneq (,$(filter $(DEB_HOST_ARCH), arm armel m68k))
   ifeq ($(on_buildd),yes)
 TEST_EXCLUDES += test_compiler
   endif
@@ -720,7 +720,7 @@ endif
 stamps/stamp-pybench:
 	echo "pybench run disabled for this build" > $(buildd_static)/pybench.log
 
-#ifeq (,$(filter $(DEB_HOST_ARCH), arm armel avr32 hppa mips mipsel mips64 mips64el m68k))
+#ifeq (,$(filter $(DEB_HOST_ARCH), arm armel hppa mips mipsel mips64 mips64el m68k))
   pybench_options = -C 2 -n 5 -w 4
 #endif
 
-- 
2.42.0

Bug#1056760: python3.11: Remove references to obsolete dpkg avr32 arch

[Guillem Jover]

Source: python3.11
Source-Version: 3.11.6-3
Severity: important
Tags: patch

Hi!

Support for this arch got removed from in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architecture.

Attached a patch that removes references to this obsolete arch.

Thanks,
Guillem
From 3f971478072c67ae6a0009edf5b7cad90c4cd4d9 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 25 Nov 2023 23:08:52 +0100
Subject: [PATCH] Remove references to obsolete avr32 arch

Support for this arch got removed from in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architecture.
---
 debian/control| 2 +-
 debian/control.in | 2 +-
 debian/rules  | 8 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index f9486a9..af4e74c 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.17.11),
   libexpat1-dev,
   libbluetooth-dev [linux-any] ,
   locales-all,
-  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k !avr32],
+  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k],
   libgpm2 [linux-any],
   media-types | mime-support, netbase, bzip2, time, python3:any, python3.11:any ,
   net-tools, xvfb , xauth , tzdata ,
diff --git a/debian/control.in b/debian/control.in
index 844c2af..c0e0c01 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -12,7 +12,7 @@ Build-Depends: debhelper (>= 11), @bd_dpkgdev@
   libexpat1-dev,
   libbluetooth-dev [linux-any] ,
   locales-all,
-  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k !avr32],
+  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k],
   libgpm2 [linux-any],
   media-types | mime-support, netbase, bzip2, time, python3@bd_qual@, @PVER@@bd_qual@ ,
   net-tools, xvfb , xauth , tzdata ,
diff --git a/debian/rules b/debian/rules
index 7b12479..492acd8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -440,7 +440,7 @@ common_configure_args = \
 		--with-ssl-default-suites=openssl \
 		MKDIR_P="/bin/mkdir -p" \
 
-ifneq (,$(filter $(DEB_HOST_ARCH), avr32 or1k))
+ifneq (,$(filter $(DEB_HOST_ARCH), or1k))
   common_configure_args += --without-ffi
 else
   common_configure_args += --with-system-ffi
@@ -597,11 +597,11 @@ endif
 ifneq (,$(filter $(DEB_HOST_ARCH),arm64))
   TEST_EXCLUDES += test_faulthandler
 endif
-ifneq (,$(filter $(DEB_HOST_ARCH), arm avr32))
+ifneq (,$(filter $(DEB_HOST_ARCH), arm))
   TEST_EXCLUDES += test_ctypes
 endif
 TEST_EXCLUDES += test_socket
-ifneq (,$(filter $(DEB_HOST_ARCH), arm armel avr32 m68k))
+ifneq (,$(filter $(DEB_HOST_ARCH), arm armel m68k))
   ifeq ($(on_buildd),yes)
 TEST_EXCLUDES += test_compiler
   endif
@@ -716,7 +716,7 @@ endif
 stamps/stamp-pybench:
 	echo "pybench run disabled for this build" > $(buildd_static)/pybench.log
 
-#ifeq (,$(filter $(DEB_HOST_ARCH), arm armel avr32 hppa mips mipsel mips64 mips64el m68k))
+#ifeq (,$(filter $(DEB_HOST_ARCH), arm armel hppa mips mipsel mips64 mips64el m68k))
   pybench_options = -C 2 -n 5 -w 4
 #endif
 
-- 
2.42.0

Bug#1056759: python3.10: Remove references to obsolete dpkg avr32 arch

[Guillem Jover]

Source: python3.10
Source-Version: 3.10.11-1
Severity: important
Tags: patch

Hi!

Support for this arch got removed from in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architecture.

Attached a patch that removes references to this obsolete arch.

Thanks,
Guillem
From 319681ede4f39f2ca520ccc878853809b5aa94a0 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 25 Nov 2023 23:08:52 +0100
Subject: [PATCH] Remove references to obsolete avr32 arch

Support for this arch got removed from in dpkg 1.22.0, which means that
once the host running dak gets its dpkg upgraded to that version it
might start being unhappy about the unknown architecture.
---
 debian/control| 2 +-
 debian/control.in | 2 +-
 debian/rules  | 8 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index b91c7c3..b2a8581 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.17.11),
   libexpat1-dev, libmpdec-dev (>= 2.5.1~),
   libbluetooth-dev [linux-any] ,
   locales-all,
-  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k !avr32],
+  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k],
   libgpm2 [linux-any],
   media-types | mime-support, netbase, bzip2, time, python3:any, python3.10:any ,
   net-tools, xvfb , xauth ,
diff --git a/debian/control.in b/debian/control.in
index 80cb526..336d117 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -12,7 +12,7 @@ Build-Depends: debhelper (>= 11), @bd_dpkgdev@
   libexpat1-dev, libmpdec-dev (>= 2.5.1~),
   libbluetooth-dev [linux-any] ,
   locales-all,
-  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k !avr32],
+  libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k],
   libgpm2 [linux-any],
   media-types | mime-support, netbase, bzip2, time, python3@bd_qual@, @PVER@@bd_qual@ ,
   net-tools, xvfb , xauth ,
diff --git a/debian/rules b/debian/rules
index f281d84..d5ceec8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -436,7 +436,7 @@ common_configure_args = \
 		--with-wheel-pkg-dir=/usr/share/python-wheels/ \
 		MKDIR_P="/bin/mkdir -p" \
 
-ifneq (,$(filter $(DEB_HOST_ARCH), avr32 or1k))
+ifneq (,$(filter $(DEB_HOST_ARCH), or1k))
   common_configure_args += --without-ffi
 else
   common_configure_args += --with-system-ffi
@@ -592,11 +592,11 @@ endif
 ifneq (,$(filter $(DEB_HOST_ARCH),arm64))
   TEST_EXCLUDES += test_faulthandler
 endif
-ifneq (,$(filter $(DEB_HOST_ARCH), arm avr32))
+ifneq (,$(filter $(DEB_HOST_ARCH), arm))
   TEST_EXCLUDES += test_ctypes
 endif
 TEST_EXCLUDES += test_socket
-ifneq (,$(filter $(DEB_HOST_ARCH), arm armel avr32 m68k))
+ifneq (,$(filter $(DEB_HOST_ARCH), arm armel m68k))
   ifeq ($(on_buildd),yes)
 TEST_EXCLUDES += test_compiler
   endif
@@ -711,7 +711,7 @@ endif
 stamps/stamp-pybench:
 	echo "pybench run disabled for this build" > $(buildd_static)/pybench.log
 
-#ifeq (,$(filter $(DEB_HOST_ARCH), arm armel avr32 hppa mips mipsel mips64 mips64el m68k))
+#ifeq (,$(filter $(DEB_HOST_ARCH), arm armel hppa mips mipsel mips64 mips64el m68k))
   pybench_options = -C 2 -n 5 -w 4
 #endif
 
-- 
2.42.0

Bug#1056758: Removal notice: obsolete

[Ilias Tsitsimpis]

Source: haskell-reform-hsp
Version: 0.2.7.2-2
Severity: serious

I intend to remove this package:

  * It has no rev dependencies
  * The current version FTBFS
  * Seems unmaintained; Last upload more than 3 years ago
  * It's not part of the latest Stackage LTS

If you believe we should keep this package in Debian, please close this
bug report.

-- 
Ilias

Bug#1056757: ITP: solanum -- simple pomodoro time tracking app for GNOME

[Jeremy Bícha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org
Control: affects -1 src:solanum
Owner: jeremy.bi...@canonical.com

Package Name: solanum
Version: 5.0.0
Upstream Author: Christopher Davis
License: GPL-3+
Programming Lang: Rust

Description: simple pomodoro time tracking app for GNOME
 Solanum is a time tracking app using the pomodoro technique.
 Work in four sessions, with breaks in between each session and
 one long break after all four.

Other Info
--
This package will be maintained by the Debian GNOME team. Packaging is at
https://salsa.debian.org/gnome-team/solanum

Thanks,
Jeremy Bícha

Bug#1056756: RM: haskell-aeson-compat -- ROM; deprecated

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: haskell-aeson-com...@packages.debian.org
Control: affects -1 + src:haskell-aeson-compat

Please remove haskell-aeson-compat from Debian.

  * It has no rev dependencies
  * The current version FTBFS
  * Deprecated in favor of haskell-aeson

Thanks,

-- 
Ilias

Bug#1056755: derby: CVE-2022-46337

[Salvatore Bonaccorso]

Source: derby
Version: 10.14.2.0-2
Severity: important
Tags: security upstream
Forwarded: https://issues.apache.org/jira/browse/DERBY-7147
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for derby.

CVE-2022-46337[0]:
| A cleverly devised username might bypass LDAP authentication checks.
| In  LDAP-authenticated Derby installations, this could let an
| attacker fill  up the disk by creating junk Derby databases. In
| LDAP-authenticated  Derby installations, this could also allow the
| attacker to execute  malware which was visible to and executable by
| the account which booted  the Derby server. In LDAP-protected
| databases which weren't also  protected by SQL GRANT/REVOKE
| authorization, this vulnerability could  also let an attacker view
| and corrupt sensitive data and run sensitive  database functions and
| procedures.  Mitigation:  Users should upgrade to Java 21 and Derby
| 10.17.1.0.  Alternatively, users who wish to remain on older Java
| versions should  build their own Derby distribution from one of the
| release families to  which the fix was backported: 10.16, 10.15, and
| 10.14. Those are the  releases which correspond, respectively, with
| Java LTS versions 17, 11,  and 8.


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-2022-46337
https://www.cve.org/CVERecord?id=CVE-2022-46337
[1] https://issues.apache.org/jira/browse/DERBY-7147

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[Pascal Hambourg]

On 25/11/2023 at 22:29, David Hillman wrote:

On 11/25/23 01:37, Cyril Brulebois wrote:

Extracting /var/log/syslog would be useful to understand what's going on
there. (...)

Thanks Cyril.  This system is running Debian 12, so there is no 
/var/log/syslog.


Cyril meant the installer syslog, which is saved in /var/log/installer 
on the installed system at the end of the installation.


(Gmail will probably reject this mail though)

Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[Cyril Brulebois]

David Hillman  (2023-11-25):
> Thanks Cyril.  This system is running Debian 12, so there is no
> /var/log/syslog.  As I mentioned in the original report, I found nothing
> apparently related in the Journal.

I'm confused. You filed an installation report regarding a failure to
recognize network cards. I'm therefore assuming you're having issues
with the installation process, and requesting /var/log/syslog, which is
definitely where the installer logs what's going on. You also marked the
overall install with E = Error…

It'd make sense to clarify whether the problem affects the installer,
and/or the installed system.

Anyway, a copy of installer logs is available under /var/log/installer/
in the installed system.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1056754: bouncycastle: CVE-2023-33202

[Salvatore Bonaccorso]

Source: bouncycastle
Version: 1.72-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for bouncycastle.

CVE-2023-33202[0]:
| Bouncy Castle for Java before 1.73 contains a potential Denial of
| Service (DoS) issue within the Bouncy Castle
| org.bouncycastle.openssl.PEMParser class. This class parses OpenSSL
| PEM encoded streams containing X.509 certificates, PKCS8 encoded
| keys, and PKCS7 objects. Parsing a file that has crafted ASN.1 data
| through the PEMParser causes an OutOfMemoryError, which can enable a
| denial of service attack.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-33202
https://www.cve.org/CVERecord?id=CVE-2023-33202
[1] https://github.com/bcgit/bc-java/wiki/CVE-2023-33202

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1056753: RFS: nihstro/0-20231121-1 [ITP] -- 3DS shader tools - development headers

[David James]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : nihstro
   Version  : 0-20231121-1
   Upstream contact : https://neobrain.github.io/
 * URL  : 
https://github.com/neobrain/nihstro/tree/fd69de1a1b960ec296cc67d32257b0f9e2d89ac6
 * License  : BSD-3-clause
 * Vcs  : https://salsa.debian.org/Castor216/nihstro
   Section  : devel

The source builds the following binary packages:

  nihstro-tools - 3DS shader tools
  nihstro-headers - 3DS shader tools - development headers

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nihstro/nihstro_0-20231121-1.dsc

Changes for the initial release:

 nihstro (0-20231121-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1056551)

Regards,
--
  David James

Sent with [Proton Mail](https://proton.me/) secure email.

Bug#1056752: zfs-linux: CVE-2023-49298

[Salvatore Bonaccorso]

Source: zfs-linux
Version: 2.1.13-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/openzfs/zfs/issues/15526
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for zfs-linux.

CVE-2023-49298[0]:
| OpenZFS through 2.1.13 and 2.2.x through 2.2.1, in certain scenarios
| involving applications that try to rely on efficient copying of file
| data, can replace file contents with zero-valued bytes and thus
| potentially disable security mechanisms. NOTE: this issue is not
| always security related, but can be security related in realistic
| situations. A possible example is cp, from a recent GNU Core
| Utilities (coreutils) version, when attempting to preserve a rule
| set for denying unauthorized access. (One might use cp when
| configuring access control, such as with the /etc/hosts.deny file
| specified in the IBM Support reference.) NOTE: this issue occurs
| less often in version 2.2.1, and in versions before 2.1.4, because
| of the default configuration in those versions.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-49298
https://www.cve.org/CVERecord?id=CVE-2023-49298
[1] https://github.com/openzfs/zfs/issues/15526
[2] https://github.com/openzfs/zfs/pull/15571

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1056751: tiff: CVE-2023-6277

[Salvatore Bonaccorso]

Source: tiff
Version: 4.5.1+git230720-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.com/libtiff/libtiff/-/issues/614
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for tiff.

CVE-2023-6277[0]:
| An out-of-memory flaw was found in libtiff. Passing a crafted tiff
| file to TIFFOpen() API may allow a remote attacker to cause a denial
| of service via a craft input with size smaller than 379 KB.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-6277
https://www.cve.org/CVERecord?id=CVE-2023-6277
[1] https://gitlab.com/libtiff/libtiff/-/issues/614
[2] 
https://gitlab.com/libtiff/libtiff/-/commit/5320c9d89c054fa805d037d84c57da874470b01a

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[David Hillman]

On 11/25/23 01:37, Cyril Brulebois wrote:

Extracting /var/log/syslog would be useful to understand what's going on
there. A very quick search suggests this card might be supported by the
tg3 module (drivers/net/ethernet/broadcom/tg3.c), which is definitely
shipped in the installer. So maybe it's something that needs tweaking or
fixing on the firmware side (e.g. “modprobe dance”), or a missing
auxiliary bus (e.g. mhi) to make the card visible. Hard to tell without
any logs.

Thanks Cyril.  This system is running Debian 12, so there is no 
/var/log/syslog.  As I mentioned in the original report, I found nothing 
apparently related in the Journal.



--
David Hillman

Bug#1053089: Source of issue identified

[VastOne]

A user on the VSIDO forum identified the problem as that lxdm 5.3-5 only
supports the Industrial theme. Changing to Industrial them brings back the
login but using any other theme causes failure to show a gretter login menu

-- 
Thank you,

VastOne
V-Ger VSIDO Developer

Bug#1056731: RFS: backintime/1.4.1-0.1 [NMU] -- simple backup/snapshot system (graphical interface)

[Fabio Fantoni]

Il 25/11/2023 20:52, Tobias Frost ha scritto:

Hi Fabio,

Am Sat, Nov 25, 2023 at 07:33:32PM +0100 schrieb Fabio Fantoni:

Il 25/11/2023 18:10, Tobias Frost ha scritto:

This seems a bit ouf of scope for an NMU (new upstream releases are
NMUed only in exceptional cases) and #998105 is severity normal and
#973760 is severity minor. (Please see the developers reference about
NMUs.

Do you have additional information why this should be an NMU?
I'm seeing you are member of the repo, should your name be added as
Uploaders and this be a regular upload?
Did you reach out to the maintainers and get an ACK from them?


Hi, thanks for reply. I recently did some help on this package because I use
it, so when I see cases with issue and/or new upstream version (with useful
things) where a lot of time passes I try to help if I have time.

even if #998105 is only set "normal" is "a regression" that make users that
backup over ssh waste time to found the workaround, I tried also to be fixed
for bookworm (before release) with a upload with only this fix 
(https://salsa.debian.org/jmw/pkg-backintime/-/commit/0066cffd98aa09c5528cb94abedda5a1a5e59e3e)
but was rejected by the maintainer, then he replied to me who just wanted to
wait for the bookworm release and have additional things before making a new
upload. so I gave up and waited until after the new upstream version came
out (and I still waited another month before doing anything)

It seems that commit was done during or just before the hard-freeze, and thus 
not
acceptable as per release policy.

The problem's severiy "normal" seems to be appropiate, too.


Although it is not such a long time or with such serious bugs from the
general point of view of debian, some upstream developers and users have
come to consider this package as abandoned, here is an example:
https://bugs.launchpad.net/ubuntu/+source/backintime/+bug/2039271 (anyway
In that case it would not have been possible to upload the new upstream
version anyway as that Ubuntu version was in freeze)

(Ubuntu != Debian.)
And as you say on the launchpad bug, 4 uploads a year well means this package
is maintained.


I would prefer a normal upload (from the maintainer), already prepared and
tested, it also saves time, but unfortunately as I wrote at the moment I
have not received any response and I had only been given permission for the
repository previously where I already started to prepare for new upload one
month ago. I also write to upload with delay for give another possibility to
the maintainer, if he will have time

regarding the maintainers list I think it would be good to have it in the
debian python team but doing this or possibly adding me as co-maintainer is
a choice of the current maintainer. however I can't guarantee that I would
have enough time to follow it and make quick enough uploads when needed in
the long term.

If the maintainer responds to me in the future I will ask if he wants do
something.

thanks for your explanations. Unfortunatly, I fear that your NMU is outside of
the scope of NMUs, despite the good intentions you have.

NMUing a new upstream version is only appropiate under certain conditions. For
example it is preferred to have dedicated patches to fix problems (but not
during a freeze, of course)

So if you come up with dedicated fixes, this NMU can go forward, otherwise, I
fear, not, unless the maintainer actively acked. (There is also no bug that
expressed the intention that you are going to NMU on the package's BTS)

Other option would be to invoke the ITS process, but I'm not sure (as in I did
not check in depth),whether the package would be eligble. Of course, you will
have to commit to the maintainance of the package then.
(But a NMU does also, albeit not to the same extend.)

thanks for reply, don't seems needed ITS for now, the maintainer is 
active (https://salsa.debian.org/jmw), probably only have few time and 
some periods where he doesn't even can't reply to mail


I'll wait a little longer for now




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056750: u-boot: Remove reference to obsolete avr32 arch

[Guillem Jover]

Source: u-boot
Source-Version: 2023.07+dfsg-1
Severity: important
Tags: patch

Hi!

The avr32 arch support was removed in dpkg 1.22.0, and once the host
running dak upgrades its dpkg to that version, the archive software
might get unhappy about unknown arch references.

The attached patch remove these references.

Thanks,
Guillem
From 9292d37f89e2c56e1fc205947c72dc3518b97ead Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 25 Nov 2023 21:34:12 +0100
Subject: [PATCH] Remove avr32 arch support removed in dpkg 1.22.0

The avr32 arch support was removed in dpkg 1.22.0, and once the host
running dak upgrades its dpkg to that version, the archive software
might get unhappy about unknown arch references.
---
 debian/control| 2 +-
 debian/targets.mk | 7 ---
 2 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/debian/control b/debian/control
index cb41a8f7f4..7c5e9fcffa 100644
--- a/debian/control
+++ b/debian/control
@@ -45,7 +45,7 @@ Vcs-Browser: https://salsa.debian.org/debian/u-boot
 Vcs-Git: https://salsa.debian.org/debian/u-boot.git
 
 Package: u-boot
-Architecture: armel avr32 sh4
+Architecture: armel sh4
 Multi-Arch: same
 Depends: ${misc:Depends},
 Description: A boot loader for embedded systems
diff --git a/debian/targets.mk b/debian/targets.mk
index e0d1ba7560..bc48e5ea31 100644
--- a/debian/targets.mk
+++ b/debian/targets.mk
@@ -527,13 +527,6 @@ else ifeq (${DEB_HOST_ARCH},armhf)
   u-boot-tegra_platforms += jetson-tk1
   jetson-tk1_targets := u-boot-tegra.bin uboot.elf
 
-else ifeq (${DEB_HOST_ARCH},avr32)
-
-# u-boot
-
-  u-boot_platforms += hammerhead
-  hammerhead_targets := u-boot.img uboot.elf
-
 else ifeq (${DEB_HOST_ARCH},riscv64)
 
 # u-boot-sifive
-- 
2.42.0

Bug#1056749: Program in disorder! (Saving and reloading may fix this problem.)

[Alma Madeleine]

Package: nethack-x11
Version: 3.6.6-3+b2

Start xnethack from an xterm in Gnome on Xorg. Observe “Warning: Cannot 
convert string "nh10" to type FontStruct” printed to the console. In the 
nethack window, choose your character (say, human, samurai, male, 
lawful), and click “Play”. Close the greeting text window. Press 
"Shift+O" for options. Observer a bunch of error messages in the 
information pane:

“
Program in disorder!  (Saving and reloading may fix this problem.)
XrmGetResourceError (nethack.map.)
”
where  ∈ {green, blue, magenta, cyan, orange, …}

Saving and reloading does NOT fix the problem.

I'd be happy if I could kindly ask for a bugfix.

Gratefully,
Alma

Bug#1056748: mariadb: References obsolete tilegx architecture

[Guillem Jover]

Source: mariadb
Source-Version: 1:10.11.5-3
Severity: important
Tags: patch

Hi!

The debian/control file refers to the tilegx architecture which has
been removed from dpkg 1.22.0. This might cause issues in the future
once the host running dak gets upgraded to that dpkg version, where
the archive software might be unhappy about the unknown architecture.

Attached patch remove the reference.

Thanks,
Guillem
From 44cda54868242e842000162e3ab21a621f97b94f Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 25 Nov 2023 21:23:41 +0100
Subject: [PATCH] Remove tilegx support removed from dpkg 1.22.0

The definition for this arch was removed in dpkg 1.22.0, and once the
host running dak gets updated to that dpkg version, the archive software
might be unhappy about the unknown architecture.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 19a16b3ae5b..58afcb46335 100644
--- a/debian/control
+++ b/debian/control
@@ -638,7 +638,7 @@ Description: OQGraph storage engine for MariaDB server
  This package contains the OQGraph plugin for MariaDB server.
 
 Package: mariadb-plugin-mroonga
-Architecture: any-alpha any-amd64 any-arm any-arm64 any-i386 any-ia64 any-mips64el any-mips64r6el any-mipsel any-mipsr6el any-nios2 any-powerpcel any-ppc64el any-sh3 any-sh4 any-tilegx
+Architecture: any-alpha any-amd64 any-arm any-arm64 any-i386 any-ia64 any-mips64el any-mips64r6el any-mipsel any-mipsr6el any-nios2 any-powerpcel any-ppc64el any-sh3 any-sh4
 Depends: mariadb-server (= ${server:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
-- 
2.42.0

Bug#1056021: Link update

[Antonio Valentino]

On Thu, 16 Nov 2023 22:51:11 +0100 (CET) gl...@debian.org wrote:

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/pysolid_0.3.1-1_unstable_boost181.log

Thanks

Anton


Sorry Anton, I'm not able to reproduce.
Moreover I have to say that pysolid does not depend directly on boost.
The only compiled code is a fortran file and the relative python 
extension generated automatically with f2py.


Finally the log that you linked reports a successful build.

Can we close this issue?

kind regards
--
Antonio Valentino

Bug#1056747: libtomcat9-java: Tomcat 9.0.70 regression #66388 breaks applications like Xwiki

[Apache Tomcat]

Package: libtomcat9-java
Version: 9.0.70-2
Severity: important

Dear Maintainer,

Tomcat 9.0.70 suffers from a regression (not occuring in Tomcat 9.0.69 and 
fixed again in 9.0.71) which causes
issues with (or entirely breaks) applications loading files with spaces in 
their name:

https://bz.apache.org/bugzilla/show_bug.cgi?id=66388

This e.g. also leads to problems in the Xwiki application: 
https://jira.xwiki.org/browse/XWIKI-20470

Backporting the relevant fix to "unbreak" these applications in Bookworm would 
be great.




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

Kernel: Linux 6.1.0-13-amd64 (SMP w/6 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 libtomcat9-java depends on:
ii  libeclipse-jdt-core-java  3.32.0+eclipse4.26-2

libtomcat9-java recommends no packages.

Versions of packages libtomcat9-java suggests:
ii  tomcat9  9.0.43-2~deb11u9

-- no debconf information

Bug#1056746: perl: CVE-2023-47038: Write past buffer end via illegal user-defined Unicode property

[Niko Tyni]

Package: perl
Version: 5.30.0-1
Severity: important
Tags: security patch fixed-upstream bullseye bookworm trixie
X-Debbugs-Cc: t...@security.debian.org

Perl upstream released 5.34.2, 5.36.2 and 5.38.1 today with coordinated
fixes for two security issues. One of these (CVE-2023-47039) is specific
to Windows, but the other one (CVE-2023-47038) concerns us.

We discussed this earlier with Salvatore from the security team and
decided that CVE-2023-47038 is non-DSA like other "crafted regular
expression crashes" we've handled in the past. It will hence be fixed
via point releases for stable and oldstable.

CVE-2023-47038 - Write past buffer end via illegal user-defined Unicode property

A test case is

  perl -e 'qr/\p{utf8::_perl_surrogate}/'

which crashes on oldstable (bullseye, 5.32), stable (bookworm, 5.36),
unstable / testing (5.36) and experimental (5.38).

The issue was introduced in the 5.30 cycle, so LTS (buster, 5.28) is
not affected.

The upstream fixes are at

  5.34 
https://github.com/Perl/perl5/commit/12c313ce49b36160a7ca2e9b07ad5bd92ee4a010
  5.36 
https://github.com/Perl/perl5/commit/7047915eef37fccd93e7cd985c29fe6be54650b6
  5.38 
https://github.com/Perl/perl5/commit/92a9eb3d0d52ec7655c1beb2a5a5219be664

The 5.34 fix applies to 5.32 as well.

I'll start with sid/trixie and handle the *stable updates after that,
mainly targeting next bookworm point update on 2023-12-09 as per

  https://lists.debian.org/debian-project/2023/11/msg3.html

For experimental/5.38, I intend to push 5.38.1 instead of cherry
picking the patch.
-- 
Niko Tyni   nt...@debian.org

Bug#1056745: smartmontools: Hurd portability and dpkg arch fixes

[Guillem Jover]

Source: smartmontools
Source-Version: 7.3-1
Severity: important
Tags: patch

Hi!

This package fails to build on the Hurd, and includes in its build
dependencies some now obsolete architectures that got recently
removed from dpkg and which might cause archive issues once the
host running dak gets upgraded to that dpkg version.

Attached a pair of patches fixing these. Test built on hurd-i386.

Thanks,
Guillem
From 16b6f07ebf31662309bdcbf83d9b4681c1a99928 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Fri, 24 Nov 2023 02:06:57 +0100
Subject: [PATCH 1/2] Do not use libsystemd on non-Linux ports

Do not enable libsystemd usage on non-linux where it does not even
exist, and switch its arch restriction in Build-Depends to the list
of architectures that are supported instead of the ones that are not,
which is not maintainable is currently wildly incomplete.
---
 debian/control | 2 +-
 debian/rules   | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index ce27941..086de79 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends: autoconf,
libcap-ng-dev [!kfreebsd-any !hurd-any !sparc !avr32],
libselinux1-dev [linux-any],
libusb2-dev [kfreebsd-any],
-   libsystemd-dev [!kfreebsd-any],
+   libsystemd-dev [linux-any],
pkg-config,
 Vcs-Git: https://salsa.debian.org/debian/smartmontools.git
 Vcs-Browser: https://salsa.debian.org/debian/smartmontools
diff --git a/debian/rules b/debian/rules
index 6828efe..e3c610b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,9 @@ DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 
 ifeq ($(DEB_HOST_ARCH_OS),linux)
 	CONFIGURE_ARGS += --with-selinux
+	CONFIGURE_ARGS += --with-systemdenvfile=/etc/default/smartmontools
+	CONFIGURE_ARGS += --with-systemdsystemunitdir=/lib/systemd/system
+	CONFIGURE_ARGS += --with-libsystemd=auto
 endif
 
 ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
@@ -45,9 +48,6 @@ override_dh_auto_configure:
 	--with-savestates=/var/lib/smartmontools/smartd. \
 	--with-smartdplugindir=/etc/smartmontools/smartd_warning.d \
 	--with-smartdscriptdir=/usr/share/smartmontools \
-	--with-systemdenvfile=/etc/default/smartmontools \
-	--with-systemdsystemunitdir=/lib/systemd/system \
-	--with-libsystemd=auto \
 	${CONFIGURE_ARGS} \
 	;
 
-- 
2.42.0

From d5c5606dcd63193bda145658671e9a44d0f7bad0 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Fri, 24 Nov 2023 02:06:57 +0100
Subject: [PATCH 2/2] Fix libcap-ng-dev Build-Depends arch restrictions

Switch its arch restrictions in Build-Depends to the list of
architectures that are supported instead of the ones that are not,
which is not maintainable and currently includes obsolete arches
that got removed from dpkg recently.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 086de79..fcfc8e0 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Build-Depends: autoconf,
debhelper-compat (= 13),
freebsd-glue [kfreebsd-any],
libcam-dev [kfreebsd-any],
-   libcap-ng-dev [!kfreebsd-any !hurd-any !sparc !avr32],
+   libcap-ng-dev [linux-any],
libselinux1-dev [linux-any],
libusb2-dev [kfreebsd-any],
libsystemd-dev [linux-any],
-- 
2.42.0

Bug#1056731: RFS: backintime/1.4.1-0.1 [NMU] -- simple backup/snapshot system (graphical interface)

[Tobias Frost]

Hi Fabio,

Am Sat, Nov 25, 2023 at 07:33:32PM +0100 schrieb Fabio Fantoni:
> Il 25/11/2023 18:10, Tobias Frost ha scritto:
> > This seems a bit ouf of scope for an NMU (new upstream releases are
> > NMUed only in exceptional cases) and #998105 is severity normal and
> > #973760 is severity minor. (Please see the developers reference about
> > NMUs.
> > 
> > Do you have additional information why this should be an NMU?
> > I'm seeing you are member of the repo, should your name be added as
> > Uploaders and this be a regular upload?
> > Did you reach out to the maintainers and get an ACK from them?
> > 
> Hi, thanks for reply. I recently did some help on this package because I use
> it, so when I see cases with issue and/or new upstream version (with useful
> things) where a lot of time passes I try to help if I have time.
> 
> even if #998105 is only set "normal" is "a regression" that make users that
> backup over ssh waste time to found the workaround, I tried also to be fixed
> for bookworm (before release) with a upload with only this fix 
> (https://salsa.debian.org/jmw/pkg-backintime/-/commit/0066cffd98aa09c5528cb94abedda5a1a5e59e3e)
> but was rejected by the maintainer, then he replied to me who just wanted to
> wait for the bookworm release and have additional things before making a new
> upload. so I gave up and waited until after the new upstream version came
> out (and I still waited another month before doing anything)

It seems that commit was done during or just before the hard-freeze, and thus 
not
acceptable as per release policy.

The problem's severiy "normal" seems to be appropiate, too.

> Although it is not such a long time or with such serious bugs from the
> general point of view of debian, some upstream developers and users have
> come to consider this package as abandoned, here is an example:
> https://bugs.launchpad.net/ubuntu/+source/backintime/+bug/2039271 (anyway
> In that case it would not have been possible to upload the new upstream
> version anyway as that Ubuntu version was in freeze)

(Ubuntu != Debian.)
And as you say on the launchpad bug, 4 uploads a year well means this package
is maintained.

> 
> I would prefer a normal upload (from the maintainer), already prepared and
> tested, it also saves time, but unfortunately as I wrote at the moment I
> have not received any response and I had only been given permission for the
> repository previously where I already started to prepare for new upload one
> month ago. I also write to upload with delay for give another possibility to
> the maintainer, if he will have time
> 
> regarding the maintainers list I think it would be good to have it in the
> debian python team but doing this or possibly adding me as co-maintainer is
> a choice of the current maintainer. however I can't guarantee that I would
> have enough time to follow it and make quick enough uploads when needed in
> the long term.
> 
> If the maintainer responds to me in the future I will ask if he wants do
> something.

thanks for your explanations. Unfortunatly, I fear that your NMU is outside of
the scope of NMUs, despite the good intentions you have.

NMUing a new upstream version is only appropiate under certain conditions. For
example it is preferred to have dedicated patches to fix problems (but not
during a freeze, of course)

So if you come up with dedicated fixes, this NMU can go forward, otherwise, I
fear, not, unless the maintainer actively acked. (There is also no bug that
expressed the intention that you are going to NMU on the package's BTS)

Other option would be to invoke the ITS process, but I'm not sure (as in I did
not check in depth),whether the package would be eligble. Of course, you will
have to commit to the maintainance of the package then.
(But a NMU does also, albeit not to the same extend.)

-- 
tobi

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Jonas Smedegaard]

Quoting Scott Talbert (2023-11-25 19:09:39)
> On Thu, 23 Nov 2023, Jonas Smedegaard wrote:
> 
> > Quoting Ilias Tsitsimpis (2023-11-23 21:10:36)
> >> On Fri, Nov 17, 2023 at 09:28AM, Ilias Tsitsimpis wrote:
> >>> On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote:
>  Quoting John MacFarlane (2023-11-16 19:25:17)
> > Removing lua support would be most unfortunate!  If you need help from 
> > upstream in getting things to work, let me know.
> 
>  I agree: Pandoc with its core scripting language disabled is a severely
>  crippled Pandoc.
> >>>
> >>> Understood, but I am not really sure how to move forward, since Pandoc
> >>> doesn't fully support the latest Stackage LTS. I can help with
> >>> packaging/upgrade libraries if you can provide the right set of
> >>> libraries we need.
> >>
> >> I uploaded the following packages:
> >>
> >> * haskell-hslua-cli_v1.3.0-1,
> >> * haskell-hslua-module-doclayout_v1.1.0-1
> >> * haskell-hslua-module-zip_v1.1.0-1
> >>
> >> I believe the next step is to update pandoc to 3.0.1, so we can then
> >> package pandoc-lua-engine, pandoc-server and eventually pandoc-cli.
> >>
> >> Jonas, how can I help move this forward? Pandoc is the last blocker to
> >> finish the Haskell transition.
> >
> > I think this will be the best way forward:
> >
> > Haskell team introduces new source package haskell-pandoc.
> >
> > When available, I can build package pandoc depending on it.
> >
> > I really don't like breaking upstream project pandoc into two Debian
> > source packages like that, but I don't have the energy at the moment to
> > try fix dh-haskell (which I suspect will be similar work as I am doing
> > to dh-cargo currently).
> 
> I'm working on this (packaging haskell-pandoc).

Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1056744: bookworm-pu: package nvidia-graphics-drivers/525.147.05-1~deb12u1

[Andreas Beckmann]

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

[ Reason ]
In oder to fix CVE-2023-31022 we need to upgrade
nvidia-graphics-drivers-tesla-470 to a new upstream release.

[ Impact ]
A proprietary graphics driver with more CVEs open.

[ Tests ]
Only module building has been tested. Anything else would require
certain hardware and driver usage.

[ Risks ]
Low. Upgrading to a new nvidia driver release in (old-)stable is an
established procedure.

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

[ Changes ]
There is infrastructure prepared for a new binary package
(nvidia-suspend-common) that will not yet be enabled in the backport for
bookworm (but it is built in sid from the -tesla package). 
(I expect that to be enabled once we switch to the 535 series in
bookworm.)
The nvidia-powerd package is not built from this source but from the
-tesla package. The changes were synced from there.
There are only minor additional packaging changes, most changes
originate from keeping the many driver packages in sync.

 debian/README.source|  
 9 +-
 debian/changelog| 
175 
 debian/control  |  
 2 +-
 debian/control.in   |  
13 ++-
 debian/control.md5sum   |  
 8 +-
 debian/copyright|  
 3 +-
 debian/detect/nvidia-tesla.ids  |  
 4 +
 debian/not-installed.in |  
14 ++-
 debian/nv-readme.ids|  
 4 +
 debian/nvidia-options.conf.in   |  
12 ++-
 debian/nvidia-powerd.examples   |  
 2 +
 debian/nvidia-powerd.install|  
 2 +-
 debian/nvidia-suspend-common.install|  
 5 ++
 debian/nvidia-suspend-common.lintian-overrides  |  
18 
 .../patches/module/0001-bump-minimum-supported-kernel-version-to-3.10.patch |  
 4 +-
 .../module/0002-conftest.sh-remove-empty-lines-from-uts_release-outp.patch  |  
 6 +-
 debian/patches/module/0010-backport-pci-dma-changes-for-ppc64el.patch   |  
68 --
 debian/patches/module/bashisms.patch|  
 2 +-
 debian/patches/module/cc_version_check-gcc5.patch   |  
 2 +-
 debian/patches/module/conftest-verbose.patch|  
 8 +-
 debian/patches/module/series.in |  
 1 -
 debian/rules|  
12 ++-
 debian/rules.defs   |  
 6 +-
 debian/xserver-xorg-video-nvidia.examples   |  
 1 -
 24 files changed, 259 insertions(+), 122 deletions(-)

[ Other info ]
This is a rebuild of the package from sid with only a minimal change:
not enabling nvidia-suspend-common.


Andreas


ngd-525.147.05-1~deb12u1.diff.xz
Description: application/xz

Bug#1056743: RFS: sane-backends/1.2.1-6 -- API development library for scanners [development files]

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sane-backends":

   Package name : sane-backends
   Version  : 1.2.1-6
   Upstream contact : 
   URL  : http://www.sane-project.org
   License  : GPL-2, Artistic, GPL-2+ with sane exception, LGPL-2.1+,
  GPL-3+, GPL-2+
   Vcs  : https://git.jff.email/cgit/sane-backends.git
   Section  : graphics

The source builds the following binary packages:

  sane-utils - API library for scanners -- utilities
  libsane-common - API library for scanners -- documentation and support files
  libsane1 - API library for scanners
  libsane-dev - API development library for scanners [development files]

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

  https://mentors.debian.net/package/sane-backends/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.2.1-6.dsc

or from 

 git https://git.jff.email/cgit/sane-backends.git?h=release%2Fdebian%2F1.2.1-6


Changes since the last upload:

 sane-backends (1.2.1-6) unstable; urgency=medium
 .
   * libsane1: move udev files to /usr, with protective diversion
 against m-a: same file loss on upgrades (DEP17 P7 M10). Diversion can be
 removed in Forky (Closes: #1056725).
 Thanks to Chris Hofstaedtler .

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://git.jff.email/cgit/

Skype:jff-skype@jff.email
Jami: joergfringsfuerst
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.






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

Bug#1056742: ghc: Please pass number of parallel jobs from DEB_BUILD_OPTIONS to hadrian

[John Paul Adrian Glaubitz]

Source: ghc
Version: 9.4.7-1
Severity: normal
Tags: patch

Hi!

When src:ghc was switched from GNU Make to Hadrian, the build system lost
the ability to pass the parallel jobs provided in DEB_BUILD_OPTIONS to the
build process.

Luckily, Hadrian knows how to deal with parallel jobs using the -j option,
so we can just extract the number of parallel jobs from DEB_BUILD_OPTIONS
which is what the attached patch does:

--- ghc-9.4.7/debian/rules.orig 2023-10-18 21:49:38.0 +0200
+++ ghc-9.4.7/debian/rules  2023-11-25 19:59:40.401680294 +0100
@@ -95,6 +95,10 @@
EXTRA_HADRIAN_FLAGS += "*.*.rts.*.opts += -O0"
 endif
 
+ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+NUMJOBS = $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))
+endif
+
 # Use system libffi
 EXTRA_CONFIGURE_FLAGS += --with-system-libffi
 
@@ -152,7 +156,7 @@
$(error cross-compilation is not supported)
 endif
hadrian/hadrian \
-   -V -j \
+   -V -j$(NUMJOBS) \
--docs=no-haddocks --docs=no-sphinx-html --docs=no-sphinx-pdfs \
binary-dist-dir \
$(EXTRA_HADRIAN_FLAGS)
@@ -175,7 +179,7 @@
$(error override_dh_auto_build-indep is not supported when cross 
compiling)
 endif
hadrian/hadrian \
-   -V -j \
+   -V -j$(NUMJOBS) \
--docs=no-sphinx-pdfs \
binary-dist-dir \
$(EXTRA_HADRIAN_FLAGS)

I adapted the above snippet from the debian/rules file for src:cmake [1] in case
you want to credit the original authors.

Thanks,
Adrian

> [1] https://salsa.debian.org/cmake-team/cmake/-/blob/master/debian/rules#L54

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- ghc-9.4.7/debian/rules.orig 2023-10-18 21:49:38.0 +0200
+++ ghc-9.4.7/debian/rules  2023-11-25 19:59:40.401680294 +0100
@@ -95,6 +95,10 @@
EXTRA_HADRIAN_FLAGS += "*.*.rts.*.opts += -O0"
 endif
 
+ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+NUMJOBS = $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))
+endif
+
 # Use system libffi
 EXTRA_CONFIGURE_FLAGS += --with-system-libffi
 
@@ -152,7 +156,7 @@
$(error cross-compilation is not supported)
 endif
hadrian/hadrian \
-   -V -j \
+   -V -j$(NUMJOBS) \
--docs=no-haddocks --docs=no-sphinx-html --docs=no-sphinx-pdfs \
binary-dist-dir \
$(EXTRA_HADRIAN_FLAGS)
@@ -175,7 +179,7 @@
$(error override_dh_auto_build-indep is not supported when cross 
compiling)
 endif
hadrian/hadrian \
-   -V -j \
+   -V -j$(NUMJOBS) \
--docs=no-sphinx-pdfs \
binary-dist-dir \
$(EXTRA_HADRIAN_FLAGS)

Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[Cyril Brulebois]

Lennart Sorensen  (2023-11-25):
> I suspect you are missing the firmware file for the network port.  I think 
> this one:
> 
> firmware-misc-nonfree: /lib/firmware/tigon/tg3.bin
> 
> The installer probably does not include that.

The netinst *definitely* does ship that package:
  
https://cdimage.debian.org/cdimage/release/current/amd64/list-cd/debian-12.2.0-amd64-netinst.list.gz


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1056741: bookworm-pu: package nvidia-open-gpu-kernel-modules/525.147.05-1~deb12u1

[Andreas Beckmann]

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

[ Reason ]
In order to fix CVE-2023-31022 we need to upgrade
nvidia-open-gpu-kernel-modules to a new upstream release.
(This package must match the version of src:nvidia-graphics-drivers
and/or src:nvidia-graphics-drivers-tesla to be useful, and these two
packages in non-free need to be updated for CVE-2023-31022, too.)

[ Impact ]
An unusable package with open CVEs.

[ Tests ]
Only module building has been tested. Anything else would require
certain hardware and driver usage.

[ Risks ]
Low. Upgrading to a new nvidia driver release in (old-)stable is an
established procedure.

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  I didn't read the upstream diff (114 files changed, 7240
  insertions(+), 830 deletions(-)), but this corresponds to the
  changes in the driver blobs in non-free.
  [*] attach debdiff against the package in (old)stable
  only for debian/*, upstream changes are excessive
  [*] the issue is verified as fixed in unstable

[ Changes ]
Mainly patch refresh for the new upstream release. This is a subset of
the changes also found in the pu requests for
src:nvidia-graphics-drivers{-tesla}.

Upstream changes diffstat, changes not included in the patch
(500kb uncompressed)

 CHANGELOG.md|6 
+
 README.md   |   15 
+-
 kernel-open/Kbuild  |3 
+-
 kernel-open/common/inc/nv-hypervisor.h  |1 
+
 kernel-open/common/inc/nv-mm.h  |   59 
+-
 kernel-open/conftest.sh |  327 
--
 kernel-open/nvidia-drm/nvidia-drm-drv.c |   15 
+
 kernel-open/nvidia-drm/nvidia-drm.Kbuild|2 
+
 kernel-open/nvidia-modeset/nvidia-modeset-linux.c   |8 
+
 kernel-open/nvidia-modeset/nvidia-modeset-os-interface.h|2 
+
 kernel-open/nvidia-uvm/nvidia-uvm.Kbuild|2 
+-
 kernel-open/nvidia-uvm/uvm_ce_test.c|4 
+-
 kernel-open/nvidia-uvm/uvm_migrate_pageable.h   |2 
+-
 kernel-open/nvidia/nv-p2p.c |5 
+
 kernel-open/nvidia/nv.c |   14 
+-
 kernel-open/nvidia/nvlink_export.h  |5 
+
 kernel-open/nvidia/nvlink_os.h  |3 
+
 src/common/displayport/src/dp_evoadapter.cpp|6 
+-
 src/common/inc/nvBldVer.h   |   20 
+-
 src/common/inc/nvUnixVersion.h  |2 
+-
 src/common/inc/nvlog_defs.h |   17 
+-
 src/common/inc/swref/published/hopper/gh100/dev_fb.h|   23 
+-
 src/common/inc/swref/published/hopper/gh100/dev_fbpa.h  |   29 
+
 src/common/inc/swref/published/hopper/gh100/dev_ltc.h   |   33 
+
 src/common/inc/swref/published/hopper/gh100/dev_nv_xpl.h|   52 
++
 src/common/inc/swref/published/hopper/gh100/dev_xtl_ep_pri.h|3 
+
 src/common/inc/swref/published/hopper/gh100/hwproject.h |6 
+
 src/common/inc/swref/published/hopper/gh100/pri_nv_xal_ep.h |   12 
+
 src/common/inc/swref/published/nvswitch/ls10/dev_nvlipt_lnk_ip.h|5 
+-
 src/common/inc/swref/published/nvswitch/ls10/ptop_discovery_ip.h|   28 
+
 src/common/nvlink/interface/nvlink.h|5 
+
 src/common/nvlink/interface/nvlink_export.h |5 
+
 src/common/nvlink/interface/nvlink_os.h |3 
+
 src/common/nvlink/kernel/nvlink/nvlink_lib_mgmt.c   |   50 
+-
 src/common/nvlink/kernel/nvlink/nvlink_lock.c   |   32 
+-
 src/common/nvswitch/common/inc/soe/soeifcore.h  |   24 
+-
 src/common/nvswitch/common/inc/soe/soeififr.h   |  116 
+++-
 src/common/nvswitch/interface/ctrl_dev_nvswitch.h   |  198 
+-
 src/common/nvswitch/kernel/inc/haldef_nvswitch.h|7 
+
 src/common/nvswitch/kernel/inc/inforom/inforom_nvl_v3_nvswitch.h|   94 
+++
 src/common/nvswitch/kernel/inc/inforom/inforom_nvl_v4_nvswitch.h|   37 
++
 src/common/nvswitch/kernel/inc/inforom/inforom_nvswitch.h   |   12 
+-
 src/common/nvswitch/kernel/inc/lr10/inforom_lr10.h  

Bug#1056740: RFS: restic-rest-server/0.12.1-1 [ITP] -- high performance HTTP server that implements restic's REST backend API

[Dale Richards]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "restic-rest-server":

 * Package name : restic-rest-server
   Version  : 0.12.1-1
   Upstream contact : The Rest Server Authors 
 * URL  : https://github.com/restic/rest-server
 * License  : BSD-2-Clause
 * Vcs  :
https://salsa.debian.org/doge-tech/restic-rest-server
   Section  : httpd

The source builds the following binary packages:

  restic-rest-server - high performance HTTP server that implements
restic's REST backend API

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

  https://mentors.debian.net/package/restic-rest-server/

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

  dget -x
https://mentors.debian.net/debian/pool/main/r/restic-rest-server/restic-rest-server_0.12.1-1.dsc

Changes for the initial release:

 restic-rest-server (0.12.1-1) unstable; urgency=medium
 .
   * Initial release. Closes: #1040667

Many thanks,
Dale Richards

Bug#1056737: bookworm-pu: minizip/1.1-8+deb12u1

[Thorsten Alteholz]

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


The attached debdiff for minizip fixes CVE-2023-45853 in Bookworm. This 
CVE has been marked as no-dsa by the security team.


Chrome upstream added a test for their internal copy of minizip. Running 
this test against libminizip1 of this package worked as well, so I don't 
expect any problems.


  Thorsten
diff -Nru minizip-1.1/debian/changelog minizip-1.1/debian/changelog
--- minizip-1.1/debian/changelog2016-01-03 04:24:26.0 +0100
+++ minizip-1.1/debian/changelog2023-11-25 13:03:02.0 +0100
@@ -1,3 +1,11 @@
+minizip (1.1-8+deb12u1) bookworm; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2023-45853 (Closes: #1056719)
+Reject overflows of zip header fields in minizip.
+
+ -- Thorsten Alteholz   Sat, 25 Nov 2023 13:03:02 +0100
+
 minizip (1.1-8) unstable; urgency=medium
 
   * Fix implicit function declaration.
diff -Nru minizip-1.1/debian/patches/CVE-2023-45853.patch 
minizip-1.1/debian/patches/CVE-2023-45853.patch
--- minizip-1.1/debian/patches/CVE-2023-45853.patch 1970-01-01 
01:00:00.0 +0100
+++ minizip-1.1/debian/patches/CVE-2023-45853.patch 2023-11-18 
17:51:11.0 +0100
@@ -0,0 +1,34 @@
+commit 73331a6a0481067628f065ffe87bb1d8f787d10c
+Author: Hans Wennborg 
+Date:   Fri Aug 18 11:05:33 2023 +0200
+
+Reject overflows of zip header fields in minizip.
+
+This checks the lengths of the file name, extra field, and comment
+that would be put in the zip headers, and rejects them if they are
+too long. They are each limited to 65535 bytes in length by the zip
+format. This also avoids possible buffer overflows if the provided
+fields are too long.
+
+Index: minizip-1.1/zip.c
+===
+--- minizip-1.1.orig/zip.c 2023-11-18 17:51:05.539763813 +0100
 minizip-1.1/zip.c  2023-11-18 17:51:05.539763813 +0100
+@@ -1082,6 +1082,17 @@
+   return ZIP_PARAMERROR;
+ #endif
+ 
++// The filename and comment length must fit in 16 bits.
++if ((filename!=NULL) && (strlen(filename)>0x))
++return ZIP_PARAMERROR;
++if ((comment!=NULL) && (strlen(comment)>0x))
++return ZIP_PARAMERROR;
++// The extra field length must fit in 16 bits. If the member also requires
++// a Zip64 extra block, that will also need to fit within that 16-bit
++// length, but that will be checked for later.
++if ((size_extrafield_local>0x) || (size_extrafield_global>0x))
++return ZIP_PARAMERROR;
++
+ zi = (zip64_internal*)file;
+ 
+ if (zi->in_opened_file_inzip == 1)
diff -Nru minizip-1.1/debian/patches/series minizip-1.1/debian/patches/series
--- minizip-1.1/debian/patches/series   2016-01-03 04:14:08.0 +0100
+++ minizip-1.1/debian/patches/series   2023-11-18 17:50:30.0 +0100
@@ -1,3 +1,5 @@
 include.patch
 automake.patch
 traversal.patch
+
+CVE-2023-45853.patch

Bug#1056739: -static-pie fails on i386

[Michael Tokarev]

Package: libc6-dev
Version: 2.37-12
Severity: normal
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org

When building a statically-linked application with -static-pie flag
(which is not supported on every platform), on i386 where it seems
to be supported (at least -static-pie flag is accepted), the link
fails like this:

/usr/bin/ld: 
/usr/lib/gcc/i686-linux-gnu/13/../../../i386-linux-gnu/libc.a(memset_chk-nonshared.o):
 unsupported non-PIC call to IFUNC `memset'
/usr/bin/ld: failed to set dynamic section sizes: bad value

This can be observed, for example, here:
https://buildd.debian.org/status/fetch.php?pkg=qemu=i386=1%3A8.2.0%7Erc1%2Bds-1=1700774780=0

There are some architectures where -static-pie build is supported
and works (eg amd64, arm64, s390x), where it is not supported at
all (most other architectures), and where it is supported but does
not work, and this is i386, - this is what this bug is about.
I guess it needs to be either rejected entirely as unsupported, or
to be working.

Does it make sense to enable pic build of glibc on i386 architecture?
Right now I'm not sure what to do with qemu which is FTBFS on i386
due to this.

Thanks,

/mjt

Bug#1056738: bullseye-pu: minizip/1.1-8+deb11u1

[Thorsten Alteholz]

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


The attached debdiff for minizip fixes CVE-2023-45853 in Bullseye. This
CVE has been marked as no-dsa by the security team.

As this is the same version as in Bookworm, I don't expect any problems in 
Bullseye as well.


  Thorsten
diff -Nru minizip-1.1/debian/changelog minizip-1.1/debian/changelog
--- minizip-1.1/debian/changelog2016-01-03 04:24:26.0 +0100
+++ minizip-1.1/debian/changelog2023-11-25 13:03:02.0 +0100
@@ -1,3 +1,11 @@
+minizip (1.1-8+deb11u1) bullseye; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2023-45853 (Closes: #1056719)
+Reject overflows of zip header fields in minizip.
+
+ -- Thorsten Alteholz   Sat, 25 Nov 2023 13:03:02 +0100
+
 minizip (1.1-8) unstable; urgency=medium
 
   * Fix implicit function declaration.
diff -Nru minizip-1.1/debian/patches/CVE-2023-45853.patch 
minizip-1.1/debian/patches/CVE-2023-45853.patch
--- minizip-1.1/debian/patches/CVE-2023-45853.patch 1970-01-01 
01:00:00.0 +0100
+++ minizip-1.1/debian/patches/CVE-2023-45853.patch 2023-11-18 
17:54:41.0 +0100
@@ -0,0 +1,34 @@
+commit 73331a6a0481067628f065ffe87bb1d8f787d10c
+Author: Hans Wennborg 
+Date:   Fri Aug 18 11:05:33 2023 +0200
+
+Reject overflows of zip header fields in minizip.
+
+This checks the lengths of the file name, extra field, and comment
+that would be put in the zip headers, and rejects them if they are
+too long. They are each limited to 65535 bytes in length by the zip
+format. This also avoids possible buffer overflows if the provided
+fields are too long.
+
+Index: minizip-1.1/zip.c
+===
+--- minizip-1.1.orig/zip.c 2023-11-18 17:51:05.539763813 +0100
 minizip-1.1/zip.c  2023-11-18 17:51:05.539763813 +0100
+@@ -1082,6 +1082,17 @@
+   return ZIP_PARAMERROR;
+ #endif
+ 
++// The filename and comment length must fit in 16 bits.
++if ((filename!=NULL) && (strlen(filename)>0x))
++return ZIP_PARAMERROR;
++if ((comment!=NULL) && (strlen(comment)>0x))
++return ZIP_PARAMERROR;
++// The extra field length must fit in 16 bits. If the member also requires
++// a Zip64 extra block, that will also need to fit within that 16-bit
++// length, but that will be checked for later.
++if ((size_extrafield_local>0x) || (size_extrafield_global>0x))
++return ZIP_PARAMERROR;
++
+ zi = (zip64_internal*)file;
+ 
+ if (zi->in_opened_file_inzip == 1)
diff -Nru minizip-1.1/debian/patches/series minizip-1.1/debian/patches/series
--- minizip-1.1/debian/patches/series   2016-01-03 04:14:08.0 +0100
+++ minizip-1.1/debian/patches/series   2023-11-18 17:54:50.0 +0100
@@ -1,3 +1,5 @@
 include.patch
 automake.patch
 traversal.patch
+
+CVE-2023-45853.patch

Bug#1056731: RFS: backintime/1.4.1-0.1 [NMU] -- simple backup/snapshot system (graphical interface)

[Fabio Fantoni]

Il 25/11/2023 18:10, Tobias Frost ha scritto:

This seems a bit ouf of scope for an NMU (new upstream releases are
NMUed only in exceptional cases) and #998105 is severity normal and
#973760 is severity minor. (Please see the developers reference about
NMUs.

Do you have additional information why this should be an NMU?
I'm seeing you are member of the repo, should your name be added as
Uploaders and this be a regular upload?
Did you reach out to the maintainers and get an ACK from them?

Hi, thanks for reply. I recently did some help on this package because I 
use it, so when I see cases with issue and/or new upstream version (with 
useful things) where a lot of time passes I try to help if I have time.


even if #998105 is only set "normal" is "a regression" that make users 
that backup over ssh waste time to found the workaround, I tried also to 
be fixed for bookworm (before release) with a upload with only this fix 
(https://salsa.debian.org/jmw/pkg-backintime/-/commit/0066cffd98aa09c5528cb94abedda5a1a5e59e3e) 
but was rejected by the maintainer, then he replied to me who just 
wanted to wait for the bookworm release and have additional things 
before making a new upload. so I gave up and waited until after the new 
upstream version came out (and I still waited another month before doing 
anything)


Although it is not such a long time or with such serious bugs from the 
general point of view of debian, some upstream developers and users have 
come to consider this package as abandoned, here is an example: 
https://bugs.launchpad.net/ubuntu/+source/backintime/+bug /2039271 
(anyway In that case it would not have been possible to upload the new 
upstream version anyway as that Ubuntu version was in freeze)


I would prefer a normal upload (from the maintainer), already prepared 
and tested, it also saves time, but unfortunately as I wrote at the 
moment I have not received any response and I had only been given 
permission for the repository previously where I already started to 
prepare for new upload one month ago. I also write to upload with delay 
for give another possibility to the maintainer, if he will have time


regarding the maintainers list I think it would be good to have it in 
the debian python team but doing this or possibly adding me as 
co-maintainer is a choice of the current maintainer. however I can't 
guarantee that I would have enough time to follow it and make quick 
enough uploads when needed in the long term.


If the maintainer responds to me in the future I will ask if he wants do 
something.





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[Lennart Sorensen]

On Fri, Nov 24, 2023 at 12:34:50PM -0600, David Hillman wrote:
> 
> Package: installation-reports
> 
> Boot method: USB stick
> Image version: 
> https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.2.0-amd64-netinst.iso
> Date: 2023-November-23 11PM GMT
> 
> Machine: Dell R720
> Processor: 2 x Xeon E5-2650
> Memory: 192GB
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O ]
> Detect network card:    [E ]
> Configure network:  [E ]
> Detect media:   [ ]
> Load installer modules: [ ]
> Detect hard drives: [O ]
> Partition hard drives:  [O ]
> Install base system:    [ ]
> Clock/timezone setup:   [ ]
> User/password setup:    [O ]
> Install tasks:  [ ]
> Install boot loader:    [ ]
> Overall install:    [E ]
> 
> Comments/Problems:
> 
> 
> Installer completely failed to identify the presence of all four integrated
> Broadcom BCM5720 ethernet ports, and even after manually adding and
> configuring the four interfaces, no network connectivity is to be had. 
> Interfaces are allegedly "UP", but cannot ping anything nor respond to any
> communication.  IDRAC card interface works fine -- on the same subnet.  A
> half-dozen other multi-interface machines on the same subnet are working
> fine, as well.
> 
> Ubuntu 20 and 22 installers work just fine on the same hardware, so this is
> a Debian-specific issue.  All four interfaces work just fine under both
> Ubuntu 20 and 22, but are totally dysfunctional with Debian 12.
> 
> Journal entries for NetworkManager and avahi-daemon appear to show the
> correct IP addresses being registered for all four interfaces, and "ip"
> agress, all to no avail.  No related error messages exist in the journal.

I suspect you are missing the firmware file for the network port.  I think this 
one:

firmware-misc-nonfree: /lib/firmware/tigon/tg3.bin

The installer probably does not include that.

-- 
Len Sorensen

Bug#1056443: pysph ftbfs with Python 3.12

[Antonio Valentino]

Dear Matthias,

On Wed, 22 Nov 2023 13:49:03 +0100 Matthias Klose  wrote:

Package: src:pysph
Version: 1.0~b1-6
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

pysph ftbfs with Python 3.12:

[...]
I: pybuild base:310: cd '/<>/.pybuild/cpython3_3.12/build'; 
python3.12 -m pytest -k "not test_sph_evaluator and not TestInterpolator 
and not test_get_points_from_mgrid and not test_get_surface_points_uniform"
= test session starts 
==

platform linux -- Python 3.12.0+, pytest-7.4.3, pluggy-1.3.0
rootdir: /<>
configfile: tox.ini
collected 224 items / 29 errors / 91 deselected / 133 selected

 ERRORS 

_ ERROR collecting 
.pybuild/cpython3_3.12/build/pysph/base/tests/test_device_helper.py _
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.12/build/pysph/base/tests/test_device_helper.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.12/importlib/__init__.py:90: in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
pysph/base/tests/test_device_helper.py:4: in 
 from pysph.base.utils import get_particle_array  # noqa: E402
pysph/base/utils.py:7: in 
 from .particle_array import ParticleArray, \
pysph/base/particle_array.pyx:25: in init pysph.base.particle_array
 from compyle.array import Array, get_backend, to_device
/usr/lib/python3/dist-packages/compyle/array.py:11: in 
 from .sort import radix_sort
/usr/lib/python3/dist-packages/compyle/sort.py:5: in 
 from .transpiler import Transpiler, convert_to_float_if_needed
/usr/lib/python3/dist-packages/compyle/transpiler.py:12: in 
 from .ext_module import ExtModule
/usr/lib/python3/dist-packages/compyle/ext_module.py:14: in 
 from pyximport import pyxbuild
/usr/lib/python3/dist-packages/pyximport/__init__.py:1: in 
 from .pyximport import *
/usr/lib/python3/dist-packages/pyximport/pyximport.py:51: in 
 import imp
E   ModuleNotFoundError: No module named 'imp'
_ ERROR collecting 
.pybuild/cpython3_3.12/build/pysph/base/tests/test_domain_manager.py _
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.12/build/pysph/base/tests/test_domain_manager.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.12/importlib/__init__.py:90: in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
pysph/base/tests/test_domain_manager.py:8: in 
 from pysph.base.nnps import DomainManager, BoxSortNNPS, LinkedListNNPS
pysph/base/nnps.py:1: in 


This seems to be an issue in cython3.
I will reassign it.

cheers
--
Antonio Valentino

Bug#1056736: smartmontools: please do not force people to use update-smart-drivedb and install foreign code

[Christoph Anton Mitterer]

If you really insist on having that functionality, wouldn't it be
anyway better to:

- Add a systemd.timer that regularly (perhaps weekly?) calls
  update-smart-drivedb instead of doing it only once in postinst,
  where it's unlikely to be of much use, because the package was just
  upgraded, so there's a good change that it's drivedb.h is still
  current.
- But even then, please don't run that out of the box.
  Either let people manually enable it or provide a debconf question
  where one can at least choose to opt-out once and for all.
  Though even *with* debconf I'd still prefer if this was an opt-in.


Cheers,
Chris.

Bug#1056619: ITP: soplex -- sequential object-oriented simplex solver

[David Bremner]

Timo Röhling  writes:


> More importantly though, all three of PaPILO, SoPlex, and SCIP can 
> potentially be linked against each other. In order to avoid circular 
> dependencies, I came to the conclusion that SCIP should be linked 
> against both PaPILO and SoPlex, PaPILO should probably be linked 
> against SoPlex, and SoPlex should be built standalone.
>
> If you think otherwise, I'd be happy to hear your thoughts.

Based on my limited understanding of what these things do, that makes
sense to me.

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Scott Talbert]

On Thu, 23 Nov 2023, Jonas Smedegaard wrote:


Quoting Ilias Tsitsimpis (2023-11-23 21:10:36)

On Fri, Nov 17, 2023 at 09:28AM, Ilias Tsitsimpis wrote:

On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote:

Quoting John MacFarlane (2023-11-16 19:25:17)

Removing lua support would be most unfortunate!  If you need help from upstream 
in getting things to work, let me know.


I agree: Pandoc with its core scripting language disabled is a severely
crippled Pandoc.


Understood, but I am not really sure how to move forward, since Pandoc
doesn't fully support the latest Stackage LTS. I can help with
packaging/upgrade libraries if you can provide the right set of
libraries we need.


I uploaded the following packages:

* haskell-hslua-cli_v1.3.0-1,
* haskell-hslua-module-doclayout_v1.1.0-1
* haskell-hslua-module-zip_v1.1.0-1

I believe the next step is to update pandoc to 3.0.1, so we can then
package pandoc-lua-engine, pandoc-server and eventually pandoc-cli.

Jonas, how can I help move this forward? Pandoc is the last blocker to
finish the Haskell transition.


I think this will be the best way forward:

Haskell team introduces new source package haskell-pandoc.

When available, I can build package pandoc depending on it.

I really don't like breaking upstream project pandoc into two Debian
source packages like that, but I don't have the energy at the moment to
try fix dh-haskell (which I suspect will be similar work as I am doing
to dh-cargo currently).


I'm working on this (packaging haskell-pandoc).

Regards,
Scott

Bug#1056736: smartmontools: please do not force people to use update-smart-drivedb and install foreign code

[Christoph Anton Mitterer]

Package: smartmontools
Version: 7.4-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

Hey.

The most recent upgrade forces people to use
update-smart-drivedb by doing it already in the postinst and not leaving it
up to the user whether he wants to use such a tool.

Security-wise this is really a bad idea.

Downloader packages (i.e. packages that install further code from
outside Debian) - and this effectively just that - are generally questionable.

Even if the downloader tool does everything right (which is actually quite
difficult if one assumes things like replay or blocking attacks), there's still
code introduced which is not in the control of Debian and especially also
outside security support.

Now you may argue that Debian doesn't audit the drivedb.h it ships either and
that thus security wouldn't be any better if Debian would just ship the
upstream file.
But there's still a difference:
If Debian ships the package, then all installations are guaranteed to get the
same file. So an attacker would need to attack all installation at the same
time and thus be far more likely to be detected.
If however the package is downloaded from some remote server, an attacker can
choose based on IP whether the "good" or the "evil" file is delivered.

And this is not to say that I'd assume smartmontools upstream would be evil.
But even their GPG keys or systemd can be compromised.


The package already has the update-smart-drivedb tool, if people are confident
with using it, they can do so.
But please don't force it on everyone by unconditionally calling it from
postinst (or from anywhere else).


Cheers,
Chris.

Bug#1056735: dgit - improve web interface to git.dgit.debian.org

[Peter Michael Green]

Package: dgit

(this bug report is a result of a question discussion in IANs tag2upload 
talk at the cambridge miniconf 2023)


In the talk Ian made the following points

* the current Salsa approach leads to users accidentlly receiving 
patches unapplied git trees
* In a later slide git.dgit.debian.org was identified as a "canonical 
git repo" where users could
   obtain the "patches applied" trees that correspond to the archive 
contents.
* It was also stated (and is already the case with dgit) that 
git.dgit.debian.org would store
   both the maintainers original git tag (which may or may not be 
patches applied, but usually
   is not), and the "patches applied" tag that corresponds to the 
archive content.


The problem is when a user visits git.dgit.debian.org they just meet a 
generic git web
interface with a list of branches, tags etc. It is not at all clear to a 
user what each

tag means and in particular what the difference between debian/ and
archive/debian/ are (IIRC one is the maintainer tree and one is the
"standardised" tree but it's not at all obvious which is which)

Bug#1043471: pgpainless: FTBFS: make[1]: *** [debian/rules:40: override_dh_auto_test] Error 1

[tony mancill]

On Sat, Nov 04, 2023 at 12:01:48AM +0100, Santiago Vila wrote:
> # also happens in bookworm
> tags 1054771 + bookworm
> thanks

The cause of the FTBFS is that keys used as during the test suite have
expired, so it will fail everywhere a build is attempted (unless the
build system clock is rewound to before 2023-10-26).

As a temporary measure, I have uploaded a work-around to ignore the
impacted tests and keep the package in testing, but the real fix is to
update pgpainless, as reported in Debian bug #1043471 [1], which is turn
blocked by an update for BouncyCastle [2].

Cheers,
tony

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


signature.asc
Description: PGP signature

Bug#1053950: openttd: diff for NMU version 13.4-0.1

[Matthijs Kooijman]

Hi Maytham,

> I've prepared an NMU for openttd (versioned as 13.4-0.1). The diff
> is attached to this message.
Thanks for your patch. I should have uploaded a new OpenTTD version
a long time ago, so let met correct that by handling the update now.
I'll go through my normal git-based workflow rather than using your NMU
though, AFAICS you've made no changes to the packaging except import the
upstream tarball, right?

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#1056734: mirror submission for mirror.blue3.com.br

[Samir Hanna Verza]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.blue3.com.br
Archive-architecture: amd64 arm64 armel armhf i386 mips
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Samir Hanna Verza 
Country: BR Brazil
Location: Porto Alegre,RS
Sponsor: BLUE3 INTERNET https://blue3.com.br
Comment: Extreme south of Brazil, close to Uruguay and Argentina.




Trace Url: http://mirror.blue3.com.br/debian/project/trace/
Trace Url: http://mirror.blue3.com.br/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.blue3.com.br/debian/project/trace/mirror.blue3.com.br

Bug#1056731: RFS: backintime/1.4.1-0.1 [NMU] -- simple backup/snapshot system (graphical interface)

[Tobias Frost]

Control: tags -1 moreinfo


On Sat, Nov 25, 2023 at 05:39:44PM +0100, Fabio Fantoni wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "backintime":
> 
>  * Package name : backintime
>    Version  : 1.4.1-0.1
>  * URL  : https://github.com/bit-team/backintime
>  * License  : GPL-2+
>  * Vcs  : https://salsa.debian.org/jmw/pkg-backintime
>    Section  : utils
> 
> The source builds the following binary packages:
> 
>   backintime-common - simple backup/snapshot system (common files)
>   backintime-qt - simple backup/snapshot system (graphical interface)
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/backintime/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/b/backintime/backintime_1.4.1-0.1.dsc
> 
> After one month from new upstream version without no activity on debian
> packaging I prepared it on git https://salsa.debian.org/jmw/pkg-backintime
> 
> After some days, 21 day ago I also write a mail to maintainer without reply
> for now
> 
> So I prepared this NMU, can someone upload it with a delay of few days
> please? to give a further upload possibility to the maintainer, just as I
> have not uploaded the release commit to git (I will only do it if the nmu
> reaches the repository)
> 
> 
> Changes since the last upload:
> 
>  backintime (1.4.1-0.1) unstable; urgency=medium
>  .
>    * Non-maintainer upload
>    * New upstream version 1.4.1 (Closes: #998105, #973760)
>    * d/patches: remove one patch applied upstream
>    * Update d/copyright

This seems a bit ouf of scope for an NMU (new upstream releases are
NMUed only in exceptional cases) and #998105 is severity normal and
#973760 is severity minor. (Please see the developers reference about
NMUs.

Do you have additional information why this should be an NMU?
I'm seeing you are member of the repo, should your name be added as
Uploaders and this be a regular upload?
Did you reach out to the maintainers and get an ACK from them?

Cheers,
tobi

> Regards,
 -- 
>   Fabio Fantoni
> 

Bug#1056733: iscsiuio - iscsiuio.socket

[Laszlo]

Package: iscsiuio

Hello,

/lib/systemd/system/iscsiuio.socket seems to be missing from the iscsiuio
package, see https://packages.debian.org/sid/amd64/iscsiuio/filelist .

Thanks,
  Laszlo

Bug#973760: backintime-common: in backintime.py function smartRemoveList missing return value

[Fabio Fantoni]

Control: reopen -1

This was not really solved in debian, will be solved in next upload



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056732: bookworm-pu: package opendkim/2.11.0~beta2-8+deb12u1

[Tobias Frost]

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

After sponsoring the maintainer David Bürgin I've offered them to tackle
s-p-u and o-s-p-u, addressing CVE-2022-48521. (Details: RFS #1056285)

Before the upload, stable and sid were at the same version, 
namely 2.11.0~beta2-8, so the patch could been applied as is,
without changes needed. Additional changes, not suitable for s-p-u
have been dropped.

The patch is authored by David Bürgin and they confirm that they have
tested the patch and it indeeds fix the issue (quote from #1056285#19):

> Hello Tobi,
> 
> > A question to that: Can you elaborate a bit on the testing you have
> > done to verify that this patch indeed fixes the vulnerability?
> > (Asking, becasue unfortunatly there is not lot of information available
> > e.g from the upstream issue and upstream seems to be generally very
> > silent…

> I developed the upstream patch, and so did do the necessary testing
> locally. You can simply prepare a crafted message containing some
> Authentication-Results headers and then see if the right ones get
> deleted.

(I've uploaded the package to the s-p-u queue already.)

debdiff attached.

-- 
Cheers,
tobi
diff -Nru opendkim-2.11.0~beta2/debian/changelog opendkim-2.11.0~beta2/debian/changelog
--- opendkim-2.11.0~beta2/debian/changelog	2022-12-20 09:10:44.0 +0100
+++ opendkim-2.11.0~beta2/debian/changelog	2023-11-25 17:19:13.0 +0100
@@ -1,3 +1,13 @@
+opendkim (2.11.0~beta2-8+deb12u1) bookworm; urgency=medium
+
+  * Non-Maintainer upload by the security team.
+
+  [ David Bürgin ]
+  * Add patch "rev-ares-deletion.patch" for CVE-2022-48521:
+Delete Authentication-Results headers in reverse (Closes: #1041107).
+
+ -- Tobias Frost   Sat, 25 Nov 2023 17:19:13 +0100
+
 opendkim (2.11.0~beta2-8) unstable; urgency=medium
 
   [ David Bürgin ]
diff -Nru opendkim-2.11.0~beta2/debian/patches/rev-ares-deletion.patch opendkim-2.11.0~beta2/debian/patches/rev-ares-deletion.patch
--- opendkim-2.11.0~beta2/debian/patches/rev-ares-deletion.patch	1970-01-01 01:00:00.0 +0100
+++ opendkim-2.11.0~beta2/debian/patches/rev-ares-deletion.patch	2023-11-25 17:19:13.0 +0100
@@ -0,0 +1,33 @@
+Description: Delete Authentication-Results headers in reverse (CVE-2022-48521)
+Author: David Bürgin 
+Bug: https://github.com/trusteddomainproject/OpenDKIM/pull/189
+
+--- a/opendkim/opendkim.c
 b/opendkim/opendkim.c
+@@ -13651,9 +13651,16 @@
+ 			return SMFIS_TEMPFAIL;
+ 		}
+ 
+-		c = 0;
++		c = 1;
++
+ 		for (hdr = dfc->mctx_hqhead; hdr != NULL; hdr = hdr->hdr_next)
+ 		{
++			if (strcasecmp(hdr->hdr_hdr, AUTHRESULTSHDR) == 0)
++c++;
++		}
++
++		for (hdr = dfc->mctx_hqtail; hdr != NULL; hdr = hdr->hdr_prev)
++		{
+ 			memset(ares, '\0', sizeof(struct authres));
+ 
+ 			if (strcasecmp(hdr->hdr_hdr, AUTHRESULTSHDR) == 0)
+@@ -13664,7 +13671,7 @@
+ char *slash;
+ 
+ /* remember index */
+-c++;
++c--;
+ 
+ /* parse the header */
+ arstat = ares_parse((u_char *) hdr->hdr_val,
diff -Nru opendkim-2.11.0~beta2/debian/patches/series opendkim-2.11.0~beta2/debian/patches/series
--- opendkim-2.11.0~beta2/debian/patches/series	2022-12-12 14:41:20.0 +0100
+++ opendkim-2.11.0~beta2/debian/patches/series	2023-11-25 17:19:13.0 +0100
@@ -12,3 +12,4 @@
 conf_refcnt.patch
 lua-5.3.patch
 fix-RSA_Sign-call.patch
+rev-ares-deletion.patch


signature.asc
Description: PGP signature

Bug#1056731: RFS: backintime/1.4.1-0.1 [NMU] -- simple backup/snapshot system (graphical interface)

[Fabio Fantoni]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : backintime
   Version  : 1.4.1-0.1
 * URL  : https://github.com/bit-team/backintime
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/jmw/pkg-backintime
   Section  : utils

The source builds the following binary packages:

  backintime-common - simple backup/snapshot system (common files)
  backintime-qt - simple backup/snapshot system (graphical interface)

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/backintime/backintime_1.4.1-0.1.dsc


After one month from new upstream version without no activity on debian 
packaging I prepared it on git https://salsa.debian.org/jmw/pkg-backintime


After some days, 21 day ago I also write a mail to maintainer without 
reply for now


So I prepared this NMU, can someone upload it with a delay of few days 
please? to give a further upload possibility to the maintainer, just as 
I have not uploaded the release commit to git (I will only do it if the 
nmu reaches the repository)



Changes since the last upload:

 backintime (1.4.1-0.1) unstable; urgency=medium
 .
   * Non-maintainer upload
   * New upstream version 1.4.1 (Closes: #998105, #973760)
   * d/patches: remove one patch applied upstream
   * Update d/copyright

Regards,
--
  Fabio Fantoni



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056730: RM: pgrouting [armel armhf i386] -- ROM; FTBFS on 32bit architectures

[Bas Couwenberg]

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

Please remove pgrouting from the armel, armhf, and i386 where it FTBFS.

Kind Regards,

Bas

Bug#1052696: sccache: FTBFS in sid

[Blair Noctis]

On Tue, 26 Sep 2023 11:40:24 +0200 Gianfranco Costamagna
 wrote:
> (11900+ lines of inlined build log)

Hi Gianfranco,

It would be great if you had kindly sent the log as a separate attachment or
pasted its r-b URL.

-- 
Sdrager,
Blair Noctis


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056525: sarsen's autopkg tests fail with Python 3.12

[Antonio Valentino]

Dear Matthias,

On Wed, 22 Nov 2023 16:40:45 +0100 Matthias Klose  wrote:

Package: src:sarsen
Version: 0.9.3+ds-2
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

sarsen's autopkg tests fail with Python 3.12:

[...]



624s import xarray_sentinel
624s   File 
"/usr/lib/python3/dist-packages/xarray_sentinel/__init__.py", line 23, 
in 

624s from .esa_safe import make_stac_item
624s   File 
"/usr/lib/python3/dist-packages/xarray_sentinel/esa_safe.py", line 8, in 


624s import xmlschema
624s   File "/usr/lib/python3/dist-packages/xmlschema/__init__.py", line 
20, in 
624s from .dataobjects import DataElement, DataElementConverter, 
DataBindingConverter
624s   File "/usr/lib/python3/dist-packages/xmlschema/dataobjects.py", 
line 27, in 

624s from . import validators
624s   File 
"/usr/lib/python3/dist-packages/xmlschema/validators/__init__.py", line 
38, in 
624s from .schemas import XMLSchemaMeta, XMLSchemaBase, XMLSchema, 
XMLSchema10, XMLSchema11
624s   File 
"/usr/lib/python3/dist-packages/xmlschema/validators/schemas.py", line 
2137, in 

624s class XMLSchema10(XMLSchemaBase):
624s   File 
"/usr/lib/python3/dist-packages/xmlschema/validators/schemas.py", line 
148, in __new__
624s meta_schema = 
meta_schema_class.create_meta_schema(meta_schema_file)
624s 
^^
624s   File 
"/usr/lib/python3/dist-packages/xmlschema/validators/schemas.py", line 
763, in create_meta_schema
624s meta_schema = meta_schema_class(source, XSD_NAMESPACE, 
global_maps=global_maps,
624s 
^
624s   File 
"/usr/lib/python3/dist-packages/xmlschema/validators/schemas.py", line 
357, in __init__

624s self.source = XMLResource(source, base_url, allow, defuse, timeout)
624s   ^
624s   File "/usr/lib/python3/dist-packages/xmlschema/resources.py", 
line 511, in __init__

624s self.parse(source, lazy)
624s   File "/usr/lib/python3/dist-packages/xmlschema/resources.py", 
line 746, in parse

624s url = normalize_url(source, self._base_url)
624s   ^
624s   File "/usr/lib/python3/dist-packages/xmlschema/resources.py", 
line 188, in normalize_url

624s path = _PurePath.from_uri(url)
624s^^^
624s   File "/usr/lib/python3/dist-packages/xmlschema/resources.py", 
line 109, in from_uri

624s return cls(uri)
624s
624s   File "/usr/lib/python3/dist-packages/xmlschema/resources.py", 
line 98, in __new__

624s return cast('_PurePath', cls._from_parts(args))
624s  ^^^
624s AttributeError: type object '_PurePosixPath' has no attribute 
'_from_parts'. Did you mean: '_load_parts'?

624s autopkgtest [20:06:43]: test autodep8-python3: ---]
624s autopkgtest [20:06:43]: test autodep8-python3:  - - - - - - - - - - 
results - - - - - - - - - -

624s autodep8-python3 FAIL non-zero exit status 1




This seems to be an issue related to xmlschema.
I will reassign.

cheers
--
Antonio Valentino

Bug#1056729: RFS: libnginx-mod-vts/0.2.2-1 [ITP] -- Virtual host traffic status (VTS) module for Nginx

[Gregor Jasny]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: pkg-nginx-maintain...@alioth-lists.debian.net

Dear mentors,

I am looking for a sponsor for my package "libnginx-mod-vts":

 * Package name : libnginx-mod-vts
   Version  : 0.2.2-1
   Upstream contact : YoungJoo.Kim (김영주) 
 * URL  : https://github.com/vozlt/nginx-module-vts
 * License  : BSD-2-clause
 * Vcs  : https://salsa.debian.org/gjasny-guest/libnginx-mod-vts
   Section  : httpd

The source builds the following binary packages:

  libnginx-mod-http-vhost-traffic-status - Virtual host traffic status (VTS) 
module for Nginx

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

  https://mentors.debian.net/package/libnginx-mod-vts/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libn/libnginx-mod-vts/libnginx-mod-vts_0.2.2-1.dsc

Changes for the initial release:

 libnginx-mod-vts (0.2.2-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1055012)

Regards,
Gregor Jasny

Bug#1056728: ITP: prometheus-flask-exporter -- Prometheus metrics exporter for Flask

[Guilherme Puida Moreira]

Package: wnpp
Severity: wishlist
Owner: Guilherme Puida Moreira 
X-Debbugs-Cc: debian-de...@lists.debian.org, guilhe...@puida.xyz

* Package name: prometheus-flask-exporter
  Version : 0.23.0
  Upstream Contact: Viktor Adam 
* URL : https://github.com/rycus86/prometheus_flask_exporter
* License : Expat
  Programming Lang: Python
  Description : Prometheus metrics exporter for Flask

This library provides HTTP request metrics to export into Prometheus.
It can also track method invocations using convenient functions.

This library will be used in image-finder [1].

I plan to maintain this package under the Debian Python Team's umbrella.

[1]: https://salsa.debian.org/cloud-team/image-finder

Bug#1053101: qemu-user-static: Without PIE emulator and targets map to same address

[Tj]

Package: qemu-user-static
Version: 1:7.2+dfsg-7+deb12u2
Followup-For: Bug #1053101

After building without `--disable-pie` and observing differences and
results I suspect the cause is something that is so obvious I missed it!

The emulator - when totally static - maps to 0x0004 itself. Then in
the target ld-linux-aarch64.so.1 tries to map a static aarch64
executable to the same address (0x0004) and since qemu doesn't
translate that in any way (could it?) the SIGSEGV occurs because the
emulator (qemu-aarch64-static) already uses that address.

However... the mmap() documentation suggests it should return -1 and set
errno and I'd expect that to be EEXIST MAP_FIXED_NOREPLACE.

However #2... those same docs state SIGSEGV when "Attempted write into a
region mapped as read-only" and that does make sense if the emulator's
.text is mapped there (presumably as PROT_EXEC|PROT_READ and
MAP_DENYWRITE).

Bug#1056595: dgit: must not override dpkg include lists

[Sean Whitton]

control: tag -1 + wontfix
control: close -1

Hello,

As has been explained, this bug is invalid, at least as currently titled
-- it's fundamental to the design of dgit that it behaves in this way.
If the discussion yields some ways in which dgit can become friendlier
to users and non-users, then it might be better to file new bugs with
those concrete change proposals.

Julien, given that you have decided not to use dgit in the near future,
it would have been more helpful to frame this bug explicitly in terms of
helping people like you, who have decided that.  As it stands, your
submission rather like a complaint, and that is not fair or kind to
those of us who work on dgit.  We don't want you to feel frustrated!

-- 
Sean Whitton


signature.asc
Description: PGP signature