date:20230819


Package: src:ca-certificates
Version: 20230311
Severity: wishlist
Tags: patch

Dear ca-certificates maintainers,

this package currently uses debhelper with an ad-hoc sequence of steps 
in d/rules. This long list of steps can be shortened and greatly 
simplified by using the standard dh sequence.


You can find a MR that changes `d/rules` to use the standard dh sequence at:

https://salsa.debian.org/debian/ca-certificates/-/merge_requests/10

According to diffoscope, the generated binary packages (deb and udeb) 
are identical to the current ones.


--
Gioele Barabucci

Bug#1050113: unblock: rust-rustls-webpki/0.101.3-1.1

2023-08-19 Thread plugwash

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package rust-rustls-webpki

The package is blocked by autopkgtest failures on ppc64el and s390x. The reason
for these failures is that the package (which is arch all) is not installable
on these architectures because it depends on the ring crate which is not
currently portable. Please can you override these failures and allow the
package to migrate to testing.

-- System Information:
Debian Release: 10.11
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1050106: lxc: [INTL:it] Italian debconf translation

2023-08-19 Thread Mathias Gibbens

Control: tags -1 + pending

  Thanks for the contribution! It will be included in the next upload
of lxc.

Mathias



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

Bug#1047718: liblld-X-dev should probably depend on zlib1g-dev/libzstd-dev

2023-08-19 Thread Faidon Liambotis

Control: reopen -1
Control: severity -1 serious

