Bug#909124: quilt: Please fail gracefully on 'quilt series' when less(1) is not installed

[Trent W. Buck]

I ran into the same bug, except PAGER=cat also fails.

I also tried fixing ${x-fallback} to the more normal ${x:-fallback}, but it did 
not help.

I do not understand why that is happening.

root@hera:/gdk-pixbuf# quilt series
/usr/share/quilt/scripts/patchfns: line 1128: less: command not found

root@hera:/gdk-pixbuf# PAGER=cat quilt series
/usr/share/quilt/scripts/patchfns: line 1128: less: command not found

root@hera:/gdk-pixbuf# env | grep PAGER
PAGER=cat

root@hera:/gdk-pixbuf# emacs /usr/share/quilt/scripts/patchfns +1128
root@hera:/gdk-pixbuf# git diff --no-index 
/usr/share/quilt/scripts/patchfns.~1~ /usr/share/quilt/scripts/patchfns
diff --git a/usr/share/quilt/scripts/patchfns.~1~ 
b/usr/share/quilt/scripts/patchfns
index 4a36335d..a7e6e54d 100644
--- a/usr/share/quilt/scripts/patchfns.~1~
+++ b/usr/share/quilt/scripts/patchfns
@@ -,7 +,7 @@ setup_pager()

# QUILT_PAGER = QUILT_PAGER | GIT_PAGER | PAGER | less -R
# NOTE: QUILT_PAGER='' is significant
-   QUILT_PAGER=${QUILT_PAGER-${GIT_PAGER-${PAGER-less -R}}}
+   QUILT_PAGER=${QUILT_PAGER:-${GIT_PAGER:-${PAGER:-less -R}}}

[ -z "$QUILT_PAGER" -o "$QUILT_PAGER" = "cat" ]  && return 0

root@hera:/gdk-pixbuf# PAGER=cat quilt series
/usr/share/quilt/scripts/patchfns: line 1128: less: command not found

Bug#1007804: amfora: AppArmor policy

[Jo Coscia]

Subject: amfora: AppArmor policy
Package: amfora
X-Debbugs-Cc: j...@jcoscia.com
Version: 1.9.2-2~bpo11+1
Severity: wishlist
Tags: patch

I would like to contribute an AppArmor policy for amfora. I asked the
folks in #apparmor about this, and they recommended going to the Debian
bug tracker.

I tested amfora with the following policy, and all features appear to
work correctly.

#include 

# vim:syntax=apparmor
# AppArmor policy for amfora

/usr/bin/amfora {
   #include 
   #include 
   #include 

   /etc/mime.types r,
   /etc/hosts r,
   /etc/resolv.conf r,
   /etc/nsswitch.conf r,
   /sys/kernel/mm/transparent_hugepage/hpage_pmd_size r,
   network tcp,

   # Allow opening/saving geminitext files; amfora only opens files with
these extensions
   /**.[gG][mM][iI] rw,
   /**.[gG][eE][mM][iI][nN][iI] rw,

   # Allow amfora to make these dirs, if they don't exist
   owner @{HOME}/.cache/ w,
   owner @{HOME}/.config/ w,
   owner @{HOME}/.local/ w,
   owner @{HOME}/.local/share/ w,

   owner @{HOME}/.cache/amfora/ rw,
   owner @{HOME}/.cache/amfora/** rw,
   owner @{HOME}/.config/amfora/ rw,
   owner @{HOME}/.config/amfora/** rw,
   owner @{HOME}/.local/share/amfora/ rw,
   owner @{HOME}/.local/share/amfora/** rw,

   owner @{HOME}/.config/user-dirs.dirs r,

   # Allows browsing/saving to a user-owned directory other than the
default Downloads directory. Supports removable media, etc. Restricting
it to only @{HOME}/Downloads/ would be more secure, but could cause
breakage.
   owner /**/ rw,

   # Allow amfora to open non-gemini URLs in other applications
   /usr/bin/xdg-open Ux,

}

Bug#1007803: plasma-pa: Could dependency on pulseaudio-module-gsettings be lessened?

[chris]

Package: plasma-pa
Version: 4:5.24.3-1
Severity: normal
X-Debbugs-Cc: inkbottle...@gmail.com

Dear Maintainer,

`plasma-pa` has `pulseaudio-module-gsettings` in its recommend dependencies and 
it is conflicting with `pipewire` / `wireplumber`, because it causes the 
installation of `pulseaudio`.

At the moment I don't have `pulseaudio-module-gsettings` installed, since it's 
only a recommend dependency, I'm not compelled to install it.

I've initially put that issue on `pulseaudio-module-gsettings` package, but the 
maintainer of this package said nothing could be fixed from his side. They also 
said that installing `pulseaudio` was not conflicting "per se" with `pipewire`. 
And I want to believe them. I think it does make more complicated to have 
`pipewire` working.


What you really want is the reverse dependencies (either
plasma-pa or paprefs) to not require gsettings, or get pipewire to
implement module-gsettings (and then add the alternative to each package).
See https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1066 and
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/771


Thanks,
Chris

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

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

Versions of packages plasma-pa depends on:
ii  libc62.33-7
ii  libcanberra0 0.30-8
ii  libglib2.0-0 2.70.4-1
ii  libkf5coreaddons55.90.0-1
ii  libkf5globalaccel-bin5.90.0-1
ii  libkf5globalaccel5   5.90.0-1
ii  libkf5i18n5  5.90.0-1
ii  libkf5notifications5 5.90.0-1
ii  libkf5quickaddons5   5.90.0-1
ii  libpulse-mainloop-glib0  15.0+dfsg1-4
ii  libpulse015.0+dfsg1-4
ii  libqt5core5a 5.15.2+dfsg-15
ii  libqt5dbus5  5.15.2+dfsg-15
ii  libqt5gui5   5.15.2+dfsg-15
ii  libqt5qml5   5.15.2+dfsg-10
ii  libqt5quick5 5.15.2+dfsg-10
ii  libqt5widgets5   5.15.2+dfsg-15
ii  libstdc++6   12-20220313-1
ii  perl 5.34.0-3
ii  pipewire-pulse   0.3.48-1
ii  plasma-framework 5.90.0-2
ii  qml-module-org-kde-draganddrop   5.90.0-1
ii  qml-module-org-kde-kquickcontrolsaddons  5.90.0-1
ii  qml-module-qtquick-controls  5.15.2-2
ii  qml-module-qtquick-layouts   5.15.2+dfsg-10
ii  qml-module-qtquick2  5.15.2+dfsg-10

Versions of packages plasma-pa recommends:
ii  libcanberra-pulse0.30-8
pn  pulseaudio-module-gsettings  
ii  qml-module-gsettings1.0  0.2-4
ii  sound-theme-freedesktop  0.8-2

plasma-pa suggests no packages.

-- no debconf information

Bug#969698: guile-gnome-platform: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

On 2020-09-15, Tommi Höynälänmaa wrote:
> su, 2020-09-06 kello 15:21 -0500, Rob Browning kirjoitti:
>> Please migrate to guile-3.0 as soon as it's feasible. If we can, I'd
>> like to have the option to drop guile-2.2 from bullseye, so that we
>> won't have to maintain two versions throughout that release.
...
> This message needs to be forwarded to guile-gnome-platform upstream
> authors if it has not been already done.

Upstream guile-gnome is unlikely to ever make another release; the last
release was a bugfix release in 2017:

  https://git.savannah.gnu.org/cgit/guile-gnome.git/log/


I talked to daviid on irc about it (possibly the David Pirotte from
"recent" git commits?), and they suggested to migrate to using guile-gi
or g-golf instead, as guile-gnome will not be updated to support guile
3.0.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#969673: g-wrap: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

On 2020-09-14, Göran Weinholt wrote:
> Tommi Höynälänmaa  writes:
>> su, 2020-09-06 kello 15:21 -0500, Rob Browning kirjoitti:
>>> Please migrate to guile-3.0 as soon as it's feasible. If we can, I'd
>>> like to have the option to drop guile-2.2 from bullseye, so that we
>>> won't have to maintain two versions throughout that release.

Upstream g-wrap is unlikely to ever make another release; there has been
no real development since 2015, with two minor commits as recently as
2018:

  https://git.savannah.nongnu.org/cgit/g-wrap.git/log/


I talked to daviid on irc about it (possibly the David Pirotte from
"recent" git commits?), and they suggested to migrate away from g-wrap,
as it will not be updated to use guile 3.0.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1005953: needrestart: user session restart needing detection broken probably by cgroupv2 from systemd 247.2-4

[Paul Wise]

Control: severity -1 important

On Fri, 18 Feb 2022 09:42:03 +0800 Paul Wise wrote:

> I've filed this at severity serious because it means that the user
> notification scripts in the needrestart package don't work, which means
> the needrestart-session package is not very useful any more.

It seems this bug is going to cause autoremoval on April 3rd. The
inclusion of needrestart in Debian in general is more important than
the user session functionality. The needrestart-session package has a
GUI tool that can be run manually, so it doesn't become entirely
useless. For these reasons I am decreasing the severity of this bug.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1007802: Subject: RFS: nvidia-vaapi-driver/0.0.5-1 [ITP] -- VA-API implementation that uses NVDEC as a backend

[YaNing Lu]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "nvidia-vaapi-driver":

 * Package name: nvidia-vaapi-driver
   Version : 0.0.5-1
   Upstream Author : Stephen 
 * URL : https://github.com/elFarto/nvidia-vaapi-driver
 * License : MIT
 * Vcs : https://salsa.debian.org/Dami/nvidia-vaapi-driver
   Section : video

It builds those binary packages:

  nvidia-vaapi-driver - VA-API implementation that uses NVDEC as a backend

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

  https://mentors.debian.net/package/nvidia-vaapi-driver/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nvidia-vaapi-driver/nvidia-vaapi-driver_0.0.5-1.dsc

Changes for the initial release:

 nvidia-vaapi-driver (0.0.5-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1007264)

Regards,
-- 
  Lu YaNing

Bug#787511: libpython3.9-stdlib: double embarassing failure in RFC2047 eMail header encoding

[Thorsten Glaser]

retitle 787511 libpython3.9-stdlib: double embarassing failure in RFC2047 eMail 
header encoding
found 787511 3.9.10-2
tags 787511 + bookworm sid
thanks

The bug’s also still pertinent in bullseye, see previous message,
as well as sid:

(sid-amd64)tglase@tglase:~ $ python3 x.py3 
pöstal foo bar baz foo bar baz foo bar baz foo bar baz
Subject: 
=?iso-8859-1?q?p=F6stal_foo_bar_baz_foo_bar_baz_foo_bar_baz_foo_bar_baz?=


[service-Aufgaben S][#19415] VM''s aufsetzen mit unterschiedlichen
Subject: 
=?utf-8?q?=5Bservice-Aufgaben_S=26W-Team=5D=5B=2319415=5D_VM=27=27s_aufsetzen_mit_unterschiedlichen?=


(sid-amd64)tglase@tglase:~ $ cat x.py3 
from email.message import Message
from email.header import Header
def testit(text, encoding):
msg = Message()
h = Header(text, encoding)
msg['Subject'] = h
print(h)
print(msg.as_string())
testit('p\xf6stal foo bar baz foo bar baz foo bar baz foo bar baz', 
'iso-8859-1')
testit("[service-Aufgaben S][#19415] VM''s aufsetzen mit 
unterschiedlichen", 'UTF-8')


It apparently was, *ahem*, “forgotten” because the name of the package
changed and the bug was not carried over to the new name…

Incidentally, no, reporting bugs regarding encoding issues upstream is
n̲o̲t̲ easily possible, because upstream’s bugtracker errors out with
encoding errors if trying that… see https://bugs.python.org/issue46701
(encoding in Python and py3k both is a neverending joke…)

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#969670: xbindkeys: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

Control: tags 969670 +patch

On 2020-09-06, Rob Browning wrote:
> Please migrate to guile-3.0 as soon as it's feasible. If we can, I'd
> like to have the option to drop guile-2.2 from bullseye, so that we
> won't have to maintain two versions throughout that release.

The attached patch builds successfully by just switching the build
dependencies to use guile 3.0. I haven't tested if the resulting package
works.

live well,
  vagrant
From fad7056da45211e8fc85a625032ae822ff53c5eb Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 17 Mar 2022 00:36:17 +
Subject: [PATCH] debian/rules: Switch to guile 3.0.

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index b654879..d0a1e10 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: x11
 Priority: optional
 Maintainer: Joerg Jaspert 
 Uploaders: Ricardo Mones 
-Build-Depends: debhelper-compat (= 13), libx11-dev, libxt-dev, guile-2.2-dev
+Build-Depends: debhelper-compat (= 13), libx11-dev, libxt-dev, guile-3.0-dev
 Standards-Version: 4.5.0
 Rules-Requires-Root: no
 Homepage: https://www.nongnu.org/xbindkeys/
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#969694: aisleriot: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

Control: tags 969694 +patch

I *meant* this bug.

live well,
  vagrant

On 2022-03-16, Vagrant Cascadian wrote:
> On 2020-09-06, Rob Browning wrote:
>> Please migrate to guile-3.0 as soon as it's feasible. If we can, I'd
>> like to have the option to drop guile-2.2 from bullseye, so that we
>> won't have to maintain two versions throughout that release.
>
> With the following two patches, aisleriot builds successfully with
> guile-3.0. I haven't tested that it functions correctly.


signature.asc
Description: PGP signature

Bug#1007801: ITS: python-scrypt

[Boyuan Yang]

Source: python-scrypt
Version: 0.8.19-0.1
Severity: important
X-Debbugs-CC: mi...@debian.org

Dear package python-scrypt maintainer in Debian,

After looking into the package you maintain (python-scrypt, 
https://tracker.debian.org/pkg/python-scrypt), I found that this package
received no maintainer uploads in the past 9 years. As a result, I am filing
an ITS (Intent to Salvage) request against your package according to section
5.12 in Debian's Developers' Reference [1].

My current plan is to package the latest upstream release and put this package
under Debian Python Team to allow possible team contribution.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(Apr. 06, 2022) to continue with the package salvaging.

If you find it necessary to pause the ITS process, please let me know
immediately by replying this bug report. Please also let me know if you would
like to be kept in the uploaders field if the package is to be team-maintained
under python-team.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#969683: dico: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

Control: tags 969683 +patch

On 2020-11-10, Marc Dequènes (duck) wrote:
> I packaged 2.10 and no Guile 3.0 support yet. I just sent a mail 
> upstream to ask if that would be feasible.

Builds successfully with with the attached patch, which switches the
build-dependencies to use guile 3.0. I haven't tested if it functions
correctly.

live well,
  vagrant
From 8ba9f2ec9e7a37a330aefe82644cac2c224d0778 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 17 Mar 2022 00:24:45 +
Subject: [PATCH] debian/control: Switch to guile 3.0.

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 3c2a872..614fc47 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,7 @@ Uploaders: أحمد المحمودي (Ahmed El-Mahmoudy) 
 Build-Depends: debhelper-compat (= 13),
dh-sequence-python3,
-   guile-2.2-dev,
+   guile-3.0-dev,
libgsasl7-dev,
libldap2-dev,
libltdl7-dev,
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1006233: transition: poppler

[Jeremy Bicha]

On Wed, Mar 16, 2022 at 3:42 PM Sebastian Ramacher  wrote:
> As libwebp finally migrated, please go ahead

Will poppler get entangled with the openldap transition?

https://release.debian.org/transitions/html/auto-poppler.html

Thanks,
Jeremy Bicha

Bug#969694: aisleriot: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

Control: tags 696694 +patch

On 2020-09-06, Rob Browning wrote:
> Please migrate to guile-3.0 as soon as it's feasible. If we can, I'd
> like to have the option to drop guile-2.2 from bullseye, so that we
> won't have to maintain two versions throughout that release.

With the following two patches, aisleriot builds successfully with
guile-3.0. I haven't tested that it functions correctly.


live well,
  vagrant
From 2d6adb9b3579bf105683898149c4c1e51736bd6e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 17 Mar 2022 00:04:27 +
Subject: [PATCH 1/3] configure.ac: Support guile 3.0.

---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index bab2a0b..70b104a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -476,13 +476,13 @@ IT_PROG_INTLTOOL([0.35.0])
 # Guile
 # *
 
-guile_versions_all="2.2 2.0"
+guile_versions_all="3.0 2.2 2.0"
 AC_MSG_CHECKING([which guile version to use])
 AC_ARG_WITH([guile],
   [AS_HELP_STRING([--with-guile=2.2|2.0|auto],[Which guile version to use (default: auto)])],
   [case "$with_guile" in
  1.8) AC_MSG_ERROR([unsupported guile version $with_guile requested]) ;;
- 2.0|2.2) guile_versions="$withval" ;;
+ 2.0|2.2|3.0) guile_versions="$withval" ;;
  auto) guile_versions="$guile_versions_all" ;;
  *) AC_MSG_ERROR([unsupported guile version $with_guile requested]) ;;
 esac],
-- 
2.30.2

From cffd680b327fe4b79339214255edb7541129946a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 17 Mar 2022 00:04:45 +
Subject: [PATCH 2/3] debian/control: Update guile to 3.0.

