Bug#244843: pspresent: starts but does not show anything

[Jamie Wilkinson]

I'm really sorry I didn't look at this sooner.  I found the file in my
email from Brice, and tried viewing it in pspresent and receive the error:

`ERROR: Document does not follow PostScript structuring convention`

which.. makes sense because it's an EPS, not a regular PS?

I don't intend to keep this bug open because pspresent has been
unmaintained for over a decade.

On Sat, 19 Apr 2008 at 00:49, Jamie Wilkinson  wrote:

> This one time, at band camp, Brice Goglin wrote:
> >I'm just running pspresent without any parameter except
> >the name of my file (which was created with latex and prosper).
>
> How big is this file?  How long does gv take to display it?
>
> Could I see it?  (send it directly to me if you don't want it archived
> in the bug report)
>
> --
> j...@debian.org   http://people.debian.org/~jaq
>

Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken

[Ansgar]

Control: retitle -1 trixie/sid system ended up with split-usr

Hi,

On Thu, 17 Aug 2023 18:42:14 +0200 Vincent Lefevre wrote:
> Control: retitle -1 cron-daemon-common: in /etc/crontab, run-parts is no 
> longer in $PATH
> 
> That's actually the real reason.
> 
> /etc/crontab has
> 
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
> 
> but
> 
> zira:~> dlocate =run-parts
> debianutils: /bin/run-parts

This seems the be the real issue:

+---
| Debian Release: trixie/sid
| [...]
| merged-usr: no
+---[ https://bugs.debian.org/1049969#5 ]

/bin *must* be a symlink to /usr/bin, so /usr/bin/run-parts must exist
and cron's PATH is sufficient.

Please investigate why "usrmerge" is not installed (I assume this is an
upgraded system).  Or, if it is installed, why /bin, /sbin, /lib* are
not symlinks to their respective counterparts in /usr.

Ansgar

Bug#1029203: Fix for serious bug needs package in new (r-cran-gsfonts)

[Andreas Tille]

Control: block -1 by 1029203

Hi,

the new version of flextable works together with recent r-cran-bookdown.
Unfortunately r-cran-flextable (0.9.2-1) implizitly depends from
r-cran-gfonts (ITP #1029203) which takes its second round in new [1].
It would help if this package could get preference to fix this RC bug.

Kind regards
Andreas.

[1] https://ftp-master.debian.org/new/r-cran-gfonts_0.2.0-1.html

-- 
http://fam-tille.de

Bug#1042769: provean: incompatible with cd-hit >= 4.8.1-4

[Andrius Merkys]

Hi Andreas,

On 2023-08-17 10:49, Andreas Tille wrote:

thanks for reporting this issue.  You were mentioning you want to come
up with a patch.  Since you seem to have dived into this issue deeper
I assume you will care for this bug.  If not please clarify the status
(or may be set the "help" tag).


I feel like working on it myself as I have a setup for reproducing it 
(it needs a version of NR database, ~100 GB) and I have located the 
approximate location in the code (cd-hit output parsing). It could help 
me a lot if someone knew the changes in cd-hit output since 4.8.1, 
though, as I am not a frequent user.


Best wishes,
Andrius

Bug#1049996: sponsorship-requests: update libkysdk-base version, and upload the package to unstable

[xibowen]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libkysdk-base":

 * Package name : libkysdk-base
   Version  : 2.2.0.0-1
   Upstream contact : Zhikai Chen 
 * URL  : https://gitee.com/openkylin/libkysdk-base
 * License  : LGPL-3
 * Vcs  : https://gitee.com/openkylin/libkysdk-base
   Section  : libs

The source builds the following binary packages:

  libkysdk-base - Kylin SDK basic library
  libkysdk-base-dev - development files for libkysdk-base
  libkysdk-timer - C style timer module
  libkysdk-timer-dev - development files for libkysdk-timer
  libkysdk-config - configuration file module
  libkysdk-config-dev - development files for libkysdk-config
  libkysdk-log - C style log module
  libkysdk-log-dev - development files for libkysdk-log
  libkysdk-utils - Basic tool function module
  libkysdk-utils-dev - development files for libkysdk-utils
  libkysdk-gsetting - gsetting configuration module
  libkysdk-gsetting-dev - gsetting configuration module, development package

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

  https://mentors.debian.net/package/libkysdk-base/

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

  dget -x https://mentors.debian.net/debian/pool/main/libk/libkysdk-
base/libkysdk-base_2.2.0.0-1.dsc

Changes since the last upload:

 libkysdk-base (2.2.0.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Upload to unstable.

Regards,
--
  xibowen

Bug#1049995: openssh: catalan translation [INTL:ca]

[Pablo Huguet]

Source: openssh
Severity: wishlist
Tags: patch l10n
X-Debbugs-Cc: pa...@establetech.com.es


I did the catalan translation of it, and I will add the translation is included
thanks for reading!

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/1 CPU thread)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Pablo Huguet, 2023.
# 
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: openssh\n"
"Report-Msgid-Bugs-To: open...@packages.debian.org\n"
"POT-Creation-Date: 2014-03-20 02:06+\n"
"PO-Revision-Date: 2023-08-18 03:20+0200\n"
"Last-Translator: Pablo Huguet \n"
"Language-Team: Catalan \n"
"Language: ca\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../openssh-server.templates:1001
msgid "Disable SSH password authentication for root?"
msgstr "Desactivar l'autenticació de contrasenya SSH per a root?"

#. Type: boolean
#. Description
#: ../openssh-server.templates:1001
msgid ""
"Previous versions of openssh-server permitted logging in as root over SSH "
"using password authentication. The default for new installations is now "
"\"PermitRootLogin prohibit-password\", which disables password "
"authentication for root without breaking systems that have explicitly "
"configured SSH public key authentication for root."
msgstr ""
"Les versions anteriors d'openssh-server permetien iniciar sessió com a root a 
través de SSH"
"utilitzant l'autenticació de contrasenya. El valor predeterminat per a 
instal·lacions noves és ara "
"\"PermitRootLogin prohibit-password\", que desactiva la contrasenya "
"autenticació per a root sense trencar sistemes que tenen explícitament"
"Autenticació de clau pública SSH configurada per a root".

#. Type: boolean
#. Description
#: ../openssh-server.templates:1001
msgid ""
"This change makes systems more secure against brute-force password "
"dictionary attacks on the root user (a very common target for such attacks). "
"However, it may break systems that are set up with the expectation of being "
"able to SSH as root using password authentication. You should only make this "
"change if you do not need to do that."
msgstr ""
"Aquest canvi fa que els sistemes siguin més segurs contra contrasenyes de 
força bruta"
"atacs de diccionari a l'usuari root (un objectiu molt comú per a aquests 
atacs)."
"No obstant això, pot trencar sistemes que es configuren amb l'expectativa de 
ser"
"Pot fer SSH com a root mitjançant l'autenticació de contrasenya. Només hauríeu 
de fer això"
"canvia si no cal fer-ho".

Bug#994746: Upstream source now uses system gpac

[Ben Westover]

Hello,

Now that https://github.com/CCExtractor/ccextractor/pull/1535 has been 
merged, the upstream source uses system gpac instead of vendoring it.


--
Ben Westover


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1049994: zephyr: translation ca [INTL:ca]

[Pablo Huguet]

Source: zephyr
Severity: wishlist
Tags: patch l10n
X-Debbugs-Cc: pa...@establetech.com.es

I did the Catalan translation of this file, thanks for reading.


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

Kernel: Linux 5.10.0-21-amd64 (SMP w/1 CPU thread)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Pablo Huguet, 2023.
# 
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: zep...@packages.debian.org\n"
"Report-Msgid-Bugs-To: Source: zep...@packages.debian.org\n"
"POT-Creation-Date: 2007-12-05 09:47+0530\n"
"PO-Revision-Date: 2023-08-18 03:09+0200\n"
"Last-Translator: Pablo Huguet \n"
"Language-Team: Catalan \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: string
#. Description
#: ../zephyr-clients.templates:2001 ../zephyr-server.templates:2001
msgid "Zephyr servers:"
msgstr "Servidors Zephyr"

#. Type: string
#. Description
#: ../zephyr-clients.templates:2001 ../zephyr-server.templates:2001
msgid ""
"Please specify the full names of the Zephyr servers, as a space-separated "
"list."
msgstr ""
"Especifiqueu els noms complets dels servidors Zephyr, separats per espais"
"llista".

#. Type: string
#. Description
#: ../zephyr-clients.templates:2001 ../zephyr-server.templates:2001
msgid ""
"The list configured on clients can be a subset of the list configured on "
"servers."
msgstr ""
"La llista configurada als clients pot ser un subconjunt de la llista 
configurada a "
"servidors".

#. Type: string
#. Description
#: ../zephyr-clients.templates:2001
msgid "This can be left empty if Hesiod is used to advertise Zephyr servers."
msgstr "Això es pot deixar buit si Hesíode s'utilitza per anunciar servidors 
Zephyr."
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Pablo Huguet, 2023.
# 
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: zep...@packages.debian.org\n"
"Report-Msgid-Bugs-To: Source: zep...@packages.debian.org\n"
"POT-Creation-Date: 2007-12-05 09:47+0530\n"
"PO-Revision-Date: 2023-08-18 03:09+0200\n"
"Last-Translator: Pablo Huguet \n"
"Language-Team: Catalan \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: string
#. Description
#: ../zephyr-clients.templates:2001 ../zephyr-server.templates:2001
msgid "Zephyr servers:"
msgstr "Servidors Zephyr"

#. Type: string
#. Description
#: ../zephyr-clients.templates:2001 ../zephyr-server.templates:2001
msgid ""
"Please specify the full names of the Zephyr servers, as a space-separated "
"list."
msgstr ""
"Especifiqueu els noms complets dels servidors Zephyr, separats per espais"
"llista".

#. Type: string
#. Description
#: ../zephyr-clients.templates:2001 ../zephyr-server.templates:2001
msgid ""
"The list configured on clients can be a subset of the list configured on "
"servers."
msgstr ""
"La llista configurada als clients pot ser un subconjunt de la llista 
configurada a "
"servidors".

#. Type: string
#. Description
#: ../zephyr-clients.templates:2001
msgid "This can be left empty if Hesiod is used to advertise Zephyr servers."
msgstr "Això es pot deixar buit si Hesíode s'utilitza per anunciar servidors 
Zephyr."

Bug#1049993: gcc: add symlink for path with vendored-triple

[YunQiang Su]

Package: src:gcc-13
Version: 13.2.0-4

Can we consider adding a symlink from non-vendor triples to vendored triples?
For example:
 /usr/lib/gcc/x86_64-linux-gnu -> /usr/lib/gcc/x86_64-unknown-linux-gnu

LLVM guys complains about it:
https://reviews.llvm.org/D158183#4596086



-- 
YunQiang Su

Bug#1049992: acpi: Please add loong64 architecture for acpi package.

[JiaLing Zhang]

Package: acpi
Version: acpi_1.7-1.2
Severity: normal
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,

Please add 'loong64' to architecture stanza of debian/control.


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

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

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

Bug#1041556: [R-pkg-team] Bug#1041556: What is the architecture name in R what we call armel/armhf

[Charles Plessy]

Le Thu, Aug 17, 2023 at 07:52:35AM +0200, Andreas Tille a écrit :
> 
>   arch <- R.version$arch
>   identical(arch, "i386") || identical(arch, "i686") || identical(arch, 
> "armel") || identical(arch, "armhf")

Hi Andreas, how about:

system("dpkg-architecture -qDEB_BUILD_ARCH", intern=TRUE) %in% c("i386", 
"i686", "armel", "armhf")

Have a nice day,

-- 
Charles

Bug#1049991: arm-trusted-firmware: suggestions to improve the maintability of debian/rules

[Nicolas Boulenguez]

Source: arm-trusted-firmware
Severity: wishlist
Tags: patch

Hello.

The attached patch arguably improves debian/rules.

The ediff mode of emacs provides a more useful overview of the changes
than plain diff or gitk.
According to the test described at the end of the commit log, the new
version executes the same shell commands than before.

As usual… thanks for maintaining this package.
I hope this will simplify your work.
>From 92481e8b58dcf28727164c0764265e78d82656b0 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 17 Aug 2023 23:01:48 +0200
Subject: debian/rules: improve readability and logs

Group all references to a given board.

Use global variables for default values and target-specific variables
for overrides.

Run each command separately so that Make checks the exit status and
the log is more useful in case of failure.

Avoid Make obscure features like `define`, `eval`, `call` and
constructed variable names.

Display (indent with tab) a comment at the start of each subplatform,
but hide comments intended for readers of debian/rules.

Replace a Make `foreach` loop with the implicit iteration of the
`install` command on its argument.

Remove a reference to the unset `board` variable (introduced by
commit 97c362ab).

The diff between the output of
`DEB_HOST_ARCH=arm64 debian/rules -n override_dh_auto_build | sed 's/ *; 
*/\n/g' | sort`
before and after this commit seems correct.

diff --git a/debian/rules b/debian/rules
index 710178171..f1e435f73 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,62 +14,67 @@ else
 VERBOSE=1
 endif
 
-platforms := g12a gxbb sun50i_a64 sun50i_h6 rcar rk3328 rk3399 rpi3 rpi4 
imx8mn imx8mm
+subplatforms := g12a gxbb sun50i_a64 rpi3 rpi4
+
 # Disable building of imx8mq, as it is not well supported upstream.
-#platforms_nodebug := imx8mq
+# subplatforms += imx8mq
+imx8mq: buildtype := release
+imx8mq: debug := 0
 
 # By default, iMX8MN uses UART2 console. However, other boards supported
 # upstream (e.g. Variscite VAR-SOM-MX8M-NANO board) uses UART4.
 # Add two subplatforms for imx8mn platform:
 #   * imx8mn: default configuration
 #   * imx8mn_uart4: console set to UART4
-imx8mn_subplatforms := imx8mn imx8mn_uart4
-imx8mn_uart4_assigns := IMX_BOOT_UART_BASE=0x30a6
+subplatforms += imx8mn imx8mn_uart4
+imx8mn_uart4: platform := imx8mn
+imx8mn_uart4: assigns := IMX_BOOT_UART_BASE=0x30a6
 
 # By default, iMX8MM uses UART2 console. However, other boards
 # use other UARTs
-imx8mm_subplatforms := imx8mm imx8mm_uart1 imx8mm_uart3 imx8mm_uart4
-imx8mm_uart1_assigns := IMX_BOOT_UART_BASE=0x3086
-imx8mm_uart3_assigns := IMX_BOOT_UART_BASE=0x3088
-imx8mm_uart4_assigns := IMX_BOOT_UART_BASE=0x30A6
+subplatforms += imx8mm imx8mm_uart1 imx8mm_uart3 imx8mm_uart4
+imx8mm_uart1 imx8mm_uart3 imx8mm_uart4: platform := imx8mm
+imx8mm_uart1: assigns := IMX_BOOT_UART_BASE=0x3086
+imx8mm_uart3: assigns := IMX_BOOT_UART_BASE=0x3088
+imx8mm_uart4: assigns := IMX_BOOT_UART_BASE=0x30A6
 
 # TF-A's regulator setup breaks Ethernet on some H6 boards,
 # so make it optional by having two subplatforms:
 #   * sun50i_h6: default configuration
 #   * sun50i_h6_no_pmic: skip regulator setup
-sun50i_h6_subplatforms := sun50i_h6 sun50i_h6_no_pmic
-sun50i_h6_no_pmic_assigns := SUNXI_SETUP_REGULATORS=0
-
-rk3328_targets := bl31/bl31.elf
-rk3399_targets := bl31/bl31.elf
+subplatforms += sun50i_h6 sun50i_h6_no_pmic
+sun50i_h6_no_pmic: platform := sun50i_h6
+sun50i_h6_no_pmic: assigns := SUNXI_SETUP_REGULATORS=0
 
-rcar_subplatforms := rcar_uclb_h3 rcar_uclb_m3w rcar_uclb_m3n
-rcar_uclb_h3_assigns := LSI=H3 RCAR_DRAM_SPLIT=1 RCAR_GEN3_ULCB=1 
PMIC_LEVEL_MODE=0 RCAR_DRAM_LPDDR4_MEMCONF=0 SPD=opteed RCAR_LOSSY_ENABLE=1
-rcar_uclb_m3n_assigns := LSI=M3N RCAR_GEN3_ULCB=1 PMIC_LEVEL_MODE=0 
RCAR_DRAM_LPDDR4_MEMCONF=0 SPD=opteed RCAR_LOSSY_ENABLE=1
-rcar_uclb_m3w_assigns := LSI=M3 RCAR_DRAM_SPLIT=2 RCAR_GEN3_ULCB=1 
PMIC_LEVEL_MODE=0 RCAR_DRAM_LPDDR4_MEMCONF=0 SPD=opteed RCAR_LOSSY_ENABLE=1
+subplatforms += rk3328 rk3399
+rk3328 rk3399: targets := bl31/bl31.elf
 
-rcar_targets := bl31.srec bl2.srec
-rcar_make_target := rcar
+subplatforms += rcar_uclb_h3 rcar_uclb_m3w rcar_uclb_m3n
+rcar_uclb_h3: assigns := LSI=H3 RCAR_DRAM_SPLIT=1 RCAR_GEN3_ULCB=1 
PMIC_LEVEL_MODE=0 RCAR_DRAM_LPDDR4_MEMCONF=0 SPD=opteed RCAR_LOSSY_ENABLE=1
+rcar_uclb_m3n: assigns := LSI=M3N RCAR_GEN3_ULCB=1 PMIC_LEVEL_MODE=0 
RCAR_DRAM_LPDDR4_MEMCONF=0 SPD=opteed RCAR_LOSSY_ENABLE=1
+rcar_uclb_m3w: assigns := LSI=M3 RCAR_DRAM_SPLIT=2 RCAR_GEN3_ULCB=1 
PMIC_LEVEL_MODE=0 RCAR_DRAM_LPDDR4_MEMCONF=0 SPD=opteed RCAR_LOSSY_ENABLE=1
+rcar_uclb_h3 rcar_uclb_m3n rcar_uclb_m3w: platform := rcar
+rcar_uclb_h3 rcar_uclb_m3n rcar_uclb_m3w: targets := bl31.srec bl2.srec
+rcar_uclb_h3 rcar_uclb_m3n rcar_uclb_m3w: make_target := rcar
 
-# Always set CROSS_COMPILE, which also works for native builds.
-define build_platform
-   $(eval platform := $(1))
-   $(eval debug := $(2))
-   $(eval buildtype := $(3))
-  

Bug#1042543: Known upstream regression in 6.4: audio distortion on ThinkPad X1 Gen 11

[David]

Version: 6.4.4-3

Hello,

1. the bug is still present

2. Dell XPS 9310 is also affected.

It's still not included in stable series, but got merged into for-next 
branch already [1].


Please apply.

Thank you

David

[1] https://www.spinics.net/lists/alsa-devel/msg163701.html

On Sat, 29 Jul 2023 19:58:50 -0700 Josh Triplett  
wrote:

> Package: src:linux
> Version: 6.4.4-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: j...@joshtriplett.org
>
> See https://github.com/thesofproject/linux/issues/4482 and
> https://bugzilla.kernel.org/show_bug.cgi?id=217673 for the bug, and
> https://github.com/thesofproject/linux/pull/4484 for the fix.
>
> I can confirm that 6.4 has intermittent audio distortion on my system,
> and 6.3 does not.
>
> Please consider applying the fix.

Bug#1000097: compton: depends on obsolete pcre3 library

[Bastian Germann]

It can be built without pcre by adding the following to d/rules:

override_dh_auto_build:
dh_auto_build -- NO_REGEX_PCRE=1

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Alexandru Mihail]

