Bug#1040751: ITP: nanosvg -- simple svg parsing library

[Mathieu Malaterre]

On Mon, Jul 10, 2023 at 6:03 AM Chow Loong Jin  wrote:
> * Package name: nanosvg
>   Version : 0~git20221204.1.9da543e
>   Upstream Contact: https://github.com/memononen/nanosvg/issues
> * URL : https://github.com/memonenen/nanosvg

https://github.com/memononen/nanosvg

> * License : zlib
>   Programming Lang: C
>   Description : simple svg parsing library
>
> NanoSVG is a simple stupid single-header-file SVG parse. The output of
> the parser is a list of cubic bezier shapes.
[...]
> I will be packaging this library under the Debian 3-D Printing Packages
> team as a build-dependency of slic3r-prusa.

4 years ago the project was declared as not actively maintained:

* 
https://github.com/memononen/nanosvg/commit/25241c5a8f8451d41ab1b02ab2d865b01600d949

Bug#1040758: bullseye-pu: package spip/3.2.11-3+deb11u9

[David Prévot]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: s...@packages.debian.org
Control: affects -1 + src:spip

This issue is similar to #1040756 in bookworm.

Another upstream release fixed a security issue. It introduces some
factorisation adding two more clean up in sessions. We agreed with the
security team that this don’t warrant a DSA.

https://blog.spip.net/Mise-a-jour-de-maintenance-et-securite-sortie-de-SPIP-4-2-4-SPIP-4-1-11.html

The 3.2 branch is not maintained upstream anymore, but the patches have
been cherry-picked directly from the 4.1 branch, except for the first
one that needed some slight editing. Also, I’ve already deployed the
proposed package on a server providing over 30 SPIP websites.

