Bug#1003893: pseudo breaks tar and thereby building python2.7

[Andrej Shadura]

Hi,

On Mon, 17 Jan 2022 20:01:26 +0100 Helmut Grohne  wrote:

Any of the following actions resolve this bug:
 * Removing pseudo from the archive.
 * Having pseudo stop providing fakeroot.
 * Having pseudo stop making tar segfault.


Downgrading the severity since pseudo haven’t been providing fakeroot 
since 1.9.0+git2021+300d7570720b-2.


--
Cheers,
  Andrej

Bug#1005797: [Pkg-utopia-maintainers] Bug#1005797: network-manager: after upgrade to 1.35.91-1, VPN routes are dropped

[Michael Biebl]

Am 15.02.22 um 07:41 schrieb Norbert Kiesel:

Package: network-manager
Version: 1.35.91-1
Severity: important
X-Debbugs-Cc: n...@iname.com

Dear Maintainer,

I used network-manager with open-connect to conext to my corporate network for
years. After the upgrade to 1.35.91-1, my VPN stopped working.  I looked at the
changes in the nmconnection file and I see the following (I have etckeeper
configured and thus can show the changes):

-dns=1.1.1.1;10.0.1.165;
+dns=1.1.1.1;10.10.10.98;
  dns-search=
  ignore-auto-routes=true
  method=auto
-never-default=true
-route1=10.0.0.0/8
-route2=172.16.0.0/12
-route3=192.168.0.0/16
-route4=63.205.89.190/32
-route5=148.168.136.0/21
-route6=192.9.200.0/24

I manually added the routes again and then ran `nmcli connection down ;
nmcli connection up `.  but the routes were gone again. So seem that
network-amanger removes the routes on startup.


Looking at the NEWS file, I wonder if this is related to


* Routes managed by routing daemons are now ignored. This is done to
  address a performance bottleneck on specialized routers.


Could you please raise this upstream at
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues

What you see might be a deliberate change in behavior or a simply a bug.

The upstream developers can help you further with this.

Regards,
Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005798: ITP: golang-github-sebdah-goldie -- Golden file testing for Go (library)

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: golang-github-sebdah-goldie -- Golden file testing for Go 
(library)
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: golang-github-sebdah-goldie
  Version : 2.5.3
  Upstream Author : Sebastian Dahlgren
* URL : https://github.com/sebdah/goldie
* License : Expat
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : Golden file testing for Go (library)
 Goldie is a golden file test utility for Go projects. It's typically
 used for testing responses with larger data bodies.
 .
 The concept is straight forward. Valid response data is stored in a
 "golden file". The actual response data will be byte compared with the
 golden file and the test will fail if there is a difference.
 .
 Updating the golden file can be done by running go test -update ./

Remark: This package is maintained by Debian Go Packaging Team at
   https://salsa.debian.org/go-team/packages/golang-github-sebdah-goldie

Bug#1005796: libxmu: FTBFS on arch-indep buildd

[Sebastiaan Couwenberg]

Control: tags -1 patch