Hello, Nicholas !
>Thanks again for your work!  I submitted a second (I think we're at
>the
>second one) gitlab review here:
Fixes for review items are commited :)
I cannot yet review the untested patch about VHOSTING as I cannot
replicate (or maybe miss something in my mini_httpd.conf ?) the bug.
I'd deffer it to next upload if you don't happen to have some
time/knowledge about ancient multihosting  :)
>After that, let's talk about uploading.  Think about whether you'd
>like
>to start gaining practice with dput (or dput-ng), or whether you'd
>like
>me to sponsor directly from git.
I'm pretty ambivalent to both..are you more comfortable with either one
? I'd reckon practice with dput might help me in the case where I
become an uploading maintainer with full rights?

Cheers, we're getting close :D !
Alexandru



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

Bug#1049990: RM: gtkpool -- RoQA; depends on gtk2; dead upstream; unmaintained; low popcon

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:gtkpool

Please remove gtkpool. The package depends on gtk2, is unmaintained in 
Debian (last maintainer upload in 2009), dead upstream and has a low 
popcon. A better and more popular alternative exists with foobillardplus.

Bug#1049989: gnome-calendar: Multiple assertion failures

[Marc Glisse]

Package: gnome-calendar
Version: 44.1-2
Severity: important

Dear Maintainer,

my terminal currently shows the following, I think you can guess why I
am not happy

hippo ~ $ gnome-calendar 

(gnome-calendar:33118): GcalWeatherService-WARNING **: 00:10:36.416: Could not 
create GCLueSimple: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: 
Geolocation disabled for UID 59682

(gnome-calendar:33118): Gtk-CRITICAL **: 00:11:12.266: gtk_header_bar_pack: 
assertion 'gtk_widget_get_parent (widget) == NULL' failed
**
GcalEditCalendarPage:ERROR:../src/gui/calendar-management/gcal-edit-calendar-page.c:206:update_calendar:
 assertion failed: (self->calendar != NULL)
Bail out! 
GcalEditCalendarPage:ERROR:../src/gui/calendar-management/gcal-edit-calendar-page.c:206:update_calendar:
 assertion failed: (self->calendar != NULL)
zsh: IOT instruction (core dumped)  gnome-calendar
hippo ~ $ gnome-calendar

(gnome-calendar:35447): GcalWeatherService-WARNING **: 00:22:44.384: Could not 
create GCLueSimple: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: 
Geolocation disabled for UID 59682
**
GcalTimeline:ERROR:../src/core/gcal-timeline.c:579:on_calendar_monitor_completed_cb:
 assertion failed: (self->completed_calendars <= g_hash_table_size 
(self->calendars))
Bail out! 
GcalTimeline:ERROR:../src/core/gcal-timeline.c:579:on_calendar_monitor_completed_cb:
 assertion failed: (self->completed_calendars <= g_hash_table_size 
(self->calendars))
zsh: IOT instruction (core dumped)  gnome-calendar

I launched gnome-calendar, added an online calendar, removed some,
looked around in manage calendars, and it crashed. Twice, with a
different error. I am sorry, I do not remember what exact menu I was on
at the time, and if I was clicking on something.

After that, I restarted gnome-calendar in gdb, removed a few more
calendars, and finally got

GcalTimeline:ERROR:../src/core/gcal-timeline.c:579:on_calendar_monitor_completed_cb:
 assertion failed: (self->completed_calendars <= g_hash_table_size 
(self->calendars))
Bail out! 
GcalTimeline:ERROR:../src/core/gcal-timeline.c:579:on_calendar_monitor_completed_cb:
 assertion failed: (self->completed_calendars <= g_hash_table_size 
(self->calendars))

Thread 1 "gnome-calendar" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=signo@entry=6, 
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
Download failed: Invalid argument.  Continuing without source file 
./nptl/./nptl/pthread_kill.c.
44  ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x76cbc15f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x76c6e472 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x76c584b2 in __GI_abort () at ./stdlib/abort.c:79
#4  0x770f3ee8 in g_assertion_message
(domain=domain@entry=0x555b76c9 "GcalTimeline", 
file=file@entry=0x555b76fd "../src/core/gcal-timeline.c", 
line=line@entry=579, func=func@entry=0x555c1b20 <__func__.8> 
"on_calendar_monitor_completed_cb", message=message@entry=0x56ded470 
"assertion failed: (self->completed_calendars <= g_hash_table_size 
(self->calendars))") at ../../../glib/gtestutils.c:3497
#5  0x7715955a in g_assertion_message_expr
(domain=domain@entry=0x555b76c9 "GcalTimeline", 
file=file@entry=0x555b76fd "../src/core/gcal-timeline.c", 
line=line@entry=579, func=func@entry=0x555c1b20 <__func__.8> 
"on_calendar_monitor_completed_cb", expr=expr@entry=0x555bde58 
"self->completed_calendars <= g_hash_table_size (self->calendars)") at 
../../../glib/gtestutils.c:3523
#6  0x55587853 in on_calendar_monitor_completed_cb (monitor=, pspec=, self=0x55875fd0 [GcalTimeline]) at 
../src/core/gcal-timeline.c:579
#11 0x77d6e5ff in 
(instance=instance@entry=0x557db8f0, signal_id=, 
detail=) at ../../../gobject/gsignal.c:3675
#7  0x77d543f8 in g_closure_invoke (closure=0x56bb8680, 
return_value=0x0, n_param_values=2, param_values=0x7fffdbd0, 
invocation_hint=0x7fffdb20)
at ../../../gobject/gclosure.c:832
#8  0x77d6701c in signal_emit_unlocked_R
(node=node@entry=0x7fffdca0, detail=detail@entry=345, 
instance=instance@entry=0x557db8f0, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffdbd0) at 
../../../gobject/gsignal.c:3980
#9  0x77d68951 in signal_emit_valist_unlocked 
(instance=instance@entry=0x557db8f0, signal_id=signal_id@entry=1, 
detail=detail@entry=345, var_args=var_args@entry=0x7fffde00)
at ../../../gobject/gsignal.c:3612
#10 0x77d6e552 in g_signal_emit_valist (instance=0x557db8f0, 
signal_id=1, detail=345, var_args=0x7fffde00) at 
../../../gobject/gsignal.c:3355
#12 0x77d581b4 in 

Bug#1049985: closed by "Adam D. Barratt" (Re: Bug#1049985: buster-pu: package riemann-c-client/1.10.4-2)

[Romain Tartière]

On Thu, Aug 17, 2023 at 09:57:05PM +, Debian Bug Tracking System wrote:
> buster hasn't been managed by the Release Team for a year now.

D'oh! I shifted "stable and oldstable" with "oldstable and
oldoldstable".

Will redo targeting the correct distribution, thank you for your
vigilance!

Romain



signature.asc
Description: PGP signature

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

[Romain Tartière]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: riemann-c-cli...@packages.debian.org, rom...@blogreen.org
Control: affects -1 + src:riemann-c-client

[ Reason ]
Due to improper return value checks, when communicating with a remote
server over TLS riemann-c-client sometimes send the same data fragment
multiple times, resulting in the server receiving a malformed payload.

This happen with all versions of TLS, but TLS 1.3 trigger this bad
behaviour more often.  With more and more services using TLS 1.3, this
problem is more and more prevalent.

[ Impact ]
When the client send a large payload over TLS faster than the network
can send it, the improper return value checks cause portions of that
data to be send multiple times to the server.  When the transfer
eventually finish, the server detect that the payload is invalid and
drop the connection.  The client will then reconnect and retry the
transfer that might fail again and again.

Beside error messages in the server logs, these data corrupt data
transfer cause an unexpectedly hight bandwidth usage.

[ Tests ]
Manually tested on our infrastructure (mostly Debian oldstable).

[ Risks ]
Low

[ 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 ]
Adjust the checks of the return values of gnutls_record_send() /
gnutls_record_recv() and keep track of the quantity of data already
sent / received when the function return before completion so that it
can continue from the point it stopped the previous time.
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-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.
diff -Nru riemann-c-client-1.10.4/debian/control 
riemann-c-client-1.10.4/debian/control
--- riemann-c-client-1.10.4/debian/control  2019-01-03 07:09:15.0 
-1000
+++ riemann-c-client-1.10.4/debian/control  2023-08-13 12:08:48.0 
-1000
@@ -10,8 +10,6 @@
 Standards-Version: 4.2.1
 Section: libs
 Homepage: https://git.madhouse-project.org/algernon/riemann-c-client
-Vcs-Git:  https://git.madhouse-project.org/algernon/riemann-c-client.git -b 
debian/master
-Vcs-Browser: 
https://git.madhouse-project.org/algernon/riemann-c-client/src/branch/debian/master
 
 Package: libriemann-client0
 Architecture: any
diff -Nru riemann-c-client-1.10.4/debian/gbp.conf 
riemann-c-client-1.10.4/debian/gbp.conf
--- riemann-c-client-1.10.4/debian/gbp.conf 2019-01-03 07:08:30.0 
-1000
+++ riemann-c-client-1.10.4/debian/gbp.conf 1969-12-31 14:00:00.0 
-1000
@@ -1,7 +0,0 @@
-[DEFAULT]
-debian-branch = debian/master
-debian-tag = debian/riemann-c-client-%(version)s
-upstream-tag = riemann-c-client-%(version)s
-compression = xz
-
-postbuild = lintian -I $GBP_CHANGES_FILE && echo "Lintian OK"
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-13 12:08:48.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 

Bug#978595: #978595 is looking higher priority

[Elliott Mitchell]

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.




On a very different note, I'm concerned about commit 5e68feec5b2.  If you
would care to examine patch #3 attached to message #22 on bug 978595, you
will notice it bears a strong resemblance.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978595#22
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=3;bug=978595;filename=0003-debian-rules-Switch-to-truncate-from-dd.patch;msg=22

I believe 5e68feec5b2 is simply parallel development (that was an ugly
use of `dd` and `truncate` is known).  Yet I find it discouraging I
pointed to the issue more than a full 2 years earlier it was ignored.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#1049326: pandas FTBFS with numexpr 2.8.5

[Rebecca N. Palmer]

On further thought, both of those probably should be fixed in numexpr - 
I have pushed them to fix1049326.


With those changes to numexpr, the new pandas (1.5.3+dfsg-5) should 
build; pytables will still also need its upstream fix.

Bug#1049987: linux-image-6.4.0-1-amd64: Headphones not detected after suspend or lid close on laptop

[Andres Pedraza Granados]

Package: src:linux
Version: 6.4.4-2
Severity: important
X-Debbugs-Cc: adpg@gmail.com

The bug was found on a Dell Vostro 3405 with a Cirrus CS8409/CS42L42
audio card. When I plug in my hands-free headphones after waking the laptop
from suspension or opening my lid, the audio keeps playing from the
speakers, my headphones remain quiet, and the mic isn't detected either.

I tried changing to the headphones' sink in Pulseaudio, but it wouldn't
play any sound. I checked through acpi_listen and evtest and noticed
plugging the headphones would trigger events before suspend, but not
after.


-- Package-specific info:
** Version:
Linux version 6.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.1.0-9) 13.1.0, GNU ld (GNU Binutils for Debian) 2.40.90.20230720) #1 SMP 
PREEMPT_DYNAMIC Debian 6.4.4-2 (2023-07-30)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.4.0-1-amd64 
root=UUID=e415e2dc-dac2-49fa-b2bf-5ad6f3025bc5 ro quiet splash

** Not tainted

** Kernel log:
[ 3774.056926] Freezing remaining freezable tasks
[ 3774.058360] Freezing remaining freezable tasks completed (elapsed 0.001 
seconds)
[ 3774.058387] printk: Suspending console(s) (use no_console_suspend to debug)
[ 3774.126455] psmouse serio1: Failed to disable mouse on isa0060/serio1
[ 3774.823825] ACPI: EC: interrupt blocked
[ 3774.872681] ACPI: PM: Preparing to enter system sleep state S3
[ 3774.873933] ACPI: EC: event blocked
[ 3774.873935] ACPI: EC: EC stopped
[ 3774.873936] ACPI: PM: Saving platform NVS memory
[ 3774.874361] Disabling non-boot CPUs ...
[ 3774.876269] smpboot: CPU 1 is now offline
[ 3774.879312] smpboot: CPU 2 is now offline
[ 3774.882026] smpboot: CPU 3 is now offline
[ 3774.884723] smpboot: CPU 4 is now offline
[ 3774.887396] smpboot: CPU 5 is now offline
[ 3774.890156] smpboot: CPU 6 is now offline
[ 3774.892572] smpboot: CPU 7 is now offline
[ 3774.894110] ACPI: PM: Low-level resume complete
[ 3774.894145] ACPI: EC: EC started
[ 3774.894147] ACPI: PM: Restoring platform NVS memory
[ 3774.895188] AMD-Vi: Virtual APIC enabled
[ 3774.895284] AMD-Vi: Virtual APIC enabled
[ 3774.895852] Enabling non-boot CPUs ...
[ 3774.895887] x86: Booting SMP configuration:
[ 3774.895888] smpboot: Booting Node 0 Processor 1 APIC 0x1
[ 3774.898248] ACPI: \_PR_.C001: Found 2 idle states
[ 3774.898579] CPU1 is up
[ 3774.898604] smpboot: Booting Node 0 Processor 2 APIC 0x2
[ 3774.901244] ACPI: \_PR_.C002: Found 2 idle states
[ 3774.901549] CPU2 is up
[ 3774.901565] smpboot: Booting Node 0 Processor 3 APIC 0x3
[ 3774.903906] ACPI: \_PR_.C003: Found 2 idle states
[ 3774.904204] CPU3 is up
[ 3774.904223] smpboot: Booting Node 0 Processor 4 APIC 0x4
[ 3774.906830] ACPI: \_PR_.C004: Found 2 idle states
[ 3774.907162] CPU4 is up
[ 3774.907176] smpboot: Booting Node 0 Processor 5 APIC 0x5
[ 3774.909545] ACPI: \_PR_.C005: Found 2 idle states
[ 3774.909910] CPU5 is up
[ 3774.909925] smpboot: Booting Node 0 Processor 6 APIC 0x6
[ 3774.912348] ACPI: \_PR_.C006: Found 2 idle states
[ 3774.912755] CPU6 is up
[ 3774.912773] smpboot: Booting Node 0 Processor 7 APIC 0x7
[ 3774.915170] ACPI: \_PR_.C007: Found 2 idle states
[ 3774.915574] CPU7 is up
[ 3774.916790] ACPI: PM: Waking up from system sleep state S3
[ 3774.917646] ACPI: EC: interrupt unblocked
[ 3774.925675] ACPI: EC: event unblocked
[ 3774.926941] [drm] PCIE GART of 1024M enabled.
[ 3774.926944] [drm] PTB located at 0x00F400A0
[ 3774.926960] [drm] PSP is resuming...
[ 3774.946873] [drm] reserve 0x40 from 0xf47fc0 for PSP TMR
[ 3775.045416] amdgpu :04:00.0: amdgpu: RAS: optional ras ta ucode is not 
available
[ 3775.059785] amdgpu :04:00.0: amdgpu: RAP: optional rap ta ucode is not 
available
[ 3775.066380] amdgpu: restore the fine grain parameters
[ 3775.151666] nvme nvme0: 8/0/0 default/read/poll queues
[ 3775.186226] usb 1-4: reset high-speed USB device number 2 using xhci_hcd
[ 3775.214770] usb 3-2: reset high-speed USB device number 2 using xhci_hcd
[ 3775.823052] usb 3-2.4: reset full-speed USB device number 3 using xhci_hcd
[ 3775.880524] [drm] kiq ring mec 2 pipe 1 q 0
[ 3775.891378] [drm] VCN decode and encode initialized successfully(under SPG 
Mode).
[ 3775.891393] amdgpu :04:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0
[ 3775.891396] amdgpu :04:00.0: amdgpu: ring gfx_low uses VM inv eng 1 on 
hub 0
[ 3775.891397] amdgpu :04:00.0: amdgpu: ring gfx_high uses VM inv eng 4 on 
hub 0
[ 3775.891399] amdgpu :04:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 5 
on hub 0
[ 3775.891400] amdgpu :04:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 6 
on hub 0
[ 3775.891402] amdgpu :04:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 7 
on hub 0
[ 3775.891403] amdgpu :04:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 8 
on hub 0
[ 3775.891404] amdgpu :04:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 9 
on hub 0
[ 3775.891405] amdgpu :04:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 10 
on hub 0
[ 3775.891407] amdgpu :04:00.0: amdgpu: 

Bug#1037569: aflplusplus: ftbfs with GCC-13

[Jonathan Bergh]

Control: tags -1 + patch

Hi,

This seems to fix the FTBFS for aflplusplus by updating the 
debian/control deps to the latest gcc-13 dependencies.


diff -Nru aflplusplus-4.07c/debian/control aflplusplus-4.07c/debian/control
--- aflplusplus-4.07c/debian/control  2023-06-20 22:46:27.0 +0200
+++ aflplusplus-4.07c/debian/control  2023-08-17 23:06:53.0 +0200
@@ -9,7 +9,7 @@
  clang-14,
  debhelper-compat (= 13),
  dh-buildinfo,
- gcc-12-plugin-dev,
+ gcc-13-plugin-dev,
  gcc-multilib [amd64 s390x],
  lld-14 [!s390x],
  llvm-14-dev,

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

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2023-08-17 at 10:17 -1000, Romain Tartière wrote:
> Due to improper return value checks, when communicating with a remote
> server over TLS riemann-c-client sometimes send the same data
> fragment
> multiple times, resulting in the server receiving a malformed
> payload.
> 
> This happen with all versions of TLS, but TLS 1.3 trigger this bad
> behaviour more often.  With more and more services using TLS 1.3,
> this
> problem is more and more prevalent.
> 

"debdiff against the package in (old)stable" means between the package
you're requesting to upload to (old)stable and the relevant base suite,
not between unstable and (old)stable.

Please supply an appropriate debdiff.

Regards,

Adam

Bug#1049986: ITP: filtermail -- Filtermail filters incoming e-mail as accepted, spam, or ignored

[Frank B. Brokken]

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

* Package name: filtermail
  Version : 1.02.00
  Upstream Contact: Frank B. Brokken 
* URL : https://fbb-git.gitlab.io/filtermail
* License : GPL
  Programming Lang: C++
  Description : Filtermail filters incoming e-mail as accepted, spam, or 
ignored