[ 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 (old)stable
  [x] the issue is verified as fixed in unstable

Thanks in advance.

Regards,

taffit
diff -Nru spip-3.2.11/debian/changelog spip-3.2.11/debian/changelog
--- spip-3.2.11/debian/changelog	2023-06-11 15:47:39.0 +0200
+++ spip-3.2.11/debian/changelog	2023-07-08 20:38:26.0 +0200
@@ -1,3 +1,11 @@
+spip (3.2.11-3+deb11u9) bullseye; urgency=medium
+
+  * Backport security fix from 4.1.11
+- use an auth_desensibiliser_session() function to centralize extended
+  authentification data filtering.
+
+ -- David Prévot   Sat, 08 Jul 2023 20:38:26 +0200
+
 spip (3.2.11-3+deb11u8) bullseye; urgency=medium
 
   * Backport security fixes from 4.1.10
diff -Nru spip-3.2.11/debian/patches/0056-security-Utiliser-une-fonction-d-di-e-pour-nettoyer-.patch spip-3.2.11/debian/patches/0056-security-Utiliser-une-fonction-d-di-e-pour-nettoyer-.patch
--- spip-3.2.11/debian/patches/0056-security-Utiliser-une-fonction-d-di-e-pour-nettoyer-.patch	1970-01-01 01:00:00.0 +0100
+++ spip-3.2.11/debian/patches/0056-security-Utiliser-une-fonction-d-di-e-pour-nettoyer-.patch	2023-07-08 20:38:18.0 +0200
@@ -0,0 +1,69 @@
+From: Cerdic 
+Date: Mon, 3 Jul 2023 10:23:02 +0200
+Subject: =?utf-8?q?security=3A_Utiliser_une_fonction_d=C3=A9di=C3=A9e_pour_?=
+ =?utf-8?q?nettoyer_les_donn=C3=A9es_d=E2=80=99auteur_lors_de_la_pr=C3=A9pa?=
+ =?utf-8?q?ration_d=E2=80=99une_session?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+- Ajout d’une fonction `auth_desensibiliser_session()` pour desensibiliser une ligne auteur,
+- qu'on utilise lors de la preparation d'une session
+- et dans informer_login
+
+Refs:  spip-team/securite#4847
+(cherry picked from commit 2e4d6273cee8ec63ce7f565a73262a8aae70b7bb)
+
+Origin: backport, https://git.spip.net/spip/spip/commit/f1d2351c90a6127cab354be1647662ec5e941676
+---
+ ecrire/inc/auth.php | 23 ++-
+ 1 file changed, 18 insertions(+), 5 deletions(-)
+
+diff --git a/ecrire/inc/auth.php b/ecrire/inc/auth.php
+index 12fc4ce..cb61446 100644
+--- a/ecrire/inc/auth.php
 b/ecrire/inc/auth.php
+@@ -249,11 +249,7 @@ function auth_init_droits($row) {
+ 	$GLOBALS['visiteur_session'] = array_merge((array)$GLOBALS['visiteur_session'], $row);
+ 
+ 	// au cas ou : ne pas memoriser les champs sensibles
+-	unset($GLOBALS['visiteur_session']['pass']);
+-	unset($GLOBALS['visiteur_session']['htpass']);
+-	unset($GLOBALS['visiteur_session']['alea_actuel']);
+-	unset($GLOBALS['visiteur_session']['alea_futur']);
+-	unset($GLOBALS['visiteur_session']['ldap_password']);
++	$GLOBALS['visiteur_session'] = auth_desensibiliser_session($GLOBALS['visiteur_session']);
+ 
+ 	// creer la session au besoin
+ 	if (!isset($_COOKIE['spip_session'])) {
+@@ -310,6 +306,22 @@ function auth_init_droits($row) {
+ 	return ''; // i.e. pas de pb.
+ }
+ 
++/**
++ * Enlever les clés sensibles d'une ligne auteur
++ * @param array $auteur
++ * @return array
++ */
++function auth_desensibiliser_session(array $auteur) {
++	$cles_sensibles = ['pass', 'htpass', 'alea_actuel', 'alea_futur', 'ldap_password', 'backup_cles'];
++	foreach ($cles_sensibles as $cle) {
++		if (isset($auteur[$cle])) {
++			unset($auteur[$cle]);
++		}
++	}
++
++	return $auteur;
++}
++
+ /**
+  * Retourne l'url de connexion
+  *
+@@ -490,6 +502,7 @@ function auth_informer_login($login, $serveur = '') {
+ 	}
+ 
+ 	$prefs = unserialize($row['prefs']);
++	$row = auth_desensibiliser_session($row);
+ 	$infos = array(
+ 		'id_auteur' => $row['id_auteur'],
+ 		'login' => $row['login'],
diff -Nru spip-3.2.11/debian/patches/0057-security-Utiliser-auth_desensibiliser_session-aussi-.patch spip-3.2.11/debian/patches/0057-security-Utiliser-auth_desensibiliser_session-aussi-.patch
--- spip-3.2.11/debian/patches/0057-security-Utiliser-auth_desensibiliser_session-aussi-.patch	1970-01-01 01:00:00.0 +0100
+++ spip-3.2.11/debian/patches/0057-security-Utiliser-auth_desensibiliser_session-aussi-.patch	2023-07-08 20:38:18.0 +0200
@@ -0,0 +1,69 @@

Bug#1040757: dose: (W)CudfAdd: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe

[Paul Wise]

Package: qa.debian.org
Severity: important
User: qa.debian@packages.debian.org
Usertags: dose
X-Debbugs-CC: Ralf Treinen 

The dose cron job has been producing these errors since 2023-07-02:

   Subject: Cron  nice -15 flock -n 
/srv/qa.debian.org/lock/dose-job /srv/qa.debian.org/data/cronjobs/dose-job
   
   (W)CudfAdd: package ncurses-base:amd64 (= 6.4-4) is not associate with an 
integer in the given universe
   The applications raised this exception : Not_found
   (W)CudfAdd: package ncurses-base:arm64 (= 6.4-4) is not associate with an 
integer in the given universe
   The applications raised this exception : Not_found
   (W)CudfAdd: package ncurses-base:armel (= 6.4-4) is not associate with an 
integer in the given universe
   The applications raised this exception : Not_found
   (W)CudfAdd: package ncurses-base:armhf (= 6.4-4) is not associate with an 
integer in the given universe
   The applications raised this exception : Not_found
   (W)CudfAdd: package ncurses-base:i386 (= 6.4-4) is not associate with an 
integer in the given universe
   The applications raised this exception : Not_found
   (W)CudfAdd: package ncurses-base:mips64el (= 6.4-4) is not associate with an 
integer in the given universe
   The applications raised this exception : Not_found
   (W)CudfAdd: package ncurses-base:mipsel (= 6.4-4) is not associate with an 
integer in the given universe
   The applications raised this exception : Not_found
   (W)CudfAdd: package ncurses-base:ppc64el (= 6.4-4) is not associate with an 
integer in the given universe
   The applications raised this exception : Not_found
   (W)CudfAdd: package ncurses-base:s390x (= 6.4-4) is not associate with an 
integer in the given universe
   The applications raised this exception : Not_found
   
-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1040756: bookworm-pu: package spip/4.1.9+dfsg-1+deb12u2

[David Prévot]

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

Another upstream release fixed a security issue. It introduces some
factorisation adding two more clean up in sessions. We agreed with the
security team that this don’t warrant a DSA.

https://blog.spip.net/Mise-a-jour-de-maintenance-et-securite-sortie-de-SPIP-4-2-4-SPIP-4-1-11.html

The 4.1 branch is mostly in maintenance mode, and the patches have been
cherry-picked directly from upstream.

[ 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 (old)stable
  [x] the issue is verified as fixed in unstable

Thanks in advance.

Regards,

taffit
diff -Nru spip-4.1.9+dfsg/debian/changelog spip-4.1.9+dfsg/debian/changelog
--- spip-4.1.9+dfsg/debian/changelog	2023-06-11 15:38:54.0 +0200
+++ spip-4.1.9+dfsg/debian/changelog	2023-07-08 20:29:04.0 +0200
@@ -1,3 +1,11 @@
+spip (4.1.9+dfsg-1+deb12u2) bookworm; urgency=medium
+
+  * Backport security fix from 4.1.11
+- use an auth_desensibiliser_session() function to centralize extended
+  authentification data filtering.
+
+ -- David Prévot   Sat, 08 Jul 2023 20:29:04 +0200
+
 spip (4.1.9+dfsg-1+deb12u1) bookworm; urgency=medium
 
   [ David Prévot ]
diff -Nru spip-4.1.9+dfsg/debian/patches/0009-security-Utiliser-une-fonction-d-di-e-pour-nettoyer-.patch spip-4.1.9+dfsg/debian/patches/0009-security-Utiliser-une-fonction-d-di-e-pour-nettoyer-.patch
--- spip-4.1.9+dfsg/debian/patches/0009-security-Utiliser-une-fonction-d-di-e-pour-nettoyer-.patch	1970-01-01 01:00:00.0 +0100
+++ spip-4.1.9+dfsg/debian/patches/0009-security-Utiliser-une-fonction-d-di-e-pour-nettoyer-.patch	2023-07-08 20:25:35.0 +0200
@@ -0,0 +1,69 @@
+From: Cerdic 
+Date: Mon, 3 Jul 2023 10:23:02 +0200
+Subject: =?utf-8?q?security=3A_Utiliser_une_fonction_d=C3=A9di=C3=A9e_pour_?=
+ =?utf-8?q?nettoyer_les_donn=C3=A9es_d=E2=80=99auteur_lors_de_la_pr=C3=A9pa?=
+ =?utf-8?q?ration_d=E2=80=99une_session?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+- Ajout d’une fonction `auth_desensibiliser_session()` pour desensibiliser une ligne auteur,
+- qu'on utilise lors de la preparation d'une session
+- et dans informer_login
+
+Refs:  spip-team/securite#4847
+(cherry picked from commit 2e4d6273cee8ec63ce7f565a73262a8aae70b7bb)
+
+Origin: upstream, https://git.spip.net/spip/spip/commit/f1d2351c90a6127cab354be1647662ec5e941676
+---
+ ecrire/inc/auth.php | 23 ++-
+ 1 file changed, 18 insertions(+), 5 deletions(-)
+
+diff --git a/ecrire/inc/auth.php b/ecrire/inc/auth.php
+index 85d5ab1..6185aff 100644
+--- a/ecrire/inc/auth.php
 b/ecrire/inc/auth.php
+@@ -250,11 +250,7 @@ function auth_init_droits($row) {
+ 	$GLOBALS['visiteur_session'] = array_merge((array)$GLOBALS['visiteur_session'], $row);
+ 
+ 	// au cas ou : ne pas memoriser les champs sensibles
+-	unset($GLOBALS['visiteur_session']['pass']);
+-	unset($GLOBALS['visiteur_session']['htpass']);
+-	unset($GLOBALS['visiteur_session']['alea_actuel']);
+-	unset($GLOBALS['visiteur_session']['alea_futur']);
+-	unset($GLOBALS['visiteur_session']['ldap_password']);
++	$GLOBALS['visiteur_session'] = auth_desensibiliser_session($GLOBALS['visiteur_session']);
+ 
+ 	// creer la session au besoin
+ 	if (!isset($_COOKIE['spip_session'])) {
+@@ -314,6 +310,22 @@ function auth_init_droits($row) {
+ 	return ''; // i.e. pas de pb.
+ }
+ 
++/**
++ * Enlever les clés sensibles d'une ligne auteur
++ * @param array $auteur
++ * @return array
++ */
++function auth_desensibiliser_session(array $auteur) {
++	$cles_sensibles = ['pass', 'htpass', 'alea_actuel', 'alea_futur', 'ldap_password', 'backup_cles'];
++	foreach ($cles_sensibles as $cle) {
++		if (isset($auteur[$cle])) {
++			unset($auteur[$cle]);
++		}
++	}
++
++	return $auteur;
++}
++
+ /**
+  * Retourne l'url de connexion
+  *
+@@ -480,6 +492,7 @@ function auth_informer_login($login, $serveur = '') {
+ 	}
+ 
+ 	$prefs = @unserialize($row['prefs']);
++	$row = auth_desensibiliser_session($row);
+ 	$infos = [
+ 		'id_auteur' => $row['id_auteur'],
+ 		'login' => $row['login'],
diff -Nru spip-4.1.9+dfsg/debian/patches/0010-security-Utiliser-auth_desensibiliser_session-aussi-.patch spip-4.1.9+dfsg/debian/patches/0010-security-Utiliser-auth_desensibiliser_session-aussi-.patch
--- spip-4.1.9+dfsg/debian/patches/0010-security-Utiliser-auth_desensibiliser_session-aussi-.patch	1970-01-01 01:00:00.0 +0100
+++ spip-4.1.9+dfsg/debian/patches/0010-security-Utiliser-auth_desensibiliser_session-aussi-.patch	2023-07-08 20:25:35.0 +0200
@@ -0,0 +1,69 @@
+From: Matthieu Marcillaud 
+Date: Mon, 3 Jul 2023 10:55:19 +0200
+Subject: =?utf-8?q?security=3A_Utiliser_=60auth=5Fdesensibiliser=5Fsession?=
+ 

Bug#1040755: ftbfs in rygel with meson 1.2.0 rc2

[Eli Schwartz]

Source: rygel
Version: 0.42.3-2
Severity: important
Tags: ftbfs upstream
Forwarded: https://gitlab.gnome.org/GNOME/rygel/-/issues/230
X-Debbugs-CC: hel...@subdivi.de


During an archive rebuild against the release candidate for meson in
experimental, rygel failed to build from source with the following log
excerpt:

```
cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson setup ..
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc
--localstatedir=/var --libdir=
lib/x86_64-linux-gnu -Dsystemd-user-units-dir=/usr/lib/systemd/user
-Dapi-docs=true -Dintrospection=disabled -Dexamples=false
-Dplugins=external,gst-launch,media-export
,mpris,playbin,ruih,tracker3
The Meson build system
Version: 1.2.0.rc2
Source dir: /<>
Build dir: /<>/obj-x86_64-linux-gnu
Build type: native build

../meson.build:1:0: ERROR: Unexpected "[provides]" section, did you mean
"[provide]"?
```

Previous versions of meson silently ignored this invalid section, but
the release candidate complains about it.

This is an upstream bug as the file did not do what it was expected to
do, but it prevents building in Debian. The simplest solution is to
delete the .wrap files from the subprojects/ directory, since Debian
does not build this project with vendored dependencies.

-- 
Eli Schwartz

Bug#1040620: quickplot will not read input file

[Brent Roman]

Hi Lance,

I'd been holding off installing Debian 12 because I routinely rely on 
X11 for remote access.
Sorry to hear the the X11<->Wayland wrapper is not quite ready for prime 
time.


Linus was, as usual, spot on in his lampooning the lack of binary 
compatibility in Linux user space.
While it might be understandable that not all Fedora/Redhat binaries run 
under Ubuntu/Debian, it's
inexcusable that old binaries will not run on the same distro's latest 
release on the same arch.

This the main reason why Linux can't break into the mainstream desktop apps.

For Debian 11, fixing quickplot will likely involve simply comparing 
libsndfile-1.0.28 with Debian's 1.0.31 to identify the "breaking change" 
and modifying either quickplot or sndfile to fix the problem.


I'll send you a patch to quickplot in the coming weeks if I end up 
changing it, leaving you to wrestle with the GTK3 issues unique to 
Debian 12.


- brent

P.S.  Are you aware of any other graphing package that accepts ASCII 
numeric input from a pipe?

(i.e. a viable alternative to quickplot?)


Lance Arsenault wrote:

Hi Brent,

5.  I forgot to mention.  I'm using Debian 12 with GNOME and on that, 
both libsndfile and GTK3 break quickplot; though "apt install 
quickplot" works, but it installs a broken program.  I can't test your 
fix very easily on my system.  I'd rather refactor quickplot than 
downgrade my OS. (ya, I know, VMs, but I worry about slow displays and 
lots of unknowns ...; and VMs turn me off in general) GTK3 uses a 
Wayland Display (on Debain 12 GNOME) and the X11/wayland wrapper stuff 
seems to be broken. You see, quickplot uses raw libX11 code to get 
more speed than that is gotten from the cairo/x11 wrapper crap in GDK 
(GTK3), on older systems.   My refactoring will use WaylandDisplay and 
not libX11, and that promises to be much faster than libX11 ever was. 
  Wayland should be better and faster, but it has been a long time 
coming; and has totally broken lots of my code. GdkWaylandDisplay 
(GTK3 sub-library) is now giving me pain... I feel that the GTK3 and 
GTK4 developers are sadists.


Linus is talking about my pain in this video:
https://www.youtube.com/watch?v=Pzl1B7nB9Kc


Thanks again for your help.  Very helpful feedback.

cheers
lance


On Sun, Jul 9, 2023 at 1:29 PM Lance Arsenault > wrote:



Hi Brent,

1. First thank you for submitting this bug ticket.  I'm not sure
if I have write access to the debian bug system, but we'll see.

2.  I'm the sole downstream developer of quickplot.  quickplot as
distributed by Debian GNU/Linux was pretty cool stuff.  It
currently has some package dependencies that have broken it.  In
particular, libsndfile and GTK3.  And so, quickplot is in need of
refactoring, maybe dropping the libsndfile dependency and removing
deprecated GTK3 API usage.  As it turns out, I just happened to
have released (alpha) a much larger software package that kind-of
needs a "quickplot" like tool to help my current work.  So I need
to fix quickplot for my own use.  I have not used it in a while.

3. I looked at your bio.  We seem to have a little bit of overlap
in professional interests,  my CV is at
http://107.191.96.171/cv.html , sorry it's http without https yet.

4. My new alpha software package is at
https://github.com/lanceman2/quickstream , you might find it
interesting.

cheers
lance


On Fri, Jul 7, 2023 at 11:30 PM Brent Roman mailto:br...@mbari.org>> wrote:
>
> Package: quickplot
> Version: 1.0.1~rc-1+b3
>
> Any attempt to read an input file or pipe fails with the error
message:
>
> Failed to read file /home/brent/quickplot/plot.dat: lseek() failed
>
> A workaround is the link the quickplot binary with the upstream
> libsndfile-1.0.28
> rather than the libsndfile-1.0.31 packaged with Debian 11
>
> For instance, after installing libsndfile-1.0.28 in /usr/local/lib,
> quickplot
> will work if started with this shell script:
>
> #!/bin/sh #force linkage with our local version of libsndfile
> # (1.0.28 rather than Debian's 1.0.31)
> LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH exec
/usr/bin/quickplot "$@"
>
> I am using Debian 11 on x86 (tested both 32 or 64-bit) with various
> Linux 5.x kernels.
>
> --
>   Brent Roman                                   MBARI
>   Software Engineer               Tel: (831) 775-1808
>   mailto:br...@mbari.org 
http://www.mbari.org/~brent
>




--
 Brent Roman   MBARI
 Software Engineer   Tel: (831) 775-1808
 mailto:br...@mbari.org  http://www.mbari.org/~brent

Bug#1040754: chromium: Enable GTK4 backend to use IME for Wayland window

[yokota]

Package: chromium
Version: 114.0.5735.198-1
Severity: wishlist
X-Debbugs-Cc: yokota.h...@gmail.com

Dear Chromium Maintainer,

Current Debian Chromium enables GTK3 backend only, but I want GTK4 backend to
use IMEs for Wayland window.
See upstream issue tracker for technical details:
  https://bugs.chromium.org/p/chromium/issues/detail?id=1422087

--
YOKOTA

Bug#1040753: FTBFS in gupnp-tools with meson 1.2.0 rc2

[Eli Schwartz]

Source: gupnp-tools
Version: 0.12.0-2
Severity: important
Tags: ftbfs upstream fixed-upstream
Forwarded: https://gitlab.gnome.org/GNOME/gupnp-tools/-/issues/26
X-Debbugs-CC: hel...@subdivi.de


During an archive rebuild against the release candidate for meson in
experimental, gupnp-tools failed to build from source with the following
log excerpt:

```
cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson setup ..
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc
--localstatedir=/var --libdir=
lib/x86_64-linux-gnu
The Meson build system
Version: 1.2.0.rc2
Source dir: /<>
Build dir: /<>/obj-x86_64-linux-gnu
Build type: native build

../meson.build:1:0: ERROR: Unexpected "[provides]" section, did you mean
"[provide]"?
```

Previous versions of meson silently ignored this invalid section, but
the release candidate complains about it.

This is an upstream bug as the file did not do what it was expected to
do, but it prevents building in Debian. The simplest solution is to
delete the .wrap files from the subprojects/ directory, since Debian
does not build this project with vendored dependencies.

It is also fixed upstream in git.


-- 
Eli Schwartz

Bug#1040752: marco: Window titles in mate-panel/tasklist (libwnck) show only " (as superuser)"

[Mike Gabriel]

Package: marco
Version: 1.26.1-3
Severity: normal

MATE's window manager does not show the correct window title if the  
window is owned by superuser root: Window titles in some situations  
only show " (as superuser)".





--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpZRVQmp81dk.pgp
Description: Digitale PGP-Signatur

Bug#1040638: Bothersome message every day from cron

[Frédéric Brière]

(Klaus, did you really mean to close this bug report with your last
message?  I'll go ahead and reopen it since I'm also affected by this
bug.)


>From what I understand, this bug affects entries of the form `/dev/md0`
in `mdadm.conf`, and was introduced by commit 84d969be, which now always
looks for `/dev/md/$(basename)`, resulting in failures when attempting
to access the non-existent `/dev/md/md0`.

(Until this is resolved, a simple `../md0` symlink seems to do the job
as a temporary fix.)

Bug#980288: mate-desktop: Please add gnome-system-tools dependency

[Mike Gabriel]

Control: reassign -1 mate-desktop-environment-extras
Control: close -1
Control: fixed -1 1.20.0+5

Hi Jean-Philippe,

On  So 17 Jan 2021 21:22:56 CET, Jean-Philippe MENGUAL wrote:


Hi Mike,

Le 17/01/2021 à 20:52, Mike Gabriel a écrit :

Hi Jean-Philippe,

On  So 17 Jan 2021 12:16:09 CET, Jean-Philippe MENGUAL wrote:



I think we should have this again via the package gnome-system-tools as
dependency or recommended. Would be great! I know this is old but still
compatible with mate


I agree. Do you rather see this recommendation in  
mate-desktop-environment or mate-desktop-environment-extras?


As -extras seems to contains utilities less related to the core of  
MATE, I would suggest to add this dependency there. Less invasive  
but makes easy the installation of these tools.



Best regards,


Mike


Found this bug still being open for src:mate-desktop. Closing it here.  
The issue has been resolved in src:mate-desktop-environment since  
1.20.0+5.


Greets,
Mike


--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpqWkaLd9ETf.pgp
Description: Digitale PGP-Signatur

Bug#1040751: ITP: nanosvg -- simple svg parsing library

[Chow Loong Jin]

Package: wnpp
Severity: wishlist
Owner: Chow Loong Jin 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: nanosvg
  Version : 0~git20221204.1.9da543e
  Upstream Contact: https://github.com/memononen/nanosvg/issues
* URL : https://github.com/memonenen/nanosvg
* License : zlib
  Programming Lang: C
  Description : simple svg parsing library

NanoSVG is a simple stupid single-header-file SVG parse. The output of
the parser is a list of cubic bezier shapes.

The library suits well for anything from rendering scalable icons in
your editor application to prototyping a game.

NanoSVG supports a wide range of SVG features, but something may be
missing, feel free to create a pull request!

The shapes in the SVG images are transformed by the viewBox and
converted to specified units. That is, you should get the same looking
data as your designed in your favorite app.

NanoSVG can return the paths in few different units. For example if you
want to render an image, you may choose to get the paths in pixels, or
if you are feeding the data into a CNC-cutter, you may want to use
millimeters.

The units passed to NanoSVG should be one of: 'px', 'pt', 'pc' 'mm',
'cm', or 'in'. DPI (dots-per-inch) controls how the unit conversion is
done.

If you don't know or care about the units stuff, "px" and 96 should get
you going.


I will be packaging this library under the Debian 3-D Printing Packages
team as a build-dependency of slic3r-prusa.

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#1040750: please add loong64 arch support in lintian

[xiao sheng wen]

Package: lintian
Version: 2.116.3
Severity: wishlist
X-Debbugs-Cc: wuxiaot...@loongson.cn, atzli...@sina.com, 
debian-chinese...@lists.debian.org

Hi,

   I hope lintian can support new loong64 arch[1].

This is a example info for loong64 arch when run lintian:

E: png2svg: binary-from-other-architecture [usr/bin/png2svg]
W: png2svg: unknown-architecture loong64
W: png2svg-dbgsym: unknown-architecture loong64
W: png2svg changes: unknown-architecture loong64
W: png2svg buildinfo: unknown-architecture loong64

[1] https://wiki.debian.org/Ports/loong64

Thanks!

肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB

-- System Information:
Debian Release: 12.0
merged-usr: no
Architecture: loong64 (loongarch64)

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

Versions of packages lintian depends on:
ii  binutils2.40.50.20230510-1.ulb1
ii  bzip2   1.0.8-6
ii  diffstat1.65-1
ii  dpkg1.21.9
ii  dpkg-dev1.21.21
ii  file1:5.44-3
ii  gettext 0.21-12
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.35-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.21
ii  libemail-address-xs-perl1.05-1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.003+ds-1
ii  libsereal-encoder-perl  5.003+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2
ii  libtext-levenshteinxs-perl  0.03-5
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.16-1
ii  libwww-perl 6.68-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzop1.04-2
ii  man-db  2.11.2-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-7
ii  plzip [lzip-decompressor]   1.10-5
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.1-0.2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#1039873: pam-auth-update --disable does not work

[duck]

Quack,

Sorry for the lag, I'm deep in Bookworm upgrades :-).

On 2023-06-30 02:03, Sam Hartman wrote:


I just tried:

* pam-auth-update --enable mkhomedir

* confirm pam_mkhomedir is in the config
p
* pam-auth-update --disable mkhomedir

* Confirm that it is not in the config.


Indeed it works… for mkhomedir, but still not for sss.

Also the fact that used interactively it does not remember my setting 
from the command line is not right.


Let's suppose I borked the config, then --remove which really works and 
reset the config clean (at least for the pam_sss lines), then --enable 
followed by --remove should work.


I could reassign to libpam-sss but I did not see anything weird in 
/usr/share/pam-configs/sss, so I can only guess there's a problem with 
the matching when removing the lines.


I'll try to have a deeper look when I'm clear of migrations.

\_o<

--
Marc Dequènes

Bug#1040749: rifle: imv from renameutils breaks image opening

[Christopher Bock]

Package: ranger
Version: 1.9.3-5
Severity: minor

I was wondering for a while now why i couldn't open images from ranger.

cb@asterix ~ % grep imv /etc/ranger/config/rifle.conf
mime ^image, has imv,   X, flag f = imv -- "$@"
cb@asterix ~ % ls -fla ~/.config/ranger
total 10
drwxr-xr-x   2 cb cb   2 Jul 10 03:52 .
drwxr-xr-x 119 cb cb 164 Jul 10 03:52 ..
cb@asterix ~ % rifle -l ~/snips/maim_20230710-032739.png
0::f:imv -- "$@"
1::f:pqiv -- "$@"
2::f:sxiv -- "$@"
3::f:feh -- "$@"
4::f:gpicview -- "$@"
5::f:gimp -- "$@"
11:wallpaper::feh --bg-scale "$1"
12:wallpaper::feh --bg-tile "$1"
13:wallpaper::feh --bg-center "$1"
14:wallpaper::feh --bg-fill "$1"
15:open::xdg-open -- "$@"
16:open::open -- "$@"
17:::ask
18:editor::${VISUAL:-$EDITOR} -- "$@"
19:pager::"$PAGER" -- "$@"
20:trash::mkdir -p -- ${XDG_DATA_DIR:-$HOME/.ranger}/ranger-trash;
mv -- "$@" ${XDG_DATA_DIR:-$HOME/.ranger}/ranger-trash
cb@asterix ~ % dpkg -S /usr/bin/imv
renameutils: /usr/bin/imv

And after looking at the description of 'imv' it becomes clear that we
should use the wrapper /usr/libexec/imv/imv instead.

cb@asterix ~ % cp /etc/ranger/config/rifle.conf
~/.config/ranger/rifle.conf cb@asterix ~ % vim
~/.config/ranger/rifle.conf cb@asterix ~ % grep imv-folder
~/.config/ranger/rifle.conf mime ^image, has imv-x11, X, flag f =
/usr/libexec/imv/imv -- "$@" cb@asterix ~ % rifle -l
~/snips/maim_20230710-032739.png 0::f:/usr/libexec/imv/imv -- "$@"
1::f:pqiv -- "$@"
2::f:sxiv -- "$@"
3::f:feh -- "$@"
4::f:gpicview -- "$@"
5::f:gimp -- "$@"
11:wallpaper::feh --bg-scale "$1"
12:wallpaper::feh --bg-tile "$1"
13:wallpaper::feh --bg-center "$1"
14:wallpaper::feh --bg-fill "$1"
15:open::xdg-open -- "$@"
16:open::open -- "$@"
17:::ask
18:editor::${VISUAL:-$EDITOR} -- "$@"
19:pager::"$PAGER" -- "$@"
20:trash::mkdir -p -- ${XDG_DATA_DIR:-$HOME/.ranger}/ranger-trash;
mv -- "$@" ${XDG_DATA_DIR:-$HOME/.ranger}/ranger-trash

And now it works even when i uninstall imv again \o/.

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

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

Versions of packages ranger depends on:
ii  python3 3.11.2-1+b1
ii  sensible-utils  0.0.20

Versions of packages ranger recommends:
ii  file 1:5.44-3
ii  less 590-2
ii  python3-chardet  5.1.0+dfsg-2
ii  w3m-img  0.5.3+git20230121-2

Versions of packages ranger suggests:
ii  atool 0.39.0-12
ii  caca-utils0.99.beta20-3
ii  elinks0.16.1.1-4
ii  highlight 3.41-2+b6
ii  lynx  2.9.0dev.12-1
ii  mediainfo 23.06-1
ii  mupdf-tools   1.22.1+ds1-1+b1
ii  poppler-utils 22.12.0-2+b1
ii  python3-pygments  2.15.1+dfsg-1
ii  sudo  1.9.13p3-3
pn  unoconv   
ii  w3m   0.5.3+git20230121-2

-- no debconf information

Bug#1040708: Acknowledgement (Wrong database scheme for postgresql)

[duck]

I forgot to say it can be reproduced with a fresh install of 
mailman3-full.


--
Marc Dequènes

Bug#1040748: ftbfs in pycairo with meson 1.2.0 rc2

[Eli Schwartz]

Source: pycairo
Version: 1.24.0-1
Severity: important
Tags: ftbfs
X-Debbugs-CC: hel...@subdivi.de


During an archive rebuild against the release candidate for meson in
experimental, pycairo failed to build from source with the following log
excerpt:


```
   dh_auto_install -O--buildsystem=meson
cd obj-x86_64-linux-gnu && DESTDIR=/<>/debian/tmp
LC_ALL=C.UTF-8 ninja install
[0/1] Installing files.
Compiling
'/<>/debian/tmp/usr/lib/python3/dist-packages/cairo/__init__.py'...
[...]
Running custom install script '/usr/bin/python3
/<>/obj-x86_64-linux-gnu/meson-private/pycompile.py
python-3.11-installed.json 0'
[...]
   dh_missing -O--buildsystem=meson
dh_missing: warning:
usr/lib/python3/dist-packages/cairo/__pycache__/__init__.cpython-311.pyc
exists in debian/tmp but is not installed to anywhere
dh_missing: error: missing files, aborting
[...]
make: *** [debian/rules:6: binary] Error 25
```


This fails with the release candidate, but does not fail against the
stable release of meson. The underlying cause is an additional feature
of meson:

https://mesonbuild.com/Release-notes-for-1-2-0.html#python-module-can-now-compile-bytecode

If this file is not desired in the debian package, please specify your
preferred value for this meson setting. For example, to avoid compiling
bytecode as part of `meson install`, you could setup the build system
with the `-Dpython.bytecompile=-1` option.


-- 
Eli Schwartz

Bug#1040747: dwz: makes wlgreet FTBFS with "Couldn't find DIE"

[duck]

Package: dwz
Version: 0.15-1


Quack,

I've now disabled dh_dwz but the original build log can be found here:
  https://salsa.debian.org/debian/wlgreet/-/jobs/4401335

The package is awaiting NEW but sources are on Salsa if you wish to 
experiment.


I honestly have no idea how dwz works so I cannot help with the code but 
tell me if you need me to make some tests.


Regards.
\_o<

--
Marc Dequènes

Bug#1040746: ftbfs in gnome-photos with recent babl

[Jeremy Bícha]

On Sun, Jul 9, 2023 at 9:57 PM Eli Schwartz  wrote:
> This *should* fail in all versions of meson, and occurs because of a
> renamed pkg-config file in libbabl-dev. Upstream adapted to this rename in:
>
> https://gitlab.gnome.org/GNOME/gnome-photos/-/merge_requests/248
> https://gitlab.gnome.org/GNOME/gnome-photos/-/merge_requests/261
>
> Both merge requests are available when upgrading to 44.0, or
> alternatively in 43.1 (a bugfix release containing only this change)

Yes, that issue is already fixed in gnome-photos 44.0-2 in
Experimental. However, gnome-photos now fails to build with the
version of gegl in Unstable.

https://gitlab.gnome.org/GNOME/gnome-photos/-/issues/214

Thank you,
Jeremy Bícha

Bug#1026335: RFS: carl9170fw/1.9.9-450-gad1c721-1 [ITP] -- firmware for AR9170 USB wireless adapters

[John Scott]

Control: retitle -1 RFS: carl9170fw [ITP] -- firmware for AR9170 USB wireless 
adapters

Dear mentors,

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

 * Package name : carl9170fw
   Version  : 1.9.9-450-gad1c721-1
   Upstream contact : linux-wirel...@vger.kernel.org
 * URL  : 
https://wireless.wiki.kernel.org/en/users/Drivers/carl9170.fw
 * License  : many, but mostly GPL-2.0-or-later or GPL-2.0-only
 * Vcs  : https://salsa.debian.org/kernel-team/carl9170fw
   Section  : kernel

The source builds the following binary packages:

  firmware-carl9170 - firmware for AR9170 USB wireless adapters

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/carl9170fw/carl9170fw_1.9.9-450-gad1c721-1.dsc

This is a package that's very dear to my heart and which has gone through a 
couple rounds of review already, so I hope to make it great.

carl9170 is a fully libre driver and firmware combo for particular USB wireless 
adapters. carl9170 is already in firmware-linux-free, but this new source 
package is special: it builds the firmware from source using a cross toolchain 
that I've also packaged. Because this is firmware that runs on the CPU inside 
the Wi-Fi adapter instead of on the Debian host, it's an Arch: all package 
despite being written in C.

Because of the situation with this package shipping a file that's already in 
firmware-linux-free, this initial upload will be practically unusable: the only 
goal is to clear NEW so that the second upload (which will have appropriate 
Breaks+Replaces) can be made on a predictable timeframe. (I have, however, 
manually tested that the built firmware works.) I wonder, should I add a 
temporary Conflicts: firmware-linux-free to this initial upload since they will 
not be co-installable? I've decided not to, but let me know if I should.

I'm not very good with Git, so this upload is not in the VCS right now. I'll 
sort that out once we're uploading the package to NEW.

Also, per discussion on #debian-mentors and a recent re-reading of Debian 
Policy, I've added Built-Using fields because carl9170 is GPL and statically 
links in other libraries.

P.S. If any of my seemingly-omniscient regular sponsors are concerned, I'm 
about to fix the FTBFS in the sibling package ath9k_htc, so do not be alarmed 
by that.


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


smime.p7s
Description: S/MIME cryptographic signature

Bug#1040621: binutils-mipsen: missing shlib dependencies

[YunQiang Su]

Adam Borowski  于2023年7月8日周六 11:36写道：
>
> Source: binutils-mipsen
> Version: 10+c3
> Severity: grave
> Justification: renders package unusable
>
> mips* binutils tools crash on startup:
> $ mips64el-linux-gnuabi64-as
> mips64el-linux-gnuabi64-as: error while loading shared libraries: 
> libsframe.so.0: cannot open shared object file: No such file or directory
>
> The culprit is:
> $ ldd /usr/lib/x86_64-linux-gnu/libopcodes-2.40.50-mips64el.20230611.so
> libsframe.so.0 => not found
> which would be prevented by package relationships/DAK/etc, had the
> dependency on libsframe be included in binaries you produce.
>

It seems that just rebuilding can solve this problem.
I will upload a new version.

>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
> (120, 'experimental'), (1, 'experimental-debug')
> merged-usr: no
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.4.2-00035-g5920c330f094 (SMP w/64 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)



-- 
YunQiang Su

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Ben Finney]

On 26-Nov-2022, Damyan Ivanov wrote:

> There are more (minor) problems with the copyright summary. I will create
> issues/PRs about them for easier tracking (one already created - #7711).

Upstream issue #7711 has been closed as resolved, by merging some changes
to the copyright information.

https://github.com/endless-sky/endless-sky/pull/7881>

Does that resolve the copyright issues for this Debian bug report? What
remains to be done before we can release an updated package?

-- 
 \ “We can't depend for the long run on distinguishing one |
  `\ bitstream from another in order to figure out which rules |
_o__)   apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1040323: android-libnativehelper: undeclared file conflict with android-libnativehelper-dev from bullseye

[Roger Shimizu]

control: tag -1 +pending

uploaded fix to bullseye-backport
pending for NEW queue check

Bug#1040746: ftbfs in gnome-photos with recent babl

[Eli Schwartz]

Source: gnome-photos
Version: 43.0-2
Severity: serious
Tags: ftbfs
X-Debbugs-CC: hel...@subdivi.de


During an archive rebuild against the release candidate for meson in
experimental, gnome-photos failed to build from source with the
following log excerpt:

```
../meson.build:155:11: ERROR: Dependency "babl" not found, tried pkgconfig
dh_auto_configure: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8
meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr
--sysconfdir=/etc --localstate
dir=/var --libdir=lib/x86_64-linux-gnu -Ddogtail=false
-Dinstalled_tests=true returned exit code 1
make[1]: *** [debian/rules:12: override_dh_auto_configure] Error 25
```

This *should* fail in all versions of meson, and occurs because of a
renamed pkg-config file in libbabl-dev. Upstream adapted to this rename in:

https://gitlab.gnome.org/GNOME/gnome-photos/-/merge_requests/248
https://gitlab.gnome.org/GNOME/gnome-photos/-/merge_requests/261

Both merge requests are available when upgrading to 44.0, or
alternatively in 43.1 (a bugfix release containing only this change)

-- 
Eli Schwartz

Bug#1040745: ITP: samplebrain -- a custom sample mashing app designed by Aphex Twin

[tous]

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

* Package name: samplebrain
  Version : 0.18.4
  Upstream Author : Dave Griffiths
* URL : https://gitlab.com/then-try-this/samplebrain
* License : GPL
  Programming Lang: C++
  Description : A custom sample mashing app designed by Aphex Twin

Samplebrain chops samples up into a 'brain' of interconnected small
sections called blocks which are connected into a network by
similarity. It processes a target sample, chopping it up into blocks
in the same way, and tries to match each block with one in its brain
to play in realtime.

Bug#1040744: v4l2loopback-dkms: Device in broken state after use with exclusive_caps=1

[Gero Treuner]

Package: v4l2loopback-dkms
Version: 0.12.7-2
Severity: important
Tags: patch

With the Droidcam client (application to use mobile phone cameras with
the computer) the loopback device can be used only once. Then it is
neither an output nor a capture device, without being able to set format
and send data any more until the module is reloaded.
Without parameter "exclusive_caps=1" the issue doesn't appear, but I
need it for my scenario.

Output of command "v4l2-ctl -d /dev/video0 --all" before use:
Driver Info:
Driver name  : v4l2 loopback
Card type: Loopback Cam
Bus info : platform:v4l2loopback-000
Driver version   : 6.1.37
Capabilities : 0x8522
Video Output
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps  : 0x0522
Video Output
Read/Write
Streaming
Extended Pix Format

Output of command "v4l2-ctl -d /dev/video0 --all" after use:
Driver Info:
Driver name  : v4l2 loopback
Card type: Loopback Cam
Bus info : platform:v4l2loopback-000
Driver version   : 6.1.37
Capabilities : 0x8520
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps  : 0x0520
Read/Write
Streaming
Extended Pix Format

On analysis of the application no bug could be found there, but for
v4l2loopback module at the point of failure apparently
vidioc_try_fmt_cap() is called instead of vidioc_try_fmt_out(), which
must be caused by dev->ready_for_output == 0 but should be reset to 1
latest when all file handles are close.

As a VIDIOC_STREAMON ioctl is never happening here (no such call in
Droidcam), state of ready_for_output probably is changing in
v4l2_loopback_write() but without to set opener-type as WRITER at the
same time. Do I read it correctly that opener->type is unique for a
single file handle - what if the same file handle is used for both
writing and reading?

This patch fixes the issue for me:

--- v4l2loopback.c.orig 2022-08-05 00:30:07.0 +0200
+++ v4l2loopback.c  2023-07-10 00:25:06.480011644 +0200
@@ -2000,7 +2000,7 @@ static int v4l2_loopback_close(struct fi
v4l2_fh_exit(>fh);
 
kfree(opener);
-   if (iswriter) {
+   if (iswriter || dev->open_count.counter == 0) {
dev->ready_for_output = 1;
}
MARK();

Link to the original bug report for the Droidcam application
   https://github.com/dev47apps/droidcam/issues/242
Link to similar bug report for Pyvirtualcam
   https://github.com/letmaik/pyvirtualcam/issues/61


Kind regards,
   Gero


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

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

Versions of packages v4l2loopback-dkms depends on:
ii  dkms  3.0.10-8

v4l2loopback-dkms recommends no packages.

Versions of packages v4l2loopback-dkms suggests:
ii  v4l2loopback-utils  0.12.7-2

-- no debconf information

Bug#1040521: tpm2-tss: FTBFS (test failures)

[Bastian Germann]

On Fri, 7 Jul 2023 10:19:00 +0200 Gianfranco Costamagna wrote:

(outdated libtpms?)


I have tried with the current libtpms 0.9.6 but that does not solve the problem.

Bug#1038737: photoqt: diff for NMU version 3.3+ds-1.1

[Adrian Bunk]

Control: tags 1038737 + pending

Dear maintainer,

I've prepared an NMU for photoqt (versioned as 3.3+ds-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

cu
Adrian
diff -Nru photoqt-3.3+ds/debian/changelog photoqt-3.3+ds/debian/changelog
--- photoqt-3.3+ds/debian/changelog	2023-06-19 10:17:44.0 +0300
+++ photoqt-3.3+ds/debian/changelog	2023-07-10 01:28:08.0 +0300
@@ -1,3 +1,12 @@
+photoqt (3.3+ds-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Increase the timeout for the PyChromecast test and enable
+PyChromecast on all architectures. (Closes: #1038737)
+  * Enable FreeImage on all architectures. (see #1002610)
+
+ -- Adrian Bunk   Mon, 10 Jul 2023 01:28:08 +0300
+
 photoqt (3.3+ds-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru photoqt-3.3+ds/debian/control photoqt-3.3+ds/debian/control
--- photoqt-3.3+ds/debian/control	2023-06-19 10:17:44.0 +0300
+++ photoqt-3.3+ds/debian/control	2023-07-10 01:28:08.0 +0300
@@ -11,7 +11,7 @@
  libgraphicsmagick1-dev,
  libgraphicsmagick++1-dev,
  libraw-dev,
- libfreeimageplus-dev [!hppa !powerpc !ppc64],
+ libfreeimageplus-dev,
  libdevil-dev,
  libvips-dev,
  libmpv-dev,
@@ -23,7 +23,7 @@
  python3-pip,
  python3-dev,
  python3-requests,
- python3-pychromecast [!ia64 !kfreebsd-amd64 !kfreebsd-i386 !sparc64 !sh4 !riscv64 !m68k !hppa !mips64el],
+ python3-pychromecast,
  qtbase5-dev,
  qt5-qmake,
  qttools5-dev,
diff -Nru photoqt-3.3+ds/debian/patches/0001-Increase-the-timeout-for-the-PyChromecast-test.patch photoqt-3.3+ds/debian/patches/0001-Increase-the-timeout-for-the-PyChromecast-test.patch
--- photoqt-3.3+ds/debian/patches/0001-Increase-the-timeout-for-the-PyChromecast-test.patch	1970-01-01 02:00:00.0 +0200
+++ photoqt-3.3+ds/debian/patches/0001-Increase-the-timeout-for-the-PyChromecast-test.patch	2023-07-10 01:27:27.0 +0300
@@ -0,0 +1,32 @@
+From ab3886b0086f05adaa6cfe275c3a33ca42ee229b Mon Sep 17 00:00:00 2001
+From: Adrian Bunk 
+Date: Mon, 10 Jul 2023 01:06:39 +0300
+Subject: Increase the timeout for the PyChromecast test
+
+---
+ CMakeLists.txt | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 37123697..b27292c0 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -370,13 +370,13 @@ if(CHROMECAST)
+ elseif(NOT ${Python3_Interpreter_FOUND})
+ message(FATAL_ERROR "** Unable to locate Python3 Interpreter... is it installed?")
+ else()
+-execute_process(COMMAND ${Python3_EXECUTABLE} -c "import pychromecast" RESULT_VARIABLE EXIT_CODE OUTPUT_QUIET TIMEOUT 2)
++execute_process(COMMAND ${Python3_EXECUTABLE} -c "import pychromecast" RESULT_VARIABLE EXIT_CODE OUTPUT_QUIET TIMEOUT 60)
+ if(NOT ${EXIT_CODE} EQUAL 0)
+ if(CHROMECAST_PIPINSTALL)
+ # try installing it with pip
+ message(">> Attempt to install pychromecast locally using pip...")
+ execute_process(COMMAND ${Python3_EXECUTABLE} -m pip install pychromecast)
+-execute_process(COMMAND ${Python3_EXECUTABLE} -c "import pychromecast" RESULT_VARIABLE EXIT_CODE OUTPUT_QUIET TIMEOUT 2)
++execute_process(COMMAND ${Python3_EXECUTABLE} -c "import pychromecast" RESULT_VARIABLE EXIT_CODE OUTPUT_QUIET TIMEOUT 60)
+ if(NOT ${EXIT_CODE} EQUAL 0)
+ message(FATAL_ERROR "** Unable to locate Python3 module pychromecast. Please first install it or disable Chromecast support.")
+ else()
+-- 
+2.30.2
+
diff -Nru photoqt-3.3+ds/debian/patches/disable-pychromecast photoqt-3.3+ds/debian/patches/disable-pychromecast
--- photoqt-3.3+ds/debian/patches/disable-pychromecast	2022-04-08 10:02:42.0 +0300
+++ photoqt-3.3+ds/debian/patches/disable-pychromecast	1970-01-01 02:00:00.0 +0200
@@ -1,56 +0,0 @@
-Description: 
- TODO: Put a short summary on the line above and replace this paragraph
- with a longer explanation of this change. Complete the meta-information
- with other relevant fields (see below for details). To make it easier, the
- information below has been extracted from the changelog. Adjust it or drop
- it.
- .
- photoqt (2.6-1) unstable; urgency=medium
- .
-   * New upstream version.
-Author: Gürkan Myczko 
-

-The information above should follow the Patch Tagging Guidelines, please
-checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
-are templates for supplementary fields that you might want to add:
-
-Origin: , 
-Bug: 
-Bug-Debian: https://bugs.debian.org/
-Bug-Ubuntu: https://launchpad.net/bugs/
-Forwarded: 
-Reviewed-By: 
-Last-Update: 2022-04-08
-
 photoqt-2.6.orig/CMakeLists.txt
-+++ photoqt-2.6/CMakeLists.txt
-@@ -318,17 +318,17 @@ if(CHROMECAST)
- message(FATAL_ERROR "** Unable to locate Python3 Interpreter... is it installed?")
- else()
- execute_process(COMMAND ${Python3_EXECUTABLE} -c 

Bug#1040742: mailman3: Unable to 'dpkg-reconfigure' with MySQL after failed attempt

[Isaac Bennetch]

Package: mailman3
Version: 3.3.3-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I am attempting to use Mysql as the database backend. I ran `dpkg-reconfigure 
mailman3` as directed in README.Debian, but encountered an error because it 
couldn't reach my MySQL instance. I was able to 'abort' which brought me to a 
shell. I corrected the database problem and tried to `dpkg-configure mailman3` 
again, but it only stated "Determining localhost credentials from 
/etc/mysql/debian.cnf: succeeded." without asking any more prompts or finishing 
the configuration. Even if I use -plow I cannot force it to run the 
reconfiguration, to even ask whether I want to use SQLite or MySQL much less 
configure them properly.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

As mostly explained above, I used `dpkg-reconfigure mailman3` and 
`dpkg-reconfigure -plow mailman3`.

   * What was the outcome of this action?

The package was not proper reconfigured.

   * What outcome did you expect instead?

Prompts about which database to use and how to configure it, including 
prompting me for the password.


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

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

Versions of packages mailman3 depends on:
ii  dbconfig-mysql   2.0.19
ii  dbconfig-sqlite3 2.0.19
ii  debconf [debconf-2.0]1.5.77
ii  init-system-helpers  1.60
ii  logrotate3.18.0-2+deb11u1
ii  lsb-base 11.1.0
ii  python3  3.9.2-3
ii  python3-aiosmtpd 1.2.2-1
ii  python3-alembic  1.4.3-1
ii  python3-authheaders  0.13.1-1
ii  python3-authres  1.2.0-2
ii  python3-click7.1.2-1
ii  python3-dateutil 2.8.1-6
ii  python3-dnspython2.0.0-1
ii  python3-falcon   2.0.0-2+b1
ii  python3-flufl.bounce 3.0.1-1
ii  python3-flufl.i18n   3.0.1-1
ii  python3-flufl.lock   5.0.1-1
ii  python3-gunicorn 20.1.0-1
ii  python3-importlib-resources  5.1.0-1
ii  python3-lazr.config  2.2.3-1
ii  python3-passlib  1.7.4-1
ii  python3-psycopg2 2.8.6-2
ii  python3-public   0.5-1.1
ii  python3-requests 2.25.1+dfsg-2
ii  python3-sqlalchemy   1.3.22+ds1-1
ii  python3-zope.component   4.3.0-3
ii  python3-zope.configuration   4.4.0-1
ii  python3-zope.event   4.4-3
ii  python3-zope.interface   5.2.0-1
ii  ucf  3.0043

Versions of packages mailman3 recommends:
ii  exim4-daemon-heavy [mail-transport-agent]  4.94.2-7

Versions of packages mailman3 suggests:
pn  mailman3-doc
ii  mariadb-server-10.5 [virtual-mysql-server]  1:10.5.19-0+deb11u2
ii  w3m [www-browser]   0.5.3+git20210102-6+deb11u1

-- debconf information:
  mailman3/password-confirm: (password omitted)
  mailman3/app-password-confirm: (password omitted)
* mailman3/db/basepath: /var/lib/mailman3/data
  mailman3/upgrade-error: abort
* mailman3/db/dbname: mailman.db
  mailman3/init_service_failed:
  mailman3/install-error: abort
  mailman3/purge: false
  mailman3/missing-db-package-error: abort
  mailman3/internal/skip-preseed: false
  mailman3/dbconfig-reinstall: false
  mailman3/dbconfig-upgrade: true
  mailman3/dbconfig-remove: true
* mailman3/config_hyperkitty: true
  mailman3/passwords-do-not-match:
  mailman3/remove-error: abort
* mailman3/dbconfig-install: true
  mailman3/upgrade-backup: true
  mailman3/internal/reconfiguring: false
* mailman3/database-type: sqlite3

Bug#993400: mosquitto: New Upstream release v2.0.15

[Philippe Coval]

Package: mosquitto
Followup-For: Bug #993400

Dear Maintainer,

I can help on this, by uploadig latest upstream release.

Please review:

https://salsa.debian.org/debian-iot-team/mosquitto/-/merge_requests/

Upstream seems positive for co-maintenance in debian-iot team

https://github.com/eclipse/mosquitto/issues/2688#issuecomment-1626357713

Some sponsorship uploaders might be requiered.

Regards

Bug#1040685: systemd-cron: the MAILTO variable in /etc/crontab is not applied to generated cron units environments

[Alexandre Detiste]

crontrol: tag -1 fixed-upstream

Dear,

Thanks for caring,

Your feature request has been implemented upstream:

https://github.com/systemd-cron/systemd-cron/commit/e47e557820636905945b4bf5ff920339e259fbd5

As the repository is in the middle of a major rewrite,
a new release won't be published right away.

Le dim. 9 juil. 2023 à 11:57,  a écrit :
> The /etc/crontab files allow to define environment variables (MAILTO among 
> others) as per the man page.
> This definition should be applied to all the cron definitions as a fallback.
>
> The generator from this package parses /etc/crontab to identify jobs for 
> generating the associated systemd units.
> When parsing files in cron.d, the MAILTO is inserted as Environment if 
> explicitly defined.
> But if it not defined, the generator does not include the fallback value from 
> the /etc/crontab file.
>
> The generator should parse /etc/crontab, retrieve MAILTO and maybe PATH or 
> other env variables,
> and pass this fallback to the parsing of each file in cron.d or user crontabs.

Bug#1040620: quickplot will not read input file

[Lance Arsenault]

Hi Brent,

5.  I forgot to mention.  I'm using Debian 12 with GNOME and on that, both
libsndfile and GTK3 break quickplot; though "apt install quickplot" works,
but it installs a broken program.  I can't test your fix very easily on my
system.  I'd rather refactor quickplot than downgrade my OS. (ya, I know,
VMs, but I worry about slow displays and lots of unknowns ...; and VMs turn
me off in general) GTK3 uses a Wayland Display (on Debain 12 GNOME) and the
X11/wayland wrapper stuff seems to be broken.   You see, quickplot uses raw
libX11 code to get more speed than that is gotten from the cairo/x11
wrapper crap in GDK (GTK3), on older systems.   My refactoring will use
WaylandDisplay and not libX11, and that promises to be much faster than
libX11 ever was.   Wayland should be better and faster, but it has been a
long time coming; and has totally broken lots of my code.
GdkWaylandDisplay (GTK3 sub-library) is now giving me pain...   I feel that
the GTK3 and GTK4 developers are sadists.

Linus is talking about my pain in this video:
https://www.youtube.com/watch?v=Pzl1B7nB9Kc


Thanks again for your help.  Very helpful feedback.

cheers
lance


On Sun, Jul 9, 2023 at 1:29 PM Lance Arsenault  wrote:

>
> Hi Brent,
>
> 1. First thank you for submitting this bug ticket.  I'm not sure if I have
> write access to the debian bug system, but we'll see.
>
> 2.  I'm the sole downstream developer of quickplot.  quickplot as
> distributed by Debian GNU/Linux was pretty cool stuff.  It currently has
> some package dependencies that have broken it.  In particular, libsndfile
> and GTK3.  And so, quickplot is in need of refactoring, maybe dropping the
> libsndfile dependency and removing deprecated GTK3 API usage.  As it turns
> out, I just happened to have released (alpha) a much larger software
> package that kind-of needs a "quickplot" like tool to help my current
> work.  So I need to fix quickplot for my own use.  I have not used it in a
> while.
>
> 3. I looked at your bio.  We seem to have a little bit of overlap in
> professional interests,  my CV is at http://107.191.96.171/cv.html ,
> sorry it's http without https yet.
>
> 4. My new alpha software package is at
> https://github.com/lanceman2/quickstream  , you might find it interesting.
>
> cheers
> lance
>
>
> On Fri, Jul 7, 2023 at 11:30 PM Brent Roman  wrote:
> >
> > Package: quickplot
> > Version: 1.0.1~rc-1+b3
> >
> > Any attempt to read an input file or pipe fails with the error message:
> >
> > Failed to read file /home/brent/quickplot/plot.dat: lseek() failed
> >
> > A workaround is the link the quickplot binary with the upstream
> > libsndfile-1.0.28
> > rather than the libsndfile-1.0.31 packaged with Debian 11
> >
> > For instance, after installing libsndfile-1.0.28 in /usr/local/lib,
> > quickplot
> > will work if started with this shell script:
> >
> > #!/bin/sh #force linkage with our local version of libsndfile
> > # (1.0.28 rather than Debian's 1.0.31)
> > LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH exec /usr/bin/quickplot
> "$@"
> >
> > I am using Debian 11 on x86 (tested both 32 or 64-bit) with various
> > Linux 5.x kernels.
> >
> > --
> >   Brent Roman   MBARI
> >   Software Engineer   Tel: (831) 775-1808
> >   mailto:br...@mbari.org  http://www.mbari.org/~brent
> >
>

Bug#1040716: libc6: Stack Traces

[Tim McConnell]

Hi Aurelien, 
The Stack Traces started showing up in my System Event logs yesterday
and has totaled up to 18 times so far. As far as issues, the system is
slower than usual and occasionally freezes. 
 I ran apt-file search lib.so and came up with libc6 so that's where I
filed the bug. I tried running gdb on it (libc6) and it told me file
not found, I'd be happy to give more information just tell me how to
get it. 

-- 
Tim McConnell 


On Sun, 2023-07-09 at 23:34 +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2023-07-09 15:05, Tim McConnell wrote:
> > Package: libc6
> > Version: 2.37-3
> > Severity: normal
> > 
> 
> Thanks for your bug report. Could you please explain me what are
> those
> stack traces, and what is the issue you encountered? Thanks.
> 
> Regards
> Aurelien
> 

Bug#1040741: gnome-text-editor: Change to capital letters of a word doesnt work if highlighted by language corrector

[zezamoral]

Package: gnome-text-editor
Version: 43.2-1
Severity: normal
X-Debbugs-Cc: sazamor...@gmail.com

Dear Maintainer,


   * What led up to the situation?

Trying to change a word to capital letters. Right click. Doesnt work.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Right click over a word that is highlighted by language corrector.

   * What was the outcome of this action?

Capital letter option was not showed, not even displayed the sub menu.

   * What outcome did you expect instead?

' Change all to capital letters ' option.



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

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

Versions of packages gnome-text-editor depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libadwaita-1-0   1.2.2-1
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libeditorconfig0 0.12.6-0.1
ii  libenchant-2-2   2.3.3-2
ii  libglib2.0-0 2.74.6-2
ii  libgtk-4-1   4.8.3+ds-2
ii  libgtksourceview-5-0 5.6.2-1
ii  libicu72 72.1-3
ii  libpango-1.0-0   1.50.12+ds-1

gnome-text-editor recommends no packages.

gnome-text-editor suggests no packages.

-- no debconf information

Bug#1040415: bullseye-pu: package pacemaker/2.1.5-1+deb12u1

[Ferenc Wágner]

Control: tag -1 - confirmed

Jonathan Wiltshire  writes:

> On Wed, Jul 05, 2023 at 07:14:09PM +0200, Ferenc Wágner wrote:
>
>> Shortly after the release of bookworm we got a report that Pacemaker
>> regressed in certain migration scenarios when compared to the bullseye
>> version.  Upstream identified the cause (a bug already fixed in 2.1.6),
>> and after backporting the fix the submitter acknowledged that they can't
>> reproduce the bug anymore with the proposed packages.
>> https://bugs.clusterlabs.org/show_bug.cgi?id=5521
>> Pacemaker package bug opened after discussion on the mailing list:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040165
>
> Please go ahead, and bear in mind the upload window closes next weekend.

Thanks, Jonathan!  Does it mean that I have to upload before 15th of July?

On the other hand, meanwhile upstream notified me that to fully fix this
bug I need to backport one more patch, which in turn required including
a third one.  So the debdiff grew a little, please reconfirm the upload:

$ debdiff pacemaker_2.1.5-1.dsc pacemaker_2.1.5-1+deb12u1.dsc
dpkg-source: warning: extracting unsigned source package 
(/home/wferi/ha/pacemaker/pacemaker_2.1.5-1.dsc)
diff -Nru pacemaker-2.1.5/debian/changelog pacemaker-2.1.5/debian/changelog
--- pacemaker-2.1.5/debian/changelog2023-01-22 16:38:34.0 +0100
+++ pacemaker-2.1.5/debian/changelog2023-07-09 23:10:45.0 +0200
@@ -1,3 +1,17 @@
+pacemaker (2.1.5-1+deb12u1) bookworm; urgency=medium
+
+  * [0c22be8] New patches fixing migration regression.
+Backport of https://github.com/ClusterLabs/pacemaker/pull/3020/ to
+Pacemaker 2.1.5 (without the CTS changes, which we don't ship):
+5754a2af9 Refactor: scheduler: improve xpath efficiency when unpacking
+3f6f524f1 Low: scheduler: unknown_on_node() should ignore pending actions
+ad9fd9548 Fix: scheduler: handle cleaned migrate_from history correctly
+The starting refactor is required by the other two patches, but the
+third patch still needed backporting.
+Thanks to Ken Gaillot (Closes: #1040165)
+
+ -- Ferenc Wágner   Sun, 09 Jul 2023 23:10:45 +0200
+
 pacemaker (2.1.5-1) unstable; urgency=medium
 
   * [5792d59] Work around lazy loading of GitHub release pages in watch file
diff -Nru pacemaker-2.1.5/debian/gbp.conf pacemaker-2.1.5/debian/gbp.conf
--- pacemaker-2.1.5/debian/gbp.conf 2023-01-22 13:10:39.0 +0100
+++ pacemaker-2.1.5/debian/gbp.conf 2023-07-09 22:33:06.0 +0200
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/bookworm
 upstream-branch = upstream/latest
 
 [import-orig]
diff -Nru 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
--- 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
  1970-01-01 01:00:00.0 +0100
+++ 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
  2023-07-09 23:07:30.0 +0200
@@ -0,0 +1,30 @@
+From: Ken Gaillot 
+Date: Wed, 1 Feb 2023 17:12:13 -0600
+Subject: Fix: scheduler: handle cleaned migrate_from history correctly
+
+Fixes T623
+---
+ lib/pengine/unpack.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/lib/pengine/unpack.c b/lib/pengine/unpack.c
+index e9fcae1..99a2dc4 100644
+--- a/lib/pengine/unpack.c
 b/lib/pengine/unpack.c
+@@ -2937,6 +2937,16 @@ unpack_migrate_to_success(pe_resource_t *rsc, pe_node_t 
*node, xmlNode *xml_op,
+ }
+ 
+ } else { // Pending, or complete but erased
++
++/* If there is no history at all for the resource on an online 
target, then
++ * it was likely cleaned. Just return, and we'll schedule a probe. 
Once we
++ * have the probe result, it will be reflected in target_newer_state.
++ */
++if ((target_node != NULL) && target_node->details->online
++&& unknown_on_node(rsc, target)) {
++return;
++}
++
+ /* If the resource has newer state on the target, this migrate_to no
+  * longer matters for the target.
+  */
diff -Nru 
pacemaker-2.1.5/debian/patches/Low-scheduler-unknown_on_node-should-ignore-pending-actio.patch
 
pacemaker-2.1.5/debian/patches/Low-scheduler-unknown_on_node-should-ignore-pending-actio.patch
--- 
pacemaker-2.1.5/debian/patches/Low-scheduler-unknown_on_node-should-ignore-pending-actio.patch
  1970-01-01 01:00:00.0 +0100
+++ 
pacemaker-2.1.5/debian/patches/Low-scheduler-unknown_on_node-should-ignore-pending-actio.patch
  2023-07-09 23:07:30.0 +0200
@@ -0,0 +1,80 @@
+From: Ken Gaillot 
+Date: Thu, 2 Feb 2023 10:25:53 -0600
+Subject: Low: scheduler: unknown_on_node() should ignore pending actions
+
+Previously, unknown_on_node() looked for any lrm_rsc_op at all to decide
+whether a resource is known on 

Bug#1002610: freeimage: diff for NMU version 3.18.0+ds2-9.1

[Adrian Bunk]

Control: tags 1002610 + pending
Control: tags 1040259 + patch
Control: tags 1040259 + pending

Dear maintainer,

I've prepared an NMU for freeimage (versioned as 3.18.0+ds2-9.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

cu
Adrian
diff -Nru freeimage-3.18.0+ds2/debian/changelog freeimage-3.18.0+ds2/debian/changelog
--- freeimage-3.18.0+ds2/debian/changelog	2023-02-14 09:56:16.0 +0200
+++ freeimage-3.18.0+ds2/debian/changelog	2023-07-10 00:29:00.0 +0300
@@ -1,3 +1,11 @@
+freeimage (3.18.0+ds2-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for FTBFS with LibRaw 0.21. (Closes: #1040259)
+  * Add upstream fix for compilation on big endian. (Closes: #1002610)
+
+ -- Adrian Bunk   Mon, 10 Jul 2023 00:29:00 +0300
+
 freeimage (3.18.0+ds2-9) unstable; urgency=medium
 
   * Team upload.
diff -Nru freeimage-3.18.0+ds2/debian/patches/Fix-big-endian.patch freeimage-3.18.0+ds2/debian/patches/Fix-big-endian.patch
--- freeimage-3.18.0+ds2/debian/patches/Fix-big-endian.patch	1970-01-01 02:00:00.0 +0200
+++ freeimage-3.18.0+ds2/debian/patches/Fix-big-endian.patch	2023-07-10 00:29:00.0 +0300
@@ -0,0 +1,63 @@
+Description: Fix FTBFS on some big-endian targets
+Bug-Debian: https://bugs.debian.org/1002610
+Origin: backport, https://sourceforge.net/p/freeimage/svn/1809/
+
+Index: freeimage-3.18.0+ds2/Source/FreeImage/PluginBMP.cpp
+===
+--- freeimage-3.18.0+ds2.orig/Source/FreeImage/PluginBMP.cpp
 freeimage-3.18.0+ds2/Source/FreeImage/PluginBMP.cpp
+@@ -518,7 +518,7 @@ LoadWindowsBMP(FreeImageIO *io, fi_handl
+ io->read_proc(FreeImage_GetPalette(dib), used_colors * sizeof(RGBQUAD), 1, handle);
+ #if FREEIMAGE_COLORORDER == FREEIMAGE_COLORORDER_RGB
+ RGBQUAD *pal = FreeImage_GetPalette(dib);
+-for(int i = 0; i < used_colors; i++) {
++for(unsigned i = 0; i < used_colors; i++) {
+ 	INPLACESWAP(pal[i].rgbRed, pal[i].rgbBlue);
+ }
+ #endif
+@@ -1419,7 +1419,7 @@ Save(FreeImageIO *io, FIBITMAP *dib, fi_
+ 
+ 			free(buffer);
+ #ifdef FREEIMAGE_BIGENDIAN
+-		} else if (bpp == 16) {
++		} else if (dst_bpp == 16) {
+ 			int padding = dst_pitch - dst_width * sizeof(WORD);
+ 			WORD pad = 0;
+ 			WORD pixel;
+@@ -1440,7 +1440,7 @@ Save(FreeImageIO *io, FIBITMAP *dib, fi_
+ 			}
+ #endif
+ #if FREEIMAGE_COLORORDER == FREEIMAGE_COLORORDER_RGB
+-		} else if (bpp == 24) {
++		} else if (dst_bpp == 24) {
+ 			int padding = dst_pitch - dst_width * sizeof(FILE_BGR);
+ 			DWORD pad = 0;
+ 			FILE_BGR bgr;
+@@ -1461,7 +1461,7 @@ Save(FreeImageIO *io, FIBITMAP *dib, fi_
+ 	}
+ }
+ 			}
+-		} else if (bpp == 32) {
++		} else if (dst_bpp == 32) {
+ 			FILE_BGRA bgra;
+ 			for(unsigned y = 0; y < dst_height; y++) {
+ BYTE *line = FreeImage_GetScanLine(dib, y);
+Index: freeimage-3.18.0+ds2/Source/FreeImage/PluginDDS.cpp
+===
+--- freeimage-3.18.0+ds2.orig/Source/FreeImage/PluginDDS.cpp
 freeimage-3.18.0+ds2/Source/FreeImage/PluginDDS.cpp
+@@ -356,14 +356,6 @@ SwapHeader(DDSHEADER *header) {
+ 	for(int i=0; i<11; i++) {
+ 		SwapLong(>surfaceDesc.dwReserved1[i]);
+ 	}
+-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwSize);
+-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwFlags);
+-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwFourCC);
+-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwRGBBitCount);
+-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwRBitMask);
+-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwGBitMask);
+-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwBBitMask);
+-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwRGBAlphaBitMask);
+ 	SwapLong(>surfaceDesc.ddsCaps.dwCaps1);
+ 	SwapLong(>surfaceDesc.ddsCaps.dwCaps2);
+ 	SwapLong(>surfaceDesc.ddsCaps.dwReserved[0]);
diff -Nru freeimage-3.18.0+ds2/debian/patches/Fix-libraw-compilation-2.patch freeimage-3.18.0+ds2/debian/patches/Fix-libraw-compilation-2.patch
--- freeimage-3.18.0+ds2/debian/patches/Fix-libraw-compilation-2.patch	1970-01-01 02:00:00.0 +0200
+++ freeimage-3.18.0+ds2/debian/patches/Fix-libraw-compilation-2.patch	2023-07-10 00:27:16.0 +0300
@@ -0,0 +1,13 @@
+Index: Source/FreeImage/PluginRAW.cpp
+===
+--- a/Source/FreeImage/PluginRAW.cpp	(revision 1894)
 b/Source/FreeImage/PluginRAW.cpp	(revision 1895)
+@@ -701,7 +701,7 @@
+ 		// 
+ 
+ 		// (-s [0..N-1]) Select one raw image from input file
+-		RawProcessor->imgdata.params.shot_select = 0;
++		RawProcessor->imgdata.rawparams.shot_select = 0;
+ 		// (-w) Use camera white balance, if possible (otherwise, fallback to auto_wb)
+ 		RawProcessor->imgdata.params.use_camera_wb = 1;
+ 		// (-M) Use any color matrix from the camera metadata. This option only affects Olympus, Leaf, and Phase One cameras.
diff -Nru freeimage-3.18.0+ds2/debian/patches/series 

Bug#1040740: sagemath: three.js plots not shown

[Balbir Thomas]

Package: sagemath
Version: 9.5-6
Severity: normal

Dear Maintainer,

In trying to plot any 3D surface using sagemath and the default 3D
viewer (three.js) the HTML plot page is generated and a new browser
tab is opened however no plot is shown. The three.js tab does have
a menu icon that works, also the source code of the generated HTML 
page and page source looks reasonable including the plotting code.
In the browser debug console only one error is shown. This error is


Uncaught ReferenceError: THREE is not defined
 file:///.../.sage/.../tmp_t5mlfrwr.html:49

The line referenced by the error is

var scene = new THREE.Scene();

I do see such a variable THREE defined globally in the

However the script included in the sagemath plot is


It seems the path to three.min.js should not include "r122". I am not
sure why this is happening.

If a manually edit the tmp_t5mlfrwr.html file and remove the "r122"
then the plot screen becomes black (previously it was white) and
the error message is now different (shown below)

Uncaught TypeError: THREE.MathUtils is undefined
addLabel file:///.../.sage/.../tmp_oznfc_be.html:208
 file:///.../.sage/.../tmp_oznfc_be.html:155

This is how far I can dig.

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/6 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

Versions of packages sagemath depends on:
ii  python3   3.11.2-1+b1
ii  python3-sage  9.5-6

Versions of packages sagemath recommends:
ii  sagemath-doc9.5-6
ii  sagemath-jupyter9.5-6
ii  sagetex 3.6.1+ds-1
ii  texlive-latex-base  2022.20230122-3

Versions of packages sagemath suggests:
pn  dot2tex  
pn  gap-design   
ii  gap-factint  1.6.3+ds-2
pn  gap-grape
pn  gap-guava
ii  gap-laguna   3.9.5+ds-2
pn  gap-sonata   
pn  gap-toric

-- no debconf information

Bug#1040739: bullseye-pu: package desktop-base/12.0.6+nmu1~deb12u1

[Andreas Beckmann]

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

[ Reason ]
When the emeral theme was added to the alternatives, it was forgotten to
add that to the alternatives removal, too.

[ Impact ]
Leaving broken alternatives after package removal, probably only
noticable by QA tooling.

[ Tests ]
local piuparts tests of all bullseye->bookworm upgrades that have
desktop-base installed, using the new package version in the bookworm
upgrade target.

[ Risks ]
low, alternatives addition/removal is using for loops, this patch
just adds some entries to each of the removal loops

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

[ Changes ]
prerm: remove all emerald alternatives created by the postinst

[ Other info ]
This is a rebuild of the package (soon) from sid with no further
changes.


Andreas
diff -Nru desktop-base-12.0.6/debian/changelog 
desktop-base-12.0.6+nmu1~deb12u1/debian/changelog
--- desktop-base-12.0.6/debian/changelog2023-04-13 21:58:23.0 
+0200
+++ desktop-base-12.0.6+nmu1~deb12u1/debian/changelog   2023-07-09 
23:27:38.0 +0200
@@ -1,3 +1,16 @@
+desktop-base (12.0.6+nmu1~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Sun, 09 Jul 2023 23:27:38 +0200
+
+desktop-base (12.0.6+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * prerm: Remove the emerald alternatives, too.  (Closes: #1035431)
+
+ -- Andreas Beckmann   Fri, 30 Jun 2023 12:36:56 +0200
+
 desktop-base (12.0.6) unstable; urgency=medium
 
   * Fix LUKS password not being shown in multi-screen setup with mixed aspect
diff -Nru desktop-base-12.0.6/debian/prerm 
desktop-base-12.0.6+nmu1~deb12u1/debian/prerm
--- desktop-base-12.0.6/debian/prerm2022-10-02 21:24:41.0 +0200
+++ desktop-base-12.0.6+nmu1~deb12u1/debian/prerm   2023-06-30 
12:36:11.0 +0200
@@ -16,6 +16,7 @@
 desktop-background \
 
/usr/share/desktop-base/$theme-theme/wallpaper/contents/images/$filename
 done << EOF
+emerald 1920x1080.svg
 homeworld 1920x1080.svg
 futureprototype 1920x1080.svg
 moonlight 1920x1080.svg
@@ -58,6 +59,7 @@
 desktop-background.xml \
 /usr/share/desktop-base/$theme-theme/wallpaper/gnome-background.xml
 done << EOF
+emerald
 homeworld
 futureprototype
 moonlight
@@ -79,6 +81,7 @@
 desktop-lockscreen.xml \
 
/usr/share/desktop-base/$theme-theme/lockscreen/gnome-background.xml
 done << EOF
+emerald
 homeworld
 futureprototype
 moonlight
@@ -99,6 +102,7 @@
 desktop-plasma5-wallpaper \
 /usr/share/desktop-base/$theme-theme/wallpaper
 done << EOF
+emerald
 homeworld
 futureprototype
 moonlight
@@ -121,6 +125,7 @@
 desktop-login-background \
 /usr/share/desktop-base/$theme-theme/login/$background
 done << EOF
+emerald background.svg
 homeworld background.svg
 futureprototype background.svg
 moonlight background.svg
@@ -141,6 +146,8 @@
 desktop-grub \
 /usr/share/desktop-base/$theme-theme/grub/grub-$ratio.png
 done << EOF
+emerald 4x3
+emerald 16x9
 homeworld 4x3
 homeworld 16x9
 futureprototype 4x3
@@ -182,6 +189,7 @@
 desktop-theme \
 /usr/share/desktop-base/$theme-theme
 done << EOF
+emerald
 futureprototype
 moonlight
 softwaves

Bug#1037135: please update to latest upstream version (>> 4.2.0) and confirm intent to maintain package

[Nicholas D Steeves]

Hi Dhavan,

Dhavan  writes:

> Thanks for dropping the email to this address, and apologies for causing 
> trouble by letting the previous address go dead.

You're welcome.

> I stopped updating the package because the docs of modus-themes are licensed 
> such that they cannot be added to Debian repos anymore. They'll have to be 
> split and moved to debian-contrib. I do not know how to do this, and haven't 
> looked into it since I last tried. I shall try to get it done soon(TM). 
> Bremner had suggested we can let go of the docs for now. If I cannot figure 
> things out in time, perhaps we can explore this path as well.
>

Minor correction: The docs would need to go into non-free, not contrib;
however, If you wanted to make modus-themes depend on non-free docs,
then elpa-modus-themes would need to be moved to contrib.  Please note
that the docs will also need their on source package.  So in addition to
src:modus-themes (in Debian main), you would also have
src:modus-themes-docs (in non-free).  I recommend using a "Suggests"
from elpa-modus-themes, or a "Enhances" from the future non-free
modus-themes docs.

I agree with Bremner, and will add that the harm of shadowing the
copy of modus-themes that is bundled in Emacs is greater than the
usefulness of the docs.  Elpa-modus-themes doesn't have a "-docs"
package, so won't need to go through the NEW queue again.

> In any case, I shall be attempting to upgrade soon.
>

You've got this! :) You're already using a gbp (git-buildpackage) style
git repository so this is *very easy*.  Just use the Files-Excluded
feature of debian/control, and run "gbp import-orig --uscan".

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1040727: Correction

[Super Veridical]

Correction: The issue occurs only in graphical and text modes of
installation, but not in liveCD. LiveCD installation (somewhat)
correctly warns about the lack of space (says 10G is needed)

Bug#1040711: Acknowledgement (SDDM's setting 'minimum-vt' is ignored)

[Joerg Schiermeier, Bielefeld/Germany]

Some additional infos about the 'minimum-vt' setting:

https://manpages.debian.org/stretch/sddm/sddm.conf.5.en.html

See the section "[X11]" and the description there:

--
MinimumVT=
Minimum virtual terminal number that will be used by the first display. Virtual 
terminal number will increase as new displays added. Default value is 7.
--

-- 
Yours sincerely
Joerg Schiermeier
Bielefeld / Germany

Bug#1040716: libc6: Stack Traces

[Aurelien Jarno]

Hi,

On 2023-07-09 15:05, Tim McConnell wrote:
> Package: libc6
> Version: 2.37-3
> Severity: normal
> 

Thanks for your bug report. Could you please explain me what are those
stack traces, and what is the issue you encountered? Thanks.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1040738: linux: Please review firmware related Debian patches

[Diederik de Haas]

Source: linux
Version: 6.4.1-1~exp1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

While working on building/testing a Debian kernel for the PineTab2 I
noticed that I got a firmware (related) *error* in `dmesg`, while that
was not the case on a kernel with a Debian (based) config and the
upstream kernel source. Neither was it reported as an error in the OOTB
provided image/kernel (ALARM).
In both other cases it was reported as a *warning*.

When I build a new Debian kernel with the "firmware_class: Log every
success and failure against given device" patch removed (and adjusted
`d/patches/debian/firmware_class-refer-to-debian-wiki-firmware-page.patch`
to fix the resulting issue), then that same firmware related message was
reported as a warning too.

Before:  
```
root@pinetab2:~# dmesg --level emerg,alert,crit,err
[0.00] clk: failed to reparent gpll to clk_rtc32k_frac: -22
[0.00] clk: failed to reparent gpll to clk_rtc32k_frac: -22
[   23.391432] spi-nor spi4.0: unrecognized JEDEC id bytes: 00 00 00 00 00 00
[   23.466581] ov5648 2-0036: failed to find 16800 clk rate in endpoint 
link-frequencies
[   23.513593] Goodix-TS 1-005d: firmware: failed to load goodix_911_cfg.bin 
(-2)
[   23.513603] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   23.513640] Goodix-TS 1-005d: firmware: failed to load goodix_911_cfg.bin 
(-2)
```

After:  
```
root@pinetab2:~# dmesg --level emerg,alert,crit,err
[0.00] clk: failed to reparent gpll to clk_rtc32k_frac: -22
[0.00] clk: failed to reparent gpll to clk_rtc32k_frac: -22
[   32.571259] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   32.589465] ov5648 2-0036: failed to find 16800 clk rate in endpoint 
link-frequencies
```
Note: The `spi-nor` msg already disappeared on a reboot, but is
irrelevant anyway. And looks like my patch (removal) wasn't complete,
but that also seems irrelevant.

I really don't like ignoring errors I see in `dmesg`. But this isn't the
first instance where I was inclined to do exactly that as the
Debian patch(es) 'upgrade' an upstream warning to an error.
And IIUC/IIRC I've also seen that several times when triaging Debian
kernel bugs, f.e. with an issue which 'rhymes' with yolo-debug.

So hereby a request to review the firmware related Debian patches to see
whether they still are the best way to solve the (initial) problem and
if not, improve on them so they will.

Cheers,
  Diederik

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZKsmVQAKCRDXblvOeH7b
bg0LAP43Zo91VX1KK8d7/Icsl3JerHPBmNAOskhTvGv3NkT5yAD+Obg69navr+Rw
sNgU43OHquxKFhGhlBOo1UWN+M9XNAg=
=9ctN
-END PGP SIGNATURE-

Bug#1040676: elpa-debian-el: Documentation fixes.

[Nicholas D Steeves]

manp...@gmail.com writes:

> I have a merge request on salsa[1] for documentation fixes for the
> package elpa-debian-el.  The first commit has typo fixes only, the
> second one has some proposed wording fixes.  Please review.  Thanks!
>
> [1] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/10

Thank you for these fixes!  I've started a review.  If for some reason I
seem to take too long to notice that you've resolved all issues (when
you've resolved them), please ping me at this bug.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1040727: The Installation system doesn't check available free disk space, either provides an uninformative error message or completes installation "successfully" with a resulting non-working syste

[Super Veridical]

Package: installation-reports

Boot method: "-cdrom" key in qemu with OVMF firmware
Image version: 
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.0.0-amd64-kde.iso
Date: Jul 8 2023

Machine: ASUS ROG STRIX B650E-F GAMING WIFI
Processor: AMD Ryzen 9 7950X, "-cpu host -smp 6" flags in qemu
Memory: "-m 6000" flag in qemu
Partitions: "Guided partition" method during the installation with a
single root partition.

The entire qemu command:
qemu-system-x86_64 -nic user,model=virtio-net-pci -cpu host -smp 6 -m
6000 -enable-kvm -device virtio-vga-gl -display gtk,gl=on -drive
file=/usr/share/edk2-ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on
-drive if=pflash,format=raw,file=OVMF_VARS.fd -drive
format=raw,file=sda.img,if=virtio -drive
format=raw,file=sdb.img,if=virtio -cdrom
~/debian-live-12.0.0-amd64-kde.iso

qemu --version output: "QEMU emulator version 7.2.3"
Host OS: Gentoo Linux

With "qemu-img create -f raw -o size=6G sda.img" i.e. 6GB virtual hdd:

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[E]

proceeds to the system installation step despite not having enough
space in the root partition, fails with an uninformative error message
"the step that failed : install the system", in all three installation
modes (livecd, graphical, text)

with "qemu-img create -f raw -o size=12G sda.img" (should work
according to this documentation entry
https://www.debian.org/releases/stable/amd64/ch03s04.en.html):

Overall install:[E]

Installs seemingly successfully, but shows black screen after login
due to completely exhausted disk space on the root partition. "Avail
0" in df output. I.e. installation process exhausted disk space but
completed installation without an apparent error.

with "qemu-img create -f raw -o size=22G sda.img" works perfectly fine.

Bug#1039617: liblopsub: reproducible-builds: timestamps in gzip headers for changelog and manpage

[Vagrant Cascadian]

On 2023-07-09, Andre Noll wrote:
> On Thu, Jun 29, 19:45, Andre Noll wrote
>> > It also needs someone to upload to Debian. Looks like Adam Borowski
>> >  has sponsored in the past, but if you need someone
>> > else to sponsor the upload, I could too.
>> 
>> Yes, Adam uploaded all previous versions so far. But of course it's
>> also fine if you sponsor the upload this time.
>
> Could either of you please upload v1.0.4 (released on Jun 28th)?

Thanks for getting it prepared!

I'll see if I can work it in today... otherwise it will have to wait
till the 17th or so for me...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1040472: p11-kit FTCBFS: AC_RUN_IFELSE

[Helmut Grohne]

Hi Andreas,

On Sun, Jul 09, 2023 at 04:04:20PM +0200, Andreas Metzler wrote:
> > @@ -178,10 +179,13 @@
> > return strerror_r (EINVAL, buf, 32);
> > }
> > ]])],
> > +   [ac_cv_strerror_r_ret=xsi],
> > +   [ac_cv_strerror_r_ret=gnu],
> > +   [ac_cv_strerror_r_ret=cross])])
> > +dnl Guess that we cross build on glibc
> > +AS_IF([test "$ac_cv_strerror_r_ret" = xsi],
> >  [AC_DEFINE([HAVE_XSI_STRERROR_R], 1, [Whether 
> > XSI-compliant strerror_r() is available])],
> > -   [AC_DEFINE([HAVE_GNU_STRERROR_R], 1, [Whether 
> > GNU-specific strerror_r() is available])],
> > -   [])],
> > -   [])
> > +   [AC_DEFINE([HAVE_GNU_STRERROR_R], 1, [Whether 
> > GNU-specific strerror_r() is available])])])
> 
> > AC_CACHE_CHECK([for thread-local storage class],
> > [ac_cv_tls_keyword],
> 
> Hello Helmut,
> 
> thanks.
> 
> I guess this should read 
> AS_IF([test "$ac_cv_strerror_r_ret" = cross],
> 
> instead of
> 
> AS_IF([test "$ac_cv_strerror_r_ret" = xsi],
> 
> ?

Thanks for asking rather than just changing my patch. I think my patch
is correct as is. If the strerror_r returns 0, ac_cv_strerror_r_ret will
be set to xsi. In that case, we want to define HAVE_XSI_STRERROR_R. In
other cases, ac_cv_strerror_r_ret will be set to gnu or cross. Since I
guess cross compilation to target glibc, I set HAVE_GNU_STRERROR_R in
both cases.

Do you now see why it needs to be the way I've written it?

> Also wouldn't using AC_FUNC_STRERROR_R be a better fix? (I do not expect
> you to provide this, I asking for your opinion)

After having read the documentation of that macro, I am unsure whether
it resolves what is being checked here. AC_FUNC_STRERROR_R checks for
the function and also for how it is being declared, but makes no
statement about its return value. If there is a connection between
return type and return value that I don't see, then yes, this may be
better. Otherwise, this probably still is better than using
AC_CHECK_FUNC outside. Maybe that connection is XSI <=> int return, GNU
<=> pointer return?

Helmut

Bug#1040717: qt6-remoteobjects FTCBFS: misses the native repc

[Helmut Grohne]

Source: qt6-remoteobjects
Version: 6.4.2-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qt6-remoteobjects recently gained that common -DQT_HOST_PATH flag.
Thanks for adding it without having me file a patch for it.

This is one of the cases where that change is necessary and
insufficient. We also need a native repc here. We need another
dependency and some cmake flags to get that working. I'm a attaching a
patch for your convenience.

Note that this kind of change also somewhat is a pattern, but it is less
mechanical and less frequent than the -DQT_HOST_PATH one. Therefore, I
see no need for you to proactively do this for me in other packages.

Helmut
diff --minimal -Nru qt6-remoteobjects-6.4.2/debian/changelog 
qt6-remoteobjects-6.4.2/debian/changelog
--- qt6-remoteobjects-6.4.2/debian/changelog2023-06-22 00:06:36.0 
+0200
+++ qt6-remoteobjects-6.4.2/debian/changelog2023-07-08 12:08:13.0 
+0200
@@ -1,3 +1,10 @@
+qt6-remoteobjects (6.4.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use the build repc and also build it for host. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 08 Jul 2023 12:08:13 +0200
+
 qt6-remoteobjects (6.4.2-2) unstable; urgency=medium
 
   [ Patrick Franz ]
diff --minimal -Nru qt6-remoteobjects-6.4.2/debian/control 
qt6-remoteobjects-6.4.2/debian/control
--- qt6-remoteobjects-6.4.2/debian/control  2022-12-30 16:46:01.0 
+0100
+++ qt6-remoteobjects-6.4.2/debian/control  2023-07-08 12:08:12.0 
+0200
@@ -18,6 +18,7 @@
qt6-base-private-dev (>= 6.4.2+dfsg~),
qt6-declarative-dev (>= 6.4.2+dfsg~),
qt6-declarative-private-dev (>= 6.4.2+dfsg~),
+   qt6-remoteobjects-dev:native ,
xauth ,
xvfb ,
 Standards-Version: 4.6.2
diff --minimal -Nru qt6-remoteobjects-6.4.2/debian/rules 
qt6-remoteobjects-6.4.2/debian/rules
--- qt6-remoteobjects-6.4.2/debian/rules2023-06-22 00:05:50.0 
+0200
+++ qt6-remoteobjects-6.4.2/debian/rules2023-07-08 12:08:13.0 
+0200
@@ -6,7 +6,10 @@
 
 # QT_HOST_PATH isn't passed in cross-builds
 ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
-   extra_cmake_args += -DQT_HOST_PATH=/usr
+   extra_cmake_args += \
+   -DQT_HOST_PATH=/usr \
+   -DQT_HOST_PATH_CMAKE_DIR=/usr/lib/$(DEB_BUILD_MULTIARCH)/cmake \
+   -DQT_BUILD_TOOLS_WHEN_CROSSCOMPILING=ON
 endif
 
 %:

Bug#1038402: openorienteering-mapper: FTBFS with Qt ≥ 5.15.9: QPainterTest failures

[Dmitry Shachnev]

Control: tags -1 +pending

Hi,

On Sat, Jun 17, 2023 at 09:24:07PM +0300, Dmitry Shachnev wrote:
> Dear Maintainer,
>
> openorienteering-mapper fails to build with Qt ≥ 5.15.9, which is currently
> available in experimental (but I am going to upload it to unstable soon).
>
> [...]
>
> I have created an upstream pull request that fixes this issue, see the
> Forwarded URL.

As Qt 5.15.10 is in unstable now and this package needs to be rebuilt against
the new private ABI, I have uploaded NMU to DELAYED/2.

The debdiff is attached. Also created a merge request on salsa:
https://salsa.debian.org/debian/openorienteering-mapper/-/merge_requests/2

--
Dmitry Shachnev
diff -Nru openorienteering-mapper-0.9.5/debian/changelog openorienteering-mapper-0.9.5/debian/changelog
--- openorienteering-mapper-0.9.5/debian/changelog	2021-12-28 12:45:41.0 +0300
+++ openorienteering-mapper-0.9.5/debian/changelog	2023-07-09 23:48:02.0 +0300
@@ -1,3 +1,11 @@
+openorienteering-mapper (0.9.5-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add a patch to make the QPainterTest pass with Qt 5.15.9
+(closes: #1038402).
+
+ -- Dmitry Shachnev   Sun, 09 Jul 2023 23:48:02 +0300
+
 openorienteering-mapper (0.9.5-3) unstable; urgency=medium
 
   * Cherry-pick upstream commit updating expected
diff -Nru openorienteering-mapper-0.9.5/debian/patches/qt-5.15.9.patch openorienteering-mapper-0.9.5/debian/patches/qt-5.15.9.patch
--- openorienteering-mapper-0.9.5/debian/patches/qt-5.15.9.patch	1970-01-01 03:00:00.0 +0300
+++ openorienteering-mapper-0.9.5/debian/patches/qt-5.15.9.patch	2023-07-09 23:48:02.0 +0300
@@ -0,0 +1,60 @@
+Description: make QPainterTest pass with Qt 5.15.9
+ https://bugreports.qt.io/browse/QTBUG-100327 was fixed in 5.15.9,
+ so now we have a good result from the beginning and don't need
+ ImageTransparencyFixup.
+Author: Dmitry Shachnev 
+Forwarded: https://github.com/OpenOrienteering/mapper/pull/2156
+Last-Update: 2023-07-09
+
+--- a/src/core/image_transparency_fixup.h
 b/src/core/image_transparency_fixup.h
+@@ -57,6 +57,9 @@ public:
+ 	 * 
+ 	 * The image must be of QImage::Format_ARGB32_Premultiplied.
+ 	 * It may be null.
++	 *
++	 * This fixup is needed for Qt5 < 5.15.9 and Qt6 < 6.2.4 which are
++	 * affected by https://bugreports.qt.io/browse/QTBUG-100327.
+ 	 */
+ 	inline ImageTransparencyFixup(QImage* image)
+ 	: dest(0), dest_end(0)
+@@ -81,11 +84,13 @@ public:
+ 	 */
+ 	inline void operator()() const
+ 	{
++#if QT_VERSION < QT_VERSION_CHECK(5, 15, 9) || (QT_VERSION >= QT_VERSION_CHECK(6, 0, 0) && QT_VERSION < QT_VERSION_CHECK(6, 2, 4))
+ 		for (QRgb* px = dest; px < dest_end; px++)
+ 		{
+ 			if (*px == 0x0100) /* qRgba(0, 0, 0, 1) */
+ *px = 0x;  /* qRgba(0, 0, 0, 0) */
+ 		}
++#endif
+ 	}
+ 	
+ protected:
+--- a/test/qpainter_t.cpp
 b/test/qpainter_t.cpp
+@@ -80,9 +80,10 @@ void QPainterTest::multiplyComposition()
+ 	QCOMPARE(compose(white_img, white_img, multiply).pixel(0,0), qRgba(255, 255, 255, 255));
+ 	QCOMPARE(compose(black_img, black_img, multiply).pixel(0,0), qRgba(0, 0, 0, 255));
+ 	
++#if QT_VERSION < QT_VERSION_CHECK(5, 15, 9) || (QT_VERSION >= QT_VERSION_CHECK(6, 0, 0) && QT_VERSION < QT_VERSION_CHECK(6, 2, 4))
+ 	QEXPECT_FAIL("", "CompositionMode_Multiply incorrectly composes full transparency.", Continue);
++#endif
+ 	QCOMPARE(compose(trans_img, trans_img, multiply).pixel(0,0), qRgba(0, 0, 0, 0));
+-	QCOMPARE(compose(trans_img, trans_img, multiply).pixel(0,0), qRgba(0, 0, 0, 1)); // This should fail!
+ 	
+ 	// ImageTransparencyFixup fixes the particular issue.
+ 	QImage result = compose(trans_img, trans_img, multiply);
+@@ -107,9 +108,10 @@ void QPainterTest::darkenComposition()
+ 	QCOMPARE(compose(white_img, white_img, darken).pixel(0,0), qRgba(255, 255, 255, 255));
+ 	QCOMPARE(compose(black_img, black_img, darken).pixel(0,0), qRgba(0, 0, 0, 255));
+ 	
++#if QT_VERSION < QT_VERSION_CHECK(5, 15, 9) || (QT_VERSION >= QT_VERSION_CHECK(6, 0, 0) && QT_VERSION < QT_VERSION_CHECK(6, 2, 4))
+ 	QEXPECT_FAIL("", "CompositionMode_Darken incorrectly composes full transparency.", Continue);
++#endif
+ 	QCOMPARE(compose(trans_img, trans_img, darken).pixel(0,0), qRgba(0, 0, 0, 0));
+-	QCOMPARE(compose(trans_img, trans_img, darken).pixel(0,0), qRgba(0, 0, 0, 1)); // This should fail!
+ 	
+ 	// ImageTransparencyFixup fixes the particular issue.
+ 	QImage result = compose(trans_img, trans_img, darken);
diff -Nru openorienteering-mapper-0.9.5/debian/patches/series openorienteering-mapper-0.9.5/debian/patches/series
--- openorienteering-mapper-0.9.5/debian/patches/series	2021-12-28 12:06:01.0 +0300
+++ openorienteering-mapper-0.9.5/debian/patches/series	2023-07-09 23:48:02.0 +0300
@@ -1,3 +1,4 @@
 fix-help-data-dir.patch
 proj8.patch
 proj8.2.0.patch
+qt-5.15.9.patch


signature.asc
Description: PGP signature

Bug#1037996: xfce: Re: xfce4: xfce-Desktop will be crashed at start and than black Desktop

[Jon Fineman]

Package: xfce4
Version: 4.18
Followup-For: Bug #1037996

Dear Maintainer,

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

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

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

apt update
apt full-upgrade
reboot
logged in using xfce4
at this point the the screen will blank and maybe get
some raster lines. The system will usually reboot once.
After logging again the screen will blank and then the system
will hang.

I can log in fine if I switch to awesome wm.


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

Kernel: Linux 6.3.0-2-amd64 (SMP w/2 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 xfce4 depends on:
ii  libxfce4ui-utils 4.18.4-1
ii  thunar   4.18.6-1
ii  xfce4-appfinder  4.18.0-1
ii  xfce4-panel  4.18.4-1
ii  xfce4-pulseaudio-plugin  0.4.7-1
ii  xfce4-session4.18.3-1
ii  xfce4-settings   4.18.3-1
ii  xfconf   4.18.1-1
ii  xfdesktop4   4.18.1-1
ii  xfwm44.18.0-1

Versions of packages xfce4 recommends:
ii  desktop-base  12.0.6
ii  tango-icon-theme  0.8.90-11
ii  thunar-volman 4.18.0-1
ii  xfce4-notifyd 0.8.2-1
ii  xorg  1:7.7+23

Versions of packages xfce4 suggests:
ii  xfce4-goodies4.18.1
ii  xfce4-power-manager  4.18.2-1

-- no debconf information

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi,

On 09-07-2023 21:09, Dirk Eddelbuettel wrote:

| I don't understand this then. For several packages we're seeing failures
| in testing even if we only use r-base from unstable and everything else
| from testing to run the test. They pass with a rebuild r-cran-fnn and/or
| a rebuild and updated r-cran-ps, and/or r-cran-tibble. (Sorry, in my
| previous message I think I added r-cran-dplyr by mistake, misremembered).

It would be useful to break this down into concrete reproducible examples.


Several in the set that I explicitly tested:
r-cran-stars (needs r-cran-tibble and r-cran-interval)
r-cran-spacetime (needs r-cran-interval)
r-cran-uwot (needs r-cran-fnn)
r-cran-xopen (needs r-cran-ps)


So this is where R 4.3.[01] will possibly break with some older packages.
But the fix is simple because when R 4.3.0 came out all packages at CRAN
complied. We need to have current packages that correspond to the R 4.3.0
standard.


And Andreas already ensured (nearly) everything is rebuild by now, so 
that part is done. To be clear, I think I understand it when you say 
this is not caused by r-base, but rather by those packages that need 
rebuilding with the new r-base. However, to ensure those packages are 
upgraded alongside r-base, r-base needs to force that. And that's why 
there is the Breaks.


I think the list is now:
r-cran-cairo (<= 1.6-0-1)
r-cran-fnn (<= 1.1.3.1-1)
r-cran-magick (<= 2.7.3+dfsg-3)
r-cran-ps (<= 1.7.2-1)
r-cran-ragg (<= 1.2.5-1)
r-cran-svglite (<= 2.1.1-1)
r-cran-tibble (<= 3.1.8+dfsg-1)
r-cran-tikzdevice (<= 0.12.4-1)
r-cran-vdiffr (<= 1.0.5-1)


they built with. My point is that the accept-vs-break comes from the package,
not from R.)


Sure, but the package in testing and stable can't (easily) tell that 
anymore in their relationships as they are already shipped, so packages 
moving into testing should solve it. I think only r-base is in the 
position to add the right Breaks.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040709: gettext: Please disable java dep on hurd-amd64

[Samuel Thibault]

Santiago Vila, le dim. 09 juil. 2023 21:49:21 +0200, a ecrit:
> El 9/7/23 a las 20:27, Samuel Thibault escribió:
> > Package: gettext
> > Version: 0.21-12
> > Severity: important
> > Tags: patch
> > 
> > Hello,
> > 
> > We are in the process of bootstrapping hurd-amd64, and gettext comes
> > early :)
> > 
> > Could you apply the attached patch to drop the java dependency on
> > hurd-amd64 too?
> 
> Looks ok. However, for completeness: should not we also change "hurd-i386"
> to "hurd-any" in debian/gettext.install and debian/not-installed as well?

Oh, right! I missed diffing them.

Samuel

Bug#1032186: Further patch to improve things?

[Steve McIntyre]

Hey,

The first patch committed here allows people to uninstall
raspi-firmware more easily. I suggest the attached to make things
easier for people even before that removal...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer
>From 75142eda35e6554d6f40ee2501e9cef1607a6f06 Mon Sep 17 00:00:00 2001
From: Steve McIntyre 
Date: Sun, 9 Jul 2023 20:29:51 +0100
Subject: [PATCH] Don't attempt to do anything with /boot/firmware unless we're

running on an arm-based system. #1032186 again.
---
 debian/kernel/postinst.d/z50-raspi-firmware | 14 ++
 debian/raspi-firmware.postinst  | 15 +++
 2 files changed, 29 insertions(+)

diff --git a/debian/kernel/postinst.d/z50-raspi-firmware b/debian/kernel/postinst.d/z50-raspi-firmware
index 9b3bfa5..b4a2d75 100755
--- a/debian/kernel/postinst.d/z50-raspi-firmware
+++ b/debian/kernel/postinst.d/z50-raspi-firmware
@@ -27,11 +27,25 @@ pi_4_family() {
   grep -q 'Raspberry Pi \(Compute Module \)*4' /sys/firmware/devicetree/base/model 2>/dev/null
 }
 
+is_arm_system() {
+  # Check to see if the host is running an arm-based system
+  # (i.e. whether the raspi-firmware package is useful)
+  DPKG_ARCH=$(dpkg-architecture -q DEB_TARGET_ARCH)
+  case "$DPKG_ARCH" in
+arm64|armel|armhf)
+  return 0;;
+*)
+  return 1;;
+  esac
+}
 
 if ischroot ; then
   true # chroot detected - skip mount point check
 elif [ -e /usr/bin/systemd-detect-virt ] && systemd-detect-virt -q ; then
   true # virtualization detected - skip mount point check
+elif ! is_arm_system ; then
+  echo "$0: Not running on an arm-based system, doing nothing"
+  exit 0
 elif ! mountpoint -q /boot/firmware ; then
   echo "raspi-firmware: missing /boot/firmware, did you forget to mount it?" >&2
   exit 1
diff --git a/debian/raspi-firmware.postinst b/debian/raspi-firmware.postinst
index 8ecc5f3..22e86d3 100644
--- a/debian/raspi-firmware.postinst
+++ b/debian/raspi-firmware.postinst
@@ -3,6 +3,18 @@
 
 set -e
 
+is_arm_system() {
+  # Check to see if the host is running an arm-based system
+  # (i.e. whether the raspi-firmware package is useful)
+  DPKG_ARCH=$(dpkg-architecture -q DEB_TARGET_ARCH)
+  case "$DPKG_ARCH" in
+arm64|armel|armhf)
+  return 0;;
+*)
+  return 1;;
+  esac
+}
+
 case "$1" in
   configure)
 