The attached patch resolves the issue.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1From 4ca536e51e51850a7a93da8c173c5395828965fb Mon Sep 17 00:00:00 2001
From: Bas Couwenberg 
Date: Tue, 15 Feb 2022 07:39:00 +0100
Subject: Fix dh_install override. (closes: #1005796)

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

diff --git a/debian/rules b/debian/rules
index 63cf75b..62bda98 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,7 +25,7 @@ override_dh_auto_install:
 	dh_auto_install
 	find debian/tmp/usr/share/doc/libxmu-headers -name '*.xml' -delete
 
-override_dh_install-arch:
+override_dh_install:
 	find debian/tmp -name '*.la' -delete
 	dh_install
 
-- 
2.30.2

Bug#1005797: network-manager: after upgrade to 1.35.91-1, VPN routes are dropped

[Norbert Kiesel]

Package: network-manager
Version: 1.35.91-1
Severity: important
X-Debbugs-Cc: n...@iname.com

Dear Maintainer,

I used network-manager with open-connect to conext to my corporate network for
years. After the upgrade to 1.35.91-1, my VPN stopped working.  I looked at the
changes in the nmconnection file and I see the following (I have etckeeper
configured and thus can show the changes):

-dns=1.1.1.1;10.0.1.165;
+dns=1.1.1.1;10.10.10.98;
 dns-search=
 ignore-auto-routes=true
 method=auto
-never-default=true
-route1=10.0.0.0/8
-route2=172.16.0.0/12
-route3=192.168.0.0/16
-route4=63.205.89.190/32
-route5=148.168.136.0/21
-route6=192.9.200.0/24

I manually added the routes again and then ran `nmcli connection down ;
nmcli connection up `.  but the routes were gone again. So seem that
network-amanger removes the routes on startup.



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

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

Versions of packages network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.20-3
ii  libaudit11:3.0.7-1
ii  libbluetooth35.62-2
ii  libc62.33-5
ii  libcurl3-gnutls  7.81.0-1
ii  libglib2.0-0 2.70.3-1
ii  libgnutls30  3.7.3-4+b1
ii  libjansson4  2.13.1-1.1
ii  libmm-glib0  1.18.4-1
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-5+b1
ii  libnm0   1.35.91-1
ii  libpsl5  0.21.0-1.2
ii  libreadline8 8.1.2-1
ii  libselinux1  3.3-1+b1
ii  libsystemd0  250.3-2
ii  libteamdctl0 1.31-1
ii  libudev1 250.3-2
ii  policykit-1  0.105-31.1+b1
ii  udev 250.3-2

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.86-1.1
ii  iptables 1.8.7-1
ii  libpam-systemd   250.3-2
ii  modemmanager 1.18.4-1
ii  ppp  2.4.9-1+1
ii  wireless-regdb   2021.08.28-1
ii  wpasupplicant2:2.10-2

Versions of packages network-manager suggests:
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.1-2.3

-- no debconf information

Bug#1005796: libxmu: FTBFS on arch-indep buildd

[Bas Couwenberg]

Source: libxmu
Version: 2:1.1.3-2
Severity: serious
Tags: ftbfs
Justification: makes the package in question unusable or mostly so
Control: affects -1 src:pdl

Dear Maintainer,

Your package FTBFS on the all buildd:

 dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: libxmu-dev (3), libxmu-headers (2), libxmu6 (2), 
libxmuu-dev (3), libxmuu1 (2)
 * dh_installdocs: libxmu-dev (0), libxmu-headers (0), libxmu6 (0), 
libxmuu-dev (0), libxmuu1 (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.
 
Remember to be careful with paths containing "x86_64-linux-gnu", where 
you might need to
use a wildcard or (assuming compat 13+) e.g. ${DEB_HOST_MULTIARCH} in 
debian/not-installed
to ensure it works on all architectures (see #961104).

https://buildd.debian.org/status/fetch.php?pkg=libxmu=all=2%3A1.1.3-2=1644852059=0

This makes libxmu-dev uninstallable:

 libxmu-dev : Depends: libxmu-headers (= 2:1.1.3-2) but it is not installable

Kind Regards,

Bas

Bug#997972: haskell-pandoc-citeproc has been deprecated upstream

[Sean Whitton]

Hello,

On Wed 27 Oct 2021 at 07:13pm -04, Louis-Philippe Véronneau wrote:

> Package: src:haskell-pandoc-citeproc
> Version: 2.9.2.1-1+b2
> Severity: important
>
> Dear maintainers,
>
> This project has been deprecated upstream since October 9th 2020 [1].
> There is a new project called "citeproc" by the same author that
> replaces it [2].
>
> Pandoc version 2.11 (not in Debian yet) now supports the new citeproc
> invocation ("--citeproc" instead of "--filter pandoc-citeproc") and I
> believe requires this new binary.
>
> Does anyone plan to package the new "citeproc"?

I guess that this will happen when pandoc itself gets updated.

-- 
Sean Whitton

Bug#1005784: policykit-1: CVE-2021-4115: file descriptor leak allows an unprivileged user to cause a crash

[Salvatore Bonaccorso]

Hi Simon,

On Mon, Feb 14, 2022 at 10:07:49PM +, Simon McVittie wrote:
> On Mon, 14 Feb 2022 at 22:29:29 +0100, Salvatore Bonaccorso wrote:
> > Simon, Michael opinions on the DSA need? *If* it's automatically
> > restarted after crash, then we can schedule the fixes via the upcoming
> > point releases IMHO.
> 
> I can't say much about the impact of a vulnerability that doesn't have
> a patch or any details available, but if it's literally just running
> out of fd space and crashing, that's pretty weak even as an attack
> on availability.

Apologies, this is my fault. I was expecting that the commit is going
to be pushed out soon (as the issue was public after 15:00 UTC) but
apparently not. I'm attaching teh aimed patch. The issue is introduced
by the "PolkitSystemBusName: Retrieve both pid and uid" patch we
backport.

> polkitd is D-Bus-activated on-demand, so a crash should just inconvenience
> people who are actively trying to authenticate at that moment: the next
> time a client tries to contact polkit, systemd (if used) or dbus-daemon
> (if using other init systems) will relaunch polkitd automatically before
> delivering the message.

Yes, that would be exactly the poing. As polkitd will be relaunched I
think this would be more no-dsa than needing a DSA. Along with the
point release update we maight as well replace the changes done for
CVE-2021-4034 with the upstream approach (with correct exit status).

Regards,
Salvatore
>From a7b1416cca95441d14e67775274a9887c83d4d10 Mon Sep 17 00:00:00 2001
From: Jan Rybar 
Date: Mon, 31 Jan 2022 11:34:15 +0100
Subject: [PATCH] CVE-2021-4115 (GHSL-2021-077) fix

Quitting loop before both dbus responds received causes file descriptor
leak
---
 src/polkit/polkitsystembusname.c | 37 
 1 file changed, 33 insertions(+), 4 deletions(-)

diff --git a/src/polkit/polkitsystembusname.c b/src/polkit/polkitsystembusname.c
index 8ed1363..153ca7d 100644
--- a/src/polkit/polkitsystembusname.c
+++ b/src/polkit/polkitsystembusname.c
@@ -62,6 +62,10 @@ enum
   PROP_NAME,
 };
 
+
+int dbus_call_respond_fails;  // has to be global because of callback
+
+
 static void subject_iface_init (PolkitSubjectIface *subject_iface);
 
 G_DEFINE_TYPE_WITH_CODE (PolkitSystemBusName, polkit_system_bus_name, G_TYPE_OBJECT,
@@ -364,6 +368,7 @@ on_retrieved_unix_uid_pid (GObject  *src,
   if (!v)
 {
   data->caught_error = TRUE;
+  dbus_call_respond_fails += 1;
 }
   else
 {
@@ -395,6 +400,7 @@ polkit_system_bus_name_get_creds_sync (PolkitSystemBusName   *system_bus
   AsyncGetBusNameCredsData data = { 0, };
   GDBusConnection *connection = NULL;
   GMainContext *tmp_context = NULL;
+  dbus_call_respond_fails = 0;
 
   connection = g_bus_get_sync (G_BUS_TYPE_SYSTEM, cancellable, error);
   if (connection == NULL)
@@ -432,11 +438,34 @@ polkit_system_bus_name_get_creds_sync (PolkitSystemBusName   *system_bus
 			  on_retrieved_unix_uid_pid,
 			  );
 
-  while (!((data.retrieved_uid && data.retrieved_pid) || data.caught_error))
-g_main_context_iteration (tmp_context, TRUE);
+  while (TRUE)
+  {
+/* If one dbus call returns error, we must wait until the other call
+ * calls _call_finish(), otherwise fd leak is possible.
+ * Resolves: GHSL-2021-077
+*/
 
-  if (data.caught_error)
-goto out;
+if ( (dbus_call_respond_fails > 1) )
+{
+  // we got two faults, we can leave
+  goto out;
+}
+
+if ((data.caught_error && (data.retrieved_pid || data.retrieved_uid)))
+{
+  // we got one fault and the other call finally finished, we can leave
+  goto out;
+}
+
+if ( !(data.retrieved_uid && data.retrieved_pid) )
+{
+  g_main_context_iteration (tmp_context, TRUE);
+}
+else
+{
+  break;
+}
+  }
 
   if (out_uid)
 *out_uid = data.uid;
-- 
2.31.1

Bug#1005795: origtargz: MUT package tarball creation fails

[Maxime Chambonnet]

Package: origtargz
Version: origtargz
Severity: normal
X-Debbugs-Cc: max...@maxzor.eu

Dear Maintainer,

origtargz fails on Multi-Upstream Tarball (MUT) packages it seems.
On this example package hipamd, I imported the tarball with:

gbp import-orig --component=clr --component=opencl --component=hip --pristine-
tar --uscan

https://salsa.debian.org/rocm-team/rocm-hipamd

(you should be able to quickly repro with equivs for BDs.)

uscan --overwrite-download works.

Best regards, Maxime


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

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

Bug#1005794: snibbetracker: reproducible-builds: Build path embedded in debug symbols

[Vagrant Cascadian]

Source: snibbetracker
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Different build paths trigger reproducibility issues with binaries such
as /usr/bin/snibbetracker and relevent debugging symbols.

For two builds done with reprotest, the debug symbols contain the
different build paths:

  0  (line_strp) (offset: 0x0): 
/tmp/reprotest.lNSnkN/const_build_path/snibbetracker/src
vs.
  0  (line_strp) (offset: 0x0): 
/tmp/reprotest.lNSnkN/build-experiment-1/snibbetracker/src


The attached patch fixes this by passing -ffile-prefix-map in
debian/Makefile to avoid embedding the build path into the binaries.


Another option might be to pass COMPILER_FLAGS=$(CFLAGS) to use the
default flags from debhelper/dpkg-buildflags, which includes
-ffile-prefix-map, and/or explore patching the upstream
Makefile to accept variables passed to it...


With this patch applied, snibbetracker should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining snibbetracker!


live well,
  vagrant
From d2cb9d8738ad25dcbbe9a0cb2dd8906d86e558e5 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 15 Feb 2022 02:05:07 +
Subject: [PATCH] debian/Makefile: Pass -ffile-prefix-map to remove build
 directory from binaries.

Without this, building the package in a different directory results in
different binaries.

https://reproducible-builds.org/docs/build-path/
---
 debian/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/Makefile b/debian/Makefile
index f053e39..33ccea1 100644
--- a/debian/Makefile
+++ b/debian/Makefile
@@ -14,7 +14,7 @@ INCLUDE_PATHS = -I/usr/include/cjson
 LIBRARY_PATHS = -L/usr/lib/x86_64-linux-gnu
 
 # Compiler flags
-COMPILER_FLAGS = -Wall -std=c99 -Wno-unused-function -g
+COMPILER_FLAGS = -Wall -std=c99 -Wno-unused-function -g -ffile-prefix-map=$(CURDIR)=.
 
 # Linker flags
 LINKER_FLAGS = -lSDL2main -lSDL2 -lm -lcjson -luuid
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#890472: Clarification

[Shmerl]

I contacted LunarG about this, and they clarified the current situation.
While they maintain their own repo with Ubuntu packages, they don't have
resources to allocate for working on packaging it for Debian.

So I'm not sure what's the right way forward for this. Does this need
another maintainer or Debian developer to be packaged?

Shmerl.

Bug#1005793: libadwaita-1: reproducible builds: Embedded date in .xml file

[Vagrant Cascadian]

Source: libadwaita-1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The file /usr/share/metainfo/org.gnome.Adwaita1.Demo.metainfo.xml
contains an embedded build date:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libadwaita-1.html

  
  vs.
  

The attached patch fixes this by removing the call to date from the
meson.build file.


An alternate option would be to use the SOURCE_DATE_EPOCH environment
variable, and there is a meson example available:

  https://reproducible-builds.org/docs/source-date-epoch/

This would be better if the package somehow fails to work correctly when
there is no date in this file, though ideally no timestamp would be
better if possible.


With this patch applied, libadwaita-1 should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining libadwaita-1!


live well,
  vagrant
From c0be5862ff331f874e674a041209451f91329ed6 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 15 Feb 2022 01:06:49 +
Subject: [PATCH] demo/data/meson.build: Remove build date.

The build date does not appear to be required, and makes the build
unreproducible when built on a different date.
---
 demo/data/meson.build | 8 
 1 file changed, 8 deletions(-)

diff --git a/demo/data/meson.build b/demo/data/meson.build
index 612410c5..55b4152c 100644
--- a/demo/data/meson.build
+++ b/demo/data/meson.build
@@ -15,14 +15,6 @@ if desktop_utils.found()
 endif
 
 today = 'unknown'
-date = find_program('date',
- required: false)
-if date.found()
-  r = run_command(date, '-I')
-  if r.returncode() == 0
-today = r.stdout().strip()
-  endif
-endif
 
 appdata_config = configuration_data()
 appdata_config.set('BUILD_VERSION', meson.project_version())
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1005792: btop: reproducible-builds: Build path embedded in /usr/bin/btop

[Vagrant Cascadian]

Source: btop
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Different build paths trigger reproducibility issues with binaries such
as /usr/bin/btop and relevent debugging symbols.

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/btop.html

  /build/1st/btop-1.1.3/include/robin_hood.h:2296
  vs.
  /build/2/btop-1.1.3/2nd/include/robin_hood.h:2296

The attached patch fixes this by passing -ffile-prefix-map via the
ADDFLAGS variable (documented in btop/README.md) to avoid embedding the
build path into the binaries.

Another option might be to pass CXXFLAGS via ADDFLAGS with the default
values that debhelper/dpkg-buildflags get.


With this patch applied, btop should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining btop!


live well,
  vagrant
From 3263f2b38bc106bdd7da289be6296e625f50ab4f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 15 Feb 2022 00:52:34 +
Subject: [PATCH] debian/rules: Remove embedded build paths by passing
 -ffile-prefix-map via ADDFLAGS variable.

https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index b80fa90..c9ca95a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,6 +3,7 @@
 #export DH_VERBOSE = 1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
+export ADDFLAGS = -ffile-prefix-map=$(CURDIR)=.
 
 %:
 	dh $@
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1005791: diagnosticator package

[Diagnosticator Gmail]

Please find attached

Enrico Cocchi


diagnosticator_0.1.0-1_all.deb
Description: application/vnd.debian.binary-package

Bug#1005791: ITP: diagnosticator -- Python3 web-based application for genetic variants clinical annotation

[Enrico Cocchi]

Package: wnpp
Severity: wishlist
Owner: Enrico Cocchi 

* Package name: diagnosticator
  Version : 0.1.0
  Upstream Author : Enrico Cocchi 
* URL : https://diagnosticator.com
* License : MIT
  Programming Lang: Python, bash, c++
  Description : Python3 web-based application for genetic variants clinical 
annotation

This is a web-based app mainly developed in Python and served through Flask 
that allows variants clinical annotation (as per American College of Medical 
Genetics guidelines: https://pubmed.ncbi.nlm.nih.gov/25741868/) automated 
review starting from VEP-annotated VCF files. 
It proved to save an incredible amount of time to genetic researcher users (I 
already deployed and mantaining on Columbia University servers where it is used 
by internal researchers and genetic counselors). 
This is also completely free and open-source, as no other similar tool at the 
moment.
This is a community-based application which aim is to share among all users 
annotation, variants interpretations etc. in order to boost data and knowledge 
sharing in clinical genetics.
It is designed as a parent-child application and no sensitive information is 
shared over internet or similar.

I will maintain this with the Bioinformatics team at Gharavi Lab. (Columbia 
University, http://columbiamedicine.org/divisions/gharavi) as we are already 
doing for internal Columbia users.
I would love to have co-maintainers and a sponsor

Bug#1005790: ITP: simple-whip-client -- simple GStreamer-based WHIP client

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian VoIP Team 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: simple-whip-client
  Version : 0.0~git2021
  Upstream Author : Lorenzo Miniero 
* URL : https://github.com/meetecho/simple-whip-client
* License : BSD-2-Clause and GPL-3
  Programming Lang: C
  Description : simple GStreamer-based WHIP client

 simple-whip-client is a WHIP client implementation,
 using GStreamer.
 .
 WebRTC-HTTP ingestion protocol (WHIP)
 is a simple HTTP based protocol
 that will allow WebRTC based ingest of content
 into streaming servics and/or CDNs.
 .
 GStreamer is a pipeline-based multimedia framework
 that links together a wide variety of media processing systems
 to complete complex workflows.

This package will be maintained in the VoIP team at

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmIK6ZwACgkQLHwxRsGg
ASFIgQ/+NYE63NitDbpzZkeGVUSZrtke/IBf2hik3TvK5icCLhWkTRGkdE4xXACP
6PuTj/obFRgLN8g9JJ3usgaITIdvBig4oGP0kigUCBc36jcedwtOKgTMWsAyrai4
R1wLyWZJKY0pdbSJFL2Mp3dzVV2vgTc0a3qb9CU961WZ9exKDg7WAa5jk5NTeUIR
BjtmT17smd90NkYyhJfbIgFd1DwpnU47oBYHeM9JOZgIRJlHiXhrgLaN6/8msqx1
D/Ard4ebp4mf66/k/0hb4RD/ZmRc8uA64q/vkzQLpdaEUhgL+kR17dCEfM+xPjr1
3K07aHoqVy4lTPfSNyiRsbIAtm2oG1P31MOzQNYw15HH1AtRMmne6we/pkGkm8SA
RSKcTUumpE4yXSFKVzNoz9WTuVCPJviT/NeUzGcIS5xnQC0z4yUd6xsfeDKI7aaE
/T0WFEfht+Eimd/npCii82oLavWIsVJvHIlF48rbgalOrF21NRFiwymwYO7d/KXq
Xp18lxxCpjIduxfN4sXMIL2R4wtnydl2crgIe5KP9bc3aspc0FBSxdeyc5XKEcsO
+2c1vGWH8ypmuyyNunJUPB4hRftmeodHtOF0YV57ymcgS0GESuAQ3T5wUWZ74fCm
BT0X9iNkfsENqxAAK/5Lox3wr6Cvdz4m0s1o5RzeqP/gHYpBQFw=
=Gagi
-END PGP SIGNATURE-

Bug#1005197: pcmemtest: please make the build partly reproducible

[Vagrant Cascadian]

On 2022-02-12, Felix Zielcke wrote:
> Am Freitag, dem 11.02.2022 um 22:46 +0100 schrieb Thomas Schmitt:
>> Chris Lamb wrote:
>> > Did you try the --invariant flag?
>> 
>> Well, i step aside and let this question reach Felix. :))
>> 
>>   https://manpages.debian.org/unstable/dosfstools/mkdosfs.8.en.html
>> says that this is what we need if my theory about the second
>> difference
>> is correct:
>> 
>>   --invariant
>>     Use constants for normally randomly generated or time based data
>>     such as volume ID and creation time. Multiple runs of mkfs.fat on
>>     the same device create identical results with this option.
>> 
>> 
>> So the options to be added to the mkdosfs runs in the hope for a
>> fully
>> reproducible ISO are:
>> 
>>   -i 12345678 --invariant
>> 
>> If a more more individual -i number is desired, one could use
>> something
>> like
>> 
>>   -i $(printf '%8.8x' "$SOURCE_DATE_EPOCH" | head -c 8)
>> 
>> 
>
> Wow. Thanks very much to you both.
> This is the solution. I would never come up that fast with it.

I noticed 1.5-3 is still affected by timezone differences, but is very
nearly there!

Figured out using:

  reprotest --auto-build --store-dir=$(mktemp -d ${HOME}/rb-test-XX) 
--min-cpus=1 --vary=-user_group,-domain_host,-fileordering auto -- null

Which does a build for each different tested variation. Some variations
are trickier to set up with the null backend, so I just disable
them. The store-dir argument allows you to see all the various
diffoscope outputs and build artifacts.

If I come up with an updated patch, I'll maybe submit a new bug...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1005789: libpmix2: unable to open mca_pmix_ext3x: cannot open shared object file: No such file or directory

[Drew Parsons]

Package: libpmix2
Version: 4.1.2-1
Severity: serious

Looks like something is missing in the new pmix package.

mpi4py tests show the problem, referring to a missing mca_pmix_ext3x


autopkgtest [03:24:44]: test command1: OMPI_MCA_rmaps_base_oversubscribe=yes 
mpiexec -n 5 python3 test/runtests.py --verbose
autopkgtest [03:24:44]: test command1: [---
[ci-045-e09157ad:02675] mca_base_component_repository_open: unable to open 
mca_pmix_ext3x: libpmix.so.2: cannot open shared object file: No such file or 
directory (ignored)
[ci-045-e09157ad:02675] [[58836,0],0] ORTE_ERROR_LOG: Not found in file 
../../../../../../orte/mca/ess/hnp/ess_hnp_module.c at line 320
--
It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):

  opal_pmix_base_select failed
  --> Returned value Not found (-13) instead of ORTE_SUCCESS




https://ci.debian.net/data/autopkgtest/testing/amd64/m/mpi4py/19194504/log.gz





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

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

Versions of packages libpmix2 depends on:
ii  libc62.33-5
ii  libcurl3-gnutls  7.81.0-1
ii  libevent-core-2.1-7  2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libhwloc-plugins 2.7.0-2
ii  libhwloc15   2.7.0-2
ii  zlib1g   1:1.2.11.dfsg-2

libpmix2 recommends no packages.

libpmix2 suggests no packages.

-- no debconf information

Bug#894126: help2man: Problem with encoding kk_KZ.RK1048

[Brendan O'Dea]

On Wed, Jan 05, 2022 at 02:54:48PM +0100, Marcus Hardt wrote:
>I'm experiencing the same problem every now and then, because reprotest
>uses this encoding to verify reproducible builds.
>
>The problem seems to be triggered by setting this environment:
>
>LANG=kk_KZ.RK1048
>LANGUAGE=kk_KZ.RK1048:fr

As noted earlier in this bug, the only error reports that I've had about
this issue are from reprotests, and not actual users wanting to use
RK1048 as their language encoding for kk_KZ.

I've prepared a change which should fix this problem, by falling back to
calling iconv from libc-bin to handle unrecognised encodings.

Hopefully this should resolve the issue for reprotests, although I've
tried to make it sufficiently general that it might actually be useful
for someone with an unusual, unsupported encoding.

--bod

Bug#1005788: mupdf: Incomplete rendering "jbig2dec error: incompatible jbig2dec header (0.19) and library (0.16)"

[GSR]

Package: mupdf
Version: 1.19.0+ds1-1
Severity: normal

Hi:

There seems to be a small problem with lib dependencies because
https://tomlehrersongs.com/wp-content/uploads/2018/11/so-long-mom.pdf
renders nothing. xpdf rendered it fine. Exact message is:

---8<---
warning: ICC support is not available
warning: jbig2dec error: incompatible jbig2dec header (0.19) and library (0.16) 
versions (segment 4294967295)
error: cannot allocate jbig2 context
warning: Ignoring error during interpretation
mupdf: warning: Errors found on page. Page rendering may be incomplete.
--->8---

Manually upgrading libjbig2dec0 to 0.19-3 got the text to render (must
be a scanned page), just the warning about ICC support left.

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

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

Versions of packages mupdf depends on:
ii  freeglut32.8.1-3
ii  libc62.33-5
ii  libfreetype6 2.10.4+dfsg-1
ii  libgl1   1.4.0-1
ii  libgumbo10.10.1+dfsg-2.4
ii  libharfbuzz0b2.1.1-1
ii  libjbig2dec0 0.16+20190905-3
ii  libjpeg62-turbo  1:2.1.2-1
ii  libmujs1 1.0.7-1
ii  libopenjp2-7 2.4.0-3
ii  libssl1.11.1.1m-1
ii  libx11-6 2:1.7.2-2+b1
ii  libxext6 2:1.3.4-1
ii  zlib1g   1:1.2.11.dfsg-2

mupdf recommends no packages.

Versions of packages mupdf suggests:
ii  mupdf-tools  1.19.0+ds1-1

-- no debconf information

Bug#1005744: u-boot-rpi: Please enable CONFIG_BOOTCOUNT_LIMIT=y

[Vagrant Cascadian]

On 2022-02-14, Pascal Dupuis wrote:
>* I'm searching a solution to implement a fallback kernel mechanism
>  in case of boot failure. 'u-boot' has this ability, but it must be
>  enabled. See some example at
>  
> https://github.com/balena-os/balena-raspberrypi/blob/master/layers/meta-balena-raspberrypi/recipes-bsp/u-boot/u-boot/configs-Add-bootcount-configs-to-rpi-defconfigs.patch
>* From the debian sources, it appears this option is not selected. It
>  would be great to at least test if enabling it permits to
>  effectively work around boot failures.

It would be ideal to get this addressed in upstream u-boot:

  https://www.denx.de/wiki/U-Boot

... unless there is some particular reason this would only make sense in
the context of Debian? Not sure what that would be.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1005787: redis: CVE-2022-0543

[Chris Lamb]

Package: redis
Version: 5:5.0.14-1+deb10u1
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

A vulnerability was published for redis as CVE-2022-0543[0]. This is
the placeholder Debian bug which will be renamed and fleshed out later
with more details once it has become unembargoed.

[0] https://security-tracker.debian.org/tracker/CVE-2022-0543
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0543


Regards,

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

Bug#849440: udd: Please use HTTP 503 for "Current system load is too high"

[Fioddor Superconcentrado]

Looks like 3 ruby cgi's need this fix/improvement:

udd$ grep -r "is too high" .
./web/bugs.cgi:puts "Current system load (#{load}) is too high.
Please retry later!"
./web/cgi-bin/nobugs.cgi:  puts "Current system load (#{load}) is too
high. Please retry later!"
./web/dmd.cgi:  puts "Current system load (#{load}) is too high.
Please retry later!"

Bug#1005784: policykit-1: CVE-2021-4115: file descriptor leak allows an unprivileged user to cause a crash

[Simon McVittie]

On Mon, 14 Feb 2022 at 22:29:29 +0100, Salvatore Bonaccorso wrote:
> Simon, Michael opinions on the DSA need? *If* it's automatically
> restarted after crash, then we can schedule the fixes via the upcoming
> point releases IMHO.

I can't say much about the impact of a vulnerability that doesn't have
a patch or any details available, but if it's literally just running
out of fd space and crashing, that's pretty weak even as an attack
on availability.

polkitd is D-Bus-activated on-demand, so a crash should just inconvenience
people who are actively trying to authenticate at that moment: the next
time a client tries to contact polkit, systemd (if used) or dbus-daemon
(if using other init systems) will relaunch polkitd automatically before
delivering the message.

smcv

Bug#1005786: gnome-weather: Display summary for current day on daily tab

[Vagrant Cascadian]

Package: gnome-weather
Version: 41.0-1
Severity: wishlist
X-Debbugs-Cc: Vagrant Cascadian 

The tab for the daily summary of weather does not display the current
day.

There is information available in the daily summary (wind speed,
humidity) that is not available in the hourly tab.

It also would be nice to be able to compare today to future days in the
week without having to switch between the two tabs.

Thanks for maintaining gnome-weather!


live well,
  vagrant

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

Kernel: Linux 5.16.0-1-arm64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-weather depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  geoclue-2.0  2.5.7-3
ii  gir1.2-geoclue-2.0   2.5.7-3
ii  gir1.2-glib-2.0  1.70.0-3
ii  gir1.2-gnomedesktop-3.0  41.3-1
ii  gir1.2-gtk-3.0   3.24.31-1
ii  gir1.2-gweather-3.0  40.0-5
ii  gir1.2-handy-1   1.5.90-1
ii  gjs  1.70.1-1
ii  libglib2.0-bin   2.70.3-1

gnome-weather recommends no packages.

gnome-weather suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1005785: gnome-weather: wind speed reporting stuck in MPH

[Vagrant Cascadian]

Package: gnome-weather
Version: 41.0-1
Severity: normal
X-Debbugs-Cc: Vagrant Cascadian 

Thanks for maintaining gnome-weather, I use it regularly!


I did notice a recent problem after switching units from from Celsius to
Fahrenheit units, and then switching back to Celsius.

The temperature reporting consistantly changes units, but the wind speed
reporting in the daily tab now only displays in mph, regardless of
setting gnome-weather to use Celsius or Fahrenheit. It definitely used
to display wind speed in kph (or kmph?) before having switched to
Fahrenheit.

It seems like the configuration should be Metric or Imperial rather than
Celcius and Fahrenheit, but at the very least, when you switch between
whatever unit the interface allows, it should at least consistently use
the same system of units for all of the reporting...


live well,
  vagrant


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

Kernel: Linux 5.16.0-1-arm64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-weather depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  geoclue-2.0  2.5.7-3
ii  gir1.2-geoclue-2.0   2.5.7-3
ii  gir1.2-glib-2.0  1.70.0-3
ii  gir1.2-gnomedesktop-3.0  41.3-1
ii  gir1.2-gtk-3.0   3.24.31-1
ii  gir1.2-gweather-3.0  40.0-5
ii  gir1.2-handy-1   1.5.90-1
ii  gjs  1.70.1-1
ii  libglib2.0-bin   2.70.3-1

gnome-weather recommends no packages.

gnome-weather suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

[Alex Deucher]

On Sat, Feb 12, 2022 at 1:23 PM Salvatore Bonaccorso  wrote:
>
> Hi Alex, hi all
>
> In Debian we got a regression report from Dominique Dumont, CC'ed in
> https://bugs.debian.org/1005005 that afer an update to 5.15.15 based
> kernel, his machine noe longer suspends correctly, after screen going
> black as usual it comes back. The Debian bug above contians a trace.
>
> Dominique confirmed that this issue persisted after updating to 5.16.7
> furthermore he bisected the issue and found
>
> 3c196f0510912645c7c5d9107706003f67c3 is the first bad commit
> commit 3c196f0510912645c7c5d9107706003f67c3
> Author: Alex Deucher 
> Date:   Fri Nov 12 11:25:30 2021 -0500
>
> drm/amdgpu: always reset the asic in suspend (v2)
>
> [ Upstream commit daf8de0874ab5b74b38a38726fdd3d07ef98a7ee ]
>
> If the platform suspend happens to fail and the power rail
> is not turned off, the GPU will be in an unknown state on
> resume, so reset the asic so that it will be in a known
> good state on resume even if the platform suspend failed.
>
> v2: handle s0ix
>
> Acked-by: Luben Tuikov 
> Acked-by: Evan Quan 
> Signed-off-by: Alex Deucher 
> Signed-off-by: Sasha Levin 
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> to be the first bad commit, see https://bugs.debian.org/1005005#34 .
>
> Does this ring any bell? Any idea on the problem?

Does the system actually suspend?  Putting the GPU into reset on
suspend shouldn't cause any problems since the power rail will
presumably be cut by the platform.  Is this system S0i3 or regular S3?
 Does this patch help by any chance?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e55a3aea418269266d84f426b3bd70794d3389c8

Alex


>
> Regards,
> Salvatore

Bug#1005784: policykit-1: CVE-2021-4115: file descriptor leak allows an unprivileged user to cause a crash

[Salvatore Bonaccorso]

Source: policykit-1
Version: 0.105-31.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.105-31
Control: found -1 0.105-31+deb11u1
Control: found -1 0.105-25
Control: found -1 0.105-25+deb10u1

Hi,

The following vulnerability was published for policykit-1.

CVE-2021-4115[0]:
| file descriptor leak allows an unprivileged user to cause a crash

See [1]. Upstream has not yet pushed the commit into the repository,

Simon, Michael opinions on the DSA need? *If* it's automatically
restarted after crash, then we can schedule the fixes via the upcoming
point releases IMHO.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-4115
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4115
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2007534

Regards,
Salvatore

Bug#1005060: transition: ace

[Sudip Mukherjee]

On Sun, Feb 13, 2022 at 7:41 PM Sebastian Ramacher  wrote:
>
> Control: tags -1 confirmed
>
> On 2022-02-13 18:52:08 +, Sudip Mukherjee wrote:
> > Hi,
> >
> > Just to add here, diagnostics FTBFS has been fixed and I have verified
> > that it builds fine with ace 7.0.6+dfsg-1 version in experimental.
>
> Please go ahead

Thanks. And uploaded to unstable now.



-- 
Regards
Sudip

Bug#996973: msc-generator_7.1-1_amd64.changes REJECTED, feedback

[Geert Stappers]

On Mon, Feb 14, 2022 at 02:10:07AM -0800, NG wrote:
> On 2022-02-13 12:00, Thorsten Alteholz wrote:
> > please also mention at least
> >  The Khronos Group Inc.
> >  Sean Barrett
> >  Tristan Grimmer
> >  Stephane Cuillerdier (aka aiekick)
> > in your debian/copyright.
> 
> Done, I have included these and created a new upload at mentors. @Geert
> can you please check and forward it in Thorsten's way?

Done.

In case that upload also needs additional care,
please tell how we, Maintainer & Uploader, could/should check.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1005783: xorg-server: "no screens found" when run under: kvm -vga virtio

[Philip Hands]

Source: xorg-server
Version: 2:21.1.3-2
Severity: normal

Dear Maintainer,

[I'm reporting this against the source because I'm not sure which binary is at
fault, but this presuambly related to the bits of xorg that gets put into a udeb
and it has been seen while testing on amd64.]

Daily Debian-Installer images made after Feb 9 are failing to start X, as seen 
here:

  https://openqa.debian.net/tests/42033#step/_boot_to_debianinstaller/4

which conicides with 2:21.1.3-2 hitting unstable, which suggests that is what is
responsible for the change.

Here is that same test, using the version of D-I built at 2022-02-09 22:16:

  https://openqa.debian.net/tests/41989#step/_boot_to_debianinstaller/3

which, as you can see, gets to run X.

If I set things such that it uses `-vga std` instead of `-vga virtio`, and do a
BIOS boot, it is again able to start X:

  https://openqa.debian.net/tests/42370#step/_boot_to_debianinstaller/3

However, a UEFI boot still fails (with `-vga std`):

  https://openqa.debian.net/tests/42416#step/_boot_to_debianinstaller/4

BTW One can reproduce this behaviour by running kvm thus:

  kvm -cdrom debian-testing-amd64-netinst.iso -m 1G
  (which works, because it's defaulting to: -vga std )

and:

  kvm -cdrom debian-testing-amd64-netinst.iso -m 1G -vga virtio
  (which fails for recent versions, and works for versions produced up until 
Feb 9)

If you need an earlier copy of a daily image, for comparision purposes, I have
copies at present, and can put them somewhere you can get them.

Cheers, Phil.

Bug#1005782: RFS: budgie-control-center/0.4-1 [ITP] -- utilities to configure the Budgie desktop

[David Mohammed]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "budgie-control-center":

 * Package name: budgie-control-center
   Version : 0.4-1
   Upstream Author : Budgie Desktop Developers 
 * URL : https://github.com/buddiesofbudgie/budgie-control-center
 * License : GPL-3+, GPL-2+ and LGPL-2.1+ and LGPL-2+ and Expat
 * Vcs : https://github.com/ubuntubudgie/budgie-control-center
   Section : misc

It builds those binary packages:

  budgie-control-center - utilities to configure the Budgie desktop
  budgie-control-center-dev - Development package for Budgie Settings
  budgie-control-center-data - configuration applets for Budgie - data files

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

  https://mentors.debian.net/package/budgie-control-center/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-control-center/budgie-control-center_0.4-1.dsc

Background:
I am the DM for the budgie desktop and related packages  in Debian and
part of the upstream development team.

As part of the next version of budgie-desktop we have replaced our
dependency of gnome-control-center with our own budgie-control-center.

This package is focused on budgie whereas the current
gnome-control-center is focussed on gnome-shell.

This package is a fork of gnome-control-center at v41.  The Debian
package itself is derived from Debian's gnome-control-center.

The copyright file & its authors has been derived from the current
gnome-control-center package with the addition of our own authorship
plus the changes described next.

This package was previously sponsored but was rejected by ftp-master
with the request to add
the GPL-3+ files to debian/copyright.  This has now been done.

I've also taken the opportunity to spot check some of the existing
GPL2+ authors and update the date ranges as appropriate.

In addition have taken the opportunity to resolve some of the information and
pedantic issues found in the current gnome-control-center package.

In terms  of testing we have ensured that budgie-control-center can
coexist with gnome-control-center i.e. this allows users to use both
gnome-shell and budgie-desktop on the same installed machine.

I have tested this package on the current debian testing image +
debian unstable repos.
By installing the two built packages,  budgie-desktop (which is a
necessary dependency) with budgie-control-center was installed.
Budgie Control Center was confirmed to be working as expected.

I would like to continue providing the best experience of
budgie-desktop for Debian and this package is part of this continued
commitment.  Please can you consider sponsoring this package -
obviously in the future I would like to ensure that I can continue
providing timely uploads through supplementing my current DM package
rights with this new package.

Changes for the initial release:

 budgie-control-center (0.4-1) unstable; urgency=medium
 .
   * Initial Release (Closes: #1003845)


Regards,
-- 
  David Mohammed

Bug#1005780: libgusb: Please package 0.3.10

[Jeremy Bicha]

Source: libgusb
Version: 0.3.8-1
Severity: wishlist

Please package libgusb 0.3.10. I'm told it fixes a regression in 0.3.8
seen with libfprint.

https://github.com/hughsie/libgusb/blob/main/NEWS

Thank you,
Jeremy Bicha

Bug#893058: ITP: libdecaf -- implementation of Montgomery and Edwards elliptic curve cryptography

[Christopher Hoskin]

Dear Bernhard,

Sorry for the delay in replying. I'm afraid I haven't found any time
to work on this package recently, so if someone else would like to
take it over then that would be fine with me.

Thanks.

Christopher

Bug#1005311: forcing dependency is not enough, at least for optirun

[Gianluigi Tiesi]

optirun glxinfo

optirun glxinfo
[ 1566.529702] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Unable to locate/open config directory: 
"/etc/bumblebee/xorg.conf.d"


[ 1566.529735] [ERROR]Aborting because fallback start is disabled.


in xorg log:

[  1566.527] (II) NVIDIA dlloader X Driver  470.103.01  Thu Jan  6 12:18:33 UTC 
2022
[  1566.527] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[  1566.529] (EE) No devices detected.
[  1566.529] (EE)
Fatal server error:
[  1566.529] (EE) no screens found(EE)
[  1566.529] (EE)

perhaps nvidia module loads:

[ 1566.540788] nvidia :01:00.0: enabling device ( -> 0003)
[ 1566.540886] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=none
[ 1566.587576] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  470.103.01  Thu 
Jan  6 12:10:04 UTC 2022


--
Gianluigi Tiesi 
Chief Technology Officer
Netfarm S.r.l. - https://www.netfarm.it/
Free Software: https://oss.netfarm.it/

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

Bug#1005779: djangorestframework: autopkgtest needs update for new version of pygments

[Paul Gevers]

Source: djangorestframework
Version: 3.12.4-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, pygme...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pygments

Dear maintainer(s),

With a (not so) recent upload of pygments the autopkgtest of 
djangorestframework fails in testing when that autopkgtest is run with 
the binary packages of pygments from unstable. It passes when run with 
only packages from testing. In tabular form:


   passfail
pygments   from testing2.10.0+dfsg-1
djangorestframeworkfrom testing3.12.4-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of pygments to 
testing [1]. Of course, pygments shouldn't just break your autopkgtest 
(or even worse, your package), but it seems to me that the change in 
pygments was intended and your package needs to update to the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from pygments should really 
add a versioned Breaks on the unfixed version of (one of your) 
package(s). Note: the Breaks is nice even if the issue is only in the 
autopkgtest as it helps the migration software to figure out the right 
versions to combine in the tests.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=pygments

https://ci.debian.net/data/autopkgtest/testing/amd64/d/djangorestframework/19192844/log.gz

=== FAILURES 
===
__ TestViewNamesAndDescriptions.test_markdown 
__


self = testMethod=test_markdown>


@pytest.mark.skipif(not apply_markdown, reason="Markdown is not 
installed")

def test_markdown(self):
"""
Ensure markdown to HTML works as expected.
"""
# Markdown 3.3 is only supported on Python 3.6 and higher
if sys.version_info >= (3, 6):

  assert apply_markdown(DESCRIPTION) == MARKDOWN_BASE % MARKDOWN_gte_33
E   AssertionError: assert ''
E Skipping 445 identical leading characters in diff, use -v 
to show
E - an class="nt">beta: class="err">this is class="err">a stringclass="p">}]
E + an class="s2">beta: class="kc">this class="err">is a class="err">strclass="err">inclass="err">gE E ...Full output truncated (2 lines hidden), 
use '-vv' to show


tests/test_description.py:170: AssertionError


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005778: src:pypandoc: fails to migrate to testing for too long: autopkgtest failure

[Paul Gevers]

Source: pypandoc
Version: 1.6.4+ds0-1
Severity: serious
Control: close -1 1.7.2+ds0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

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:pypandoc has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. You added an autopkgtest to your 
package, great. However, it fails on the Debian infrastructure on all 
architectures where it's run.


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=pypandoc



OpenPGP_signature
Description: OpenPGP digital signature

Bug#856870: me too

[Joey Hess]

Version: 1.5.2-2.1

I'm now seeing this bug. Oddly, I did not see the bug back in 2020,
when I was successfully using arduino-mk. But now:

make do_upload
make[1]: Entering directory '/home/joey/src/arduino-copilot/Examples/Blink'
/usr/share/arduino/hardware/tools/avr/bin/avrdude -q -V -p atmega328p -C 
/usr/share/arduino/hardware/tools/avr/etc/avrdude.conf -D -c arduino -b 115200 
-P /dev/ttyUSB0 \
-U flash:w:build-uno/Blink_.hex:i
avrdude: can't open config file 
"/usr/share/arduino/hardware/tools/avr/etc/avrdude.conf": No such file or 
directory
avrdude: error reading system wide configuration file 
"/usr/share/arduino/hardware/tools/avr/etc/avrdude.conf"
make[1]: *** [/usr/share/arduino/Arduino.mk:1462: do_upload] Error 1
make[1]: Leaving directory '/home/joey/src/arduino-copilot/Examples/Blink'
make: *** [/usr/share/arduino/Arduino.mk:1455: upload] Error 2

I think it was probably fixed in the interim and then broken again,
since the path is different than in the original bug report.

My workaround:

root@darkstar:/usr/share/arduino/hardware/tools/avr>mkdir etc
root@darkstar:/usr/share/arduino/hardware/tools/avr>cd etc
root@darkstar:/usr/share/arduino/hardware/tools/avr/etc>ln -s /etc/avrdude.conf 

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Nicolas Boulenguez]

Package: dpkg-dev
Followup-For: Bug #872381

Of course,
-dpkg_datadir := $(shell $(dir $(lastword $(MAKEFILE_LIST
+dpkg_datadir := $(dir $(lastword $(MAKEFILE_LIST)))

Hello.
I have rebased the changes and taken your explanations into
account. This new patch queue is not tested again, but should be
easyer to review.
>From 5852b310ea8cdd519a0f7d6e1099c3c54db026ed Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Mon, 29 Jul 2019 14:38:32 +0200
Subject: [PATCH 01/10] scripts/mk: stop hard-coding dpkg_datadir

The Makefile snippets include each other from their common directory,
but the path differ during tests and after installation.  Instead of
rewriting the file with a hardcoded path, compute it within Make.
---
 build-aux/subst.am   |  6 --
 scripts/mk/Makefile.am   | 17 -
 scripts/mk/buildtools.mk |  3 +--
 scripts/mk/default.mk| 12 ++--
 4 files changed, 7 insertions(+), 31 deletions(-)

diff --git a/build-aux/subst.am b/build-aux/subst.am
index 74a40bf0b..4cd4bdca8 100644
--- a/build-aux/subst.am
+++ b/build-aux/subst.am
@@ -38,9 +38,3 @@ SUFFIXES += .pl
 	@test -d `dirname $@` || $(MKDIR_P) `dirname $@`
 	$(do_perl_subst) <$< >$@
 	$(AM_V_at) chmod +x $@
-
-# Makefile support.
-
-do_make_subst = $(AM_V_GEN) $(SED) \
-	-e "s:dpkg_datadir[[:space:]]*=[[:space:]]*[^[:space:]]*:dpkg_datadir = $(pkgdatadir):" \
-	# EOL
diff --git a/scripts/mk/Makefile.am b/scripts/mk/Makefile.am
index 62d8592d2..0c635bf00 100644
--- a/scripts/mk/Makefile.am
+++ b/scripts/mk/Makefile.am
@@ -9,20 +9,3 @@ dist_pkgdata_DATA = \
 	pkg-info.mk \
 	vendor.mk \
 	# EOL
-
-SUFFIXES =
-
-include $(top_srcdir)/build-aux/subst.am
-
-install-data-hook:
-	mv $(DESTDIR)$(pkgdatadir)/default.mk \
-	   $(DESTDIR)$(pkgdatadir)/default.mk.tmp
-	$(do_make_subst) <$(DESTDIR)$(pkgdatadir)/default.mk.tmp \
-	 >$(DESTDIR)$(pkgdatadir)/default.mk
-	rm -f $(DESTDIR)$(pkgdatadir)/default.mk.tmp
-
-	mv $(DESTDIR)$(pkgdatadir)/buildtools.mk \
-	   $(DESTDIR)$(pkgdatadir)/buildtools.mk.tmp
-	$(do_make_subst) <$(DESTDIR)$(pkgdatadir)/buildtools.mk.tmp \
-	 >$(DESTDIR)$(pkgdatadir)/buildtools.mk
-	rm -f $(DESTDIR)$(pkgdatadir)/buildtools.mk.tmp
diff --git a/scripts/mk/buildtools.mk b/scripts/mk/buildtools.mk
index b2ab2a2ac..5cd9151f1 100644
--- a/scripts/mk/buildtools.mk
+++ b/scripts/mk/buildtools.mk
@@ -26,8 +26,7 @@
 # The variables are not exported by default. This can be changed by
 # defining DPKG_EXPORT_BUILDTOOLS.
 
-dpkg_datadir = $(srcdir)/mk
-include $(dpkg_datadir)/architecture.mk
+include $(dir $(lastword $(MAKEFILE_LIST)))architecture.mk
 
 # We set the TOOL_FOR_BUILD variables to the specified value, and the TOOL
 # variables (for the host) to the their triplet-prefixed form iff they are
diff --git a/scripts/mk/default.mk b/scripts/mk/default.mk
index 3916a0c24..afe5d6876 100644
--- a/scripts/mk/default.mk
+++ b/scripts/mk/default.mk
@@ -1,9 +1,9 @@
 # This Makefile fragment (since dpkg 1.16.1) includes all the Makefile
 # fragments that define variables that can be useful within debian/rules.
 
-dpkg_datadir = $(srcdir)/mk
-include $(dpkg_datadir)/architecture.mk
-include $(dpkg_datadir)/buildflags.mk
-include $(dpkg_datadir)/buildopts.mk
-include $(dpkg_datadir)/pkg-info.mk
-include $(dpkg_datadir)/vendor.mk
+dpkg_datadir := $(dir $(lastword $(MAKEFILE_LIST)))
+include $(dpkg_datadir)architecture.mk
+include $(dpkg_datadir)buildflags.mk
+include $(dpkg_datadir)buildopts.mk
+include $(dpkg_datadir)pkg-info.mk
+include $(dpkg_datadir)vendor.mk
-- 
2.30.2

>From 94c84d34ff28d81f2fceef797fa8314d7b03fb23 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 11 Feb 2021 15:36:15 +0100
Subject: [PATCH 02/10] scripts/t: test SOURCE_DATE_EPOCH

Set SOURCE_DATE_EPOCH either from the environment or the Debian changelog.
Check that the value is (re)exported.
---
 scripts/t/mk.t   | 9 -
 scripts/t/mk/pkg-info.mk | 2 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/scripts/t/mk.t b/scripts/t/mk.t
index 10e030a16..25e25d56c 100644
--- a/scripts/t/mk.t
+++ b/scripts/t/mk.t
@@ -16,7 +16,7 @@
 use strict;
 use warnings;
 
-use Test::More tests => 10;
+use Test::More tests => 11;
 use Test::Dpkg qw(:paths);
 
 use File::Spec::Functions qw(rel2abs);
@@ -131,6 +131,13 @@ foreach my $tool (keys %buildtools) {
 delete $ENV{"${tool}_FOR_BUILD"};
 }
 
+delete $ENV{SOURCE_DATE_EPOCH};
+$ENV{TEST_SOURCE_DATE_EPOCH} = `date +%s -d "Tue, 04 Aug 2015 16:13:50 +0200"`;
+chomp $ENV{TEST_SOURCE_DATE_EPOCH};
+test_makefile('pkg-info.mk');
+
+$ENV{SOURCE_DATE_EPOCH} = 100;
+$ENV{TEST_SOURCE_DATE_EPOCH} = 100;
 test_makefile('pkg-info.mk');
 
 test_makefile('vendor.mk');
diff --git a/scripts/t/mk/pkg-info.mk b/scripts/t/mk/pkg-info.mk
index 22a2bf44f..c0e3287b5 100644
--- a/scripts/t/mk/pkg-info.mk
+++ b/scripts/t/mk/pkg-info.mk
@@ -7,3 +7,5 @@ test:
 	test "$(DEB_VERSION_UPSTREAM_REVISION)" = "2:3.4-5-6"
 	test "$(DEB_VERSION_UPSTREAM)" = 

Bug#1005776: libpgf: Please package the updated 7.x series (and fix FTBFS)

[Boyuan Yang]

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

Dear Debian libpgf package maintainer,

Package libpgf currently FTBFS with gcc-11. Its upstream is active and is
constantly releasing new releases, which should solve the FTBFS issue. Since
the package in Debian hasn't receive any updates since 2014, it would be
important to package the new version.

If you no longer intend to maintain this package, please also consider taking
actions and orphan this package so that others can help with package
maintenance.

Thanks!
Boyuan Yang


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

Bug#1005775: ksmbd-tools: backport package for bullseye

[Solya Reka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: ksmbd-tools
Severity: wishlist

Dear Maintainer,

Linux kernel 5.15 is already available for bullseye backports, and is
also the default kernel for Raspberry Pi OS, which brings ksmbd kernel
module for bullseye users. Is there any chance someone might be
interested in providing a backport of ksmbd-tools to bullseye users as
well?

Best regards,
Reka
-BEGIN PGP SIGNATURE-
Version: BCPG C# v1.8.10.0

iQE4BAEBCAAiBQJiCqKtGxxTb2x5YSBSZWthIDxyZWthQGJ1dGEubW9lPgAKCRDX
S8NKJK0NOpTQB/0auYkLY4XG0oTnKZcntAtX2swnKppCS8UXQK+daXQ2R5TyC0vz
tR40npLEN9uLNBcQS+F3m+IUpem2Al+0z9s6chcMaXGiiwnAX9W8+6IxSC8Eums6
VXIxgaO0jhpujWOkL8SDtOOkv9pvHCPTi/CsXvr0E0aOoYOtxPcTdQk2/WlMzxsz
ZJsbFCVXsPobMXWf0gKlyUXhu6GFi+G0LJrtXAWEOecHKUkZjGHDLdyMSl680J6Q
8ENrUlcQW3S/7L1bd0NXsN9cmqDTcTvQLnItTzUf89MQhCzRlOiOoUpv/hHVWtcZ
g7wCXUT9HAEcD9Zh2B3mIKWwBPxS6ppon39N
=bKl3
-END PGP SIGNATURE-

Bug#1001740: bullseye-pu: package fcitx5-chinese-addons/5.0.4-1+deb11u1

[Boyuan Yang]

Hi, is there any updates for this pu?

On Tue, 14 Dec 2021 20:39:43 -0500 Boyuan Yang  wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: bullseye
> X-Debbugs-Cc: by...@debian.org
> Severity: normal
> 
> [ Reason ]
> Currently the table input methods provided by fcitx5-table (in src:fcitx5-
> chinese-addons) will not work due to missing dependencies on fcitx5-module-
> pinyinhelper and fcitx5-module-punctuation. This is reported as
> https://bugs.debian.org/1001739 . The bug is present from the very
beginning.
> While the latest fcitx5-chinese-addons/5.0.9-2 upload has fixed the bug in
> Debian Sid, This bullseye-pu will fix this bug in Debian 11 (stable).
> 
> [ Impact ]
> If this update is not present, users that only have fcitx5-table installed
> (i.e. did not explicitly install fcitx5-module-pinyinhelper and fcitx5-
module-
> punctuation) will not be able to use any table input method in fcitx5
> framework.
> 
> [ Tests ]
> I have tested the fix in a freshly-installed Debian 11 VM.
> 
> [ Risks ]
> No risk expected. This fix only adds two package dependencies.
> 
> [ Checklist ]
>   [X] *all* changes are documented in the d/changelog
>   [X] I reviewed all changes and I approve them
>   [X] attach debdiff against the package in stable
>   [X] the issue is verified as fixed in unstable
> 
> [ Changes ]
>   * debian/control: Add missing package dependency relationship:
> + fcitx5-table:
>   - fcitx5-module-pinyinhelper (Dep)
>   - fcitx5-module-punctuation (Dep) (Closes: #1001739)
> 
> Full debdiff provided in attachment.
> 
> [ Other info ]
> Changes in git packaging repo:
>
https://salsa.debian.org/input-method-team/fcitx5-chinese-addons/-/commit/1d489d123c26e37b63fe24fe6748856a5f72103d
> 
> -- 
> Regards,
> Boyuan Yang


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

Bug#1005774: kamailio-python3-modules: Needlessly depends on python3-dev

[Matthias Urlichs]

Package: kamailio-python3-modules
Version: 5.5.3-2
Severity: normal
X-Debbugs-Cc: sm...@smurf.noris.de

I can't see why this module depends on python3-dev. This pulls in a whole
lot of other -dev dependencies. None of those are of any use on a SIP
border gateway.

-- 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-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
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 kamailio-python3-modules depends on:
pn  kamailio  
ii  libc6 2.33-5
pn  libpython3.7  
ii  libpython3.9  3.9.9-2.1
ii  python3-dev   3.9.2-3

kamailio-python3-modules recommends no packages.

kamailio-python3-modules suggests no packages.

Bug#1005622: [Pkg-utopia-maintainers] Bug#1005622: libblockdev: FTBFS: dpkg-gensymbols: error: some new symbols appeared in the symbols file: see diff output below

[Michael Biebl]

Am 14.02.22 um 18:51 schrieb Michael Biebl:


I agree.
Apparently this isn't the first time that dmraid has been bitten by this 
split-usr issue (and having to manually fiddle with the creation of the 
.so symlink) [1]


Getting rid of this unnecessary complexity would solve this once and for 
all.


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



While speaking of getting rid off unnecessary complexity: Is the 
separate udeb build still needed?
Apparently dmraid doesn't link against libselinux anymore (and even if 
it did, we do have a libselinux udeb nowadays)


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005622: [Pkg-utopia-maintainers] Bug#1005622: libblockdev: FTBFS: dpkg-gensymbols: error: some new symbols appeared in the symbols file: see diff output below

[Michael Biebl]

Am 14.02.22 um 17:55 schrieb Helmut Grohne:

We have this moratorium in place that says you should not move files
from / to /usr, because it could go bad when moving files.


ttbomk, those "bad" things only happen if you move files from /lib to 
/usr (under the same name) but *also* move it between different binary 
packages, which isn't the case here.



 However, in

this case, we are moving files from non-triplet to triplet and thus we
can safely move from / to /usr without the aforementioned risk. So we
may want to go the extra mile here and use the multiarch-conversion to
move all files to /usr in a safe way for stable upgrades and get rid of
a pile of complexity that way.


I agree.
Apparently this isn't the first time that dmraid has been bitten by this 
split-usr issue (and having to manually fiddle with the creation of the 
.so symlink) [1]


Getting rid of this unnecessary complexity would solve this once and for 
all.


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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005622: [Pkg-utopia-maintainers] Bug#1005622: libblockdev: FTBFS: dpkg-gensymbols: error: some new symbols appeared in the symbols file: see diff output below

[Helmut Grohne]

Control: tags -1 + patch

Hi Michael,

On Sun, Feb 13, 2022 at 02:20:26PM +0100, Michael Biebl wrote:
> I suspect the following:
> 
> in 1.0.0.rc16-10 /usr/lib/libdmraid.so is a dangling symlink to
> /lib/libdmraid.so.1.0.0.rc16 (yay for those pointless split-usr shenanigans,
> can we please have merged-usr like yesterday) and as a result the
> compiler/linker falls back to link
> /usr/lib/x86_64-linux-gnu/libdmraid.a
> statically into libblockdev-dm2

Thank you for the detailed analysis and for contacting me directly. I am
sorry for the inconvenience this bug has caused to you. I usually
double-check these links in a multiarch conversion, but it turns out
that both me and Laszlo missed this instance.

Before blindly applying this patch, let me propose something else:

We have this moratorium in place that says you should not move files
from / to /usr, because it could go bad when moving files. However, in
this case, we are moving files from non-triplet to triplet and thus we
can safely move from / to /usr without the aforementioned risk. So we
may want to go the extra mile here and use the multiarch-conversion to
move all files to /usr in a safe way for stable upgrades and get rid of
a pile of complexity that way.

That's up to Laszlo to decide. In the mean time, here is the patch that
fixes the issue reported by Lucas and diagnosed by Michael. Thank you
two.

Helmut
diff --minimal -Nru dmraid-1.0.0.rc16/debian/changelog 
dmraid-1.0.0.rc16/debian/changelog
--- dmraid-1.0.0.rc16/debian/changelog  2022-02-03 17:28:13.0 +0100
+++ dmraid-1.0.0.rc16/debian/changelog  2022-02-14 17:43:28.0 +0100
@@ -1,3 +1,11 @@
+dmraid (1.0.0.rc16-10.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix bad library symlink (closes: #1005622). Thanks to Michael Biebl and
+Lucas Nussbaum.
+
+ -- Helmut Grohne   Mon, 14 Feb 2022 17:43:28 +0100
+
 dmraid (1.0.0.rc16-10) unstable; urgency=medium
 
   [ Johannes Schauer Marin Rodrigues  ]
diff --minimal -Nru dmraid-1.0.0.rc16/debian/libdmraid-dev.links 
dmraid-1.0.0.rc16/debian/libdmraid-dev.links
--- dmraid-1.0.0.rc16/debian/libdmraid-dev.links2017-08-30 
23:28:37.0 +0200
+++ dmraid-1.0.0.rc16/debian/libdmraid-dev.links2022-02-14 
17:41:24.0 +0100
@@ -1 +1,2 @@
-lib/libdmraid.so.1.0.0.rc16 usr/lib/libdmraid.so
+#!/usr/bin/dh-exec
+lib/${DEB_HOST_MULTIARCH}/libdmraid.so.1.0.0.rc16 
usr/lib/${DEB_HOST_MULTIARCH}/libdmraid.so
diff --minimal -Nru dmraid-1.0.0.rc16/debian/rules 
dmraid-1.0.0.rc16/debian/rules
--- dmraid-1.0.0.rc16/debian/rules  2022-02-03 17:28:13.0 +0100
+++ dmraid-1.0.0.rc16/debian/rules  2022-02-14 17:41:52.0 +0100
@@ -71,7 +71,6 @@
 binary-arch: install
dh_testdir
dh_testroot
-   chmod +x debian/libdmraid*.install
dh_install
dh_installdirs
dh_installudev --priority=97

Bug#1005773: ortools-samples: ships /usr/bin/knapsack, /usr/bin/tsp

[Andreas Beckmann]

Package: ortools-samples
Version: 8.2+ds-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

I do not think that Breaks+Replaces would be an appropriate solution in
this case.

Given the package name (ortools-samples), I'm not sure whether these
example binaries belong to /usr/bin at all ..., at least not with such
generic names.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../ortools-samples_8.2+ds-1_amd64.deb ...
  Unpacking ortools-samples (8.2+ds-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/ortools-samples_8.2+ds-1_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/knapsack', which is also in package 
ruby-knapsack 1.18.0-2
  Errors were encountered while processing:
   /var/cache/apt/archives/ortools-samples_8.2+ds-1_amd64.deb

  Preparing to unpack .../ortools-samples_8.2+ds-1_amd64.deb ...
  Unpacking ortools-samples (8.2+ds-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/ortools-samples_8.2+ds-1_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/tsp', which is also in package task-spooler 
1.0.1+dfsg1-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/ortools-samples_8.2+ds-1_amd64.deb


cheers,


Andreas


ruby-knapsack=1.18.0-2_ortools-samples=8.2+ds-1.log.gz
Description: application/gzip

Bug#1005772: go-rpmdb: trying to overwrite '/usr/bin/rpmdb', which is also in package rpm

[Andreas Beckmann]

Package: go-rpmdb
Version: 0.0~git20210911.73bd0ce-1
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:

  Preparing to unpack .../go-rpmdb_0.0~git20210911.73bd0ce-1_amd64.deb ...
  Unpacking go-rpmdb (0.0~git20210911.73bd0ce-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/go-rpmdb_0.0~git20210911.73bd0ce-1_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/rpmdb', which is also in package rpm 
4.17.0+dfsg1-4
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/go-rpmdb_0.0~git20210911.73bd0ce-1_amd64.deb

This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

The use of alternatives might also be an option, this will need
coordination with the rpm package.


cheers,

Andreas

PS: for more information about the detection of file overwrite errors
of this kind see https://qa.debian.org/dose/file-overwrites.html


rpm=4.17.0+dfsg1-4_go-rpmdb=0.0~git20210911.73bd0ce-1.log.gz
Description: application/gzip

Bug#1005771: ITP: golang-github-apptainer-sif -- development files for Singularity Image Format (SIF)

[Andreas Tille]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org

Subject: ITP: golang-github-apptainer-sif -- development files for Singularity 
Image Format (SIF)
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: golang-github-apptainer-sif
  Version : 2.3.1
  Upstream Author : Apptainer a Series of LF Projects LLC
* URL : https://github.com/apptainer/sif
* License : BSD-3-Clause
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : development files for Singularity Image Format (SIF)
 This module contains an open source implementation of the Singularity
 Image Format (SIF) that makes it easy to create complete and
 encapsulated container environments stored in a single file.

Remark: This package is maintained by Debian Go Packaging Team at
   https://salsa.debian.org/go-team/packages/golang-github-apptainer-sif

Bug#1005770: ucommon: new upstream release 7.0.1

[Frédéric Brière]

Source: ucommon
Version: 7.0.0-19
Severity: wishlist

Although the main page still lists 7.0.0 as the latest version, 7.0.1
has been tagged and tarballed on Savannah[1] for some time.  This
version most notably compiles with GCC 11, thus fixing #984373.

 [1] https://git.savannah.gnu.org/cgit/commoncpp.git


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1005768: wsdd2: Please allow dependency on either samba or ksmbd-tools

[Solya Reka]

Also it would be nice if someone can package it in Backports for Debian 
11 (bullseye-backports / stable-backports).

Bug#991998: gparted segfaults if scrolling quickly the device dropdown list

[waxhead]

Package: gparted
Version: 1.3.1-1
Followup-For: Bug #991998
X-Debbugs-Cc: waxh...@dirtcellar.net

Dear Maintainer,

This version of gparted still behaves (segfaults) exactly like the original 
bugreport so no need to repeat myself.



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

Kernel: Linux 5.15.0-3-amd64 (SMP w/2 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 gparted depends on:
ii  gparted-common1.3.1-1
ii  libatkmm-1.6-1v5  2.28.2-1
ii  libc6 2.33-5
ii  libcairomm-1.0-1v51.12.2-4
ii  libgcc-s1 11.2.0-16
ii  libglib2.0-0  2.70.3-1
ii  libglibmm-2.4-1v5 2.66.2-2+b1
ii  libgtk-3-03.24.31-1
ii  libgtkmm-3.0-1v5  3.24.5-1
ii  libpangomm-1.4-1v52.46.1-1
ii  libparted-fs-resize0  3.4-2
ii  libparted23.4-2
ii  libsigc++-2.0-0v5 2.10.4-2
ii  libstdc++611.2.0-16
ii  libuuid1  2.37.3-1+b1
ii  policykit-1   0.105-31.1+b1

gparted recommends no packages.

Versions of packages gparted suggests:
pn  dmraid 
ii  dmsetup2:1.02.175-2.1
ii  dosfstools 4.2-1
ii  e2fsprogs  1.46.5-2
pn  exfatprogs 
pn  gpart  
pn  jfsutils   
pn  kpartx 
pn  mtools 
ii  ntfs-3g1:2021.8.22-3
pn  reiser4progs   
pn  reiserfsprogs  
pn  udftools   
ii  xfsprogs   5.14.2-1
ii  yelp   41.2-1

-- no debconf information

Bug#1005769: ITP: --

[Andreas Tille]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org

Subject: ITP:  -- 
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: 
  Version : 
  Upstream Author : 
* URL : 
* License : 
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : 


Remark: This package is maintained by  at
   

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

[Vincent Lefevre]

Control: reassign -1 less
Control: found -1 487-0.1
Control: found -1 590-1
Control: retitle -1 less: with option -R, the escape sequences should be sent 
in an atomic way so that they are not broken by stderr
Control: tags -1 upstream - wontfix

On 2020-01-30 21:21:03 -0500, Thomas Dickey wrote:
> So... (see my previous message), there's no way for xterm (or any terminal)
> to distinguish your shell's stdout from stderr.  There's only the usual
> solution, which assumes that applications which spit out both will do
> fflush's to keep the two in sync.

Indeed. Reassigning to less, which knows about the valid escape
sequences when option -R is used, so that it could ensure that
they are sent in an atomic way. The problem would still exist
with -r, but this option is already strongly discouraged.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1005462: xserver-xorg-video-mach64: FTBFS: ../../src/aticonfig.c:315:63: error: ‘ValueUnion’ has no member named ‘bool’; did you mean ‘boolean’?

[Sven Joachim]

Control: tags -1 + patch

On 2022-02-13 08:03 +0100, Lucas Nussbaum wrote:

> Source: xserver-xorg-video-mach64
> Version: 6.9.6-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220212 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
>> /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H
>> -I. -I../../src -I..  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall
>> -Wpointer-arith -Wmissing-declarations -Wformat=2
>> -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
>> -Wbad-function-cast -Wold-style-definition
>> -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow
>> -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls
>> -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self
>> -Werror=main -Werror=missing-braces -Werror=sequence-point
>> -Werror=return-type -Werror=trigraphs -Werror=array-bounds
>> -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast
>> -Werror=pointer-to-int-cast -fno-strict-aliasing -fvisibility=hidden
>> -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/libdrm
>> -I/usr/include/X11/dri -I/usr/include/libdrm -I/usr/include/X11/dri
>> -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong
>> -Wformat -Werror=format-security -c -o aticonfig.lo
>> ../../src/aticonfig.c
>> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src
>> -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wpointer-arith
>> -Wmissing-declarations -Wformat=2 -Wstrict-prototypes
>> -Wmissing-prototypes -Wnested-externs -Wbad-function-cast
>> -Wold-style-definition -Wdeclaration-after-statement -Wunused
>> -Wuninitialized -Wshadow -Wmissing-noreturn
>> -Wmissing-format-attribute -Wredundant-decls -Wlogical-op
>> -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main
>> -Werror=missing-braces -Werror=sequence-point -Werror=return-type
>> -Werror=trigraphs -Werror=array-bounds -Werror=write-strings
>> -Werror=address -Werror=int-to-pointer-cast
>> -Werror=pointer-to-int-cast -fno-strict-aliasing -fvisibility=hidden
>> -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/libdrm
>> -I/usr/include/X11/dri -I/usr/include/libdrm -I/usr/include/X11/dri
>> -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong
>> -Wformat -Werror=format-security -c ../../src/aticonfig.c -fPIC
>> -DPIC -o .libs/aticonfig.o
>> ../../src/aticonfig.c: In function ‘ATIProcessOptions’:
>> ../../src/aticonfig.c:315:63: error: ‘ValueUnion’ has no member named 
>> ‘bool’; did you mean ‘boolean’?
>>   315 | #   define Accel PublicOption[ATI_OPTION_ACCEL].value.bool
>>   |   ^~~~
>> ../../src/aticonfig.c:358:5: note: in expansion of macro ‘Accel’
>>   358 | Accel = CacheMMIO = HWCursor = TRUE;
>>   | ^
>> ../../src/aticonfig.c:342:68: error: ‘ValueUnion’ has no member named 
>> ‘bool’; did you mean ‘boolean’?
>>   342 | #   define CacheMMIO 
>> PublicOption[ATI_OPTION_MMIO_CACHE].value.bool
>>   |
>> ^~~~
>> ../../src/aticonfig.c:358:13: note: in expansion of macro ‘CacheMMIO’
>>   358 | Accel = CacheMMIO = HWCursor = TRUE;
>>   | ^
>> ../../src/aticonfig.c:322:66: error: ‘ValueUnion’ has no member named 
>> ‘bool’; did you mean ‘boolean’?
>>   322 | #   define HWCursor  PublicOption[ATI_OPTION_HWCURSOR].value.bool
>>   |  ^~~~
>> ../../src/aticonfig.c:358:25: note: in expansion of macro ‘HWCursor’
>>   358 | Accel = CacheMMIO = HWCursor = TRUE;
>>   | ^~~~
>> ../../src/aticonfig.c:345:67: error: ‘ValueUnion’ has no member named 
>> ‘bool’; did you mean ‘boolean’?
>>   345 | #   define ShadowFB  
>> PublicOption[ATI_OPTION_SHADOW_FB].value.bool
>>   |   
>> ^~~~
>> ../../src/aticonfig.c:362:5: note: in expansion of macro ‘ShadowFB’
>>   362 | ShadowFB = TRUE;
>>   | ^~~~
>> ../../src/aticonfig.c:317:64: error: ‘ValueUnion’ has no member named 
>> ‘bool’; did you mean ‘boolean’?
>>   317 | #   define Blend PrivateOption[ATI_OPTION_BLEND].value.bool
>>   |^~~~
>> ../../src/aticonfig.c:364:5: note: in expansion of macro ‘Blend’
>>   364 | Blend = PanelDisplay = TRUE;
>>   | ^
>> ../../src/aticonfig.c:344:71: error: ‘ValueUnion’ has no member named 
>> ‘bool’; did you mean ‘boolean’?
>>   344 | #   define PanelDisplay  
>> PublicOption[ATI_OPTION_PANEL_DISPLAY].value.bool
>>   |  
>>  ^~~~
>> ../../src/aticonfig.c:364:13: note: in expansion of macro ‘PanelDisplay’
>>   364 | Blend = 

Bug#1004946: Cannot hold down backspace to delete password

[Daniel Kahn Gillmor]

Control: forwarded 1004946 
https://gitlab.freedesktop.org/xorg/lib/libxi/-/issues/13

On Sun 2022-02-13 08:26:24 -0800, Jamie Zawinski wrote:
>> Why did you switch to it? Or am I misunderstanding that you did?
>
> For the new security model. No other way to increase the privilege separation.

Thanks for these explanations, I think I understand the situation better
now.  I've forwarded the concern upstream at the link above.  Maybe the
libXi devs will be able to address the problem, or at least propose an
alternate solution that lets XScreenSaver retain the privilege
separation and the user-friendly key repeat functionality.

   --dkg


signature.asc
Description: PGP signature

Bug#1005765: dgit doesn't handle upstream files with CRLF well

[Ian Jackson]

Stéphane Glondu writes ("Bug#1005765: dgit doesn't handle upstream files with 
CRLF well"):
> I just tried to upload opam with dgit, and I couldn't because of
> pretended differences in upstream files. However, these differences
> consist of line endings only. I couldn't find a combination of
> checked-in files and git crlf handling that would please both git and
> dgit.
> 
> Maybe dgit should call "git diff" with --ignore-cr-at-eol?

Hi.  I'm sorry you're having trouble.

I'm not sure why things don't just work for you, although I have some
guesses/suppositions.

I think that if
 - your upstream files have CRLF in the orig
 - your upstream files have CRLF in your git tree
 - you do not expect (or enable) line ending conversions in git
then
 - dgit will not complain
 - the source package you produce will have files with CRLF
 - everything should work

I suspect that maybe you are trying to create a .dsc containing
CRLFs where the git tree contains LFs, or vice versa ?

That's not going to work with dgit, because dgit's purpose is to give
someone *the very exact same source tree* via git, as they would via
"apt-get source".  So dgit checks that the git tree and the dsc are
identical - and it tries to to ensure that this check is not affected
by (and thereby perhaps defeated by) any git automatic line ending
conversions.

I think perhaps you are trying to
 - work with files with LF line endings in git
 - nevertheless use an upstream .orig tarball with CRLF line endings
 - not declare any kind of delta to represent this anomaly
?

I may be able to advise more helpfully if you were to share your git
HEAD and your orig (or means to reproduce or download it - eg
pristine-tar branch, or url, or whatever).

Ian.

Bug#1005768: wsdd2: Please allow dependency on either samba or ksmbd-tools

[Solya Reka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: wsdd2
Severity: wishlist
X-Debbugs-Cc: r...@buta.moe

Dear Maintainer,

KSMBD is a Linux kernel server which implements SMB3 protocol in kernel
space for sharing files over network, it's part of Linux kernel since
5.15. ksmbd-tools are the user space utilities for ksmbd kernel server,
and its Debian package has been accepted since December 2021.

Right now, wsdd2 depends on samba, which conflicts with ksmbd-tools.
Would you consider allow wsdd2 to be dependent on either samba or
ksmbd-tools, so that users may install them together?


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

Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wsdd2 depends on:
ii  libc6  2.33-5
pn  samba  

wsdd2 recommends no packages.

wsdd2 suggests no packages.
-BEGIN PGP SIGNATURE-
Version: BCPG C# v1.8.10.0

iQE4BAEBCAAiBQJiCoEcGxxTb2x5YSBSZWthIDxyZWthQGJ1dGEubW9lPgAKCRDX
S8NKJK0NOk+7B/9ITkTqzJNDK0loS7sGofxCPHS9j2TKI3vbVYjhifLMbhe4w/Ys
kKHf1rZZELBPgJd7/wWBM6dvjZXs96cptCg05QIV6FspSCiK7BAQ3395AKu4TYx7
Af4/Ytb2OgEaElUgei96p6LEjQ9QCldYQym2mekr7HkrAakhZlBju9PSZsO+WP8X
YVC81rF2AcpNWHYx6BHLn8aJ3TMF36GyVmF+draT2adqEdgrVY7NA6fLM/p4krQo
YOTAlqjhtAbIbyum99hENr4qW4CS9NC+GrarmC6QBYJoWyLfQDttiT9UUCwzBcjS
cPRWs9fGIVFID+Scndiv8+f8EODE0Jm82O6s
=Z0aY
-END PGP SIGNATURE-


reka@buta.moe.asc
Description: application/pgp-keys

Bug#1005480: xserver-xorg-video-trident: FTBFS: ../../src/trident.h:41:10: fatal error: xf86RamDac.h: No such file or directory

[Sven Joachim]

Control: tags -1 + patch

On 2022-02-13 08:03 +0100, Lucas Nussbaum wrote:

> Source: xserver-xorg-video-trident
> Version: 1:1.3.8-2
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220212 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
>> /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
>> -I../../src -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden 
>> -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/libdrm 
>> -I/usr/include/X11/dri  -g -O2 -ffile-prefix-map=/<>=. 
>> -fstack-protector-strong -Wformat -Werror=format-security -c -o 
>> blade_accel.lo ../../src/blade_accel.c
>> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -Wdate-time 
>> -D_FORTIFY_SOURCE=2 -fvisibility=hidden -I/usr/include/xorg 
>> -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/X11/dri -g -O2 
>> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
>> -Werror=format-security -c ../../src/blade_accel.c  -fPIC -DPIC -o 
>> .libs/blade_accel.o
>> In file included from ../../src/blade_accel.c:38:
>> ../../src/trident.h:41:10: fatal error: xf86RamDac.h: No such file or 
>> directory
>>41 | #include "xf86RamDac.h"
>>   |  ^~
>> compilation terminated.
>> make[3]: *** [Makefile:539: blade_accel.lo] Error 1

The reason is the removal of ramdac drivers in xserver 1.21[1].
Upstream's git repository for -trident has a patch[2] which works for me
(only build-time tested because I lack the hardware), attached for
convenience.

Cheers,
   Sven


1. 
https://gitlab.freedesktop.org/xorg/xserver/-/commit/f0385fb420158ac3bc1c4c325431ffc5c62344bb
2. 
https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/-/commit/07a5c4732f1c28ffcb873ee04500e3cb813c50b4

From 07a5c4732f1c28ffcb873ee04500e3cb813c50b4 Mon Sep 17 00:00:00 2001
From: Fabrice Fontaine 
Date: Tue, 7 Dec 2021 22:28:04 +0100
Subject: [PATCH] Remove ramdac

ramdac drivers have been removed from xserver since version 21.0.99.1
and
https://gitlab.freedesktop.org/xorg/xserver/-/commit/f0385fb420158ac3bc1c4c325431ffc5c62344bb
resulting in the following build failure:

In file included from trident_bank.c:37:
trident.h:41:10: fatal error: xf86RamDac.h: No such file or directory
   41 | #include "xf86RamDac.h"
  |  ^~

Fixes:
 - http://autobuild.buildroot.org/results/c81ac8075af257e8626d9d097270be7a7b4a1496

Signed-off-by: Fabrice Fontaine 
---
 src/trident.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/trident.h b/src/trident.h
index 5cadf52..c82de4c 100644
--- a/src/trident.h
+++ b/src/trident.h
@@ -38,7 +38,6 @@
 #include "xaa.h"
 #endif
 #include "xf86fbman.h"
-#include "xf86RamDac.h"
 #include "compiler.h"
 #include "vgaHW.h"
 #include "xf86i2c.h"
@@ -103,7 +102,6 @@ typedef struct {
 int			useEXA;
 int			Chipset;
 int			DACtype;
-int			RamDac;
 int ChipRev;
 int			HwBpp;
 int			BppShift;
@@ -169,7 +167,6 @@ typedef struct {
 CARD32		BltScanDirection;
 CARD32		DrawFlag;
 CARD16		LinePattern;
-RamDacRecPtr	RamDacRec;
 int			CursorOffset;
 xf86CursorInfoPtr	CursorInfoRec;
 xf86Int10InfoPtr	Int10;
--
2.34.1

Bug#1005767: mirror submission for archive.debian.petiak.ir

[Arash Sadeghi]

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

Submission-Type: new
Site: archive.debian.petiak.ir
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Arash Sadeghi 
Country: IR Iran, Islamic Republic of
Location: Tehran
Sponsor: Petiak https://www.petiak.com
Comment: We have a 10G connection to serve requests.
 We're currently official country mirror for Ubuntu and would be more than 
happy if we could be a push mirroring client and become Debian's official and 
country mirror for Iran which currently there's none.
 Hope to hear from you soon.
 Greeting from Tehran




Trace Url: http://archive.debian.petiak.ir/debian/project/trace/
Trace Url: 
http://archive.debian.petiak.ir/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://archive.debian.petiak.ir/debian/project/trace/archive.debian.petiak.ir

Bug#1005766: alert to upstream bug report on pikepdf test failures

[Jay Berkenbilt]

Package: pikepdf
Version: 4.2.0+dfsg-1
X-Debbugs-CC: q...@debian.org

The current version of pikepdf has some failed tests that are preventing qpdf 
10.6.1 from transitioning. I just wanted to make you aware of this upstream bug 
report: https://github.com/pikepdf/pikepdf/issues/303

Short version: qpdf 10.6 fixed a character encoding bug for a few obscure 
characters. This changed qpdf's response to some calls that were being made in 
pikepdf's tests. A fix to pikepdf is forthcoming that will adjust the error 
handling behavior based on a runtime check, but in the meantime, the failures 
are not actually a regression but are instead tests that are failing because 
they were relying on incorrect qpdf behavior.

I'm hoping a new pikepdf version will come out with this fix soon so just 
uploading a new pikepdf will unblock the qpdf transition. Since debian 
maintenance of pikepdf has generally been very responsive, I won't plan on 
creating another issue about it unless you would like to say something when 
pikepdf is updated. Thanks!

Bug#997120:

[Andreas Tille]

Hi Jose,

Am Mon, Feb 14, 2022 at 12:18:47AM +0100 schrieb Jose Luis Rivero:
> 
> You are welcome. This bug is preventing one of my packages (Gazebo) from
> being
> migrated to testing. Could we please upload a revision bump of the current
> version to solve this issue while we work on 5.0.2?

Hmmm, that's a bit tricky now.  I've uploaded 5.0.2 to new[1].  May be
pinging #debian-ftp could help?  (I'm hesitating a bit to do so myself
since I used that option recently a bit frequently.)
 
Kind regards

 Andreas.

[1] https://ftp-master.debian.org/new/camitk_5.0.2-1.html

-- 
http://fam-tille.de

Bug#1005765: dgit doesn't handle upstream files with CRLF well

[Stéphane Glondu]

Package: dgit
Version: 9.15
Severity: important

Dear Maintainer,

I just tried to upload opam with dgit, and I couldn't because of
pretended differences in upstream files. However, these differences
consist of line endings only. I couldn't find a combination of
checked-in files and git crlf handling that would please both git and
dgit.

Maybe dgit should call "git diff" with --ignore-cr-at-eol?


Cheers,

-- 
Stéphane


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

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

Versions of packages dgit depends on:
ii  apt2.3.15
ii  ca-certificates20211016
ii  coreutils  8.32-4.1
ii  curl   7.81.0-1
ii  devscripts 2.22.1
ii  dpkg-dev   1.21.1
ii  dput   1.1.0
ii  git [git-core] 1:2.34.1-1
ii  git-buildpackage   0.9.25
ii  libdpkg-perl   1.21.1
ii  libjson-perl   4.04000-1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-gettext-perl 1.07-4+b2
ii  libtext-csv-perl   2.01-1
ii  libtext-glob-perl  0.11-2
ii  libtext-iconv-perl 1.7-7+b2
ii  libwww-curl-perl   4.17-7+b2
ii  perl [libdigest-sha-perl]  5.34.0-3

Versions of packages dgit recommends:
ii  distro-info-data 0.52
ii  liburi-perl  5.10-1
ii  openssh-client [ssh-client]  1:8.7p1-4

Versions of packages dgit suggests:
ii  cowbuilder  0.89
ii  pbuilder0.231

-- no debconf information

Bug#1005764: ITP: wxutils -- wxPython utilities and convenience functions

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams 
X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org

* Package name: wxutils
  Version : 0.2.4
  Upstream Author : Matthew Newville 
* URL : https://github.com/newville/wxutils
* License : Expat
  Programming Lang: Python
  Description : wxPython utilities and convenience functions

 The wxutils library is a small collection of functions and classes,
 and is by no means comprehensive.
 .
 The aim is to simplify code, reduce boiler-plate, make wxPython
 coding a bit more python-like, and prevent repeating code across
 several projects.

This package is a dependency of xraylarch and will be maintained within
the Debian Python Team.

Bug#1005763: ITP: wxmplot -- wxPython plotting widgets using matplotlib

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams 
X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org

* Package name: wxmplot
  Version : 0.9.46
  Upstream Author : Matthew Newville 
* URL : https://github.com/newville/wxmplot
* License : Expat
  Programming Lang: Python
  Description : wxPython plotting widgets using matplotlib

 wxmplot bridges the gap between matplotlib and wxPython by
 providing wxPython widgets and user-friendly functions for
 basic 2D line plots, image display, and some custom plots. 

This package is a dependency of xraylarch and will be maintained within
the Debian Python Team.

Bug#958488: memtest86+: freezes in non-SMP mode at 15%

[Cristian Ionescu-Idbohrn]

Version 5.31b+dfsg-4 now behaves as expected on my hardware.



Cheers,


--

Cristian

Bug#1002789: python-pycdlib: FTBFS: failed tests

[Thomas Goirand]

On 2/14/22 14:56, Lucas Nussbaum wrote:

On 14/02/22 at 14:35 +0100, Thomas Goirand wrote:

Hi Lucas,

Please find, attached, the diff of the build log as you asked.
Your thoughts?


It's not the same version, are there any relevant differences?

Lucas


It's the same version. I just do "dch -i -m "Rebuild" to not override my 
build log.


I haven't spotted any relevant difference, indeed...

Cheers,

Thomas Goirand (zigo)

Bug#895440: jabref: The problem continues in Debian 11 bullseye

[tony mancill]

Thank you Pep!  I will follow-up soon.

On Mon, Feb 14, 2022 at 08:05:38AM +0100, Pep Roca wrote:
> Hello, Tony:
> 
> I'm sorry. Now I put the full output.
> 
> El dg. 13 de 02 de 2022 a les 09:39 -0800, en/na tony mancill va
> escriure:
> > Hello Pep,
> > 
> > On Sat, Feb 12, 2022 at 09:47:41AM +0100, Pep Roca wrote:
> > > Package: jabref
> > > Version: 3.8.2+ds-15
> > > Followup-For: Bug #895440
> > > X-Debbugs-Cc: pep.r...@gmail.com
> > > 
> > > I have problems to connect JabRef and LibreOffice in the jabref
> > > bullseye version.
> > > 
> > > I do manual connection and I get the error:
> > > 
> > > “File not found:
> > > /usr/lib/libreoffice/program/classes/program/classes/unoil.jar”
> > 
> > Can you please provide the output from the program start to the time
> > when you attempt the connection and it fails?
> > 
> > DEBUG_WRAPPER=true /usr/bin/jabref
> 
> $ DEBUG_WRAPPER=true /usr/bin/jabref
> [debug] /usr/bin/jabref: Picking up the JVM designated by the
> alternatives system: 
> [debug] /usr/bin/jabref:   JAVA_HOME = '/usr/lib/jvm/java-11-openjdk-
> amd64'
> [debug] /usr/bin/jabref: Found JAVA_HOME = '/usr/lib/jvm/java-11-
> openjdk-amd64'
> [debug] /usr/bin/jabref: Found JAVA_CMD = '/usr/lib/jvm/java-11-
> openjdk-amd64/bin/java'
> [debug] /usr/bin/jabref: Environment variable CLASSPATH is ''
> [debug] /usr/bin/jabref: Runnning /usr/lib/jvm/java-11-openjdk-
> amd64/bin/java  -classpath
> /usr/share/java/jabref.jar:/usr/share/java/bcprov.jar:/usr/share/java/a
> ntlr3-runtime.jar:/usr/share/java/antlr4-
> runtime.jar:/usr/share/java/com.android.json.jar:/usr/share/java/common
> s-cli.jar:/usr/share/java/commons-codec.jar:/usr/share/java/commons-
> lang3.jar:/usr/share/java/commons-
> logging.jar:/usr/share/java/fontbox.jar:/usr/share/java/glazedlists.jar
> :/usr/share/java/guava.jar:/usr/share/java/httpasyncclient.jar:/usr/sha
> re/java/httpclient.jar:/usr/share/java/httpcore.jar:/usr/share/java/htt
> pcore-nio.jar:/usr/share/java/httpmime.jar:/usr/share/java/java-string-
> similarity.jar:/usr/share/java/jaxb-
> runtime.jar:/usr/share/java/jempbox.jar:/usr/share/java/jgoodies-
> common.jar:/usr/share/java/jgoodies-forms.jar:/usr/share/java/jgoodies-
> looks.jar:/usr/share/java/jhlabs-
> filters.jar:/usr/share/java/jsoup.jar:/usr/share/java/juh.jar:/usr/shar
> e/java/jurt.jar:/usr/share/java/log4j-api.jar:/usr/share/java/log4j-
> core.jar:/usr/share/java/log4j-
> jcl.jar:/usr/share/java/microba.jar:/usr/share/java/mariadb-java-
> client.jar:/usr/share/java/pdfbox.jar:/usr/share/java/postgresql.jar:/u
> sr/share/java/ridl.jar:/usr/share/java/spin.jar:/usr/share/java/swingx.
> jar:/usr/share/java/swing-layout.jar:/usr/share/java/unirest-
> java.jar:/usr/share/java/unoil.jar --add-
> opens=java.desktop/java.awt=ALL-UNNAMED net.sf.jabref.JabRefMain
> 22:20:39.017 [AWT-EventQueue-0] WARN  net.sf.jabref.JabRefGUI - There
> seem to be problems with OpenJDK and the default GTK Look Using
> Metal L instead. Change to another L with caution.
> 22:20:47.775 [AWT-EventQueue-0] WARN 
> net.sf.jabref.gui.openoffice.OpenOfficePanel - Could not connect to
> running OpenOffice/LibreOffice
> java.io.IOException: File not found:
> /usr/lib/libreoffice/program/classes/program/classes/unoil.jar
> at
> net.sf.jabref.gui.openoffice.OpenOfficePanel.connect(OpenOfficePanel.ja
> va:415) ~[JabRef-3.8.2.jar:?]
> at
> net.sf.jabref.gui.openoffice.OpenOfficePanel.lambda$initPanel$1(OpenOff
> icePanel.java:142) ~[JabRef-3.8.2.jar:?]
> at
> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967
> ) [?:?]
> at
> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:
> 2308) [?:?]
> at
> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.j
> ava:405) [?:?]
> at
> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
> [?:?]
> at
> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonLis
> tener.java:279) [?:?]
> at
> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297
> ) [?:?]
> at java.awt.Component.processMouseEvent(Component.java:6635)
> [?:?]
> at
> javax.swing.JComponent.processMouseEvent(JComponent.java:3342) [?:?]
> at java.awt.Component.processEvent(Component.java:6400) [?:?]
> at java.awt.Container.processEvent(Container.java:2263) [?:?]
> at java.awt.Component.dispatchEventImpl(Component.java:5011)
> [?:?]
> at java.awt.Container.dispatchEventImpl(Container.java:2321)
> [?:?]
> at java.awt.Component.dispatchEvent(Component.java:4843) [?:?]
> at
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918)
> [?:?]
> at
> java.awt.LightweightDispatcher.processMouseEvent(Container.java:4547)
> [?:?]
> at
> java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488) [?:?]
> at java.awt.Container.dispatchEventImpl(Container.java:2307)
> [?:?]
> at 

Bug#1005762: lintian: Update known Java version up to 19

[Emmanuel Bourg]

Package: lintian
Version: 2.114.0
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java17

Dear Maintainer,

Lintian doesn't recognize bytecode generated by Java 17 yet (the 
unknown-java-class-version
warning is emitted). Could you please update the maximum known Java version to
the latest one please (i.e. Java 19, with bytecode version 63).

Thank you,

Emmanuel Bourg

Bug#995636: transition: openssl

[Sebastian Andrzej Siewior]

On 2022-02-01 21:11:11 [+0100], Sebastian Ramacher wrote:
> > Could you please update this transition request?  It's open for four
> > months and no visible response.
> 
> Kurt mention some 100 packages failing to build. I only see a handfull
> of bugs filed. So what's the status on those build failures?

I'm not sure. I checked & filled some bugs over the weekend and added a
few which were filled by ubuntu dev but not tagged as Kurt did. This
took more time than expected.
I will probably do a rebuild of the packages to be sure to have the view
of today. Some build failures got fixed in the meantime while the
packages are listed as "fail" in my old (OCT) logs (php, ruby3 (not
ruby2 but is going to be removed)).
So new logs probably…

> Cheers

Sebastian

Bug#1005761: python3.10: problem with the switch to libedit

[duck]

Source: python3.10
Version: 3.10.2-1
Severity: important
Control: affects -1 src:python-cmd2
X-Debbugs-CC: Federico Ceratto 


Quack,

I was working with python-cmd2's maintainer to get a newer version 
packaged in #1002463 and noticed Python is now using libedit, so I 
proposed a patch since libedit seems to work fine as well (in my use 
case).


Unfortunately when suggesting upstream to also make the change they 
replied that libedit does not implement the 
`rl_completion_display_matches_hook` hook and that breaks various cmd2 
features:

  https://github.com/python-cmd2/cmd2/issues/1186
I just found out #977732 and the reason for the switch but since libedit 
is not equivalent would you consider rolling this change back?


Regards.
\_o<

--
Marc Dequènes

Bug#1005758: hiera-eyaml: eyaml command is unusable with ruby-rubygems 3.3.5-2

[intrigeri]

Package: hiera-eyaml
Version: 3.2.2-2
Severity: serious

Hi,

I usually use "eyaml edit FILE.eyaml" to edit files.
It's currently broken for me on sid.

Even this simpler command fails:

  $ eyaml version
  Traceback (most recent call last):
7: from /bin/eyaml:25:in `'
6: from /bin/eyaml:25:in `load'
5: from 
/usr/share/rubygems-integration/all/gems/hiera-eyaml-3.2.2/bin/eyaml:10:in 
`'
4: from 
/usr/share/rubygems-integration/all/gems/hiera-eyaml-3.2.2/lib/hiera/backend/eyaml/plugins.rb:31:in
 `find'
3: from 
/usr/share/rubygems-integration/all/gems/hiera-eyaml-3.2.2/lib/hiera/backend/eyaml/plugins.rb:31:in
 `each'
2: from 
/usr/share/rubygems-integration/all/gems/hiera-eyaml-3.2.2/lib/hiera/backend/eyaml/plugins.rb:34:in
 `block in find'
1: from 
/usr/share/rubygems-integration/all/gems/hiera-eyaml-3.2.2/lib/hiera/backend/eyaml/plugins.rb:34:in
 `each'
  
/usr/share/rubygems-integration/all/gems/hiera-eyaml-3.2.2/lib/hiera/backend/eyaml/plugins.rb:37:in
 `block (2 levels) in find': undefined method `dependencies' for 
# (NoMethodError)


Downgrading ruby-rubygems from 3.3.5-2 (sid) to 3.2.5-2 (Bullseye)
fixes the problem.

This looks like https://github.com/voxpupuli/hiera-eyaml/issues/325.

Cheers!

Bug#994204: Fix merged; package rebuilds needed after release

[Dave Jones]

Thanks to Niels Thykier, the proposed fix [1] was merged over the 
weekend. When debhelper is next released, this should at least deal with 
the issue for future package builds. However, packages built after the 
release of 13.4 (which first incorporated the fix for #989155 which 
caused this issue) ought to have a rebuild in order to correct their 
generated maintainer scripts.


I've had a search of DCS [2] (thanks to Christian for informing me of 
this excellent resource!) and gone through all packages that match 
--no-(stop-after|restart-(on|after))-upgrade in their source (I've 
stripped out those that obviously don't apply like debhelper itself, or 
the odd one that only mentioned these in their historical changelogs, or 
within their code, like dh-runit).


The resulting list is ~80 packages long but please bear in mind that 
this *may not* be comprehensive. In particular, packages might be using 
the short form of these options (-r or -R), but for obvious reasons 
searching for these forms would be impractical. Still, I have a sneaking 
suspicion that most package maintainers tend to stick to the long-form 
of these options so I'd hope the list captures the majority of packages 
that need rebuilding.


Once the fix makes it into a debhelper release, the following packages 
ought to be rebuilt:


aoetools
apcupsd
apparmor
apt
apt-cacher-ng
aumix
bip
buildbot
ceph
chrony
cloud-init
cpufrequtils
dbus
dbus-broker
docker.io
dpdk
drbd-utils
fsprotect
g810-led
ganeti
gdnsd
gpm
h2o
haproxy
ifupdown
ifupdown-ng
iipimage
inetsim
inspircd
iwd
libvirt
live-config
live-tools
lizardfs
lxc
lxcfs
moosefs
nghttp2
nginx
ngtcp2
nodm
ntp
nullmailer
ocfs2-tools
open-infrastructure-compute-tools
open-iscsi
openstack-cluster-installer
open-vm-tools
openvpn
pacemaker
packagekit
pdudaemon
phosh
plymouth
policycoreutils
python-certbot
qcontrol
qemu
quassel
robustirc-bridge
rpcbind
runit
samba
sanlock
sbd
sbuild
slim
sysstat
systemd
tarantool
targetcli-fb
tgt
tlp
ufw
umtp-responder
unscd
wdm
whereami
xrdp
yubikey-luks
zfs-linux

[1]: https://salsa.debian.org/debian/debhelper/-/merge_requests/61

[2]: 
https://codesearch.debian.net/search?q=--no-%28stop-after%7Crestart-%28on%7Cafter%29%29-upgrade=0



Best regards,

Dave Jones.

Bug#1002325: [Help] Re: python-envisage: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned exit code 13

[Stefano Rivera]

Hi Andreas (2022.02.14_13:00:13_+)
> I switched to Github downloads and followed the Fedora approach.
> I'd be happy if you could review my changes[1].

That looks like it's all doing the right thing, I only have minor
nit-picks from review:

I'd suggest starting the multi-line shell thing with a "set -e;" for
sanity.

You could use a subshell in the inner-loop, to avoid having to change
directory back to CURDIR again, but

You could generate all the eggs and then run pybuild --test once,
letting it loop over python versions, itself.

SR

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

Bug#1002789: python-pycdlib: FTBFS: failed tests

[Lucas Nussbaum]

On 14/02/22 at 14:35 +0100, Thomas Goirand wrote:
> Hi Lucas,
> 
> Please find, attached, the diff of the build log as you asked.
> Your thoughts?

It's not the same version, are there any relevant differences?

Lucas

Bug#1005757: python-jsonschema: Please provide latest upstream release 4.4.0

[Agathe Porte]

Source: python-jsonschema
Version: 3.2.0-5
Severity: wishlist
X-Debbugs-Cc: deb...@microjoe.org

Dear Maintainer,

I am currently packaging dtschema (see ITP #1005301 [0]). This package
seems to use a validator introduced in 2019 but not available in the
current 3.2 release.

Here is the test failing during package build:

> ==
> ERROR: dtschema (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: dtschema
> Traceback (most recent call last):
>   File "/usr/lib/python3.9/unittest/loader.py", line 470, in _find_test_path
> package = self._get_module_from_name(name)
>   File "/usr/lib/python3.9/unittest/loader.py", line 377, in 
> _get_module_from_name
> __import__(name)
>   File 
> "/home/microjoe/dev/debian/result/dt-schema/.pybuild/cpython3_3.9_dt-schema/build/dtschema/__init__.py",
>  line 1, in 
> from dtschema.lib import (
>   File 
> "/home/microjoe/dev/debian/result/dt-schema/.pybuild/cpython3_3.9_dt-schema/build/dtschema/lib.py",
>  line 766, in 
> DTVal = jsonschema.validators.extend(jsonschema.Draft201909Validator, 
> {'typeSize': typeSize, 'phandle': phandle})
> AttributeError: module 'jsonschema' has no attribute 'Draft201909Validator'
>
>
> --
> Ran 1 test in 0.000s
>
> FAILED (errors=1)


It seems to be that providing the latest 4.4.0 release should solve this
issue, and allow me to finish the packaging of the dtschema package. The
`Draft201909Validator` was introduced a commit 6 months ago in upstream
[1].

Bests regards,

Agathe.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005301
[1] 
https://github.com/Julian/jsonschema/commit/d104bdbe2ce3f283e4e2bbf2a5fe7f6f7d6f7280


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

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

Bug#1005756: RM: python-pydot-ng -- ROM; deprecated upstream

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal

Hi,

pydot-ng and pydotplus were created as fork of pydot for OpenStack to use,
because upstream wasn't responsive. When I mentionned we effectively had
2 forks for the same thing, they merged back in pydotplus. Now, pydot-ng
isn't used anywhere upstream or in Debian.

It's probably a good time to get rid of python-pydot-ng in Debian now that
this has been solved upstream.

Please remove python-pydot-ng from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#1005518: frogr: FTBFS: ../data/meson.build:32:5: ERROR: Function does not take positional arguments.

[Alberto Garcia]

On Sun, Feb 13, 2022 at 08:27:19AM +0100, Lucas Nussbaum wrote:

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > Configuring org.gnome.frogr.desktop.in using configuration
> > 
> > ../data/meson.build:32:5: ERROR: Function does not take positional 
> > arguments.

For reference, this is the reason why it fails:

   https://github.com/mesonbuild/meson/issues/9441

If you follow the link you'll see that lots of GNOME apps were
affected by this.

I'll prepare a fixed version of Frogr soon.

Berto

Bug#1005755: debian/copyright missing GPL-3+ copyright statements

[David Mohammed]

Package: gnome-control-center
Version: 1:41.2-2
Severity: serious

Hi,

  gnome-control-center has several files that are stated as GPL-3+ in
their source headers

for example -

panels/applications/search.h
panels/applications/cc-applications-panel.h
panels/network/cc-qr-code.h

In the package, debian/copyright GPL-3+ isn't explicitly stated for these files.

The reason for raising this is that budgie-desktop has forked
gnome-control-center and we have used much of the packaging from
G-C-C.

ftp-master (Thorsten Alteholz) has rejected this package with the reason

"please mention the files licensed under GPL-3+ in your debian/copyright."

I've also stated "serious" since according to this bug-report this is
a Debian policy violation

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

thanks

David

Bug#699746: #699746 x11-utils: xprop assumes that WM_ICON_NAME and WM_NAME are encoded in ISO-8859-1

[Vincent Lefevre]

On 2022-02-13 18:44:28 -0500, Thomas Dickey wrote:
> I was recently reminded of this one, and can see that it's no longer relevant:
> 
> + The bug-report made incorrect assumptions about what xprop ought to be 
> doing.
>   So it's not relevant to xprop.

Well, I initially thought that this was xprop's fault, while according
to a few tests below, it now seems that this was entirely xterm's.

FYI, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699746#38
I said:

| Is xprop doing anything wrong or should this problem be regarded
| as coming from xterm specifically, in which case the bug should be
| reassigned to xterm?

But no-one replied to this.

> + Regarding xterm, my changes in patch #349 make it do by default what Vincent
>   assumed.
> 
>  Patch #349 - 2019/09/22
>  * improve title-string feature:
>   + if any of allowC1Printable, utf8Title or titleModes hint that
> an  application  might  send a title-string encoded in UTF-8,
> check  if  that  is  the  case,  and  if it is recodable into
> ISO-8859-1, use that for the ICCCM-style title.
>   + check  if the title given by a control sequence happens to be
> already  encoded  in UTF-8, to avoid double-encoding (FreeBSD
> #240393).
>   + Make sameName resource work for the EWMH titles.
>   + Modify menu-state of utf8Title to be consistent with the utf8
> source,  i.e., setting the EWMH properties automatically when
> UTF-8 is active.

Thanks. It seems to solve all the problems, while the results with
xterm 344 on Debian/oldstable were still incorrect.

To summarize:

$ /usr/bin/xterm -e 'printf "\e]1;my_icon€\x07\e]2;my_title€\x07"; sleep 999'

with xterm 344 gives "my_title???" and "my_icon???" in FVWM, and the
current xprop (from x11-utils 7.7+5) gives

WM_ICON_NAME(STRING) = "my_iconâ?¬"
WM_NAME(STRING) = "my_titleâ?¬"

which is obviously incorrect.

With xterm 351, I get "my_title€" and "my_icon€" in FVWM as expected,
and the current xprop gives

WM_ICON_NAME(COMPOUND_TEXT) = "my_icon€"
WM_NAME(COMPOUND_TEXT) = "my_title€"

which is correct.

$ /usr/bin/xterm -e 'printf "\e]1;my_iconé\x07\e]2;my_titleé\x07"; sleep 999'

with xterm 344 gives "my_titleé" and "my_iconé" in FVWM, which is
correct, but the current xprop gives

WM_ICON_NAME(STRING) = "my_iconé"
WM_NAME(STRING) = "my_titleé"

which still corresponds to the issue reported here.

With xterm 351, I still get  "my_titleé" and "my_iconé" in FVWM as
expected, and the current xprop gives

WM_ICON_NAME(STRING) = "my_iconé"
WM_NAME(STRING) = "my_titleé"

which is correct.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1005754: libopenmpi3: linked library libpmix.so.2 not found

[Markus Blatt]

Package: libopenmpi3
Version: 4.1.2-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I just updated my chroot of cowbuilder to build my own package that runs some
parallel
programs during make test. When these are run I get errors like this

 7/27 Test #16: minpvprocessor ..***Failed0.64 sec
[smaug.dr-blatt.de:34326] mca_base_component_repository_open: unable to open
mca_pmix_ext3x: libpmix.so.2: cannot open shared object file: No such file or
directory (ignored)
[smaug.dr-blatt.de:34326] [[62064,0],0] ORTE_ERROR_LOG: Not found in file
../../../../../../orte/mca/ess/hnp/ess_hnp_module.c at line 320
--
It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):

  opal_pmix_base_select failed
  --> Returned value Not found (-13) instead of ORTE_SUCCESS
--

It seems libpmix2 library is not found. There seems to have been an aborted
mini transition
for that lately, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951310
which might be
the cause for this.

root@smaug:/tmp/buildd/opm-grid-2021.10# ldd /usr/lib/x86_64-linux-
gnu/openmpi/lib/openmpi3/mca_pmix_ext3x.so
linux-vdso.so.1 (0x7ffd381e7000)
/usr/lib/cowdancer/libcowdancer.so (0x7f4e86c75000)
libopen-pal.so.40 => /usr/lib/x86_64-linux-gnu/libopen-pal.so.40
(0x7f4e86bb8000)
libpmix.so.2 => not found
libevent_core-2.1.so.7 => /usr/lib/x86_64-linux-
gnu/libevent_core-2.1.so.7 (0x7f4e86b7e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f4e86b5d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4e86993000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f4e8698c000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f4e86987000)
libhwloc.so.15 => /usr/lib/x86_64-linux-gnu/libhwloc.so.15
(0x7f4e8692b000)
libevent_pthreads-2.1.so.7 => /usr/lib/x86_64-linux-
gnu/libevent_pthreads-2.1.so.7 (0x7f4e86926000)
/lib64/ld-linux-x86-64.so.2 (0x7f4e86ca4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f4e867e3000)
libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1
(0x7f4e867b8000)
root@smaug:/tmp/buildd/opm-grid-2021.10#

Please not that this means that packages tested by salsaci that run parallel
programs
during make test will fail also. See e.g.
https://salsa.debian.org/science-team/opm-grid/-/jobs/2466390


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

Kernel: Linux 5.10.0-11-amd64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C),
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libopenmpi3 depends on:
ii  libc62.33-5
ii  libevent-core-2.1-7  2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libfabric1   1.11.0-3
ii  libgcc-s111.2.0-16
ii  libhwloc-plugins 2.7.0-2
ii  libhwloc15   2.7.0-2
ii  libibverbs1  39.0-1
ii  libnl-3-200  3.5.0-0.1
ii  libpmix2 4.1.2-1
ii  libpsm-infinipath1   3.3+20.604758e7-6.1
ii  libpsm2-211.2.185-1
ii  libstdc++6   11.2.0-16
ii  libucx0  1.12.1~rc1-1
ii  zlib1g   1:1.2.11.dfsg-2


libopenmpi3 recommends no packages.

libopenmpi3 suggests no packages.

Bug#1005632: python-novaclient: FTBFS: make[1]: pyversions: No such file or directory

[Thomas Goirand]

Hi Lucas & Sandro,

It looks like the issue isn't in novaclient, but in prettytable. Indeed, 
the package registers itself as version 0.0.0 (ie: it shows in the 
egg-info directory name and in the generated PKG-INFO file). This breaks 
the version detection from python3-novaclient, which leads to the FTBFS 
Lucas reported.


I've posted a diff over here:
https://salsa.debian.org/python-team/packages/prettytable/-/merge_requests/2/diffs

This fixed the build of python-novaclient for me (I tried with the built 
version of prettytable with the mentioned patch).


Sando, please either fix it yourself, or allow me to NMU the fix.

Cheers,

Thomas Goirand (zigo)

Bug#1005725: gavodachs2-server: fails to install with new python3-twisted.

[Ole Streicher]

Hi Markus,

On 14.02.22 13:47, Markus Demleitner wrote:

My plan right now would be to fix this in unstable by just packaging
release 2.6, which ought to happen in May 2022 and will contain the
patch (or whatever else).  If that's a major problem for someone,
speak up and I'll try to provide a more timely fix.


Just FYI: The Ubuntu 22.04 LTS Debian import freeze is on Feb 24:

https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906

If you want to have the fixes in Ubuntu 22.04 LTS, you should act before.

Cheers

Ole

Bug#1005753: ITP: simple-whip-server -- simple WHIP server using Janus as backend

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian VoIP Team 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: simple-whip-server
  Version : 0.0~git20220204
  Upstream Author : Lorenzo Miniero 
* URL : https://github.com/meetecho/simple-whip-server
* License : GPL-3
  Programming Lang: JavaScript
  Description : simple WHIP server using Janus as backend

 simple-whip-server is a WHIP server
 using the Janus WebRTC Server as a WebRTC server backend.
 .
 WebRTC-HTTP ingestion protocol (WHIP)
 is a simple HTTP based protocol
 that will allow WebRTC based ingest of content
 into streaming servics and/or CDNs.
 .
 janus is a general purpose WebRTC server/gateway
 with a minimal footprint.

Package will be team-maintained in the Debian VoIP team at
https://salsa.debian.org/pkg-voip-team/simple-whip-server

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmIKUq0ACgkQLHwxRsGg
ASEYahAAn2DeR38DCj7QWfaDWXokaNNj2excXTciYAX1xe/u4M0YU1chYnmmQck9
vSD4wReyegzPPbtXXEh3zFxoF/VMWWtXp7qNNOMeC/6lPx6Mpo0e15beM12IVcJ3
yWEiEDZABwBY7WWv5yBMandLncWglEp/ZFqsJCkkcMGso4WfscBAoYn9PdCLdTs6
K9FRYOnXosMsAxQ575qihfTY6mBN+/88l0HBgDTJD6iB6Zjf2q5vecrdeZLZoX/E
+onMldQOBz9pzTiFJ2fSWFQrma9ynUjA8+c8C/8huvBU7Zy4jI/oWVLTQyqwmvu0
3tLqGtEAKbD5JCnxyfD8NPXzI/ezwm5qj4sHJ/YSNPL9EgZCysxDlonXuYVU+OqD
A8cII5jZan15XzFGYHgeKF6gAMPorrF7erJaiTDRxGsf5d6EfGXCTeCrhXrBjFOU
ioT7NCG8sZ/ewCgpLdu1VJ/SE/fIfvd5S5quwGC5f/WONBJaSCwtkjaMIV/KecGI
od/pQWLLwJ3glGFBwRr+bcpUddi47S6GXaLBtEel6S6qTgt7cxXaASL60FN67LNj
Dy3F/YXLPh6f42GCADM5lV6idkB0nUvYS/hYG9XMTbrlIBvBt+1MUqGGBgoTvZYE
QFfl8NpC4fg6j2sUYlfDPLpgxyxXkDazgwWg1N6ynLKVJzGBC7c=
=9W8r
-END PGP SIGNATURE-

Bug#1002325: [Help] Re: python-envisage: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned exit code 13

[Andreas Tille]

Hi Scott,

thanks a lot for your hints.

Am Sun, Feb 13, 2022 at 10:28:15PM -0500 schrieb Scott Talbert:
> I spent some time looking into this.  The problem is that upstream includes
> binary eggs (which are Python version specific) as part of its test suite.
> The problem here is that there are no eggs included for Python 3.10.
> Upstream is aware of this[1] but unfortunately, that patch can't be applied
> because it is a binary patch.  They have also later[2] removed the binary
> eggs completely, but that patch can't be applied either because it involves
> files that are not in the PyPI distribution.  The best solution might be do
> what Fedora did[3], but for that we'd probably have to switch to using a
> GitHub tarball instead of the PyPI tarball because the PyPI tarball is
> missing files.

I switched to Github downloads and followed the Fedora approach.
I'd be happy if you could review my changes[1].

Kind regards

 Andreas.


[1] 
https://salsa.debian.org/python-team/packages/python-envisage/-/commit/1498f59734676a667d7ba64a2cc622a5c4f07f7b

-- 
http://fam-tille.de

Bug#1005725: gavodachs2-server: fails to install with new python3-twisted.

[Markus Demleitner]

On Sun, Feb 13, 2022 at 11:57:56PM +, peter green wrote:
> > Exception payload: module 'twisted.web.template' has no attribute
> > '_ToStan'
> > dpkg: error processing package gavodachs2-server (--configure):
> >  installed gavodachs2-server package post-installation script subprocess 
> > returned error exit status 1
> 
> I attempted to fix that error (debdiff attatched), however it then
> failed with a "TypeError: 'Tag' object is not subscriptable", I
> modified the error handling to get a backtrace, but it didn't leave
> me any the wiser as to what the actual problem was.

The problem is a good deal deeper -- DaCHS needs some functionality
in the stan templates previously provided by nevow.  To have that, it
needs to patch template.Tag (and yes, someone should try to get
twisted.web have a configurable Tag class); that, however, has
changed its interface in subtle ways (and needs to be monkeypatched
in other places).

I *think* the patch at https://docs.g-vo.org/twisted-21-patch.txt
ought to do the trick, but since the postgres in my unstable
container keeps crashing on me right now, it's not properly tested
yet.

My plan right now would be to fix this in unstable by just packaging
release 2.6, which ought to happen in May 2022 and will contain the
patch (or whatever else).  If that's a major problem for someone,
speak up and I'll try to provide a more timely fix.

 -- Markus

Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

[Thorsten Leemhuis]

[TLDR: I'm adding the regression report below to regzbot, the Linux
kernel regression tracking bot; all text you find below is compiled from
a few templates paragraphs you might have encountered already already
from similar mails.]

Hi, this is your Linux kernel regression tracker speaking.

CCing the regression mailing list, as it should be in the loop for all
regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

To be sure this issue doesn't fall through the cracks unnoticed, I'm
adding it to regzbot, my Linux kernel regression tracking bot:

#regzbot ^introduced 3c196f05
#regzbot title amdgfx: suspend stopped working
#regzbot ignore-activity
#regzbot link: https://bugs.debian.org/1005005

Reminder for developers: when fixing the issue, please add a 'Link:'
tags pointing to the report (the mail quoted above) using
lore.kernel.org/r/, as explained in
'Documentation/process/submitting-patches.rst' and
'Documentation/process/5.Posting.rst'. This allows the bot to connect
the report with any patches posted or committed to fix the issue; this
again allows the bot to show the current status of regressions and
automatically resolve the issue when the fix hits the right tree.

I'm sending this to everyone that got the initial report, to make them
aware of the tracking. I also hope that messages like this motivate
people to directly get at least the regression mailing list and ideally
even regzbot involved when dealing with regressions, as messages like
this wouldn't be needed then.

Don't worry, I'll send further messages wrt to this regression just to
the lists (with a tag in the subject so people can filter them away), if
they are relevant just for regzbot. With a bit of luck no such messages
will be needed anyway.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of
reports on my table. I can only look briefly into most of them and lack
knowledge about most of the areas they concern. I thus unfortunately
will sometimes get things wrong or miss something important. I hope
that's not the case here; if you think it is, don't hesitate to tell me
in a public reply, it's in everyone's interest to set the public record
straight.


On 12.02.22 19:23, Salvatore Bonaccorso wrote:
> Hi Alex, hi all
> 
> In Debian we got a regression report from Dominique Dumont, CC'ed in
> https://bugs.debian.org/1005005 that afer an update to 5.15.15 based
> kernel, his machine noe longer suspends correctly, after screen going
> black as usual it comes back. The Debian bug above contians a trace.
> 
> Dominique confirmed that this issue persisted after updating to 5.16.7
> furthermore he bisected the issue and found 
> 
>   3c196f0510912645c7c5d9107706003f67c3 is the first bad commit
>   commit 3c196f0510912645c7c5d9107706003f67c3
>   Author: Alex Deucher 
>   Date:   Fri Nov 12 11:25:30 2021 -0500
> 
>   drm/amdgpu: always reset the asic in suspend (v2)
> 
>   [ Upstream commit daf8de0874ab5b74b38a38726fdd3d07ef98a7ee ]
> 
>   If the platform suspend happens to fail and the power rail
>   is not turned off, the GPU will be in an unknown state on
>   resume, so reset the asic so that it will be in a known
>   good state on resume even if the platform suspend failed.
> 
>   v2: handle s0ix
> 
>   Acked-by: Luben Tuikov 
>   Acked-by: Evan Quan 
>   Signed-off-by: Alex Deucher 
>   Signed-off-by: Sasha Levin 
> 
>drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 -
>1 file changed, 4 insertions(+), 1 deletion(-)
> 
> to be the first bad commit, see https://bugs.debian.org/1005005#34 .
> 
> Does this ring any bell? Any idea on the problem?
> 
> Regards,
> Salvatore

-- 
Additional information about regzbot:

If you want to know more about regzbot, check out its web-interface, the
getting start guide, and the references documentation:

https://linux-regtracking.leemhuis.info/regzbot/
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md

The last two documents will explain how you can interact with regzbot
yourself if your want to.

Hint for reporters: when reporting a regression it's in your interest to
CC the regression list and tell regzbot about the issue, as that ensures
the regression makes it onto the radar of the Linux kernel's regression
tracker -- that's in your interest, as it ensures your report won't fall
through the cracks unnoticed.

Hint for developers: you normally don't need to care about regzbot once
it's involved. Fix the issue as you normally would, just remember to
include 'Link:' tag in the patch descriptions pointing to all reports
about the issue. This has been expected from developers even before
regzbot showed up for reasons explained in

Bug#1005643: ruby2.7: FTBFS with OpenSSL 3.0

[Lucas Kanashiro]

Em 13/02/2022 07:37, Sebastian Andrzej Siewior escreveu:

Source: ruby2.7
Version: 2.7.5-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0
control: forwarded -1 https://github.com/ruby/openssl/issues/369

Your package is failing to build using OpenSSL 3.0 with the
following error:
| make -f exts.mk -w RUBY="./miniruby -I./lib -I. -I.ext/common " 
top_srcdir="." note
| make[3]: Entering directory '/<>'
| *** Following extensions are not compiled:
| openssl:
| Could not be configured. It will not be installed.
| /<>/ext/openssl/extconf.rb:111: OpenSSL >= 1.0.1, < 3.0.0 
or LibreSSL >= 2.5.0 is required
| Check ext/openssl/mkmf.log for more details.
| *** Fix the problems, then remove these directories and try again if you want.

Sebastian

This issue is fixed in ruby3.0, and the idea is to not release ruby2.7 
in bookworm. Let's keep this opened until we remove ruby2.7 and the 
ruby3.0 transition to be the default is done.


--
Lucas Kanashiro

Bug#1005397: src:ruby2.7: fails to migrate to testing for too long: FTBFS on ppc64el

[Lucas Kanashiro]

AFAIK we are not working to fix it (if some of the other maintainers is 
actively working on this, correct me please). We are willing to ship 
ruby3.0 in bookworm (instead of ruby2.7), but at the moment we are 
waiting for the release team to start the ruby2.7 removal. Hopefully, 
ruby2.7 will be removed from soon.


Em 12/02/2022 16:50, Paul Gevers escreveu:

Source: ruby2.7
Version: 2.7.4-1
Severity: serious
Control: close -1 2.7.5-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

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:ruby2.7 has been trying 
to migrate for 61 days [2]. Hence, I am filing this bug. Your package 
fails to build from source on ppc64el while it built there in the past.


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=ruby2.7


--
Lucas Kanashiro

Bug#991597: pulseaudio: Please enable GStreamer support

[Laurent Bigonville]

Le 14/02/22 à 13:01, Tomas Janousek a écrit :

-

Hi all,


Hello,


On Wed, Aug 04, 2021 at 09:55:44AM +0200, Laurent Bigonville wrote:

Le 3/08/21 à 18:46, Felipe Sateler a écrit :
>Does that mean that enabling it, would only add some dependencies
>but not actually do anything?

Yes, a (soft) dependency should probably be added against
gstreamer1.0-plugins-bad, but as I said, the needed version (>=
1.19) is not yet in debian

There's gstreamer 1.20 in unstable and testing now, so there's a 
chance it would finally do something useful if enabled. :-)


Yes it's planned, I've a build on my laptop and I did some testing with 
my Sony (WF1000xm4, WH1000xm4,...) devices and when using LDAC, it's not 
working (no sound or device crashing).


So I personally don't want to upload the change before this is fixed.

Bug#1005751: kuvert: mishandles sendmail invocation for messages without X-Kuvert-From header

[Victor Westerhuis]

Package: kuvert
Version: 2.2.3
Severity: normal
Tags: patch upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

kuvert passes the full contents of the first address in the From header to
sendmail's -f option. At least msmtp's sendmail implementation expects the
argument to -f to be just the e-mail address.

I've opened a PR on Github with the 1-character fix, see
https://github.com/az143/kuvert/pull/3.


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

Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_NL.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US:en:nl_NL:nl
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kuvert depends on:
ii  gnupg 2.2.27-3
ii  libauthen-sasl-perl   2.1600-1.1
ii  libc6 2.33-5
ii  libencode-locale-perl 1.05-1.1
ii  libfile-slurp-perl.32-1
ii  libio-socket-ssl-perl 2.074-2
ii  libmailtools-perl 2.21-1
ii  libmime-tools-perl5.509-1
ii  libnet-server-mail-perl   0.28-1
ii  libnet-smtps-perl 0.10-1
ii  libproc-processtable-perl 0.634-1+b1
ii  msmtp-mta [mail-transport-agent]  1.8.16-1
ii  perl  5.34.0-3

kuvert recommends no packages.

Versions of packages kuvert suggests:
ii  keyutils  1.6.1-2+~lto

- -- no debconf information

- -- debsums errors found:
debsums: changed file /usr/bin/kuvert (from kuvert package)

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmIKTTcTHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+0rUEACjXbb1WwdWvk2DrPo6UMuqPhoTZ9sM
bA+93xT9iAgWSzhz222SO0MQyWtlHx0Z39s/wUj1HecJb51+6EDqKA1b8l2FESgv
k2iON7zyuoYqbY7WNhLT1YM3weiH8eb43d5HAydieo42EeoaemQYTlthA8pCfgxB
JBGBw8aEnnxCsfwOKSi4pVzzry0H3yDRoj2jq5b/h0RvLjYPFxasW602oqzgXgZE
Zp06LRa6LMeD9hMc6ZOkoTNIV31zBnJSIPWkbuTsYRi+pgfvqqriJ7gnK0+ei0VW
2sG0SJ6nGtNweFDCGYV3XrYEcy483ETT4YNHGmkmLVJEUPK5bFiKUrc1J/ZAw7YC
O5O6KTR++yFMG6K8iQHvTsY5nhzzfCYit0G1xMos9tb4OF2M4kWiTiUkYTm8+Fm0
/RVMwK/AZ+JUBAfghXpTbb21+CExL6Q9eERcQCPWvxyVs390RqB2gCh+PCLeYNRM
oKeDJLbGZO3ep2NsdKhh/739KEMCl2mqn4xBMKLG5r0Zqv3SRUp+oSWfO9BSPnW5
ZSwdGgFY+k8qkKI9v+eTWpeB3GqPNPmzam9+UyfSmL+ksxU9uJoioC4BY849RnNN
rkwcVb4epFcEfJas2OQW9F/UVoZSs25w5PSXKOuoGoJiF4bF1yLO9BHoJkh7Ma96
LrfvW3X5cUFTEw==
=Y5Y/
-END PGP SIGNATURE-

Bug#996903: xpdf 3.04+git20211001-1 crashes

[Eugene Berdnikov]

  Hi.
  
On Fri, Oct 22, 2021 at 01:44:38AM +0200, Florian Schlichting wrote:
> On Thu, Oct 21, 2021 at 04:25:28PM +0300, Eugene Berdnikov wrote:
> >   Hi Florian.
> >   
> > On Thu, Oct 21, 2021 at 03:11:41PM +0200, Florian Schlichting wrote:
> > > I've just uploaded xpdf 3.04+git20211021-1 which should fix #996832 -
> > > once it hits the mirrors in a few hours, can you check if that improves
> > > your issue as well?
> > 
> >  Can you give a direct url of package for download?
> 
> there's a mirror sync like 4 times a day, so it can take a while. By
> now, the new package can be seen here:
> https://packages.debian.org/sid/xpdf
> 
> from which you can follow links to (for example)
> - 
> http://ftp.ru.debian.org/debian/pool/main/x/xpdf/xpdf_3.04+git20211021-1_amd64.deb
> - 
> http://ftp.debian.org/debian/pool/main/x/xpdf/xpdf_3.04+git20211021-1_i386.deb
> or whatever suits you

 The 3.04+git20220201-1 Debian package was tried today, but it has same
 problems: question marks where "Page" and "Size" should be,
 "?" and "+" instead of letters in table of contents and in search form.
 Tested for LANG=C and russian locale "ru_RU.UTF8".
-- 
 Eugene Berdnikov

Bug#991597: pulseaudio: Please enable GStreamer support

[Tomas Janousek]

Hi all,

On Wed, Aug 04, 2021 at 09:55:44AM +0200, Laurent Bigonville wrote:

Le 3/08/21 à 18:46, Felipe Sateler a écrit :
Does that mean that enabling it, would only add some dependencies 
but not actually do anything?


Yes, a (soft) dependency should probably be added against 
gstreamer1.0-plugins-bad, but as I said, the needed version (>= 1.19) 
is not yet in debian


There's gstreamer 1.20 in unstable and testing now, so there's a chance 
it would finally do something useful if enabled. :-)


--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/

Bug#1005750: RM: sat-templates -- RoM; superseded by libervia-templates

[From]

Package: ftp.debian.org
X-Debbugs-Cc: pkg-xmpp-de...@lists.alioth.debian.org

sat-templates has been renamed to libervia-templates

Bug#1005749: RM: sat-pubsub -- RoM; superseded by libervia-pubsub

[From]

Package: ftp.debian.org
X-Debbugs-Cc: pkg-xmpp-de...@lists.alioth.debian.org

sat-pubsub has been renamed to libervia-pubsub

Bug#1005748: RM: salutatoi -- RoM; superseded by libervia-backend

[Martin]

Package: ftp.debian.org
X-Debbugs-Cc: pkg-xmpp-de...@lists.alioth.debian.org

salutatoi has been renamed to libervia-backend

Bug#1005747: freecad: CVE-2021-45844 - Improper sanitization in the invocation of ODA File Converter

[Neil Williams]

Source: freecad
Version: 0.19.2+dfsg1-3
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for freecad.

CVE-2021-45844[0]:
| Improper sanitization in the invocation of ODA File Converter from
| FreeCAD 0.19 allows an attacker to inject OS commands via a crafted
| filename.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-45844
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45844

Please adjust the affected versions in the BTS as needed.


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

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

Bug#985696: debian-installer: Speech synthesis and Intel SOF firmware

[Samuel Thibault]

Hello,

Arnaud Rebillout, le lun. 22 mars 2021 17:30:30 +0700, a ecrit:
> some recent Intel sound cards require a firmware to work. This firmware
> is packaged under 'firmware-sof-signed'. For reference, you might want
> to look at the ITP [1].
> 
> I tried it with my laptop. What happens is that the installer gets stuck
> straight from the beginning, prior it can show any kind of GUI. All I
> get is a black scree with the lines:
> 
>   Please wait while we probe your sound card(s)...

Could you try with the following image:

https://people.debian.org/~sthibault/tmp/debian-sid-amd64-NETINST-1.iso

It's supposed to have the firmware available for loading before speech
starts.

Samuel

Bug#965584: hunspell-ar: diff for NMU version 3.2-1.2

[Jonas Smedegaard]

Control: tags 965584 + patch
Control: tags 965584 + pending

Dear maintainer,

I've prepared an NMU for hunspell-ar (versioned as 3.2-1.2) and
uploaded it without delay, due to fixing release-critical bug.

Regards,

 - Jonas

diff -Nru hunspell-ar-3.2/debian/changelog hunspell-ar-3.2/debian/changelog
--- hunspell-ar-3.2/debian/changelog2018-10-30 19:31:07.0 +0100
+++ hunspell-ar-3.2/debian/changelog2022-02-14 12:22:31.0 +0100
@@ -1,3 +1,12 @@
+hunspell-ar (3.2-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * use debhelper compatibility level 9 (not 5);
+tighten build-dependency on debhelper;
+closes: bug#965584, thanks to Niels Thykier
+
+ -- Jonas Smedegaard   Mon, 14 Feb 2022 12:22:31 +0100
+
 hunspell-ar (3.2-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru hunspell-ar-3.2/debian/compat hunspell-ar-3.2/debian/compat
--- hunspell-ar-3.2/debian/compat   2007-09-22 11:25:05.0 +0200
+++ hunspell-ar-3.2/debian/compat   2022-02-14 12:22:01.0 +0100
@@ -1 +1 @@
-5
+9
diff -Nru hunspell-ar-3.2/debian/control hunspell-ar-3.2/debian/control
--- hunspell-ar-3.2/debian/control  2018-10-30 19:30:57.0 +0100
+++ hunspell-ar-3.2/debian/control  2022-02-14 12:22:11.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Lior Kaplan 
 Uploaders: Mohammed Sameer 
 Standards-Version: 3.9.3
-Build-Depends: debhelper (>> 5.0.0)
+Build-Depends: debhelper (>> 9)
 Build-Depends-Indep: dictionaries-common-dev (>= 0.49.2)
 Homepage: http://ayaspell.sourceforge.net/
 

Bug#965741: myspell-sq: diff for NMU version 1.6.4-1.2

[Jonas Smedegaard]

Control: tags 965741 + patch
Control: tags 965741 + pending

Dear maintainer,

I've prepared an NMU for myspell-sq (versioned as 1.6.4-1.2) and
uploaded it without delay, due to fixing release-critical bugs.

Regards,

 - Jonas

diff -Nru myspell-sq-1.6.4/debian/changelog myspell-sq-1.6.4/debian/changelog
--- myspell-sq-1.6.4/debian/changelog   2021-01-02 16:37:38.0 +0100
+++ myspell-sq-1.6.4/debian/changelog   2022-02-14 12:19:49.0 +0100
@@ -1,3 +1,11 @@
+myspell-sq (1.6.4-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * use debhelper compatibility level 9 (not 5); tighten build-
+dependency on debhelper; closes: bug#965741, thanks to Niels Thykier
+
+ -- Jonas Smedegaard   Mon, 14 Feb 2022 12:19:49 +0100
+
 myspell-sq (1.6.4-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru myspell-sq-1.6.4/debian/compat myspell-sq-1.6.4/debian/compat
--- myspell-sq-1.6.4/debian/compat  2010-05-09 21:02:36.0 +0200
+++ myspell-sq-1.6.4/debian/compat  2022-02-14 12:17:13.0 +0100
@@ -1 +1 @@
-5
+9
diff -Nru myspell-sq-1.6.4/debian/control myspell-sq-1.6.4/debian/control
--- myspell-sq-1.6.4/debian/control 2017-09-04 15:59:19.0 +0200
+++ myspell-sq-1.6.4/debian/control 2022-02-14 12:17:25.0 +0100
@@ -2,7 +2,7 @@
 Section: text
 Priority: optional
 Maintainer: Lior Kaplan 
-Build-Depends: debhelper (>> 5.0.0)
+Build-Depends: debhelper (>> 9)
 Build-Depends-Indep: dictionaries-common-dev
 Standards-Version: 4.0.0
 Homepage: http://www.shkenca.org/k6i/