Filtermail filters incoming e-mail as either accepted, spam, or ignored
e-mail. It uses rule files, which are inspected in sequence until the incoming
e-mail matches a rule. Once that happens the rule's associated action (accept,
spam, or ignore) is executed. If the e-mail is not matched by any rule then
the e-mail is accepted.

Accepted e-mail normally is appended to the mail file which is used by the
incoming mail server when receiving mail for the current user. E.g., if the
user's username is frank then incoming mail is appended to the file
/var/mail/frank. Users may also define directories to contain saved e-mails
(e.g., ~/Mail), and filtermail can be configured to append e-mail considered as
spam to, e.g., ~/Mail/spam. Likewise, e-mail matching the 'ignore'
criteria could be appended to ~/Mail/ignore. 

Instead of appending the complete e-mail to its destination file the received
e-mail's From: and Subject: headers can be appended to its destination
file. Alternatively, such e-mail can also be ignored, losing it completely.

Filtermail uses three types of files:
* The configuration file contains values of options with are generally
used (covered in the man-page's sections CONFIGURATION and OPTIONS);
* Mail filtering rules are hierarchically ordered in the rules
file: incoming mail is sequentially matched against the patterns
defined in files specified in the rules file until a match is
found. Once a match has been found the rule's action (accept, ignore
or spam) is executed, ending the filtering process;
* Each file specified in the rules file defines matching patterns, which
are tested sequentially. Testing those patterns ends once the incoming
mail matches a pattern.

In addition to the filtermail program itself a small support program 'inspect'
is part of filtermail: inspect expects a received e-mail file at its standard
input. Mail handling programs (e.g., mutt(1)) allow its users to pipe an
e-mail file to a program, inspecting the received e-mail.  Depending on the
content of the Received: headers inspect's output shows the domain name of the
sender, its IP address, its country of origin and the cidr-range containing
the received IP address. If the received e-mail is considered conspicuous
(e.g., spam or mail to ignore) then the mail's details, e.g. its cidr
range. could be added to the file recognizing spam-rated e-mail.

 - why is this package useful/relevant? 
The main reason for developing filtermail was the fact that I frequently
receive mail which is either spam or which is completely irrelevant and
annoying. Previously I used a bash-script to filter such mail, but that
script eventually was hard to maintain. A compilable program offers, IMHO,
better facilities for maintenance and modifications so I wrote
filtermail. Over the past three months it performed its job as
expected. E.g., of the about 300 e-mails I received in the category
'igored' were all correctly categorized.

  - it a dependency for another package? 
 No, it's a stand-alone program

  - do you use it? 
 Yes, I do

  - if there are other packages providing similar functionality, how does it
compare?  
 There exists a program 'mailfilter' focusing on handling pop-accounts and
 also offering ways to recognize e-mail as spam. Filtermail, on the other
 hand, uses the 'ignore' category in addition to the 'spam' category and
 primarily aims at categorizing (in various forms) incoming e-mail.

 - how do you plan to maintain it? 
 I have a long history of building and maintaining programs, many of them
 are also registered as Debian packages. I handle the maintenance of the
 programs myself, and almost all my direct contact with Debian is via Tony
 Mancill (tmanc...@debian.org) who is a Debian developer. When there's a
 new version of one of my Debian provided programs I prepare the required
 update, upload it to salsa, and send Tony an e-mail asking him to verify
 the latest update.

 Filtermail's website is at https://fbb-git.gitlab.io/filtermail/ where
 you also find links to the man-pages, to its repository, and to a list of
 programs I developed, most of them are available as Debian packages.

   - do you need a sponsor?
  If I'm correct then the 'sponsor' is a Debian maintainer who's willing to
  adopt a program for Debian. If so, then yes, I do.
  
I hope you like filtermail!

Bug#1049985: buster-pu: package riemann-c-client/1.10.4-2

[Romain Tartière]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: rom...@blogreen.org

[ Reason ]
Due to improper return value checks, when communicating with a remote
server over TLS riemann-c-client sometimes send the same data fragment
multiple times, resulting in the server receiving a malformed payload.

This happen with all versions of TLS, but TLS 1.3 trigger this bad
behaviour more often.  With more and more services using TLS 1.3, this
problem is more and more prevalent.

[ Impact ]
When the client send a large payload over TLS faster than the network
can send it, the improper return value checks cause portions of that
data to be send multiple times to the server.  When the transfer
eventually finish, the server detect that the payload is invalid and
drop the connection.  The client will then reconnect and retry the
transfer that might fail again and again.

Beside error messages in the server logs, these data corrupt data
transfer cause an unexpectedly hight bandwidth usage.

[ Tests ]
Manually tested on our infrastructure (mostly Debian oldstable).

[ Risks ]
Low

[ 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 ]
Adjust the checks of the return values of gnutls_record_send() /
gnutls_record_recv() and keep track of the quantity of data already
sent / received when the function return before completion so that it
can continue from the point it stopped the previous time.
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-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.
diff -Nru riemann-c-client-1.10.4/debian/control 
riemann-c-client-1.10.4/debian/control
--- riemann-c-client-1.10.4/debian/control  2019-01-03 07:09:15.0 
-1000
+++ riemann-c-client-1.10.4/debian/control  2023-08-13 12:08:48.0 
-1000
@@ -10,8 +10,6 @@
 Standards-Version: 4.2.1
 Section: libs
 Homepage: https://git.madhouse-project.org/algernon/riemann-c-client
-Vcs-Git:  https://git.madhouse-project.org/algernon/riemann-c-client.git -b 
debian/master
-Vcs-Browser: 
https://git.madhouse-project.org/algernon/riemann-c-client/src/branch/debian/master
 
 Package: libriemann-client0
 Architecture: any
diff -Nru riemann-c-client-1.10.4/debian/gbp.conf 
riemann-c-client-1.10.4/debian/gbp.conf
--- riemann-c-client-1.10.4/debian/gbp.conf 2019-01-03 07:08:30.0 
-1000
+++ riemann-c-client-1.10.4/debian/gbp.conf 1969-12-31 14:00:00.0 
-1000
@@ -1,7 +0,0 @@
-[DEFAULT]
-debian-branch = debian/master
-debian-tag = debian/riemann-c-client-%(version)s
-upstream-tag = riemann-c-client-%(version)s
-compression = xz
-
-postbuild = lintian -I $GBP_CHANGES_FILE && echo "Lintian OK"
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-13 12:08:48.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 = 

Bug#1049984: debuild: please export CC=gcc CXX=g++ for buildpackage instead of just clearing

[наб]

Control: retitle -1 debuild: please export CC=gcc CXX=g++ for buildpackage 
instead of just clearing
Control: reassign -1 devscripts 2.23.4

I've unduly implicated gbp in this, it looks like this is debuild's
fault ‒ it sees CC=gcc CXX=g++ in its environment, /its/ children don't;
passing "--set-envvar CC=gcc" works. Unfortunately it's non-obvious
perl, so.

Please initialise the environment with CC=gcc CXX=g++, then process it
as-usual. debuild can easily do this since (it appears that) it defines
a completely fresh environment, so initialising it thusly and letting it
get overridden with --preserve-envvar/--set-envvar/--preserve-env
is fully-compatible with already-working setups and unbreaks some which
currently need configuration.

Best,
наб


signature.asc
Description: PGP signature

Bug#1049983: panic: connection already exists

[Shengjing Zhu]

Control: severity -1 grave

On Fri, Aug 18, 2023 at 4:51 AM Yuri D'Elia  wrote:
>
> Package: syncthing
> Version: 1.19.2~ds1-2
> Severity: normal
>
> With 1.19.2~ds1-2 syncthing panis immediately on the first connection
> with the following error:
>
> | goroutine 685 [select]:
> | 
> github.com/syncthing/syncthing/lib/fs.(*BasicFilesystem).watchLoop(0xc0002ec180,
>  {0x12318d0, 0xc00066f7c0}, {0x1221680, 0x1}, {0xc00270ca00, 0x1, 0x1}, 
> 0xc0026a6480, 0xc0005f1080, ...)
> | github.com/syncthing/syncthing/lib/fs/basicfs_watch.go:81 +0x13d
> | created by github.com/syncthing/syncthing/lib/fs.(*BasicFilesystem).Watch 
> in goroutine 836
> | github.com/syncthing/syncthing/lib/fs/basicfs_watch.go:59 +0x453
> | panic: connection already exists
>
> Rolling back to 1.19.2~ds1-1+b5 and keeping everything else the same the
> problem disappears...

Thanks for the report, I'm raising the severity to prevent it
migrating to testing.

-- 
Shengjing Zhu

Bug#452721: irt: irt: Bug#452721 notes from explorations

[Elliott Mitchell]

Synthesizing things since I hadn't been copied on previous message...

On Mon Jul 31 18:10:34 BST 2023, zithro wrote:
> 
> On 31 Jul 2023 03:39, Elliott Mitchell wrote:
> 
> > Presently I hope to convince the Xen core to allow full Python in domain
> > configuration files, but no news on that front so far.  This would mean
> > /etc/default/xendomains would need to change to match Python syntax.
> 
> There was an answer today on xen-devel: the ability to use scripts in
> domU cfg files has been explicitely removed for various reasons.
> This does not prevent you from "source"-ing teh cfg files in your
> script(s) if they are proper Python syntax. Or you could simply
> parse/regex the values you want.