@@ -10,6 +22,9 @@ case "$1" in
   true # chroot detected - skip mount point check
 elif test -e /usr/bin/systemd-detect-virt && systemd-detect-virt -q ; then
   true # virtualization detected - skip mount point check
+elif ! is_arm_system ; then
+  echo "$0: Not running on an arm-based system, doing nothing"
+  exit 0
 elif ! mountpoint -q /boot/firmware; then
   echo "Error: missing /boot/firmware, did you forget to mount it?" >&2
   exit 1
-- 
2.30.2

Bug#1040709: gettext: Please disable java dep on hurd-amd64

[Santiago Vila]

El 9/7/23 a las 20:27, Samuel Thibault escribió:

Package: gettext
Version: 0.21-12
Severity: important
Tags: patch

Hello,

We are in the process of bootstrapping hurd-amd64, and gettext comes
early :)

Could you apply the attached patch to drop the java dependency on
hurd-amd64 too?


Looks ok. However, for completeness: should not we also change "hurd-i386"
to "hurd-any" in debian/gettext.install and debian/not-installed as well?

Thanks.

Bug#987503:

[Richard Hartmann]

On Sun, Jul 9, 2023 at 7:48 PM Cyril Brulebois  wrote:

> For the avoidance of doubt, the relevant partman-auto code is present
> in buster, bullseye, and bookworm.