On Fri, Aug 18, 2023 at 07:21:05AM +, Debian Bug Tracking System wrote:
>* Also build-depend on libzstd-dev (Closes: #1047718)

Thanks for this, but the bug report was not about a Build-Depends, but
rather for a (runtime) Depends from a -dev package to another -dev
package, namely liblld-16-dev -> libzstd-dev, as well as liblld-16-dev
-> zlib1g-dev. Therefore the bug is still present, as far as I can tell.

I saw #1050071, where Sylvestre started planning the llvm-defaults 16
transition. With this bug open, the switch will make WasmEdge FTBFS,
therefore I'm upping the severity to "serious".

(I can of course add these two transitive B-Ds to the WasmEdge B-D to
workaround this, but I don't think that's the right place for them. Let
me know if you disagree).

Thanks,
Faidon

Bug#1050111: osk-sdl: [INTL:it] Italian debconf translation

Package: osk-sdl
Severity: wishlist
Tags: l10n patch
X-Debbugs-Cc: ce...@oziosi.org

Hello,
in the attachment you can find the Italian debconf translation. I think it
should be placed in `debian/po/it.po`.
Cheers,


--
Ceppo
# osk-sdl po-debconf italian translation.
# Copyright (C) 2023 osk-sdl copyright holder
# This file is distributed under the same license as the osk-sdl package.
# Ceppo , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: osk-sdl\n"
"Report-Msgid-Bugs-To: osk-...@packages.debian.org\n"
"POT-Creation-Date: 2022-08-08 09:21+\n"
"PO-Revision-Date: 2023-07-12 00:00+\n"
"Last-Translator: Ceppo \n"
"Language-Team: Italian \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Automatically clean crypttab?"
msgstr "Ripulire automaticamente crypttab?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"Selecting this will result in instances of 'osk-sdl-keyscript'  being "
"removed from /etc/crypttab on package removal."
msgstr ""
"Selezionando questa opzione, alla rimozione del pacchetto le istanze di "
"'osk-sdl-decrypt' saranno rimosse da /etc/crypttab."

Bug#1050110: sash: [INTL:it] Italian debconf translation

Package: sash
Severity: wishlist
Tags: l10n patch
X-Debbugs-Cc: ce...@oziosi.org

Hello,
in the attachment you can find the Italian debconf translation. I think it
should be placed in `debian/po/it.po`.
Cheers,


--
Ceppo
# sash po-debconf italian translation.
# Copyright (C) 2023 sash' copyright holder
# This file is distributed under the same license as the sash package.
# Ceppo , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: sash\n"
"Report-Msgid-Bugs-To: s...@packages.debian.org\n"
"POT-Creation-Date: 2017-07-16 19:14+0200\n"
"PO-Revision-Date: 2023-07-12 00:00+\n"
"Last-Translator: Ceppo \n"
"Language-Team: Italian \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: error
#. Description
#: ../templates:1001
msgid "sashroot user detected"
msgstr "rilevato utente sashroot"

#. Type: error
#. Description
#: ../templates:1001
msgid ""
"Previous versions of sash offered to create a root user with shell set to /"
"bin/sash.  This system has such a user."
msgstr ""
"Le versioni precedenti di sash offrivano la possibilità di creare un utente "
"di root con shell impostata a /bin/sash. Questo sistema ha tale utente."

#. Type: error
#. Description
#: ../templates:1001
msgid ""
"This can unfortunately not be automatically removed together with the "
"package, so you need to manually delete the sashroot user."
msgstr ""
"Purtroppo questo non può essere rimosso automaticamente con il pacchetto, "
"quindi è necessario rimuovere manualmente l'utente sashroot."

Bug#1050083: shotwell: crash in folders_sidebar_entry_construct

2023-08-19 Thread Patrice Duroux

Here it is:

#apt --installed list | grep /experimental

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

adwaita-icon-theme/experimental,experimental,now 44.0-1 all  [installé]
audacious-plugins-data/experimental,experimental,now 4.3.1-1~exp1 all
[installé]
audacious-plugins/experimental,now 4.3.1-1~exp1+b1 amd64  [installé]
audacious/experimental,now 4.3.1-1~exp1 amd64  [installé]
baobab/experimental,now 45~alpha-1 amd64  [installé]
gir1.2-adw-1/experimental,now 1.4~beta-2 amd64  [installé]
gir1.2-gtk-4.0/experimental,now 4.12.0+ds-1 amd64  [installé]
gir1.2-mutter-12/experimental,now 44.3-5 amd64  [installé, automatique]
gir1.2-tracker-3.0/experimental,now 3.6~beta-1 amd64  [installé, automatique]
gnome-backgrounds/experimental,experimental,now 45~beta-1 all  [installé]
gnome-calendar/experimental,now 45~beta-1 amd64  [installé]
gnome-characters/experimental,now 45~alpha-1 amd64  [installé]
gnome-console/experimental,now 45~beta-1 amd64  [installé]
gnome-contacts/experimental,now 45~beta-1 amd64  [installé]
gnome-control-center-data/experimental,experimental,now 1:45~beta-1
all  [installé]
gnome-control-center/experimental,now 1:45~beta-1 amd64  [installé]
gnome-font-viewer/experimental,now 45~alpha-1 amd64  [installé]
gnome-logs/experimental,now 45~beta-1 amd64  [installé]
gnome-maps/experimental,now 45~beta-1 amd64  [installé]
gnome-mastermind/experimental,now 0.4.0-2 amd64  [installé]
gnome-photos/experimental,now 44.0-2 amd64  [installé]
gnome-remote-desktop/experimental,now 44.2-5 amd64  [installé]
gnome-shell-common/experimental,experimental,now 44.3-3 all  [installé]
gnome-shell-extension-gsconnect-browsers/experimental,experimental,now
55-2 all  [installé]
gnome-shell-extension-gsconnect/experimental,experimental,now 55-2 all
 [installé]
gnome-shell-extension-prefs/experimental,now 44.3-3 amd64  [installé,
automatique]
gnome-shell-extensions/experimental,experimental,now 44.0-1 all  [installé]
gnome-shell/experimental,now 44.3-3 amd64  [installé]
gnome-terminal-data/experimental,experimental,now 3.49.92-2 all  [installé]
gnome-terminal/experimental,now 3.49.92-2 amd64  [installé]
gnome-text-editor/experimental,now 45~beta-1 amd64  [installé]
gnome-weather/experimental,experimental,now 45~alpha-1 all  [installé]
libadwaita-1-0/experimental,now 1.4~beta-2 amd64  [installé]
libaudcore5/experimental,now 4.3.1-1~exp1 amd64  [installé, automatique]
libaudgui5/experimental,now 4.3.1-1~exp1 amd64  [installé, automatique]
libaudqt2/experimental,now 4.3.1-1~exp1 amd64  [installé, automatique]
libaudtag3/experimental,now 4.3.1-1~exp1 amd64  [installé, automatique]
libgtk-4-1/experimental,now 4.12.0+ds-1 amd64  [installé]
libgtk-4-bin/experimental,now 4.12.0+ds-1 amd64  [installé]
libgtk-4-common/experimental,experimental,now 4.12.0+ds-1 all  [installé]
libgtk-4-media-gstreamer/experimental,now 4.12.0+ds-1 amd64  [installé]
libmutter-12-0/experimental,now 44.3-5 amd64  [installé, automatique]
libtracker-sparql-3.0-0/experimental,now 3.6~beta-1 amd64  [installé,
automatique]
mutter-common-bin/experimental,now 44.3-5 amd64  [installé]
mutter-common/experimental,experimental,now 44.3-5 all  [installé]
mutter/experimental,now 44.3-5 amd64  [installé]
orca/experimental,experimental,now 45~beta-1 all  [installé]
tracker-extract/experimental,now 3.5.2-1 amd64  [installé]
tracker-miner-fs/experimental,now 3.5.2-1 amd64  [installé]
tracker/experimental,now 3.6~beta-1 amd64  [installé]
xdg-desktop-portal-gnome/experimental,now 44.2-1 amd64  [installé]

Could it also be related to a filename encoding?

Thanks

Le sam. 19 août 2023 à 19:09, Jörg Frings-Fürst  a écrit :
>
> forwarded 1050083 https://gitlab.gnome.org/GNOME/shotwell/-/issues/5069
> severity 1050083 minor
> thanks
>
>
> Hello Patrice
>
>
> thank you for spending your time helping to make Debian better with this bug
> report.
>
>
> Since I can't reproduce the bug here, I forwarded the report to Upstream. And
> since packages from Experimental are used, the severity was set to minor.
>
>
> To investigate the problem further, please provide us with a list of installed
> Experimental packages.
>
>
> Am Samstag, dem 19.08.2023 um 15:48 +0200 schrieb Patrice Duroux:
> > Package: shotwell
> > Version: 0.32.2-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > My system is a Debian Sid (+ some experimental GNOME 45 packages).
> > Here is what I got using a terminal:
> >
> > #shotwell
> > ** Message: 15:36:49.447: main.vala:445: Starting session with system 
> > profile
> > fish: Job 1, 'shotwell' terminated by signal SIGSEGV (Erreur de frontière
> > d'adresse)
> >
> [...]
>
> > More than one entry matches, ignoring rest.
> >
> > Do not hesitate to ask me more on this if needed.
> >
> > Regards,
> > Patrice
> >
> [...]
>
> 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
>

Bug#1050109: iperf3: [INTL:it] Italian debconf translation

Package: iperf3
Severity: wishlist
Tags: l10n patch
X-Debbugs-Cc: ce...@oziosi.org

Hello,
in the attachment you can find the Italian debconf translation.
Cheers,


--
Ceppo
# iperf3 package's debconf template translation template
# Copyright (C) 2021, 2023 Roberto Lumbreras
# This file is distributed under the same license as the iperf3 package.
# Roberto Lumbreras, 2021, 2023
#
msgid ""
msgstr ""
"Project-Id-Version: iperf3\n"
"Report-Msgid-Bugs-To: ipe...@packages.debian.org\n"
"POT-Creation-Date: 2021-06-27 19:24+0200\n"
"PO-Revision-Date: 2023-07-12 00:00+\n"
"Last-Translator: Ceppo \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Start Iperf3 as a daemon automatically?"
msgstr "Avviare automaticamente Iperf3 come demone?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"Choose this option if Iperf3 should start automatically as a daemon, now and "
"at boot time."
msgstr ""
"Scegliere questa opzione per avviare automaticamente Iperf3 come demone, "
"adesso e al momento dell'avvio."

Bug#1047054: sysvinit: Fails to build source after successful build

2023-08-19 Thread Jesse Smith

Thank you, I'll add this patch upstream for the next version.

- Jesse



On 2023-08-19 4:28 p.m., Mark Hindley wrote:
> Control: tags -1 pending patch
>
> Lucas,
>
> Thanks for raising this. Fixed version is pending.
>
> Jesse,
>
> My patch for man/Makefile to fix the clean recipe is attached. You may want 
> it,
> or something similar, upstream.
>
> Thanks.
>
> Mark

Bug#1050108: elfutils: [INTL:it] Italian debconf translation

Package: elfutils
Severity: wishlist
Tags: l10n patch
X-Debbugs-Cc: ce...@oziosi.org

Hello,
in the attachment you can find the Italian debconf translation. I think it
should be placed in `debian/po/it.po`.
Cheers,


--
Ceppo
# elfutils po-debconf italian translation.
# Copyright (C) 2023 elfutils' copyright holder
# This file is distributed under the same license as the elfutils package.
# Ceppo , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: elfutils\n"
"Report-Msgid-Bugs-To: elfut...@packages.debian.org\n"
"POT-Creation-Date: 2021-03-06 18:23-0500\n"
"PO-Revision-Date: 2023-07-11 00:00+\n"
"Last-Translator: Ceppo \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../libdebuginfod-common.templates:1001
msgid "Connect to Debian's debuginfod server to download debug symbols?"
msgstr ""
"Connettersi al server debuginfod di Debian per scaricare i simboli di debug?"

#. Type: boolean
#. Description
#: ../libdebuginfod-common.templates:1001
msgid ""
"While debugging programs (with GDB, for example) or using debuginfo-consumer "
"applications, it is possible to connect to Debian's debuginfod server and "
"download the necessary debug information for the program you are debugging "
"on-the-fly, without the need to configure the debian-debug apt repository "
"nor installing any dbgsym packages.  This service is maintained by Debian, "
"and the only information you will have to send to it is the Build-ID hash of "
"the program(s)/library(ies) being debugged."
msgstr ""
"Mentre si effettua il debug di programmi (con GDB, ad esempio) o si usano "
"applicazioni che utilizzano debuginfo, è possibile connettersi al server "
"debuginfod di Debian e scaricare al momento le informazioni di debug per il "
"programma di cui si sta effettuando il debug, senza bisogno di configurare "
"il repository apt debian-debug né di installare alcun pacchetto dbgsym. "
"Questo servizio è mantenuto da Debian e l'unica informazione che sarà "
"necessario inviare è l'hash del Build-ID del programma/libreria di cui si "
"sta effettuando il debug."

Bug#1050107: puppet-agent: [INTL:it] Italian debconf translation

Package: puppet-agent
Severity: wishlist
Tags: l10n patch
X-Debbugs-Cc: ce...@oziosi.org

Hello,
in the attachment you can find the Italian debconf translation. I think it
should be placed in `debian/po/it.po`.
Cheers,


--
Ceppo
# puppet-agent po-debconf italian translation.
# Copyright (C) 2023 puppet-agent's copuright holder
# This file is distributed under the same license as the puppet-agent package.
# Ceppo , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: puppet-agent\n"
"Report-Msgid-Bugs-To: puppet-ag...@packages.debian.org\n"
"POT-Creation-Date: 2023-01-28 13:26-0500\n"
"PO-Revision-Date: 2023-07-11 00:00+\n"
"Last-Translator: Ceppo \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../puppet-agent.templates:1001
msgid "Remove Puppet configuration and data when package is purged?"
msgstr ""
"Rimuovere la configurazione e i dati di Puppet quando viene eseguito il "
"purge del pacchetto?"

#. Type: boolean
#. Description
#: ../puppet-agent.templates:1001
msgid ""
"The directories containing Puppet code, environments, configuration, ssl "
"certificates, logs and other data are about to be removed."
msgstr ""
"Le directory contenenti codice, ambienti, configurazione, certificati ssl, "
"log e altri dati di Puppet stanno per essere rimosse."

#. Type: boolean
#. Description
#: ../puppet-agent.templates:1001
msgid ""
"If you're purging the puppet-agent package in order to replace it with a "
"more recent or custom version or if you want to keep the data for further "
"analysis, the data should be kept."
msgstr ""
"Se si sta eseguendo la rimozione completa del pacchetto puppet-agent per "
"sostituirlo con una versione più recente o personalizzata o se si desidera "
"conservare i dati per ulteriori analisi, i dati dovrebbero essere mantenuti."

#. Type: boolean
#. Description
#: ../puppet-agent.templates:1001
msgid ""
"If puppet.conf was modified from its default configuration, some data may "
"still remain."
msgstr ""
"Se puppet.conf è stato modificato rispetto alla configurazione predefinita, "
"alcuni dati potrebbero comunque permanere."

Bug#1050106: lxc: [INTL:it] Italian debconf translation

Package: lxc
Severity: wishlist
Tags: l10n patch
X-Debbugs-Cc: ce...@oziosi.org

Hello,
in the attachment you can find the Italian debconf translation. I think it
should be placed in `debian/po/it.po`.
Cheers,


--
Ceppo
# lxc po-debconf italian translation.
# Copyright (C) 2023 lxc's copyright holder
# This file is distributed under the same license as the lxc package.
# Ceppo , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: lxc\n"
"Report-Msgid-Bugs-To: l...@packages.debian.org\n"
"POT-Creation-Date: 2018-11-29 22:19+0100\n"
"PO-Revision-Date: 2023-07-11 00:00+\n"
"Last-Translator: Ceppo \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Auto update lxc2 configuration format to lxc3?"
msgstr ""
"Aggiornare automaticamente il formato della configurazione di lxc2 a lxc3?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"LXC 3 comes with many changes for containers' configuration files. It also "
"comes with a binary `/usr/bin/lxc-update-config` that allows one to update "
"his configuration."
msgstr ""
"LXC 3 porta molti cambiamenti ai file di configurazione dei container. "
"Fornisce inoltre un binario, \"/usr/bin/lxc-update-config\", che consente di "
"aggiornare la sua configurazione."

#. Type: boolean
#. Description
#: ../templates:1001
msgid "This job can be done either automatically now or manually later."
msgstr ""
"Questa operazione può essere eseguita automaticamente adesso oppure "
"manualmente più tardi."

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"Unpriviledged containers configurations will have to be updated manually "
"either way via the `/usr/bin/lxc-update-config` command."
msgstr ""
"In ogni caso, le configurazioni dei container non privilegiati dovranno "
"essere aggiornate manualmente con il comando \"/usr/bin/lxc-update-config\"."

Bug#1049988: bookworm-pu: package riemann-c-client/1.10.4-2

2023-08-19 Thread Romain Tartière

On Sat, Aug 19, 2023 at 04:58:51PM +0100, Jonathan Wiltshire wrote:
> This seems to be a copy of the most recent upload to unstable; please
> consult the developers' reference and prepare an appropriate diff for a
> stable update.

Sorry for the confusion, here is an updated debdiff.  Thank you!

-- 
Romain Tartière http://romain.blogreen.org/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)
diff -Nru riemann-c-client-1.10.4/debian/changelog 
riemann-c-client-1.10.4/debian/changelog
--- riemann-c-client-1.10.4/debian/changelog2019-01-03 07:09:25.0 
-1000
+++ riemann-c-client-1.10.4/debian/changelog2023-08-19 10:21:24.0 
-1000
@@ -1,3 +1,9 @@
+riemann-c-client (1.10.4-2+deb12u1) bookworm; urgency=medium
+
+  * Fix GnuTLS send/recv.
+
+ -- Romain Tartirère   Sat, 19 Aug 2023 10:21:24 -1000
+
 riemann-c-client (1.10.4-2) unstable; urgency=medium
 
   * Orphaning the package.
diff -Nru 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-eagain 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-eagain
--- 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-eagain  
1969-12-31 14:00:00.0 -1000
+++ 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-eagain  
2023-08-19 10:21:23.0 -1000
@@ -0,0 +1,46 @@
+Origin: upstream, 9e382db87bd1703423760bbe104a66e7cdfcf5a6
+Description: Fix GnuTLS send/recv when returning GNUTLS_E_AGAIN
+ Some values returned from gnutls_record_send() / gnutls_record_recv() indicate
+ that the operation could not be done. In such cases, the error should not
+ propagate to the caller but be operation should be retried.
+ .
+ Upstream fixed this issue in 9e382db87bd1703423760bbe104a66e7cdfcf5a6 with a
+ lot more changes, so this patch only fix the wrong behavior.
+Author: Romain Tartière 
+Forwarded: not-needed
+---
+--- riemann-c-client-1.10.4.orig/lib/riemann/client/tls-gnutls.c
 riemann-c-client-1.10.4/lib/riemann/client/tls-gnutls.c
+@@ -202,7 +202,9 @@ _riemann_client_send_message_tls (rieman
+   if (!buffer)
+ return -errno;
+ 
+-  sent = gnutls_record_send (client->tls.session, buffer, len);
++  do {
++sent = gnutls_record_send (client->tls.session, buffer, len);
++  } while (sent == GNUTLS_E_AGAIN || sent == GNUTLS_E_INTERRUPTED);
+   if (sent < 0 || (size_t)sent != len)
+ {
+   free (buffer);
+@@ -220,7 +222,9 @@ _riemann_client_recv_message_tls (rieman
+   ssize_t received;
+   riemann_message_t *message;
+ 
+-  received = gnutls_record_recv (client->tls.session, , sizeof 
(header));
++  do {
++received = gnutls_record_recv (client->tls.session, , sizeof 
(header));
++  } while (received == GNUTLS_E_AGAIN || received == GNUTLS_E_INTERRUPTED);
+   if (received != sizeof (header))
+ {
+   errno = EPROTO;
+@@ -230,7 +234,9 @@ _riemann_client_recv_message_tls (rieman
+ 
+   buffer = (uint8_t *) malloc (len);
+ 
+-  received = gnutls_record_recv (client->tls.session, buffer, len);
++  do {
++received = gnutls_record_recv (client->tls.session, buffer, len);
++  } while (received == GNUTLS_E_AGAIN || received == GNUTLS_E_INTERRUPTED);
+   if (received != len)
+ {
+   free (buffer);
diff -Nru 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-less-than-expected
 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-less-than-expected
--- 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-less-than-expected
  1969-12-31 14:00:00.0 -1000
+++ 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-less-than-expected
  2023-08-19 10:21:23.0 -1000
@@ -0,0 +1,91 @@
+Description: Fix GnuTLS send/recv when returning a lower value than expected
+ gnutls_record_send() / gnutls_record_recv() may be interrupted after some data
+ transmission but before the message was completely read/written.  When this
+ happen, the value returned by the function is positive but lower that the size
+ of the read/write.  In this case, we should not return an error, but rather
+ loop to recv/send the missing data.
+Author: Romain Tartière 
+Forwarded: https://git.madhouse-project.org/algernon/riemann-c-client/pulls/14
+---
+--- riemann-c-client-1.10.4.orig/lib/riemann/client/tls-gnutls.c
 riemann-c-client-1.10.4/lib/riemann/client/tls-gnutls.c
+@@ -202,13 +202,18 @@ _riemann_client_send_message_tls (rieman
+   if (!buffer)
+ return -errno;
+ 
+-  do {
+-sent = gnutls_record_send (client->tls.session, buffer, len);
+-  } while (sent == GNUTLS_E_AGAIN || sent == GNUTLS_E_INTERRUPTED);
+-  if (sent < 0 || (size_t)sent != len)
++  size_t left = len;
++  while (left > 0)
+ {
+-  free (buffer);
+-  return -EPROTO;
++  do {
++sent = gnutls_record_send (client->tls.session, buffer + len - left, 
left);
++  } while

Bug#1049982: bullseye-pu: package riemann-c-client/1.10.4-2+b2

2023-08-19 Thread Romain Tartière

On Thu, Aug 17, 2023 at 10:52:17PM +0100, Adam D. Barratt wrote:
> Please supply an appropriate debdiff.

Sorry for the confusion, here is an updated debdiff.  Thank you!

-- 
Romain Tartière http://romain.blogreen.org/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)
diff -Nru riemann-c-client-1.10.4/debian/changelog 
riemann-c-client-1.10.4/debian/changelog
--- riemann-c-client-1.10.4/debian/changelog2019-01-03 07:09:25.0 
-1000
+++ riemann-c-client-1.10.4/debian/changelog2023-08-19 10:21:25.0 
-1000
@@ -1,3 +1,9 @@
+riemann-c-client (1.10.4-2+deb11u1) bullseye; urgency=medium
+
+  * Fix GnuTLS send/recv.
+
+ -- Romain Tartirère   Sat, 19 Aug 2023 10:21:25 -1000
+
 riemann-c-client (1.10.4-2) unstable; urgency=medium
 
   * Orphaning the package.
diff -Nru 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-eagain 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-eagain
--- 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-eagain  
1969-12-31 14:00:00.0 -1000
+++ 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-eagain  
2023-08-19 10:21:24.0 -1000
@@ -0,0 +1,46 @@
+Origin: upstream, 9e382db87bd1703423760bbe104a66e7cdfcf5a6
+Description: Fix GnuTLS send/recv when returning GNUTLS_E_AGAIN
+ Some values returned from gnutls_record_send() / gnutls_record_recv() indicate
+ that the operation could not be done. In such cases, the error should not
+ propagate to the caller but be operation should be retried.
+ .
+ Upstream fixed this issue in 9e382db87bd1703423760bbe104a66e7cdfcf5a6 with a
+ lot more changes, so this patch only fix the wrong behavior.
+Author: Romain Tartière 
+Forwarded: not-needed
+---
+--- riemann-c-client-1.10.4.orig/lib/riemann/client/tls-gnutls.c
 riemann-c-client-1.10.4/lib/riemann/client/tls-gnutls.c
+@@ -202,7 +202,9 @@ _riemann_client_send_message_tls (rieman
+   if (!buffer)
+ return -errno;
+ 
+-  sent = gnutls_record_send (client->tls.session, buffer, len);
++  do {
++sent = gnutls_record_send (client->tls.session, buffer, len);
++  } while (sent == GNUTLS_E_AGAIN || sent == GNUTLS_E_INTERRUPTED);
+   if (sent < 0 || (size_t)sent != len)
+ {
+   free (buffer);
+@@ -220,7 +222,9 @@ _riemann_client_recv_message_tls (rieman
+   ssize_t received;
+   riemann_message_t *message;
+ 
+-  received = gnutls_record_recv (client->tls.session, , sizeof 
(header));
++  do {
++received = gnutls_record_recv (client->tls.session, , sizeof 
(header));
++  } while (received == GNUTLS_E_AGAIN || received == GNUTLS_E_INTERRUPTED);
+   if (received != sizeof (header))
+ {
+   errno = EPROTO;
+@@ -230,7 +234,9 @@ _riemann_client_recv_message_tls (rieman
+ 
+   buffer = (uint8_t *) malloc (len);
+ 
+-  received = gnutls_record_recv (client->tls.session, buffer, len);
++  do {
++received = gnutls_record_recv (client->tls.session, buffer, len);
++  } while (received == GNUTLS_E_AGAIN || received == GNUTLS_E_INTERRUPTED);
+   if (received != len)
+ {
+   free (buffer);
diff -Nru 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-less-than-expected
 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-less-than-expected
--- 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-less-than-expected
  1969-12-31 14:00:00.0 -1000
+++ 
riemann-c-client-1.10.4/debian/patches/fix-gnutls-send-recv-when-return-less-than-expected
  2023-08-19 10:21:24.0 -1000
@@ -0,0 +1,91 @@
+Description: Fix GnuTLS send/recv when returning a lower value than expected
+ gnutls_record_send() / gnutls_record_recv() may be interrupted after some data
+ transmission but before the message was completely read/written.  When this
+ happen, the value returned by the function is positive but lower that the size
+ of the read/write.  In this case, we should not return an error, but rather
+ loop to recv/send the missing data.
+Author: Romain Tartière 
+Forwarded: https://git.madhouse-project.org/algernon/riemann-c-client/pulls/14
+---
+--- riemann-c-client-1.10.4.orig/lib/riemann/client/tls-gnutls.c
 riemann-c-client-1.10.4/lib/riemann/client/tls-gnutls.c
+@@ -202,13 +202,18 @@ _riemann_client_send_message_tls (rieman
+   if (!buffer)
+ return -errno;
+ 
+-  do {
+-sent = gnutls_record_send (client->tls.session, buffer, len);
+-  } while (sent == GNUTLS_E_AGAIN || sent == GNUTLS_E_INTERRUPTED);
+-  if (sent < 0 || (size_t)sent != len)
++  size_t left = len;
++  while (left > 0)
+ {
+-  free (buffer);
+-  return -EPROTO;
++  do {
++sent = gnutls_record_send (client->tls.session, buffer + len - left, 
left);
++  } while (sent == GNUTLS_E_AGAIN || sent == GNUTLS_E_INTERRUPTED);
++  if (sent < 0)
++{
++  free (buffer);
++

Bug#756120: gcc-defaults: Please provide libstdc++-doc metapackage

2023-08-19 Thread Jochen Sprickerhof

Source: gcc-defaults
Followup-For: Bug #756120
Control: tags -1 patch

Hi doko,

please find a patch for this attached.

Cheers Jochen
>From 9a3dc5402a8cc2a20fafee8ce9eb9898d33f3b6f Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Sat, 19 Aug 2023 21:22:26 +0200
Subject: [PATCH] Add libstdc++-doc package

---
 debian/control   | 9 +
 debian/control.native.in | 9 +
 debian/rules | 2 +-
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index dac97d2..38b5b7a 100644
--- a/debian/control
+++ b/debian/control
@@ -423,6 +423,15 @@ Description: GCC offloading compiler to AMD GCN
  .
  This is a dependency package providing the default AMD GCN offload compiler.
 
+Package: libstdc++-doc
+Section: doc
+Priority: optional
+Architecture: all
+Depends: libstdc++-${pv:gpp}-doc ${reqv:gpp}, ${misc:Depends}
+Description: GNU Standard C++ Library v3 (documentation files)
+ This is a dependency package providing the default documentation files for the
+ GNU stdc++ library.
+
 Package: gcc-hppa64-linux-gnu
 Priority: optional
 Architecture: amd64 hppa i386 x32
diff --git a/debian/control.native.in b/debian/control.native.in
index 2fbf2ed..b7c40d9 100644
--- a/debian/control.native.in
+++ b/debian/control.native.in
@@ -411,3 +411,12 @@ Description: GCC offloading compiler to AMD GCN
  This package contains libgomp plugin for offloading to AMD GCN
  .
  This is a dependency package providing the default AMD GCN offload compiler.
+
+Package: libstdc++-doc
+Section: doc
+Priority: optional
+Architecture: all
+Depends: libstdc++-${pv:gpp}-doc ${reqv:gpp}, ${misc:Depends}
+Description: GNU Standard C++ Library v3 (documentation files)
+ This is a dependency package providing the default documentation files for the
+ GNU stdc++ library.
diff --git a/debian/rules b/debian/rules
index 212fd83..3725f0d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1247,7 +1247,7 @@ ifeq ($(with_native),yes)
dh_testroot
 #  dh_installdebconf
dh_installdocs -pcpp
-   for p in `dh_listpackages $(nopkgs_native) -Ncpp $(if $(filter 
yes,$(with_gfdl_docs)),-Ncpp-doc -Ngcc-doc -Ngfortran-doc -Ngccgo-doc) -Ngdc 
-Nlibgphobos-dev`; do \
+   for p in `dh_listpackages $(nopkgs_native) -Ncpp $(if $(filter 
yes,$(with_gfdl_docs)),-Ncpp-doc -Ngcc-doc -Ngfortran-doc -Ngccgo-doc) -Ngdc 
-Nlibgphobos-dev -Nlibstdc++-doc`; do \
  case "$$p" in \
*-gnu*|*-kfreebsd*|gcc-hppa64-linux-gnu) continue;; \
*) t=cpp; \
-- 
2.40.1

Bug#856877: Bug#983423: Bug#856877: schroot: Please mount a new instance of /dev/pts

2023-08-19 Thread Christoph Biedl

Simon McVittie wrote...

> 2½ years later, updating a debootstrap merge request reminded me that this
> is unresolved. I see schroot now has a new maintainer and a new upstream:
> please consider applying the patch proposed here to set up a working
> /dev/ptmx and /dev/console in more situations.

Thanks, I'll have a look into that.

> I don't currently have a codeberg account set up, so I haven't proposed
> this at the new upstream yet. I'll try to do that and mark this bug as
> forwarded.

That wouldn't be necessary as it's the same people anyway.

Christoph


signature.asc
Description: PGP signature

Bug#1041810: librsvg: CVE-2023-38633

On Sat, 19 Aug 2023 at 18:57:29 +0200, Salvatore Bonaccorso wrote:
> If you are happy with the results and coverage from unstable, would
> you be open to prepare/finalize next the respective updates for
> bookworm-security and bullseye-security?

I already had them in what I believe to be an uploadable state, so I've
uploaded them to security-master. Please do whatever testing you feel is
appropriate and approve or reject.

librsvg_2.54.7+dfsg-1~deb12u1 is a trivial backport of what's in unstable,

(diff vs. unstable below, debdiff vs. bookworm attached). I've been
using it on a bookworm GNOME desktop for the last few weeks with no
apparent regressions, and I haven't seen any regression reports from
testing/unstable users either.

librsvg_2.50.3+dfsg-1+deb11u1 is

(debdiff vs. bullseye attached). I don't have bullseye on actual hardware
any more, so this has only been tested on a GNOME VM.

smcv

diff --git a/debian/changelog b/debian/changelog
index d58c430b1..825f50e1e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+librsvg (2.54.7+dfsg-1~deb12u1) bookworm-security; urgency=medium
+
+  * Team upload
+  * Rebuild for bookworm-security
+
+ -- Simon McVittie   Sun, 30 Jul 2023 17:13:13 +0100
+
 librsvg (2.54.7+dfsg-1) unstable; urgency=high

   * Team upload
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 4ed071a96..098b7f22b 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,7 +1,7 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = debian/master
-upstream-branch = upstream/latest
+debian-branch = debian/bookworm
+upstream-branch = upstream/2.54.x

 [buildpackage]
 sign-tags = True

librsvg_2.50.3+dfsg-1+deb11u1.debdiff.gz
Description: application/gzip

librsvg_2.54.7+dfsg-1~deb12u1.debdiff.gz
Description: application/gzip

Bug#1050105: Please drop python-setuptools-scm-git-archive from b-deps

Package: matplotlib
Version: 3.6.3-1
Severity: minor

Upstream setuptools-scm-git-archive is obsolete -- setuptools-scm >= 7
has everything, so I would like to get it out of Debian.

The upstream matplotlib 3.6.3 doesn't depend on setuptools-scm-git-
archive, but the Debian package still b-deps on it -- and it's wrong:
please drop that line.

Thanks,

J.Puydt

Bug#1042376: digikam crashes with "Illegal instruction"

2023-08-19 Thread Steven Robbins

On Saturday, August 19, 2023 11:53:35 A.M. CDT you wrote:
>Hi Steve,
> 
>I'm afraid, it doesn't prevent digikam from crashing.
> 
>Here is what I did (after fetching the latest updates from "testing" this
> morning):

[ ... ]

>Not sure if my approach is the preferred way to test something across
> different branches, though. I didn't want to switch my entire system to
> "sid" (this is my main machine, after all :) ). Hope that's OK. If there's
> a better way of testing your version, please let me know.

The testing approach is fine.  Thanks for this.  

Given the gdb stack trace, this result is what I expected.  I don't understand 
what the illegal instruction is at that address.  I have two ideas at this 
point.

1. Test a build without SSE4.  If you feel up to it, this would be easiest to 
do on your machine because the build-time detection should simply work fine.  
If you have sufficient time and interest, please look at https://
www.linuxfordevices.com/tutorials/debian/build-packages-from-source

If you aren't able to build from sources, let me know.  The alternative is for 
me to build it here after hacking the sources to disable SSE4 detection.

2. Dig further with the debugger to understand what the illegal instruction 
is.  I may be completely wrong in assuming it is an SSE4 instruction -- 
particularly given the fact that the test code we discussed August 13/14 
builds the same with/without the -msse4.1 flag.  If you are handy with gdb you 
can probably dig into the assembly and figure out what the instruction is.

Regards,
-Steve

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

Bug#1050104: Please drop b-dep on python3-setuptools-scm-git-archive

Package: statsmodels
Version: 0.14.0+dfsg-3
Severity: minor

Hi,

upstream setuptools-scm-git-archive is obsolete -- setuptools-scm >= 7
contains everything needed ; so I would like to drop the package from
Debian.

Unfortunately, statsmodels' d/control still mentions it as a b-dep. But
that is incorrect, so it can be dropped.

Thanks,

J.Puydt

Bug#1050103: git-buildpackage: gbp import-orig --uscan --upstream-version drops repack suffix from tag

2023-08-19 Thread Drew Parsons

Package: git-buildpackage
Version: 0.9.32
Severity: normal

gbp import-orig creates a git tag, with default 
--upstream-tag=upstream/%(version)s

When used with --uscan, the tag includes any repacking suffix (+dfsg1)
specified in debian/watch. However that works only when the latest
upstream release is pulled via uscan.

Sometimes we need an older release, specified by --upstream-version.
But in the case of a specified version, the +dfsg1 repacking suffix is
dropped, it is not used in gbp's upstream tag.

For instance, trying to package adios2
(https://salsa.debian.org/science-team/adios2) and specifying v2.8.1,
I get:

$ gbp import-orig --uscan -u2.8.1 --verbose
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
gbp:debug: ['git', 'status', '--porcelain']
gbp:info: Launching uscan...
Newest version of adios2 on remote site is 2.8.1, specified download version is 
2.8.1
Successfully repacked ../adios2-2.8.1.tar.gz as 
../adios2_2.8.1+dfsg1.orig.tar.xz, deleting 517 files from itgbp:info: Using 
uscan downloaded tarball ../adios2_2.8.1+dfsg1.orig.tar.xz
gbp:debug: ['git', 'tag', '-l', 'upstream/2.8.1']
gbp:debug: tar ['-C', '../tmp1zd0cmte', '-a', '-xf', 
'../adios2_2.8.1+dfsg1.orig.tar.xz'] []
gbp:debug: Unpacked '../adios2_2.8.1+dfsg1.orig.tar.xz' to 
'../tmp1zd0cmte/ADIOS2-2.8.1'
gbp:info: 
gbp:info: Importing '../adios2_2.8.1+dfsg1.orig.tar.xz' to branch 'upstream'...
gbp:info: Source package is adios2
gbp:info: Upstream version is 2.8.1
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
gbp:debug: ['git', 'add', '-f', '.']
gbp:debug: ['git', 'write-tree']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
gbp:debug: ['git', 'commit-tree', 'b6bd2fec8ddd4682bb7b16f87e57286f93ac0984', 
'-p', '0d8247511446cb41740f2cbb74ee40943e549e82']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 2.8.1', 
'refs/heads/upstream', '687fef9491c76d31f551408e1dfc5fa200405fc3', 
'0d8247511446cb41740f2cbb74ee40943e549e82']
gbp:debug: ['git', 'tag', '-m', 'Upstream version 2.8.1', '--no-sign', 
'upstream/2.8.1', '687fef9491c76d31f551408e1dfc5fa200405fc3']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/master']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'master']
gbp:debug: ['git', 'show', '--pretty=medium', 'master:debian/source/format']
gbp:debug: 3.0 (quilt) package, replacing debian/ dir
gbp:info: Replacing upstream source on 'master'
gbp:debug: ['git', 'ls-tree', '-z', 'upstream/2.8.1^{tree}', '--']
gbp:debug: ['git', 'ls-tree', '-z', 'master^{tree}', '--']
gbp:debug: Using 98a2d1eddd69b16b3b68b040a0132f9c80ebef39 as debian/ tree
gbp:debug: ['git', 'mktree', '-z']
gbp:debug: ['git', 'commit-tree', '11b6cfd34d89eea0c9c12ac8f1a1f04346f1da5b', 
'-p', 'master^{commit}', '-p', 'upstream/2.8.1^{commit}']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: Updating master after import of 
upstream/2.8.1', 'refs/heads/master', 
'f687f080be196b7a37375aa561f561d4bd104678']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'reset', '--quiet', '--hard', 
'f687f080be196b7a37375aa561f561d4bd104678', '--']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: rm ['-rf', '../tmp1zd0cmte'] []
gbp:info: Successfully imported version 2.8.1 of 
../adios2_2.8.1+dfsg1.orig.tar.xz
drew@sandy:~/projects/mathlibs/build/adios2$ git tag
upstream/2.5.0+g2020.05.13
upstream/2.5.0+g2020.05.13.1
upstream/2.5.0+g2020.05.13.1+dfsg1
upstream/2.5.0+g2020.05.21+dfsg1
upstream/2.8.1


So the tag is given as upstream/2.8.1 without the +dfsg1 suffix
(but the suffix is used in the orig tarball name)


If I then try to import the latest release (v2.9.1), I get:

$ gbp import-orig --uscan  --verbose
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
gbp:debug: ['git', 'status', '--porcelain']
gbp:info: Launching uscan...
Newest version of adios2 on remote site is 2.9.1, local version is 
2.5.0+g2020.05.21
   (mangled local version is 2.5.0+g2020.05.21)
 => Newer package available from:
=> https://github.com/ornladios/ADIOS2/archive/refs/tags/v2.9.1.tar.gz
Successfully repacked ../adios2-2.9.1.tar.gz as 
../adios2_2.9.1+dfsg1.orig.tar.xz, deleting 517 files from itgbp:info: Using 
uscan downloaded tarball ../adios2_2.9.1+dfsg1.orig.tar.xz
What is the upstream version? [2.9.1+dfsg1] 
gbp:debug: ['git', 'tag', '-l', 'upstream/2.9.1+dfsg1']

Bug#1047054: sysvinit: Fails to build source after successful build

2023-08-19 Thread Mark Hindley

Control: tags -1 pending patch

Lucas,

Thanks for raising this. Fixed version is pending.

Jesse,

My patch for man/Makefile to fix the clean recipe is attached. You may want it,
or something similar, upstream.

Thanks.

Mark
>From 807614887ce310471b72032b4385eed9312acc23 Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Sat, 19 Aug 2023 20:09:52 +0100
Subject: [PATCH] man/Makefile: fix clean recipe (Closes: #1047054).

---
 man/Makefile | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/man/Makefile b/man/Makefile
index 11062419..99475bd8 100644
--- a/man/Makefile
+++ b/man/Makefile
@@ -21,8 +21,7 @@ endif
 install: all
 
 clean distclean:
-	for man in $(MANPAGES) ; do \
-	   if [ -f "$$man.orig" ] ; then mv "$$man.orig" "$$man" ; fi \
-	done
-	for lang in $(LANGUAGES) ; do rm -rf "$$lang" "$$lang.po" ; done
-
+ifdef PO4A
+	po4a $(PO4A_OPTS) --rm-translations po/po4a.cfg
+endif
+	rm -f *.po sysvinit-man.pot
-- 
2.39.2

Bug#1050102: Drop b-dep on python-setuptools-scm-archive

Package: python-jira
Version: 3.5.2-1
Severity: minor

setuptools-scm-archive is obsolete, so I would like to drop its package
from Debian.

Unfortunately, python-jira still b-deps on it. But that can be dropped
from d/control, as the build and upstream don't depend on it anyway!

Cheers,

J.Puydt

Bug#1050101: Drop b-dep on python3-setuptools-scm-git-archive

Package: ocrmypdf
Version: 14.0.1+dfsg1
Severity: minor

Upstream setuptools-scm-git-archive is obsolete, so depending packages
should stop using it.

And in fact, ocrmypdf (contrary to what docs/maintainers.rst says)
doesn't use it anymore, at it depends on setuptools-scm >= 7 ; so I
propose to get rid of the b-dep so we can kick an obsolete package out
of Debian.

Cheers,

J.Puydt

Bug#1050100: gPodder not suggesting normalize-audio

2023-08-19 Thread paculino

Package: gpodder
Version: 3.11.1-1

When gPodder is started from terminal without package normalize-audio, this is 
the error returned:
$ gpodder

1692466078.932185 [gpodder.extensions] ERROR: Cannot load normalize_audio from 
/usr/share/gpodder/extensions/normalize_audio.py: Command not found: 
normalize-ogg
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gpodder/extensions.py", line 255, in 
set_enabled
    self.load_extension()
  File "/usr/lib/python3/dist-packages/gpodder/extensions.py", line 313, in 
load_extension
    self.module = module_file.gPodderExtension(self)
                  ^^
  File "/usr/share/gpodder/extensions/normalize_audio.py", line 48, in __init__
    self.container.require_command('normalize-ogg')
  File "/usr/lib/python3/dist-packages/gpodder/extensions.py", line 215, in 
require_command
    raise MissingCommand(msg, command)
gpodder.extensions.MissingCommand: Command not found: normalize-ogg
1692466078.932721 [gpodder.extensions] WARNING: Could not enable extension: 
Command not found: normalize-ogg
1692466289.397934 [gpodder.my] WARNING: Flush requested, but sync disabled.

Installing package normalize-audio fixes the errors with normalize-ogg, 
although it is not included in the recommended or suggested packages. Since 
some extensions rely on this, might the package normalize-audio be included in 
the suggested packages like yt-dlp?

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

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

Versions of packages gpodder depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.8-2~deb12u1
ii  dbus-x11 [dbus-session-bus]                   1.14.8-2~deb12u1
ii  gir1.2-gtk-3.0                                3.24.37-2
ii  python3                                       3.11.2-1+b1
ii  python3-cairo                                 1.20.1-5+b1
ii  python3-dbus                                  1.3.2-4+b1
ii  python3-gi                                    3.42.2-3+b1
ii  python3-gi-cairo                              3.42.2-3+b1
ii  python3-mygpoclient                           1.9-1
ii  python3-podcastparser                         0.6.9-1
ii  python3-requests                              2.28.1+dfsg-1

Versions of packages gpodder recommends:
ii  gir1.2-ayatanaappindicator3-0.1  0.5.92-1
ii  libgpod4                         0.8.3-17+b1
ii  python3-eyed3                    0.9.7-1
ii  python3-html5lib                 1.1-3
ii  python3-simplejson               3.18.3-1

Versions of packages gpodder suggests:
pn  gnome-bluetooth-sendto  
pn  mplayer                 
ii  yt-dlp                  2023.03.04-1

Additionally, normalize-audio is 0.7.7-17

Bug#1050091: hostname: VCS repository with all past releases

2023-08-19 Thread Michael Meskes

> > > you can find a DEP-14-compliant git repository with the history
> > > of 
> > > the hostname package at
> > > 
> > > https://salsa.debian.org/gioele/hostname
> > > 
> > > My plan is to move this repo into the debian/ namespace in a few 
> > > weeks, unless you are against it.
> > 
> > What is this? Are you trying to highjack the package?
> 
> That must had been the most polite hijacking attempt ever. I even 
> spelled out the instructions to take the repo and make it yours. :)

Let's agree to disagree. I find your behavior rather rude.

> A search on tracker.d.o and all other metadata services showed no
> record 
> of a VCS (because the VCS URLs are missing from d/control) as well as
> a 
> not-yet-acknowledged NMU that happened in 2022.

A new release to just acknowledge an NMU is a waste of time and
bandwidth.


Best,
Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org

Bug#1050027: closed by Debian FTP Masters (reply to Julien Puydt ) (Bug#1050027: fixed in mathcomp-analysis 0.6.4-2)

Le samedi 19 août 2023 à 20:58 +0200, Helmut Grohne a écrit :
> Control: reopen -1
> Control: found -1 mathcomp-analysis/0.6.4-2
> 
> On Sat, Aug 19, 2023 at 05:33:11PM +, Debian Bug Tracking System
> wrote:
> > It has been closed by Debian FTP Masters
> >  (reply to Julien Puydt
> > ).
> 
> I'm sorry. Adding Breaks is necessary but insufficient. You also need
> Replaces.

What is in libcoq-mathcomp-analysis << 0.6.4 is now in two packages:
- libcoq-mathcomp-classical (a small part) ;
- libcoq-mathcomp-analysis (the most part -- and that binary package
depends on libcoq-mathcomp-classical with a strong version constraint).

The problem you pointed was that a user with an old libcoq-mathcomp-
analysis asking to install libcoq-mathcomp-classical would lead dpkg to
a conflict of files.

 The breaks I added prevents that, and in fact a user with an old
licoq-mathcomp-analysis should have no issue in those situations:

(1) try to install a newer libcoq-mathcomp-classical -- with my Breaks
dpkg will refuse because of the conflict which is a sane answer :
system not broken, features not broken ;

(2) try to upgrade - dpkg will see the new libcoq-mathcomp-analysis
needs libcoq-mathcomp-classical and that it breaks the outgoing libcoq-
mathcomp-analysis, but it's able to handle the situation ;

If I declare libcoq-mathcomp-classical Replaces libcoq-mathcomp-
analysis << 0.6.4, then in situation (1), dpkg will install libcoq-
mathcomp-classical and drop that old libcoq-mathcomp-analysis. The
system is not broken, but the user just lost most of the functionality,
and that is bad.

So I think the change I made is sound.

Do you have another problem in mind? Or a better fix?

Cheers,

J.Puydt

Bug#1050099: Drop b-dep on setuptools-scm-git-archive

Package: pyocd
Version: 0.13.1+dfsg-3
Severity: minor

In d/control, the b-dep on python3-setuptools-scm-git-archive can be
dropped:

1. it isn't used anyway (patched out by debian/patches/0001-Update-
setup.py-to-work-with-Python3.patch) ;

2. setuptools-scm-git-archive upstream is obsolete ;

3. pyocd is one of the packages holding its package in Debian.

Cheers,

J.Puydt

Bug#1050027: closed by Debian FTP Masters (reply to Julien Puydt ) (Bug#1050027: fixed in mathcomp-analysis 0.6.4-2)

2023-08-19 Thread Helmut Grohne

Control: reopen -1
Control: found -1 mathcomp-analysis/0.6.4-2

On Sat, Aug 19, 2023 at 05:33:11PM +, Debian Bug Tracking System wrote:
> It has been closed by Debian FTP Masters  
> (reply to Julien Puydt ).

I'm sorry. Adding Breaks is necessary but insufficient. You also need
Replaces.

Helmut

Bug#983423: Bug#856877: schroot: Please mount a new instance of /dev/pts

On Wed, 24 Feb 2021 at 00:47:46 +, Simon McVittie wrote:
> On Sun, 05 Mar 2017 at 19:23:40 +, Simon McVittie wrote:
> > [the change proposed here] makes script(1) work inside "schroot --sbuild"
> > inside a LXC
> > container on a Debian jessie kernel. Previously, that would have failed.
> 
> On Tue, 23 Feb 2021 at 23:55:07 +, Simon McVittie wrote:
> > schroot: Default profile doesn't provide a working /dev/ptmx inside lxc >= 3
> ...
> > The same patch I proposed in 2017 for #856877 resolves this, setting
> > up a working /dev/ptmx.  Under lxc 2 it's a symlink to /dev/ptx/ptmx,
> > and under lxc >= 3 it's a device node.
> >¯
> > Under lxc 4, that patch also provides a working /dev/console.
> 
> Here's the patch I proposed in 2017, with an updated commit message.
> 
> Also available as a merge request:
> https://salsa.debian.org/debian/schroot/-/merge_requests/2

2½ years later, updating a debootstrap merge request reminded me that this
is unresolved. I see schroot now has a new maintainer and a new upstream:
please consider applying the patch proposed here to set up a working
/dev/ptmx and /dev/console in more situations.

I don't currently have a codeberg account set up, so I haven't proposed
this at the new upstream yet. I'll try to do that and mark this bug as
forwarded.

Thanks,
smcv

Bug#1050098: systemd: Using systemd-networkd as DHCP server static leases are ignored

2023-08-19 Thread Jan Dorniak

Package: systemd
Version: 252.12-1~deb12u1
Severity: normal
X-Debbugs-Cc: j...@dorniak.me

Dear Maintainer,

Using two Bookworm systems, one as a DHCP server, one as a DHCP client.

The server does not respect static leases. The issue has been fixed in
systemd 254.

For description, see: https://github.com/systemd/systemd/issues/21368
For the patch, see: https://github.com/systemd/systemd/pull/27313

Jan

-- Package-specific info:

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

Kernel: Linux 5.15.108-1-pve (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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)

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.0.9-1
ii  libblkid1  2.38.1-5+b1
ii  libc6  2.36-9+deb12u1
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-4~deb12u1
ii  libfdisk1  2.38.1-5+b1
ii  libgcrypt201.10.1-3
ii  libkmod2   30+20221128-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.1-0.2
ii  libmount1  2.38.1-5+b1
ii  libp11-kit00.24.1-2
ii  libseccomp22.5.4-1+b3
ii  libselinux13.4-1+b6
ii  libssl33.0.9-1
ii  libsystemd-shared  252.12-1~deb12u1
ii  libsystemd0252.12-1~deb12u1
ii  libzstd1   1.5.4+dfsg2-5
ii  mount  2.38.1-5+b1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.8-2~deb12u1
ii  systemd-timesyncd [time-daemon]  252.12-1~deb12u1

Versions of packages systemd suggests:
ii  libfido2-1 1.12.0-2+b1
pn  libqrencode4   
pn  libtss2-esys-3.0.2-0   
pn  libtss2-mu0
pn  libtss2-rc0
pn  polkitd | policykit-1  
pn  systemd-boot   
pn  systemd-container  
pn  systemd-homed  
pn  systemd-resolved   
pn  systemd-userdbd

Versions of packages systemd is related to:
pn  dbus-user-session  
pn  dracut 
pn  initramfs-tools
ii  libnss-systemd 252.12-1~deb12u1
ii  libpam-systemd 252.12-1~deb12u1
ii  udev   252.12-1~deb12u1

-- no debconf information

Bug#1050091: hostname: VCS repository with all past releases


reopen 1050091
retitle 1050091 hostname: VCS URLs should be specified in d/control
thanks

On 19/08/23 19:37, Michael Meskes wrote:
you can find a DEP-14-compliant git repository with the history of 
the hostname package at


https://salsa.debian.org/gioele/hostname

My plan is to move this repo into the debian/ namespace in a few 
weeks, unless you are against it.


What is this? Are you trying to highjack the package?


That must had been the most polite hijacking attempt ever. I even 
spelled out the instructions to take the repo and make it yours. :)



If you prefer to create the repo on salsa.d.o yourself, you can fork
it
and then use "Settings" → "General" →  "Remove fork relationship".


Right, makes an awful lot of send for me to fork your git and in the
process lose all the commit details from the real git archive, not!

A simple search on salsa would have shown you the real archive.


A search on tracker.d.o and all other metadata services showed no record 
of a VCS (because the VCS URLs are missing from d/control) as well as a 
not-yet-acknowledged NMU that happened in 2022.


Now that I know that there is a VCS repo for hostname, you can find:

1. a MR that acknowledges the NMU at

https://salsa.debian.org/meskes/hostname/-/merge_requests/1

2. a MR that adds the VCS fields at

https://salsa.debian.org/meskes/hostname/-/merge_requests/2

Regards,

--
Gioele Barabucci

Bug#1050093: hostname: Packaging updates (dh 13, simplification)


A ready-to-merge MR can be found at

https://salsa.debian.org/meskes/hostname/-/merge_requests/3

--
Gioele Barabucci

Bug#1033907: numba crashes on non-x86

2023-08-19 Thread Diane Trout

On Sat, 2023-08-19 at 18:21 +0100, Rebecca N. Palmer wrote:
> numba also crashes on mips64el, mipsel and armhf (and s390x but that
> was 
> already known; not amd64, i386 or ppc64el).  However, I agree that
> arm64 
> is a good place to start trying to fix this, given how common it is.
> 

Also given how popular Apple arm chips are upstream has some motivation
to fix numba on arm64.

Bug#1033279: the clamav-freshclam package fails to upgrade on Debian 11

On 2023-03-21 08:42:00 [+0100], Giancarlo Giesa wrote:
> description: the clamav upgrade via apt-get failed
> the reason seems to be that the file /var/log/clamav/freshclam.log is not
> detected but instead this exists

Is this still valid? Asking because…

> proceeding with the command dpkg --configure -a does not solve the problem.
> 
> some output:
> 
> root@nas:~# dpkg --configure -a
> Setting up clamav-freshclam (0.103.8+dfsg-0+deb11u1) ...
> touch: cannot touch '"/var/log/clamav/freshclam.log"': No such file or
> directory

touch on that file does not work. Do you have some kind of symlink setup
or so? /var/log/clamav/ should exist an touching
/var/log/clamav/freshclam.log should be possibling.

…
 
> but the file "/var/log/clamav/freshclam.log" is readable:
> root@nas:~# cat /var/log/clamav/freshclam.log

Is there somerhing special here?

Sebastian

Bug#1050096: Maybe related to bug 1049350

2023-08-19 Thread Michael Rasmussen

Hi,

If I apply the fix from bug 1049350 then it builds on 6.4.0-3 but will
no longer build on 6.4.0-2

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
https://keys.openpgp.org/vks/v1/by-fingerprint/A1306C5094B5E31B7721A3A66F4844C7CA7501AA
mir  datanom  net
https://keys.openpgp.org/vks/v1/by-fingerprint/0C14CD9479667E848770C8F98417B6C5E1BB093F
mir  miras  org
https://keys.openpgp.org/vks/v1/by-fingerprint/5F71405B571CB8EE2A414A4FC77C11E049A06E66
--

'During times of universal deceit, telling the truth becomes a
revolutionary act.' -George Orwell

/usr/games/fortune -es says:
A prig is a fellow who is always making you a present of his opinions.
-- George Eliot


pgpCARV0LmOH4.pgp
Description: OpenPGP digital signature

Bug#1049977: rust-hyper-rustls - please update to match new rust-tokio-rustls

2023-08-19 Thread Jonas Smedegaard

Quoting Jeremy Bícha (2023-08-19 19:56:29)
> In this case, britney noticed an increase in uninstallability which
> would also have prevented the migration of rust-tokio-rustls to
> Testing.
> 
> https://tracker.debian.org/pkg/rust-tokio-rustls

Ah, right - I forgot about those tests.

So I was wrong that it would have a real risk in this case of wrecking
havoc in testing if only a severe bugreport was filed against this
package.

My argument stands, however, that it is the wrong package to file that
severe bugreport against.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1049977: rust-hyper-rustls - please update to match new rust-tokio-rustls

In this case, britney noticed an increase in uninstallability which
would also have prevented the migration of rust-tokio-rustls to
Testing.

https://tracker.debian.org/pkg/rust-tokio-rustls

Thank you for the quick fix though!

Jeremy Bícha

Bug#1043586: dnstwist: Failing autopkgtest with python3-selenium 4.11.2+dfsg-1

2023-08-19 Thread Andres Salomon


Control: affects -1 chromium


On Sun, 13 Aug 2023 12:31:13 +0200 Carsten Schoenert 
 wrote:

> Source: dnstwist
> Version: 0~20230509-1
> Severity: important
>
> Dear Maintainer,
>
> the autopkgtest of dnstwist is failing with the most recent version 
of

> python3-selenium.
>
> This is due a internal change in Selenium upstream since version 
4.11.0.
> Upstream is using a method/component called Selenium Manager since 
then
> and as we can't ship this due it's binary form calling 
webdriver.Chrome()
> needs to be extended about the information which driver needs to be 
used.

>

This is also going to cause chromium to fail to migrate to testing. (I 
say "going to" because chromium has other issues right now, but once 
those are fixed..)

Bug#1049977: rust-hyper-rustls - please update to match new rust-tokio-rustls

2023-08-19 Thread Jonas Smedegaard

Hi Jeremy,

Quoting Jeremy Bícha (2023-08-19 17:45:20)
> I am bumping the severity since rust-hyper-rustls fails to build from
> source in Unstable. This is true regardless of whether this situation
> should have been coordinated better.

It is but academic now that I have uploaded a fix for this, but I
disagree with your raising severity:

This package is not broken *in itself* but is instead *affected* by
breakage in rust-tokio-rustls.  The difference is not merely nitpicking
but has an effect on whether this package can migrate or not to testing:
Since this package is not broken, it is not problematic to let it
migrate to testing, but if rust-tokio-rustls had not had a severe bug
reported against it (and Peter had not been so quick at convincing me to
release a fix this soon) then it would have migrated to testing and
caused breakage there as well.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1050097: scrcpy: fails to build from source on arch:indep

2023-08-19 Thread Gianfranco Costamagna


Package: scrcpy
Version: 1.25-1
Severity: serious
Tags: patch


Dear Maintainer,

For some reasons now the package FTBFS due to missing dx java tool.
I don't know if dalvik-exchange should be pulled in by java automatically, or 
an external additional dependency is needed.
   dh_auto_test -a
cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 
MESON_TESTTHREADS=3 meson test
No tests defined.
   create-stamp debian/debhelper-build-stamp
dh build-indep --buildsystem=makefile
   dh_update_autotools_config -i -O--buildsystem=makefile
   dh_autoreconf -i -O--buildsystem=makefile
   dh_auto_configure -i -O--buildsystem=makefile
   debian/rules override_dh_auto_build-indep
make[2]: Entering directory '/build/scrcpy-1.25'
BUILD_DIR=build_manual ANDROID_PLATFORM=23 ANDROID_BUILD_TOOLS=debian 
server/build_without_gradle.sh
Platform: android-23
Build-tools: debian
Build dir: /build/scrcpy-1.25/build_manual
Generating java from aidl...
Compiling java sources...
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
Dexing...
server/build_without_gradle.sh: line 62: 
/usr/lib/android-sdk/build-tools/debian/dx: No such file or directory
make[2]: *** [debian/rules:41: override_dh_auto_build-indep] Error 127
make[2]: Leaving directory '/build/scrcpy-1.25'
make[1]: *** [debian/rules:22: build] Error 2
make[1]: Leaving directory '/build/scrcpy-1.25'
make: *** [debian/rules:18: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


Adding the dependency works

Thanks for considering the patch.

diff -Nru scrcpy-1.25/debian/control scrcpy-1.25/debian/control
--- scrcpy-1.25/debian/control  2023-01-20 11:28:52.0 +0100
+++ scrcpy-1.25/debian/control  2023-08-19 19:38:24.0 +0200
@@ -16,6 +16,7 @@
  android-sdk,
  android-sdk-platform-23,
  default-jdk,
+ dalvik-exchange,
  unzip,
  zip,
 Rules-Requires-Root: no

Bug#1044136: clamav-daemon: The server delivers "4.7.1 Tempfail- internal scan engine error" when sending with file attachments

On 2023-08-13 17:42:29 [+0200], Andreas Guenther wrote:
>   you can clearly see that the service is triggered by the associated 
> socket! This was not the case with Debian Linux Bullseye!
> 
>   The only currently working solution is this:
> 
>   systemctl disable --now clamav-daemon.socket
>   systemctl enable --now clamav-daemon.service
> 
>   For only one system upgrade, that's pretty sloppy. Why do I need the 
> socket here if it runs better without it?

There went something wrong with the dependency of the socket vs service
file. I just fixed that.
The intention was to start the service via the socket file in case it
was not yet running. Usually because the database files (after a fresh
install) are missing.

Sebastian

Bug#1033907: numba crashes on non-x86

2023-08-19 Thread Rebecca N. Palmer

numba also crashes on mips64el, mipsel and armhf (and s390x but that was 
already known; not amd64, i386 or ppc64el).  However, I agree that arm64 
is a good place to start trying to fix this, given how common it is.


For examples, see the pandas 2.0.3+dfsg-3 / 1.5.3+dfsg-5 build logs. 
Given the different error messages, there may be more than one bug here.

Bug#1050096: virtualbox-dkms: Does not build on 6.4.0-3-amd64

2023-08-19 Thread Michael Rasmussen

Package: virtualbox-dkms
Version: 7.0.10-dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

DKMS make.log for virtualbox-7.0.10 for kernel 6.4.0-3-amd64 (x86_64)
2023-08-19T19:17:04 CEST
make: Entering directory '/usr/src/linux-headers-6.4.0-3-amd64'
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/linux/SUPDrv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrv.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvGip.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvSem.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvTracer.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPLibAll.o
  CC [M]  
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/common/string/strformatrt.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/combined-agnostic1.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/combined-agnostic2.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/combined-os-specific.o
  LD [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
SUPR0TracerFireProbe+0x7: indirect jump found in RETPOLINE build
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
supdrvTracerProbeFireStub+0x0: 'naked' return found in RETHUNK build
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
rtThreadCtxHooksLnxSchedOut+0x23: call to {dynamic}() with UACCESS enabled
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
rtThreadCtxHooksLnxSchedIn+0x2d: call to {dynamic}() with UACCESS enabled
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
VBoxHost_RTR0MemKernelCopyFrom+0x17: redundant CLD
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
VBoxHost_RTR0MemKernelCopyTo+0x17: redundant CLD
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
supdrvTracerCommonDeregisterImpl+0x3c: relocation to !ENDBR: 
supdrvTracerProbeFireStub+0x0
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
___ksymtab+SUPR0TracerFireProbe+0x0: data relocation to !ENDBR: 
SUPR0TracerFireProbe+0x0
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
g_aFunctions+0xea0: data relocation to !ENDBR: SUPR0TracerFireProbe+0x0
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
g_pfnSupdrvProbeFireKernel+0x0: data relocation to !ENDBR: 
supdrvTracerProbeFireStub+0x0
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
SUPR0TracerFireProbe+0x7: missing int3 after indirect jump
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o: warning: objtool: 
supdrvTracerProbeFireStub+0x0: missing int3 after ret
  CC [M]  
/var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/VBoxNetFlt-linux.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/VBoxNetFlt.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/SUPR0IdcClient.o
  CC [M]  
/var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/SUPR0IdcClientComponent.o
  CC [M]  
/var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/SUPR0IdcClient-linux.o
/var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/VBoxNetFlt-linux.c: In 
function ‘vboxNetFltLinuxForwardToIntNetInner’:
/var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/VBoxNetFlt-linux.c:1570:40:
 error: implicit declaration of function ‘skb_gso_segment’; did you mean 
‘skb_gso_reset’? [-Werror=implicit-function-declaration]
 1570 | struct sk_buff *pSegment = skb_gso_segment(pBuf, 0 
/*supported features*/);
  |^~~
  |skb_gso_reset
/var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/VBoxNetFlt-linux.c:1570:40:
 warning: initialization of ‘struct sk_buff *’ from ‘int’ makes pointer from 
integer without a cast [-Wint-conversion]
cc1: some warnings being treated as errors
make[2]: *** [/usr/src/linux-headers-6.4.0-3-common/scripts/Makefile.build:257: 
/var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/VBoxNetFlt-linux.o] 
Error 1
make[1]: *** [/usr/src/linux-headers-6.4.0-3-common/scripts/Makefile.build:502: 
/var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt] Error 2
make: *** [/usr/src/linux-headers-6.4.0-3-common/Makefile:2057: 
/var/lib/dkms/virtualbox/7.0.10/build] Error 2
make: Leaving directory '/usr/src/linux-headers-6.4.0-3-amd64'


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

Kernel: Linux 6.4.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8
Shell: /bin/sh linked to

Bug#1050083: shotwell: crash in folders_sidebar_entry_construct

2023-08-19 Thread Jörg Frings-Fürst

forwarded 1050083 https://gitlab.gnome.org/GNOME/shotwell/-/issues/5069
severity 1050083 minor
thanks


Hello Patrice


thank you for spending your time helping to make Debian better with this bug
report.


Since I can't reproduce the bug here, I forwarded the report to Upstream. And
since packages from Experimental are used, the severity was set to minor.


To investigate the problem further, please provide us with a list of installed
Experimental packages.


Am Samstag, dem 19.08.2023 um 15:48 +0200 schrieb Patrice Duroux:
> Package: shotwell
> Version: 0.32.2-1
> Severity: normal
> 
> Dear Maintainer,
> 
> My system is a Debian Sid (+ some experimental GNOME 45 packages).
> Here is what I got using a terminal:
> 
> #shotwell
> ** Message: 15:36:49.447: main.vala:445: Starting session with system profile
> fish: Job 1, 'shotwell' terminated by signal SIGSEGV (Erreur de frontière
> d'adresse)
> 
[...]

> More than one entry matches, ignoring rest.
> 
> Do not hesitate to ask me more on this if needed.
> 
> Regards,
> Patrice
> 
[...]

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#1050095: faad2: CVE-2023-38858

Source: faad2
Version: 2.10.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/knik0/faad2/issues/173
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for faad2.

CVE-2023-38858[0]:
| Buffer Overflow vulnerability infaad2 v.2.10.1 allows a remote
| attacker to execute arbitrary code and cause a denial of service via
| the mp4info function in mp4read.c:1039.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-38858
https://www.cve.org/CVERecord?id=CVE-2023-38858
[1] https://github.com/knik0/faad2/issues/173

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1049977: rust-hyper-rustls - please update to match new rust-tokio-rustls

2023-08-19 Thread Jonas Smedegaard

Quoting Peter Green (2023-08-19 14:30:22)
> > Since rust-hyper-rustls has reverse dependencies as well, its move
> > to to v0.24 will involve NEW queue and potentially take some time.
> 
> According to my searches the only direct reverse dependency of
> rust-hyper-rustls is rust-reqwest.

Indeed - I made the error of taking into account indirect reverse
dependencies.


I have the new version of that (which is not semver-breaking) ready to
> upload as soon as hyper-rustls is uploaded to unstable.

Excellent: Then I'll re-release to unstable now.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1050094: faad2: CVE-2023-38857

Source: faad2
Version: 2.10.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/knik0/faad2/issues/171
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for faad2.

CVE-2023-38857[0]:
| Buffer Overflow vulnerability infaad2 v.2.10.1 allows a remote
| attacker to execute arbitrary code and cause a denial of service via
| the stcoin function in mp4read.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-38857
https://www.cve.org/CVERecord?id=CVE-2023-38857
[1] https://github.com/knik0/faad2/issues/171

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1049964: closed by Debian FTP Masters (reply to Georges Khaznadar ) (Bug#1049964: fixed in cron 3.0pl1-169)

2023-08-19 Thread Vincent Lefevre

On 2023-08-19 13:01:28 +0200, Chris Hofstaedtler wrote:
> someone on IRC pointed out, that:
> 
> 1) the original bug report seems to point out something that is not
> a problem on supported systems. On such systems, /usr/sbin and
> /sbin, and /usr/bin and /bin are equivalent.

IMHO, it is too soon to assume that all systems are usrmerge
(there should be a longer transition period of old machines),
in particular if it easy to support both kinds of systems.

At least, an *old* crontab file should have have been blindly
modified.

> 2) The patch in fefe29b3415fddc4163bc0f9a0b73dfde6564663 is broken:
> 
> -# define _PATH_DEFPATH "/usr/bin:/bin"
> +# define _PATH_DEFPATH "/usr/sbin:/usr/bin:/bin/sbin"
> ^

and this is not _PATH_DEFPATH that should be changed, but
debian/crontab.main (for /etc/crontab).

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

Bug#1019361: clamav-daemon: cron job fails

On 2022-09-07 15:26:44 [-0500], Tim McConnell wrote:
> --log="$HOME/.clamtk/history/$(date +\%b-\%d-\%Y).log" 2>/dev/null # clamtk-
> scan"
>  Loaded: loaded (/var/spool/cron/crontabs/tmick; generated)
>  Active: failed (Result: exit-code) since Wed 2022-09-07 04:39:26 CDT; 1s
> ago
> TriggeredBy: ● cron-tmick-tmick-0.timer
>Docs: man:systemd-crontab-generator(8)
> Process: 25146 ExecStart=/bin/sh /run/systemd/generator/cron-tmick-
> tmick-0.sh (code=exited, status=1/FAILURE)
>Main PID: 25146 (code=exited, status=1/FAILURE)
> CPU: 3h 52min 16.894s
> 
> Sep 07 04:39:25 DebianTim sh[25149]: Data scanned: 56848.61 MB
> Sep 07 04:39:25 DebianTim sh[25149]: Data read: 375263.33 MB (ratio 0.15:1)
> Sep 07 04:39:25 DebianTim sh[25149]: Time: 16825.735 sec (280 m 25 s)
> Sep 07 04:39:25 DebianTim sh[25149]: Start Date: 2022:09:06 23:59:00
> Sep 07 04:39:25 DebianTim sh[25149]: End Date:   2022:09:07 04:39:25
> Sep 07 04:39:26 DebianTim systemd[1]: cron-tmick-tmick-0.service: Main process
> exited, code=exited, status=1/FAILURE
> Sep 07 04:39:26 DebianTim systemd[1]: cron-tmick-tmick-0.service: Failed with
> result 'exit-code'.
…
> How do I fix the report/ cron job??

This does not appear be a clamav/clamscan problem. It run for almost
four hours and then quit. Please consult the logfile for the results.
clamscan should exit with 2 on error, 1 if infected files were found and
0 on success (everything was fine, nothing found).
Systemd assumes exitcode != 0 is an error.

Sebastian

Bug#1049821: g3dviewer: Fails to build binary packages again after successful build

2023-08-19 Thread Sven Eckelmann

Control: merge 924973 1049821 

On Wednesday, 16 August 2023 10:26:37 CEST you wrote:
> This package fails to do build a binary-only build (not source) after a
> successful build (dpkg-buildpackage ; dpkg-buildpackage -b).
> 
> This is probably a clear violation of Debian Policy section 4.9 (clean 
> target),
> but this is filed as severity:minor for now, because a discussion on
> debian-devel showed that we might want to revisit the requirement of a working
> 'clean' target.
[...]
> > /bin/bash: ../mkinstalldirs: No such file or directory

Looks like #670796 (dh-autoreconf) which was reported against g3dviewer in 
#924973.

Kind regards,
Sven

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

Bug#1041810: librsvg: CVE-2023-38633

Hi Simon,

On Sun, Jul 30, 2023 at 09:48:57PM +0100, Simon McVittie wrote:
> On Sun, 30 Jul 2023 at 22:04:24 +0200, Salvatore Bonaccorso wrote:
> > For bullseye I think we should simply pick the upstream commit?
> 
> Yes: we didn't keep up with upstream 2.50.x so there are a bunch of
> unrelated fixes (2.50.4 up to .7) which would be out of scope for a
> security update. If it was a package I knew better then I might be
> advocating the new upstream release, but I can't really assess risk vs
> benefit for librsvg, so cherry-picking the equivalent of .8 and .9 seems
> more conservative.
> 
> 
> compiles successfully, I'll try it in a bullseye VM next.

If you are happy with the results and coverage from unstable, would
you be open to prepare/finalize next the respective updates for
bookworm-security and bullseye-security?

Thanks a lot for your work so far on it!

Regards,
Salvatore

Bug#1042376: digikam crashes with "Illegal instruction"

2023-08-19 Thread Detlef Matthiessen




  Hi Steve,

  I'm afraid, it doesn't prevent digikam from crashing.

  Here is what I did (after fetching the latest updates from "testing" this 
morning):

root@fluke:/etc/apt# sed -i 's/trixie/sid/' sources.list
root@fluke:/etc/apt# apt-get update
Get:1 http://ftp.de.debian.org/debian sid InRelease [210 kB]
(...)

root@fluke:/etc/apt# apt-get install digikam
(...)
The following additional packages will be installed:
  digikam-data digikam-private-libs
Suggested packages:
  digikam-doc
The following packages will be upgraded:
  digikam digikam-data digikam-private-libs
3 upgraded, 0 newly installed, 0 to remove and 212 not upgraded.
Need to get 19.2 MB of archives.
After this operation, 2,048 B disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://ftp.de.debian.org/debian sid/main amd64 digikam amd64 4:8.1.0-3 
[100 kB]
Get:2 http://ftp.de.debian.org/debian sid/main amd64 digikam-private-libs amd64 
4:8.1.0-3 [9,949 kB]
Get:3 http://ftp.de.debian.org/debian sid/main amd64 digikam-data all 4:8.1.0-3 
[9,121 kB]
Fetched 19.2 MB in 2s (12.0 MB/s)
Reading changelogs... Done
(Reading database ... 475773 files and directories currently installed.)
Preparing to unpack .../digikam_4%3a8.1.0-3_amd64.deb ...
Unpacking digikam (4:8.1.0-3) over (4:8.1.0-2+b1) ...
Preparing to unpack .../digikam-private-libs_4%3a8.1.0-3_amd64.deb ...
Unpacking digikam-private-libs (4:8.1.0-3) over (4:8.1.0-2+b1) ...
Preparing to unpack .../digikam-data_4%3a8.1.0-3_all.deb ...
Unpacking digikam-data (4:8.1.0-3) over (4:8.1.0-2) ...
Setting up digikam-private-libs (4:8.1.0-3) ...
Setting up digikam-data (4:8.1.0-3) ...
Setting up digikam (4:8.1.0-3) ...
(...)

dm@fluke:~$ digikam
Illegal instruction
dm@fluke:~$ export DEBUGINFOD_URLS="https://debuginfod.debian.net;
dm@fluke:~$ gdb digikam
(...)
Program received signal SIGILL, Illegal instruction.
0x76cc2103 in operator* (m1=..., m2=...) at 
/usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h:642
642 QMatrix4x4 m = m1;
(gdb) bt
#0  0x76cc2103 in operator* (m1=..., m2=...) at 
/usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h:642
#1  0x765b861d in __static_initialization_and_destruction_0 () at 
./core/libs/video/qtav/utils/ColorTransform.cpp:59
#2  0x77fcfe2e in call_init (env=0x7fffe0b8, argv=0x7fffe0a8, argc=1, 
l=) at ./elf/dl-init.c:70
#3  call_init (l=, argc=1, argv=0x7fffe0a8, 
env=0x7fffe0b8) at ./elf/dl-init.c:26
#4  0x77fcff14 in _dl_init (main_map=0x77ffe2c0, argc=1, 
argv=0x7fffe0a8, env=0x7fffe0b8) at ./elf/dl-init.c:117
#5  0x77fe5170 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6  0x0001 in ?? ()
#7  0x7fffe3d4 in ?? ()
#8  0x in ?? ()

  Not sure if my approach is the preferred way to test something across different 
branches, though. I didn't want to switch my entire system to "sid" (this is my 
main machine, after all :) ). Hope that's OK. If there's a better way of testing your 
version, please let me know.

  I'm willing to repeat the test once 8.1.0-3 lands in "testing" although I'm 
not expecting the result to be different.

  Cheers,

Detlef

Bug#1050085: RFS: vnstat/2.11-1 -- console-based network traffic monitor

2023-08-19 Thread Jeroen Ploemen

Control: tags -1 moreinfo

On Sat, 19 Aug 2023 16:56:12 +0200
Christian Göttsche  wrote:

> I am looking for a sponsor for my package vnstat:

hi Christian,

one minor issue:
* copyright: years outdated for upstream only


Please remove the moreinfo tag (and CC me directly) once you have an
updated package ready.


pgplt0b38Y5Yi.pgp
Description: OpenPGP digital signature

Bug#1030171: clamav-daemon: clamav-clamonacc.service fails to start

On 2023-06-12 08:39:53 [+0300], Martin-Éric Racine wrote:
> Syslog already suggests what the fix should be:
> 
> $ grep Clamonacc /var/log/syslog
> 2023-06-12T08:33:40.562184+03:00 p8h61 clamonacc[248359]: ERROR:
> Clamonacc: at least one of OnAccessExcludeUID, OnAccessExcludeUname,
> or OnAccessExcludeRootUID must be specified ... it is recommended you
> exclude the clamd instance UID or uname to prevent infinite event
> scanning loops
> 
> When will this get implemented?

I'm going to disable the servuce by default on new instalation. It was
agreed on not have it running by default. These option are not set in
the default config file shipped by upstream.

> Martin-Éric

Sebastian

Bug#1050093: hostname: Packaging updates (dh 13, simplification)


Package: hostname
Version: 3.23+nmu1
Tags: patch

Dear hostname maintainer,

you can find a series of patches that update the packaging of `hostname` 
to debhelper 13 and to the standard dh sequence at


https://salsa.debian.org/gioele/hostname/-/compare/debian%2Flatest...dh-13

The debian/rules files is now almost empty and the package is fully 
lintian clean.


diffoscope says that the generated binary package is identical to the 
current binary package (except for an ID change in the .gnu_debuglink 
section of the main executable).


Regards,

--
Gioele Barabucci

Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates

2023-08-19 Thread Daniel Gröber

Hi,

On Sat, Aug 19, 2023 at 04:53:09PM +0200, Raphael Hertzog wrote:
> > The problem is that regex is NOT supported at the moment.
> 
> Urgh, and you did not complain that the release notes actually encourage
> users to do that?

Yeah, that seems less than ideal. Brings me back to thinking we should
change the security codename to something that's not going to need these
hacky regexes then.

Since $release/security is not well liked for unclear ("dak") reasons
(please someone elaborate if possible), perhaps an approach based on
Ubuntu's is less controvertial.

In debian-security/bookworm-security we have this right now

Origin: Debian
Label: Debian-Security
Suite: stable-security
Version: 12
Codename: bookworm-security

and we need the regex becuase $codename/$suite doesn't match "bookworm",
"bookworm/*" or stable, stable/* resp. Compare this to what Ubuntu uses:

Origin: Ubuntu
Label: Ubuntu
Suite: kinetic-security
Version: 22.10
Codename: kinetic

Here APT::Default-Release "kinetic" would match just fine. Just seems they
don't support the "stable" alias like we do. Could we use this to cover
both use-cases:

Origin: Debian
Label: Debian-Security
Suite: stable
Codename: bookworm

Now no weird hacks are neceessary APT::DefaultRelease "bookworm" or
"stable" will match the security repos just fine.

Users that _really_ want to do weird things to the security repo can still
use a "label" match in apt/preferences like `Pin: release
l=Debian-Security`. I think you'd be able to combine this with a codename
match to be specific about which release too: `Pin: release
l=Debian-Security n=bookworm` but don't quote me on that until someone
tests it.

I don't see any real downsides to this approach other than "ugh more
change".

--Daniel

Bug#1049304: maildir-utils: Fails to build source after successful build

2023-08-19 Thread Jeremy Sowden

On 2023-08-13, at 21:20:57 +0200, Lucas Nussbaum wrote:
> Source: maildir-utils
> Version: 1.8.14-3
> Severity: minor
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-sab-20230813 ftbfs-source-after-build
> User: debian...@lists.debian.org
> Usertags: qa-doublebuild
> 
> Hi,
> 
> This package fails to build a source package after a successful build
> (dpkg-buildpackage ; dpkg-buildpackage -S).
> 
> This is probably a clear violation of Debian Policy section 4.9 (clean 
> target),
> but this is filed as severity:minor for now, because a discussion on
> debian-devel showed that we might want to revisit the requirement of a working
> 'clean' target.
> 
> More information about this class of issues, included common problems and
> solutions, is available at
> https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild
> 
> [...]
> 
> The full build log is available from:
> http://qa-logs.debian.net/2023/08/13/maildir-utils_1.8.14-3_unstable.log

There are some Texinfo output files left over.  I've pushed a fix to Salsa.

J.


signature.asc
Description: PGP signature

Bug#1050092: RFS: ffcall/2.4-2.1 [NMU] -- foreign function call libraries - closures in C (non-reentrant variant)

2023-08-19 Thread Bo YU

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : ffcall
   Version  : 2.4-2.1
   Upstream contact : libffc...@gnu.org
 * URL  : https://www.gnu.org/software/libffcall/
 * License  : GPL-2+, LGPL-2+, GPL-3+ with Autoconf exception, GPL-3+, 
LGPL-2.1+, GFDL-NIV-1.2+ or GPL-2+, FSFULLR
 * Vcs  : https://salsa.debian.org/common-lisp-team/ffcall
   Section  : libs

The source builds the following binary packages:

  libffcall-dev - foreign function call libraries - development files
  libffcall1b - foreign function call libraries - main shared library
  libavcall1 - foreign function call libraries - calling C functions with 
variable arguments
  libcallback1 - foreign function call libraries - closures with variable 
arguments in C
  libtrampoline1 - foreign function call libraries - closures in C 
(non-reentrant variant)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/ffcall/ffcall_2.4-2.1.dsc

Changes since the last upload:

 ffcall (2.4-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * fix ftbfs on riscv64 and this is rdep of clisp which to bootstrap sbcl on
 riscv64. (Closes: #1038803)

->--
BTW: I can confirm that clisp can be built with the package[0]. And the sbcl
can be built with clisp but unfortunately sbcl was failed to bootstrap 
itself[1].
I am looking at this issue.

[0]: https://buildd.debian.org/status/package.php?p=clisp
[1]: 
https://salsa.debian.org/common-lisp-team/sbcl/-/blob/master/debian/rules#L51
-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1050091: hostname: VCS repository with all past releases


Package: hostname
Severity: wishlist
Tags: patch

Dear hostname maintainer,

you can find a DEP-14-compliant git repository with the history of the 
hostname package at


https://salsa.debian.org/gioele/hostname

My plan is to move this repo into the debian/ namespace in a few weeks, 
unless you are against it.


If you prefer to create the repo on salsa.d.o yourself, you can fork it 
and then use "Settings" → "General" →  "Remove fork relationship".


Regards,

--
Gioele Barabucci

Bug#1041166: Source debdiff

2023-08-19 Thread Jonathan Wiltshire

Control: tag -1 confirmed

On Tue, Jul 18, 2023 at 05:39:51AM +0100, RW Penney wrote:
> Apologies - original submission did not include a debdiff on the *source*
> packages.
> 
> Hopefully this attachment will remedy that.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1040475: Broken symlinks cause Apache Directory Server to not work at all out-of-the-box

2023-08-19 Thread Markus Koschany

I believe the symlink problem is fixed in version 2.0.0~M26-2 but I'd like to
test the apacheds server component more before I'm going to close this bug
report.

Markus


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

Bug#1049988: bookworm-pu: package riemann-c-client/1.10.4-2

2023-08-19 Thread Jonathan Wiltshire

Control: tag -1 moreinfo

On Thu, Aug 17, 2023 at 01:01:01PM -1000, Romain Tartière wrote:
> diff -Nru riemann-c-client-1.10.4/debian/changelog 
> riemann-c-client-1.10.4/debian/changelog
> --- riemann-c-client-1.10.4/debian/changelog  2019-01-03 07:09:25.0 
> -1000
> +++ riemann-c-client-1.10.4/debian/changelog  2023-08-13 12:08:48.0 
> -1000
> @@ -1,3 +1,13 @@
> +riemann-c-client (1.10.4-3) unstable; urgency=medium
> +
> +  * QA upload.
> +  * Drop Vcs-* fields and gbp.conf.
> +
> +  [ Romain Tartière ]
> +  * Fix GnuTLS send/recv.
> +
> + -- Bastian Germann   Mon, 14 Aug 2023 00:08:48 +0200
> +
>  riemann-c-client (1.10.4-2) unstable; urgency=medium
>  
>* Orphaning the package.

This seems to be a copy of the most recent upload to unstable; please
consult the developers' reference and prepare an appropriate diff for a
stable update.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1050090: bookworm-pu: package ltsp/23.02-1+deb12u1

2023-08-19 Thread Mike Gabriel

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: l...@packages.debian.org, alk...@gmail.com, vagr...@debian.org
Control: affects -1 + src:ltsp

While prepare the initial Debian Edu 12 release, we came across a problem in
LTSP. Thin client machines and diskless workstations started failing to boot
from NFS-located chroot environments.

[ Reason ]
The underlying cause is a regression in the linux kernel since version 5.15
(see #1049885 [1]) for details.

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

A workaround could be found for LTSP in Debian 12 (it is not just a
Debian Edu problem). This upload provides this workaround and brings
back above named functionality (PXE-booting Debian systems via LTSP
when the system is a chroot tree on NFS).

[ Impact ]
LTSP with rootfs on NFS stays broken.

[ Tests ]
Manual tests on a Debian Edu 12 network.

[ Risks ]
Another regression might have been introduced into LTSP with that workaround.

[ 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

[ Changes ]

+  * debian/patches:
++ Add 0001_Avoid-mv-on-init-symlink-in-order-to-work-around-ove.patch
+  (cherry-picked from upstream). Avoid mv on init symlink in order to
+  work around overlayfs issue. (Closes: #1049397).


[ Other info ]
This issue has been discussed with and approved by LTSP upstream.

See: https://github.com/ltsp/ltsp/issues/860#issuecomment-1682047744
diff -Nru ltsp-23.02/debian/changelog ltsp-23.02/debian/changelog
--- ltsp-23.02/debian/changelog 2023-02-28 04:27:32.0 +0100
+++ ltsp-23.02/debian/changelog 2023-08-19 17:33:29.0 +0200
@@ -1,3 +1,12 @@
+ltsp (23.02-1+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
++ Add 0001_Avoid-mv-on-init-symlink-in-order-to-work-around-ove.patch
+  (cherry-picked from upstream). Avoid mv on init symlink in order to
+  work around overlayfs issue. (Closes: #1049397).
+
+ -- Mike Gabriel   Sat, 19 Aug 2023 17:33:29 +0200
+
 ltsp (23.02-1) unstable; urgency=medium
 
   * Match both memtest86+x32.bin and memtest86+ia32.bin (#801)
diff -Nru 
ltsp-23.02/debian/patches/0001_Avoid-mv-on-init-symlink-in-order-to-work-around-ove.patch
 
ltsp-23.02/debian/patches/0001_Avoid-mv-on-init-symlink-in-order-to-work-around-ove.patch
--- 
ltsp-23.02/debian/patches/0001_Avoid-mv-on-init-symlink-in-order-to-work-around-ove.patch
   1970-01-01 01:00:00.0 +0100
+++ 
ltsp-23.02/debian/patches/0001_Avoid-mv-on-init-symlink-in-order-to-work-around-ove.patch
   2023-08-19 17:33:29.0 +0200
@@ -0,0 +1,31 @@
+From 19ccbb7c4a5daeebacb4157bea772e26c3fb0f44 Mon Sep 17 00:00:00 2001
+From: gber 
+Date: Thu, 17 Aug 2023 09:45:49 +0200
+Subject: [PATCH] Avoid mv on init symlink in order to work around overlayfs
+ issue (#860)
+
+Signed-off-by: Mike Gabriel 
+---
+ ltsp/client/initrd-bottom/55-initrd-bottom.sh | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/ltsp/client/initrd-bottom/55-initrd-bottom.sh 
b/ltsp/client/initrd-bottom/55-initrd-bottom.sh
+index 633ef47..bf68ae0 100644
+--- a/ltsp/client/initrd-bottom/55-initrd-bottom.sh
 b/ltsp/client/initrd-bottom/55-initrd-bottom.sh
+@@ -73,8 +73,10 @@ install_ltsp() {
+ fi
+ # To avoid specifying an init=, we override the real init.
+ # We can't mount --bind as it's in use by libraries and can't be 
unmounted.
+-re mv "$rootmnt/sbin/init" "$rootmnt/sbin/init.ltsp"
+-re ln -s ../../usr/share/ltsp/client/init/init "$rootmnt/sbin/init"
++# With Linux 6.1 rename(2) on the symlink fails with ENXIO, so do not use
++# mv for now (see #860).
++re cp -a "$rootmnt/sbin/init" "$rootmnt/sbin/init.ltsp"
++re ln -sf ../../usr/share/ltsp/client/init/init "$rootmnt/sbin/init"
+ # Jessie needs a 3.18+ kernel and this initramfs-tools hack:
+ if grep -qs jessie /etc/os-release; then
+ echo "init=${init:-/sbin/init}" >> /scripts/init-bottom/ORDER
+-- 
+2.39.2
+
diff -Nru ltsp-23.02/debian/patches/README ltsp-23.02/debian/patches/README
--- ltsp-23.02/debian/patches/README1970-01-01 01:00:00.0 +0100
+++ ltsp-23.02/debian/patches/README2023-08-19 17:33:29.0 +0200
@@ -0,0 +1,3 @@
+0xxx: Grabbed from upstream development.
+1xxx: Possibly relevant for upstream adoption.
+2xxx: Only relevant for official Debian release.
diff -Nru ltsp-23.02/debian/patches/series ltsp-23.02/debian/patches/series
--- ltsp-23.02/debian/patches/series2023-02-28 04:27:32.0 +0100
+++ ltsp-23.02/debian/patches/series2023-08-19 17:33:29.0 +0200
@@ -0,0 +1 @@
+0001_Avoid-mv-on-init-symlink-in-order-to-work-around-ove.patch

Bug#1050089: bootstrap tries to search for gnulib PO files in spite of '--skip-po'

2023-08-19 Thread Bjarni Ingi Gislason

Package: man-db
Version: 2.11.2-3
Severity: normal

N.B.
I find the user interface for "gitlab.com" to be bad.

Dear Maintainer,

bootstrapping with --no-git --gnulib-srcdir=/home/bg/git/gnulib --skip-po 
--bootstrap-sync
[...]
  m4/zzgnulib.m4
Creating directory ./gl/ref-po
Updating file build-aux/config.rpath (backup in build-aux/config.rpath~)
Updating file gl/lib/argp-help.c (backup in gl/lib/argp-help.c~)
Updating file gl/lib/argp-parse.c (backup in gl/lib/argp-parse.c~)
Updating file gl/m4/extern-inline.m4 (backup in gl/m4/extern-inline.m4~)
Creating gl/ref-po/Makefile.in.in
Creating gl/ref-po/remove-potcdate.sin
Creating gl/ref-po/Makevars
Creating gl/ref-po/POTFILES.in
Fetching gnulib PO files from https://translationproject.org/latest/
failed: Connection refused.
failed: Network is unreachable.
ls: cannot access '*.po': No such file or directory
Creating gl/ref-po/LINGUAS
Finished.
[...]



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

Kernel: Linux 6.4.4-2 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages man-db depends on:
ii  bsdextrautils  2.39.1-4
ii  bsdmainutils   12.1.8
ii  debconf [debconf-2.0]  1.5.82
ii  groff-base 1.23.0-2
ii  libc6  2.37-7
ii  libgdbm6   1.23-3
ii  libpipeline1   1.5.7-1
ii  libseccomp22.5.4-1+b3
ii  zlib1g 1:1.2.13.dfsg-1

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor   
ii  elinks [www-browser]   0.16.1.1-4
ii  firefox-esr [www-browser]  115.1.0esr-1
ii  groff  1.23.0-2
ii  less   590-2
ii  lynx [www-browser] 2.9.0dev.12-1
ii  w3m [www-browser]  0.5.3+git20230121-2

-- Configuration Files:
/etc/manpath.config changed [not included]

-- debconf information:
  man-db/install-setuid: false
  man-db/auto-update: true

Bug#1049977: rust-hyper-rustls - please update to match new rust-tokio-rustls

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

I am bumping the severity since rust-hyper-rustls fails to build from
source in Unstable. This is true regardless of whether this situation
should have been coordinated better.

Thank you,
Jeremy Bícha

Bug#1050088: rust-cargo-mutants: Unknown section 'FIXME-IN-THE-SOURCE-SECTION'

Source: rust-cargo-mutants
Version: 23.6.0-1
Severity: serious

rust-cargo-mutants ended up with an invalid Section field in its
debian/control . Perhaps this is a debcargo bug? This can be handled
in the package debian/debcargo.toml

This error is basically an autoreject in Ubuntu:
https://launchpad.net/ubuntu/+source/rust-cargo-mutants/23.6.0-1/+latestbuild/amd64

Thank you,
Jeremy Bícha

Bug#1050087: rust-microformats: Fails to build

Source: rust-microformats
Version: 0.4.2-1
Severity: serious
Tags: ftbfs

rust-microformats fails to build from source with several test failures.

https://buildd.debian.org/status/package.php?p=rust-microformats

Thank you,
Jeremy Bícha

Bug#1050086: rust-ahash: Fails to build

Source: rust-ahash
Version: 0.8.3-7
Severity: serious
Tags: ftbfs

rust-ahash fails to build. Here's a build log excerpt:

error[E0432]: unresolved import `criterion`
 --> tests/map_tests.rs:6:5
  |
6 | use criterion::*;
  | ^ use of undeclared crate or module `criterion`

error[E0432]: unresolved import `fxhash`
 --> tests/map_tests.rs:7:5
  |
7 | use fxhash::FxHasher;
  | ^^ use of undeclared crate or module `fxhash`
  |
help: there is a crate or module with a similar name
  |
7 | use ahash::FxHasher;
  | ~

error: cannot find macro `criterion_main` in this scope
   --> tests/map_tests.rs:233:1
|
233 | criterion_main!(benches);
| ^^

error: cannot find macro `criterion_group` in this scope
   --> tests/map_tests.rs:234:1
|
234 | criterion_group!(benches, bench_ahash_words, bench_fx_words,);
| ^^^

error[E0412]: cannot find type `Criterion` in this scope
   --> tests/map_tests.rs:223:30
|
223 | fn bench_ahash_words(c:  Criterion) {
|  ^ not found in this scope

error[E0425]: cannot find function `black_box` in this scope


Full build log
==
https://buildd.debian.org/status/package.php?p=rust-ahash

Thank you,
Jeremy Bícha

Bug#1028897: fontconfig: wrong name for the Noto monospace font

2023-08-19 Thread Raphaël Halimi

Le 19/08/2023 à 16:04, Gunnar Hjalmarsson a écrit :
As you may have seen, I submitted and
fixed it. Thanks for mentioning it!

Yes I saw that, you CC'd me ; and thank you for acting on this problem.
Seeing that the time I spend on writing detailed e-mails to the BTS is
not in vain, is very much appreciated :)

On 2023-08-17 15:34, Raphaël Halimi wrote:

IMHO, if Debian wants to follow the upstream fontconfig default to
use the Noto fonts, the system should work without the DejaVu
packages installed, so it would make more sense to patch fontconfig
to use Noto Mono as a default and keep the "Noto look" across the
whole system, than to go back to DejaVu Sans Mono.

As regards "Noto look", and despite of the name "Noto Mono", personally
I think that DejaVu Sans Mono aligns better with Noto Sans/Serif than
Noto Mono does. Look at the letter 'g', for instance.

Also:

* If Debian would change the default monospace font, we would not follow
upstream. That's true whether we would pick Noto Mono or DejaVu Sans Mono.

As I said, having a "pure" Noto set or a mix of Noto and DejaVu set by
default is a personal opinion (I did state "IMHO") and I admit I didn't
compare those fonts thoroughly to see which one of Noto (Sans) Mono or
DejaVu Sans Mono goes better with Noto Sans/Serif. I took a guess purely
based on the fact that fonts distributed as parts of the same set are
supposed to go along.

Since you're part of the team who maintains the package, I won't discuss
your decision on that point (but I'd still prefer full-Noto or
full-DejaVu over a mix of both, although I agree this may be a purely
psychological bias).

* There were reasons why I broke out DejaVu Sans Mono to its own
package. :) Given that change, it's possible to install
fonts-dejavu-mono without installing fonts-dejavu-core.

This remark made me read the Debian changelog and query #1043271. Thanks
for clarifying that.

For those reasons I disagree with the quoted statement.

As I said, we have a divergence of opinion, but as the maintainer of
this package, you have the final word.

Another question is if the Noto Sans Mono deficiency is important enough
to motivate a Debian level change in this respect. I don't know.
@Fabian, I sent this reply to you as well in the hope to broaden the
discussion a bit.

Here, I don't agree ; not on bringing more people in the discussion (the
more thinking minds, the wiser the final decision will be), but on the
very problem itself: did you see the screenshots I provided ? Won't you
agree that the current default configuration is ugly, whether with Gnome
Terminal or XTerm ?

(I know that for XTerm it's not really the "default configuration" since
it uses bitmap fonts by default, but still, I consider the font resolved
by the "Monospace" alias for TrueType fonts to be some kind of default).

It's worth mentioning that the fonts-noto packages in Debian ship almost
3 years old fonts. An update to latest upstream would be highly
desirable. Possibly Noto Sans Mono has improved.

I didn't know that. Thanks for mentioning it.

So, I just downloaded NotoSansMono-Regular.ttf from its new home [1]
(the old repository in the Debian copyright file has been archived),
opened it in font-viewer and... Sadly, the spacing is still
"Proportional" and not "Monospace" :(

[1]
https://github.com/notofonts/notofonts.github.io/blob/main/fonts/NotoSansMono/hinted/ttf/NotoSansMono-Regular.ttf

After all this time, I seriously doubt that that Google intends to fix
that. Maybe we could open an issue in the new Github repository ? My
hopes are not high, though. I'm afraid it will be ignored like the ones
before.

Regards,

--
Raphaël Halimi

Bug#1050085: RFS: vnstat/2.11-1 -- console-based network traffic monitor

2023-08-19 Thread Christian Göttsche

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : vnstat
   Version  : 2.11-1
   Upstream contact : Teemu Toivola 
 * URL  : https://humdi.net/vnstat/
 * License  : GPL-any, GPL-2
 * Vcs  : https://salsa.debian.org/debian/vnstat
   Section  : net

The source builds the following binary packages:

  vnstat - console-based network traffic monitor
  vnstati - image output support for vnStat

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.11-1.dsc

Changes since the last upload:

 vnstat (2.11-1) unstable; urgency=medium
 .
   * New upstream version 2.11
   * d/patches: rebase

Regards,
-- 
  Christian Göttsche

Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates

2023-08-19 Thread Raphael Hertzog

Hi,

Le samedi 19 août 2023, David Kalnischkies a écrit :
> > Agreed. It would be nice to document that we can use regex here and
> > that it actually makes sense to do so as most Debian release are actually
> > composed of multiple repositories.
> 
> The problem is that regex is NOT supported at the moment.

Urgh, and you did not complain that the release notes actually encourage
users to do that?

> It happens to work in most commands, but it e.g. doesn't in 'source'.
> 
> Before we could (leaving alone the question if we should) document it
> as supported, we would need to check all commands and fix those which do
> not work with it. Nobody did in the last couple of years.
> 
> So the only reasonable solution for this request so far is to document
> it explicitly as not supported… which helps exactly nobody.

Well, it's always nice to document the known limitations and thus invite
users to prefer explicit pinning over usage of APT::Default-Release which
is commonly used in a configuration file.

> Step back and question why you want to use the option. There are
> probably easier and simpler ways. Adding backports e.g. doesn't need
> pinning at all (it comes by default with 100). Adding unstable to stable
> might be a bad idea to begin with, but is certainly better dealt with
> a pin against unstable rather than trying to catch all your "good"
> "stable" repos in a regex to filter out the one bad "unstable" apple.

I understand that but in my mental model, it was more like "as soon as
you add other suites, make sure to document the preferred release with
APT::Default-Release" instead of the opposite (i.e. make sure to pin down the
repositories that you don't want to use by default).

Clearly I have often used that when I added a newer release in
sources.list (be it unstable/testing or just stable on an oldstable server
or similar).

Is there any difference of behaviour between reducing pin of alternate
releases to a value < 500 vs increasing the priority of the desired
release to 990?

> In preferences the regex actually works and is documented, which is the
> deeper reason behind APT::Default-Release working with regex or not as
> certain commands can rely on the preferences infrastructure while
> a command like 'source' can currently not and hence implements it
> differently without support for a lot of things possible elsewhere.

Maybe it can be documented as a limitation of the source command instead
of refusing to acknowledging what works and what's used?

> If you can come up with a list of use cases for that option (personally,
> I don't see a good one) without too much by-catch we might be able to
> implement a transition notice like I did for non-free-firmware.
> Too late, too little, but at least it would prevent future misuse.

Maybe you should deprecate the option in the configuration file and
invite users to switch to preferences?

I don't know what's best. It would still be nice to have a simple syntax
that would match the -security repo, the -updates repo and the main repo
for a given release... but maybe it should rely on a new "PartOfRelease"
field in the various "Release" files or something like that.

Cheers,
-- 
Raphaël Hertzog


signature.asc
Description: PGP signature

Bug#1050084: RFS: oxygencursors/0.0.2012-06-kde4.8-5 [QA] -- Oxygen mouse cursor theme

2023-08-19 Thread Christian Göttsche

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : oxygencursors
   Version  : 0.0.2012-06-kde4.8-5
   Upstream contact : plasma-de...@kde.org
 * URL  : https://techbase.kde.org/Projects/Oxygen
 * License  : GPL-3+
 * Vcs  : [fill in URL of packaging vcs]
   Section  : x11

The source builds the following binary packages:

  oxygencursors - Oxygen mouse cursor theme

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/oxygencursors/oxygencursors_0.0.2012-06-kde4.8-5.dsc

Changes since the last upload:

 oxygencursors (0.0.2012-06-kde4.8-5) unstable; urgency=medium
 .
   * QA upload.
   * d/changelog: fix typo
   * d/control: bump to std version 4.6.2 (no further changes)
   * d/copyright: update year
   * d/patches: fix typo
   * d/lintian-overrides: update format
   * d/rules: remove created symlinks on dh_clean (Closes: #1046465, 1049654)

Regards,
-- 
  Christian Göttsche

Bug#1042429: libvirt-daemon-system: VM running but virt-manager not connecting

2023-08-19 Thread Andrea Bolognani

On Fri, Jul 28, 2023 at 09:21:42AM +0200, Andreas Guenther wrote:
> After starting, the Virt-manager window remains empty and
> instead shows the message "QEMU/KVM - Not Connected".
> 
> * What led up to the situation?
> 
>   System upgrade from Debian 11 to Debian 12
> 
> * What exactly did you do (or not do) that was effective (or
>   ineffective)?
> 
>   Copy the file
>   /var/lib/polkit-1/localauthority/10-vendor.d/60-libvirt.pkla
>   from the package of the same name in Buster to the same place
>   on the Bookworm installation. Restart libvirtd.
> 
> * What was the outcome of this action?
> 
>   The virt-manager works as usual again

This is surprising, as the version of polkit that comes with Debian
12 is capable of using JavaScript rules.

For libvirt that's /usr/share/polkit-1/rules.d/60-libvirt.rules,
which implements the same logic as the pkla rules did in previous
releases, namely that members of the "libvirt" group should be
allowed to manage the system instance of libvirtd.

I have tried just now with a fresh installation of Debian 12 and
everything seems to work as intended.

> -- System Information:
> Debian Release: 12.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)

This doesn't look right for Debian 12, you should be running 6.1.0.

Is it possible that you haven't rebooted the machine after performing
the upgrade? The new version of polkit, which can read the JavaScript
rules, will only take over at that point, so if you haven't rebooted
yet it would make sense that the pkla rules disappearing would cause
the currently running version of polkit to no longer grant you access
to libvirt.

> Versions of packages libvirt-daemon-system depends on:
> ii  polkitd 122-3

This version of polkit should be perfectly able to process the
JavaScript version of the rules.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.

signature.asc
Description: PGP signature

Bug#1028897: fontconfig: wrong name for the Noto monospace font

2023-08-19 Thread Gunnar Hjalmarsson


Hi again,

As you may have seen, I submitted  and 
fixed it. Thanks for mentioning it!


On 2023-08-17 15:34, Raphaël Halimi wrote:

IMHO, if Debian wants to follow the upstream fontconfig default to
use the Noto fonts, the system should work without the DejaVu
packages installed, so it would make more sense to patch fontconfig
to use Noto Mono as a default and keep the "Noto look" across the
whole system, than to go back to DejaVu Sans Mono.


As regards "Noto look", and despite of the name "Noto Mono", personally 
I think that DejaVu Sans Mono aligns better with Noto Sans/Serif than 
Noto Mono does. Look at the letter 'g', for instance.


Also:

* If Debian would change the default monospace font, we would not follow 
upstream. That's true whether we would pick Noto Mono or DejaVu Sans Mono.


* There were reasons why I broke out DejaVu Sans Mono to its own 
package. :) Given that change, it's possible to install 
fonts-dejavu-mono without installing fonts-dejavu-core.


For those reasons I disagree with the quoted statement.

Another question is if the Noto Sans Mono deficiency is important enough 
to motivate a Debian level change in this respect. I don't know. 
@Fabian, I sent this reply to you as well in the hope to broaden the 
discussion a bit.


It's worth mentioning that the fonts-noto packages in Debian ship almost 
3 years old fonts. An update to latest upstream would be highly 
desirable. Possibly Noto Sans Mono has improved.


--
Cheers,
Gunnar

Bug#1040925: bookworm-pu: package ca-certificates-java/20230103+x

2023-08-19 Thread Jonathan Wiltshire

On Fri, Aug 18, 2023 at 09:52:36PM +0200, Andreas Beckmann wrote:
> The actual regression is in openjdk-XX which removed some undocumented
> undefined behavior. This was not neccessarily on purpose.
> ca-certificates-java relied on the fact that an unconfigured
> openjdk-jre-XX-headless could be used for its configuration, which is no
> longer the case. ca-certificates-java now has to pre-configure java to a
> usable state if ca-certificates-java gets configured before
> openjdk-XX-jre-headless was ever configured. That may happen due to the
> circular dependency.
> 
> The current fix may actually cause dpkg trigger cycles (due to the circular
> dependency), but that's a rare event. IIRC in my piuparts tests of this fix
> I encountered one new trigger cycle, while fixing about 50-250 installation
> failures due to the ca-certificates-java failure.
> (exact numbers are hard to estimate since that failure may not propagate
> transitively: if installing foo which depends on ca-certifictes-java fails,
> installing bar which depends on foo (and therefore ca-certificates-java,
> too) may succeed if apt swaps the configuration order of
> ca-certificates-java and openjdk-XX-jre-headless.

This still seems better for now than the current situation, so even if we
do something else later I'd like to get the wheels turning on this. I
sent a revised text, as it will have you name on it are you happy with it?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1050083: shotwell: crash in folders_sidebar_entry_construct

2023-08-19 Thread Patrice Duroux

Package: shotwell
Version: 0.32.2-1
Severity: normal

Dear Maintainer,

My system is a Debian Sid (+ some experimental GNOME 45 packages).
Here is what I got using a terminal:

#shotwell
** Message: 15:36:49.447: main.vala:445: Starting session with system profile
fish: Job 1, 'shotwell' terminated by signal SIGSEGV (Erreur de frontière
d'adresse)

#coredumpctl dump /usr/bin/shotwell

   Message: Process 13905 (shotwell) of user 1001 dumped core.

Module libsystemd.so.0 from deb systemd-254.1-2.amd64
Module libudev.so.1 from deb systemd-254.1-2.amd64
Stack trace of thread 13905:
#0  0x7fd6a07b3e7b __GI___wcsxfrm_l (libc.so.6 + 0xbae7b)
#1  0x7fd6a1b7eeda g_utf8_collate_key (libglib-2.0.so.0 +
0x91eda)
#2  0x7fd6a1b7f386 g_utf8_collate_key_for_filename
(libglib-2.0.so.0 + 0x92386)
#3  0x564de9758570 folders_sidebar_entry_construct
(shotwell + 0x19d570)
#4  0x564de9758d78 folders_sidebar_entry_new (shotwell +
0x19dd78)
#5  0x564de97590f6 folders_branch_on_media_contents_altered
(shotwell + 0x19e0f6)
#6  0x564de97592d3 folders_branch_construct (shotwell +
0x19e2d3)
#7  0x564de96c5624 library_window_instance_init (shotwell +
0x10a624)
#8  0x7fd6a1c6857b g_type_create_instance
(libgobject-2.0.so.0 + 0x3857b)
#9  0x7fd6a1c4be80 g_object_new_internal
(libgobject-2.0.so.0 + 0x1be80)
#10 0x7fd6a1c4dfb3 g_object_new_internal
(libgobject-2.0.so.0 + 0x1dfb3)
#11 0x7fd6a1c4e309 g_object_new (libgobject-2.0.so.0 +
0x1e309)
#12 0x564de975c6e0 page_window_construct (shotwell +
0x1a16e0)
#13 0x564de975f21b app_window_construct (shotwell +
0x1a421b)
#14 0x564de96c91e3 library_window_construct (shotwell +
0x10e1e3)
#15 0x564de975ad0a library_exec (shotwell + 0x19fd0a)
#16 0x564de964fe32 _vala_main (shotwell + 0x94e32)
#17 0x7fd6a07206ca __libc_start_call_main (libc.so.6 +
0x276ca)
#18 0x7fd6a0720785 __libc_start_main_impl (libc.so.6 +
0x27785)
#19 0x564de9650311 _start (shotwell + 0x95311)

Stack trace of thread 13912:
#0  0x7fd6a07f9eb9 syscall (libc.so.6 + 0x100eb9)
#1  0x7fd6a1ba0770 g_cond_wait (libglib-2.0.so.0 + 0xb3770)
#2  0x7fd6a1b10f2b g_async_queue_pop_intern_unlocked
(libglib-2.0.so.0 + 0x23f2b)
#3  0x7fd6a1b73931 g_thread_pool_wait_for_new_task
(libglib-2.0.so.0 + 0x86931)
#4  0x7fd6a1b730cd g_thread_proxy (libglib-2.0.so.0 +
0x860cd)
#5  0x7fd6a07813ec start_thread (libc.so.6 + 0x883ec)
#6  0x7fd6a0801a1c __clone3 (libc.so.6 + 0x108a1c)

Stack trace of thread 13914:
#0  0x7fd6a07f9eb9 syscall (libc.so.6 + 0x100eb9)
#1  0x7fd6a1ba0770 g_cond_wait (libglib-2.0.so.0 + 0xb3770)
#2  0x7fd6a1b10f2b g_async_queue_pop_intern_unlocked
(libglib-2.0.so.0 + 0x23f2b)
#3  0x7fd6a1b73931 g_thread_pool_wait_for_new_task
(libglib-2.0.so.0 + 0x86931)
#4  0x7fd6a1b730cd g_thread_proxy (libglib-2.0.so.0 +
0x860cd)
#5  0x7fd6a07813ec start_thread (libc.so.6 + 0x883ec)
#6  0x7fd6a0801a1c __clone3 (libc.so.6 + 0x108a1c)

Stack trace of thread 13906:
#0  0x7fd6a07f9eb9 syscall (libc.so.6 + 0x100eb9)
#1  0x7fd6a1ba0770 g_cond_wait (libglib-2.0.so.0 + 0xb3770)
#2  0x7fd6a1b10f2b g_async_queue_pop_intern_unlocked
(libglib-2.0.so.0 + 0x23f2b)
#3  0x7fd6a1b73712 g_thread_pool_spawn_thread
(libglib-2.0.so.0 + 0x86712)
#4  0x7fd6a1b730cd g_thread_proxy (libglib-2.0.so.0 +
0x860cd)
#5  0x7fd6a07813ec start_thread (libc.so.6 + 0x883ec)
#6  0x7fd6a0801a1c __clone3 (libc.so.6 + 0x108a1c)

Stack trace of thread 13922:
#0  0x7fd6a07f9eb9 syscall (libc.so.6 + 0x100eb9)
#1  0x7fd6a1ba0770 g_cond_wait (libglib-2.0.so.0 + 0xb3770)
#2  0x7fd6a1b10f2b g_async_queue_pop_intern_unlocked
(libglib-2.0.so.0 + 0x23f2b)
#3  0x7fd6a1b73931 g_thread_pool_wait_for_new_task
(libglib-2.0.so.0 + 0x86931)
#4  0x7fd6a1b730cd g_thread_proxy (libglib-2.0.so.0 +
0x860cd)
#5  0x7fd6a07813ec start_thread (libc.so.6 + 0x883ec)
#6  0x7fd6a0801a1c __clone3 (libc.so.6 + 0x108a1c)

Stack trace of thread 13918:
#0  0x7fd6a07f9eb9 syscall (libc.so.6 + 0x100eb9)
#1

Bug#1050080: unrar: Fix CVE-2022-48579 for Debian 11

2023-08-19 Thread Markus Koschany

Hello,

I wanted to prepare a fix for CVE-2022-48579 in Bullseye and release it via a
bullsye point update. Do you want to take care of the upload instead?

Regards,

Markus


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

Bug#1050082: octave-image: could FTBFS due to missing .oct files

2023-08-19 Thread Graham Inggs

Source: octave-image
Version: 2.14.0-4
Tags: ftbfs patch

Hi Maintainer

While rebuilding octave-* packages for the octave-abi-58 transition in
Ubuntu 23.10, octave-image FTBFS due to missing .oct files.  I've
copied some of the output below.

Upon investigation, I found the following files were not built:
bwconncomp.oct
bwlabeln.oct
conndef.oct
imerode.oct
imreconstruct.oct
watershed.oct

Instead, the following were:
connectivity.oct
strel.oct

I was able to solve it with a simple patch:

--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -24,10 +24,10 @@
 $(FLAGGED_MKOCTFILE) -c $<

 $(conn_dependent): %.oct: %.cc connectivity.o
-$(FLAGGED_MKOCTFILE) $^
+$(FLAGGED_MKOCTFILE) $^ -o $@

 $(strel_dependent): %.oct: %.cc strel.o
-$(FLAGGED_MKOCTFILE) $^
+$(FLAGGED_MKOCTFILE) $^ -o $@

 %.oct: %.cc
 $(FLAGGED_MKOCTFILE) $<

I'm not sure what changed, or when, but I was able to reproduce this
failure in the Ubuntu 23.04 release.

Regards
Graham


! test failed
'conndef' undefined near line 48, column 12

The ’conndef’ function belongs to the image package from Octave Forge
which seems to not be installed in your system.

Bug#1050080: unrar: Fix CVE-2022-48579 for Debian 11

2023-08-19 Thread yokota

Hello Salvatore,

> FWIW, does not warrant a DSA, but can be fixed via upcoming point
> release.

Thank you.
I will try to do that.

--
YOKOTA Hiroshi

Bug#1050080: unrar: Fix CVE-2022-48579 for Debian 11

Hi,

On Sat, Aug 19, 2023 at 10:04:40PM +0900, YOKOTA Hiroshi wrote:
> Package: unrar
> Version: 1:6.0.3-1+deb11u1
> Severity: normal
> X-Debbugs-Cc: yokota.h...@gmail.com, a...@debian.org, t...@security.debian.org
> 
> 
> CVE-2022-48579 was fixed at unrar-nonfree/1:5.6.6-1+deb10u2 in Debian 10
> by Debian LTS team ( DLA-3535-1 ).
> The fix patch for Debian 10 can be apply for Debian 11.
> 
> Fix patch for CVE-2022-48579
> Debian 10: https://github.com/debian-calibre/unrar-
> nonfree/commit/28eb57cb85aa656b7cda0e2f6a282c09f7351272
> Debian 11: https://github.com/debian-calibre/unrar-
> nonfree/commit/5daa9b93c099bd0219528d26778835ca1f6896da
> 
> 
> FYI: CVE-2022-48579 was already fixed in 1:6.2.3-1 in Debian sid.

FWIW, does not warrant a DSA, but can be fixed via upcoming point
release.

Regards,
Salvatore

Bug#1050081: ITP: python-parsl -- Parallel Scripting Library

2023-08-19 Thread Étienne Mollier

Package: wnpp
Severity: wishlist
Owner: Étienne Mollier 
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: python-parsl
  Version : 2023.08.14
  Upstream Contact: Yadu Nand Babuji , et al.
* URL : https://github.com/Parsl/parsl
* License : Apache 2.0
  Programming Lang: Python
  Description : Parallel Scripting Library

 Parsl extends parallelism in Python beyond a single computer.
 .
 One can use Parsl just like Python's parallel executors but across multiple
 cores and nodes. However, the real power of Parsl is in expressing multi-step
 workflows of functions. Parsl lets one chain functions together and will
 launch each function as inputs and computing resources are available.


This package is a new dependency for upgrading the qiime2
distribution on Debian Med radar.  Since the module parsl itself
is a bit more generic than medical field, I intend to put the
package under the Debian Python team umbrella.  A stub of
packaging is available on Salsa[1].

[1]: https://salsa.debian.org/python-team/packages/python-parsl/

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#1050080: unrar: Fix CVE-2022-48579 for Debian 11

2023-08-19 Thread YOKOTA Hiroshi

Package: unrar
Version: 1:6.0.3-1+deb11u1
Severity: normal
X-Debbugs-Cc: yokota.h...@gmail.com, a...@debian.org, t...@security.debian.org


CVE-2022-48579 was fixed at unrar-nonfree/1:5.6.6-1+deb10u2 in Debian 10
by Debian LTS team ( DLA-3535-1 ).
The fix patch for Debian 10 can be apply for Debian 11.

Fix patch for CVE-2022-48579
Debian 10: https://github.com/debian-calibre/unrar-
nonfree/commit/28eb57cb85aa656b7cda0e2f6a282c09f7351272
Debian 11: https://github.com/debian-calibre/unrar-
nonfree/commit/5daa9b93c099bd0219528d26778835ca1f6896da


FYI: CVE-2022-48579 was already fixed in 1:6.2.3-1 in Debian sid.

--
YOKOTA Hiroshi

Bug#1050079: puma: CVE-2023-40175: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')

Source: puma
Version: 5.6.5-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 6.0.2-1

Hi,

The following vulnerability was published for puma.

CVE-2023-40175[0]:
| Puma is a Ruby/Rack web server built for parallelism. Prior to
| versions 6.3.1 and 5.6.7, puma exhibited incorrect behavior when
| parsing chunked transfer encoding bodies and zero-length Content-
| Length headers in a way that allowed HTTP request smuggling.
| Severity of this issue is highly dependent on the nature of the web
| site using puma is. This could be caused by either incorrect parsing
| of trailing fields in chunked transfer encoding bodies or by parsing
| of blank/zero-length Content-Length headers. Both issues have been
| addressed and this vulnerability has been fixed in versions 6.3.1
| and 5.6.7. Users are advised to upgrade. There are no known
| workarounds for this vulnerability.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-40175
https://www.cve.org/CVERecord?id=CVE-2023-40175
[1] https://github.com/puma/puma/security/advisories/GHSA-68xg-gqqm-vgj8

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#892491: Related bug upstream

2023-08-19 Thread Joachim Zobel



This might be the bug mentioned here
https://github.com/eclipse/mosquitto/issues/2142

Bug#1050078: nano should provide "editor"

2023-08-19 Thread VA


Package: nano
Version: 7.2-1

nano package does not provide virtual package "editor", though it should.

Bug#1049366: indent: CVE-2023-40305

Hi Santiago,

On Sat, Aug 19, 2023 at 02:23:03PM +0200, Santiago Vila wrote:
> Thanks for the report.
> 
> I'm going to apply the two patches which Petr Písař
> has recently posted in Savannah.

Thanks!

> After that: Should I prepare packages for security
> (stable and oldstable) for you to review (I assume
> this helps a little bit), or should I just take the
> proposed-updates route?

We think those do not really warrant a DSA, no, but a point release
update should be sufficient. For that we have marked them already
earlier this week as no-dsa in
https://security-tracker.debian.org/tracker/CVE-2023-40305 .

Thanks for taking care as well of updating those in the stable and
oldstable suites!

Regards,
Salvatore

Bug#978595: #978595 is looking higher priority

2023-08-19 Thread Paul Leiber

On Thu, 17 Aug 2023 15:29:29 -0700 Elliott Mitchell 
 wrote:

On Tue, Jul 04, 2023 at 11:56:39PM +0300, Michael Tokarev wrote:
> Out of curiocity, what value is it to boot a xen domU (or qemu) guest in uefi 
mode?
> I mean, bios mode is still recommended for at least commercial virt solutions 
such
> as vmware, and it works significantly faster in qemu and xen too.  It is 
more, qemu
> ships minimal bios (qboot) to eliminate all boot-time cruft which is not 
needed in
> a vm most of the time.

First, the known high value portion of #978595 is getting
ArmVirtPkg/ArmVirtXen.dsc built and packaged.  This results in a
XEN_EFI.fd file.  As such the presently verified value only applies to
ARM.

What you do with XEN_EFI.fd is you configure an ARM domain with
'kernel = "${edk2_install_dir}/XEN_EFI.fd"'

The resultant domain has no extra daemons emulating hardware.  Inside the
domain, Tianocore/EDK2 will search via its normal means for a boot.efi
file and load that if it can.

This is similar to PyGRUB versus PvGRUB.  If the OS being loaded has
native Xen drivers, you've gotten rid of the Qemu process hanging around
in domain 0 providing security holes.

So far this is reliably booting the WIP FreeBSD/arm64.  I imagine this
could also load GRUB.

I believe OvmfPkg/OvmfXen.dsc aims to be something similar for x86, but
I've yet to achieve results from that.  My hope is this could load
FreeBSD/x86 in a PVH domain.

On Tue, Jul 04, 2023 at 10:30:34PM +0200, Paul Leiber wrote:
> As the Windows systems are not usable anymore, Xen is significantly
> reduced in functionality after the upgrade. Is this existing bug report
> the right place to file this, or should I open a new bug report? If this
> bug report is the right place, its priority should indeed be raised, at
> least to important (linux PVH DomUs are still working fine). If I should
> open a new bug report, for which package?

New report.  The topic for #978595 is I was hoping for some other build
types of EDK2/Tianocore to be built and packaged.  What you're describing
is a regression and certainly not merely a wishlist packaging request.

I'm unsure, but at first thought this would be src:xen.  On that note a
FreeBSD VM I've got has been having difficulty since the 4.14 -> 4.17
upgrade.  I'm still fighting other upgrade issues right now.

Some portions of the EDK2/Tianocore packaging look suspicious, so I
wouldn't be surprised if the failure was there.
As a test using a previous version of ovmf package (version 
2020.11-2+deb11u1, which the DomU booted normally with) pointed to the 
bug being in ovmf, I filed the bug there:

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

Thanks for the assistance!

Paul

Bug#1049977: rust-hyper-rustls - please update to match new rust-tokio-rustls

2023-08-19 Thread Peter Green


Since
rust-hyper-rustls has reverse dependencies as well, its move to to v0.24
will involve NEW queue and potentially take some time.


According to my searches the only direct reverse dependency of
rust-hyper-rustls is rust-reqwest. I have the new version of that
(which is not semver-breaking) ready to upload as soon as hyper-rustls
is uploaded to unstable.

I don't see any need for introducing NEW packages here.

Bug#1049366: indent: CVE-2023-40305

2023-08-19 Thread Santiago Vila


Thanks for the report.

I'm going to apply the two patches which Petr Písař
has recently posted in Savannah.

After that: Should I prepare packages for security
(stable and oldstable) for you to review (I assume
this helps a little bit), or should I just take the
proposed-updates route?

Thanks.

Bug#804722: git-buildpackage: import-dsc creates impractical merge commits after new upstream releases

On Sun, 10 Jul 2022 14:34:01 +0200 Gioele Barabucci  
wrote:

All that is needed to do two-step merge (first merge the upstream branch, then
apply the debian diff) is to do a merge at the right moment in `import_dsc.py`.

The following quick-and-dirty patch adds such a merge.

[...]

+tag = os.popen("git tag --list 'upstream/*' --sort=-v:refname | head 
-n1").read().rstrip()
+os.system(f'git merge {tag} --strategy-option theirs -m "Merge tag 
\'{tag}\'"')
+
  if dsc.diff or dsc.deb_tgz:


The attached new patch, although still "quick and dirty", improves the 
handing of possible modification+deletion conflicts that may arise while 
merging the the upstream branch into the Debian branch.


--
Gioele Barabucci--- /usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py.orig	2023-08-19 13:59:00.391232974 +0200
+++ /usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py	2023-08-19 14:02:05.330777453 +0200
@@ -524,12 +524,20 @@
 if options.create_missing_branches:
 repo.create_branch(options.debian_branch, commit)
 else:
 raise GbpError("Branch %s does not exist, use --create-missing-branches" %
options.debian_branch)
 
+tag = os.popen("git tag --list 'upstream/*' --sort=-v:refname | head -n1").read().rstrip()
+ver = tag.split("/")[1]
+msg = f"Merge upstream version {ver}"
+ret = os.system(f'git merge {tag} --strategy-option theirs -m "{msg}"' + " || { git diff --name-only --diff-filter=U | xargs git rm && git commit --no-edit ;}")
+if ret != 0:
+gbp.log.err(f"Failed to merge upstream version {ver}")
+return ret
+
 if dsc.diff or dsc.deb_tgz:
 apply_debian_patch(repo, sources[0], dsc, commit, options)
 else:
 gbp.log.warn("Didn't find a diff to apply.")
 
 if imported and options.pristine_tar:

Bug#1042005: Info received (Bug#1042005: transition: mumps hypre2.28.0 superlu combblas)

2023-08-19 Thread Drew Parsons


All direct uploads have been made and migrated to testing.

trilinos is not yet rebuilt against MUMPS 5.6. I gather trilinos has 
other issues not related to this transition (gcc-13 for instance).


Apart from that I think this transition is done.

Drew.

Bug#1050077: gtk4: 4.12 regression: FTBFS on mips(64)el: multiple test failures

Source: gtk4
Version: 4.12.0+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-m...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips64el mipsel

gtk4 4.12.0 in experimental has test failures on multiple buildds.
Of those, mips64el and mipsel seem to have the same failure mode:
failure mode:

  72/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-flipped-gl / gl 
border-one-rounded flipped   FAIL   
  5.47s   exit status 1
 315/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl / gl opacity-overdraw   
 FAIL   
  4.89s   exit status 1
 316/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-flipped-gl / gl 
opacity-overdraw flipped FAIL   
  4.94s   exit status 1
 317/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-repeated-gl / 
gl opacity-overdraw repeated   FAIL 
5.05s   exit status 1
 318/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-rotated-gl / gl 
opacity-overdraw rotated FAIL   
  4.95s   exit status 1
 319/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-masked-gl / gl 
opacity-overdraw masked   FAIL  
   5.02s   exit status 1
1406/1464 gtk:reftest / reftest label-sizing.ui 
 FAIL   
 19.29s   0/1 subtests passed
1422/1464 gtk:reftest / reftest opacity.ui  
 FAIL   
  6.79s   0/1 subtests passed

These are "reftests", which work by rendering the same image in two
different ways and then doing a pixel-by-pixel comparison. Because
Debian buildds do not give us a way to capture test artifacts, the images
are output into the log with uuencode, for example these:

begin-base64 644 testsuite/gsk/compare/opacity-overdraw.png
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iRklEQVRIie3WMQ4AIAxCUWo8uDev
B7BjYwc+I8tLmAgpjwayJlDgr9lVmYpWJJRP5zc1MDAwMDAwsDFcfq7qI3XHb2o/+AJ0lQS/vZJx
GQBJRU5ErkJggg==


begin-base64 644 
debian/build/deb/testsuite/gsk/compare/gl/x11/opacity-overdraw.out.png
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iS0lEQVRIie3WMQ4AIAhD0aIe3Isb
vACDA5GB35HlJWWpSb5VkFGBAn/Nio5HlopM+Rv8o4Z+PwYGBgYGBgauh8PpY8FGyk6/qvvBF6Er
BMOKG8HLAElFTkSuQmCC


begin-base64 644 
debian/build/deb/testsuite/gsk/compare/gl/x11/opacity-overdraw.diff.png
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iKklEQVRIie3NoQEAIAzEwGdvZPeG
BUBR3J2MSQKfjFOsZHVO5uUDAAC82WlIAgJv9eZaAElFTkSuQmCC


The way these work is that they are output in sets of three: a reference
image, an actual output, and an artifically-enhanced diff image to
highlight what the difference is. See #1024391, #993550, #1003348 for
previous examples of architecture-specific rendering differences (#1024391
was not on mips*, but has details of how to run individual tests which
might be useful, while the other two were on mips*el).

I haven't reconstructed the actual images for a visual comparison yet.
If the mis-rendering doesn't seem release-critically bad then we'll work
around this by ignoring those particular test failures on mips*el.

mips*el are the only architectures where we are using the softpipe GL
driver (because llvmpipe appears to be otherwise broken there) so that is a
possible root cause.

Having to investigate and work around failing tests in GL-dependent
packages on mips*el is becoming a significant time sink for the GNOME team,
so I would appreciate it if mips porters could fix its llvmpipe so that it
can be back in the same situation as every other release architecture.

smcv

Bug#1043147: [Pkg-sssd-devel] Bug#1043147: Bug#1043147: ding-libs: please consider upgrading to 3.0 source format

2023-08-19 Thread Simon Josefsson

Hi.  I have uploaded a fixed ding-libs to DELAYED/5 now, see attached
for easy review.

/Simon
diff -Nru ding-libs-0.6.2/debian/changelog ding-libs-0.6.2/debian/changelog
--- ding-libs-0.6.2/debian/changelog	2023-08-19 13:24:21.0 +0200
+++ ding-libs-0.6.2/debian/changelog	2023-08-19 13:12:21.0 +0200
@@ -1,3 +1,30 @@
+ding-libs (0.6.2-2) unstable; urgency=medium
+
+  [ Simon Josefsson ]
+  * control: Add myself as Uploaders.
+  * control: Use new pkg-sssd email address.
+  * copyright: Add myself for debian/*, silencing lintian warning update-
+debian-copyright.
+  * Add Rules-Requires-Root: no.
+  * Standards-Version 4.6.2.
+  * Build with hardening=+all.
+  * Drop '--with quilt'.  Remove placeholder series.
+  * Update watch (thanks Oneric!) and add debian/upstream/signing-key.asc.
+  * source/options: Add extend-diff-ignore.
+  * Add Build-Depends-Package to *.symbols.
+  * copyright: Drop obsolete build/ltmain.sh.
+
+  [ Debian Janitor ]
+  * Use secure copyright file specification URI.
+  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse.
+  * Update standards version to 4.6.1, no changes needed.
+  * Apply multi-arch hints.
+
+  [ Timo Aaltonen ]
+  * source: Migrate to format 3.0 (quilt). (Closes: #1043147)
+
+ -- Simon Josefsson   Sat, 19 Aug 2023 13:12:21 +0200
+
 ding-libs (0.6.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru ding-libs-0.6.2/debian/control ding-libs-0.6.2/debian/control
--- ding-libs-0.6.2/debian/control	2023-08-19 13:24:21.0 +0200
+++ ding-libs-0.6.2/debian/control	2023-08-08 14:52:15.0 +0200
@@ -1,22 +1,25 @@
 Source: ding-libs
 Section: libs
 Priority: optional
-Maintainer: Debian SSSD Team 
-Uploaders: Timo Aaltonen 
+Maintainer: Debian SSSD Team 
+Uploaders: Timo Aaltonen ,
+   Simon Josefsson 
 Build-Depends: debhelper-compat (= 13),
  quilt,
  check,
  pkg-config,
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
 Homepage: https://github.com/SSSD/ding-libs
 Vcs-Git: https://salsa.debian.org/sssd-team/ding-libs.git
 Vcs-Browser: https://salsa.debian.org/sssd-team/ding-libs
+Rules-Requires-Root: no
 
 Package: libpath-utils-dev
 Section: libdevel
 Architecture: any
 Depends: ${misc:Depends},
  libpath-utils1 (= ${binary:Version}),
+Multi-Arch: same
 Description: Development files for libpath_utils
  Utility functions to manipulate filesystem pathnames. Development files.
  .
@@ -39,6 +42,7 @@
 Architecture: any
 Depends: ${misc:Depends},
  libdhash1 (= ${binary:Version}),
+Multi-Arch: same
 Description: Development files for libdhash
  A hash table which will dynamically resize to achieve optimal storage & access
  time properties. Development files.
@@ -63,6 +67,7 @@
 Architecture: any
 Depends: ${misc:Depends},
  libcollection4 (= ${binary:Version}),
+Multi-Arch: same
 Description: Development files for libcollection
  A data-type to collect data in a hierarchical structure for easy iteration
  and serialization. Development files.
@@ -87,6 +92,7 @@
 Architecture: any
 Depends: ${misc:Depends},
  libref-array1 (= ${binary:Version}),
+Multi-Arch: same
 Description: Development files for refcounted array for C
  A dynamically-growing, reference-counted array. Development files.
  .
@@ -136,6 +142,7 @@
 Architecture: any
 Depends: ${misc:Depends},
  libbasicobjects0 (= ${binary:Version}),
+Multi-Arch: same
 Description: Basic object types for C -- development files
  Library that add basic object types for C. Development files.
  .
diff -Nru ding-libs-0.6.2/debian/copyright ding-libs-0.6.2/debian/copyright
--- ding-libs-0.6.2/debian/copyright	2023-08-19 13:24:21.0 +0200
+++ ding-libs-0.6.2/debian/copyright	2023-08-19 13:07:29.0 +0200
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: ding-libs
 Source: https://github.com/SSSD/ding-libs
 
@@ -10,10 +10,6 @@
 Copyright: 2009-2010 Dmitri Pal 
 License: GPL-3+
 
-Files: build/ltmain.sh
-Copyright: 1996 Gordon Matzigkeit 
-License: GPL-2+
-
 Files: dhash/* path_utils/*
 Copyright: 2009 Red Hat
 License: LGPL-3+
@@ -30,30 +26,9 @@
 Copyright: 2011 Fabrice Coutadeur ,
2011 Jonathan Carter ,
2011 Timo Aaltonen 
+	   2023 Simon Josefsson 
 License: GPL-3+
 
-License: GPL-2+
- This program is free software; you can redistribute it
- and/or modify it under the terms of the GNU General Public
- License as published by the Free Software Foundation; either
- version 2 of the License, or (at your option) any later
- version.
- .
- This program is distributed in the hope that it will be
- useful, but WITHOUT ANY WARRANTY; without even the implied
- warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
- PURPOSE.  See the GNU General Public License for more
- details.
- .
- You should have received a copy of the GNU General Public
- License along with this package; if not, write

Bug#1050026: r-bioc-metagenomeseq: autopkgtest regression

2023-08-19 Thread Andreas Tille

Control: tags -1 upstream
Control: forwarded -1 https://github.com/HCBravoLab/metagenomeSeq/issues/87


-- 
http://fam-tille.de

Bug#1050076: gtk4: 4.12 regression: FTBFS on i386: assertion failed (r == tests[i].r (+/- FLT_EPSILON))

Source: gtk4
Version: 4.12.0+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Usertags: i387

gtk4 4.12.0 in experimental has test failures on multiple buildds.
On i386 there is this failure:

not ok /color/roundtrips - 
ERROR:../../../testsuite/gtk/colorutils.c:43:test_roundtrips: assertion failed 
(r == tests[i].r (+/- FLT_EPSILON)): (1.1920929e-07 == 0)

I think this is our old enemy, the legacy i387 FPU and its 80-bit
extended precision, and the test will need to apply more fuzz to its
acceptable result.

If our i386 port had a baseline that included SSE2 so that we could
build everything with -mfpmath=sse, this class of bug would probably
go away; but at the moment our baseline is officially a not-quite-i686
(i686 with one missing opcode, to accommodate certain Geode CPUs) so
we cannot assume MMX, SSE or SSE2, and various developers have resisted
suggestions to raise the baseline. I'm going to start tracking bugs in
this class with a usertag to get an idea of how many of them there are.

smcv

Bug#1050075: gtk4: 4.12 regression: FTBFS on arm*|ppc64el|s390x: several checkerboard tests failing