Though the reasons given seem orthogonal to my thinking.  I'm thinking
use libpython as the parser since that allows dictionaries and guarantees
the syntax remains a subset of Python.  Whereas the responses read like
they think I'm asking for full Python scripts as domain configurations
(which is a very large superset of what I'm proposing).

> And as Marek suggested in his answer, you can also put any arbitrary
> settings in the comments.

I had already thought of that as it is a common strategy for such things.
This though has substantial limitations and since Python has all the
capabilities needed, strategies based on Python seem very attractive.

I was thinking Perl for a bit, but Python provides a simple strategy for
extracting required information out of configurations.  Crucially the
UUID which lets you match running domains to their configuration.


> Although ...
> 
> > My thinking for adding to domain configuration files would be something
> > along these lines:
> >
> > init = {
> >   'tool': 'xendomains-ng',
> >   'version': 0,
> >   'order': 9,
> >   'startwait': 60,
> >   'stopaction': 'save',
> > }
> 
> The problem with adding this to a domU config file is that it could
> cause problems for (live) migrations. The start/stop order is "per
> dom0", and may be different on another one.
> Imagine two dom0s, one storing the domain files "locally", while the
> other uses NFS. Only in the second case the domU should wait for the NFS
> server/domain to be available.
> 
> To me, the start/stop logic should be in a dom0 config file.

I'm not understanding the situation you're thinking of.

The closest I can come is you're thinking of a situation which would be
handled by having host defaults, but also overrides in domain.cfg files.
Generic VMs would act according to the host settings, only domains which
had overridden values would act differently.

You could have a network of VM hosts where normal hosts specify 'migrate'
in /etc/default/xendomains.  Then you have the magic host which specifies
'save' or 'shutdown'.  You would also specify something other than
'migrate' for domains handling services local to a particular host.

> > 'startwait' would tell the script to wait that long before starting
> > subsquent domains.
> 
> A time-based wait may be useful for when everything goes well, but what
> about when there are problems ?
> If you want to be sure a domain is up (ie. ready to serve), you would
> need to peek at the related "service".
> For example, to be sure a DNS domU is up, you would have to try a DNS
> request, as a ping or "xl list" would not be enough.
> Also, domains in xen/auto are started with a mix of serialization AND
> parallelization, as "xl create" returns once the domain has started (ie.
> in the Xen point of view, not the user's).

Indeed.  I'm well aware what I'm suggesting has major limitations.  I'm
proposing what I consider feasible given available time.  What you're
suggesting could be a feature for v2, which might be written based on
what I manage.


> > 'stopaction' would allow different actions if the machine was to stop.
> > The 3 options which come to mind are 'stop' (shutdown), 'save' (save to
> > specified storage location), and 'migrate'.
> 
> Then, each time you do NOT want to follow the usual action, you'd have
> to edit -each- domU cfg file ?

Usually if you didn't want to follow the usual action, you would invoke
`xl` manually.

What has come to mind though is perhaps the action should be uploaded to
the xenstore.  Then when an unusual action was desired, the xenstore
information could be changed and the action would follow the domain.
This though seems a feature for a future version.


> > If full Python doesn't become available, this might take the format:
> > init = 'tool=xendomains-ng,version=0,order=9,startwait=60,stopaction=save'
> > Not needing to parse the string though does make one's life simpler.
> 
> Well, it makes -your- life easier, not the maintainers' one ;)

Given what the parser looks like, it shouldn't take much to make things
easier.  I suspect getting rid of the Bison/Flex parser and using
libpython will be easier.  Though the maintainers may disagree.

Dunno until things reach full implementation.  What I've sent so far is

Bug#1049984: git-buildpackage: please export CC=gcc CXX=g++ for buildpackage instead of just clearing

[наб]

Package: git-buildpackage
Version: 0.9.30
Severity: normal

Dear Maintainer,

git-buildpackage (or dpkg-buildpackage, or whatever) clears CC and CXX.

Cool. Except
  $ env -i make -f <(printf '%s\n' '_:' '   echo $(CC) $(CXX)')
  echo cc g++

So C++ programs are built with GCC but C programs are built with the
system C compiler. That's fine, right, no iss
 dh_dwz -a
  install -m0755 -d 
debian/systemd-cron/usr/lib/debug/.dwz/x86_64-linux-gnu
  dwz 
-mdebian/systemd-cron/usr/lib/debug/.dwz/x86_64-linux-gnu/systemd-cron.debug 
-M/usr/lib/debug/.dwz/x86_64-linux-gnu/systemd-cron.debug -- 
debian/systemd-cron/lib/systemd/system-generators/systemd-crontab-generator 
debian/systemd-cron/usr/bin/crontab 
debian/systemd-cron/usr/libexec/systemd-cron/crontab_setgid
  dwz: debian/systemd-cron/usr/libexec/systemd-cron/crontab_setgid: Unknown 
debugging section .debug_addr
  dwz: debian/systemd-cron/usr/libexec/systemd-cron/crontab_setgid: Unknown 
debugging section .debug_addr
  dh_dwz: error: dwz 
-mdebian/systemd-cron/usr/lib/debug/.dwz/x86_64-linux-gnu/systemd-cron.debug 
-M/usr/lib/debug/.dwz/x86_64-linux-gnu/systemd-cron.debug -- 
debian/systemd-cron/lib/systemd/system-generators/systemd-crontab-generator 
debian/systemd-cron/usr/bin/crontab 
debian/systemd-cron/usr/libexec/systemd-cron/crontab_setgid returned exit code 1
  dh_dwz: error: Aborting due to earlier error
  make: *** [debian/rules:16: binary] Error 25
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2
  debuild: fatal error at line 1182:
  dpkg-buildpackage -us -uc -ui -i -I -sa -d failed
  gbp:error: 'debuild -i -I -sa -d' failed: it exited with 29

Every time. Well, almost every time. Every package that builds a C
program, since dwz(1) says
> The tool handles DWARF 32-bit format debugging sections of versions 2,
> 3, 4, most of version 5 and GNU extensions on top of those.  It is
> strongly  recommended to use at least DWARF 3, but using DWARF 4 or
> higher will work much better.
> 
> While most of DWARF 5 is supported dwz doesn't yet generate spec
> compliant DWARF Supplementary Object Files (DWARF 5, section 7.3.6)
> unless the --dwarf-5 option is used. Instead of  a  .debug_sup
> section  it  will  generate  by  default  a  .gnu_debugaltlink
> section.  And  it  will  use  the  DW_FORM_GNU_strp_alt  and
> DW_FORM_GNU_reg_alt, instead of DW_FORM_strp_sup and DW_FORM_ref_sup
> to keep compatibility with existing DWARF consumers.
> 
> DWARF 4 .debug_types are supported, but DWARF 5 DW_UT_type units are
> not. Likewise .gdb_index is supported, but the DWARF 5 .debug_names is
> not. Also some forms and sections that are only emitted by GCC when
> generating Split DWARF, DW_FORM_strx and .debug_str_offsets,
> DW_FORM_addrx and .debug_addr, DW_FORM_rnglistx  and
> DW_FORM_loclistsx, are not supported yet.
(note: "using DWARF 4 or higher will work much better" while
 simultaneously "DWARF 5 [laundry list] aren't supported").

So, either, in decreasing order of meme:
  (a) have dwz actually process .debug_addr
  (b) make dwz not consider encountering .debug_addr a fatal error
  (since AIUI it's supposed to just... pre-optimise the debug
   sections? why is it fatal?)
  (c) have dh_dwz not consider dwz being broken a fatal error
  (d) have gbp-buildpackage force GCC to work around a known
  long-standing dwz bug

Setting CC CXX and then running dpkg-buildpackage works,
so option (d) is probably the least meme
(replace "unset CC CXX" with "export CC=gcc CXX=g++").

Best,
наб

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
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
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.23.4
ii  git1:2.39.2-1.1
ii  man-db 2.11.2-2
ii  python33.11.2-1+b1
ii  python3-dateutil   2.8.2-2
ii  python3-pkg-resources  66.1.1-1
ii  python3-yaml   6.0-3+b2
ii  sensible-utils 0.0.17+nmu1

Versions of packages git-buildpackage recommends:
pn  cowbuilder | pbuilder | sbuild  
ii  pristine-tar1.50
ii  python3-requests2.28.1+dfsg-1

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.13p3-1+deb12u1
ii  unzip6.0-28

-- no debconf information
Script started on 2023-08-17 23:05:36+02:00 [COMMAND="gbp buildpackage -d 
--git-verbose" TERM="st-256color" TTY="/dev/pts/2" COLUMNS="172" LINES="54"]

Bug#1049326: pandas FTBFS with numexpr 2.8.5

[Rebecca N. Palmer]

stringToExpression() in this numexpr patch needs a default of True for 
sanitize (like the others already have), because pytables calls that 
directly:


https://salsa.debian.org/science-team/pandas/-/jobs/4571451/raw

(The other failure in there is one I plan to fix.)

The two pytables tests with [] are operations that are supposed to fail 
but that now check for the wrong exception type - upstream fix:


https://github.com/PyTables/PyTables/pull/1046

Bug#1043543: autopkgtest: /usr/share/autopkgtest/lib/__pycache__ is not managed

[Antonio Terceiro]

On Sat, Aug 12, 2023 at 09:07:44PM +0200, Alexandre Detiste wrote:
> Le sam. 12 août 2023 à 20:16, Paul Gevers  a écrit :
> >
> > Call me innocent, but I'm not even seeing cache files on my system for
> > the recent python. When are these files created?
> >
> > Paul
> 
> I think I just ran autopkgtest once, as root, on this day at 2am...
> I think I should sleep more.
> 
> So they are created anytime a user with write access to
> /usr/share/autopkgtest/lib
> run autopkgtest, which means root.
> 
> dh_python3 would add the calls to py3compile/py3clean,
> but might have other side effects for your package that have to be
> backportable to oldstable(?not sure) so you might consider calling
> py3{compile/clean} directly.

I think the correct fix for this is to turn autopkgtest into a "proper"
Python package, so that we can just use dh-python instead of the custom
build system, and all of this will be taken care of.

I have thought a few times about starting this, but I haven't had the
spoons to actually do it yet.


signature.asc
Description: PGP signature

Bug#1049983: panic: connection already exists

[Yuri D'Elia]

Package: syncthing
Version: 1.19.2~ds1-2
Severity: normal

With 1.19.2~ds1-2 syncthing panis immediately on the first connection
with the following error:

| goroutine 685 [select]:
| 
github.com/syncthing/syncthing/lib/fs.(*BasicFilesystem).watchLoop(0xc0002ec180,
 {0x12318d0, 0xc00066f7c0}, {0x1221680, 0x1}, {0xc00270ca00, 0x1, 0x1}, 
0xc0026a6480, 0xc0005f1080, ...)
| github.com/syncthing/syncthing/lib/fs/basicfs_watch.go:81 +0x13d
| created by github.com/syncthing/syncthing/lib/fs.(*BasicFilesystem).Watch in 
goroutine 836
| github.com/syncthing/syncthing/lib/fs/basicfs_watch.go:59 +0x453
| panic: connection already exists

Rolling back to 1.19.2~ds1-1+b5 and keeping everything else the same the
problem disappears...

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

Kernel: Linux 6.4.0-2-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_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages syncthing depends on:
ii  init-system-helpers  1.65.2
ii  libc62.37-7

syncthing recommends no packages.

syncthing suggests no packages.

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

[Romain Tartière]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: rom...@blogreen.org

[ Reason ]
Due to improper return value checks, when communicating with a remote
server over TLS riemann-c-client sometimes send the same data fragment
multiple times, resulting in the server receiving a malformed payload.

This happen with all versions of TLS, but TLS 1.3 trigger this bad
behaviour more often.  With more and more services using TLS 1.3, this
problem is more and more prevalent.


[ Impact ]
When the client send a large payload over TLS faster than the network
can send it, the improper return value checks cause portions of that
data to be send multiple times to the server.  When the transfer
eventually finish, the server detect that the payload is invalid and
drop the connection.  The client will then reconnect and retry the
transfer that might fail again and again.

Beside error messages in the server logs, these data corrupt data
transfer cause an unexpectedly hight bandwidth usage.


[ Tests ]
Manually tested on our infrastructure (mostly Debian oldstable).


[ Risks ]
Low

[ 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 ]
Adjust the checks of the return values of gnutls_record_send() /
gnutls_record_recv() and keep track of the quantity of data already
sent / received when the function return before completion so that it
can continue from the point it stopped the previous time.
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-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.
diff -Nru riemann-c-client-1.10.4/debian/control 
riemann-c-client-1.10.4/debian/control
--- riemann-c-client-1.10.4/debian/control  2019-01-03 07:09:15.0 
-1000
+++ riemann-c-client-1.10.4/debian/control  2023-08-13 12:08:48.0 
-1000
@@ -10,8 +10,6 @@
 Standards-Version: 4.2.1
 Section: libs
 Homepage: https://git.madhouse-project.org/algernon/riemann-c-client
-Vcs-Git:  https://git.madhouse-project.org/algernon/riemann-c-client.git -b 
debian/master
-Vcs-Browser: 
https://git.madhouse-project.org/algernon/riemann-c-client/src/branch/debian/master
 
 Package: libriemann-client0
 Architecture: any
diff -Nru riemann-c-client-1.10.4/debian/gbp.conf 
riemann-c-client-1.10.4/debian/gbp.conf
--- riemann-c-client-1.10.4/debian/gbp.conf 2019-01-03 07:08:30.0 
-1000
+++ riemann-c-client-1.10.4/debian/gbp.conf 1969-12-31 14:00:00.0 
-1000
@@ -1,7 +0,0 @@
-[DEFAULT]
-debian-branch = debian/master
-debian-tag = debian/riemann-c-client-%(version)s
-upstream-tag = riemann-c-client-%(version)s
-compression = xz
-
-postbuild = lintian -I $GBP_CHANGES_FILE && echo "Lintian OK"
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-13 12:08:48.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 = 

Bug#1037682: gr-gsm: ftbfs with GCC-13

[Jonathan Bergh]

On Wed, 26 Jul 2023 15:53:15 +0200 Bastian Germann wrote:
> Control: status -1 important
>
> On Wed, 14 Jun 2023 09:25:16 + Matthias Klose wrote:
> > <<< Welcome to GNU Radio Companion Compiler 3.10.5.1 >>>
> >
> > Block paths:
> > /<>/grc
> > /usr/share/gnuradio/grc/blocks
> >
> > >>> Loading: /<>/apps/grgsm_livemon_headless.grc
> > >>> Load Error: /<>/apps/grgsm_livemon_headless.grc: Flowgraph invalid
> > **
> > 4 errors from flowgraph:
> > Param - Cell allocation(cell_allocation):
> > Value "[arfcn.downlink2arfcn(fc)]" cannot be evaluated:
> > name 'arfcn' is not definedParam - Cell allocation(cell_allocation):
>
> I cannot reproduce this. Maybe some other upload has fixed this in the
> mean time.
>
>

Likewise, I cannot reproduce this error. The issue appears to have been 
fixed in the meantime.

Bug#1040690: emacsen-common analysis for cruft files from elpa-foo packages during apt upgrade

[Nicholas D Steeves]

Richard Lewis wrote:
> David Bremner wrote:
> 
> > Richard Lewis writes:
> > > David Bremner wrote:
> > >
> >
> > As far as the actual bug with failing to clean up, I ran
> >
> > % systemd-nspawn --machine bullseye /usr/lib/dh-elpa/helper/remove emacs
> > dash 2.17.0
> >
> > and that cleans up the directory
> >
> > /usr/share/emacs/site-lisp/elpa/dash-2.17.0
> >
> > so the bug is at some other level of the stack. I guess I will have to
> > look at the log from the upgrade, but I haven't had a chance to do that
> > yet.
> >
> 
> I was trying to understand when (and how ) your command above was intended
> to be run as part of the upgrade. I cna see that in bullseye
> /usr/lib/emacsen-common/packages/remove/elpa-dash would do it if called
> with 'emacs'. but this is never called:
> 
> What happens in the 'apt upgrade' is:
> 
> the old emacsen-common prerm is called (' upgrade
> '):
> 
> /var/lib/dpkg/info/emacsen-common.prerm upgrade 3.0.5
> 
> This calls:
> /usr/lib/emacsen-common/emacs-package-remove --prerm emacsen-common
> 
> This calls:
> /usr/lib/emacsen-common/packages/remove/emacsen-common
> 
> and at the end it _unlinks_:
> /var/lib/emacsen-common/state/package/installed/emacsen-common

@1

> Then, apt prepares to unpack elpa-dash:
> 
> The elpa-dash prerm (from bullseye) is called as:
> /var/lib/dpkg/info/elpa-dash.prerm upgrade
> 2.19.1+git20220608.1.0ac1ecf+dfsg-1)
> 
> but this starts with:
> 
> if [ -e /var/lib/emacsen-common/state/package/installed/emacsen-common -a
> -x
>   /usr/lib/emacsen-common/emacs-package-remove ] ; then
> /usr/lib/emacsen-common/emacs-package-remove --prerm elpa-dash
> 
> fi
> 
> ... and so does nothing,
> because /var/lib/emacsen-common/state/package/installed/emacsen-common is
> gone.

Oh!  It's a state-related bug!  I wonder if emacsen-common (old version)
has been deinstalled at @1 (see above), or if the state is
emacsen-common (new version) is unpacked, but unconfigured, and thus
missing /var/lib/emacsen-common/state/package/installed/emacsen-common,
which is presumably created as a last step during package configuration
post-unpack?

In other words, elpa-dash (and other...most?..all? dh-elpa-using
packages) upgrades depends on having emacsen-common fully installed and
configured at @1.

I wonder if this can be solved in emacsen-common, or if it needs to be
solved in dh-elpa and then all the dh-elpa-using packages rebuilt to
generate new prerm scripts?  Which do you think would be the better
approach?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1049915: mate-terminal: background is non-transparent, settings are useless there

[an0t...@int.pl]

HiSorry about that, it's in fact more like support question. What I applied was 
installinggnome-terminal, and from that moment MATE-terminal looks perfect. 
Temat: Re: Bug#1049915: mate-terminal: background is non-transparent, settings 
are useless thereData: 2023-08-17 9:18Nadawca: "Mike Gabriel" 
sunwea...@debian.orgAdresat: "?" an0t...@int.pl; 
1049...@bugs.debian.org;  Control: close -1
 
 Hi,
 
 On  Mi 16 Aug 2023 21:14:19 CEST, ? wrote:
 
  Package: mate-terminal
  Version: 1.26.0-2
  Severity: normal
  Tags: d-i
  X-Debbugs-Cc: an0t...@int.pl
 
  Dear Maintainer,
 
  I wasn't able to see through the terminal on this distribution.
  I think there are conflicting packages in Live image Bookworm  
  gnome/mate, but dunno much really. Several installs
   from that media gives same result, I'm using 2014 Macbook if that's
 
  relevant. Thanks for reading.
 
 I got really read from your bug report what the underlying problem is.
 
 Is there something wrong with your background image? Or is your MATE  
 Terminal session's background (are you really using MATE terminal and 

 not some other terminal emulator?) not transparent, so you can't see  
 the background image through it.
 
 Note, that in MATE terminal in Debian, a transparent background is not
 
 the default setting. Please play with the terminal's settings and let 

 me know if things improve.
 
 I will close this as a bug report now as I have the impression that  
 you are rather asking a support question. Please use the debian-user  
 mailing list for this in the future.
 
 Mike
 -- 
 
 mike gabriel aka sunweaver (Debian Developer)
 mobile: +49 (1520) 1976 148
 landline: +49 (4351) 486 14 27
 
 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
 mail: sunwea...@debian.org, http://sunweavers.net
 
 

Bug#1049915: mate-terminal: background is non-transparent, settings are useless there

[an0t...@int.pl]

Oh I didn't mention, i played with settings and dconf-editor even, but no 
effect. Justinstallation of gnome-terminal made it work. Temat: Re: 
Bug#1049915: mate-terminal: background is non-transparent, settings are useless 
thereData: 2023-08-17 9:18Nadawca: "Mike Gabriel" 
sunwea...@debian.orgAdresat: "?" an0t...@int.pl; 
1049...@bugs.debian.org;  Control: close -1
 
 Hi,
 
 On  Mi 16 Aug 2023 21:14:19 CEST, ? wrote:
 
  Package: mate-terminal
  Version: 1.26.0-2
  Severity: normal
  Tags: d-i
  X-Debbugs-Cc: an0t...@int.pl
 
  Dear Maintainer,
 
  I wasn't able to see through the terminal on this distribution.
  I think there are conflicting packages in Live image Bookworm  
  gnome/mate, but dunno much really. Several installs
   from that media gives same result, I'm using 2014 Macbook if that's
 
  relevant. Thanks for reading.
 
 I got really read from your bug report what the underlying problem is.
 
 Is there something wrong with your background image? Or is your MATE  
 Terminal session's background (are you really using MATE terminal and 

 not some other terminal emulator?) not transparent, so you can't see  
 the background image through it.
 
 Note, that in MATE terminal in Debian, a transparent background is not
 
 the default setting. Please play with the terminal's settings and let 

 me know if things improve.
 
 I will close this as a bug report now as I have the impression that  
 you are rather asking a support question. Please use the debian-user  
 mailing list for this in the future.
 
 Mike
 -- 
 
 mike gabriel aka sunweaver (Debian Developer)
 mobile: +49 (1520) 1976 148
 landline: +49 (4351) 486 14 27
 
 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
 mail: sunwea...@debian.org, http://sunweavers.net
 
 

Bug#1049981: RFS: cliphist/0.4.0-1 [ITP] -- wayland clipboard manager (program)

[Ricardo Marliere]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : cliphist
   Version  : 0.4.0-1
   Upstream contact : Senan Kelly 
 * URL  : https://github.com/sentriz/cliphist
 * License  : GPL-3.0
 * Vcs  : https://salsa.debian.org/go-team/packages/cliphist
   Section  : golang

The source builds the following binary packages:

  cliphist - wayland clipboard manager (program)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cliphist/cliphist_0.4.0-1.dsc

Changes for the initial release:

 cliphist (0.4.0-1) unstable; urgency=medium
 .
   * Initial release (Closes: 1049970)

Any review is appreciated. Thank you!

Regards,

-- 
Ricardo Marlierehttps://marliere.net/
030A 8E9E 424E E3C0 6557 87E1 C90B 8A7C 6386 58A6


signature.asc
Description: PGP signature

Bug#1049980: phpsysinfo: [INTL:sv] Swedish translation of debconf messages

[Peter Kvillegård]

Package: phpsysinfo
Version: 3.4.3-1
Severity: wishlist
Tags: l10n patch
X-Debbugs-Cc: peterkvilleg...@posteo.net

Dear Maintainer,

Please copy the attachment into debian/po/sv.po
It's been reviewed by the Swedish translation team,
tested with msgfmt -c -v -o /dev/null sv.po, and is in UTF-8.

Regards,
Peter Kvillegård
# Translation of phpSysInfo debconf templates to Swedish
# Copyright (C) The phpSysInfo package copyright holder.
# This file is distributed under the same license as the phpSysInfo package.
#
# Peter Kvillegård , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: phpsysinfo 3.4.3-1\n"
"Report-Msgid-Bugs-To: phpsysi...@packages.debian.org\n"
"POT-Creation-Date: 2023-01-14 13:26+0400\n"
"PO-Revision-Date: 2023-08-16 13:19+0200\n"
"Last-Translator: Peter Kvillegård \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 3.2.2\n"

#. Type: multiselect
#. Description
#: ../templates:2001
msgid "Web server to reconfigure automatically:"
msgstr "Webbserver som ska omkonfigureras automatiskt:"

#. Type: multiselect
#. Description
#: ../templates:2001
msgid ""
"Please choose the web server that should be automatically configured to run "
"phpSysInfo."
msgstr ""
"Välj vilken webbserver som ska bli automatiskt konfigurerad att köra "
"phpSysInfo."

#. Type: boolean
#. Description
#: ../templates:3001
msgid "Do you want to restart the webservers now if needed?"
msgstr "Vill du starta om webbservrarna nu om det behövs?"

#. Type: boolean
#. Description
#: ../templates:3001
msgid ""
"Remember that in order to activate the new configuration the webservers have "
"to be restarted."
msgstr ""
"Kom ihåg att webbservrarna behöver startas om för att aktivera den nya "
"konfigurationen."

#. Type: note
#. Description
#: ../templates:4001
msgid "Configuring phpSysInfo with Nginx"
msgstr "Konfigurera phpSysInfo med Nginx"

#. Type: note
#. Description
#: ../templates:4001
msgid ""
"The phpSysInfo Nginx configuration file is a location block configuration. "
"Please add the line \"include /etc/phpsysinfo/nginx.conf;\" **inside** a "
"Nginx \"server {...}\" block. For example in '/etc/nginx/sites-enabled/"
"default'. You may need to adjust the socket path in '/etc/phpsysinfo/nginx."
"conf' to another path like '/run/php/php8.2-fpm.sock'. Be sure to restart "
"the webserver afterwards."
msgstr ""
"Nginx-konfigurationsfilen för phpSysInfo är ett block med platskonfiguration "
"(location block configuration). Lägg till raden \"include /etc/phpsysinfo/"
"nginx.conf;\" **inuti** ett \"server {...}\"-block för Nginx. Till exempel i "
"'/etc/nginx/sites-enabled/default'. Du kan behöva ändra sockelsökvägen i '/"
"etc/phpsysinfo/nginx.conf' till en annan sökväg, exempelvis '/run/php/php8.2-"
"fpm.sock'. Se till att starta om webbservern efter detta."

Bug#1049962: closed by Stefano Rivera (Re: Bug#1049962: python3-pip: Misleading error message on "pip install --user")

[Stefano Rivera]

Hi Ralf (2023.08.17_17:50:18_+)
> I still think the text and definitely the README.venv could be written in a
> less confusing way. For instance, README.venv starts out saying

Patches welcome :)

It's tricky to try to keep something short enough that people read it,
while still getting critical information across. I did my best, but...
:)

> > It is recommended to let Debian's package managers manage Python packages in
> > /usr/lib/ and /usr/share/.
> 
> So for my case ("pip install --user"), obviously this document is not
> relevant, since indeed I do want to let Debian manage the packages in /usr.
> Nothing in that file even mentions ~/.local.

That's a fair point. How's this?

https://salsa.debian.org/cpython-team/python3/-/merge_requests/31

Stefano

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

Bug#1042415: ruby-aws-partitions: Package missing partitions.json

[Max Maton]

Package: ruby-aws-partitions
Version: 1.653.0-1
Followup-For: Bug #1042415

This also occurs on bookworm. After manually creating the file I also
had to manually create partitions-metadata.json for the package to work.

-- 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-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby-aws-partitions depends on:
ii  ruby  1:3.1

ruby-aws-partitions recommends no packages.

ruby-aws-partitions suggests no packages.

-- no debconf information

Bug#1049979: nss: Please package version 3.92

[Carsten Schoenert]

Source: nss
Version: 2:3.91-1
Severity: wishlist

Hello Mike,

couly you please package the current most recent version 3.92 of nss
please?

I try to keep track of the beta versions of Thunderbird but version
117.0+ requires nss >= 3.92 to be around.

Regards
Carsten

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

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

Bug#1049863: (no subject)

[iluxa]

> https://github.com/fvwmorg/fvwm3/issues/818

I've created there comment with bug description and link to this page.

Hope they will help, as such bug in such essential applications like fvwm2/3

in stable repo -- not good sign.

Bug#1049978: lava: [INTL:sv] Swedish translation of debconf messages

[Peter Kvillegård]

Package: lava
Version: 2023.01-2
Severity: wishlist
Tags: l10n patch
X-Debbugs-Cc: peterkvilleg...@posteo.net

Dear Maintainer,

Please copy the attachment into debian/po/sv.po
It's been reviewed by the Swedish translation team,
tested with msgfmt -c -v -o /dev/null sv.po, and is in UTF-8.

Regards,
Peter Kvillegård
# Swedish translation of lava debconf messages
# Copyright (C) The lava package copyright holders
# This file is distributed under the same license as the lava-server package.
# Peter Kvillegård , 2023
#
msgid ""
msgstr ""
"Project-Id-Version: lava-server 2023.01-2\n"
"Report-Msgid-Bugs-To: lava-ser...@packages.debian.org\n"
"POT-Creation-Date: 2017-11-16 15:40+\n"
"PO-Revision-Date: 2023-08-16 17:57+0200\n"
"Last-Translator: Peter Kvillegård \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 3.2.2\n"

#. Type: boolean
#. Description
#: ../lava-server.templates:1001
msgid "Remove V1 data from database?"
msgstr "Ta bort V1-data från databasen?"