Thanks for the correction; I was under the impression that this has
been more recent. I don't install my systems very often, basically
only when I get a new machine. Debian Just Works(TM), as you certainly
know. Now that I think about it, I do remember that I had to partition
the Gen 7 by hand as well though I had forgotten the details as to
why.

Bug#1040714: dhcpcd: Missing epoch from souce package version

[Salvatore Bonaccorso]

Hi,

On Sun, Jul 09, 2023 at 10:29:58PM +0300, Martin-Éric Racine wrote:
> On Sun, Jul 9, 2023 at 10:27 PM Salvatore Bonaccorso  
> wrote:
> >
> > Source: dhcpcd
> > Version: 10.0.1-1
> > Severity: serious
> > Justification: Debian version goes backwards from previous released versions
> > X-Debbugs-Cc: car...@debian.org
> >
> > Hi
> >
> > The new src:dhcpcd has a lower version of any previous released
> > src:dhcpd version, which had an epoch:
> >
> > 1:3.2.3-11+deb7u1
> > 1:3.2.3-11
> > 1:3.2.3-10
> > 1:3.2.3-9
> > 1:3.2.3-8
> > 1:3.2.3-7
> > 1:3.2.3-6
> > 1:3.2.3-5+squeeze2
> > 1:3.2.3-5+squeeze1
> > 1:3.2.3-5
> > 1:3.2.3-4
> > 1:3.2.3-3
> > 1:3.2.3-2
> > 1:3.2.3-1.1
> > 1:3.2.3-1
> > 1:3.2.2-1
> > 1:3.0.17-2
> > 1:3.0.17-1
> > 1:2.0.3-1
> > 1:2.0.2-1
> > 1:2.0.1-1
> > 1:2.0.0-2
> > 1:2.0.0-1
> > 1:1.3.22pl4-22
> > 1:1.3.22pl4-21sarge1
> > 1:1.3.22pl4-21
> > 1:1.3.22pl4-20
> > 1:1.3.17pl2-8.1
> > 1:1.3.17pl2-8
> > 1:0.70-5
> > 1.3.8-0.1
> > 0.70-3
> > 0.6-1
> > 0.4-1
> >
> > Regards,
> > Salvatore
> 
> This was already reported at #1037190. Closing.