---
 debian/control| 2 +-
 debian/control.in | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 3806fdc..5832391 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends: debhelper-compat (= 12),
docbook-xml ,
lsb-release,
yelp-tools,
-   guile-2.2-dev,
+   guile-3.0-dev,
intltool (>= 0.35.0),
libcairo2-dev (>= 1.10),
libcanberra-gtk3-dev (>= 0.26),
diff --git a/debian/control.in b/debian/control.in
index 2000d00..28b4a31 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -9,7 +9,7 @@ Build-Depends: debhelper-compat (= 12),
docbook-xml ,
lsb-release,
yelp-tools,
-   guile-2.2-dev,
+   guile-3.0-dev,
intltool (>= 0.35.0),
libcairo2-dev (>= 1.10),
libcanberra-gtk3-dev (>= 0.26),
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1006978: closed by Debian FTP Masters (reply to Ricardo Ribalda Delgado ) (Bug#1006978: fixed in ugrep 3.7.5+dfsg-1)

[Peter Mueller]

reopen 1006978
found 1006978 3.7.5+dfsg-1
thanks
No, the bug is still there. The same goes for 
https://github.com/Genivia/ugrep/issues/193 
https://github.com/Genivia/ugrep/issues/193.  Ricardo, with all respect: if I 
asked you a specific question, there was also a specific reason for this. The 
developer seems to have produced a fix more or less blindly, without having the 
same Debian amd64 installation as I do. The result is that the bug still 
exists. So, you (or someone else) answering their question is crucial (myself, 
I can't – I simply know nothing about /sys and apparmor and too little about 
the Linux file system anyway). So, please, we all know how open-source 
development works and it may be unpaid, but still, I would kindly ask you to do 
it at your earliest convenience (if you technically can't, of course, please 
forward the request to someone who can).

Bug#969676: gnubik: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

Control: tags 969676 +patch

On 2020-09-06, Rob Browning wrote:
> Please migrate to guile-3.0 as soon as it's feasible. If we can, I'd
> like to have the option to drop guile-2.2 from bullseye, so that we
> won't have to maintain two versions throughout that release.

With the following two patches applied, gnubik builds successfully with
guile-3.0.


live well,
  vagrant
From 9a187c7bd4b8f29f123e3b27f0f055cb633f2b18 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 16 Mar 2022 23:43:55 +
Subject: [PATCH 1/3] configure.ac: Update to guile-3.0

---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 747cb0a..2db89c6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -70,7 +70,7 @@ PKG_CHECK_MODULES(GLU, glu,,
 
 
 dnl Checks for libraries.
-PKG_CHECK_MODULES(GUILE, guile-2.2,,
+PKG_CHECK_MODULES(GUILE, guile-3.0,,
   AC_SEARCH_LIBS([scm_c_string_length], [guile],,
 	AC_MSG_ERROR("Guile 2.0 or later is required"))
 )
-- 
2.30.2

From 02c137649aa41285dbd4340b45fea82aa99cc91a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 16 Mar 2022 23:44:45 +
Subject: [PATCH 2/3] debian/control: Update to guile 3.0.

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 13c8cfb..b343bf7 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Debian Games Team 
 Uploaders: Jonathan Carter 
 Build-Depends: debhelper-compat (= 12),
automake,
-   guile-2.2-dev,
+   guile-3.0-dev,
libgtkglext1-dev,
autoconf (>= 2.61),
gtk-update-icon-cache
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1007717: Native source package format with non-native version

[Wookey]

On 2022-03-16 15:29 +, Ian Jackson wrote:
> In practice, the vast majority of packages are maintained in git on
> salsa.  The maintainers use those git repositories as the PFM.

> but almost everyone is already treating git as primary.

Is this definitely true? For example: I know I'm not doing this. I did
try, and I do have some git repos on salsa, but I've mostly given up
with it all and stuck with uscan and tarballs and quilt (and my trusty
'packages' directory). It's much easier for me. (The salsa repos that
exist for my packages are not canonical and often stale).

I'm sure Ian is right that there is a trend towards git from tarballs
and dscs, but I just question whether we know it is 'the vast
majority'? Are there really now very few maintainers using the
'classic tooling'? How do we know?

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1007800: golang-golang-x-tools: FTBFS with Go 1.18

[William 'jawn-smith' Wilson]

Package: golang-golang-x-tools
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

golang-golang-x-tools currently FTBFS with Go 1.18

In Ubuntu, the attached patch was applied to achieve the following:


  * Fix FTBFS with Go 1.18


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-22-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-golang-x-tools-0.1.9+ds/debian/patches/0010-fix-ftbfs-with-go-1.18.patch 
golang-golang-x-tools-0.1.9+ds/debian/patches/0010-fix-ftbfs-with-go-1.18.patch
--- 
golang-golang-x-tools-0.1.9+ds/debian/patches/0010-fix-ftbfs-with-go-1.18.patch 
1969-12-31 18:00:00.0 -0600
+++ 
golang-golang-x-tools-0.1.9+ds/debian/patches/0010-fix-ftbfs-with-go-1.18.patch 
2022-03-16 18:36:11.0 -0500
@@ -0,0 +1,21 @@
+Description: Fix FTBFS with Go 1.18
+ At the time of this package upload, there was still a change
+ required for one of the test cases to succeed with Go 1.18.
+Origin: upstream, 
https://github.com/golang/tools/commit/845bb90a1df4ce4789c794479a29a4ea07e12414
+Applied-Upstream: 
https://github.com/golang/tools/commit/845bb90a1df4ce4789c794479a29a4ea07e12414
+Last-Update: 2022-03-16
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: 
golang-golang-x-tools-0.1.9+ds/go/types/objectpath/objectpath_go118_test.go
+===
+--- 
golang-golang-x-tools-0.1.9+ds.orig/go/types/objectpath/objectpath_go118_test.go
 golang-golang-x-tools-0.1.9+ds/go/types/objectpath/objectpath_go118_test.go
+@@ -79,7 +79,7 @@
+   wantErr string
+   }{
+   {types.Universe.Lookup("any"), "predeclared type any = 
interface{} has no path"},
+-  {types.Universe.Lookup("comparable"), "predeclared type 
comparable interface{} has no path"},
++  {types.Universe.Lookup("comparable"), "predeclared type 
comparable interface{comparable} has no path"},
+   } {
+   path, err := objectpath.For(test.obj)
+   if err == nil {
diff -Nru golang-golang-x-tools-0.1.9+ds/debian/patches/series 
golang-golang-x-tools-0.1.9+ds/debian/patches/series
--- golang-golang-x-tools-0.1.9+ds/debian/patches/series2022-02-23 
09:11:16.0 -0600
+++ golang-golang-x-tools-0.1.9+ds/debian/patches/series2022-03-16 
18:32:47.0 -0500
@@ -7,3 +7,4 @@
 0007-skip-tests-that-run-go-build.patch
 0008-skip-test-needs-go-mod.patch
 0009-skip-license-testing.patch
+0010-fix-ftbfs-with-go-1.18.patch

Bug#1007799: missing thermal driver for sun8i platforms running Bullseye 11.2

[Simon Vetter]

Package: linux-image-armmp-lpae
Version: 5.10.103-1

On a freshly installed NanoPi NEO (sunxi 8) system running Bullseye 11.2 (all 
updates applied), the kernel is lacking the sun8i_thermal driver, preventing 
CPU temperature readings as well as thermal throttling operation.
Depending on system load and thermal environment (ambient temperature, 
enclosure, heatsink, etc.), this may lead to overheating and/or damage to the 
hardware.

# grep SUN8I_THERMAL /boot/config-5.10.0-12-armmp-lpae
# CONFIG_SUN8I_THERMAL is not set

Recompiling the kernel with that config option set to 'm' solved the issue 
(i.e. CONFIG_SUN8I_THERMAL=m), and I've been able to confirm that thermal 
throttling is indeed operational.


Would you be able to change that config option and push an updated package?

I figured I'd send a bug report 
sincehttps://wiki.debian.org/InstallingDebianOn/Allwinner  lists the NanoPi NEO 
as stable/untested and welcomes reports.

I believe other sun8i-based systems should be affected as well, but the NanoPi 
NEO is the only one I have around to play with.

Cheers,
-Simon

--
Simon Vetter - CEO
Vetter Technolgies

Bug#1006830: elpa-mailscripts: notmuch-slurp-debbugs misses messages

[Sean Whitton]

Hello Vagrant,

On Wed 16 Mar 2022 at 04:24PM -07, Vagrant Cascadian wrote:

> Not sure if this is an entirely different or related problem, but also
> having issues with 969697, this time getting none of the messages on the
> bug.

If the problem really is the lack of tilde expansion, it would be a
different bug, because tilde expansion not working would mean you get no
message, rather than some.

> So I tried the commandline interface instead, which had some curious
> messages:
>
>   $ notmuch-slurp-debbug 969697
>   WARNING: Folder does not exist, failed opening maildir folder 
> ~/Mail/debian/INBOX.debian-bugs/.

Erk, why doesn't it die at that point?!

> So, ~/Mail/debian/INBOX.debian-bugs/ definitely does exist, and seems to
> be a valid Maildir. If it matters, ~/Mail/debian is a symlink.
>
> My .config/mailscripts/notmuch-slurp-debbug contains:
>
>   maildir = ~/Mail/debian/INBOX.debian-bugs/
>
> Also not sure why it thinks the .mbox file is a read-only folder ... it
> appears writeable:
>
>   $ ls -latr .cache/devscripts/bts/969697.mbox
>   -rw-r--r-- 1 vagrant vagrant 11605 Mar 16 16:12 
> .cache/devscripts/bts/969697.mbox

It's just because it's opened read-only by the script.

> And Now I Tried Changing .config/mailscripts/notmuch-slurp-debbug to:
>
>   maildir = /home/vagrant/debian/INBOX.debian-bugs/
>
>
> Which at least works, with no errors or warnings from
> notmuch-slurp-debbug.
>
> The ~ for the homedir definitely *used* to be supported; been using it
> since at least ~debconf18 that way. :)

Hmm... I don't see how it could have worked before.  Does this fix it:

> diff --git a/notmuch-slurp-debbug b/notmuch-slurp-debbug
> index ad0db47..1568d9c 100755
> --- a/notmuch-slurp-debbug
> +++ b/notmuch-slurp-debbug
> @@ -50,7 +50,7 @@ if (-f $conf_f) {
>  $maildir = catfile $database_path, "inbox";
>  }
>  $maildir = $mgr->open(
> -folder=> $maildir,
> +folder=> glob $maildir,
>  access=> "a",
>  keep_dups => 1,
>  type  => "maildir"

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#969697: autogen: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

Control: tags 969697 +patch

On 2020-09-13, Bruce Korb wrote:
> I am ripping out Guile version checks. That means that if they change
> their interfaces again, AutoGen will stop working in inexplicable ways
> and it will take hours of work to determine the cause. But that risk
> seems small now, so updating the acceptable Guile version looks like
> more trouble than a mutation of the interface.
>
> I am trying to upload to alpha.gnu.org a new version 5.19.90 -- a 
> pre-release for 5.20. It looks like I successfully got some source RPMs 
> up there, but the distribution tarballs aren't seeming to make it. I'll 
> keep trying.

It seems like there is still a version check in config/guile.m4 in
5.19.96 from from debian experimental.

With the attached patches, it builds and passes the test suites using
guile 3.0.

live well,
  vagrant
From 32956b18f09cdc436f96e006a5486ba23d989c9e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 16 Mar 2022 22:36:18 +
Subject: [PATCH 1/2] config/guile.m4: Allow guile 3.0.

---
 config/guile.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config/guile.m4 b/config/guile.m4
index 89823e9..1338fbc 100644
--- a/config/guile.m4
+++ b/config/guile.m4
@@ -61,7 +61,7 @@
 #
 AC_DEFUN([GUILE_PKG],
  [PKG_PROG_PKG_CONFIG
-  _guile_versions_to_search="m4_default([$1], [2.2 2.0 1.8])"
+  _guile_versions_to_search="m4_default([$1], [3.0 2.2 2.0 1.8])"
   if test -n "$GUILE_EFFECTIVE_VERSION"; then
 _guile_tmp=""
 for v in $_guile_versions_to_search; do
-- 
2.30.2

From a21423407b216bfd9873572072700d02b73fe5ca Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 16 Mar 2022 22:36:44 +
Subject: [PATCH 2/2] debian/control, debian/rules: Switch to guile 3.0.

---
 debian/control | 2 +-
 debian/rules   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 92d5f82..c28789c 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Andreas Metzler 
 Build-Depends: chrpath,
  debhelper-compat (= 13),
  gperf,
- guile-2.2-dev,
+ guile-3.0-dev,
  libxml2-dev,
  pkg-config,
  tar (>= 1.28),
diff --git a/debian/rules b/debian/rules
index 8f298af..fb8e331 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,7 +22,7 @@ override_dh_auto_configure:
 		--with-libxml2-libs="$(shell $(DEB_HOST_GNU_TYPE)-pkg-config --libs libxml-2.0)" \
 		--with-libxml2-cflags="$(shell $(DEB_HOST_GNU_TYPE)-pkg-config --cflags libxml-2.0)" \
 		GREP=/bin/grep POSIX_SHELL=/bin/sh SHELL=/bin/sh \
-		CONFIG_SHELL=/bin/bash
+		CONFIG_SHELL=/bin/bash GUILE=/usr/bin/guile-3.0
 
 override_dh_auto_build:
 	dh_auto_build --verbose
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1006830: elpa-mailscripts: notmuch-slurp-debbugs misses messages

[Vagrant Cascadian]

On 2022-03-09, Sean Whitton wrote:
> On Sun 06 Mar 2022 at 07:25AM -08, Vagrant Cascadian wrote:
>> On 2022-03-06, Sean Whitton wrote:
>>> Could you determine whether downloading the mailbox like this contains
>>> the message:
>>>
>>> bts --bts-server https://bugs.debian.org --mbox --mailreader "true %s" 
>>> show 1004939
>>
>> It didn't appear to visibly do anything (I guess true is a very low
>> interactive mailreader), although the .mbox did land in
>> .cache/devscripts/bts/ and contains the mentioned Message-Id:
>>
>>   $ grep ltfe7r.ccn2zwkm4w...@pappacoda.it .cache/devscripts/bts/1004939.mbox
>>   Message-Id: 
>>   References:  <87czk3pluc.fsf@contorta>
>>   In-Reply-To: 
>>
>> The references/in-repy-to's are from my reply to the message after
>> having manually imported the message into my maildir...
>
> Thanks.  As it is included in the downloaded mbox, we can assume that
> notmuch-slurp-debbug(1) is skipping over that message somehow, or
> notmuch isn't processing it, or something like that.
>
> Unfortunately I can't reproduce here, however -- I get all three
> messages for #1004939.  Let's keep this bug open as you've seen this
> more than once.  Let me know if you have other cases.

Not sure if this is an entirely different or related problem, but also
having issues with 969697, this time getting none of the messages on the
bug.

So I tried the commandline interface instead, which had some curious
messages:

  $ notmuch-slurp-debbug 969697
  WARNING: Folder does not exist, failed opening maildir folder 
~/Mail/debian/INBOX.debian-bugs/.
  Use of uninitialized value $name in string eq at 
/usr/share/perl5/Mail/Box/Manager.pm line 296.
  Use of uninitialized value $name in string eq at 
/usr/share/perl5/Mail/Box/Manager.pm line 296.
  Use of uninitialized value $name in pattern match (m//) at 
/usr/share/perl5/Mail/Box/Dir.pm line 105.
  Use of uninitialized value $dir in substitution (s///) at 
/usr/share/perl5/Mail/Box/Dir.pm line 106.
  Use of uninitialized value $directory in -d at 
/usr/share/perl5/Mail/Box/MH.pm line 99.
  Use of uninitialized value $name in pattern match (m//) at 
/usr/share/perl5/Mail/Box/Dir.pm line 105.
  Use of uninitialized value $dir in substitution (s///) at 
/usr/share/perl5/Mail/Box/Dir.pm line 106.
  Use of uninitialized value $directory in concatenation (.) or string at 
/usr/share/perl5/Mail/Box/Maildir.pm line 77.
  Use of uninitialized value $name in string eq at 
/usr/share/perl5/Mail/Box/Manager.pm line 296.
  Use of uninitialized value $name in string eq at 
/usr/share/perl5/Mail/Box/Manager.pm line 296.
  Use of uninitialized value $name in pattern match (m//) at 
/usr/share/perl5/Mail/Box/Dir.pm line 105.
  Use of uninitialized value $dir in substitution (s///) at 
/usr/share/perl5/Mail/Box/Dir.pm line 106.
  Use of uninitialized value $directory in -d at 
/usr/share/perl5/Mail/Box/MH.pm line 99.
  Use of uninitialized value $name in pattern match (m//) at 
/usr/share/perl5/Mail/Box/Dir.pm line 105.
  Use of uninitialized value $dir in substitution (s///) at 
/usr/share/perl5/Mail/Box/Dir.pm line 106.
  Use of uninitialized value $directory in concatenation (.) or string at 
/usr/share/perl5/Mail/Box/Maildir.pm line 77.
  Use of uninitialized value $name in string eq at 
/usr/share/perl5/Mail/Box/Manager.pm line 296.
  Use of uninitialized value $name in string eq at 
/usr/share/perl5/Mail/Box/Manager.pm line 296.
  Use of uninitialized value $name in pattern match (m//) at 
/usr/share/perl5/Mail/Box/Dir.pm line 105.
  Use of uninitialized value $dir in substitution (s///) at 
/usr/share/perl5/Mail/Box/Dir.pm line 106.
  Use of uninitialized value $directory in -d at 
/usr/share/perl5/Mail/Box/MH.pm line 99.
  Use of uninitialized value $name in pattern match (m//) at 
/usr/share/perl5/Mail/Box/Dir.pm line 105.
  Use of uninitialized value $dir in substitution (s///) at 
/usr/share/perl5/Mail/Box/Dir.pm line 106.
  Use of uninitialized value $directory in concatenation (.) or string at 
/usr/share/perl5/Mail/Box/Maildir.pm line 77.
  Use of uninitialized value $name in string eq at 
/usr/share/perl5/Mail/Box/Manager.pm line 296.
  Use of uninitialized value $name in string eq at 
/usr/share/perl5/Mail/Box/Manager.pm line 296.
  Use of uninitialized value $name in pattern match (m//) at 
/usr/share/perl5/Mail/Box/Dir.pm line 105.
  Use of uninitialized value $dir in substitution (s///) at 
/usr/share/perl5/Mail/Box/Dir.pm line 106.
  Use of uninitialized value $directory in -d at 
/usr/share/perl5/Mail/Box/MH.pm line 99.
  Use of uninitialized value $name in pattern match (m//) at 
/usr/share/perl5/Mail/Box/Dir.pm line 105.
  Use of uninitialized value $dir in substitution (s///) at 
/usr/share/perl5/Mail/Box/Dir.pm line 106.
  Use of uninitialized value $directory in concatenation (.) or string at 
/usr/share/perl5/Mail/Box/Maildir.pm line 77.
  Use of uninitialized value $name in string eq at 
/usr/share/perl5/Mail/Box/Manager.pm line 296.
  Use of 

Bug#1007798: fenics-dolfinx: sporadic python MPI unit test failure in test_sub_bbtree_box: incompatible constructor arguments

[Drew Parsons]

Source: fenics-dolfinx
Version: 1:0.3.0-13+b1
Severity: normal
Control: forwarded -1 https://github.com/FEniCS/dolfinx/issues/2070

The rebuild of dolfinx against PETSc 3.16 has started showing a debci
failure in the python MPI unit test failure test_sub_bbtree_box (in
python/test/unit/geometry/test_bounding_box_tree.py).

The failure is not consistent.  It can be reproduced directly from the
geometry test dir (copy dolfinx_utils into it first), with

  mpirun -n 2 python3 -mpytest test_bounding_box_tree.py


But while that reproduces the failure, it does not *always* reproduce
it. Sometimes the test passes.

Bug filed upstream at https://github.com/FEniCS/dolfinx/issues/2070

Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff updated

[Felix Lechner]

Hi,

The attached debdiff contains an updated d/changelog (plus, an excerpt below):

(1) The target release now says 'bullseye'.
(2) Pursuant to a request from the security team, the annotation
CVE-2021-37155 was added to PR 3990.

Is this ready to upload? Thanks!

Kind regards,
Felix Lechner

* * *

wolfssl (4.6.0+p1-1) bullseye; urgency=medium

  * Stable update to address the following vulnerabilities. All fixes were
backported by upstream:
- PR 3676: CVE-2021-3336
- PR 3990: CVE-2021-37155 (OCSP Match Issue)
- PR 4211: CVE-2021-38597
- PR 4629: CVE-2021-44718
- PR 4813: CVE-2022-25638
- PR 4831: CVE-2022-25640
  * Drop 58f9b6ec01f0caf89e9e4d37a8816b310005aaf1.patch, which was previously
cherry-picked from upstream.
  * Upstream updated some certificates in the test suite.

 -- Felix Lechner   Mon, 14 Mar 2022 15:45:37 -0700


wolfssl_4.6.0-3.dsc_wolfssl_4.6.0+p1-1.dsc.debdiff.xz
Description: application/xz

Bug#1007725: linux-image-5.16.0-4-amd64: Intel Alder Lake-P audio device not detected correctly

[Salvatore Bonaccorso]

Hi

On Wed, Mar 16, 2022 at 10:19:41AM +, Sean Clarke wrote:
> updated to kernel 5.17rc8 (needed for another bug I raised) and downloaded
> version 1.9.3 of intel-signed sof-adl.ri from the SOF Project (
> https://github.com/thesofproject).
> 
> The sound is now recognised, I can hear audio - when "test right" is played
> no audio is observed, when "tet left" is selected both speaks appear to
> work - so its working, but not quite.
> 
> Who is responsible for packaging the firmware-sof-signed package? looks
> like it needs updating.

So this would be fixed in the 2.0 version as uploaded
https://tracker.debian.org/news/1301129/accepted-firmware-sof-20-1-source-into-unstable/
?

Unfortunately there seems to have been a problem with that upload, as
the arch:all packages are missing.

Regards,
Salvatore

Bug#1006905: ostree 2020.8-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006905 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: ostree
Version: 2020.8-2+deb11u1

Explanation: fix compatibility with eCryptFS; avoid infinite recursion when 
recovering from certain errors; mark commits as partial before downloading; fix 
an assertion failure when using a backport or local build of GLib >= 2.71; fix 
the ability to fetch OSTree content from paths containing non-URI characters 
(such as backslashes) or non-ASCII

Bug#1006883: python-pip 20.3.4-4+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006883 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: python-pip
Version: 20.3.4-4+deb11u1

Explanation: avoid a race-condition when using zip-imported dependencies

Bug#1006797: galera-4 26.4.11-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006797 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: galera-4
Version: 26.4.11-0+deb11u1

Explanation: new upstream release

Bug#1006796: galera-3 25.3.36-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006796 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: galera-3
Version: 25.3.36-0+deb11u1

Explanation: new upstream release

Bug#1006768: golang-1.15 1.15.15-1~deb11u4 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006768 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: golang-1.15
Version: 1.15.15-1~deb11u4

Explanation: fix stack exhaustion compiling deeply nested expressions 
[CVE-2022-24921]

Bug#1006752: epiphany-browser 3.38.2-1+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006752 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: epiphany-browser
Version: 3.38.2-1+deb11u2

Explanation: work around a bug in GLib, fixing a UI process crash

Bug#1006371: lemonldap-ng 2.0.11+ds-4+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006371 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: lemonldap-ng
Version: 2.0.11+ds-4+deb11u1

Explanation: fix auth process in password-testing plugins [CVE-2021-40874]

Bug#1006215: node-prismjs 1.23.0+dfsg-1+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006215 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: node-prismjs
Version: 1.23.0+dfsg-1+deb11u2

Explanation: escape markup in command line output [CVE-2022-23647]; update 
minified files to ensure that Regular Expression Denial of Service issue is 
resolved [CVE-2021-3801]

Bug#1005868: bible-kjv 4.34+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1005868 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: bible-kjv
Version: 4.34+deb11u1

Explanation: fix off-by-one-error in search

Bug#1003173: nvidia-cuda-toolkit 11.2.2-3+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1003173 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: nvidia-cuda-toolkit
Version: 11.2.2-3+deb11u1

Explanation: cuda-gdb: Disable non-functional python support causing 
segmentation faults; use a snapshot of openjdk-8-jre (8u312-b07-1)

Bug#1003133: glx-alternatives 1.2.1~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1003133 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: glx-alternatives
Version: 1.2.1~deb11u1

Explanation: after initial setup of the diversions, install a minimal 
alternative to the diverted files so that libraries are not missing until 
glx-alternative-mesa processes its triggers

Bug#1003526: node-follow-redirects 1.13.1-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1003526 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: node-follow-redirects
Version: 1.13.1-1+deb11u1

Explanation: don't send Cookie header across domains [CVE-2022-0155]; don't 
send confidential headers across schemes [CVE-2022-0536]

Bug#1006010: php-crypt-gpg 1.6.4-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006010 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: php-crypt-gpg
Version: 1.6.4-2+deb11u1

Explanation: prevent additional options being passed to GPG [CVE-2022-24953]

Bug#1002012: sysvinit 2.96-7+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1002012 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: sysvinit
Version: 2.96-7+deb11u1

Explanation: fix parsing of "shutdown +0"; clarify that when called with a 
"time" shutdown will not exit

Bug#1001661: notcurses: flaky autopkgtests on armhf

[Paul Gevers]

Control: severity -1 serious
Control: found -1 3.0.7+dfsg.1-1

On Mon, 13 Dec 2021 22:26:10 +0100 Sebastian Ramacher 
 wrote:

For a recent failure see
https://ci.debian.net/data/autopkgtest/testing/armhf/n/notcurses/17505950/log.gz


https://ci.debian.net/data/autopkgtest/testing/armhf/n/notcurses/20022214/log.gz

https://ci.debian.net/data/autopkgtest/testing/armhf/n/notcurses/19977381/log.gz

https://ci.debian.net/data/autopkgtest/testing/armhf/n/notcurses/19573842/log.gz

https://ci.debian.net/data/autopkgtest/testing/armhf/n/notcurses/18318908/log.gz

https://ci.debian.net/data/autopkgtest/testing/armhf/n/notcurses/18235559/log.gz

https://ci.debian.net/data/autopkgtest/testing/armhf/n/notcurses/18231285/log.gz

All timeout after 2:47 hours.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004915: transition: ruby2.7-rm

[Paul Gevers]

Hi,

On 16-03-2022 22:18, Lucas Kanashiro wrote:

The problem is that it did not migrated yet, some regressions were reported.


If you mean autopkgtest regressions found by ci, than those should be 
dealt with now.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004915: transition: ruby2.7-rm

[Lucas Kanashiro]

Hi,

Em 16/03/2022 17:20, Paul Gevers escreveu:
> Hi,
>
> On 07-03-2022 23:36, Lucas Kanashiro wrote:
>> I uploaded ruby-defaults/1:3.0+1 removing ruby2.7 support.
>
> Thanks for that. It looked like the transition was nearly over, but
> britney (rightfully) refuses to remove src:ruby2.7. It took me some
> time, but it's because some packages depend on ruby-rexml, which is
> only provided by libruby2.7.
>
> Any proposal for a way forward?

This was an issue in the script to generate the Provides of libruby3.0.
It was fixed in ruby3.0/3.0.3-1, this is the commit:

https://salsa.debian.org/ruby-team/ruby/-/commit/e6d192830071320905729c8560dbcb7fc5a99746

The problem is that it did not migrated yet, some regressions were reported.

-- 
Lucas Kanashiro

Bug#1007793: ovmf: edk2-stable202202 not working with QEMU NVMe

[dann frazier]

On Wed, Mar 16, 2022 at 09:15:16PM +0100, Mara Sophie Grosch wrote:
> Package: ovmf
> Version: 2022.02-2
> Severity: important
> Tags: upstream patch
> 
> Hi,
> 
> the latest edk2 stable release (202202) introduces an issue with the
> NVMe controller in QEMU, recognizing it as not support NVMe command set.
> 
> The problem was introduced by a recent change for a new feature (boot
> partition), making broken code look at more bits of the "command sets
> supported" register and thus failing by the value QEMU sets.
> 
> I submitted a patch upstream via GitHub PR [1], but since I got bitten by
> this via debian package, I figured I report this here, too.

Thanks Mara! I've *'d your PR to keep an eye on it.

  -dann

Bug#1007795: src:mailutils: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: mailutils
Version: 1:3.13-1
Severity: serious
Control: close -1 1:3.14-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1003755

Dear maintainer(s),

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


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=mailutils



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007794: sia: FTBFS with Go 1.18

[William 'jawn-smith' Wilson]

Package: sia
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

sia currently FTBFS with Go 1.18 due to the increased checks for unused
variables

In Ubuntu, the attached patch was applied to achieve the following:


  * Fix FTBFS with Go 1.18


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-22-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru sia-1.3.0/debian/control sia-1.3.0/debian/control
--- sia-1.3.0/debian/control2020-09-09 18:21:01.0 -0500
+++ sia-1.3.0/debian/control2022-03-16 15:30:07.0 -0500
@@ -1,8 +1,7 @@
 Source: sia
 Section: net
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Go Packaging Team 

+Maintainer: Debian Go Packaging Team 

 Uploaders: Free Ekanayaka , Bjorn Dolk 
 Build-Depends: debhelper (>= 10),
dh-golang,
diff -Nru sia-1.3.0/debian/patches/0003-fix-ftbfs-with-go1.18.patch 
sia-1.3.0/debian/patches/0003-fix-ftbfs-with-go1.18.patch
--- sia-1.3.0/debian/patches/0003-fix-ftbfs-with-go1.18.patch   1969-12-31 
18:00:00.0 -0600
+++ sia-1.3.0/debian/patches/0003-fix-ftbfs-with-go1.18.patch   2022-03-16 
15:30:05.0 -0500
@@ -0,0 +1,31 @@
+Description: Fix FTBFS with Go 1.18
+ Go 1.18 is more strict about unused variables. This package
+ has an unused variable that is currently causing an FTBFS.
+ The change will not be upstreamed as the repository has
+ been archived by the owner and is therefore read-only.
+Author: William 'jawn-smith' Wilson 
+Origin: Ubuntu
+Forwarded:
+Last-Update: 2022-03-16
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: sia-1.3.0/modules/host/contractmanager/storagefolderempty.go
+===
+--- sia-1.3.0.orig/modules/host/contractmanager/storagefolderempty.go
 sia-1.3.0/modules/host/contractmanager/storagefolderempty.go
+@@ -51,7 +51,6 @@
+   wal.mu.Lock()
+   storageFolders := wal.cm.availableStorageFolders()
+   wal.mu.Unlock()
+-  var syncChan chan struct{}
+   for len(storageFolders) >= 1 {
+   var storageFolderIndex int
+   err := func() error {
+@@ -134,7 +133,6 @@
+   delete(wal.cm.sectorLocations, oldSU.ID)
+   delete(sf.availableSectors, id)
+   wal.cm.sectorLocations[id] = sl
+-  syncChan = wal.syncChan
+   wal.mu.Unlock()
+   return nil
+   }()
diff -Nru sia-1.3.0/debian/patches/series sia-1.3.0/debian/patches/series
--- sia-1.3.0/debian/patches/series 2017-10-31 18:54:54.0 -0500
+++ sia-1.3.0/debian/patches/series 2022-03-16 15:28:11.0 -0500
@@ -1,2 +1,3 @@
 0001-fix-log-dir.patch
 0002-inconshreveable-muxado.patch
+0003-fix-ftbfs-with-go1.18.patch

Bug#975684: [la...@debian.org: Bug#1005955: paper-icon-theme: please make the build reproducible]

[Eriberto]

Em qua., 16 de mar. de 2022 às 17:15, Jody Bruchon
 escreveu:
>
> I'll get on this issue as soon as possible. It may be next week, but I'll 
> work on it by then.

Thanks a lot Jody. When done, I will test with paper-icon-theme,
before sending it to Debian. If all is right, I think I will reassign
the bug to jdupes package and close the bug.

Cheers,

Eriberto


>
> On March 16, 2022 4:05:10 PM EDT, Carlos Henrique Lima Melara 
>  wrote:
>>
>> Hi, Jody and Eriberto.
>>
>> Recently I've received a patch [1] to make paper reproducible, the email
>> contained relevant information about the problem of reproducibility in
>> regards to filesystem operations and concerns. Therefore, I'm forwarding
>> 2 emails to you in hope it can be of assistance.
>>
>> Regards,
>> Charles
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005955
>>
>> - Forwarded message from Chris Lamb  -
>>
>> Date: Thu, 17 Feb 2022 17:47:08 -0800
>> From: Chris Lamb 
>> To: sub...@bugs.debian.org
>> Subject: Bug#1005955: paper-icon-theme: please make the build reproducible
>> X-Mailer: MessagingEngine.com Webmail Interface
>> User-Agent: 
>> Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997
>>
>> Source: paper-icon-theme
>> Version: 1.5.0+git20200312.aa3e8af-3
>> Severity: wishlist
>> Tags: patch
>> User: reproducible-bui...@lists.alioth.debian.org
>> Usertags: filesystem
>> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>>
>> Hi,
>>
>> Whilst working on the Reproducible Builds effort [0] we noticed that
>> paper-icon-theme could not be built reproducibly.
>>
>> This is caused by jdupes iterating over its arguments using the
>> filesystem ordering, instead of using their filenames. A patch is
>> attached that sorts the input prior to passing it to jdupes (using
>> find, sort and xargs), but it may be more sensible that jdupes does
>> this itself. Indeed, the jdupes manpage implies that it should do
>> this, but I leave this up to your (almost certainly more informed)
>> judgement.
>>
>>  [0] https://reproducible-builds.org/
>>
>>
>> Regards,
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#1004915: transition: ruby2.7-rm

[Paul Gevers]

Hi,

On 07-03-2022 23:36, Lucas Kanashiro wrote:

I uploaded ruby-defaults/1:3.0+1 removing ruby2.7 support.


Thanks for that. It looked like the transition was nearly over, but 
britney (rightfully) refuses to remove src:ruby2.7. It took me some 
time, but it's because some packages depend on ruby-rexml, which is only 
provided by libruby2.7.


Any proposal for a way forward?

Paul

ruby-google-api-client depends on ruby-rexml
ruby-kramdown depends on ruby-rexml
ruby-prawn-svg depends on ruby-rexml (>= 3.2)
ruby-vagrant-cloud depends on ruby-rexml (>= 3.2)
vagrant depends on ruby-rexml
vagrant-libvert depends on ruby-rexml


OpenPGP_signature
Description: OpenPGP digital signature

Bug#975684: [la...@debian.org: Bug#1005955: paper-icon-theme: please make the build reproducible]

[Jody Bruchon]

I'll get on this issue as soon as possible. It may be next week, but I'll work 
on it by then.

On March 16, 2022 4:05:10 PM EDT, Carlos Henrique Lima Melara 
 wrote:
>Hi, Jody and Eriberto.
>
>Recently I've received a patch [1] to make paper reproducible, the
>email
>contained relevant information about the problem of reproducibility in
>regards to filesystem operations and concerns. Therefore, I'm
>forwarding
>2 emails to you in hope it can be of assistance.
>
>Regards,
>Charles
>
>[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005955
>
>- Forwarded message from Chris Lamb  -
>
>Date: Thu, 17 Feb 2022 17:47:08 -0800
>From: Chris Lamb 
>To: sub...@bugs.debian.org
>Subject: Bug#1005955: paper-icon-theme: please make the build
>reproducible
>X-Mailer: MessagingEngine.com Webmail Interface
>User-Agent:
>Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997
>
>Source: paper-icon-theme
>Version: 1.5.0+git20200312.aa3e8af-3
>Severity: wishlist
>Tags: patch
>User: reproducible-bui...@lists.alioth.debian.org
>Usertags: filesystem
>X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
>Hi,
>
>Whilst working on the Reproducible Builds effort [0] we noticed that
>paper-icon-theme could not be built reproducibly.
>
>This is caused by jdupes iterating over its arguments using the
>filesystem ordering, instead of using their filenames. A patch is
>attached that sorts the input prior to passing it to jdupes (using
>find, sort and xargs), but it may be more sensible that jdupes does
>this itself. Indeed, the jdupes manpage implies that it should do
>this, but I leave this up to your (almost certainly more informed)
>judgement.
>
> [0] https://reproducible-builds.org/
>
>
>Regards,
>
>-- 
>  ,''`.
> : :'  : Chris Lamb
> `. `'`  la...@debian.org / chris-lamb.co.uk
>   `-
>
>--- a/debian/rules 2022-02-17 17:21:20.786897478 -0800
>--- b/debian/rules 2022-02-17 17:40:21.992308727 -0800
>@@ -7,4 +7,4 @@
> override_dh_auto_install:
>   dh_auto_install
>   # Remove duplicate files using softlinks
>-  jdupes -lr debian/paper-icon-theme/usr/share/icons
>+  find -type f -print0 debian/paper-icon-theme/usr/share/icons | sort
>-z | xargs -0r jdupes -Ol
>
>
>- End forwarded message -
>
>- Forwarded message from Chris Lamb  -
>
>Date: Tue, 08 Mar 2022 12:49:02 -
>From: Chris Lamb 
>To: Carlos Henrique Lima Melara 
>Cc: 1005955-qu...@bugs.debian.org
>User-Agent:
>Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997
>Subject: Re: paper-icon-theme: please make the build reproducible
>
>Hi Carlos,
>
>> Actually, I wasn't able to reproduce this issue on my machine. I
>tested
>> back when the issue appeared and now that you submitted the patch and
>> the builds on my machine are identical.
>
>Ah, perhaps I could have helped here: given this is a filesystem
>ordering issue, it's unsurprising that you could not easily reproduce
>it locally.
>
>Unless you use disorderfs or similar, most file systems will happen to
>return directory entries in the same order if asked multiple times in
>a row — the underlying problem is that this is not defined and/or
>deterministic.
>
>
>Best wishes,
>
>--
>  ,''`.
> : :'  : Chris Lamb
> `. `'`  la...@debian.org  chris-lamb.co.uk
>
>
>- End forwarded message -

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#1000341: mariadb-10.3 10.3.34-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1000341 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: mariadb-10.3
Version: 10.3.34-0+deb10u1

Explanation: new upstream stable release; security fixes [CVE-2021-35604 
CVE-2021-46659 CVE-2021-46661 CVE-2021-46662 CVE-2021-46663 CVE-2021-46664 
CVE-2021-46665 CVE-2021-46667 CVE-2021-46668 CVE-2022-24048 CVE-2022-24050 
CVE-2022-24051 CVE-2022-24052]

Bug#1007750: libnfsidmap_0.25-6+b1_mips64el-buildd.changes REJECTED

[Andreas Beckmann]

Followup-For: Bug #1007750
Control: tag -1 sid bookworm
Control: retitle -1 src:libnfsidmap: libnfsidmap-dev is also built by 
src:nfs-utils

libnfsidmap | 0.25-6| stable | source
libnfsidmap-dev | 0.25-6| stable | amd64, arm64, armel, armhf, 
i386, mips64el, mipsel, ppc64el, s390x
libnfsidmap2| 0.25-6| stable | amd64, arm64, armel, armhf, 
i386, mips64el, mipsel, ppc64el, s390x

libnfsidmap-dev   | 1:2.6.1-1+b1  | unstable   | amd64, arm64, armel, armhf, 
i386, mips64el, mipsel, ppc64el, s390x
libnfsidmap1  | 1:2.6.1-1+b1  | unstable   | amd64, arm64, armel, armhf, 
i386, mips64el, mipsel, ppc64el, s390x
nfs-common| 1:2.6.1-1+b1  | unstable   | amd64, arm64, armel, armhf, 
i386, mips64el, mipsel, ppc64el, s390x
nfs-kernel-server | 1:2.6.1-1+b1  | unstable   | amd64, arm64, armel, armhf, 
i386, mips64el, mipsel, ppc64el, s390x
nfs-utils | 1:2.6.1-1 | unstable   | source

src:nfs-utils seems to have taken over libnfsidmap-dev,
but the soversion of the shared library went backwards:

src:libnfsidmap built libnfsidmap1 from 0.8-1 to 0.17-1
src:libnfsidmap built libnfsidmap2 from 0.17-2 to 0.25-6+b1
src:nfs-utils built libnfsidmap1 from 1:2.5.4-1~exp1 to 1:2.6.1-1+b1


Andreas

Bug#1007230: transition: google-glog

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-03-14 08:56:07, László Böszörményi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi Release Team,
> 
> ABI changed back with 0.5.0 and further with 0.6.0 (release candidate
> at this time) by moving an internal function to the public API.
> Packaged for experimental and built on all release architectures.
> Reverse dependencies are built correctly, only src:pytorch needs a
> patch. I've submitted that [1] and asked its maintainer for testing.
> Waiting for feedback, but the package build is working for sure.

Please go ahead

Cheers

> 
> Thanks for considering,
> Laszlo/GCS
> [1] https://bugs.debian.org/1007200
> 

-- 
Sebastian Ramacher

Bug#1006233: transition: poppler

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-poppler.html

On 2022-02-21 13:56:51, Jeremy Bicha wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: popp...@packages.debain.org
> Severity: normal
> 
> I request permission to do the transition for poppler.
> 
> Poppler appears to be doing monthly releases now. To minimize
> disruption and extra transitions, we have been skipping some of the
> releases. Ubuntu 22.04 LTS will be using the 22.02 release so that's a
> good one for us to use for a few months.
> 
> I completed the transition in Ubuntu earlier this month.
> 
> I believe we can do binNMUs for all of the affected packages.

As libwebp finally migrated, please go ahead

Cheers

> 
> https://release.debian.org/transitions/html/auto-poppler.html
> 
> Thank you,
> Jeremy Bicha
> 

-- 
Sebastian Ramacher

Bug#1007792: nmu: fdroidcl_0.5.0-3+b3

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: jspri...@debian.org

nmu fdroidcl_0.5.0-3+b3 . ANY . unstable . -m "rebuild with new golang version"

Bug#1006648: transition: numerical stack: slepc petsc hypre scotch scalapack

[Sebastian Ramacher]

On 2022-03-16 18:35:28, Drew Parsons wrote:
> On 2022-03-16 09:27, Sebastian Ramacher wrote:
> > On 2022-03-15 20:33:02 +0100, Drew Parsons wrote:
> > > Control: block 1006648 by 1006615
> > > 
> > > On 2022-03-05 12:29, Sebastian Ramacher wrote:
> > > > Control: tags -1 confirmed
> > > >
> > > > On 2022-03-01 13:34:21 +0100, Drew Parsons wrote:
> > > > >
> > > > > The transitions are:
> > > > >
> > > > > scalapack  2.1 → 2.2
> > > > > scotch 6.1 → 7.0
> > > > > hypre  2.22 → 2.23
> > > > > petsc  3.15 → 3.16
> > > > > slepc  3.15 → 3.16
> > > 
> > > All transition packages uploaded and built, but got some turbulence
> > > right at
> > > the end from the pybind11 clients (dolfin and dolfinx).
> > > 
> > > Some pybind11 patches are already available, will start applying.
> > 
> > Thanks for the quick pybind11 fix.
> > 
> > fenicsx-performance-tests failed with MPI errors on some architectures.
> 
> 
> Not clear yet what's going on with fenicsx-performance-tests. A new release
> is expected soon, perhaps some of the updates will have fixed tests with
> PETSc 3.16.
> 
> fenicsx-performance-tests is at the end of the chain.  At this point I
> recommend just removing fenicsx-performance-tests from testing so as not to
> hold up the transition while we figure out what's wrong with the performance
> tests.  The dolfinx operational tests (fenics-dolfinx build and debci tests)
> are passing fine (except s390x which has always been failing debci, and
> test_sub_bbtree_box reported now at
> https://github.com/FEniCS/dolfinx/issues/2070). The test_sub_bbtree_box
> failure is unfortunate but sporadic. I don't think it's worth holding up the
> transition for it (only one dolfinx test failure in 312, can be skipped
> temporarily if needed).
> 
> I'm comfortable removing fenicsx-performance-tests from testing for now.

Alright, removal hint added.

Cheers
-- 
Sebastian Ramacher

Bug#920485: mplayer gets signal 6 when playing ogg files

[Diederik de Haas]

Control: retitle -1 mplayer gets signal 6 when playing ogg video files (.ogv)

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

Bug#1007791: nvidia-cudnn: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: nvidia-cudnn 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of nvidia-cudnn debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1005899: mplayer: should not release with bookworm

[Diederik de Haas]

On 16 Feb 2022 23:25:00 +0100 Sebastian Ramacher  wrote:
> Source: mplayer
> Version: 2:1.4+ds1-3
> Severity: serious
> Tags: sid bookworm
> 
> I think we should not include mplayer in bookworm. 
> mpv is a worthy replacement for mplayer.

I do use mpv to play ~ all my video files, but I also wrote the following in 
January of *2022* (in ~/docs/Multimedia.md):

Apparently you can dump the video files belonging to one episode using VLC, but 
that was rather cumbersome and it wasn't very clear to me what it did or what 
I should do.  
Luckily, ``mplayer`` is (still) packaged for Debian and with that, one can 
dump a whole episode into a single VOB file:  
``$ mplayer dvd://2 -dvd-device ALIAS_SEASON_1D1.iso -v -dumpstream -dumpfile 
S01E02.vob``  
The value after ``dvd://`` is the Title number that ``lsdvd`` showed us 
earlier.


So I'm glad that several people indicated they wanted to improve mplayer in 
Debian and I'll try to 'chip in' when I have some free time.

Cheers,
  Diederik

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

Bug#1007790: golang-github-cloudflare-circl: FTBFS with Go 1.18

[William 'jawn-smith' Wilson]

Package: golang-github-cloudflare-circl
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

golang-github-cloudflare-circl currently FTBFS with Go 1.18

In Ubuntu, the attached patch was applied to achieve the following:

  * Fix FTBFS with Go 1.18

Thanks for considering the patch.


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

Kernel: Linux 5.15.0-22-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-github-cloudflare-circl-1.0.0+20200724/debian/patches/fix-ftbfs-with-go-1.18.patch
 
golang-github-cloudflare-circl-1.0.0+20200724/debian/patches/fix-ftbfs-with-go-1.18.patch
--- 
golang-github-cloudflare-circl-1.0.0+20200724/debian/patches/fix-ftbfs-with-go-1.18.patch
   1969-12-31 18:00:00.0 -0600
+++ 
golang-github-cloudflare-circl-1.0.0+20200724/debian/patches/fix-ftbfs-with-go-1.18.patch
   2022-03-16 13:59:34.0 -0500
@@ -0,0 +1,29 @@
+Description: Fix FTBFS with Go 1.18
+ Per https://go.dev/doc/go1.18: "Operating on invalid
+ curve points (those for which the IsOnCurve method
+ returns false, and which are never returned by Unmarshal
+ or a Curve method operating on a valid point) has always
+ been undefined behavior, can lead to key recovery attacks,
+ and is now unsupported by the new backend." Upstream has
+ already rewritten the tests for this change.
+Origin: upstream, https://github.com/cloudflare/circl/pull/327
+Forwarded:
+Applied-Upstream: 
https://github.com/cloudflare/circl/commit/c7e43e0f74e917f712bdc46f32aead07b27b0abb
+Last-Update: 2022-03-16
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: golang-github-cloudflare-circl-1.0.0+20200724/ecc/p384/p384_test.go
+===
+--- golang-github-cloudflare-circl-1.0.0+20200724.orig/ecc/p384/p384_test.go
 golang-github-cloudflare-circl-1.0.0+20200724/ecc/p384/p384_test.go
+@@ -163,8 +163,8 @@
+   x, _ := rand.Int(rand.Reader, params.P)
+   y, _ := rand.Int(rand.Reader, params.P)
+ 
+-  got := CirclCurve.IsOnCurve(CirclCurve.ScalarMult(x, y, 
k.Bytes()))
+-  want := StdCurve.IsOnCurve(StdCurve.ScalarMult(x, y, 
k.Bytes()))
++  got := CirclCurve.IsOnCurve(x, y) && 
CirclCurve.IsOnCurve(CirclCurve.ScalarMult(x, y, k.Bytes()))
++  want := StdCurve.IsOnCurve(x, y) && 
StdCurve.IsOnCurve(StdCurve.ScalarMult(x, y, k.Bytes()))
+ 
+   if got != want {
+   test.ReportError(t, got, want, k, x, y)
diff -Nru golang-github-cloudflare-circl-1.0.0+20200724/debian/patches/series 
golang-github-cloudflare-circl-1.0.0+20200724/debian/patches/series
--- golang-github-cloudflare-circl-1.0.0+20200724/debian/patches/series 
1969-12-31 18:00:00.0 -0600
+++ golang-github-cloudflare-circl-1.0.0+20200724/debian/patches/series 
2022-03-16 13:59:05.0 -0500
@@ -0,0 +1 @@
+fix-ftbfs-with-go-1.18.patch

Bug#920485: mplayer gets signal 6 when playing ogg video files

[Diederik de Haas]

Package: mplayer
Version: 2:1.4+ds1-3+b1
Followup-For: Bug #920485

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

When I first read the bug title, I played an .ogg music file and that
went fine. After reading the bug report, I learned it was with ogv
file(s), i.e. ogg video files.

I DL-ed the exact same file and then tried whether I could replicate
this bug with version 1.4 and that was the case.
The output of mplayer was a bit different though:

diederik@bagend:~/tmp$ wget 
https://archive.org/download/lca2019-Distributed_storage_is_easier_now_usability_from_Ceph_Luminous_to_Nautilus/Distributed_storage_is_easier_now_usability_from_Ceph_Luminous_to_Nautilus.ogv
diederik@bagend:~/tmp$ mplayer 
Distributed_storage_is_easier_now_usability_from_Ceph_Luminous_to_Nautilus.ogv
MPlayer 1.4 (Debian), built with gcc-11 (C) 2000-2019 MPlayer Team
do_connect: could not connect to socket
connect: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing 
Distributed_storage_is_easier_now_usability_from_Ceph_Luminous_to_Nautilus.ogv.
libavformat version 58.76.100 (external)
libavformat file format detected.
[lavf] stream 0: video (theora), -vid 0, Distributed storage is easier now: 
usability from Ceph Luminous to Nautilus
[lavf] stream 1: audio (vorbis), -aid 0, Distributed storage is easier now: 
usability from Ceph Luminous to Nautilus
VIDEO:  [theo]  534x300  0bpp  29.970 fps0.0 kbps ( 0.0 kbyte/s)
Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object 
file: No such file or directory
[vdpau] Error when calling vdp_device_create_x11: 1
==
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 58.134.100 (external)
[theora @ 0x7fe8f5901360]Requested frame threading with a custom get_buffer2() 
implementation which is not marked as thread safe. This is not supported 
anymore, make your callback thread-safe.
Selected video codec: [fftheora] vfm: ffmpeg (FFmpeg Theora)
==
Load subtitles in ./
==
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, floatle, 128.0 kbit/4.54% (ratio: 16000->352800)
Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis)
==
AO: [pulse] 44100Hz 2ch floatle (4 bytes per sample)
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 534x300 => 534x300 Planar YV12
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 534x300 => 534x300 Planar YV12
Dropping frame with size not matching configured size (534x300 vs 524x296 vs 
534x300)
Dropping frame with size not matching configured size (534x300 vs 524x296 vs 
534x300)
[VD_FFMPEG] DRI failure.
mplayer: libmpcodecs/vf.c:286: vf_get_image: Assertion `w == -1 || w >= vf->w' 
failed.


MPlayer interrupted by signal 6 in module: decode video
 [ This binary of MPlayer in Debian is currently compiled with
   '--enable-debug'; the debugging symbols are in the package
   'mplayer-dbgsym'.]

I did install mplayer-dbgsym, but that didn't show anything else AFAICT.
I also ran the command with '-msglevel all=8' and that should get
attached as 'mplayer-debug-lvl8.log'.

HW: AMD Ryzen 1800X CPU and Radeon RX Vega 64 GPU
(I saw it tried to use NVidia's VDPAU, hence mentioning my HW)

HTH,
  Diederik

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

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

Versions of packages mplayer depends on:
ii  liba52-0.7.4  0.7.4-20
ii  libaa11.4p5-50
ii  libasound21.2.6.1-2
ii  libass9   1:0.15.2-1
ii  libaudio2 1.9.4-7
ii  libavcodec58  7:4.4.1-3+b2
ii  libavformat58 7:4.4.1-3+b2
ii  libavutil56   7:4.4.1-3+b2
ii  libbluray21:1.3.1-1
ii  libbs2b0  3.1.0+dfsg-5
ii  libc6 2.33-7
ii  libcaca0  0.99.beta19-2.2
ii  libcdio-cdda2 10.2+2.0.0-1+b2
ii  libcdio-paranoia2 10.2+2.0.0-1+b2
ii  libcdio19 2.1.0-3
ii  libdca0   0.0.7-2
ii  libdv41.0.0-14
ii  libdvdnav4

Bug#1007789: golang-github-matryer-try: FTBFS with Go 1.18

[William 'jawn-smith' Wilson]

Package: golang-github-matryer-try
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

golang-github-matryer-try currently FTBFS with Go 1.18

In Ubuntu, the attached patch was applied to achieve the following:


  * Remove unused variables to fix FTBFS with Go 1.18


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-22-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-github-matryer-try-1+git20161228.6.9ac251b/debian/patches/fix-ftbfs-with-go1.18.patch
 
golang-github-matryer-try-1+git20161228.6.9ac251b/debian/patches/fix-ftbfs-with-go1.18.patch
--- 
golang-github-matryer-try-1+git20161228.6.9ac251b/debian/patches/fix-ftbfs-with-go1.18.patch
1969-12-31 18:00:00.0 -0600
+++ 
golang-github-matryer-try-1+git20161228.6.9ac251b/debian/patches/fix-ftbfs-with-go1.18.patch
2022-03-16 13:50:42.0 -0500
@@ -0,0 +1,43 @@
+Description: Fix FTBFS with Go 1.18
+ Go 1.18 is more strict about unused variables. This patch
+ removes some unused variables to enable building this
+ package against Go 1.18
+Author: William 'jawn-smith' Wilson 
+Forwarded:
+Applied-Upstream: https://github.com/matryer/try/pull/7
+Last-Update: 2022-03-16
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: golang-github-matryer-try-1+git20161228.6.9ac251b/try_test.go
+===
+--- golang-github-matryer-try-1+git20161228.6.9ac251b.orig/try_test.go
 golang-github-matryer-try-1+git20161228.6.9ac251b/try_test.go
+@@ -15,10 +15,9 @@
+   SomeFunction := func() (string, error) {
+   return "", nil
+   }
+-  var value string
+   err := try.Do(func(attempt int) (bool, error) {
+   var err error
+-  value, err = SomeFunction()
++  _, err = SomeFunction()
+   return attempt < 5, err // try 5 times
+   })
+   if err != nil {
+@@ -30,7 +29,6 @@
+   SomeFunction := func() (string, error) {
+   panic("something went badly wrong")
+   }
+-  var value string
+   err := try.Do(func(attempt int) (retry bool, err error) {
+   retry = attempt < 5 // try 5 times
+   defer func() {
+@@ -38,7 +36,7 @@
+   err = errors.New(fmt.Sprintf("panic: %v", r))
+   }
+   }()
+-  value, err = SomeFunction()
++  _, err = SomeFunction()
+   return
+   })
+   if err != nil {
diff -Nru 
golang-github-matryer-try-1+git20161228.6.9ac251b/debian/patches/series 
golang-github-matryer-try-1+git20161228.6.9ac251b/debian/patches/series
--- golang-github-matryer-try-1+git20161228.6.9ac251b/debian/patches/series 
1969-12-31 18:00:00.0 -0600
+++ golang-github-matryer-try-1+git20161228.6.9ac251b/debian/patches/series 
2022-03-16 13:50:07.0 -0500
@@ -0,0 +1 @@
+fix-ftbfs-with-go1.18.patch

Bug#1007103: Further information

[Ted Felix]

malloc_consolidate(): unaligned fastbin chunk detected Aborted


  We've not seen this upstream.  Best bet would be to do a debug build 
from source and run under gdb.  Then do a backtrace when it crashes. 
That should help us determine whether it is Rosegarden or one of the 
many libraries it pulls in.  Let me know if you need help with this and 
I'll point you to the relevant pages on our wiki.

Bug#1007788: golang-github-manyminds-api2go: FTBFS with Go 1.18

[William 'jawn-smith' Wilson]

Package: golang-github-manyminds-api2go
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

This package currently FTBFS with Go 1.18 due to some unused variables

In Ubuntu, the attached patch was applied to achieve the following:

  * Fix FTBFS with Go 1.18


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-22-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-github-manyminds-api2go-1.0-RC4/debian/patches/fix-ftbfs-with-go1.18.patch
 
golang-github-manyminds-api2go-1.0-RC4/debian/patches/fix-ftbfs-with-go1.18.patch
--- 
golang-github-manyminds-api2go-1.0-RC4/debian/patches/fix-ftbfs-with-go1.18.patch
   1969-12-31 18:00:00.0 -0600
+++ 
golang-github-manyminds-api2go-1.0-RC4/debian/patches/fix-ftbfs-with-go1.18.patch
   2022-03-16 13:37:17.0 -0500
@@ -0,0 +1,54 @@
+Description: Fix FTBFS with Go 1.18
+ Go 1.18 is more strict about unused variables. There are some
+ unused variables in this package that have already been deleted
+ in the upstream repository
+Origin: upstream, 
https://github.com/GlenPickle/api2go/commit/4e34a06d27e6b961326cf75238250e3d03530aab
+Applied-Upstream: 
https://github.com/GlenPickle/api2go/commit/4e34a06d27e6b961326cf75238250e3d03530aab
+Last-Update: 2022-03-16
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: golang-github-manyminds-api2go-1.0-RC4/api_interfaces_test.go
+===
+--- golang-github-manyminds-api2go-1.0-RC4.orig/api_interfaces_test.go
 golang-github-manyminds-api2go-1.0-RC4/api_interfaces_test.go
+@@ -414,14 +414,13 @@
+   var (
+   api*API
+   rec*httptest.ResponseRecorder
+-  payload, payloadID SomeData
++  payload SomeData
+   )
+ 
+   BeforeEach(func() {
+   api = NewAPI("v1")
+   api.AddResource(SomeData{}, ResourceDeletionOnly{})
+   rec = httptest.NewRecorder()
+-  payloadID = SomeData{ID: "12345", Data: "A Brezzn"}
+   payload = SomeData{Data: "A Brezzn"}
+   })
+ 
+Index: golang-github-manyminds-api2go-1.0-RC4/api_test.go
+===
+--- golang-github-manyminds-api2go-1.0-RC4.orig/api_test.go
 golang-github-manyminds-api2go-1.0-RC4/api_test.go
+@@ -1052,7 +1052,6 @@
+   Context("marshal errors correctly", func() {
+   var (
+   source*fixtureSource
+-  post1Json map[string]interface{}
+ 
+   api *API
+   rec *httptest.ResponseRecorder
+@@ -1063,12 +1062,6 @@
+   "1": {ID: "1", Title: "Hello, World!"},
+   }, false}
+ 
+-  post1Json = map[string]interface{}{
+-  "id":"1",
+-  "title": "Hello, World!",
+-  "value": nil,
+-  }
+-
+   api = NewAPI("")
+   api.AddResource(Post{}, source)
+ 
diff -Nru golang-github-manyminds-api2go-1.0-RC4/debian/patches/series 
golang-github-manyminds-api2go-1.0-RC4/debian/patches/series
--- golang-github-manyminds-api2go-1.0-RC4/debian/patches/series
1969-12-31 18:00:00.0 -0600
+++ golang-github-manyminds-api2go-1.0-RC4/debian/patches/series
2022-03-16 13:35:20.0 -0500
@@ -0,0 +1 @@
+fix-ftbfs-with-go1.18.patch

Bug#1007787: bullseye-pu: package adduser/3.118

[Marc Haber]

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

[ Reason ]
Bug #940577 reports a command injection vulnerability into deluser which
can be exploited by an external entity that can can create strangely named
user accounts. This is a privilege escalation on systems that have their
account database externally managed, for example in LDAP.

This issue is present in adduser since nearly forever (2006) and has
just recently been fixed in unstable.

[ Impact ]
Possible privilege escalation.

[ Tests ]
Adduser in unstable has an autopkgtest covering the issue; adduser in
stable sadly not.

[ Risks ]
Due to changes in the syntax of the crontab executable, the entire code
is non-functional; the only function it provides is thus to offer the
command injection.

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

[ Changes ]
The suggested fix differs from the fix employed for unstable and just
removes the affected code:

diff --git a/deluser b/deluser
index b1bf56b..c27ec8d 100644
--- a/deluser
+++ b/deluser
@@ -348,13 +348,6 @@ if($action eq "deluser") {
   }
 }

-if (system("crontab -l $user >/dev/null 2>&1") == 0) {
-  # crontab -l returns 1 if there is no crontab
-  my $crontab = ('crontab');
-  ($crontab, "-r", $user);
-  s_print (gtx("Removing crontab ...\n"));
-}
-
 s_printf (gtx("Removing user `%s' ...\n"),$user);
 my @members = get_group_members($maingroup);
 if (@members == 0) {

[ Other info ]
This is my first try to do a stable upload. Since adduser is a vital
package, but my time is rather limited at the moment, I would like to
know whether this fix is acceptable for stable before I prepare an
actual package. Also, the fix suggested for stable is not the same fix
that is in place in unstable and testing (that one also fixes the broken
functionality and adds more safety).

Greetings
Marc

Bug#1007786: isc-dhcp-client: workaround for DHCPv6 + Dynamic DNS

[Christian Kuhn]

Package: isc-dhcp-client
Version:    4.4.1-2.3
Severity:   minor
Platform:   amd64

Dear Maintainer,

in an IPv4 network with DHCPv4 and Dynamic DNS, the DHCP client works
very well with the following default configuration in
/etc/dhcp/dhclient.conf:

...
option rfc3442-classless-static-routes code 121 = array of unsigned
integer 8;
send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
    domain-name, domain-name-servers, domain-search, host-name,
    dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn,
dhcp6.sntp-servers,
    netbios-name-servers, netbios-scope, interface-mtu,
    rfc3442-classless-static-routes, ntp-servers;
...

However, in a pure IPv6 network with DHCPv6 (isc-dhcp-server) and
Dynamic DNS (bind9) I need to insert additional information as
workaround in order to update the name server correctly:

...
option rfc3442-classless-static-routes code 121 = array of unsigned
integer 8;
send host-name = gethostname();
send fqdn.fqdn "hostname.domain.local";
send fqdn.encoded on;
send fqdn.server-update on;
request subnet-mask, broadcast-address, time-offset, routers,
    domain-name, domain-name-servers, domain-search, host-name,
    dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn,
dhcp6.sntp-servers,
    netbios-name-servers, netbios-scope, interface-mtu,
    rfc3442-classless-static-routes, ntp-servers;
...

It works, but it would be unusableto send hostname and domain namefor
computers (notebooks), which should be used in different IPv6 networks
configured with DHCPv6 and Dynamic DNS.

Please, can you consider this requirement?

Best regards,
Christian

Bug#1007785: docs about policy layer

[Marc Haber]

Package: adduser
Version: 3.121
Severity: important

(inflated severity so that we don't miss it, it's 'just' a docs issue)

Adduser should be - in the docs - more clear about that it is trying to
be a Debian-specific policy layer around the lower level tools and that
it aims to be usable especially in maintainer scripts without any
scaffolding such as testing, error suppression and other conditionals.

We will add whatever flags we need to add to adduser to make that work,
and we consider the actual NEED for such scaffolding other than checking
for presence of executable in postrm a bug and encourage people to file
bugs requesting features to allow that.

(bad english, no time to do it any better right now).

Greetings
Marc

Bug#1004037: Segmentation fault in plink2 (Was: src:plink2: fails to migrate to testing for too long: autopkgtest regression)

[Andreas Tille]

Am Tue, Mar 15, 2022 at 09:01:12AM -0700 schrieb Chris Chang:
> Just a heads-up, today's release contains a fix for an
> infinite-loop-instead-of-error bug in the previous release.

Thanks a lot for the headsup - just uploaded the updated version to Debian.
 
> On Sun, Feb 20, 2022 at 12:36 PM Andreas Tille  wrote:
> 
> > Cool!  This finally works.  Thanks a lot for your patience, Andreas.
> >
> > Am Sun, Feb 20, 2022 at 09:43:10AM -0800 schrieb Chris Chang:
> > > Hmm.  Ordinarily, that download link would be fine.  I had not updated it
> > > this time because the issue only affects gcc 11+, so it did not affect
> > any
> > > of the precompiled binaries and I wanted to keep the posted source
> > > identical to that used to compile those binaries.
> > >
> > > On the other hand, the only difference (in the non-gcc-11+ case) between
> > > the binaries and the updated source is the version date.  I guess this is
> > > insignificant enough that a temporary discordance is less disruptive than
> > > making you change your packing process, so I've updated the website
> > source
> > > link to point to the newer code; let me know if you still run into any
> > > problems.
> > >
> > > On Sat, Feb 19, 2022 at 11:53 PM Andreas Tille  wrote:
> > >
> > > > Hi Chris,
> > > >
> > > > Am Sat, Feb 19, 2022 at 11:37:34PM -0800 schrieb Chris Chang:
> > > > > To elaborate: when I look at
> > > > > https://salsa.debian.org/med-team/plink2/-/tree/master , I can see
> > that
> > > > > plink2.cc, include/plink2_base.h, and include/plink2_base.cc don't
> > have
> > > > the
> > > > > same contents as the v2.00a3-20220218 GitHub tag/release.  So I don't
> > > > know
> > > > > where you grabbed the code from this time, but it does not appear to
> > be
> > > > > from GitHub.
> > > >
> > > > That's true since on Github the source code of plink1.9 and plink2 is
> > not
> > > > separated.  Thus I download the tarball from
> > > >
> > > >https://www.cog-genomics.org/plink/2.0/
> > > >
> > > > which points to
> > > >
> > > >https://www.cog-genomics.org/static/bin/plink2_src_220217.zip
> > > >
> > > > I confirm that the tag on Github says v2.00a3-20220218 which seems to
> > be
> > > > later than 220217.  In principle I could point the packaging metadata
> > to
> > > > Github and exclude everything that I do not need for plink2 packaging
> > (so
> > > > remove 1.9 directory and code copies of libdeflate, simde and zstd in
> > 2.0)
> > > >
> > > > In case you consider this the safer way to download plink2 code I'll
> > do so.
> > > >
> > > > Kind regards and thanks a lot for comparing the code base
> > > >
> > > >  Andreas.
> > > >
> > > > > On Sat, Feb 19, 2022 at 7:54 AM Chris Chang 
> > > > wrote:
> > > > >
> > > > > > If you build off the current head, the version string should say
> > "18
> > > > Feb
> > > > > > 2022", not "17 Feb 2022".
> > > > > >
> > > > > > On Sat, Feb 19, 2022 at 7:02 AM Andreas Tille 
> > > > wrote:
> > > > > >
> > > > > >> Hi again,
> > > > > >>
> > > > > >> Am Sat, Feb 19, 2022 at 12:28:21AM -0800 schrieb Chris Chang:
> > > > > >> > Ok, new release/tag created.
> > > > > >>
> > > > > >> I've built the new version now.  The bad news is that it keeps on
> > > > > >> SEGFAULTing for me:
> > > > > >>
> > > > > >> ...
> > > > > >> (gdb) run
> > > > > >> Starting program: /usr/lib/plink2/plink2-sse3 --debug --pfile
> > tmp_data
> > > > > >> --export vcf vcf-dosage=DS --out tmp_data2
> > > > > >> [Thread debugging using libthread_db enabled]
> > > > > >> Using host libthread_db library
> > > > "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > > > > >> [New Thread 0x74cc7640 (LWP 985019)]
> > > > > >> [New Thread 0x744c6640 (LWP 985020)]
> > > > > >> [New Thread 0x7fffebcc5640 (LWP 985021)]
> > > > > >> PLINK v2.00a3 64-bit (17 Feb 2022)
> > > > > >> www.cog-genomics.org/plink/2.0/
> > > > > >> (C) 2005-2022 Shaun Purcell, Christopher Chang   GNU General
> > Public
> > > > > >> License v3
> > > > > >> Logging to tmp_data2.log.
> > > > > >> Options in effect:
> > > > > >>   --debug
> > > > > >>   --export vcf vcf-dosage=DS
> > > > > >>   --out tmp_data2
> > > > > >>   --pfile tmp_data
> > > > > >>
> > > > > >> Start time: Sat Feb 19 16:00:00 2022
> > > > > >> 31998 MiB RAM detected; reserving 15999 MiB for main workspace.
> > > > > >> Using up to 4 compute threads.
> > > > > >> [New Thread 0x77fc5640 (LWP 985022)]
> > > > > >>
> > > > > >> Thread 1 "plink2-sse3" received signal SIGSEGV, Segmentation
> > fault.
> > > > > >> plink2::LoadPsam (psamname=psamname@entry=0x7fffbe60
> > > > > >> "tmp_data.psam", pheno_range_list_ptr=,
> > fam_cols=...,
> > > > > >> pheno_ct_max=,
> > > > > >> missing_pheno=, affection_01=0,
> > max_thread_ct=4,
> > > > > >> piip=0x7fff8870, sample_include_ptr=0x7fff8790,
> > > > > >> founder_info_ptr=0x7fff87a8, sex_nm_ptr=0x7fff8798,
> > > > > >> sex_male_ptr=0x7fff87a0, pheno_cols_ptr=0x7fff8770,
> > > > > >> pheno_names_ptr=0x7fff8780, 

Bug#1007702: Acknowledgement (fdpowermon: "Not charging" state not supported)

[Roland Rosenfeld]

Hi Wouter!

It seems, that my patch isn't complete, since with the following
output of acpi -bi:

Battery 0: Discharging, 87%, 03:13:16 remaining
Battery 0: design capacity 1958 mAh, last full capacity 1506 mAh = 76%
Battery 1: Not charging, 5%
Battery 1: design capacity 4609 mAh, last full capacity 4239 mAh = 91%

I now see the charging symbol (flash next to the battery).

So the attached additional patch seems to be necessary.

Greetings
Roland
diff --git a/fdpowermon b/fdpowermon
index d7b8b6f..ee20dda 100755
--- a/fdpowermon
+++ b/fdpowermon
@@ -447,6 +447,9 @@ sub checklevels {
 	if($state =~ /Discharging/) {
 		$step = $themes{$theme}->{discharging};
 		$charging = 0;
+	} elsif($state =~ /Not charging/) {
+		$step = $themes{$theme}->{discharging};
+		$charging = 0;
 	} elsif($state =~/Charging/) {
 		$step = $themes{$theme}->{charging};
 		$charging = 1;


signature.asc
Description: PGP signature

Bug#1006648: transition: numerical stack: slepc petsc hypre scotch scalapack

[Drew Parsons]

On 2022-03-16 09:27, Sebastian Ramacher wrote:

On 2022-03-15 20:33:02 +0100, Drew Parsons wrote:

Control: block 1006648 by 1006615

On 2022-03-05 12:29, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
>
> On 2022-03-01 13:34:21 +0100, Drew Parsons wrote:
> >
> > The transitions are:
> >
> > scalapack  2.1 → 2.2
> > scotch 6.1 → 7.0
> > hypre  2.22 → 2.23
> > petsc  3.15 → 3.16
> > slepc  3.15 → 3.16

All transition packages uploaded and built, but got some turbulence 
right at

the end from the pybind11 clients (dolfin and dolfinx).

Some pybind11 patches are already available, will start applying.


Thanks for the quick pybind11 fix.

fenicsx-performance-tests failed with MPI errors on some architectures.



Not clear yet what's going on with fenicsx-performance-tests. A new 
release is expected soon, perhaps some of the updates will have fixed 
tests with PETSc 3.16.


fenicsx-performance-tests is at the end of the chain.  At this point I 
recommend just removing fenicsx-performance-tests from testing so as not 
to hold up the transition while we figure out what's wrong with the 
performance tests.  The dolfinx operational tests (fenics-dolfinx build 
and debci tests) are passing fine (except s390x which has always been 
failing debci, and test_sub_bbtree_box reported now at 
https://github.com/FEniCS/dolfinx/issues/2070). The test_sub_bbtree_box 
failure is unfortunate but sporadic. I don't think it's worth holding up 
the transition for it (only one dolfinx test failure in 312, can be 
skipped temporarily if needed).


I'm comfortable removing fenicsx-performance-tests from testing for now.

Drew

Bug#398793: adduser: Non system wide readable (home) directories should not be 751

[Marc Haber]

On Wed, Nov 15, 2006 at 04:19:58PM +0100, Olaf van der Spek wrote:
> Non system wide readable (home) directories should be 750, not 751.
> Or, the question should be made more clear, for example by replacing readable 
> by listable.

This might not be clear to all readers, we are talking about the Debconf
question that adduser asks on installation.

I am not sure whether we should keep that question. Most systems
installed nowadays are single-user anyway, and those who are installed
for multiple-users usually have administration that can change the
default in adduser.conf.

After deciding this, we need to decide on the default.

There is discussion going on in debian-devel about this.

Greetings
Marc

Bug#994388: dpkg currently warning about merged-usr systems

[Sean Whitton]

Hello,

On Wed 16 Mar 2022 at 08:55am -07, Russ Allbery wrote:

> Sean Whitton  writes:
>
>> Thanks for the pointer.  It's only in the postinst, it seems.  So this
>> is only going to get emitted once per system and only on upgraded
>> systems.
>
> I think the concern is less about the noise and more about the fact that
> this will be perceived by users as an official declaration from Debian as
> a project that their system configuration is unsupported, while
> simultaneously this is the default installation mode for new systems and
> something that we have elsewhere said is a correct system configuration.

Right, I share this concern, I just wanted to be completely clear about
the scope of the issue.

-- 
Sean Whitton

Bug#1007784: golang-codegangsta-cli FTBFS with Go 1.18

[William 'jawn-smith' Wilson]

Package: golang-codegangsta-cli
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

golang-codegangsta-cli is FTBFS with Go 1.18

In Ubuntu, the attached patch was applied to achieve the following:


  * Fix FTBFS with Go 1.18


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-22-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-codegangsta-cli-1.18.0/debian/patches/build-with-golang-1.18.patch 
golang-codegangsta-cli-1.18.0/debian/patches/build-with-golang-1.18.patch
--- golang-codegangsta-cli-1.18.0/debian/patches/build-with-golang-1.18.patch   
1969-12-31 18:00:00.0 -0600
+++ golang-codegangsta-cli-1.18.0/debian/patches/build-with-golang-1.18.patch   
2022-03-16 11:15:14.0 -0500
@@ -0,0 +1,21 @@
+Index: golang-codegangsta-cli-1.18.0/app_test.go
+===
+--- golang-codegangsta-cli-1.18.0.orig/app_test.go
 golang-codegangsta-cli-1.18.0/app_test.go
+@@ -363,7 +363,6 @@
+ }
+ 
+ func TestApp_ParseSliceFlags(t *testing.T) {
+-  var parsedOption, firstArg string
+   var parsedIntSlice []int
+   var parsedStringSlice []string
+ 
+@@ -377,8 +376,6 @@
+   Action: func(c *Context) error {
+   parsedIntSlice = c.IntSlice("p")
+   parsedStringSlice = c.StringSlice("ip")
+-  parsedOption = c.String("option")
+-  firstArg = c.Args().First()
+   return nil
+   },
+   }
diff -Nru golang-codegangsta-cli-1.18.0/debian/patches/series 
golang-codegangsta-cli-1.18.0/debian/patches/series
--- golang-codegangsta-cli-1.18.0/debian/patches/series 2018-12-01 
13:10:19.0 -0600
+++ golang-codegangsta-cli-1.18.0/debian/patches/series 2022-03-16 
11:14:24.0 -0500
@@ -0,0 +1 @@
+build-with-golang-1.18.patch

Bug#1007783: Breaks containerd

[Shengjing Zhu]

Source: golang-gogottrpc
Version: 1.1.0-1
Severity: serious
X-Debbugs-Cc: z...@debian.org

Rebuilding containerd with golang-gogottrpc/1.1.0-1, then install it.

Now we get:

$ sudo ctr run --rm -t docker.io/library/alpine:latest test1
ctr: failed to create shim task: ttrpc: cannot marshal unknown type: 
*task.CreateTaskRequest: unknown

$ docker run --rm -it ubuntu:20.04 bash
docker: Error response from daemon: failed to create shim task: ttrpc: cannot 
marshal unknown type: *task.CreateTaskRequest: unknown.

Bug#994388: dpkg currently warning about merged-usr systems

[Russ Allbery]

Sean Whitton  writes:

> Thanks for the pointer.  It's only in the postinst, it seems.  So this
> is only going to get emitted once per system and only on upgraded
> systems.

I think the concern is less about the noise and more about the fact that
this will be perceived by users as an official declaration from Debian as
a project that their system configuration is unsupported, while
simultaneously this is the default installation mode for new systems and
something that we have elsewhere said is a correct system configuration.

-- 
Russ Allbery (r...@debian.org)  

Bug#1006626: biber: Lots of "Use of uninitialized value" warnings after biber update

[Hilmar Preuße]

Am 28.02.2022 um 21:41 teilte Ralf Jung mit:

H,


I reported this upstream at https://github.com/plk/biber/issues/403,
but the maintainer suggested this might be a packaging issues since
they could not reproduce the problem.



https://github.com/plk/biber/issues/403#issuecomment-1069287108

So the main difference is that we (Debian) call perl with option "-w". 
After removing the option the warnings go away. Not sure if we should 
solve the issue this way.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007717: Native source package format with non-native version

[Russ Allbery]

Felix Lechner  writes:
> On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery  wrote:

>> We should define native and non-native packages in terms of version
>> numbers, and allow both native and non-native packages to use
>> single-tarball source package formats.

> I co-maintaintain several Debian-internal tools, and that description is
> backwards. "Native" sources are characterized by their lack of Debian
> patches.

This is exactly the semantic confusion that I believe is wrong and we
should undo.  "Native" vs. "non-native" should be a property of the
relationship between the package and a separate upstream release, which is
represented in the version.  That should be decoupled from the source
package format.

The point that Ian and Sam are raising is that a single tarball is a good
way of representing the Debian package source in several non-native cases
where we are still packaging a piece of software with an independent
upstream existence, and where having a version with a Debian revision is
still semantically correct.

> On that note, the term "native" is also not great. The words "patched"
> and "unpatched" describe the relationship between sources in the archive
> and their respective upstreams more accurately.

I think that would add even more confusion.  It's very common for
non-native packages to switch between patched and unpatched from upload to
upload, depending on whether Debian has to carry additional patches,
without any change in their version number format or in the source package
format.  This is correct and should continue to be supported.

-- 
Russ Allbery (r...@debian.org)  

Bug#1007781: Source format "3.0 (git-diff)" (name TBD)

[Ian Jackson]

Package: dpkg-dev
Severity: wishlist
Version: 1.21.1

In an email thread somewhere, I wrote:
> Would you welcome implementation of a "3.0 (diff)" format which
> contained a tarball plus a single diff, arranged to be capable of
> representing every git tree object ?  There would have to be some
> massaging, I guess, mostly because of symlinks.  That would be
> pareto-better than 1.0-with-diff.

I thought about this and I think it makes sense to make this a proper
wishlist bug.

My goals[1] here are to provide a source format which:

1. Can represent any git tree object (unlike 1.0-with-diff),
2. Without needing to modify it or add anything (unlike "3.0 (quilt)")
3. Is readily compatible with ftpmaster workflows (unlike "3.0 (git)")
4. Does nnt actually use git for packing/unpacking

This would be pareto-better than "3.0 (quilt)"+single-debian-patch.

I suggest the following format: the .dsc mentions one or more orig
tarballs as for 3.0, plus one file called ".diff" as for 1.0.

The diff would be in the format produced by git-diff.  But that format
would be reimplemented.  I think by now the main part that needs
reimplemneting is support for modifying symlink targets.  And there
should be some checking that the resulting tree does not contain
strange object such as sockets, device files, or other things that git
cannot represent.

The implementation of symlink-target-diffing could be done by adding
the necessary feature(s) to GNU diffutils, or by ad-hoc perl code.

Ian.

[1] I think these goals make it difficult to provide the otherwise
desirable objective of being able to represent a patch series.  IMO
that objective is less important now that more and more people are
working purely in git and treating the archive as a legacy interchange
mechanism.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#898949: schroot: PAM config should use common-session-noninteractive

[Colin Watson]

On Sun, Sep 08, 2019 at 10:41:52PM +0100, Roger Leigh wrote:
> On 07/09/2019 10:30, Simon McVittie wrote:
> > On Thu, 17 May 2018 at 19:36:11 +0200, Ansgar Burchardt wrote:
> > > On systems with libpam-systemd installed using common-session will
> > > create a logind session which schroot should not do.
> > In particular, creating a logind session results in $XDG_RUNTIME_DIR
> > being set inside the chroot, to a path that only exists outside the chroot.
> 
> Should this path be bound into the chroot?

It's hard to see how it's useful for schroot to create a logind session
on the host system at all.

> Which Debian version introduced common-session-noninteractive?

pam 1.0.1-11, which is sufficiently long ago (2009, well before
oldoldoldstable) that it no longer needs to be specified in
dependencies.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1007717: Native source package format with non-native version

[Ian Jackson]

Helmut Grohne writes ("Re: Bug#1007717: Native source package format with 
non-native version"):
> Beyond the content of your request, I have a meta-question. Do you see a
> particular urgency with the processing of your request? What is - in
> your opinion - a reasonable time for resolving this? Of course, if Lucas
> et al are to proceed with their deprecation work, urgency may arise in
> your view, but let us assume that we can ask them to pause their
> efforts for a while.

As you surmise, the only urgency I feel is due to these deprecation
efforts (some of which take other forms).

> Lucas, please pause further work on deprecating the 1.0 format in order
> to give time to settle the dispute at hand. This implies not sending
> further bugs about it. On the other hand, I think closing all of the
> existing ones would not do any good at this time either.

It is a shame that these bugs were filed and a lot of maintainers
(including at least one of my sponsees) now find themselves in a
confusing position.  Perhaps it would be worth sending an agreed
holding message to these bugs, and/or blocking them by this one.

> Can I ask you to step back a bit and help us figure out what you really
> want to achieve?
> 
> Given your other messages on the matter, I suppose that you want to be
> able to use a source package format that can faithfully represent any
> valid source tree. In particular, a source tree with a Debian revision
> should be representable. You care less about being able to represent
> differences to a tarball in some cases as long as the changed tree as a
> whole is representable. This includes changes to permissions, symbolic
> links and binary files. Which source format is used is not important to
> you as long as it is able to meet these requirements.

Yes, that is by and large my SNPS (solution neutral problem statement)
for the ideal situation.

But, note that "faithfully" implies not including a copy of the Debian
delta in the form of patches within the unpacked source tree (as "3.0
(quilt)" does), since those patches must then be kept up to date.

And, I want a format that offers the bandwidth and disk space
optimisation of not re-uploading large files when only small changes
are made.  This is necessary for large packages.  The various
with-diffs/with-patches formats achieve this, but compromise on other
aspects.

> > Part II - bless continued use of 1.0-with-diff, for now at least:
> > 
> >  4. Declare that sometimes the use of 1.0-with-diff can be the best
> > tradeoff between different considerations.  In particular,
> > because 1.0 is the only format which botH:
> >  (a) Optimises bandwidth and storage by reusing the upstream 
> >  data when it hasn't changed.
> >  (b) Avoids polluting the working tree (package source code)
> >  with [patches], which cause trouble especially with
> >  git-based workflows.
> 
> I note that the 1.0-with-diff format does not meet my perception of your
> earlier requirement: Being able to represent any source tree.

You are correct.  But there is not currently any format that meets all
of my requirements.

In particular, 1.0-with-diff achieves the bandwdith/storage
optimisation, at the cost of representational capability.
Looked at this way "3.0 (quilt)" is mixed - it has some additional
representational capabilities, but reduced fidelity.

>  I also note that it is possible to choose a different conversion
> mechanism than dpkg-source -b between working tree and .dsc that
> does not incur your reported pollution. In particular, you do have
> experience in implementing such conversions as is evidenced in dgit
> and such conversions do exist.

Um.  The conversions done by dgit exist to *keep the pollution up to
date*.  And they are really quite inconvenient.  dgit must make
commits on your branch, or maintain multiple branches.  There is a
substantial amount of code there, dealing with a large variety of
different situations.

> Your request also touches the question of the preferred form for
> modification. That used to be the .dsc, but for the way you use the
> archive, it merely is an export for a preferred form for modification
> that resides elsewhere. I do not think we have consensus for this view
> either.

In practice, the vast majority of packages are maintained in git on
salsa.  The maintainers use those git repositories as the PFM.
The git repositories contain much information which is not in the
source packages (generated by gbp or dgit on maintainers' machines),
and, depending on the package, that information is sometimes critical.
IOW that ship has sailed.

My programme of properly supporting git in Debian is trying to sort
out this situation, by providing a discoverable, coherent, and
reliable git view of every package.  Unfortunately that is blocked
due to unfounded "security concerns".

I note that "3.0 (quilt)" with single-debian-patch exists and is fully
supported.  No-one appears to be trying to get 

Bug#1007778: Acknowledgement (IDicomDataset.h:25:10: fatal error: DicomFormat/DicomPath.h: No such file or directory)

[Mathieu Malaterre]

Control: tags -1 patch

How about:

diff --git a/debian/control b/debian/control
index 4499dca..ed61119 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: cmake,
libcurl4-openssl-dev | libcurl4-dev,
libdcmtk-dev,
libopenjp2-7-dev,
-   liborthancframework-dev,
+   liborthancframework-dev (>= 1.10.0),
libtiff5-dev,
orthanc-dev (>= 1.1.0),
uuid-dev,

Bug#1007778: IDicomDataset.h:25:10: fatal error: DicomFormat/DicomPath.h: No such file or directory

[Mathieu Malaterre]

Package: orthanc-wsi
Version: 1.1-1
Severity: normal

Dear Maintainer,

I cannot build a bpo of orthanc-wsi on current Debian/stable. It fails
with:

In file included from 
/home/mathieu/debian/orthanc-wsi/Framework/Inputs/../../Resources/Orthanc/Stone/DicomDatasetReader.h:25,
 from 
/home/mathieu/debian/orthanc-wsi/Framework/Inputs/DicomPyramidInstance.cpp:27:
/home/mathieu/debian/orthanc-wsi/Framework/Inputs/../../Resources/Orthanc/Stone/IDicomDataset.h:25:10:
 fatal error: DicomFormat/DicomPath.h: No such file or directory
   25 | #include   // From Orthanc framework
  |  ^
compilation terminated.

Build-Depends for liborthancframework-dev seems incorrect to me

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

Kernel: Linux 5.15.0-0.bpo.3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages orthanc-wsi depends on:
ii  libboost-filesystem1.74.0  1.74.0-9
ii  libboost-iostreams1.74.0   1.74.0-9
ii  libboost-locale1.74.0  1.74.0-9
ii  libboost-program-options1.74.0 1.74.0-9
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu67]  1.74.0-9
ii  libboost-thread1.74.0  1.74.0-9
ii  libc6  2.31-13+deb11u2
ii  libcurl4   7.74.0-1.3+deb11u1
ii  libdcmtk15 3.6.5-1
ii  libgcc-s1  10.2.1-6
ii  libjpeg62-turbo1:2.0.6-4
ii  libjsoncpp24   1.9.4-4
ii  libopenjp2-7   2.4.0-3
ii  libpng16-161.6.37-3
ii  libpugixml1v5  1.11.4-1
ii  libstdc++6 10.2.1-6
ii  libtiff5   4.2.0-1
ii  libuuid1   2.36.1-8+deb11u1

Versions of packages orthanc-wsi recommends:
ii  libopenslide0  3.4.1+dfsg-5
pn  orthanc

orthanc-wsi suggests no packages.

-- no debconf information

Bug#1007770: Consider adding more key words as pre releases

[Antonio Terceiro]

On Wed, Mar 16, 2022 at 05:48:09PM +0530, Pirate Praveen wrote:
> Package: gem2deb
> Severity: wishlist
> 
> ruby-gollum-lib has
> gitlab-gollum-rugged_adapter', '~> 0.4.4.4.gitlab.1'
> 
> in gemspec and 0.4.4.4.gitlab.1 is taken as 0.4.4.4~gitlab.1 for debian
> package version. But ruby:Depends does not convert .gitlab to ~gitlab.

Please be more specific. Where exactly is 0.4.4.4.gitlab.1 being
converted to 0.4.4.4~gitlab.1? AFAICT gem2deb converts dependency
operators (i.e. ~> to >= ), but does not touches version numbers.


signature.asc
Description: PGP signature

Bug#1007779: dch should have option to update timestamp

[Marc Haber]

Package: devscripts
Version: 2.22.1
Severity: wishlist
File: /usr/bin/debchange

Hi,

some lintian warnings depend on the changelog timestamp. Also, some bugs
regarding reproducible builds only fire with a recent changelog
timestamp. Both classes of issues are going to happen after the release
of a package if only dch --release updates the timestamp.

Please consider implementing an option that ONLY updates the changelog
timestamp. Thank you!

Greetings
Marc

Bug#1007717: Native source package format with non-native version

[Felix Lechner]

Hi,

On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery  wrote:
>
> We should define native and non-native
> packages in terms of version numbers, and allow both native and non-native
> packages to use single-tarball source package formats.

I co-maintaintain several Debian-internal tools, and that description
is backwards. "Native" sources are characterized by their lack of
Debian patches.

On that note, the term "native" is also not great. The words "patched"
and "unpatched" describe the relationship between sources in the
archive and their respective upstreams more accurately.

As for version strings, we need no additional restrictions. The use of
patches is declared in source format 3.0. Some folks even use Debian
revisions for unpatched sources. [1]

Most significantly, Lintian's parser is unable to deduce "nativeness"
from the version number. The native status is a required input! [2]

Please do not "define" a source's patch status via the version string.
It's what got us here in the first place. Debian version numbers are
complicated enough already. Thank you!

Kind regards,
Felix Lechner

[1] for example, https://tracker.debian.org/pkg/python3-defaults
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Changelog/Version.pm#L79-80

Bug#994388: dpkg currently warning about merged-usr systems

[Sean Whitton]

Hello,

On Wed 16 Mar 2022 at 12:39am -07, Josh Triplett wrote:

> On March 15, 2022 11:38:44 PM PDT, Sean Whitton  
> wrote:
>>Hello Josh,
>>
>>On Tue 15 Mar 2022 at 03:14pm -07, Josh Triplett wrote:
>>
>>> It would appear that the situation has deteriorated further. dpkg 1.21.2
>>> now issues a warning on all merged-usr systems:
>>>
>>> Setting up dpkg (1.21.2) ...
>>> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
>>> dpkg: warning: See .
>>
>>Does this happen just when configuring dpkg.deb here, or does the
>>warning get issued at other times, have you seen?
>>
>
> Just dpkg. It's mentioned in the changelog.

Thanks for the pointer.  It's only in the postinst, it seems.  So this
is only going to get emitted once per system and only on upgraded
systems.

-- 
Sean Whitton

Bug#1007774: uwsgi: php plugin broken with php8

[Alexandre Rossi]

Source: uwsgi
Version: 2.0.20-2.2
Severity: normal
Tags: upstream patch

Dear Maintainer,

The PHP plugin has been broken since PHP8 has been uploaded to unstable. This 
is visible
in the autopkgtest[1].

[1] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/u/uwsgi-plugin-php/19736763/log.gz

The following patch should fix the problem although I could not test yet 
because of
#1007773 .

https://github.com/unbit/uwsgi/commit/3c23cc311cbe9b698d05e4f436a497f615afc2bb

Thanks,

Alex


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

Kernel: Linux 5.10.0-12-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
From: gdam...@gmail.com
Date: Wed, 29 Dec 2021 14:02:32 +0100
Subject: [PATCH] fix: missing arginfo when compiling against PHP 8
Origin: upstream, 
https://github.com/unbit/uwsgi/commit/3c23cc311cbe9b698d05e4f436a497f615afc2bb

---
 plugins/php/php_plugin.c | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/plugins/php/php_plugin.c b/plugins/php/php_plugin.c
index 717d6317b..d336adddc 100644
--- a/plugins/php/php_plugin.c
+++ b/plugins/php/php_plugin.c
@@ -497,21 +497,24 @@ PHP_FUNCTION(uwsgi_signal) {
 RETURN_NULL();
 }
 
+ZEND_BEGIN_ARG_INFO_EX(arginfo_void, 0, 0, 0)
+ZEND_END_ARG_INFO()
+
 zend_function_entry uwsgi_php_functions[] = {
-   PHP_FE(uwsgi_version,   NULL)
-   PHP_FE(uwsgi_setprocname,   NULL)
-   PHP_FE(uwsgi_worker_id,   NULL)
-   PHP_FE(uwsgi_masterpid,   NULL)
-   PHP_FE(uwsgi_signal,   NULL)
-
-   PHP_FE(uwsgi_rpc,   NULL)
-
-   PHP_FE(uwsgi_cache_get,   NULL)
-   PHP_FE(uwsgi_cache_set,   NULL)
-   PHP_FE(uwsgi_cache_update,   NULL)
-   PHP_FE(uwsgi_cache_del,   NULL)
-   PHP_FE(uwsgi_cache_clear,   NULL)
-   PHP_FE(uwsgi_cache_exists,   NULL)
+   PHP_FE(uwsgi_version, arginfo_void)
+   PHP_FE(uwsgi_setprocname, arginfo_void)
+   PHP_FE(uwsgi_worker_id, arginfo_void)
+   PHP_FE(uwsgi_masterpid, arginfo_void)
+   PHP_FE(uwsgi_signal, arginfo_void)
+
+   PHP_FE(uwsgi_rpc, arginfo_void)
+
+   PHP_FE(uwsgi_cache_get, arginfo_void)
+   PHP_FE(uwsgi_cache_set, arginfo_void)
+   PHP_FE(uwsgi_cache_update, arginfo_void)
+   PHP_FE(uwsgi_cache_del, arginfo_void)
+   PHP_FE(uwsgi_cache_clear, arginfo_void)
+   PHP_FE(uwsgi_cache_exists, arginfo_void)
{ NULL, NULL, NULL},
 };
 

Bug#1007773: uwsgi: FTBS with /usr/bin/ld: cannot find -lpcre2-8

[Alexandre Rossi]

Source: uwsgi
Version: 2.0.20-2.2
Severity: serious
Tags: ftbfs
Justification: Policy 4.9

Dear Maintainer,

uwsgi fails to build from source in a sbuild chroot with the following error.

/usr/share/apr-1.0/build/libtool  --mode=link --tag=disable-static 
x86_64-linux-gnu-gcc -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -lpcre2-8 
-L/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0-o apache2/mod_Ruwsgi.la  
-L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu -lapr-1 -laprutil-1 
-rpath /usr/lib/apache2/modules -module -avoid-versionapache2/mod_Ruwsgi.lo
libtool: link: x86_64-linux-gnu-gcc -shared  -fPIC -DPIC  
apache2/.libs/mod_Ruwsgi.o   -lpcre2-8 
-L/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 -L/usr/lib/x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu/libapr-1.so /usr/lib/x86_64-linux-gnu/libaprutil-1.so 
 -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now   -pthread -Wl,-soname 
-Wl,mod_Ruwsgi.so -o apache2/.libs/mod_Ruwsgi.so
/usr/bin/ld: cannot find -lpcre2-8: No such file or directory
collect2: error: ld returned 1 exit status
apxs:Error: Command failed with rc=65536
.
make: *** [debian/rules:517: debian/stamp-libapache2-mod-ruwsgi] Error 1
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Thanks,

Alex

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

Kernel: Linux 5.10.0-12-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#1005468: git-buildpackage: FTBFS: XXX

[Guido Günther]

control: retitle -1 Fails on non breaking space

Hi,
On Tue, Mar 15, 2022 at 01:36:11PM +0100, Carsten Schoenert wrote:
> Control: tags -1 help
> 
> Hi,
> 
> Am Sun, Feb 13, 2022 at 12:51:47PM +0100 schrieb Guido Günther:
>  
> > I moved this here since nothing did change on the gbp site in that
> > area however it seems pydoctor didn't change either.
> > 
> > The python 3.8 changelog has
> > 
> > Python3 changelog and no sax parser change popped out that 
> > python3's sax parser changes didn't 
> > 
> > could that trigger it? I would expect for this to get noticed earlier
> > then though. I didn't look at changes in twisted yet.
> > 
> > Please move the issue back to gbp if you think it should be fixed there.
> 
> I think the root for the issue is mainly the updated pydoctor package.
> No other package that is a dependency of pydoctor has got a significant
> update too and no other involved package got also an update since the
> build of git-buildpackage is failing.
> 
> To dive into the problem I've prepared a local pbuilder chroot with the
> data from the day before pydoctor 21.12.1-1 was uploaded (that was 15
> Jan 2022 08:49:16 +) to unstable by using snapshots.d.o.
> 
> Building git-buildpackage with packages from 14 Jan 2022 works as
> expected.
> 
> Using data from snapshot.d.o. right after the upload of pydoctor
> 21.12.1-1 makes the build of git-buildpackage fail with the exact same
> error log visible in the starting email of this report.
> I've added some hacky debug printing into
> usr/lib/python3.9/xml/sax/expatreader.py around line 221 to see what
> excately is the string the build is complaining about. This leeds to
> this output (data is the second argument within 'def feed()' in line
> 206 of expatreader.py):
> 
> %<
> +++debug+++
> data= 
> -->stror  class="rst-docutils literal">listof str<--
> undefined entity: line 1, column 46
> +++debug+++
> Traceback (most recent call last):
>   File "/usr/lib/python3.9/xml/sax/expatreader.py", line 219, in feed
> self._parser.Parse(data, isFinal)
> xml.parsers.expat.ExpatError: undefined entity: line 1, column 46
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/twisted/web/_flatten.py", line 390, in 
> _flattenTree
> element = next(stack[-1])
> >%
> 
> To me the data fiels looks like valid HTML/CSS code...

Carsten extracted this:

  stror listof str

and it would fail on  which came about by a non breaking space (C2
A0) in gbp's source code. Removing these makes gbp's API build pass
again but it still looks like a regression in pydoctor.

Cheers,
 -- Guido

Bug#1002262: [Pkg-javascript-devel] Bug#1002262: node-trust-webcrypto: FTBFS: make[1]: *** [debian/rules:18: override_dh_auto_test] Error 1

[Yadd]

On 16/03/2022 14:32, Yadd wrote:

Hi,

my tools report that problem comes from incompatibility with 
node-trust-keyto (@trust/keyto) 2.0.0-alpha1. Test passed with 
@trust/keyto 0.3.7


@trust/keyto 2.0.0-alpha1 renamed EDDSA to EdDSA. Bug may come from this

Bug#1007769: scipy: FTBFS on sh4

[Laurent Bigonville]

Source: scipy
Version: 1.7.3-2
Severity: important
Tags: ftbfs
Forwarded: https://github.com/scipy/scipy/issues/15584

Hello,

scipy currently FTBFS on sh4 with the following error:

sh4-linux-gnu-gcc: scipy/special/_test_round.c
scipy/special/_test_round.c: In function 
‘__pyx_pf_5scipy_7special_11_test_round_have_fenv’:
scipy/special/_test_round.c:2213:30: error: ‘FE_UPWARD’ undeclared (first use 
in this function)
 2213 | __pyx_t_1 = ((fesetround(FE_UPWARD) != 0) != 0);
  |  ^
scipy/special/_test_round.c:2213:30: note: each undeclared identifier is 
reported only once for each function it appears in
scipy/special/_test_round.c:2241:30: error: ‘FE_DOWNWARD’ undeclared (first use 
in this function); did you mean ‘FP_INT_DOWNWARD’?
 2241 | __pyx_t_1 = ((fesetround(FE_DOWNWARD) != 0) != 0);
  |  ^~~
  |  FP_INT_DOWNWARD
scipy/special/_test_round.c: In function 
‘__pyx_pf_5scipy_7special_11_test_round_4test_add_round’:
scipy/special/_test_round.c:2767:37: error: ‘FE_UPWARD’ undeclared (first use 
in this function)
 2767 | __pyx_v_status = fesetround(FE_UPWARD);
  | ^
scipy/special/_test_round.c:2825:37: error: ‘FE_DOWNWARD’ undeclared (first use 
in this function); did you mean ‘FP_INT_DOWNWARD’?
 2825 | __pyx_v_status = fesetround(FE_DOWNWARD);
  | ^~~
  | FP_INT_DOWNWARD

Upstream seems to think that it's a bug in the architecture and propose
that debian carries a patch for it:

https://github.com/scipy/scipy/issues/15584#issuecomment-1069125146

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.16.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#1002262: node-trust-webcrypto: FTBFS: make[1]: *** [debian/rules:18: override_dh_auto_test] Error 1

[Yadd]

Hi,

my tools report that problem comes from incompatibility with 
node-trust-keyto (@trust/keyto) 2.0.0-alpha1. Test passed with 
@trust/keyto 0.3.7

Bug#1007768: webpack 5 incompatible with eslint-scope >= 7

[Yadd]

Package: webpack
Version: 4.43.0-7
Severity: important

Hi,

in lib/optimize/ConcatenatedModule.js, webpack tries to use
eslint-scope/lib/referencer which is no more authorized in
eslint-scope/package.json#exports.

Here is an untested patch.

Cheers,
Yadd

--- a/lib/optimize/ConcatenatedModule.js
+++ b/lib/optimize/ConcatenatedModule.js
@@ -6,7 +6,7 @@
 "use strict";

 const eslintScope = require("eslint-scope");
-const Referencer = require("eslint-scope/lib/referencer");
+const Referencer = eslintScope.Referencer;
 const {
CachedSource,
ConcatSource,

Bug#1007767: python3-httpx: Need h11 0.11+

[Matthias Urlichs]

Package: python3-httpx
Version: 0.22.0-1
Severity: important
X-Debbugs-Cc: sm...@smurf.noris.de

Please teach httpx that it needs to depend on h11 >>0.11.

Error while testing:

self = http://localhost:40923', CLOSED, Request Count: 
1]>
request = 

async def _receive_response_headers(
self, request: Request
) -> Tuple[bytes, int, bytes, List[Tuple[bytes, bytes]]]:
timeouts = request.extensions.get("timeout", {})
timeout = timeouts.get("read", None)

while True:
event = await self._receive_event(timeout=timeout)
if isinstance(event, h11.Response):
break

http_version = b"HTTP/" + event.http_version

# h11 version 0.11+ supports a `raw_items` interface to get the
# raw header casing, rather than the enforced lowercase headers.
>   headers = event.headers.raw_items()
E   AttributeError: 'list' object has no attribute 'raw_items'


-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'oldstable'), (500, 
'unstable'), (450, 'focal'), (350, 'oldoldstable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 python3-httpx depends on:
ii  python3 3.9.2-3
ii  python3-async-generator 1.10-3
ii  python3-certifi 2020.6.20-1
ii  python3-charset-normalizer  2.0.6-2
ii  python3-click   8.0.3-1
ii  python3-httpcore0.14.5-1
ii  python3-pygments2.7.1+dfsg-2.1
ii  python3-rfc3986 1.4.0-3
ii  python3-rich11.2.0-1
ii  python3-sniffio 1.1.0-1

python3-httpx recommends no packages.

python3-httpx suggests no packages.

-- debconf-show failed

Bug#1007766: ITP: mppp -- C++11/14/17/20 library for multiprecision arithmetic

[Gürkan Myczko]

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

* Package name: mppp
  Version : 0.26
  Upstream Authors: 2016-Francesco Biscani 
  URL : https://github.com/bluescarni/mppp
* License : MPL-2.0
  Description : C++11/14/17/20 library for multiprecision arithmetic
 Built on top of the GNU multiprecision stack (GMP, MPFR, MPC), mp++ was
 initially conceived as a GMP wrapper with special focus on performance 
with

 small operands. In particular, a small buffer optimisation and custom
 implementations of basic mathematical primitives are instrumental in 
achieving
 a performance increase, with respect to GMP and other integer 
multiprecision

 libraries, which can be substantial.

Bug#1007748: Info received (Bug#1007748: Acknowledgement (telegram-desktop: hangs on tasks related to audio and fail to read audio messages))

[Tomasz Kapias]

I tried to apply the patch for Wireplumber, but it was not the issue for me.

But it gave me a lead. In fact wireplumber is conflicting with pipewire-session-
manager. Wireplumber is replacing it but pipewire-session-manager was still
installed by APT and the systemd service was not replaced by wireplumber.

I removed pipewire-session-manager, wireplumber and pipewire-pulse. Then
reinstalled them, and there is no more issue with Telegram.

Bug#1002012: [pre-approval] bullseye-pu: package sysvinit/2.96-7

[Mark Hindley]

Adam,

On Tue, Mar 15, 2022 at 09:17:42PM +, Adam D. Barratt wrote:
> Please go ahead; sorry for the delay.

Thanks. Uploaded.

Mark

Bug#1007765: ITS: libpgf

[Boyuan Yang]

Source: libpgf
Version: 6.14.12-3.2
Severity: important
X-Debbugs-CC: da...@debian.org

Dear package libpgf maintainer in Debian,

After looking into the package you maintain (libpgf, 
https://tracker.debian.org/pkg/libpgf), I found that this package
received no maintainer uploads in the past 8 years and was not in good
shape. As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan is to fix current FTBFS bug (https://bugs.debian.org/984203),
clean up packaging and orphan this package to allow possible external
contribution.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(Apr. 06, 2022) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#1007764: gcc-defaults: please support DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Source: gcc-defaults
Version: 1.194
Severity: normal
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support
X-Debbugs-Cc: jo...@debian.org

Hi,

when creating chroots for new architectures that are in the process of
being bootstrapped without yet having emulation support from qemu, it is
not possible to run maintainer scripts inside the foreign architecture
chroot because foreign architecture ELF binaries cannot be executed. The
solution to that problem is to run maintainer scripts from outside the
chroot and use the DPKG_ROOT environment variable to instruct the
maintainer script on which chroot to operate. By default, for normal
installations, that environment variable is set, but empty.

Apart from init-system-helpers and pam, all packages in the
Essential:yes set have support for DPKG_ROOT already. To start building
packages we also need to install build-essential.

Please consider applying the patch from this merge request:

https://salsa.debian.org/toolchain-team/gcc-defaults/-/merge_requests/4

We tested it in our CI environment and it produces a bit-by-bit
identical chroot with DPKG_ROOT compared to a normal installation.

https://salsa.debian.org/helmutg/dpkg-root-demo/

Since the DPKG_ROOT variable is empty on normal installations, the patch
should have no effect in the normal case.

Thanks!

cheers, josch

Bug#1007763: linux-image-5.10.0-12-amd64: suspend using s0ix causes system to overheat

[Rusty]

Package: src:linux
Version: 5.10.103-1
Severity: normal
X-Debbugs-Cc: rgr...@rsu20.org

Dear Maintainer,

Beginning with linux-image-5.10.0-12-amd64, I've been seeing multiple Lenovo 
L13 Gen 2s not suspending correctly (I think). These devices are using s0ix for 
suspend instead of s3, which is the firmware default.
The device looks like it is sleeping like normal with slow pulse status 
indicator lights, but the system ends up getting hot while just sitting 
there... even worse in a travel bag.
Issue occurs on multiple firmware revisions.

-- Package-specific info:
** Version:
Linux version 5.10.0-12-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.103-1 (2022-03-07)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-12-amd64 
root=UUID=fe38ee53-38a5-4695-a4d4-b1166348fb1d ro quiet loglevel=1 splash 
zswap.enabled=1 zswap.compressor=zstd

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[400306.537722] Restarting tasks ... done.
[400306.568924] PM: suspend exit
[400306.569178] mei_hdcp :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: 
bound :00:02.0 (ops i915_hdcp_component_ops [i915])
[400306.636122] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 
c5cf9334 port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed
[400306.665448] usb 2-3: new SuperSpeed Gen 1 USB device number 6 using xhci_hcd
[400306.669314] usb 3-1: new high-speed USB device number 26 using xhci_hcd
[400306.677676] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 
c5cf9334 port 2: DPCD read on addr 0x4b0 for 1 bytes NAKed
[400306.688202] usb 2-3: New USB device found, idVendor=17ef, idProduct=3072, 
bcdDevice=50.43
[400306.688205] usb 2-3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[400306.688206] usb 2-3: Product: USB3.0 Hub 
[400306.688207] usb 2-3: Manufacturer: VIA Labs, Inc. 
[400306.691649] hub 2-3:1.0: USB hub found
[400306.691833] hub 2-3:1.0: 4 ports detected
[400306.716518] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 
c5cf9334 port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed
[400306.822934] usb 3-1: New USB device found, idVendor=17ef, idProduct=3073, 
bcdDevice=50.43
[400306.822938] usb 3-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[400306.822939] usb 3-1: Product: USB2.0 Hub 
[400306.822940] usb 3-1: Manufacturer: VIA Labs, Inc. 
[400306.824062] hub 3-1:1.0: USB hub found
[400306.824218] hub 3-1:1.0: 4 ports detected
[400307.085420] usb 3-2: new full-speed USB device number 27 using xhci_hcd
[400307.240239] usb 3-2: New USB device found, idVendor=17ef, idProduct=3076, 
bcdDevice= 0.00
[400307.240244] usb 3-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[400307.240247] usb 3-2: Product: USB Billboard
[400307.240250] usb 3-2: Manufacturer: Cypress Semiconductor
[400307.240252] usb 3-2: SerialNumber: 1S40AHM5F0ACZY
[400307.246696] hid-generic 0003:17EF:3076.000E: hiddev0,hidraw0: USB HID v1.11 
Device [Cypress Semiconductor USB Billboard] on usb-:00:14.0-2/input1
[400307.305979] usb 2-3.4: new SuperSpeed Gen 1 USB device number 7 using 
xhci_hcd
[400307.330019] psmouse serio1: elantech: assuming hardware version 4 (with 
firmware version 0x5f3001)
[400307.343662] psmouse serio1: elantech: Synaptics capabilities query result 
0x90, 0x18, 0x0d.
[400307.359240] psmouse serio1: elantech: Elan sample query result 00, 0d, a7
[400307.373327] psmouse serio1: elantech: Elan ic body: 0x11, current fw 
version: 0x4
[400307.407975] usb 2-3.4: New USB device found, idVendor=17ef, idProduct=3072, 
bcdDevice=50.33
[400307.407981] usb 2-3.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[400307.407983] usb 2-3.4: Product: USB3.0 Hub 
[400307.407986] usb 2-3.4: Manufacturer: VIA Labs, Inc. 
[400307.420637] hub 2-3.4:1.0: USB hub found
[400307.422161] hub 2-3.4:1.0: 1 port detected
[400307.462699] psmouse serio1: elantech: Trying to set up SMBus access
[400307.463338] elan_i2c 16-0015: supply vcc not found, using dummy regulator
[400307.481985] elan_i2c 16-0015: Elan Touchpad: Module ID: 0x000d, Firmware: 
0x0001, Sample: 0x, IAP: 0x
[400307.482408] input: Elan Touchpad as 
/devices/pci:00/:00:1f.4/i2c-16/16-0015/input/input61
[400307.484965] input: Elan TrackPoint as 
/devices/pci:00/:00:1f.4/i2c-16/16-0015/input/input62
[400307.561340] usb 3-1.2: new low-speed USB device number 28 using xhci_hcd
[400307.716212] usb 3-1.2: New USB device found, idVendor=04b3, idProduct=3025, 
bcdDevice= 1.09
[400307.716214] usb 3-1.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[400307.716215] usb 3-1.2: Product: USB NetVista Full Width Keyboard.
[400307.716215] usb 3-1.2: Manufacturer: LITE-ON Technology
[400307.724331] input: LITE-ON Technology USB NetVista Full Width Keyboard. as 

Bug#1003173: bullseye-pu: package nvidia-cuda-toolkit/11.2.2-3+deb11u1

[Andreas Beckmann]

On 15/03/2022 22.08, Adam D. Barratt wrote:

Control: tags -1 + confirmed

On Wed, 2022-01-05 at 16:57 +0100, Andreas Beckmann wrote:

I'd like to update nvidia-cuda-toolkit in bullseye/non-free in order
to
disable the non-functional python3 support in cuda-gdb. This causes
segmentation faults if libpython2.7.so.1 is available on the system,
due
to dlopening that library even if we built cuda-gdb against
python3.x.
(python3 support in cuda-gdb became functional and was re-enabled in
11.4,
it does not look fixable in 11.2 due to incomplete python3 support)



Please go ahead; sorry for the delay.


Thanks, uploading ...

In the meantime, I've added two more changes (and probably more Lintian 
overrides, too):


 * Add (tesla-)510 driver as alternate dependency.
 * Add superficial autopkgtest checking the usability of the STL headers
   in host code compiled with nvcc (cf. #1006962).
   Mark as flaky to avoid regressions.

Knowing which STL headers fail to compile with nvcc may help analyzing 
build failures in external projects.



Andreas

Bug#989777: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Andrej Ilner]

On Fri, 26 Nov 2021 12:56:36 +0100 (CET) "pham...@bluewin.ch" 
 wrote:
> Hello,
> I am pleased to announce that bluetooth now works correctly with Kernel 
5.15.3-1: amd64 and my Intel AX210 Wifi / Bluetooth card :)
> Keyboards on the other hand still cannot be paired, but this must be due to a 
Blueman v 2.1.4 dependency issue.
> Unfortunately this Kernel still does not manage the switching between an 
Intel card (integrated) and Nvidia (discrete) on laptops.
> Thank you for your support, this ticket can be closed.
> Sincerely yours and a very happy New Year's Eve !!!
> Best regards.
> Philippe

Hi Philippe,


did you do anything else besides installing a new kernel?

Last year I bought a machine with a AX 210, which didn't work on Linux. I had to use Ubuntu (wifi and bluetooth both worked) until 5.14 was released in November for Debian 
bookworm. Wifi worked but bluetooth didn't.


I'm now on 5.16 and bluetooth still doesn't work on this machine. Doesn't 
matter whether it's a cold start, a reboot or this machine wakes from sleep.


root@hostname:~# journalctl -k | grep -Ei 'bluetooth|iwlwifi'
Mar 16 06:24:47 Pleiades-1137 kernel: thinkpad_acpi: rfkill switch 
tpacpi_bluetooth_sw: radio is unblocked
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: enabling device ( 
-> 0002)
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: firmware: failed to 
load iwlwifi-ty-a0-gf-a0-67.ucode (-2)
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: Direct firmware 
load for iwlwifi-ty-a0-gf-a0-67.ucode failed with error -2
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: firmware: 
direct-loading firmware iwlwifi-ty-a0-gf-a0-66.ucode
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: api flags index 2 
larger than supported by driver
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: 
TLV_FW_FSEQ_VERSION: FSEQ Version: 0.63.2.1
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: loaded firmware 
version 66.55c64978.0 ty-a0-gf-a0-66.ucode op_mode iwlmvm
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: firmware: failed to 
load iwl-debug-yoyo.bin (-2)
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: Core ver 2.22
Mar 16 06:24:47 Pleiades-1137 kernel: NET: Registered PF_BLUETOOTH protocol 
family
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: HCI device and connection 
manager initialized
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: HCI socket layer initialized
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: L2CAP socket layer initialized
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: SCO socket layer initialized
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: hci0: Device revision is 0
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: hci0: Secure boot is enabled
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: hci0: OTP lock is enabled
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: hci0: API lock is enabled
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: hci0: Debug lock is disabled
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: hci0: Minimum firmware build 1 
week 10 2014
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: hci0: Bootloader timestamp 
2019.40 buildtype 1 build 38
Mar 16 06:24:47 Pleiades-1137 kernel: bluetooth hci0: firmware: direct-loading 
firmware intel/ibt-0041-0041.sfi
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: hci0: Found device firmware: 
intel/ibt-0041-0041.sfi
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: hci0: Boot Address: 0x100800
Mar 16 06:24:47 Pleiades-1137 kernel: Bluetooth: hci0: Firmware Version: 
86-28.21
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: Detected Intel(R) 
Wi-Fi 6 AX210 160MHz, REV=0x420
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: WRT: Failed to set 
DRAM buffer for alloc id 1, ret=-1
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: WRT: Failed to set 
DRAM buffer for alloc id 2, ret=-1
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: WRT: Failed to set 
DRAM buffer for alloc id 3, ret=-1
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: firmware: 
direct-loading firmware iwlwifi-ty-a0-gf-a0.pnvm
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: loaded PNVM version 
d35929d8
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: Detected RF GF, 
rfid=0x10d000
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0: base HW address: 
54:14:f3:af:a4:ec
Mar 16 06:24:47 Pleiades-1137 kernel: iwlwifi :09:00.0 wlp9s0: renamed from 
wlan0
Mar 16 06:24:49 Pleiades-1137 kernel: Bluetooth: BNEP (Ethernet Emulation) ver 
1.3
Mar 16 06:24:49 Pleiades-1137 kernel: Bluetooth: BNEP filters: protocol 
multicast
Mar 16 06:24:49 Pleiades-1137 kernel: Bluetooth: BNEP socket layer initialized
Mar 16 06:24:49 Pleiades-1137 kernel: iwlwifi :09:00.0: WRT: Failed to set 
DRAM buffer for alloc id 1, ret=-1
Mar 16 06:24:49 Pleiades-1137 kernel: iwlwifi :09:00.0: WRT: Failed to set 
DRAM buffer for alloc id