#. Type: boolean
#. Description
#: ../lava-server.templates:1001
msgid ""
"If you continue this upgrade, all V1 test data will be permanently DELETED."
msgstr ""
"Om du fortsätter med denna uppgradering så kommer alla V1-testdata bli "
"permanent BORTTAGNA."

#. Type: boolean
#. Description
#: ../lava-server.templates:1001
msgid ""
"V2 test data will not be affected. If you have remaining V1 test data that "
"you care about, make sure it is backed up before you continue here."
msgstr ""
"V2-testdata kommer inte att påverkas. Om du har V1-testdata kvar som du "
"bryr dig om, se till att de är säkerhetskopierade innan du fortsätter här."

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

[Peter Green]

Package: rust-hyper-rustls
Version: 0.23.2-4
Severity: serious

I just updated tokio-rustls to 0.24.1, hyper-rustls needs updating to 0.24.1
to match.

Bug#1043585: Update on this issue

[Martin Johnson]

Hi Salvatore,

Ah, I see what you mean for the links, its an unfortunate copy paste 
error, I apologize about the duplicated links.


For clarification, it really should have been this one:

https://bugzilla.kernel.org/show_bug.cgi?id=217796

and this:

https://bugzilla.kernel.org/show_bug.cgi?id=217799

Both are issues related to the patch which also is breaking the emulated 
TPM.


Glad that all this info is helping to get this issue resolved :-)

Kind Regards,

Martin.

On 17/08/2023 19:32, Salvatore Bonaccorso wrote:

Hi Martin,

On Thu, Aug 17, 2023 at 05:10:44PM +0100, Martin Johnson wrote:

Hi Salvadore,

Thanks for getting in contact regarding this issue,

Yes I did mean to reference the two bugzilla entries, since it seems to be
the same patch that's causing issues with the emulated TPM, at least turning
off the mitigation the same way they do fixes the problem for me also with
the swtpm function.

Still confused as the two links were the same, twice
https://bugzilla.kernel.org/show_bug.cgi?id=217796


I did try to apply "x86/retpoline: Don't clobber RFLAGS during
srso_safe_ret()" patch as suggested, unfortunately it is incompatible with
the 6.1.38 Debian kernel source:

--- I omitted some lines as there is a ton of text ---

Applying patch 0052-Linux-6.1.33-rt11-REBASE.patch
Now at patch 0052-Linux-6.1.33-rt11-REBASE.patch
make[2]: Leaving directory
'/home/martin/opt/kernel/debian_test/linux-6.1.38'
make[1]: Leaving directory
'/home/martin/opt/kernel/debian_test/linux-6.1.38'
Importing patch /home/martin/opt/kernel/debian_test/patch.patch (stored as
debian/patches/test/patch.patch)
Applying patch debian/patches/test/patch.patch
patching file arch/x86/lib/retpoline.S
Hunk #1 FAILED at 164.
Hunk #2 FAILED at 239.
Hunk #3 FAILED at 252.
3 out of 3 hunks FAILED -- rejects in file arch/x86/lib/retpoline.S
Patch debian/patches/test/patch.patch does not apply (enforce with -f)

Okay this needs adjustment for 6.1.y.

Thanks for confirming the issue beeing present as well in 6.4.11
upstream and fixed with cherry-picking the commit, this is helpful.

Regards,
Salvatore

Bug#1043539: project: Forwarding of @debian.org mails to gmail broken

[Helge Kreutzmann]

Hello Adam,
Am Thu, Aug 17, 2023 at 06:52:11PM +0100 schrieb Adam D. Barratt:
> An initial version, rewriting mails to Google-hosted domains from
> "external" e-mail addresses (those for which debian.org's mail relays
> don't consider themselves authoritative, so mostly not *.debian.org and
> *.debconf.org) is now live.
> 
> Please let DSA know if you encounter any issues.

Thanks a lot for the speedy fixing.

I'll report any issues (if any).

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1043585: Update on this issue

[Salvatore Bonaccorso]

Hi Martin,

On Thu, Aug 17, 2023 at 05:10:44PM +0100, Martin Johnson wrote:
> Hi Salvadore,
> 
> Thanks for getting in contact regarding this issue,
> 
> Yes I did mean to reference the two bugzilla entries, since it seems to be
> the same patch that's causing issues with the emulated TPM, at least turning
> off the mitigation the same way they do fixes the problem for me also with
> the swtpm function.

Still confused as the two links were the same, twice
https://bugzilla.kernel.org/show_bug.cgi?id=217796

> I did try to apply "x86/retpoline: Don't clobber RFLAGS during
> srso_safe_ret()" patch as suggested, unfortunately it is incompatible with
> the 6.1.38 Debian kernel source:
> 
> --- I omitted some lines as there is a ton of text ---
> 
> Applying patch 0052-Linux-6.1.33-rt11-REBASE.patch
> Now at patch 0052-Linux-6.1.33-rt11-REBASE.patch
> make[2]: Leaving directory
> '/home/martin/opt/kernel/debian_test/linux-6.1.38'
> make[1]: Leaving directory
> '/home/martin/opt/kernel/debian_test/linux-6.1.38'
> Importing patch /home/martin/opt/kernel/debian_test/patch.patch (stored as
> debian/patches/test/patch.patch)
> Applying patch debian/patches/test/patch.patch
> patching file arch/x86/lib/retpoline.S
> Hunk #1 FAILED at 164.
> Hunk #2 FAILED at 239.
> Hunk #3 FAILED at 252.
> 3 out of 3 hunks FAILED -- rejects in file arch/x86/lib/retpoline.S
> Patch debian/patches/test/patch.patch does not apply (enforce with -f)

Okay this needs adjustment for 6.1.y.

Thanks for confirming the issue beeing present as well in 6.4.11
upstream and fixed with cherry-picking the commit, this is helpful.

Regards,
Salvatore

Bug#1049976: lxc: fail to start /etc/init.d/lxc-net when LXC_IPV6_NAT="true"

[Rieker Flaik]

Package: lxc
Version: 1:5.0.2-1
Severity: normal
X-Debbugs-Cc: rieker_fl...@arcor.de

Dear Maintainer,

 /etc/init.d/lxc-net start

does not work when LXC_IPV6_NAT="true" is configured.

Cause of the issue: nftables masquarade rule for IPv6 is using falsely the IPv4 
syntax.

There is already an upstream fix:

https://github.com/lxc/lxc/commit/4de047f51365cc06a626ee9de49fec5f76556c66

It would be really nice if thie oneline fix could find its way into debian 
bookworm.

-- 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-11-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]1.5.82
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  iproute2 6.1.0-3
ii  iptables 1.8.9-2
ii  libapparmor1 3.0.8-3
ii  libc62.36-9+deb12u1
ii  libcap2  1:2.66-4
ii  libgcc-s112.2.0-14
ii  liblxc-common1:5.0.2-1
ii  liblxc1  1:5.0.2-1
ii  libseccomp2  2.5.4-1+b3
ii  libselinux1  3.4-1+b6
ii  lsb-base 11.6
ii  nftables 1.0.6-2+deb12u1
ii  sysvinit-utils [lsb-base]3.06-4

Versions of packages lxc recommends:
ii  apparmor   3.0.8-3
ii  debootstrap1.0.128+nmu2
ii  dirmngr2.2.40-1.1
ii  gnupg  2.2.40-1.1
ii  libpam-cgfs1:5.0.2-1
ii  lxc-templates  3.0.4.48.g4765da8-1
ii  lxcfs  5.0.3-1
ii  openssl3.0.9-1
ii  rsync  3.2.7-1
ii  uidmap 1:4.13+dfsg1-1+b1
ii  wget   1.21.3-1+b2

Versions of packages lxc suggests:
pn  btrfs-progs  
pn  lvm2 
pn  python3-lxc  

-- Configuration Files:
/etc/default/lxc-net changed [not included]
/etc/lxc/default.conf changed [not included]

-- debconf information excluded

Bug#1049975: rust-oxhttp - consider moving to rustls 0.21

[Peter Green]

Package: rust-oxhttp
Version: 0.1.6-2

It would be nice to only need a single version of rustls in Debian,
with my recent round of uploads, most of the reverse dependencies
are now moved to version 0.21, leaving oxhttp as one of the few
remaining on 0.20.

Upstream has moved in git, but have not yet made a release based
on the new version, the patch however is trivial and applies
cleanly to the Debian package. After applying the patch I was
able to succesfully build the package and run the autopkgtests.diff -Nru rust-oxhttp-0.1.6/debian/changelog rust-oxhttp-0.1.6/debian/changelog
--- rust-oxhttp-0.1.6/debian/changelog  2023-08-14 13:06:01.0 +
+++ rust-oxhttp-0.1.6/debian/changelog  2023-08-17 18:10:33.0 +
@@ -1,3 +1,10 @@
+rust-oxhttp (0.1.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch for rustls 0.21
+
+ -- Peter Michael Green   Thu, 17 Aug 2023 18:10:33 +
+
 rust-oxhttp (0.1.6-2) unstable; urgency=medium
 
   * update dh-cargo fork;
diff -Nru rust-oxhttp-0.1.6/debian/patches/0001_update_rustls.patch 
rust-oxhttp-0.1.6/debian/patches/0001_update_rustls.patch
--- rust-oxhttp-0.1.6/debian/patches/0001_update_rustls.patch   1970-01-01 
00:00:00.0 +
+++ rust-oxhttp-0.1.6/debian/patches/0001_update_rustls.patch   2023-08-17 
18:09:52.0 +
@@ -0,0 +1,32 @@
+commit 9590e31bfc7db3fe19ed2236d697abefb84f3de3
+Author: Tpt 
+Date:   Sun Jun 11 21:59:12 2023 +0200
+
+Upgrades Rustls
+
+diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
+index 4983b10..64e978f 100644
+--- a/.github/workflows/build.yml
 b/.github/workflows/build.yml
+@@ -1,6 +1,7 @@
+ name: build
+ 
+-on: [push, pull_request]
++on:
++  - pull_request
+ 
+ jobs:
+   fmt:
+diff --git a/Cargo.toml b/Cargo.toml
+index 2e4c7f0..138dc6a 100644
+--- a/Cargo.toml
 b/Cargo.toml
+@@ -17,7 +17,7 @@ httparse = "1"
+ lazy_static = "1"
+ native-tls = { version = "0.2", optional = true }
+ rayon-core = { version = "1", optional = true }
+-rustls-crate = { version = "0.20", optional = true, package = "rustls" }
++rustls-crate = { version = "0.21", optional = true, package = "rustls" }
+ rustls-native-certs = { version = "0.6", optional = true }
+ url = "2"
+ 
diff -Nru rust-oxhttp-0.1.6/debian/patches/series 
rust-oxhttp-0.1.6/debian/patches/series
--- rust-oxhttp-0.1.6/debian/patches/series 2022-06-24 19:28:17.0 
+
+++ rust-oxhttp-0.1.6/debian/patches/series 2023-08-17 18:10:18.0 
+
@@ -1 +1,2 @@
+0001_update_rustls.patch
 2001_disable_doctest.patch

Bug#1049971: qemu: support loongarch

[Yang Xiwen]

On 8/18/2023 1:34 AM, Michael Tokarev wrote:

Control: tag -1 + moreinfo

17.08.2023 19:51, Yang Xiwen пишет:

Source: qemu
Version: 1:8.0.3+dfsg-5
Severity: wishlist
X-Debbugs-Cc: forbidden...@foxmail.com

Dear Maintainer,

The upstream has supported a new arch -- loongarch[1], since 7.1. I wish
we can build qemu with this new arch support, including both a new
qemu-system package and qemu-user support.

[1]: https://www.qemu.org/docs/master/system/loongarch/virt.html


I'm not sure what do you want here.  From qemu debian/changelog:

qemu (1:7.1+dfsg-1) unstable; urgency=medium

   * add loongarch64 qemu-user and qemu-user arch

  -- Michael Tokarev   Mon, 12 Sep 2022 11:50:53 +0300

(there's a typo here ofc, should be qemu-user and qemu-system - fixing 
it now).


What else is missing?

/mjt
Sorry for wasting your time, it's my fault. I have two machines running 
different distros and forgot to check the machine I'm using. It's 
running an very old Ubuntu rather than Debian.

By the way, I found loongarch not listed in the package description.

> Description: QEMU full system emulation binaries
>  QEMU is a fast processor emulator: currently the package supports
>  ARM, CRIS, i386, M68k (ColdFire), MicroBlaze, MIPS, PowerPC, SH4,
>  SPARC and x86-64 emulation. By using dynamic translation it achieves
>  reasonable speed while being easy to port on new host CPUs.
>  .

Maybe it worth adding it to the list.
Again, sorry for submitting an invalid bug report and wasting your time.

Bug#1049962: closed by Stefano Rivera (Re: Bug#1049962: python3-pip: Misleading error message on "pip install --user")

[Ralf Jung]

I still think the text and definitely the README.venv could be written in a less 
confusing way. For instance, README.venv starts out saying



It is recommended to let Debian's package managers manage Python packages in
/usr/lib/ and /usr/share/.


So for my case ("pip install --user"), obviously this document is not relevant, 
since indeed I do want to let Debian manage the packages in /usr. Nothing in 
that file even mentions ~/.local.


; Ralf

Bug#1049974: bookworm-pu: package plasma-workspace/5.27.5-2+deb12u1

[Patrick Franz]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: plasma-worksp...@packages.debian.org, delta...@debian.org
Control: affects -1 + src:plasma-workspace

[ Reason ]
krunner (a launcher built into KDE Plasma capable of doing all
sorts of things) crashes when characters or numbers are typed
in a rapid fashion.
The bug was sadly introduced in Plasma 5.27.5, but subsequently
fixed in Plasma 5.27.6. The Debian bug report can be found under
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037557

This update backports a patch for plasma-workspace that is included
in 5.27.6 back to 5.27.5. The patch is taken directly from the
upstream project.

[ Impact ]
krunner cannot be used, in some cases hardly at all.

[ Tests ]
Both the bug submitter and myself verified that in the fixed
version of plasma-workspace krunner does not crash any more.
The bug is also solved in testing and unstable as they ship
Plasma 5.27.7.

[ Risks ]
Risks are generally low. The patch is directly from upstream and
part of subsequent releases of Plasma.

[ 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 ]
Added patch to migiate krunner crash.
diffstat for plasma-workspace-5.27.5 plasma-workspace-5.27.5

 changelog   |6 ++
 patches/krunner_crash.patch |  107 
 patches/series  |3 +
 3 files changed, 116 insertions(+)

diff -Nru plasma-workspace-5.27.5/debian/changelog 
plasma-workspace-5.27.5/debian/changelog
--- plasma-workspace-5.27.5/debian/changelog2023-05-27 18:23:46.0 
+0200
+++ plasma-workspace-5.27.5/debian/changelog2023-08-16 21:18:49.0 
+0200
@@ -1,3 +1,9 @@
+plasma-workspace (4:5.27.5-2+deb12u1) bookworm; urgency=medium
+
+  * Backport patch to fix crash in krunner (Closes: #1037557).
+
+ -- Patrick Franz   Wed, 16 Aug 2023 21:18:49 +0200
+
 plasma-workspace (4:5.27.5-2) unstable; urgency=medium
 
   * Release to unstable.
diff -Nru plasma-workspace-5.27.5/debian/patches/krunner_crash.patch 
plasma-workspace-5.27.5/debian/patches/krunner_crash.patch
--- plasma-workspace-5.27.5/debian/patches/krunner_crash.patch  1970-01-01 
01:00:00.0 +0100
+++ plasma-workspace-5.27.5/debian/patches/krunner_crash.patch  2023-08-16 
21:14:47.0 +0200
@@ -0,0 +1,107 @@
+From 9d18e0821455366c00a763252515d48741316f6c Mon Sep 17 00:00:00 2001
+From: Max Ramanouski 
+Date: Thu, 1 Jun 2023 19:05:00 +0300
+Subject: [PATCH] runners/calculator: implement thread-safety in
+ QalculateEngine::evaluate
+
+Libqalculate does not seem to support ability to run multiple computations
+that are controlled or have timeout set beeing run in the same time.
+After the timeout was introduced in QalculateEngine this led to BUG 470219,
+which happens when computations are started from multiple threads in the same 
time
+that "confuses" libqalculate computation thread which leads to crash in 
libqalculate code.
+
+To fix that we need to ensure that only one evaluation is running at single 
moment of time.
+This is done via QalculateLock class that is like QMutexLocker but for 
libqalculate.
+QalculateLock is implemented with two static mutexes. Mutex s_evalLock is used
+to ensure that only one evaluation is running at single moment.
+Mutex s_ctrlLock is used to ensure that thread that aborted evaluation will
+get to start next evaluation.
+
+BUG: 470219
+---
+ runners/calculator/qalculate_engine.cpp | 43 -
+ 1 file changed, 35 insertions(+), 8 deletions(-)
+
+diff --git a/runners/calculator/qalculate_engine.cpp 
b/runners/calculator/qalculate_engine.cpp
+index a9d0a78243..09ff75fed5 100644
+--- a/runners/calculator/qalculate_engine.cpp
 b/runners/calculator/qalculate_engine.cpp
+@@ -17,11 +17,42 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include 
+ #include 
+ #include 
+ 
++constexpr int evaluationTimeout = 1;
++
++// Synchronization lock that ensures that
++// a) only one evaluation is running at a time
++// b) abortion and preemption of evaluation is synchronized
++class QalculateLock
++{
++public:
++QalculateLock()
++{
++QMutexLocker ctrlLocker(_ctrlLock);
++CALCULATOR->abort();
++s_evalLock.lock();
++CALCULATOR->startControl(evaluationTimeout);
++}
++
++~QalculateLock()
++{
++CALCULATOR->stopControl();
++s_evalLock.unlock();
++}
++
++private:
++static QMutex s_ctrlLock;
++static QMutex s_evalLock;
++};
++
++QMutex QalculateLock::s_ctrlLock;
++QMutex QalculateLock::s_evalLock;
++
+ QAtomicInt QalculateEngine::s_counter;
+ 
+ QalculateEngine::QalculateEngine(QObject *parent)
+@@ -114,7 +145,8 @@ QString QalculateEngine::evaluate(const QString 
, bool *isApproximate
+ 

Bug#1043539: project: Forwarding of @debian.org mails to gmail broken

[Adam D. Barratt]

On Sun, 2023-08-13 at 10:57 +0100, Adam D. Barratt wrote:
> On Sat, 2023-08-12 at 23:13 +0200, Mattia Rizzolo wrote:
> > On Sat, Aug 12, 2023 at 01:41:46PM -0700, Russ Allbery wrote:
> > > The problem I suspect is with email forwarding, and specifically
> > > email
> > > forwarding to Gmail, which has recently ramped up the amount of
> > > verification it does on messages.  Because of email forwarding,
> > > Gmail sees
> > > a message purportedly from helgefjell.de but actually delivered
> > > by
> > > debian.org mail servers, and has now decided to be suspicious of
> > > that.
> > 
> > This is the exact use case that SRS was developer for, however
> > gmail's documentation does not recommend that (but the situation,
> > as
> > you noted, worsened, so I tried it in some other similar setups and
> > everything is great, so...).
> 
> They sort of recommend it now. But also not. It's complicated. [tm]
> 
> > My understanding is that several DSA members were opposed to using
> > SRS for @debian.org forwarding, but maybe it's now time?
> > 
> 
> That's essentially what's being worked on. But life, and free time,
> and
> other priorities, keep getting in the way.

An initial version, rewriting mails to Google-hosted domains from
"external" e-mail addresses (those for which debian.org's mail relays
don't consider themselves authoritative, so mostly not *.debian.org and
*.debconf.org) is now live.

Please let DSA know if you encounter any issues.

Regards,

Adam

Bug#1049973: chirp: debian/watch should be updated

[Diane Trout]

Source: chirp
Version: 1:20221106+py3-2
Severity: minor
Tags: patch

Dear Maintainer,

Hello, one of my coworkers mentioned he was using chirp but the debian version
was out of date so had to download it directly from the upstream site.

I looked at https://tracker.debian.org/pkg/chirp
and saw that there was a problem searching for a new upstream version.

I adjusted to the watch line to work with the layout I found on the upstream
providers website today.

Diane


-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable'), (110, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 9d8eb219dd2746d4046903d65a12b8e19f7e4c83 Mon Sep 17 00:00:00 2001
From: Diane Trout 
Date: Thu, 17 Aug 2023 10:35:29 -0700
Subject: [PATCH] Update debian/watch to 2023 August website layout

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

diff --git a/debian/watch b/debian/watch
index 92b1b72..fb1ec0b 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,2 @@
 version=4
-https://trac.chirp.danplanet.com/chirp_daily/LATEST/ 
chirp-daily-(\d.*).(?:tgz|tbz2|txz|tar\.(?:gz|bz2|xz))
+https://trac.chirp.danplanet.com/chirp_next/next-(\d.*)/ 
chirp-(\d.*).(?:tgz|tbz2|txz|tar\.(?:gz|bz2|xz))
-- 
2.40.1

Bug#1049863: (no subject)

[Jaimos Skriletz]

Severity: normal

I am dropping this bug to normal, since it is just a virusal issue due to
missing some an expose event causing the icons to refresh themselves.

It seems fvwm3 has a similar issue, if you want to follow up on this please
use the github issue form in fvwm3 (fvwm version 2 is no longer supported
upstream).

https://github.com/fvwmorg/fvwm3/issues/818

If you want to follow up more, you can use that issue and the fvwm3 devs
might be able to help track down the issue.

If it gets fixed in fvwm3, I will see if it is possible to backport the
fix, but as of now I can't fix this until it is fixed in fvwm3.

jaimos

Bug#1049971: qemu: support loongarch

[Michael Tokarev]

Control: tag -1 + moreinfo

17.08.2023 19:51, Yang Xiwen пишет:

Source: qemu
Version: 1:8.0.3+dfsg-5
Severity: wishlist
X-Debbugs-Cc: forbidden...@foxmail.com

Dear Maintainer,

The upstream has supported a new arch -- loongarch[1], since 7.1. I wish
we can build qemu with this new arch support, including both a new
qemu-system package and qemu-user support.

[1]: https://www.qemu.org/docs/master/system/loongarch/virt.html


I'm not sure what do you want here.  From qemu debian/changelog:

qemu (1:7.1+dfsg-1) unstable; urgency=medium

  * add loongarch64 qemu-user and qemu-user arch

 -- Michael Tokarev   Mon, 12 Sep 2022 11:50:53 +0300

(there's a typo here ofc, should be qemu-user and qemu-system - fixing it now).

What else is missing?

/mjt

Bug#1049972: rdiff-backup: "remove increments older than" exits with error when there are no increments to remove

[Santiago Vila]

Package: rdiff-backup
Version: 2.2.2-1

Dear maintainer:

As the subject says, when I try something like this:

rdiff-backup remove increments --older-than 1m /some/destination

the command exits with status 2 (indicating error), when it's the
case that there are no increments to remove.

This is a regression, as it did not use to happen in Debian 11,
where an equivalent command

rdiff-backup --remove-older-than 1m

never seemed to fail when there are no increments to remove.


Intuitively, in the spirit of "rm -f", one might think that using --force would 
help:

rdiff-backup --force remove increments --older-than 1m /some/destination

but that does not seem to be the case either.

Note: I'm not using any special severity here, but I would consider this worthy 
to be
fixed in a point release, as it breaks current scripts (I mean, even if the 
syntax
has changed, one would expect that an "equivalent" script using the new syntax
would behave the same as the old one). Maybe it does not worth an upload by 
itself,
but if this bug is going to be fixed in some point release:

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

then maybe this one could be fixed as well in the same upload (of course, if 
it's
confirmed that it's a bug and a fix is available).

Thanks.

Bug#1043153: empire-lafe: please consider upgrading to 3.0 source format

[Bastian Germann]

If you do not want to move to format 3.0, please at least specify 1.0 
format so that dpkg-source can move to default 3.0 format.

Bug#1043585: Update on this issue

[Martin Johnson]

Hi Salvatore,

As I was unfortunately not successful to apply the suggested patch to 
the Debian sources, however I since have tried to apply it to 6.4.11 
vanilla stable kernel.


That patch has applied fine, and the emulated TPM in KVM is also back 
into a working state :-)


So if you back-ported to the Debian kernel, it should hopefully fix 
things there too.


If you need me to test a patch for the back-port against the Debian 
kernel, and you can provide one, please let me know :-)


Kind Regards,

Martin.


On 17/08/2023 08:38, Salvatore Bonaccorso wrote:

Control: tags -1 + moreinfo upstream

Hi Martin,

On Wed, Aug 16, 2023 at 07:16:58PM +0100, Martin Johnson wrote:

Package: linux-image-amd64

Version: 6.1.0-11-amd64

Update of this recent issue - I might not have specified the package
correctly, sorry for that - its the first bug I tried to report on Debian -
hey Debian really is that good :-)

I found some sort of workaround too, but its far from ideal at present.

To avoid this issue you can set the kernel boot parameter:
spec_rstack_overflow=off

Then the problem no longer exists, obviously with an additional and quite
serious AMD Zen processor security issue.

So the cause is also related to the recent AMD Zen security patch.

The problem seems related to these posts on bugzilla.kernel.org, but is
manifesting in a different way for me:

https://bugzilla.kernel.org/show_bug.cgi?id=217796

and this:

https://bugzilla.kernel.org/show_bug.cgi?id=217796

Did you meant to reference here two different bugzilla enties?


Hope this information is of assistance for anyone who is lucky enough to
find this information :-)