I'm aware of #1037190.

I'm talking though about the *source* package version, not the
produced dhcpcd binary packages. That is versions now uploaded are
lower than previous ones in the archive for the source package still
even if the dhcpcd binary package introduced the epoch.

Regards,
Salvatore

Bug#1040714: dhcpcd: Missing epoch from souce package version

[Martin-Éric Racine]

On Sun, Jul 9, 2023 at 10:33 PM Salvatore Bonaccorso  wrote:
> On Sun, Jul 09, 2023 at 09:25:33PM +0200, Salvatore Bonaccorso wrote:
> > Source: dhcpcd
> > Version: 10.0.1-1
> > Severity: serious
> > Justification: Debian version goes backwards from previous released versions
> > X-Debbugs-Cc: car...@debian.org
> >
> > Hi
> >
> > The new src:dhcpcd has a lower version of any previous released
> > src:dhcpd version, which had an epoch:
>
> Apologies for the typo, should be src:dhcpcd in both cases obviously
> :(

Which is a slightly different issue than what Andtreas reported at
#1037190.  Sorry.

Unless I'm mistaken, we're basically looking at 2 separate issues:

1) bin:dhcpcd from Wheezy has a higher epoch that the one in Bookworm.
This is easily fixed as explained in #1037190 for Bookworm.

2) Since transiting the source from src:dhcpcd5 to src:dhcpcd we're
missing an epoch for everything. This requires reverting the above fix
and simply introducing an epoch for the whole src and binaries.

Or have I misunderstood the issue?

Martin-Éric

Bug#1040714: dhcpcd: Missing epoch from souce package version

[Martin-Éric Racine]

On Sun, Jul 9, 2023 at 10:27 PM Salvatore Bonaccorso  wrote:
>
> Source: dhcpcd
> Version: 10.0.1-1
> Severity: serious
> Justification: Debian version goes backwards from previous released versions
> X-Debbugs-Cc: car...@debian.org
>
> Hi
>
> The new src:dhcpcd has a lower version of any previous released
> src:dhcpd version, which had an epoch:
>
> 1:3.2.3-11+deb7u1
> 1:3.2.3-11
> 1:3.2.3-10
> 1:3.2.3-9
> 1:3.2.3-8
> 1:3.2.3-7
> 1:3.2.3-6
> 1:3.2.3-5+squeeze2
> 1:3.2.3-5+squeeze1
> 1:3.2.3-5
> 1:3.2.3-4
> 1:3.2.3-3
> 1:3.2.3-2
> 1:3.2.3-1.1
> 1:3.2.3-1
> 1:3.2.2-1
> 1:3.0.17-2
> 1:3.0.17-1
> 1:2.0.3-1
> 1:2.0.2-1
> 1:2.0.1-1
> 1:2.0.0-2
> 1:2.0.0-1
> 1:1.3.22pl4-22
> 1:1.3.22pl4-21sarge1
> 1:1.3.22pl4-21
> 1:1.3.22pl4-20
> 1:1.3.17pl2-8.1
> 1:1.3.17pl2-8
> 1:0.70-5
> 1.3.8-0.1
> 0.70-3
> 0.6-1
> 0.4-1
>
> Regards,
> Salvatore

This was already reported at #1037190. Closing.

Martin-Éric

Bug#1040714: dhcpcd: Missing epoch from souce package version

[Salvatore Bonaccorso]

Hi,

On Sun, Jul 09, 2023 at 09:25:33PM +0200, Salvatore Bonaccorso wrote:
> Source: dhcpcd
> Version: 10.0.1-1
> Severity: serious
> Justification: Debian version goes backwards from previous released versions
> X-Debbugs-Cc: car...@debian.org
> 
> Hi
> 
> The new src:dhcpcd has a lower version of any previous released
> src:dhcpd version, which had an epoch:

Apologies for the typo, should be src:dhcpcd in both cases obviously
:(

Regards,
Salvatore

Bug#1040690: emacs-el: Warnings resulting from org-mode source files not found

[Nicholas D Steeves]

Control: tag -1 confirmed
Control: tag -1 affects dh-elpa
Control: tag -1 severity important
# Justification: Causes packages to not upgrade cleanly

Hello,

Balbir Thomas  writes:

> Package: emacs-el
> Version: 1:28.2+1-15
> Severity: normal
>
> Dear Maintainer,
>
> On starting emacs 28 in bookworm various warnings are displayed because
> elisp source files (mostly for) org-mode are not found. 
[snip]

Thank you for filing this bug Balbir!  I wonder if you reported this
against emacs-el, because your hypothesis is that this is an
Emacs28-related bug?  Two things that stand out in your list to me are
esxml, and markdown-mode, because these are elpa-only packages that
don't overlap with files provided by emacs-el.  Consequently, I wonder
if this bug is on the dh-elpa side rather than the emacs-el side.

I have the following list, with the notable omission of org mode,
because I had uninstalled elpa-org before upgrading from bullseye to
bookworm:

  /usr/share/emacs/site-lisp/elpa/seq-2.22/seq.elc
  /usr/share/emacs/site-lisp/elpa/seq-2.22/seq-25.elc
  /usr/share/emacs/site-lisp/elpa/git-commit-2.99.0/git-commit.elc
  /usr/share/emacs/site-lisp/elpa/dash-2.17.0/dash.elc
  /usr/share/emacs/site-lisp/elpa/transient-0.2.0.30/transient.elc
  /usr/share/emacs/site-lisp/elpa/async-1.9.3/async-bytecomp.elc
  /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc
  /usr/share/emacs/site-lisp/elpa/with-editor-3.0.2/with-editor.elc
  /usr/share/emacs/site-lisp/elpa/hl-todo-3.1.2/hl-todo.elc

> There are broken symlinks to source files in the directory 
> /usr/share/emacs/site-lisp/elpa/org-9.4/
> The symlinks point to files in the directory 
> /usr/share/emacs/site-lisp/elpa-src/org-9.4/ which
> does not exist.

I suspect bullseye2bookworm is a trigger condition, and here an example
of where things get weird:

  Given /usr/share/emacs/site-lisp/elpa/with-editor-3.0.2/with-editor.elc
  # dpkg -S   /usr/share/emacs/site-lisp/elpa/with-editor-3.0.2/with-editor.elc
dpkg-query: no path found matching pattern 
/usr/share/emacs/site-lisp/elpa/with-editor-3.0.2/with-editor.elc
  # cruft /usr/share/emacs/site-lisp/
  returns no matches

Cruft should find matches, but doesn't !  Yes, I've also done a full
cruft run, and have grepped for with-editor, for example.

One final bit of data:

Your list has

  /usr/share/emacs/site-lisp/elpa/markdown-mode-2.4/markdown-mode.elc

but mine doesn't.  I remember that I had manually upgraded to
elpa-markdown 2.5 long ago, so this was the version that was present
during the bullseye2bookworm upgrade.  Consequently, it seems that the
version of the elpa-foo package needs to change during bullseye2bookworm
process in order to trigger this bug.


'hope this helps identify what's going on!
Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1037190: closed by Debian FTP Masters (reply to Martin-Éric Racine ) (Bug#1037190: fixed in dhcpcd 10.0.1-1)

[Martin-Éric Racine]

On Sun, Jul 9, 2023 at 4:32 PM Martin-Éric Racine
 wrote:
>
> On Sat, Jul 8, 2023 at 12:57 PM Martin-Éric Racine
>  wrote:
> >
> > On Sat, Jul 8, 2023 at 12:42 PM Andreas Beckmann  wrote:
> > > Thanks for fixng it in sid. Please backport the epoch related changes to
> > > src:dhcpcd5 and get this fix into bookworm-pu over the next week s.t. it
> > > can be included in the first point release.
> >
> > Welcome.
> >
> > I'm still missing the dhcpcd.preinst patch you submitted. I was
> > waiting for 10.0.1-1, which was already sitting in NEW, to get
> > accepted into the archive to merge it. I can do this now.
>
> The preinst in included in 10.0.1-2 and waiting on Mentors.
>
> > For bookworm-pu, I welcome feedback on any other cherry-pick since
> > 9.4.1-22 that would be worth including. I'll also need a sponsor to
> > ensure timely upload for Bookworm's point release.
>
> If you have a debdiff for Bookworm, please attach it to this bug.

This is what I would push to stable-proposed-updates (see attachment).
Would this do the trick? If yes, I can upload to Mentors. If not,
please explain.

Martin-Éric
diff -Nru dhcpcd5-9.4.1/debian/changelog dhcpcd5-9.4.1/debian/changelog
--- dhcpcd5-9.4.1/debian/changelog  2023-05-29 10:45:31.0 +0300
+++ dhcpcd5-9.4.1/debian/changelog  2023-07-09 22:22:47.0 +0300
@@ -1,6 +1,16 @@
+dhcpcd5 (9.4.1-24+deb12u1) stable-proposed-updates; urgency=medium
+
+  * Backported Wheezy upgrade mitigation from unstable (see #1037190):
++ Include /usr/share/dpkg/pkg-info.mk needed for target version mingling.
++ Add epoch to bin:dhcpcd via override_dh_gencontrol.
+  Wheezy had (1:3.2.3-11+deb7u1) so reintroduce the epoch for one target.
++ Add dhcpcd.preinst by Andreas Beckmann to cleanup upgrade leftovers.
+
+ -- Martin-Éric Racine   Sun, 09 Jul 2023 22:22:47 
+0300
+
 dhcpcd5 (9.4.1-24) unstable; urgency=medium
 
-  * Upload to unstable
+  * Upload to unstable.
 
  -- Martin-Éric Racine   Mon, 29 May 2023 15:45:31 
+0800
 
diff -Nru dhcpcd5-9.4.1/debian/copyright dhcpcd5-9.4.1/debian/copyright
--- dhcpcd5-9.4.1/debian/copyright  2023-05-24 16:29:33.0 +0300
+++ dhcpcd5-9.4.1/debian/copyright  2023-07-09 22:09:15.0 +0300
@@ -4,7 +4,7 @@
 Upstream-Contact: Roy Marples 
 
 Files: *
-Copyright: 2006-2018  Roy Marples 
+Copyright: 2006-2023  Roy Marples 
1999, 2016 The NetBSD Foundation, Inc.
2005 Colin Percival
2005 The DragonFly Project.  All rights reserved.
@@ -68,6 +68,7 @@
2015 Daniel Echeverry 
2018 Scott Leggett 
2022-2023 Martin-Éric Racine 
+   2023 Andreas Beckmann 
 License: BSD-2
 
 Files: debian/hooks/*
diff -Nru dhcpcd5-9.4.1/debian/dhcpcd.preinst 
dhcpcd5-9.4.1/debian/dhcpcd.preinst
--- dhcpcd5-9.4.1/debian/dhcpcd.preinst 1970-01-01 02:00:00.0 +0200
+++ dhcpcd5-9.4.1/debian/dhcpcd.preinst 2023-07-09 22:07:22.0 +0300
@@ -0,0 +1,14 @@
+#!/bin/sh
+# As per Debian bug #1037190.
+# Copyright 2023 Andreas Beckmann 
+set -e
+if dpkg --compare-versions "$2" lt-nl "1:9.4.1-24+deb12u1~" ; then
+  # Cleanup leftovers from dhcpcd 1:3.* in Wheezy.
+  # Can be removed after Trixie is released.
+  update-alternatives --remove dhcpcd /sbin/dhcpcd3
+  if [ -d /etc/dhcpc ]; then
+test ! -h /etc/dhcpc/resolv.conf || rm -fv /etc/dhcpc/resolv.conf
+rmdir --ignore-fail-on-non-empty /etc/dhcpc
+  fi
+fi
+#DEBHELPER#
diff -Nru dhcpcd5-9.4.1/debian/rules dhcpcd5-9.4.1/debian/rules
--- dhcpcd5-9.4.1/debian/rules  2023-05-24 16:29:33.0 +0300
+++ dhcpcd5-9.4.1/debian/rules  2023-07-09 22:14:37.0 +0300
@@ -1,4 +1,5 @@
 #!/usr/bin/make -f
+include /usr/share/dpkg/pkg-info.mk
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
@@ -12,8 +13,12 @@
--libexecdir=/usr/lib/dhcpcd \
--rundir=/run/dhcpcd
 
-# avoid starting the unconfigured service as it may break connectivity
+# Wheezy had (1:3.2.3-11+deb7u1) so reintroduce the epoch for one target.
+override_dh_gencontrol:
+   dh_gencontrol --package=dhcpcd -- -v1:$(DEB_VERSION_UPSTREAM_REVISION)
+   dh_gencontrol --remaining-packages
 
+# Avoid starting the unconfigured service as it may break connectivity.
 override_dh_installinit:
dh_installinit --name=dhcpcd --no-start
 

Bug#1040715: fzf: shell completions and key-bindings are not documentation files

[sodaqx+9gfblr460dt0k]

Package: fzf
Version: 0.38.0-1+b1
Severity: normal

Dear Maintainer,

fzf currently installs shell completion and key-bindings files into:
/usr/share/doc/fzf/examples/

However these files are not documentation files, they are intended to be used 
by the user, by sourcing them in their shell configuration files. Therefore, 
the files don't belong in the doc location.

For comparison, this is the location that archlinux puts those files into:
usr/
usr/bin/
usr/bin/fzf
usr/bin/fzf-tmux
usr/share/
usr/share/fish/
usr/share/fish/vendor_functions.d/
usr/share/fish/vendor_functions.d/fzf_key_bindings.fish
usr/share/fzf/
usr/share/fzf/completion.bash
usr/share/fzf/completion.zsh
usr/share/fzf/key-bindings.bash
usr/share/fzf/key-bindings.zsh
usr/share/licenses/
usr/share/licenses/fzf/
usr/share/licenses/fzf/LICENSE
usr/share/man/
usr/share/man/man1/
usr/share/man/man1/fzf-tmux.1.gz
usr/share/man/man1/fzf.1.gz
usr/share/vim/
usr/share/vim/vimfiles/
usr/share/vim/vimfiles/doc/
usr/share/vim/vimfiles/doc/fzf.txt
usr/share/vim/vimfiles/plugin/
usr/share/vim/vimfiles/plugin/fzf.vim

Please consider installing the shell completion and key-bindings files into:
/usr/share/fzf/

and document this location in /usr/share/doc/fzf/README.Debian

I know that the bash shell completion file is now in a different location, but 
I am a zsh user so that doesn't affect me.

Thank you.


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

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

Versions of packages fzf depends on:
ii  libc6  2.36-9

fzf recommends no packages.

fzf suggests no packages.

-- no debconf information

Bug#1040714: dhcpcd: Missing epoch from souce package version

[Salvatore Bonaccorso]

Source: dhcpcd
Version: 10.0.1-1
Severity: serious
Justification: Debian version goes backwards from previous released versions
X-Debbugs-Cc: car...@debian.org

Hi

The new src:dhcpcd has a lower version of any previous released
src:dhcpd version, which had an epoch:

1:3.2.3-11+deb7u1
1:3.2.3-11
1:3.2.3-10
1:3.2.3-9
1:3.2.3-8
1:3.2.3-7
1:3.2.3-6
1:3.2.3-5+squeeze2
1:3.2.3-5+squeeze1
1:3.2.3-5
1:3.2.3-4
1:3.2.3-3
1:3.2.3-2
1:3.2.3-1.1
1:3.2.3-1
1:3.2.2-1
1:3.0.17-2
1:3.0.17-1
1:2.0.3-1
1:2.0.2-1
1:2.0.1-1
1:2.0.0-2
1:2.0.0-1
1:1.3.22pl4-22
1:1.3.22pl4-21sarge1
1:1.3.22pl4-21
1:1.3.22pl4-20
1:1.3.17pl2-8.1
1:1.3.17pl2-8
1:0.70-5
1.3.8-0.1
0.70-3
0.6-1
0.4-1

Regards,
Salvatore

Bug#987503:

[Rainer Dorsch]

Am Sonntag, 9. Juli 2023, 19:35:53 CEST schrieb Richard Hartmann:
> I tried hibernation on Thinkpad X1 Carbon Gen 1, Gen 5, Gen 7, and Gen
> 11. They all work. As per
> https://chaos.social/@waldi/110683468203241035 , I believe that the
> definition of "modern system" Waldi refers to means catering to a
> Windows world, something not deeply relevant to the Debian use case.

I can a a data point:

For a new HP Laptop 17-cp2xxx with an AMD Ryzen 5 7520U hibernation also works 
flawless with an correctly sized swap partition.

Regards
Rainer


-- 
Rainer Dorsch
http://bokomoko.de/

Bug#1040712: installation-reports Debian 12

[Cyril Brulebois]

Salut Jacques,

Jacques Rubin  (2023-07-09):
> #
> Comments/Problems: Problems with package installation (alien, gdm3,
> default-jre, etc...). Example of installing alien with the command line: $
> sudo apt-get install alien . Problem with the linux-image-6.1.0-10-amd64
> package when the installed package is linux-image-6.1.0-9-amd64.
> #
> Parameter setting for linux-image-6.1.0-10-amd64 (6.1.37-1) ...
> /etc/kernel/postinst.d/initramfs-tools:
> update-initramfs: Generating /boot/initrd.img-6.1.0-10-amd64
> I: The initramfs will attempt to resume from /dev/sda3
> I: (UUID=eafc18cf-23e3-43e6-8bce-6784d60e3a92)
> I: Set the RESUME variable to override this.
> raspi-firmware: missing /boot/firmware, did you forget to mount it?
> run-parts: /etc/initramfs/post-update.d//z50-raspi-firmware exited with
> return code 1
> run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
> dpkg: erreur de traitement du paquet linux-image-6.1.0-10-amd64
> (--configure) :
>  le sous-processus paquet linux-image-6.1.0-10-amd64 script
> post-installation installé a renvoyé un état de sortie d'erreur 1

I suppose this is an installation done from the live image? In that case
that's a known bug that will be fixed for 12.1 (to be released in 2
weeks).


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


signature.asc
Description: PGP signature

Bug#1013356: fzf: Bash completions not active by default

[sodaqx+9gfblr460dt0k]

Package: fzf
Version: 0.38.0-1+b1
Followup-For: Bug #1013356

Dear Maintainer,

I confirm that this issue exists in fzf in the version released in Debian 12 
(bookworm) stable.

The only thing that needs changing is documenting the workaround in the 
/usr/share/doc/fzf/README.Debian so that people know they have to source the 
bash completions file manually in their bashrc

Bug#1040713: bookworm-pu: package installation-guide/20230508+deb12u1

[Holger Wansing]

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

Hi,

some months ago, we received a new, complete translation of the 
installation-guide
into Indonesian.
However, I failed to turn all needed wheels, to get this translation into the
package completely. 
Therefore, Indonesian translation is currently not visible on debian.org :-(

So I ask for this minor update to get that into stable (bookworm).

debdiff attached.

Thanks for considering.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff -Nru installation-guide-20230508/debian/changelog 
installation-guide-20230508+deb12u1/debian/changelog
--- installation-guide-20230508/debian/changelog2023-05-08 
22:47:33.0 +0200
+++ installation-guide-20230508+deb12u1/debian/changelog2023-07-09 
15:25:17.0 +0200
@@ -1,3 +1,11 @@
+installation-guide (20230508+deb12u1) bookworm; urgency=medium
+
+  [ Holger Wansing ]
+  * Add Indonesian (as a recently added new translation) to langlist, to get
+this translation into the package.
+
+ -- Samuel Thibault   Sun, 09 Jul 2023 15:25:17 +0200
+
 installation-guide (20230508) unstable; urgency=medium
 
   [ Samuel Thibault ]
diff -Nru installation-guide-20230508/debian/langlist 
installation-guide-20230508+deb12u1/debian/langlist
--- installation-guide-20230508/debian/langlist 2023-05-08 22:47:33.0 
+0200
+++ installation-guide-20230508+deb12u1/debian/langlist 2023-06-23 
01:16:32.0 +0200
@@ -12,6 +12,7 @@
 #fiFinnish
 fr French
 #huHungarian
+id Indonesian
 it Italian
 ja Japanese
 #kab   Kabyle

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Dirk Eddelbuettel]

Hi Paul,

On 9 July 2023 at 20:11, Paul Gevers wrote:
| On 09-07-2023 18:41, Dirk Eddelbuettel wrote:
| > On 9 July 2023 at 17:40, Paul Gevers wrote:
| > | Did we already discuss that r-cran-ps also seems to be impacted by the
| > | r-base change of the symbols thingy, as can be seen in r-cran-xopen [1].
| > 
| > Correct me if I am wrong but the "symbols thingy" was not a change in R 
4.2.*
| > to R 4.3.*. It was a change by some packages opting into different behavior.
| 
| I don't understand this then. For several packages we're seeing failures 
| in testing even if we only use r-base from unstable and everything else 
| from testing to run the test. They pass with a rebuild r-cran-fnn and/or 
| a rebuild and updated r-cran-ps, and/or r-cran-tibble. (Sorry, in my 
| previous message I think I added r-cran-dplyr by mistake, misremembered).

It would be useful to break this down into concrete reproducible examples.

| > |   33s  10. ps:::not_null(.Call("psll_connections", p))
| > 
| > Tis would be a bug in r-cran-ps and I think a Breaks may be warranted.
| 
| Ok, let's remember this.
| 
| > Given
| > that ps always had 'native symbols', maybe testthat changed?
| 
| But I think (I would need to check for the autopkgtest fallback) in none 
| of the tests, the version of testthat in testing changed between passing 
| and failing tests. Would testthat embed something during the build of 
| the binaries (from the name, I would assume not)?

I don't think it would do anything _explicit_.

I think what we are seeing is simply 'fragility from some packages with
larger tails'. If you install 'testthat' (presumably just to run tests) you
end up with with 30+ packages loaded (without considering Suggests:). It is
similar with other 'tidyverse' packages (dplyr, tibble, vctrs, ...) are all
part of that.
 
| > | Same for r-cran-fnn, which impacts r-cran-uwof [2].

I just looked at FNN, it is very narrow package at its core, it gets a bit of
tail via the Suggests of chemometrics.

| > | I think what we should do is add a versioned Breaks in r-base on
| > | , r-cran-ps, r-cran-tibble,
| > | r-cran-dplyr, r-cran-fnn. I think that's the right thing to do for
| > 
| > I think it would be best to work out to corresponding package pairings and
| > apply the Breaks to them. If we can.
| 
| Sure, lets add the Breaks to the place where it belongs.
| 
| > For spacetime and stars I suspect (based on past experience) possible
| > interaction from the underlying graphics libraries.
| 
| Good to hear, didn't check yet, but will shortly (geospatial).

It's a complex block. spacetime is one of the older ones using 'sp' (and then
'raster' via Suggests), 'stars' is newer using 'sf'. Sometimes these prefer /
work better with a consistent rebuild.
 
| > If I am not mistaken all of these were already in the Excuses list before we
| > made addition of the r-graphics-engine-* tag (which was taken care of for R
| > 4.3.* already, having it may help if another change happens like that).
| 
| Sure, I'd hope the r-graphics-engine-* Provides only reduced issue, so 
| I'm currently considering them to be different. But I might be proven 
| wrong easily.

I don't think it had a net effect this.  The 
| 
| > Unfortunately I find
| > the reports a little hard to read and am hence not very efficient at
| > pinpointing underlying causes. Above you pointed eg at [2] for uwot, I see 
no
| > error in there :-/
| 
| Well, that log has two tests. The first second one passes, the first one 
| has:
|   51s > library(testthat)
|   51s > library(uwot)
|   51s Loading required package: Matrix
|   53s >
|   53s > test_check("uwot")
|   53s Error in FNN::get.knn(X, k) : DLL requires the use of native symbols
|   53s Calls: test_check ... eval -> create_data -> find_nn -> FNN_nn -> 
| 
|   53s Execution halted

But uwot itself does not force symbols:

  https://github.com/jlmelville/uwot/blob/master/src/RcppExports.cpp#L228-L231

and I mentioned, using just those two lines in common. So the forceSymbols
comes from somewhere else.

Ok, I rechecked.  R 4.3.0 has this

* Attempting to use a character string naming a foreign function
  entry point in a foreign function call in a package will now
  signal an error if the packages has called R_forceSymbols to
  specify that symbols must be used.

It used to _ignore_ the combinatation of calling R_forceSymbols _and_ use of
non-symbols / quoted identifiers.  Now it errors: if you have R_forceSymbols
each .Call() will require symbols (not strings).

So this is where R 4.3.[01] will possibly break with some older packages.
But the fix is simple because when R 4.3.0 came out all packages at CRAN
complied. We need to have current packages that correspond to the R 4.3.0
standard.

(If one were super picky one could call this an ABI/API change and reason for
forcing _all_ packages to be rebuild. I never advocated for that but I am
getting tired of this process. But we need to throw that bomb at some point
just 

Bug#1040712: installation-reports Debian 12

[Jacques Rubin]

Package: installation-reports Debian 12

Boot method: USB key - amd64
Image version:  Debian 12 Bookworm - Last updated: Sat, 10 Jun 2023
08:51:17 +
Date: sunday 9 july 2023, 20:05

Machine: Dell Latitude 5580 intel core i5 7th Gen.
Processor: Intel© Core™ i5-7440HQ CPU @ 2.80GHz × 4
Memory: 8.0 Go
Partitions: df -Tl
Sys. of filesType blocs of 1K Used Availability Use% Mounted on
udev devtmpfs 395650003956500   0% /dev
tmpfstmpfs 800244 1700 798544   1% /run
/dev/sda2ext4   470208136 17089220  429160168   4% /
tmpfstmpfs400121604001216   0% /dev/shm
tmpfstmpfs   5120   12   5108   1% /run/lock
/dev/sda1vfat  306572 5976 300596   2% /boot/efi
tmpfstmpfs 800240   80 800160   1%
/run/user/1000


Result of lspci -knn (or lspci -nn) :
#
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core
Processor Host Bridge/DRAM Registers [8086:5910] (rev 05)
Subsystem: Dell Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM
Registers [1028:07d1]
Kernel driver in use: skl_uncore
00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor
PCIe Controller (x16) [8086:1901] (rev 05)
Subsystem: Dell 6th-10th Gen Core Processor PCIe Controller (x16)
[1028:07d1]
Kernel driver in use: pcie
port
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630
[8086:591b] (rev 04)
DeviceName:  Onboard IGD
Subsystem: Dell HD Graphics 630 [1028:07d1]
Kernel driver in use: i915
Kernel modules: i915
00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 05)
Subsystem: Dell Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal
Subsystem [1028:07d1]
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device_pci_legacy
00:14.0 USB controller [0c03]: Intel Corporation 100 Series/C230 Series
Chipset Family USB 3.0 xHCI Controller [8086:a12f] (rev 31)
Subsystem: Dell 100 Series/C230 Series Chipset Family USB 3.0 xHCI
Controller [1028:07d1]
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
00:14.2 Signal processing controller [1180]: Intel Corporation 100
Series/C230 Series Chipset Family Thermal Subsystem [8086:a131] (rev 31)
Subsystem: Dell 100 Series/C230 Series Chipset Family Thermal Subsystem
[1028:07d1]
Kernel driver in use: intel_pch_thermal
Kernel modules: intel_pch_thermal
00:15.0 Signal processing controller [1180]: Intel Corporation 100
Series/C230 Series Chipset Family Serial IO I2C Controller #0 [8086:a160]
(rev 31)
Subsystem: Dell 100 Series/C230 Series Chipset Family Serial IO I2C
Controller [1028:07d1]
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci
00:15.1 Signal processing controller [1180]: Intel Corporation 100
Series/C230 Series Chipset Family Serial IO I2C Controller #1 [8086:a161]
(rev 31)
Subsystem: Dell 100 Series/C230 Series Chipset Family Serial IO I2C
Controller [1028:07d1]
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci
00:16.0 Communication controller [0780]: Intel Corporation 100 Series/C230
Series Chipset Family MEI Controller #1 [8086:a13a] (rev 31)
Subsystem: Dell 100 Series/C230 Series Chipset Family MEI Controller
[1028:07d1]
Kernel driver in use: mei_me
Kernel modules: mei_me
00:17.0 SATA controller [0106]: Intel Corporation
Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode]
[8086:a102] (rev 31)
Subsystem: Dell Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller
[AHCI Mode] [1028:07d1]
Kernel driver in use: ahci
Kernel modules: ahci
00:1c.0 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series Chipset
Family PCI Express Root Port #2 [8086:a111] (rev f1)
Subsystem: Dell 100 Series/C230 Series Chipset Family PCI Express Root Port
[1028:07d1]
Kernel driver in use: pcieport
00:1c.2 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series Chipset
Family PCI Express Root Port #3 [8086:a112] (rev f1)
Subsystem: Dell 100 Series/C230 Series Chipset Family PCI Express Root Port
[1028:07d1]
Kernel driver in use: pcieport
00:1c.4 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series Chipset
Family PCI Express Root Port #5 [8086:a114] (rev f1)
Subsystem: Dell 100 Series/C230 Series Chipset Family PCI Express Root Port
[1028:07d1]
Kernel driver in use: pcieport
00:1f.0 ISA bridge [0601]: Intel Corporation CM238 Chipset LPC/eSPI
Controller [8086:a154] (rev 31)
Subsystem: Dell CM238 Chipset LPC/eSPI Controller [1028:07d1]
00:1f.2 Memory controller [0580]: Intel Corporation 100 Series/C230 Series
Chipset Family Power Management Controller [8086:a121] (rev 31)
Subsystem: Dell 100 Series/C230 Series Chipset Family Power Management
Controller [1028:07d1]
00:1f.3 Audio device [0403]: Intel Corporation CM238 HD Audio Controller

Bug#1040711: SDDM's setting 'minimum-vt' is ignored

[Joerg Schiermeier, Bielefeld/Germany]

Package: sddm
Version: 0.20.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

In a former version of SDDM the setting in '/etc/sddm.conf' determine on which 
VT (virtuel terminal tty) an DM will start. In the latest version of sddm this 
setting is ignored.
This should be fixed, so an existing configuration file will work like before.

- -- 
Yours sincerely
Joerg Schiermeier



- -- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), 
LANGUAGE=de:en_GB:es
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init

Versions of packages sddm depends on:
ii  adduser   3.137
ii  debconf [debconf-2.0] 1.5.82
ii  libc6 2.37-5
ii  libelogind-compat [libsystemd0]   246.10-5
ii  libgcc-s1 13.1.0-7
ii  libpam0g  1.5.2-6
ii  libqt5core5a  5.15.8+dfsg-13
ii  libqt5dbus5   5.15.8+dfsg-13
ii  libqt5gui55.15.8+dfsg-13
ii  libqt5network55.15.8+dfsg-13
ii  libqt5qml55.15.8+dfsg-3
ii  libqt5quick5  5.15.8+dfsg-3
ii  libstdc++613.1.0-7
ii  libxau6   1:1.0.9-1
ii  libxcb-xkb1   1.15-1
ii  libxcb1   1.15-1
ii  qml-module-qtquick2   5.15.8+dfsg-3
ii  tigervnc-standalone-server [xserver]  1.12.0+dfsg-8
ii  x11-common1:7.7+23
ii  xauth 1:1.1.2-1
ii  xnest [xserver]   2:21.1.7-3devuan1
ii  xserver-xephyr [xserver]  2:21.1.7-3devuan1
ii  xserver-xorg [xserver]1:7.7+23
ii  xvfb [xserver]2:21.1.7-3devuan1

Versions of packages sddm recommends:
ii  libpam-elogind [libpam-systemd]246.10-5
ii  sddm-theme-breeze [sddm-theme] 4:5.27.5-2+b1
ii  sddm-theme-debian-breeze [sddm-theme]  4:5.27.5-2+b1
ii  sddm-theme-debian-maui [sddm-theme]0.20.0-1
ii  sddm-theme-elarun [sddm-theme] 0.20.0-1
ii  sddm-theme-maldives [sddm-theme]   0.20.0-1
ii  sddm-theme-maui [sddm-theme]   0.20.0-1
ii  sddm-theme-maya [sddm-theme]   0.20.0-1

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.27.5-2
pn  qtvirtualkeyboard-plugin  

- -- Configuration Files:
/etc/pam.d/sddm changed:
authrequisite   pam_nologin.so
authrequiredpam_succeed_if.so user != root quiet_success
@include common-auth
- -auth   optionalpam_kwallet5.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] 
pam_selinux.so close
session optionalpam_keyinit.so force revoke
session requiredpam_limits.so
session requiredpam_loginuid.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] 
pam_selinux.so open
- -session optional   pam_kwallet5.so auto_start
@include common-password
session requiredpam_env.so
session requiredpam_env.so envfile=/etc/default/locale user_readenv=1


- -- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

-BEGIN PGP SIGNATURE-
Comment: This was created by GnuPG for Linux.

iQIzBAEBCAAdFiEERMHJSMoKBiNrvtXJodFQ9YsO8GMFAmSrAfAACgkQodFQ9YsO
8GPIJA//b0gdh18AxIEkF9OOTvcGcp+dkzORL2P21WbFlPIGwNOG4zj4VotQxOXQ
6jge5IeEhip/Zy7DcaisJ0HCPCVmQ6sXJFRqrEffz9Sw9JxLjOdSqrCM2uPEv64V
JZnHzaquJeTV1rotkeKZSR4YDsYx38Gju2NeOMyTlgo243ZFWgrYoKnT20Oevf5F
c+goBvT46igR3KI23Lj368clkf1p3JQbm0peBCotUu8mok723CQ8eCffcdsMP2cK
3qQlOz7iK39z1JqK65ArGjjpJpH7D9FZuBmbU8uxaLEXrj/D8YqP04D137UqvvKJ
ao0gVnRY/IxqrJh0QNpYiqbiX9xtR1XBhZmUitxH6S8OQESAXv8r8kyVkQ5S340i
hTnQKoF+xWUjojt6VFsk+e08fgJ5UxoN1Cycf+3MewH2szj6MfBEJje4/jhr9JOT
WpFRG5cNq6Wa+rUWA9yxRidkxJ/7EXOxQls8sFf+YyN9vlsnkyCUEGe+05gCEHPO
Ltw8pzALhYT+RuJiYQpb/9t5D2l9p6Mk2t80YWk9u7L7KbnuxOTMcwl1HRrUtth6
TW2w6hDIU4Vjlha7zCQEGGMWtu5tIjuWEGI0lKnqOOSit7aMG0YOnh8BXmZYcxs0
04VpNtntVgiS52+XVjjkoI810VmhASXfilR2soBj2d4Yn8u9Ixc=
=kj7a
-END PGP SIGNATURE-

Bug#907853: liblwp-protocol-https-perl: turning off hostname verification does not work

[gregor herrmann]

On Sat, 02 Jan 2021 10:24:52 +0100, Slaven Rezic wrote:

> The problem still exists in debian/testing (libwww-perl 6.50 +
> liblwp-protocol-https-perl 6.09-1 installed here):
> 
> perl -MLWP::UserAgent -e '$ua=LWP::UserAgent->new; 
> $ua->ssl_opts(verify_hostname=>0); $res = 
> $ua->get("https://quartier-heidestrasse.contempo-webcam.de/;); warn 
> $res->as_string'
> 500 Can't connect to quartier-heidestrasse.contempo-webcam.de:443 
> (certificate verify failed)
> Content-Type: text/plain
> Client-Date: Sat, 02 Jan 2021 09:23:22 GMT
> Client-Warning: Internal response
> 
> Can't connect to quartier-heidestrasse.contempo-webcam.de:443 (certificate 
> verify failed)
> 
> SSL connect attempt failed error:1416F086:SSL 
> routines:tls_process_server_certificate:certificate verify failed at 
> /usr/share/perl5/LWP/Protocol/http.pm line 50.

I just tried your example and I don't get any errors.

This is in today's unstable with libwww-perl/6.71-2 and
liblwp-protocol-https-perl 6.10-1.

Could you please try as well?

(Please note that I'm about to upload
liblwp-protocol-https-perl/6.11-1 to unstable).


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1040710: please consider packaging util-linux 2.39 for logger fix

[Marc Haber]

Package: util-linux
Version: 2.38.1-5+b1
Severity: normal

Hi,

logger in util-linux 2.38 has a bug that leads to sending uninitialized
data to a socket, see https://github.com/util-linux/util-linux/issues/2336

This might be the root cause for adduser's autopkgtests failing on s390x
keeping adduser out of testing. In addition, a program should never send
uninitialized data.

The issue in logger is fixed in util-linux 2.39.

Please consider packaging the new version.

Thanks in advance!

Greetings
Marc

Bug#1040709: gettext: Please disable java dep on hurd-amd64

[Samuel Thibault]

Package: gettext
Version: 0.21-12
Severity: important
Tags: patch

Hello,

We are in the process of bootstrapping hurd-amd64, and gettext comes
early :)

Could you apply the attached patch to drop the java dependency on
hurd-amd64 too?

Thanks,
Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.3.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 gettext depends on:
ii  gettext-base   0.21-12
ii  libc6  2.37-3
ii  libgomp1   13.1.0-6
ii  libunistring2  1.0-2
ii  libxml22.9.14+dfsg-1.2

Versions of packages gettext recommends:
ii  curl  7.88.1-10
ii  lynx  2.9.0dev.12-1
ii  wget  1.21.3-1+b2

Versions of packages gettext suggests:
ii  autopoint 0.21-12
pn  gettext-doc   
ii  libasprintf-dev   0.21-12
ii  libgettextpo-dev  0.21-12

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-07-09 20:25:19.629023690 +0200
+++ debian/control  2023-07-09 20:25:22.689041786 +0200
@@ -5,14 +5,14 @@
 Standards-Version: 4.6.2
 Build-Depends: bison,
debhelper-compat (= 13),
-   default-jdk [!hppa !hurd-i386 !kfreebsd-any] ,
+   default-jdk [!hppa !hurd-any !kfreebsd-any] ,
dh-exec (>= 0.13),
file,
groff,
help2man,
libunistring-dev,
libxml2-dev,
-   maven-repo-helper [!hppa !hurd-i386 !kfreebsd-any] ,
+   maven-repo-helper [!hppa !hurd-any !kfreebsd-any] ,
xz-utils
 Build-Depends-Indep: dh-sequence-elpa
 Homepage: https://www.gnu.org/software/gettext/

Bug#1040708: Wrong database scheme for postgresql

[duck]

Package: mailman3
Version: 3.3.8-1


Quack,

The generated configuration in /etc/mailman3/mailman.cfg contains a 
database URL with the postgres:// scheme but this has long been 
deprecated in SQLAlchemy and needs to be replaced with postgresql://. 
The service refused to start without this change after migrating to 
Bookworm.


Regards.
\_o<

--
Marc Dequènes

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi Dirk,

Thanks.

On 09-07-2023 18:41, Dirk Eddelbuettel wrote:

On 9 July 2023 at 17:40, Paul Gevers wrote:
| Did we already discuss that r-cran-ps also seems to be impacted by the
| r-base change of the symbols thingy, as can be seen in r-cran-xopen [1].

Correct me if I am wrong but the "symbols thingy" was not a change in R 4.2.*
to R 4.3.*. It was a change by some packages opting into different behavior.


I don't understand this then. For several packages we're seeing failures 
in testing even if we only use r-base from unstable and everything else 
from testing to run the test. They pass with a rebuild r-cran-fnn and/or 
a rebuild and updated r-cran-ps, and/or r-cran-tibble. (Sorry, in my 
previous message I think I added r-cran-dplyr by mistake, misremembered).



|   33s  10. ps:::not_null(.Call("psll_connections", p))

Tis would be a bug in r-cran-ps and I think a Breaks may be warranted.


Ok, let's remember this.


Given
that ps always had 'native symbols', maybe testthat changed?


But I think (I would need to check for the autopkgtest fallback) in none 
of the tests, the version of testthat in testing changed between passing 
and failing tests. Would testthat embed something during the build of 
the binaries (from the name, I would assume not)?



| Same for r-cran-fnn, which impacts r-cran-uwof [2].
|
| I think what we should do is add a versioned Breaks in r-base on
| , r-cran-ps, r-cran-tibble,
| r-cran-dplyr, r-cran-fnn. I think that's the right thing to do for

I think it would be best to work out to corresponding package pairings and
apply the Breaks to them. If we can.


Sure, lets add the Breaks to the place where it belongs.


For spacetime and stars I suspect (based on past experience) possible
interaction from the underlying graphics libraries.


Good to hear, didn't check yet, but will shortly (geospatial).


If I am not mistaken all of these were already in the Excuses list before we
made addition of the r-graphics-engine-* tag (which was taken care of for R
4.3.* already, having it may help if another change happens like that).


Sure, I'd hope the r-graphics-engine-* Provides only reduced issue, so 
I'm currently considering them to be different. But I might be proven 
wrong easily.



Unfortunately I find
the reports a little hard to read and am hence not very efficient at
pinpointing underlying causes. Above you pointed eg at [2] for uwot, I see no
error in there :-/


Well, that log has two tests. The first second one passes, the first one 
has:

 51s > library(testthat)
 51s > library(uwot)
 51s Loading required package: Matrix
 53s >
 53s > test_check("uwot")
 53s Error in FNN::get.knn(X, k) : DLL requires the use of native symbols
 53s Calls: test_check ... eval -> create_data -> find_nn -> FNN_nn -> 


 53s Execution halted


Obviously, I too want my package r-base in testing and I will help. But I
feel that pinning a large Breaks list on it seems a little inefficient /
unfair if the package was not causing the change. We can do if there is (as
we r-graphics-engine-*) an overwhelming feel "that we must".


I want the Breaks in the right location. If we locate a more logical 
location than r-base, that's where it should go. At least the packages 
involved in the r-graphics-engine would do nice, as it's really the 
change in r-base that broke them (will not be needed anymore after the 
release of trixie as now we have the Provides): r-cran-cairo, 
r-cran-magick, r-cran-ragg, r-cran-svglite, r-cran-tikzdevice and 
r-cran-vdiffr.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037136: dpkg-buildflags: 64-bit time_t by default

[Guillem Jover]

Hi!

On Wed, 2023-07-05 at 14:24:02 -0700, Steve Langasek wrote:
> On Fri, Jun 09, 2023 at 03:56:28AM +0200, Guillem Jover wrote:
> > On Mon, 2023-06-05 at 21:18:10 -0700, Steve Langasek wrote:
> > > Package: dpkg-dev
> > > Version: 1.21.22
> > > Tags: patch
> > > User: ubuntu-de...@lists.ubuntu.com
> > > Usertags: origin-ubuntu mantic patch

> > > The discussion on debian-devel around 64-bit time_t has died down, so I
> > > figure it's time to propose some patches to implement what's been 
> > > discussed
> > > there.
> 
> > Yeah, I'm not sure whether it has died off or it's just being slow.
> 
> > > I'm not sure whether you were persuaded that i386 should stay with the
> > > current ABI, but anyway thought I would propose the patches and we could
> > > discuss further if necessary.
> 
> > In any case I've tried to reply there. Also my impression was that
> > there was still some analysis pending (perhaps that was a wrong
> > impression though)?
> 
> There is analysis pending, unfortunately 90% of the -dev packages have been
> analyzed leaving 90% to go (~1600 -dev packages that require fixes to be

Ack, thanks. Is that last % supposed to be 10%? Otherwise I think I'm
missing something :).

> compilable and therefore analyzable).  I don't have any answer yet from the
> Release Team, so I'm not sure if we need this analysis to be completely done
> before starting the transition or if we can leave the long tail of packages
> with 1 or 2 reverse-build-dependencies to be figured out later.

I don't know. Perhaps ask on d-d?

> > > From 5a861d19b1610ae82bf95e6c5142a3365436fbd2 Mon Sep 17 00:00:00 2001
> > > From: Steve Langasek 
> > > Date: Fri, 2 Jun 2023 14:30:20 +
> > > Subject: [PATCH 1/3] lfs and time64 are no longer "future", call them
> > >  "feature" instead
> 
> > Ah, I actually had implemented locally the alias with your original
> > suggestion of "abi"! :) Using "feature" here seems would be rather
> > more confusing as these are called feature flags, and feature areas.
> 
> > I'll try to push the stuff I've got queued locally during the weekend,
> > then I can rebase these patches on a branch or similar.
> 
> As far as I can tell, this hasn't been pushed anywhere yet?

Right, sorry got entangled in a local branch with random stuff, but
rebased that and added on top now several other fixes including these
changes or ones similar in intention. See at:

  https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/time64-default

(Beware that I might rebase that branch, before merging it, although I
think I'll start pushing some of the foundation work into main already.)

> > > From 7eff8f89b32b6921a0d86c50c6c62154c6ddc96e Mon Sep 17 00:00:00 2001
> > > From: Steve Langasek 
> > > Date: Fri, 2 Jun 2023 16:30:19 +
> > > Subject: [PATCH 3/3] Also emit -Werror=implicit-function-declaration for
> > >  feature=+time64
> > > 
> > > Per https://lists.debian.org/debian-devel/2023/05/msg00262.html et al.,
> > > missing glibc includes can cause packages to link to the wrong symbols,
> > > potentially causing crashes or misbehavior.  Since functions that use
> > > time_t are fairly ubiquitous, there's a high risk of this happening for
> > > *some* package in Debian.  Better to make all software with missing
> > > function declarations fail to build now, than to spend all cycle tracking
> > > down runtime bugs.
> > > ---
> > >  scripts/Dpkg/Vendor/Debian.pm | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
> > > index 20d77fea1..803949024 100644
> > > --- a/scripts/Dpkg/Vendor/Debian.pm
> > > +++ b/scripts/Dpkg/Vendor/Debian.pm
> > > @@ -400,6 +400,8 @@ sub _add_build_flags {
> > >  
> > >  if ($flags->use_feature('feature', 'time64')) {
> > >  $flags->append('CPPFLAGS', '-D_TIME_BITS=64');
> > > +$flags->append('CFLAGS', 
> > > '-Werror=implicit-function-declaration');
> > > +$flags->append('CXXFLAGS', 
> > > '-Werror=implicit-function-declaration');
> > >  }
> 
> > I'm not sure I like intermingling the different semantics here, if
> > necessary I'd rather make time64 forcibly enable another feature flag,
> > like it is done for lfs.
> 
> > As I mentioned on the recent thread about the modern C stuff, I do
> > have a branch that adds these as part of a new qa=+c99 feature, but
> > that's too broad. :/
> 
> >   
> > 
> 
> > Maybe I could add a new feature area instead and add the flags
> > individually, and then make time64 also enable that other specific
> > feature. Hmmm.
> 
> Did you reach a decision here?  Anything you'd like from me to move this
> forward?

I realized now that this cannot be set for CXXFLAGS as at least g++
will warn about that. And I've gone for now by depending on qa=+bug,
but I'm not sure whether that would cause too many regressions. OTOH
and AFAIK 

Bug#987503:

[Cyril Brulebois]

Richard Hartmann  (2023-07-09):
> As such, the current behavior is a breaking change for laptop users and
> leaves them with a broken system; when they realize why hibernation does
> not work they need to reinstall the system or reformat by hand with all
> the data moving that entails.
> 
> The fact that we're stuck with this for a whole stable release cycle
> makes things even worse.

I read your message as if that was some kind of recent regression.

For the avoidance of doubt, the relevant partman-auto code is present
in buster, bullseye, and bookworm.


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


signature.asc
Description: PGP signature

Bug#987503:

[Richard Hartmann]

I tried hibernation on Thinkpad X1 Carbon Gen 1, Gen 5, Gen 7, and Gen
11. They all work. As per
https://chaos.social/@waldi/110683468203241035 , I believe that the
definition of "modern system" Waldi refers to means catering to a
Windows world, something not deeply relevant to the Debian use case.

Steve's point about servers with more RAM than local storage caters a
nice use case to the detriment of the default. It does not design for
the common case with significantly more local storage than RAM, and
certainly violates the principle of least surprise.
Server operators are also more likely to have automation, change
control, Q processes, custom install options, hardware, etc. than
normal users. In other words: They are more likely to diverge from the
default settings.

Desktop users likely do not care, or notice, either way.


Using only part of the local storage and reserving more with LVM is
certainly not the default use case, either. It is also not the default
behavior of the guided installation.

As such, the current behavior is a breaking change for laptop users
and leaves them with a broken system; when they realize why
hibernation does not work they need to reinstall the system or
reformat by hand with all the data moving that entails.


The fact that we're stuck with this for a whole stable release cycle
makes things even worse.


Richard

Bug#1036851: GNU indent 2.2.12 fix backport

[Santiago Vila]

tags 1036851 + confirmed
thanks

El 28/5/23 a las 0:02, Marek Vasut escribió:

Package: indent
Version: 2.2.12-4
Severity: normal

Gstreamer MR [1] triggers a bug in GNU indent 2.2.12, which is already fixed in 
GNU indent upstream [2] and the fix is part of GNU indent 2.2.13 .

To trigger the failure, clone [1] and run:
$ ./scripts/gst-indent subprojects/gst-plugins-bad/gst/bayer/gstbayer2rgb.c
indent: Virtual memory exhausted.
free(): double free detected in tcache 2
Aborted


Hello. I have finally verified that this happens with indent-2.2.12
in Debian 12, and not with the (to be packaged) indent 2.2.13.

Moreover, I've also verified that the exact commit you indicated
in this bug report fixes the problem as well when applied over indent 2.2.12.

Now (before uploading 2.2.13) I have to check the list of bugs reported
to Debian to see if there are any that we can close, but that will not
take a lot, so I believe it is likely that Debian 12.1 will include the fix
for the memory problem.

Thanks.

Bug#1011666: groff 1.23.0 build dependencies will change

[Colin Watson]

On Wed, May 25, 2022 at 07:55:10PM -0500, G. Branden Robinson wrote:
> * Drop the bison dependency.
> 
>   o Building groff from its distribution archive no longer requires byacc
> (or GNU Bison) to be installed.
> 
> * Drop the texinfo dependency.
> 
>   o Because all generated forms of groff's Texinfo manual are now included
> in the distribution archive, building from that archive no longer
> depends on GNU Texinfo or a TeX installation (the latter was only
> required for the "doc" target, which had to be explicitly given).

After some thought, I'm going to keep these two build-dependencies after
all, as well as adding new build-dependencies on texlive-base and
texlive-latex-base.

Debian normally prefers to build everything from the original source if
possible, even if intermediate forms are shipped in distribution
archives.  This is of course partly for ideological reasons, but there's
a significant practical motivation too: in the event that we need to
patch something in a hurry, we don't want to have to figure out the
necessary build system changes at the same time (or, worse, have changes
appear to be present in the source package but silently have no effect).
This is not a theoretical concern: my proposed patch to resolve the
SOURCE_DATE_EPOCH timezone problem changes doc/groff.texi.

It's true that this significantly bloats groff's build-dependency set
(especially texlive-base).  However, I don't think this will be a
problem in practice.  For bootstrapping new architectures, we often lean
on multiarch these days, and all three of the packages concerned here
are "Multi-Arch: foreign" - so it should be possible to satisfy those
build-dependencies using binaries from the host architecture when doing
a cross-build.

If it becomes an issue, we can look at putting these in a "nodoc"
profile, although that would probably also need some debian/rules
changes so I haven't bothered with it just yet.

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

Bug#1040620: quickplot will not read input file

[Lance Arsenault]

Hi Brent,

1. First thank you for submitting this bug ticket.  I'm not sure if I have
write access to the debian bug system, but we'll see.

2.  I'm the sole downstream developer of quickplot.  quickplot as
distributed by Debian GNU/Linux was pretty cool stuff.  It currently has
some package dependencies that have broken it.  In particular, libsndfile
and GTK3.  And so, quickplot is in need of refactoring, maybe dropping the
libsndfile dependency and removing deprecated GTK3 API usage.  As it turns
out, I just happened to have released (alpha) a much larger software
package that kind-of needs a "quickplot" like tool to help my current
work.  So I need to fix quickplot for my own use.  I have not used it in a
while.

3. I looked at your bio.  We seem to have a little bit of overlap in
professional interests,  my CV is at http://107.191.96.171/cv.html , sorry
it's http without https yet.

4. My new alpha software package is at
https://github.com/lanceman2/quickstream  , you might find it interesting.

cheers
lance


On Fri, Jul 7, 2023 at 11:30 PM Brent Roman  wrote:
>
> Package: quickplot
> Version: 1.0.1~rc-1+b3
>
> Any attempt to read an input file or pipe fails with the error message:
>
> Failed to read file /home/brent/quickplot/plot.dat: lseek() failed
>
> A workaround is the link the quickplot binary with the upstream
> libsndfile-1.0.28
> rather than the libsndfile-1.0.31 packaged with Debian 11
>
> For instance, after installing libsndfile-1.0.28 in /usr/local/lib,
> quickplot
> will work if started with this shell script:
>
> #!/bin/sh #force linkage with our local version of libsndfile
> # (1.0.28 rather than Debian's 1.0.31)
> LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH exec /usr/bin/quickplot
"$@"
>
> I am using Debian 11 on x86 (tested both 32 or 64-bit) with various
> Linux 5.x kernels.
>
> --
>   Brent Roman   MBARI
>   Software Engineer   Tel: (831) 775-1808
>   mailto:br...@mbari.org  http://www.mbari.org/~brent
>

Bug#1040707: RFS: sane-backends/1.2.1-4 -- API development library for scanners

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

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

The source builds the following binary packages:

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

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

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

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

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

or from

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

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


Changes since the last upload:

 sane-backends (1.2.1-4) unstable; urgency=medium
 .
   * Fix FTBFS on hurd-i386 (Closes: #1040123):
 - debian/rules: Remove --enable-parport-directio.
   Thanks to Pino Toscano .


CU
Jörg

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


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


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

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

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






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

Bug#983763: package unconditionally b-d's on libreoffice-writer

[Rene Engelhard]

Hi,

Am Tue, Mar 02, 2021 at 08:46:01PM +0100 schrieb Christoph Berg:
> Re: Matthias Klose
> > >> package unconditionally b-d's on libreoffice-writer, not available on all
> > >> platforms, prohibiting migration to testing.
> > > 
> > > This is not true, the package built on all release archs.
> > 
> > sorry, would be nice to fix for ports architectures as well.
> 
> Yeah the ideal fix would be to move libreoffice-writer to B-D-I and
> split the docs into a separate -doc package, but that's forbidden
> during the freeze. Will do that with the next upload.

That was over two years ago, in the meanwhile both bullseye and bookworm got
released. ;-)

(And this bug gets more pressing given the looiming removal of
mips(64)el for libreoffice from  the archive)
Moving it to B-D-I and doing -doc would effectively fix that problem as
it then will be built on amd64 anyways on the buildds (or anywhere else
where libreoffice is available).

Can this be done now? I tried but I failed to get this actually working
with all the dh_auto_* magic...

Regards,

Rene

Bug#1036971: pwsafe: empty window after internal timeout or screen blank

[Bill Wohler]

Hi Bill,

I can confirm this regression as I experienced it when I upgraded from
bullseye (perhaps with a more recent version than 1.12 from backports)
to bookworm (with PasswordSafe 1.16) yesterday.

Normally, when the database is locked after some time of inactivity, the
password dialog appears. This dialog is no longer appearing. That's the
bug.

Giuseppe, there is a workaround to get the password dialog that takes
four more button presses than we'd like: press the Close button followed
by the Open button and double-click on your database file.

Bill, I *think* I have a compiled PasswordSafe 1.16 from upstream at
work that works as expected. I'll double-check the version tomorrow and
let you know.

I wonder if this is a GNOME 43 incompatibility...

-- 
Bill Wohler  aka 
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Bug#1040706: gpredict: please use libreoffice-writer-nogui instead of libreoffice-writer

[Rene Engelhard]

Source: gpredict
Version: 2.3-72-gc596101-3
Severity: wishlist
Tags: patch

Dear Maintainer,

libreoffice-*-nogui was introduced exactly for the reason of which this
package uses libreoffice: using libreoffice for something automatically
without needing GUI. E.g. document conversion.

So I suggest using libreoffice-writer-nogui. That means "lowriter" is
gone, though, but you simply can use "soffice --writer instead" (which
is what lowriter calls anyways). --writer isn't exactly needed since odt
should be detected as writer but doesn't do harm.

Since libreoffice-writer-nogui is not available on all archs (left out
on the "slow" ones sincewe don't want to have *two* build of LO on
them...)[1] this only needs to be done after #983763 though (will mark it
as blocking).

diff -Nru gpredict-2.3-72-gc596101/debian/control 
gpredict-2.3-72-gc596101/debian/control
--- gpredict-2.3-72-gc596101/debian/control 2021-02-20 18:38:58.0 
+
+++ gpredict-2.3-72-gc596101/debian/control 2023-07-09 17:04:38.0 
+
@@ -16,7 +16,7 @@
libglib2.0-dev,
libgoocanvas-2.0-dev,
libgtk-3-dev,
-   libreoffice-writer,
+   libreoffice-writer-nogui,
libtool,
pkg-config
 
diff -Nru gpredict-2.3-72-gc596101/debian/rules 
gpredict-2.3-72-gc596101/debian/rules
--- gpredict-2.3-72-gc596101/debian/rules   2021-02-20 19:56:10.0 
+
+++ gpredict-2.3-72-gc596101/debian/rules   2023-07-09 17:04:38.0 
+
@@ -14,4 +14,4 @@
 override_dh_auto_build:
dh_auto_build
mkdir -p $(HOME)
-   cd doc/um && lowriter --headless --convert-to pdf 
gpredict-user-manual.odt
+   cd doc/um && soffice --writer --headless --convert-to pdf 
gpredict-user-manual.odt

Regards,

Rene

[1]
libreoffice-writer-nogui | 4:7.4.5-3 | stable | amd64, arm64, armhf, 
i386, ppc64el, s390x

Bug#1040705: Call to undefined function GuzzleHttp\json_decode()

[David Mandelberg]

Package: roundcube-core
Version: 1.6.1+dfsg-1

I tried setting up oauth2 in roundcube, but when the OIDC provider 
redirects back to roundcube, I get an "Oops... something went wrong!" 
page. When that happens, /var/log/roundcube/errors.log shows:


[09-Jul-2023 17:00:49 UTC] PHP Fatal error:  Uncaught Error: Call to 
undefined function GuzzleHttp\json_decode() in 
/usr/share/roundcube/program/include/rcmail_oauth.php:237

Stack trace:
#0 /usr/share/roundcube/program/actions/login/oauth.php(37): 
rcmail_oauth->request_access_token()

#1 /usr/share/roundcube/index.php(198): rcmail_action_login_oauth->run()
#2 /var/lib/roundcube/public_html/index.php(26): include('...')
#3 {main}
  thrown in /usr/share/roundcube/program/include/rcmail_oauth.php on 
line 237


Adding `require_once("GuzzleHttp/autoload.php");` to 
/etc/roundcube/config.inc.php seems to fix the error, but I'm not sure 
if that's the right way to do it. php-guzzlehttp-guzzle is installed and 
version 7.4.5-1 if that helps.


See also https://github.com/roundcube/roundcubemail/pull/8773 which is 
related, but seems to have a different cause. Presumably it will fix the 
issue when it makes it into Debian, but I'm filing this bug anyway in 
case there's a packaging issue that will prevent roundcube from finding 
other guzzle functions not affected by that PR.

Bug#1040186: ipmitool: IANA PEN registry open failed: No such file or directory

[Jörg Frings-Fürst]

Hello Marc,

the link to download the IANA PEN registry has changed to 
https://www.iana.org/assignments/enterprise-numbers.txt

(From /usr/share/doc/ipmitool/NEWS.Debian.gz)

You must download a new one or rename tho old to enterprise-numbers.txt.


Am Montag, dem 03.07.2023 um 03:27 +0200 schrieb Marc Lehmann:
> Package: ipmitool
> Version: 1.8.19-4
> Severity: normal
> 
> Dear Maintainer,
> 
> after upgrade to bookworm, ipmitool outputs this on every invocation:
> 
> IANA PEN registry open failed: No such file or directory
> 
>   
[...]

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


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


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

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

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






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

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Dirk Eddelbuettel]

On 9 July 2023 at 11:41, Dirk Eddelbuettel wrote:
| For spacetime and stars I suspect (based on past experience) possible
| interaction from the underlying graphics libraries.

Absent-minded typing error: "geospatial", of course. Not "graphics". 

Dirk

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

Bug#1040703: RFS: shotwell/0.32.1-2 -- digital photo organizer

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name : shotwell
   Version  : 0.32.1-2
   Upstream contact : Jim Nelson 
   URL  : https://wiki.gnome.org/Apps/Shotwell
   License  : LGPL-2.1
   Vcs  : https://git.jff.email/cgit/shotwell.git
   Section  : gnome

The source builds the following binary packages:

  shotwell - digital photo organizer
  shotwell-common - digital photo organizer - common files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.32.1-2.dsc

or from 

 git https://git.jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.32.1-2

 git https://jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.32.1-2



Changes since the last upload:

 shotwell (0.32.1-2) unstable; urgency=medium
 .
   * debian/rules (Closes: #1039719):
 - Drop unnecessary libexec configure option.
 - Update apport configuration option name.
 - Drop obsolete override_dh_install.
   * Replace Build-Depend gnome-pkg-tools with dh-sequence-gnome:
 - debian/rules:
   + Remove --with gnome.
 - debian/control:
   + Replace gnome-pkg-tools with dh-sequence-gnome.
   * debian/control:
 - Drop the Build-Depends libsoup2.4-dev (Closes: #1039715).
 - Add Depend xdg-desktop-portal-backend (Closes: #1039716).
 - Drop unnecessary Build-Depends versioning.

CU
Jörg

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


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


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

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

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






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

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Dirk Eddelbuettel]

Paul,

On 9 July 2023 at 17:40, Paul Gevers wrote:
| Did we already discuss that r-cran-ps also seems to be impacted by the 
| r-base change of the symbols thingy, as can be seen in r-cran-xopen [1].

Correct me if I am wrong but the "symbols thingy" was not a change in R 4.2.*
to R 4.3.*. It was a change by some packages opting into different behavior.

| In unstable r-cran-xopen works. If I take r-cran-ps, r-cran-xopen and 
| r-base from unstable and test in testing, r-cran-xopen works. If I only 
| take r-base and r-cran-ps from unstable and test in testing, 
| r-cran-xopen works. Can somebody with R understanding confirm?
| 
|   33s Error in `not_null(.Call("psll_connections", p))`: DLL requires 
| the use of native symbols
|   33s Backtrace:
|   33s   1. testthat::test_that(...)
|   33sat test.R:4:0
|   33s   2. testthat:::test_code(desc, code, env = parent.frame(), 
| reporter = reporter)
|   33s   3. reporter$start_test(context = reporter$.context, test = test)
|   33s   4. testthat:::o_apply(self$reporters, "start_test", context, test)
|   33s   5. base::lapply(objects, f)
|   33s   6. testthat (local) FUN(X[[i]], ...)
|   33s   7. x$start_test(...)
|   33s   8. ps::ps_connections(ps_handle())
|   33s   9. ps:::psl_connections(p)
|   33s  10. ps:::not_null(.Call("psll_connections", p))

Tis would be a bug in r-cran-ps and I think a Breaks may be warranted.  We
are apparently between version 1.7.2 and 1.7.5 of package (r-cran-)ps but I
see no smoking gun in https://github.com/r-lib/ps/blob/main/NEWS.md that
would have caused this.

Looking further, `git blame` indicates that the package had
`registation=TRUE` for five years / all its existence, see line 2 here
  
https://github.com/r-lib/ps/blame/357f9c01f5db95b67ce9e230282391bc835afca4/R/ps.R

It also used 'forceSymbols' for the same five years (lines 99 to 101 here
  
https://github.com/r-lib/ps/blame/357f9c01f5db95b67ce9e230282391bc835afca4/src/init.c

So I think the issue here may not be coming from ps. I has not changed how it
refers to its symbols.  Same R API, same usage.

As the last entry here is into the (unexported) ps:::not_null we can look
into it. It just indexes with map_lgl which is a local function (from R/utils)
and calls psll_connection, a local compiled function in the package.  Given
that ps always had 'native symbols', maybe testthat changed?

However, it does not force symbols :-/  Lines 20 and 21 use the two required
initialization but not the optional symbol forcing that eg ps has. 
  https://github.com/r-lib/testthat/blob/main/src/init.c

So I got nothing here. Cause is unclear to me.

| Same for r-cran-fnn, which impacts r-cran-uwof [2].
| 
| I think what we should do is add a versioned Breaks in r-base on 
| , r-cran-ps, r-cran-tibble, 
| r-cran-dplyr, r-cran-fnn. I think that's the right thing to do for 

I think it would be best to work out to corresponding package pairings and
apply the Breaks to them. If we can.

| bookworm to trixie upgrades (and current trixie to trixie with the new 
| r-base). Has anyone see other packages throwing that "DLL requires the 
| use of native symbols" error? I spotted the ones below [3, 4, 5, 6], but 
| I haven't identified which package brings in the issue. I first thought 
| it would be from the package itself, but for some (r-cran-spacetime and 
| r-cran-stars) their versions in unstable fail their own testsuite in

For spacetime and stars I suspect (based on past experience) possible
interaction from the underlying graphics libraries.

| testing. Would it hint at the same problem for the packages, or just for 
| their tests? I suspect the former, then they should also need to be 
| added to the Breaks list.
| 
| Paul
| 
| [1] 
| 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-xopen/35575366/log.gz
| [2] 
| 
https://ci.debian.net/data/autopkgtest/testing/i386/r/r-cran-uwot/35590669/log.gz
| [3] 
| 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-intervals/35575046/log.gz
| [4] 
| 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-maldiquant/35575320/log.gz
| [5] 
| 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-spacetime/35575371/log.gz
| [6] 
| 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-stars/35583884/log.gz

If I am not mistaken all of these were already in the Excuses list before we
made addition of the r-graphics-engine-* tag (which was taken care of for R
4.3.* already, having it may help if another change happens like that).

So it short, the vast majority of R packages is now fine.  A persistent
subset is not under the testing regime of autopkgtest.  Unfortunately I find
the reports a little hard to read and am hence not very efficient at
pinpointing underlying causes. Above you pointed eg at [2] for uwot, I see no
error in there :-/


Obviously, I too want my package r-base in testing and I will help. But I
feel that pinning a large Breaks list on it seems a little inefficient /
unfair if 

Bug#1002996: [Bug #1002996] ITP: python-orjson -- fast, correct JSON library for Python

[Agathe Porte]

Hi,

2023-07-02 19:03 CEST, Antonio Valentino:
> Could I kindly ask what is the status of the packaging and if you have an
> idea about when this package could go in the new queue?

Currently waiting on the ITP: maturin [1] to finish. When it is done
then I can start to have a look again at this ITP.

Best regards,

Agathe.

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

Bug#1040614: debian-reference: typo 'kerrnel'

[肖盛文]

Control: tags -1 pending

Thanks for your report.

It's a typo, I fixed it in salsa:
https://salsa.debian.org/debian/debian-reference/-/commit/f81ca39995d4d7dc44925a711fc758f2e8115bea

在 2023/7/8 07:31, snu83t+3zk8qvxfm6a78@cs.email 写道:

Package: debian-reference
Severity: normal

Dear Maintainer,

debian reference contains the typo 'kerrnel', search for that string and
please fix it.



--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039030: transition: qtbase-abi-5-15-10

[Dmitry Shachnev]

Hi Sebastian!

On Fri, Jul 07, 2023 at 10:29:41PM +0200, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
>
> Please go ahead.

Qt is uploaded.

Unfortunately, qtwebengine FTBFS on mipsel again. We are working on it
together with Adrian Bunk (huge thanks to him for that).

Other Qt packages seem to have built fine everywhere. Probably you can
start doing some binNMUs.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1040702: impossible to install: depends on missing packages

[Jonas Smedegaard]

Package: librust-log-dev
Version: 0.4.19-1
Severity: grave

depends on several unavailable packages.

 - Jonas

Bug#1040701: RFS: awstats/7.8-4 [QA] -- powerful and featureful web server log analyzer

[Lourisvaldo Figueredo Junior]

Package: sponsorship-requests
Severity: normal

Dear mentors,

This is the first step towards resolving bug #1037213.
This bug was apparently introduced in version 7.8-1 by attempting to resolve 
bug #890414.
In this version, the postinst script does a removal of the /etc/logrotate.d/
httpd-prerotate/awstats directory, but before that apt installs in the same 
directory as a file called awstats, thus generating an awstats.dpkg-new file.
If a preinst script is used to remove the directory, apt does not rename the 
file to the dpkg-new extension.
Tested on upgrading from buster to bullseye and then bookworm, requiring no 
user intervention.

Step 1: fix this bug in unstable. (7.8-3 to 7.8-4)
Step 2: fix in bookworm. (7.8-3 to 7.8-3+deb12u1)
Step 2: fix in bullseye, and finally close this bug. (7.8-2+deb11u1 to 
7.8-2+deb11u2)


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

 * Package name : awstats
   Version  : 7.8-4
   Upstream contact : Laurent Destailleur 
 * URL  : http://awstats.sourceforge.net/
 * License  : GPL-3+, Apache-2.0, CC-BY-3.0, GPL-1+
 * Vcs  : https://salsa.debian.org/debian/awstats
   Section  : web

The source builds the following binary packages:

  awstats - powerful and featureful web server log analyzer

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/awstats/
awstats_7.8-4.dsc

Changes since the last upload:

 awstats (7.8-4) unstable; urgency=medium
 .
   * QA upload.
   * debian/awstats.postinst: part of the code was moved to the 
awstats.preinst
 file, to avoid creating the
 /etc/logrotate.d/httpd-prerotate/awstats.dpkg-new file, and thus requiring
 user interaction when updating. See #1037213.
   * debian/awstats.preinst: created.

Regards,

Lourisvaldo Figueredo Junior



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

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi,

On 09-07-2023 16:20, Andreas Tille wrote:

I'm working my through the list and the ppc64el ci workers have a bit of
backlog; we're getting somewhere, but I'm think I'm still also seeing
different failure modes than the graphics engine, tibble and dplyr.


I admit the only chance I personally see to clarify this question is to
open an issue at the tibble git repository[1].  May be we also need
something like an r-cran-tibble-api?


Did we already discuss that r-cran-ps also seems to be impacted by the 
r-base change of the symbols thingy, as can be seen in r-cran-xopen [1]. 
In unstable r-cran-xopen works. If I take r-cran-ps, r-cran-xopen and 
r-base from unstable and test in testing, r-cran-xopen works. If I only 
take r-base and r-cran-ps from unstable and test in testing, 
r-cran-xopen works. Can somebody with R understanding confirm?


 33s Error in `not_null(.Call("psll_connections", p))`: DLL requires 
the use of native symbols

 33s Backtrace:
 33s   1. testthat::test_that(...)
 33sat test.R:4:0
 33s   2. testthat:::test_code(desc, code, env = parent.frame(), 
reporter = reporter)

 33s   3. reporter$start_test(context = reporter$.context, test = test)
 33s   4. testthat:::o_apply(self$reporters, "start_test", context, test)
 33s   5. base::lapply(objects, f)
 33s   6. testthat (local) FUN(X[[i]], ...)
 33s   7. x$start_test(...)
 33s   8. ps::ps_connections(ps_handle())
 33s   9. ps:::psl_connections(p)
 33s  10. ps:::not_null(.Call("psll_connections", p))

Same for r-cran-fnn, which impacts r-cran-uwof [2].

I think what we should do is add a versioned Breaks in r-base on 
, r-cran-ps, r-cran-tibble, 
r-cran-dplyr, r-cran-fnn. I think that's the right thing to do for 
bookworm to trixie upgrades (and current trixie to trixie with the new 
r-base). Has anyone see other packages throwing that "DLL requires the 
use of native symbols" error? I spotted the ones below [3, 4, 5, 6], but 
I haven't identified which package brings in the issue. I first thought 
it would be from the package itself, but for some (r-cran-spacetime and 
r-cran-stars) their versions in unstable fail their own testsuite in 
testing. Would it hint at the same problem for the packages, or just for 
their tests? I suspect the former, then they should also need to be 
added to the Breaks list.


Paul

[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-xopen/35575366/log.gz
[2] 
https://ci.debian.net/data/autopkgtest/testing/i386/r/r-cran-uwot/35590669/log.gz
[3] 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-intervals/35575046/log.gz
[4] 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-maldiquant/35575320/log.gz
[5] 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-spacetime/35575371/log.gz
[6] 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-stars/35583884/log.gz


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040653: gnome-keyring: Depends upon pinentry-gtk instead of pinentry

[Lisandro Damian Nicanor Perez Meyer]

On domingo, 9 de julio de 2023 12:20:44 -03 Lisandro Damian Nicanor Perez 
Meyer wrote:
> On sábado, 8 de julio de 2023 12:38:53 -03 Lisandro Damián Nicanor Pérez
> Meyer wrote:
> [snip]
> 
> > Hi! gnome-keyring depends upon pinentry-gtk instead of just pinentry.
> > This forces the installation of the gtk versions on systems that might
> > as well use the curses or Qt versions of pinentry.
> > 
> > If you want you could use pinentry as a dependency and pinentry-gtk as a
> > recommendation, thus installaing the GTK version by default on systems
> > that do not have any other pinentry package installed, but still
> > allowing the user to choose which pinentry version to install.
> 
> Actually the dependency can be changed to
> 
>   pinentry | pinentry-gtk
> 
> **unless** it is expected to have a GUI, in which case the dependency can be
> 
>   pinentry-x11 | pinentry- gtk

My apologies, it needs to be the other way around in order to avoid apt 
picking a random one, so either

  pinentry-gtk | pinentry

or

  pinenty-gtk | pinentry-x11

Thanks Pino Toscano for the tip!

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

Bug#1040653: gnome-keyring: Depends upon pinentry-gtk instead of pinentry

[Lisandro Damian Nicanor Perez Meyer]

On sábado, 8 de julio de 2023 12:38:53 -03 Lisandro Damián Nicanor Pérez Meyer 
wrote:
[snip] 
> Hi! gnome-keyring depends upon pinentry-gtk instead of just pinentry.
> This forces the installation of the gtk versions on systems that might
> as well use the curses or Qt versions of pinentry.
> 
> If you want you could use pinentry as a dependency and pinentry-gtk as a
> recommendation, thus installaing the GTK version by default on systems
> that do not have any other pinentry package installed, but still
> allowing the user to choose which pinentry version to install.

Actually the dependency can be changed to

  pinentry | pinentry-gtk

**unless** it is expected to have a GUI, in which case the dependency can be

  pinentry-x11 | pinentry- gtk

Thanks in advance, Lisandro.

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

Bug#987503: SWAP=115% of RAM (?)

[Rainer Dorsch]

I just run into the same issue.

https://lists.debian.org/debian-boot/2023/07/msg00049.html

Many thanks Josch for sharing the partman-auto workaround in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987503#30

worked well for me.

Just to get another datapoint, I checked a Manjaro system I recently installed 
and it did not have an issue with hibernation, but worked flawless.

It has 8 GB of RAM, 224 GB of SSD and manjaro created a swap partition of 
about 9 GB or (around 115% or the RAM size).

Drives:
  Local Storage: total: 223.57 GiB used: 89.31 GiB (39.9%)
  ID-1: /dev/sda vendor: SanDisk model: SDSSDA240G size: 223.57 GiB

MiB Spch:   7793,0 total,   1537,6 free,   2590,4 used,   3665,0 buff/cache
MiB Swap:   9011,2 total,   7391,3 free,   1619,9 used.   4096,0 avail Spch

Wouldn't it be a rather quick solution to add two options to partman (desktop/
laptop or server optimized), which either creates a swap partition of 
sufficient 
size or keeps the 1GB partition? Would probably work for more than 80% of the 
desktop/laptop users.

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Bug#1040700: kleopatra: Depends upon pinentry-qt instead of pinentry

[Lisandro Damian Nicanor Perez Meyer]

tag 1040700 + patch
thanks

On domingo, 9 de julio de 2023 12:00:30 -03 Lisandro Damián Nicanor Pérez 
Meyer wrote:
> Package: kleopatra
> Version: 4:22.12.3-1
> Severity: normal
> X-Debbugs-Cc: lisan...@debian.org
> 
> Hi! kleopatra has a direct dependency on pinentry-qt instead of
> pinentry. The problem with this is that people wanting to use any other
> pinentry fronted are forced to install the Qt version.
> 
> The correct solution for this would be to replace the dependency with
> pinentry and move pinentry-qt as Recommends, thus giving the Qt version
> a chance but allowing users to use any other variant, like the curses or
> gtk one.

MR in https://salsa.debian.org/qt-kde-team/kde/kleopatra/-/merge_requests/2

Thanks Pino for noticing that this requires a graphical pinentry manager, so 
now the dependency is pinentry-x11 | pinentry-qt.


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