Thanks for providing that. Would it be possible for you to test a
custom kernel built with the following commit applied on top and see
if this resolved the issue you are seeing?

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=ba5ca5e5e6a1d55923e88b4a83da452166f5560e

See
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
for instructions.

Regards,
Salvatore

Bug#1049971: qemu: support loongarch

[Yang Xiwen]

Source: qemu
Version: 1:8.0.3+dfsg-5
Severity: wishlist
X-Debbugs-Cc: forbidden...@foxmail.com

Dear Maintainer,

The upstream has supported a new arch -- loongarch[1], since 7.1. I wish
we can build qemu with this new arch support, including both a new
qemu-system package and qemu-user support.

[1]: https://www.qemu.org/docs/master/system/loongarch/virt.html

Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken

[Vincent Lefevre]

Control: retitle -1 cron-daemon-common: in /etc/crontab, run-parts is no longer 
in $PATH

That's actually the real reason.

/etc/crontab has

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

but

zira:~> dlocate =run-parts
debianutils: /bin/run-parts

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

Bug#1049970: ITP: cliphist -- wayland clipboard manager

[Ricardo Marliere]

Package: wnpp
Severity: wishlist
Owner: Ricardo Marliere 

* Package name: cliphist
  Version : 0.4.0-1
  Upstream Author : Senan Kelly
* URL : https://github.com/sentriz/cliphist
* License : GPL-3.0
  Programming Lang: Go
  Description : wayland clipboard manager
 
 cliphist
 .
 *clipboard history “manager” for wayland*
 .
  * write clipboard changes to a history file
  * recall history with **dmenu** / **rofi** / **wofi** (or whatever
other picker you like)
  * both **text** and **images** are supported
  * clipboard is preserved **byte-for-byte**
* leading / trailing whitespace / no whitespace or newlines are
preserved
* won’t break fancy editor selections like vim wordwise, linewise,
block mode
  * no concept of a picker, only pipes

I am a user of the program and would like to package it as my first
contribution to Debian.


signature.asc
Description: PGP signature

Bug#1049967: regression: kernel WARNING at arch/x86/kernel/fpu/xstate.c:973 get_xsave_addr+0x9b/0xb0

[Diederik de Haas]

Control: severity -1 normal
Control: tag -1 confirmed pending upstream
Control: merge -1 1044518

On Thursday, 17 August 2023 17:25:17 CEST Bernd Zeimetz wrote:
> Source: linux
> Version: 5.10.179-5
> Severity: important
> X-Debbugs-Cc: b.zeim...@conova.com, m.viertha...@conova.com
> 
> Hi,
> 
> since updating the bullseye kernel to 5.10.179-5, we get the following
> kernel WARNING (and so a tainted kernel) while running under vmware ESX:
> 
> [0.087938] [ cut here ]
> [0.087940] get of unsupported state
> [0.087947] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:973
> get_xsave_addr+0x9b/0xb0 [0.087948] Modules linked in:

This is the same bug as https://bugs.debian.org/1044518, thus merging

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

Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken

[Vincent Lefevre]

Package: cron-daemon-common
Version: 3.0pl1-166
Severity: serious

(set to serious because this is a regression whose effect will
be to send a spurious mail every hour)

After upgrading to 3.0pl1-166, I got a mail with


Subject: Cron  cd / && run-parts --report /etc/cron.hourly

/bin/sh: 1: run-parts: not found


This corresponds to this line in /etc/crontab:

17 ** * *   rootcd / && run-parts --report /etc/cron.hourly

And I suppose that I will get such a mail every hour.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages cron-daemon-common depends on:
ii  adduser  3.137

cron-daemon-common recommends no packages.

cron-daemon-common suggests no packages.

-- no debconf information

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

Bug#1042146: gatb-core: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file

[Étienne Mollier]

This symbol tracking issue in gatb-core seems to be an uncaught
regression on introduction of gcc-13: last upload dates back
from before change of compiler, and reverse dependencies do not
show autopkgtest regressions.  I'll update symbols files
appropriately.

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


signature.asc
Description: PGP signature

Bug#1041556: What is the architecture name in R what we call armel/armhf

[Dirk Eddelbuettel]

On 17 August 2023 at 07:24, Graham Inggs wrote:
| On Thu, 17 Aug 2023 at 05:52, Andreas Tille  wrote:
| > I tried to skip two tests in r-cran-checkmate with this patch[1]
| > which is based on
| >
| >   arch <- R.version$arch
| >   identical(arch, "i386") || identical(arch, "i686") || identical(arch, 
"armel") || identical(arch, "armhf")
| 
| Stack Overflow suggested to check .Machine$sizeof.pointer
| which will return the pointer size in bytes,
| so 8 on 64-bit and 4 on 32-bit architectures.

Seconded to detect 'word size'. Closest to an R-provided 'is it 32bit' ?

The failed logs for armhf and armel also clearly show that the value from
R.version$arch is 'arm', see

   
https://ci.debian.net/data/autopkgtest/testing/armel/r/r-cran-checkmate/36601942/log.gz

and its displayed text:

  68s R version 4.3.1 (2023-06-16) -- "Beagle Scouts"
  68s Copyright (C) 2023 The R Foundation for Statistical Computing
  68s Platform: arm-unknown-linux-gnueabi (32-bit)
^^^

That is the value returned from R.version$arch.  'arm', not 'armel' or 'armhf'. 

For completeness, the armhf run

   
https://ci.debian.net/data/autopkgtest/testing/armhf/r/r-cran-checkmate/36588004/log.gz

has

  56s R version 4.3.1 (2023-06-16) -- "Beagle Scouts"
  56s Copyright (C) 2023 The R Foundation for Statistical Computing
  56s Platform: arm-unknown-linux-gnueabihf (32-bit)

R.version$platform has the full triplet, ie 'x86_64-pc-linux-gnu' for me here.

Dirk

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

Bug#1049968: Warnings and tables not rendered with groff 1.23

[Faidon Liambotis]

Package: go-md2man
Version: 2.0.2+ds1-1
Severity: important
X-Debbugs-Cc: g.branden.robin...@gmail.com, cjwat...@debian.org
Control: forwarded -1 https://github.com/cpuguy83/go-md2man/issues/99

go-md2man generates output that is invalid and with groff 1.23:
1) does not render tables, producing these warnings:
   "warning: tbl preprocessor failed, or it or soelim was not run; table(s) 
likely not rendered (TE macro called with TW register undefined)"
2) produces "warning: cannot select font 'C'" warnings 

I bumped into this with the package crun, that I maintain. Reproducing
is as easy as trying to generate and display crun.1 from crun.1.md in
that source package.

Someone else reported this upstream as issue #99 2 days ago, and I just
responded there, but filing it against Debian as this is affecting all
of the go-md2man reverse build dependencies, and there are many.

Cc'ing G. Branden Robinson and Colin Watson who have been super helpful
in mailing lists and related bug reports dealing with the fallout of the
groff 1.23.0 upload.

For the former issue,
  https://lists.debian.org/debian-devel/2023/08/msg00220.html
seems to include the fix.

For the latter issue, which is relatively harmless, I guess an easy
workaround is to remove \fC from the generated output. #1040975
(originally against perl/pod2man) #1041809 (against rst2man), #1043256
(against zip) seem to provide some additional context and solutions.

Regards,
Faidon

Bug#1007510: tua: please consider upgrading to 3.0 source format

[Bastian Germann]

Am 17.08.23 um 14:25 schrieb Mark Brown:

Would it not be more sensible to just require that the format always be 
specified?


The problem with that is that most of the implicitly 1.0 packages are essentially unmaintained. 
Making them RC buggy intentionally by requiring an explicit format will not help but drive many 
packages out of Debian or shifts the update burden to other DDs who have enough work already.

Bug#1043585: Update on this issue

[Martin Johnson]

Hi Salvadore,

Thanks for getting in contact regarding this issue,

Yes I did mean to reference the two bugzilla entries, since it seems to 
be the same patch that's causing issues with the emulated TPM, at least 
turning off the mitigation the same way they do fixes the problem for me 
also with the swtpm function.


I did try to apply "x86/retpoline: Don't clobber RFLAGS during 
srso_safe_ret()" patch as suggested, unfortunately it is incompatible 
with the 6.1.38 Debian kernel source:


--- I omitted some lines as there is a ton of text ---

Applying patch 0052-Linux-6.1.33-rt11-REBASE.patch
Now at patch 0052-Linux-6.1.33-rt11-REBASE.patch
make[2]: Leaving directory 
'/home/martin/opt/kernel/debian_test/linux-6.1.38'
make[1]: Leaving directory 
'/home/martin/opt/kernel/debian_test/linux-6.1.38'
Importing patch /home/martin/opt/kernel/debian_test/patch.patch (stored 
as debian/patches/test/patch.patch)

Applying patch debian/patches/test/patch.patch
patching file arch/x86/lib/retpoline.S
Hunk #1 FAILED at 164.
Hunk #2 FAILED at 239.
Hunk #3 FAILED at 252.
3 out of 3 hunks FAILED -- rejects in file arch/x86/lib/retpoline.S
Patch debian/patches/test/patch.patch does not apply (enforce with -f)

Kind Regards,

Martin.


On 17/08/2023 08:38, Salvatore Bonaccorso wrote:

Control: tags -1 + moreinfo upstream

Hi Martin,

On Wed, Aug 16, 2023 at 07:16:58PM +0100, Martin Johnson wrote:

Package: linux-image-amd64

Version: 6.1.0-11-amd64

Update of this recent issue - I might not have specified the package
correctly, sorry for that - its the first bug I tried to report on Debian -
hey Debian really is that good :-)

I found some sort of workaround too, but its far from ideal at present.

To avoid this issue you can set the kernel boot parameter:
spec_rstack_overflow=off

Then the problem no longer exists, obviously with an additional and quite
serious AMD Zen processor security issue.

So the cause is also related to the recent AMD Zen security patch.

The problem seems related to these posts on bugzilla.kernel.org, but is
manifesting in a different way for me:

https://bugzilla.kernel.org/show_bug.cgi?id=217796

and this:

https://bugzilla.kernel.org/show_bug.cgi?id=217796

Did you meant to reference here two different bugzilla enties?


Hope this information is of assistance for anyone who is lucky enough to
find this information :-)

Thanks for providing that. Would it be possible for you to test a
custom kernel built with the following commit applied on top and see
if this resolved the issue you are seeing?

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=ba5ca5e5e6a1d55923e88b4a83da452166f5560e

See
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
for instructions.

Regards,
Salvatore

Bug#1049378: 1049378 Wifi not available after sleep.

[Richard Hornby]

With apologies, it appears the issue is with the Mediatek chipset on my 
device, not with the amd64 driver.


The issue is reportedly resolved here. 
 



I have never yet patched a kernel, but I guess now is the time to learn.

Best

R

Bug#1049967: regression: kernel WARNING at arch/x86/kernel/fpu/xstate.c:973 get_xsave_addr+0x9b/0xb0

[Bernd Zeimetz]

Source: linux
Version: 5.10.179-5
Severity: important
X-Debbugs-Cc: b.zeim...@conova.com, m.viertha...@conova.com

Hi,

since updating the bullseye kernel to 5.10.179-5, we get the following
kernel WARNING (and so a tainted kernel) while running under vmware ESX:

[0.087938] [ cut here ]
[0.087940] get of unsupported state
[0.087947] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:973 
get_xsave_addr+0x9b/0xb0
[0.087948] Modules linked in:
[0.087952] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-24-amd64 #1 
Debian 5.10.179-5
[0.087953] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 11/12/2020
[0.087954] RIP: 0010:get_xsave_addr+0x9b/0xb0
[0.087956] Code: 48 83 c4 08 5b e9 15 80 bc 00 80 3d 8d 7c 80 01 00 75 a8 
48 c7 c7 97 de cb 99 89 74 24 04 c6 05 79 7c 80 01 01 e8 f5 96 88 00 <0f> 0b 8b 
74 24 04 eb 89 31 c0 e9 e6 7f bc 00 66 0f 1f 44 00 00 89
[0.087957] RSP: :9a203ec8 EFLAGS: 00010282
[0.087958] RAX:  RBX: 9a46a600 RCX: 8b635fdfffa8
[0.087959] RDX: c0007fff RSI: 7fff RDI: 0247
[0.087960] RBP: 9a46a4a0 R08:  R09: 9a203ce8
[0.087960] R10: 9a203ce0 R11: 8b637fec18a8 R12: 0246
[0.087961] R13:  R14:  R15: 
[0.087962] FS:  () GS:8b635fe0() 
knlGS:
[0.087962] CS:  0010 DS:  ES:  CR0: 80050033
[0.087963] CR2: 8b5d8d602000 CR3: 0001cbc0a001 CR4: 007300b0
[0.087977] Call Trace:
[0.087982]  identify_cpu+0x51f/0x540
[0.087985]  identify_boot_cpu+0xc/0x94
[0.087986]  arch_cpu_finalize_init+0x5/0x47
[0.087988]  start_kernel+0x4ec/0x599
[0.087991]  secondary_startup_64_no_verify+0xb0/0xbb
[0.087993] ---[ end trace 8ac8962c4c9dda0c ]---


This sounds like the issue described in
https://lore.kernel.org/lkml/2023081511-easing-exerciser-c356@gregkh/

Could you please follow up and include the fix in case its not in the
next kernel pointrelease?

Thanks,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1007510: tua: please consider upgrading to 3.0 source format

[Mark Brown]

On Thu, Aug 17, 2023 at 04:34:56PM +0200, Bastian Germann wrote:
> Am 17.08.23 um 14:25 schrieb Mark Brown:

> > Would it not be more sensible to just require that the format always be 
> > specified?

> The problem with that is that most of the implicitly 1.0 packages are
> essentially unmaintained. Making them RC buggy intentionally by requiring an
> explicit format will not help but drive many packages out of Debian or
> shifts the update burden to other DDs who have enough work already.

Right, but I'm just generally unclear what the upside is from changing
the default at all.  Changing the default under packages is also going
to make them rc buggy.


signature.asc
Description: PGP signature

Bug#1049966: reportbug: Mouse buttons mapping under Wayland

[Michal Byrecki]

Package: reportbug
Version: 12.0.0
Severity: normal

The distro I'm using is a Bookworm, I have a problem to report with
Wayland/Gnome mouse input processing.
I have had a following input setup:
- regular, wired mouse, and
- wireless mouse+keyboard "Rapoo" model E1050
Since I've detach the wired mouse, the wireless one is not recognizing the
right button.
This is not the electrical mouse-related issue, that's for sure: when I enter
the mouse settings I am able to assing the primary mouse button to either left
one or a right one. When it is assigned to:
- the left one: the left one is working as expected, the right click makes no
action
- the right one: the both - left & right buttons call the right-click menu
I can dig a bit more, but I am clueless which package process the Wayland input
signals (and therefore I haven't report the problem to any specific one).
Brgds
Mike


-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/byrek/.reportbugrc:
reportbug_version "12.0.0"
mode standard
ui gtk
realname "Michal Byrecki"
email "michal.byre...@techniline.com"
smtphost "mail.techniline.com"
smtpuser "byrek"
smtptls

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

Kernel: Linux 5.13.0zeta (SMP w/20 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 reportbug depends on:
ii  apt2.6.1
ii  python33.11.2-1+b1
ii  python3-reportbug  12.0.0
ii  sensible-utils 0.0.17+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf1.5.82
pn  debsums
pn  dlocate
pn  emacs-bin-common   
ii  exim4-daemon-light [mail-transport-agent]  4.96-15+deb12u1
ii  file   1:5.44-3
ii  gnupg  2.2.40-1.1
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.6.1
ii  file   1:5.44-3
ii  python33.11.2-1+b1
ii  python3-apt2.6.0
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.1
ii  python3-requests   2.28.1+dfsg-1
ii  sensible-utils 0.0.17+nmu1

python3-reportbug suggests no packages.

-- no debconf information

Bug#1043297: src:dynarmic: fails to migrate to testing for too long: unresolved RC issue

[Andrea Pappacoda]

On Tue, 8 Aug 2023 20:28:16 +0200 Paul Gevers  wrote:
> Source: dynarmic
> Version: 6.4.5+ds-1
> Severity: serious
> Control: close -1 6.4.8+ds-2
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> Control: block -1 by 1041270
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing 
> and unstable for more than 30 days as having a Release Critical bug in 
> testing [1]. Your package src:dynarmic has been trying to migrate for 33 
> days [2]. Hence, I am filing this bug. The version in unstable has an 
> unresolved RC issue as reported in bug 1041270.
> 
> If a package is out of sync between unstable and testing for a longer 
> period, this usually means that bugs in the package in testing cannot be 
> fixed via unstable. Additionally, blocked packages can have impact on 
> other packages, which makes preparing for the release more difficult. 
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that 
> hamper the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new 
> bugs, there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if 
> that version or a later version migrates, this bug will no longer affect 
> testing. I have also tagged this bug to only affect sid and trixie, so 
> it doesn't affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to 
> issues beyond your control, don't hesitate to contact the Release Team.

Hi, I have fixed this issue a while ago, and uploaded the fixed package to 
Mentors since it consists in a SONAME bump and I cannot upload it myself.

If you could please upload the package for me, it'd be really nice. There's not 
much to review anyway. You can find it on 
.

Sorry for the possibly broken reply, I'm on my phone.

Thanks!

Bug#1049922: libslirp-dev: Ship a static library in libslirp-dev

[Athos Ribeiro]

On Thu, Aug 17, 2023 at 10:50:31AM +0300, Michael Tokarev wrote:

17.08.2023 02:23, Athos Ribeiro wrote:


There is also this thread in the qemu-devel mailing list which may be
relevant:
https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg01044.html


I know all these libs can be built in static libfoo.a variant, the build
system allows that.  The question is how much time/energy we want to
push there to maintain that stuff, wrt how much sense it makes.


I see.




Despite the size, are there any other downsides on supporting this here
which I am not seeing?


At the very least, it will fail in exactly the same way with other libs
(libspice-server).

It's been this way for quite some years.

For some commonly used libs shipping static variant makes sense.  Even for
libglib (which is used by qemu-user-static in static form!) shipping
a static library is questionable, because, well, libglib isn't designed
to be used as a static lib!  Notice the qemu-user-static build log: at
the link stage there's a warning about getpwent_r being problematic in
static link, - but qemu linux-user does not use getpwent! - this is because
there's a single file in glib, something-utils.c, which has numerous
"commonly used" functions, with g_gethomedir() (I don't remember the exact
name) among them. qemu linux-user uses something else from that file, and
whole thing gets linked into the binary, including getpwent and other stuff.
This should be split into separate .c files for it to work, right now it
is a big waste (incl. RAM when running qemu-user).  But since we need
qemu-user-static, we have to ship static variant of libglib, despite it
being not a thing to begin with (it is just the common build system which
allows building libfoo.a too).


Thanks for the explanation and thorough reply, Michael.  I suppose I
will request/wait for more input from the reporter regarding
https://bugs.launchpad.net/debian/+source/libslirp/+bug/2029431/comments/3


https://salsa.debian.org/qemu-team/libslirp/-/merge_requests/2


This MR lacks code which will grab the resulting libslirp.a so build will fail.
It's trivial to build a static library in addition to regular shared. But I
really want to understand the reasoning.


There is an entry in debian/libslirp-dev.install installing the static
library which should be enough, shouldn't it?


Yeah, it is exactly what's missing.


FWIW, it is there:
https://salsa.debian.org/qemu-team/libslirp/-/merge_requests/2/diffs#62c82f62d2982134f9103384374819b97e418bca_4_4

--
Athos Ribeiro

Bug#1049965: nmu: freebayes_1.3.6-2

[Michael R. Crusoe]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: freeba...@packages.debian.org, cru...@debian.org
Control: affects -1 + src:freebayes

nmu freebayes_1.3.6-2 . ANY . unstable . -m "rebuild using libvcflib 
1.0.9+dfsg1-2"

Bug#1007510: tua: please consider upgrading to 3.0 source format

[Mark Brown]

On Wed, Aug 16, 2023 at 04:51:44PM +0200, Bastian Germann wrote:
> Am 16.08.23 um 16:40 schrieb Mark Brown:
> > On Wed, Aug 16, 2023 at 04:33:40PM +0200, Bastian Germann wrote:

> > > If you do not want to move to format 3.0, please at least specify 1.0 
> > > format
> > > so that dpkg-source can move to default 3.0 format.

> > If you're forcing people to specify the format why does the default
> > matter?

> I am not forcing anybody. Think about this: If every implicit 1.0 package
> that has upstream changes on its program makes the version explicit, every
> implicitly 1.0 packages that does not have an upstream diff can still be
> built with 3.0 semantics.

> The total 1.0 packages are ~450 but if ~140 of them added a
> debian/source/format with 1.0, the defaut could be moved.

Would it not be more sensible to just require that the format always be
specified?  If the format isn't changed again it makes no difference, if
the format is changed then we would just be in the same position over
again.


signature.asc
Description: PGP signature

Bug#1043589: Patch available

[Alexander V. Makartsev]

Patch for this bug.

--
With kindest regards, Alexander.--- a/gtk/gtkpkglist.cc
+++ b/gtk/gtkpkglist.cc
@@ -427,9 +427,9 @@
 	g_value_set_string(value, str);
 	 break;
   case COMPONENT_COLUMN:
-	 str = pkg->component().c_str();
-	 if(str)
-	g_value_set_string(value, str);
+ cppstr = pkg->component();
+	 if(cppstr.c_str() != NULL)
+	g_value_set_string(value, cppstr.c_str());
 	 break;
   case INSTALLED_VERSION_COLUMN:
  str = pkg->installedVersion();

Bug#1043217: netmaze: please consider upgrading to 3.0 source format

[John Goerzen]

On Thu, Aug 17 2023, Bastian Germann wrote:

> Hi John,
>
> Am 17.08.23 um 02:54 schrieb John Goerzen:
>> Is there a way to remove from delayed?
>
> Yes. I will do so. If you don't mind, I will add an explicit 1.0 format.

Sure, that is fine.

Incidentally, I got this:

DELAYED/2-day/netmaze_0.81+jpg0.82-16.2_source.changes is already present on 
target host:
10-day/netmaze_0.81+jpg0.82-16.2_source.buildinfo
Either you already uploaded it, or someone else came first.
Job netmaze_0.81+jpg0.82-16.2_source.changes removed.

Maybe the upload for the explicit 1.0 format tried to go in to 2-day but
got rejected?  Not quite sure.

- John

Bug#1049964: Crontab should include /bin and /sbin in path

[Klaus Ethgen]

Package: cron-daemon-common
Version: 3.0pl1-165
Severity: normal

Crontab is using run-parts, which is in /bin. There are many other tools
which are in /bin and /sbin (see parallel bug report about /sbin) which
are needed for daily cron usage. As crontab of new installs has the path
set to "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin", this is
not working correctly anymore. (Although old installations work if you
never overwrite /etc/crontab.)

-- System Information:
Debian Release: trixie/sid
  APT prefers experimental
  APT policy: (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.38 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, 
TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cron-daemon-common depends on:
ii  adduser  3.137

cron-daemon-common recommends no packages.

cron-daemon-common suggests no packages.

-- no debconf information

-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

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

[Raphael Hertzog]

Hello Ralf,

Le samedi 15 juillet 2023, Ralf Treinen a écrit :
> In fact it is not related to dose-distcheck being outdated on quantz, I
> get the same error with dose-distcheck on sid.
> 
> Since I do not have time to dig further into this atm (leaving for vacation)
> I have now desactivated the unstable_main scenario, which is the only
> one where the error is occurring.

That scenario seems to be the one that tracker.debian.org relies on
to provide "debcheck" information. I have been getting failures in tracker
cron tasks:
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: 
https://qa.debian.org/dose/debcheck/unstable_main/latest/each.txt

It would be nice if it could be revived. :) Do you have an idea when you
will be able to dig further? 

Cheers,
-- 
Raphaël Hertzog

Bug#1049963: python3.11: Please add support for loongarch

[zhangdandan]

Package: python3.11
Version: 3.11.4
Severity: wishlist
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear maintainers,

    The LoongArch architecture has been supported in python upstream[1].
And, we submitted pull request under the Debian python3 project[2].
Please add support for the LoongArch architecture in python3.11 or newer 
source package.

If you have any questions, you can contact me at any time.

[1]:https://github.com/python/cpython/blob/main/configure.ac
[2]:https://salsa.debian.org/cpython-team/python3/-/merge_requests/30

thanks,
Dandan Zhang

Bug#882374: ITP: python-fpdf2

[Elena ``of Valhalla'']

After talking with Ondrej Tuma in private we've agreed that I will
package this under the Python Team.

Some work has already been started, at:

https://salsa.debian.org/python-team/packages/fpdf2
-- 
Elena ``of Valhalla''

Bug#1043217: netmaze: please consider upgrading to 3.0 source format

[Bastian Germann]

Okay, here is the new debdiff.diff -u netmaze-0.81+jpg0.82/debian/changelog 
netmaze-0.81+jpg0.82/debian/changelog
--- netmaze-0.81+jpg0.82/debian/changelog
+++ netmaze-0.81+jpg0.82/debian/changelog
@@ -1,3 +1,10 @@
+netmaze (0.81+jpg0.82-16.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Make source format 1.0 explicit.  See #1043217.
+
+ -- Bastian Germann   Thu, 17 Aug 2023 13:27:05 +0200
+
 netmaze (0.81+jpg0.82-16.1) unstable; urgency=medium
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- netmaze-0.81+jpg0.82.orig/debian/source/format
+++ netmaze-0.81+jpg0.82/debian/source/format
@@ -0,0 +1 @@
+1.0

Bug#1049962: python3-pip: Misleading error message on "pip install --user"

[Ralf Jung]

Package: python3-pip
Version: 23.2+dfsg-1
Severity: normal

Dear Maintainer,

When I try to install something to my user directory, I get a confusing error 
message:

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.

If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.

See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation 
or OS distribution provider. You can override this, at the risk of breaking 
your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

This is confusing because the error, and the README.venv file, all talk about 
system-wide installation (in /usr). But I am not trying to do a system-wide 
installation!
I just want a user-wide installation. Somehow that leads to the same error 
message though.

Kind regards,
Ralf

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

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

Versions of packages python3-pip depends on:
ii  ca-certificates 20230311
ii  python3 3.11.4-5
ii  python3-distutils   3.11.4-1
ii  python3-setuptools  68.0.0-1
ii  python3-wheel   0.38.4-2

Versions of packages python3-pip recommends:
ii  build-essential  12.10
ii  python3-dev  3.11.4-5

python3-pip suggests no packages.

-- no debconf information

Bug#1049961: ITP: composable-kernel -- library for writing performance critical kernels for ML workloads

[Christian Kastner]

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

* Package name: composable-kernel
  Version : 0+git20230816
  Upstream Author : Advanced Micro Devices, Inc.
* URL : https://github.com/ROCmSoftwarePlatform/composable_kernel
* License : MIT
  Programming Lang: C++
  Description : library for writing performance critical kernels for ML 
workloads

Composable Kernel (CK) library aims to provide a programming model for
writing performance critical kernels for machine learning workloads
across multiple architectures including GPUs, CPUs, etc, through general
purpose kernel languages, like HIP C++.

CK utilizes two concepts to achieve performance portability and code
maintainability:

 * A tile-based programming model
 * Algorithm complexity reduction for complex ML operators, using
   innovative technique we call "Tensor Coordinate Transformation".

This is needed by MIOpen, which is also in the process of being
packaged.

This will be maintained by the Debian ROCm Team.

Bug#1049960: ITP: half -- C++ library for half precision floating point arithmetics

[Christian Kastner]

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

* Package name: half
  Version : 2.2.0
  Upstream Author : Christian Rau
* URL : https://sourceforge.net/projects/half/
* License : MIT
  Programming Lang: C++
  Description : C++ library for half precision floating point arithmetics

This is a C++ header-only library to provide an IEEE-754 conformant
half-precision floating point type along with corresponding arithmetic
operators, type conversions and common mathematical functions. It aims
for both efficiency and ease of use, trying to accurately mimic the
behaviour of the builtin floating point types at the best performance
possible. It automatically uses and provides C++11 features when
possible, but stays completely C++98-compatible when neccessary.

This is needed by MIOpen, which is also in the process of being
packaged.

This will be maintained by the Debian ROCm Team.

Bug#1031878: --fail-on warnings fails overrides even though --fail-on overrides is not specified

[Philipp Huebner]

Hi,

today I ran into the same issue on Bookworm.

What was strange though: some packages hit this bug, others did not.

Turns out it is related to "automatic" overrides being present or not.
A python package of mine had automatic overrides for
"package-contains-documentation-outside-usr-share-doc 
[usr/lib/python3/dist-packages/PackageName-Version.egg-info*]"


The --show-overrides option (hitting #1019690 here) said:
"N: masked by screen python/egg/metadata"

After adding explicit overrides in the package the --fail-on function 
worked correctly again and I got exit code 0 instead of 2.



Hope this helps!

Best wishes
--
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-


OpenPGP_0xE5CA8C4925E4205F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019690: lintian: Exit code = 2 when using --show-overrides with overriden lintian error

[Philipp Huebner]

FWIW, I can reproduce and thus confirm this.

Regards
--
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-


OpenPGP_0xE5CA8C4925E4205F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037029: spyder: Saving files window does not respect current active Gnome dark mode

[Julian Gilbey]

On Thu, Jun 01, 2023 at 09:44:42PM -0400, zezamoral wrote:
> Package: spyder
> Version: 5.4.2+ds-5
> Severity: minor
> X-Debbugs-Cc: sazamor...@gmail.com

Hi zezamoral,

Thanks for this report, and sorry for the slow response.

> Dear Maintainer,
> 
>* What led up to the situation?
> Saving files with gnome dark mode enabled
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Saving a new file/project from the IDE.
> 
>* What was the outcome of this action?
> White window dialog during a gnome dark mode session
> 
>* What outcome did you expect instead?
> Dark theme window when saving a file in gnome dark mode enabled

I don't personally use gnome, but I've just tried this in XFCE4 with a
dark theme and the latest Spyder version in testing (5.4.4+ds-1), and
the saving file window was dark.  Would you be able to try this again
with the new version of Spyder and let me know if the broken behaviour
still happens?

Best wishes,

   Julian

Bug#1049959: debian-edu-router-config: [INTL:sv] Swedish translation of debconf messages

[Peter Kvillegård]

Package: debian-edu-router-config
Version: 2.12.7
Severity: wishlist
Tags: l10n patch
X-Debbugs-Cc: peterkvilleg...@posteo.net

Dear Maintainer,

Please copy the attachment into debian/po/sv.po
It's been reviewed by the Swedish translation team,
tested with msgfmt -c -v -o /dev/null sv.po, and is in UTF-8.

Regards,
Peter Kvillegård
# Swedish translation of debian-edu-router debconf messages
# Copyright (C) 2023 The debian-edu-routers copyright holders.
# This file is distributed under the same license as the debian-edu-router 
package.
# Peter Kvillegård , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: debian-edu-router 2.12.7\n"
"Report-Msgid-Bugs-To: debian-edu-rou...@packages.debian.org\n"
"POT-Creation-Date: 2023-04-09 21:17+0200\n"
"PO-Revision-Date: 2023-08-12 17:49+0200\n"
"Last-Translator: Peter Kvillegård \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 3.2.2\n"

#. Type: boolean
#. Description
#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:2001
#: ../debian-edu-router-config.templates:3001
msgid "Do you want to skip Debian Edu Router networking configuration?"
msgstr "Vill du hoppa över nätverkskonfiguration av Debian Edu Router?"

#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:2001
msgid ""
"ERROR: Not enough usable network interfaces available for setting up the "
"router!"
msgstr ""
"FEL: För få användbara nätverksgränssnitt tillgängliga för att ställa in "
"routern!"

#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:3001
msgid ""
"ERROR: Not enough unconfigured network interfaces available for setting up "
"the router!"
msgstr ""
"FEL: För få okonfigurerade nätverksgränssnitt tillgängliga för att ställa in "
"routern!"

#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:3001
msgid ""
"The following interfaces were found already configured in files not managed "
"by Debian Edu Router:"
msgstr ""
"Följande gränssnitt hittades redan konfigurerade i filer som inte hanteras av "
"Debian Edu Router:"

#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:3001
msgid "${non_d_e_r_ifaces}"
msgstr "${non_d_e_r_ifaces}"

#. Type: boolean
#. Description
#: ../debian-edu-router-config.templates:3001
msgid "Please consider unconfiguring these interfaces and re-try again."
msgstr "Överväg att avkonfigurera dessa gränssnitt och försök igen."

#. Type: error
#. Description
#: ../debian-edu-router-config.templates:4001
msgid "Please plug a cable into the 'Uplink' interface."
msgstr "Koppla in en kabel i upplänkgränssnittet ('Uplink')."

#. Type: error
#. Description
#: ../debian-edu-router-config.templates:4001
msgid ""
"NOTE: For the requested step-by-step setup, please start with all network "
"cables disconnected except for the external 'Uplink' interface."
msgstr ""
"NOTERA: För den begärda steg-för-steg-inställningen, börja med alla "
"nätverkskablar urkopplade bortsett från det externa upplänkgränssnittet."

#. Type: error
#. Description
#: ../debian-edu-router-config.templates:4001
msgid ""
"You have ${num_tries} try left to unplug all network cables (except 'Uplink') "
"until the step-by-step setup will be aborted."
msgstr ""
"Du har ${num_tries} försök kvar att koppla ur alla nätverkskablar (förutom "
"upplänk) innan steg-för-steg-inställningen avbryts."

#. Type: error
#. Description
#: ../debian-edu-router-config.templates:5001
msgid "Network cables still plugged in or no 'Uplink' interface"
msgstr "Nätverkskablar fortfarande inkopplade eller inget upplänkgränssnitt"

#. Type: error
#. Description
#: ../debian-edu-router-config.templates:5001
msgid ""
"ERROR: The networking cables were not unplugged and/or an 'Uplink' interface "
"could not be determined. Please try again."
msgstr ""
"FEL: Nätverkskablarna har inte kopplats ur och/eller ett upplänkgränssnitt "
"kunde inte avgöras. Försök igen."

#. Type: select
#. Choices
#: ../debian-edu-router-config.templates:6001
msgid "Yes"
msgstr "Ja"

#. Type: select
#. Choices
#: ../debian-edu-router-config.templates:6001
msgid "Abort"
msgstr "Avbryt"

#. Type: select
#. Description
#: ../debian-edu-router-config.templates:6002
msgid "Do you want to enable IP packet forwarding?"
msgstr "Vill du aktivera vidarebefordran av IP-paket?"

#. Type: select
#. Description
#: ../debian-edu-router-config.templates:6002
msgid ""
"The routing part of 'Debian Edu Router' requires IP packets to be forwarded "
"back and forth between network interfaces by the kernel. This is mandatory "
"and without it the router simply won't work. If you select 'Abort' this "
"package will be left unconfigured. To undo its half-installed state, remove/"
"purge it again."
msgstr ""
"Den dirigerande delen av 'Debian Edu Router' kräver att IP-paket "
"vidarebefordras fram och tillbaka mellan 

Bug#1049958: coccinelle: FTBFS on armhf - Fatal error: out of memory

[Emanuele Rocca]

Source: coccinelle
Version: 1.1.1.deb-3
Severity: serious
Tags: sid ftbfs
User: debian-...@lists.debian.org
Usertags: armhf

Hi,

coccinelle fails to build from source on armhf with a "out of memory"
error.

(1) The error seems to be a red herring given that the machine on
which I'm building the package has 32G of memory, of which only about 4G
are in use when the build fails.

(2) On armel the package builds correctly.

OCAMLOPT  engine/ctlcocci_integration.ml
OCAMLOPT  -o engine/engine.cmxa
Fatal error: out of memory
Aborted
make[1]: *** [Makefile:423: parsing_cocci/parser_cocci_menhir.cmx] Error 134
make[1]: Leaving directory '/<>'
dh_auto_build: error: make -j8 returned exit code 2
make: *** [debian/rules:24: binary-arch] Error 25

Bug#1049942: PHP warnings and errors

[Mike Gabriel]

On  Do 17 Aug 2023 09:35:21 CEST, Guido Berhoerster wrote:

Aug 17 07:40:20 tjener.intern apache2[47186]: GOsa[server-admin]:  
(debug) /usr/share/gosa/include/class_acl.inc of type all : Type:2,  
Message:Array to string conversion,  
File:/usr/share/gosa/include/class_acl.inc, Line: 180
Aug 17 07:40:20 tjener.intern apache2[47186]: GOsa[server-admin]:  
(debug) /usr/share/gosa/include/class_acl.inc of type all : Type:2,  
Message:Undefined property: acl::$Array,  
File:/usr/share/gosa/include/class_acl.inc, Line: 180
Aug 17 07:40:20 tjener.intern apache2[47186]: GOsa[server-admin]:  
(debug) /usr/share/gosa/include/class_acl.inc of type all : Type:2,  
Message:Undefined variable $oc,  
File:/usr/share/gosa/include/class_acl.inc, Line: 218
Aug 17 07:40:20 tjener.intern apache2[47186]: GOsa[server-admin]:  
(debug) /usr/share/gosa/include/class_acl.inc of type all : Type:2,  
Message:Undefined variable $oc,  
File:/usr/share/gosa/include/class_acl.inc, Line: 224


All class_acl.inc related issues will be addressed via #1049940, so  
ignoring the above errors/warnings for fixing this bug report.


Mike
--

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

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



pgpweVi96VoJD.pgp
Description: Digitale PGP-Signatur

Bug#1049957: mailman3: does not work with importlib_resources v6

[Matthias Urlichs]

Package: mailman3
Version: 3.3.8
Severity: normal
X-Debbugs-Cc: sm...@smurf.noris.de


# mailman 
Traceback (most recent call last):
  File "/usr/bin/mailman", line 33, in 
sys.exit(load_entry_point('mailman==3.3.8', 'console_scripts', 'mailman')())
 
  [...]
  File "/usr/lib/python3/dist-packages/mailman/config/config.py", line 27, in 

from importlib_resources import path, read_text
ImportError: cannot import name 'path' from 'importlib_resources' 
(/usr/lib/python3/dist-packages/importlib_resources/__init__.py)
#

Please add a "Breaks:" header for importlib-resource >= 6. Alternately,
Upstream (unreleased) contains two patches to src/mailman/utilities/i18n.py
which fix this and allow depending on importlib-resource 6+.

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

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

Versions of packages mailman3 depends on:
pn  cron  
pn  dbconfig-sqlite3 | dbconfig-pgsql | dbconfig-mysql | dbconfi  
g-no-thanks
ii  debconf [debconf-2.0] 1.5.82
ii  init-system-helpers   1.65.2
ii  logrotate 3.21.0-1
ii  lsb-base  11.6
ii  python3   3.11.2-1+b1
pn  python3-aiosmtpd  
ii  python3-alembic   1.8.1-2
pn  python3-authheaders   
pn  python3-authres   
ii  python3-click 8.1.3-2
ii  python3-dateutil  2.8.2-2
pn  python3-dnspython 
pn  python3-falcon
pn  python3-flufl.bounce  
pn  python3-flufl.i18n
pn  python3-flufl.lock
pn  python3-gunicorn  
pn  python3-importlib-resources   
pn  python3-lazr.config   
ii  python3-passlib   1.7.4-3
ii  python3-psycopg2  2.9.5-1+b1
pn  python3-public
ii  python3-requests  2.28.1+dfsg-1
ii  python3-sqlalchemy1.4.46+ds1-1
pn  python3-zope.component
pn  python3-zope.configuration
pn  python3-zope.event
ii  python3-zope.interface5.5.2-1+b1
ii  systemd-cron [cron-daemon]1.15.19-5
ii  sysvinit-utils [lsb-base] 3.06-4
ii  ucf   3.0043+nmu1

Versions of packages mailman3 recommends:
ii  nullmailer [mail-transport-agent]  1:2.2-4

Versions of packages mailman3 suggests:
ii  chromium [www-browser]   114.0.5735.198-1~deb12u1
ii  epiphany-browser [www-browser]   43.1-1
ii  firefox [www-browser]115.0.2-1
ii  links [www-browser]  2.28-1+b2
ii  lynx [www-browser]   2.9.0dev.12-1
pn  mailman3-doc 
ii  mysql-server-8.0 [virtual-mysql-server]  8.0.34-1
ii  postgresql   15+248
ii  systemd-cron [anacron]   1.15.19-5

Bug#1049942: PHP warnings and errors

[Mike Gabriel]

Control: clone -1 -2
Control: retitle -2 Accessing static property LDAP::$cid as non static
Control: severity -2 serious

Hi Guido,

I will split out various of the error messages (i.e. those that I  
considered important to be fixed in bookworm).


On  Do 17 Aug 2023 09:35:21 CEST, Guido Berhoerster wrote:

Aug 17 07:40:20 tjener.intern apache2[47186]: GOsa[unauthenticated]:  
(debug) /usr/share/gosa/include/class_config.inc of type all :  
Type:8, Message:Accessing static property LDAP::$cid as non static,  
File:/usr/share/gosa/include/class_config.inc, Line: 362


This messages comes with every click in GOsa², in spams the syslog /  
journal and needs fixing in bookworm.


Mike



--

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

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



pgpVJ1Gzfqwm1.pgp
Description: Digitale PGP-Signatur

Bug#1022221: adwaita-icon-theme: Legacy appointment icon overrides new icon

[Julian]

Hello,

Those were indeed the icons I was referring to.

It appears that in the latest experimental version of the 
adwaita-icon-theme package, the legacy icons have been removed. 
https://tracker.debian.org/news/1453258/accepted-adwaita-icon-theme-440-1-source-into-experimental/

I haven't tested this version, but if the message is to be believed, 
this is no longer an issue.

On mar, aoû 15 2023 at 10:54:22 +01:00:00, Simon McVittie 
 wrote:
> Control: reassign -1 evolution-data-server-common 3.49.2-3
> Control: severity -1 normal
> 
> On Sat, 22 Oct 2022 at 11:08:25 +0200, Julian wrote:
>>  The Adwaita Icon Theme package includes legacy versions of the
>>  appointment icons.
>> 
>>  These icons override the app icon and the notification icons of
>>  Evolution Alarm Notify.
> 
> I believe you are referring to these four icon names, which are meant 
> to
> be overridden by copies in 
> /usr/share/evolution-data-server/icons/hicolor:
> 
> - appointment-missed
> - appointment-soon
> - dialog-password
> - dialog-warning
> 
> I think we probably need to continue to ship these, at least in the 
> short
> term, because they are referred to by other packages (such as 
> gnome-panel)
> and it's difficult to assess whether those other packages are going 
> to be
> broken by their removal from the theme.
> 
> However, I think it should be possible to make e-d-s's copies "win" by
> adding a symlink to the evolution-data-server-common package:
> 
> /usr/share/evolution-data-server/icons/Adwaita -> hicolor
> 
> Please could an Evolution maintainer/user test that? I very rarely
> use Evolution myself, so I'm not familiar with how to make these icons
> be shown.
> 
> Thanks,
> smcv

Bug#1049955: bookworm-pu: package qemu/1:7.2+dfsg-7+deb12u2

[Michael Tokarev]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: q...@packages.debian.org, pkg-qemu-de...@lists.alioth.debian.org
Control: affects -1 + src:qemu

[ Reason ]
There's a next upstream qemu stable/bugfix release, fixing a
big number of various issues, including 3 (minor) security
issues too.  The full list is in the changelog below and
in the upstream git (mirrored in salsa too).

There's also another fix for bookworm qemu xen build, which
is missing 9pfs support (#1049925).  This is an easy one, as
it does not change runtime dependencies.

[ Tests ]
The upstream qemu release passed the upstream testsuite (well,
almost, besides a few corner cases which didn't work before,
such as msys-win32 build takes too much time on gitlab.com).
Also, debian build of this qemu release works fine with my
collection of qemu guests, and qemu-user works too, - I used
it in my regular work.

[ Risks ]
With the large list of fixes, at this point it seems more risky
to not update and hit one of the fixed issues, than to update
and hit some possible new issues.

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

The last point needs a comment. The xen 9pfs issue is *not* yet
fixed in unstable, it is pending upload.  The change is trivial
and I don't see a reason to push just that change to sid, esp.
since other changes are pending.  I can do that though.

[ Changes ]
The main reason for the update is the new upstream stable/bugfix
release, which is best viewed at
  https://gitlab.com/qemu-project/qemu/-/commits/v7.2.5
In the debian package (and in the debdiff), the whole thing is
shipped as a single d/patches/v7.2.5.diff file, which is not as
easy to review as individual commits with explanations.

  * d/rules: add the forgotten --enable-virtfs for the xen build.
This makes 9pfs virtual filesystem available for xen hvm domUs.
This adds no new runtime dependencies.  Closes: #1049925.
  * update to upstream 7.2.5 stable/bugfix release, v7.2.5.diff,
https://gitlab.com/qemu-project/qemu/-/commits/v7.2.5 :
   - hw/ide/piix: properly initialize the BMIBA register
   - ui/vnc-clipboard: fix infinite loop in inflate_buffer (CVE-2023-3255)
   - qemu-nbd: pass structure into nbd_client_thread instead of plain char*
   - qemu-nbd: fix regression with qemu-nbd --fork run over ssh
   - qemu-nbd: regression with arguments passing into nbd_client_thread()
   - target/s390x: Make CKSM raise an exception if R2 is odd
   - target/s390x: Fix CLM with M3=0
   - target/s390x: Fix CONVERT TO LOGICAL/FIXED with out-of-range inputs
   - target/s390x: Fix ICM with M3=0
   - target/s390x: Make MC raise specification exception when class >= 16
   - target/s390x: Fix assertion failure in VFMIN/VFMAX with type 13
   - target/loongarch: Fix the CSRRD CPUID instruction on big endian hosts
   - virtio-pci: add handling of PCI ATS and Device-TLB enable/disable
   - vhost: register and change IOMMU flag depending on Device-TLB state
   - virtio-net: pass Device-TLB enable/disable events to vhost
   - hw/arm/smmu: Handle big-endian hosts correctly
   - target/arm: Avoid writing to constant TCGv in trans_CSEL()
   - target/ppc: Disable goto_tb with architectural singlestep
   - linux-user/armeb: Fix __kernel_cmpxchg() for armeb
   - qga/win32: Use rundll for VSS installation
   - thread-pool: signal "request_cond" while locked
   - xen-block: Avoid leaks on new error path
   - io: remove io watch if TLS channel is closed during handshake
   - target/nios2: Pass semihosting arg to exit
   - target/nios2: Fix semihost lseek offset computation
   - target/m68k: Fix semihost lseek offset computation
   - hw/virtio-iommu: Fix potential OOB access in virtio_iommu_handle_command()
   - virtio-crypto: verify src buffer length for sym request
   - target/hppa: Move iaoq registers and thus reduce generated code size
   - pci: do not respond config requests after PCI device eject
   - hw/i386/intel_iommu: Fix trivial endianness problems
   - hw/i386/intel_iommu: Fix endianness problems related to VTD_IR_TableEntry
   - hw/i386/intel_iommu: Fix struct VTDInvDescIEC on big endian hosts
   - hw/i386/intel_iommu: Fix index calculation in vtd_interrupt_remap_msi()
   - hw/i386/x86-iommu: Fix endianness issue in x86_iommu_irq_to_msi_message()
   - include/hw/i386/x86-iommu: Fix struct X86IOMMU_MSIMessage for big endian 
hosts
   - vfio/pci: Disable INTx in vfio_realize error path
   - vdpa: Fix possible use-after-free for VirtQueueElement
   - vdpa: Return -EIO if device ack is VIRTIO_NET_ERR in _load_mac()
   - vdpa: Return -EIO if device ack is VIRTIO_NET_ERR in _load_mq()
   - target/ppc: Implement ASDR register for ISA v3.0 for HPT
   - target/ppc: Fix pending 

Bug#1049954: libvips42: Can not create image in AVIF format with libvips

[dvhh]

Package: libvips42
Version: 8.14.3-1
Severity: normal
X-Debbugs-Cc: d...@yahoo.com

Dear Maintainer,

I expected libvips to support avif format, but the version provided by
"libvips42/unstable,now 8.14.3-1 arm64" do not seem to support AVIF nor HEIF.

Using "vips" command line tool (from libvips-tools package), I get the
following message

$ vips copy momonga.png momonga.avif
heifsave: Unsupported compression

although I think all dependencies are correctly setup, general recommendation
seems to be to recompile the library (not tried yet).

Best regards


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

Kernel: Linux 5.11.0-custom (SMP w/8 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libvips42 depends on:
ii  libc6  2.37-7
ii  libcairo2  1.16.0-7
ii  libcfitsio10   4.2.0-3
ii  libcgif0   0.3.2-1
ii  libexif12  0.6.24-1+b1
ii  libexpat1  2.5.0-2
ii  libfftw3-double3   3.3.10-1
ii  libfontconfig1 2.14.2-3
ii  libgcc-s1  13.2.0-2
ii  libglib2.0-0   2.77.2-1
ii  libgsf-1-114   1.14.50-1
ii  libheif1   1.16.2-2
ii  libimagequant0 2.17.0-1
ii  libjpeg62-turbo1:2.1.5-2
ii  libjxl0.7  0.7.0-10
ii  liblcms2-2 2.14-2
ii  libmagickcore-6.q16-6  8:6.9.11.60+dfsg-1.6
ii  libmatio11 1.5.23-2
ii  libopenexr-3-1-30  3.1.5-5.1
ii  libopenjp2-7   2.5.0-2
ii  libopenslide0  3.4.1+dfsg-6+b1
ii  liborc-0.4-0   1:0.4.34-3
ii  libpango-1.0-0 1.51.0+ds-2
ii  libpangocairo-1.0-01.51.0+ds-2
ii  libpangoft2-1.0-0  1.51.0+ds-2
ii  libpng16-161.6.40-1
ii  libpoppler-glib8   22.12.0-2+b1
ii  librsvg2-2 2.54.7+dfsg-2
ii  libstdc++6 13.2.0-2
ii  libtiff6   4.5.1+git230720-1
ii  libwebp7   1.2.4-0.2
ii  libwebpdemux2  1.2.4-0.2
ii  libwebpmux31.2.4-0.2
ii  zlib1g 1:1.2.13.dfsg-3

libvips42 recommends no packages.

Versions of packages libvips42 suggests:
pn  nip2  

-- no debconf information