Bug#1007940: ITP: matrix-conduit -- lighweight homeserver for the Matrix protocol

[Nicolas Peugnet]

1]: Entering directory '/home/nicolas/debian/matrix-conduit'
[ -f Cargo.toml.orig ] || cp Cargo.toml Cargo.toml.orig
cp -f debian/Cargo.toml Cargo.toml
cp: cannot stat 'debian/Cargo.toml': No such file or directory
make[1]: *** [debian/rules:31: execute_before_dh_auto_configure] Error 1
make[1]: Leaving directory '/home/nicolas/debian/matrix-conduit'
make: *** [debian/rules:27: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2

debuild: fatal error at line 1184:
dpkg-buildpackage -us -uc -ui -i -I failed
gbp:error: 'debuild -i -I' failed: it exited with 29
--
Nicolas Peugnet

Bug#1077059: gettext: xgettext complains about missing charset header when using the exclude option

[Nicolas Peugnet]

Package: gettext
Version: 0.22.5-1
Severity: normal

Dear Maintainer,

After upgrading gettext to the latest version from testing (0.22.5-1) I
I can not use xgettext to extract messages from a .pot files in
conjuction with the exclude option. xgettext complains about a missing
header entry with charset specification, but is is there, and it worked
with the previous version from Debian stable (0.21-12).

Here is a demonstration of the problem:

   $ ls
   exclude.po  messages.po
   $ head -n30 *
   ==> exclude.po <==
   msgid ""
   msgstr ""
   "MIME-Version: 1.0\n"
   "Content-Type: text/plain; charset=UTF-8\n"
   "Content-Transfer-Encoding: 8bit\n"

   msgid "API"
   msgstr ""

   msgid "Atom"
   msgstr ""

   msgid "BibTeX"
   msgstr ""

   msgid "CLI"
   msgstr ""

   msgid "CalDAV"
   msgstr ""

   msgid "CardDAV"
   msgstr ""


   ==> messages.pot <==
   # SOME DESCRIPTIVE TITLE.
   # Copyright (C) 2022-2024, Membres de CLUB1
   # This file is distributed under the same license as the CLUB1 package.
   # FIRST AUTHOR , YEAR.
   #
   #, fuzzy
   msgid ""
   msgstr ""
   "Project-Id-Version: CLUB1 main\n"
   "Report-Msgid-Bugs-To: \n"
   "POT-Creation-Date: 2024-07-25 18:30+0200\n"
   "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
   "Last-Translator: FULL NAME \n"
   "Language-Team: LANGUAGE \n"
   "MIME-Version: 1.0\n"
   "Content-Type: text/plain; charset=UTF-8\n"
   "Content-Transfer-Encoding: 8bit\n"

   #: ../../_templates/404.html:2
   #: ../../_templates/404.html:5
   msgid "404 Non trouvé"
   msgstr ""

   #: ../../_templates/404.html:6
   msgid "La page demandée n'existe pas ou plus, elle a peut-être été renommée."
   msgstr ""

   #: ../../_templates/breadcrumbs.html:9
   msgid "Traduire sur Weblate"
   msgstr ""
   $ xgettext -x exclude.po messages.pot 
   Warning: program compiled against libxml 212 using older 209
   xgettext: messages.pot: input file doesn't contain a header entry with a 
charset specification

I tried to compile the upstream project from source in order to bisect
the issue, but I had to much problems compiling the example, which I
didn't even need.
It should probably be forwarded upstream.

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

Kernel: Linux 6.9.9-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

Versions of packages gettext depends on:
ii  gettext-base   0.22.5-1
ii  libc6  2.39-4
ii  libgomp1   14-20240330-1
ii  libunistring5  1.2-1
ii  libxml22.9.14+dfsg-1.3+b3

Versions of packages gettext recommends:
ii  curl  8.8.0-4
ii  lynx  2.9.2-1
ii  wget  1.24.5-1

Versions of packages gettext suggests:
ii  autopoint 0.22.5-1
pn  gettext-doc   
pn  libasprintf-dev   
pn  libgettextpo-dev  

-- no debconf information

Bug#1077531: ITP: prometheus-phpfpm-exporter -- Prometheus exporter for PHP-FPM.

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: prometheus-phpfpm-exporter
  Version : 0.6.0-1
  Upstream Author : Pedro Gomes
* URL : https://github.com/Lusitaniae/phpfpm_exporter
* License : Apache-2.0
  Programming Lang: Go
  Description : Prometheus exporter for PHP-FPM.

 Prometheus Exporter for the PHP-FPM status page.
 .
 Metrics are scrapped via unix socket and made available on port 9253.
 .
 This exporter also provides a way for embedding the output of arbitrary
 PHP scripts into its metrics page, analogous to the node exporter's
 textfile collector. Scripts that are specified with the --phpfpm.script-
 collector-paths flag will be run through PHP-FPM. Any metrics printed by
 the PHP script will be merged into the metrics provided by this
 exported. An example use case includes printing metrics for PHP's
 opcache.

I like this exporter because it is able to monitor multiple PHP-FPM pools
at once by simply using the "--phpfpm.socket-directories" option.

I currently pushed this package on my own repo on Salsa as I don't have
access to the Go Packaging Team group yet:
<https://salsa.debian.org/n-peugnet/prometheus-phpfpm-exporter>

This is the first package that I create for Debian. If I understood
correctly, I will need to find a sponsor to be able to upload it.

Bug#1077533: ITP: golang-github-tomasen-fcgi-client -- go fastcgi client with fcgi params support

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: golang-github-tomasen-fcgi-client
  Version : 0.0~git20180423.2bb3d81-1
  Upstream Author : Shen Sheng
* URL : https://github.com/tomasen/fcgi_client
* License : BSD-3-clause
  Programming Lang: Go
  Description : go fastcgi client  with fcgi params support

 Go fastcgi client with fcgi params support

This is a dependency of prometheus-phpfpm-exporter (#1077531) that I
intend to package.
It is currently pushed on my own repo as I don't have yet access to the
Go Packaging Team group:
<https://salsa.debian.org/n-peugnet/golang-github-tomasen-fcgi-client>

Bug#1033394: Bind v9.18.12+ unmarshall xml error

[Nicolas Peugnet]

On Fri, 24 Mar 2023 08:16:12 +0100 (CET) Benjamin Schönbach 
 wrote:

subject: prometheus-bind-exporter: Bind v9.18.12+ unmarshall xml error
Package: prometheus-bind-exporter
Version: 0.4.0+ds-1+b5
Severity: important

Dear Maintainer,

As a devops guy working on prometheus community stuff I would ask you to
upgrade the official debian 11 package for *prometheus-bind-exporter
(v0.4.0) *to latest stable release *v0.6.1*. It fixes a major bug that
blocks users working with bind v9.18.12+

What led up to the situation?
Upgrade to any bind version 9.18.12+ crashes every bind-exporter release below 
version 0.6.1.
The problem is an unmarshall value of negative xml files.

What exactly did you do (or not do) that was effective?
Upgrade to bind version v9.18.12+

What was the outcome of this action?
Unmarshall error of bind statistics channel output -> hence no valid metrics

What outcome did you expect instead?
Correct pars of bind xml output and output of metrics

For further information on fix, please check the project source of 
prometheus-exporter
https://github.com/prometheus-community/bind_exporter/releases/tag/v0.6.1


I am also affected by this bug on Debian bullseye (current old stable) 
since bind9 has been updated to 1:9.16.50-1~deb11u1 from bullseye-security.


Here is the error message a get:

juil. 29 23:11:24 club1.fr prometheus-bind-exporter[591]: 
level=error ts=2024-07-29T21:11:24.570Z caller=bind_exporter.go:427 
msg="Couldn't retrieve BIND stats" err="failed to unmarshal XML 
response: strconv.ParseUint: parsing \"-1\": invalid syntax"


--
Nicolas Peugnet

Bug#994189: RFP: jellyfin-server -- The Free Software Media System

[Nicolas Peugnet]

On Wed, 17 Jul 2024 12:51:18 +0200 Petter Reinholdtsen  
wrote:> I had a look at the source package for jellyfin-server provided by

upstream, and the build dependencies were not sufficient to build the
source.  I installed nodejs and ran 'debuild', and the build imediately
stopped because 'dotnet' was missing.  I suspect this is the Visual
Studio compiler for C#, and that the first step will be to get the
source to build with xbuild from mono or some ohter free software
compiler.


Another possibility would be to try to integrate Ubuntu's packaging of 
dotnet (https://launchpad.net/ubuntu/+source/dotnet8) as it is finally 
free software now, but this won't probably be easy.


I wonder if an initiative to integrate this package in Debian has 
already emerged? I guess it will not be easy to maintain over time.

--
Nicolas Peugnet

Bug#980286: RFP: signald -- A daemon that facilitates communication via Signal Private Messenger

[Nicolas Peugnet]

signald is needed for mautrix-signal, the Matrix to Signal bridge, which I 
intend to package.


mautrix-signal was recently rewritten in Go and does not make use of 
signald anymore [1], instead it links against libsignal [2].


[1]: https://github.com/mautrix/signal/issues/372
[2]: https://github.com/signalapp/libsignal
--
Nicolas Peugnet

Bug#1065668: google-android-build-tools-30.0.2-installer: Cannot install multiple "build-tools" versions side by side

[Nicolas Peugnet]

Package: google-android-build-tools-30.0.2-installer
Version: 30.0.2+1707406511
Severity: normal

Dear Maintainer,

Since I made the switch to testing packages for google-android-*
packages, I can no longer install multiple versions of the "build tools"
side by side.

Here is the log of when I try to install two of them:

$ sudo apt install -t testing google-android-build-tools-30.0.3-installer 
google-android-build-tools-30.0.2-installer 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
google-android-build-tools-30.0.2-installer is already the newest version 
(30.0.2+1707406511).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 google-android-build-tools-30.0.2-installer : Conflicts: aapt
   Conflicts: aidl
   Conflicts: apksigner
   Conflicts: dexdump
   Conflicts: split-select
   Conflicts: zipalign
 google-android-build-tools-30.0.3-installer : Conflicts: aapt
   Conflicts: aidl
   Conflicts: apksigner
   Conflicts: dexdump
   Conflicts: split-select
   Conflicts: zipalign
E: Unable to correct problems, you have held broken packages.

And here is the result of apt depends, which feels strange to me:

$ apt depends google-android-build-tools-30.0.2-installer
google-android-build-tools-30.0.2-installer
  Depends: google-android-licenses (= 1707406511)
  Depends: libstdc++6
  Depends: zlib1g
  Depends: wget
 |Depends: make
make-guile
 |Depends: build-essential
  Depends: dpkg-dev
  Depends: unzip
  Depends: ca-certificates
  Depends: debconf
  Depends: po-debconf
 |Depends: debconf (>= 0.5)
  Depends: 
cdebconf
debconf
  Conflicts: aapt
google-android-build-tools-19.1.0-installer
google-android-build-tools-20.0.0-installer
google-android-build-tools-21.1.2-installer
google-android-build-tools-22.0.1-installer
google-android-build-tools-23.0.1-installer
google-android-build-tools-23.0.2-installer
google-android-build-tools-23.0.3-installer
google-android-build-tools-24.0.0-installer
google-android-build-tools-24.0.1-installer
google-android-build-tools-24.0.2-installer
google-android-build-tools-24.0.3-installer
google-android-build-tools-25.0.0-installer
google-android-build-tools-25.0.1-installer
google-android-build-tools-25.0.2-installer
google-android-build-tools-25.0.3-installer
google-android-build-tools-26.0.0-installer
google-android-build-tools-26.0.1-installer
google-android-build-tools-26.0.2-installer
google-android-build-tools-26.0.3-installer
google-android-build-tools-27.0.0-installer
google-android-build-tools-27.0.1-installer
google-android-build-tools-27.0.2-installer
google-android-build-tools-27.0.3-installer
google-android-build-tools-28.0.0-installer
google-android-build-tools-28.0.1-installer
google-android-build-tools-28.0.2-installer
google-android-build-tools-28.0.3-installer
google-android-build-tools-29.0.0-installer
google-android-build-tools-29.0.1-installer
google-android-build-tools-29.0.2-installer
google-android-build-tools-29.0.3-installer
google-android-build-tools-30.0.0-installer
google-android-build-tools-30.0.1-installer
google-android-build-tools-30.0.3-installer
google-android-build-tools-31.0.0-installer
google-android-build-tools-32.0.0-installer
google-android-build-tools-33.0.0-installer
google-android-build-tools-33.0.1-installer
google-android-build-tools-33.0.2-installer
google-android-build-tools-33.0.3-installer
google-android-build-tools-34.0.0-installer
google-android-build-tools-installer
  Conflicts: aidl
google-android-build-tools-19.1.0-installer
google-android-build-tools-20.0.0-installer
google-android-build-tools-21.1.2-installer
google-android-build-tools-22.0.1-installer
google-android-build-tools-23.0.1-installer
google-android-build-tools-23.0.2-installer
google-android-build-tools-23.0.3-installer
google-android-build-tools-24.0.0-installer
google-android-build-tools-24.0.1-installer
google-android-build-tools-24.0.2-installer
google-android-build-tools-24.0.3-installer
google-android-build-tools-25.0.0-installer
google-android-build-tools-25.0.1-

Bug#1079361: sloccount: Go support

[Nicolas Peugnet]

Package: sloccount
Version: 2.26-5.2
Severity: wishlist
Tags: patch

Dear Maintainer,

Here is a patch to add support for counting SLOC in Go files. it is
inspired from the patch to add javascript support, as Go has a syntax
very similar to C.

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

Kernel: Linux 6.1.0-21-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=fr_FR.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 sloccount depends on:
ii  libc6  2.36-9+deb12u7
ii  perl   5.36.0-7+deb12u1

sloccount recommends no packages.

Versions of packages sloccount suggests:
pn  doc-base  

-- no debconf information
Description: add go support
Author: Nicolas Peugnet 

--- sloccount-2.26.orig/break_filelist
+++ sloccount-2.26/break_filelist
@@ -174,6 +174,7 @@ $noisy = 0;# Set to 1 if you
   # freeze is extremely rare and even more rare in source code directories.
   "f77" => "fortran", "F77" => "fortran",
   "f90" => "f90", "F90" => "f90",
+  "go" => "go",
   "cob" => "cobol", "cbl" => "cobol",
   "COB" => "cobol", "CBL" => "cobol",  # Yes, people do create wokka.CBL files
   "p" => "pascal", "pas" => "pascal", "pp" => "pascal", "dpr" => "pascal",
--- /dev/null
+++ sloccount-2.26/go_count
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# This is part of SLOCCount, a toolsuite that counts
+# source lines of code (SLOC).
+# Copyright (C) 2001-2004 David A. Wheeler.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+#
+# To contact David A. Wheeler, see his website at:
+#  http://www.dwheeler.com.
+#
+#
+
+c_count $@
+
--- sloccount-2.26.orig/makefile
+++ sloccount-2.26/makefile
@@ -107,6 +107,7 @@ EXECUTABLES= \
generic_count \
get_sloc \
get_sloc_details \
+   go_count \
haskell_count \
javascript_count \
lex_count \

Bug#1060846: freecad: Include fcinfo script in the built package

[Nicolas Peugnet]

Package: freecad
Version: 0.20.2+dfsg1-4
Severity: wishlist

Dear Maintainer,

It would be convenient if the freecad binary package (or the maybe the
freecad-python3 one) included the `fcinfo` python script [1].
This tool is recomended in FreeCAD's wiki as a way to view
human-readable diffs of .FCStd files [2]. It does not have to be in the
path, though I think it could be useful.

[1] https://github.com/FreeCAD/FreeCAD/blob/main/src/Tools/fcinfo
[2] 
https://wiki.freecad.org/WebTools_Git#Enabling_human-readable_diffs_for_FCStd_files_with_the_fcinfo_utility

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.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 freecad depends on:
ii  freecad-python3  0.20.2+dfsg1-4

Versions of packages freecad recommends:
ii  calculix-ccx  2.20-1
ii  graphviz  2.42.2-7+b3

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#921150: RFS: golang-github-arduino-go-paths-helper [ITP]

[Nicolas Peugnet]

On Thu, 8 Apr 2021 21:56:35 +0100 Rock Storm  wrote:

Hi Nilesh,

Thank you for you offer. I'm sorry, I completely forgot about this bugs.
I wanted these libraries (#921150 and #922528) to be uploaded in order
to package the latest 'arduino-builder'. However, we finally decided to
keep the current version since 'arduino-builder' will be superseded by
'arduino-cli' in the near future anyway.

I would not close the ITPs nor remove the work from Salsa since I suspect
they will be necessary for 'arduino-cli' though I haven't looked into
this yet. I guess the RFS (#934515) could be closed as "wontfix" and/or
tagged as "bullseye-ignore" and simply left open for later. I'm easy.


Hi,

I would be very interested by the addition of 'arduino-cli' to the 
Debian repository. Indeed, the now deprecated 'arduino-builder' does not 
support newer Arduino boards like the Nano 33 family and I suspect more 
of them.


It seems the 'arduino-cli' package is nearing a 1.0.0 stable release, 
and it is already a very capable tool, so it might be interesting to 
start packaging its dependencies.


I don't think I will be able to help packaging, but I could help testing 
packages for sure.

--
Nicolas Peugnet

Bug#1081737: ITP: lintian-ssg -- Static Site Generator for Lintian tags' explanations

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: lintian-ssg
  Version : 1.0.0
  Upstream Author : Nicolas Peugnet
* URL : https://salsa.debian.org/lintian/lintian-ssg
* License : GPL-3.0
  Programming Lang: Go
  Description : Static Site Generator for Lintian tags' explanations

 A very simple static site generator that builds a Web version of
 Lintian tags' explanations,  based on the output of "lintian-
 explain-tags --format=json".

This package will be maintained with the Debian Lintian Maintainers team.

Bug#900253: nslcd: disabling ppolicy breaks authentication

[Nicolas Peugnet]

Hello,

I just ran into this bug. If I understand correctly it should have been 
fixed by this commit:

<https://arthurdejong.org/git/nss-pam-ldapd/commit/?id=37a00e988304dd8b3b04886b56ecc713347f596f>
which is in Debian since version 0.9.12-1.

Just to be sure Arthur, would setting this option to "no" indeed make 
the OpenLDAP server stop logging entries like the following?


slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1

And would it be a good idea to back-port this patch to stable ?

Regards,
Nicolas Peugnet

Bug#1000963: qbittorrent: fontconfig antialiasing settings are ignored

[Nicolas Peugnet]

Package: qbittorrent
Version: 4.3.8-1
Severity: minor
Tags: upstream

Dear Maintainer,

I intalled qbittorrent 4.3.8-1 on bookworm from experimental to test the package
and I have an issue with the fonts antialiasing compared to the version from
bookworm (4.2.5-0.1).

The fontconfig parameters are ignored. Here is a fontconfig file that
completely disables antialiasing just to show that it is not used :

~/.config/fontconfig/fonts.conf






false


false


lcdnone




With this config, none of my GTK or QT programs use font antialiasing
except qbittorrent. With the same config, bittorrent 4.2.5-0.1 does not
use antialiasing as expected.

I also tried to build upstream package from their source tree but none
of the versions I built (4.2.4, 4.2.5, 4.3.0, 4.3.8) were affected by
fontconfig parameters. So I don't know why Debian's 4.2.5-0.1 works as
expected.

Other QT software that I built from source does not display this behaviour
and apply fontconfig parameters as expected.

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

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

Versions of packages qbittorrent depends on:
ii  geoip-database  20191224-3
ii  libc6   2.32-4
ii  libgcc-s1   11.2.0-10
ii  libqt5core5a5.15.2+dfsg-13
ii  libqt5dbus5 5.15.2+dfsg-13
ii  libqt5gui5  5.15.2+dfsg-13
ii  libqt5network5  5.15.2+dfsg-13
ii  libqt5widgets5  5.15.2+dfsg-13
ii  libqt5xml5  5.15.2+dfsg-13
ii  libssl1.1   1.1.1l-1
ii  libstdc++6  11.2.0-10
ii  libtorrent-rasterbar10  1.2.14-1
ii  zlib1g  1:1.2.11.dfsg-2

qbittorrent recommends no packages.

qbittorrent suggests no packages.

-- no debconf information

Bug#1000963: qbittorrent: fontconfig antialiasing settings are ignored

[Nicolas Peugnet]

I discovered the culprit, as explained in this comment:


It seems that, due to a Qt bug, setting QT_SCALE_FACTOR_ROUNDING_POLICY 
to PassThrough makes qBittorrent ignoring fontconfig parameters.
And qBittorent made this value the default, apparently to fix issues 
with HiDPI rendering, primarily on Windows:



Reverting the commit a9b0d84df95db7c30c668190ccac00d37cbf1b40 completely 
fixes the issue for me. I can also set the env var to anything but 
PassThrough as a workaround.

Bug#1053458: openstreetmap-carto-common: Configure step failed with FATAL: role "root" does not exist

[Nicolas Peugnet]

Package: openstreetmap-carto-common
Version: 5.7.0-1
Severity: important

Dear Maintainer,

When installing openstreetmap-carto-common package (as a dependency of
openstreetmap-carto), the configure step failed after having answered
yes to all the questions (as I remember: "do you want to download the
additionnal resources?" and "What is the name of the database? gis").

Here is the error message from apt install:

Setting up openstreetmap-carto-common (5.7.0-1) ...
INFO:root:Starting load of external data into database
Traceback (most recent call last):
  File "/usr/share/openstreetmap-carto-common/./get-external-data.py", line 
405, in 
main()
  File "/usr/share/openstreetmap-carto-common/./get-external-data.py", line 
305, in main
conn = psycopg2.connect(database=database,
   ^^^
  File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 122, in 
connect
conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
   ^^^
psycopg2.OperationalError: connection to server on socket 
"/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  role "root" does not exist

dpkg: error processing package openstreetmap-carto-common (--configure):
 installed openstreetmap-carto-common package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of openstreetmap-carto:
 openstreetmap-carto depends on openstreetmap-carto-common; however:
  Package openstreetmap-carto-common is not configured yet.

dpkg: error processing package openstreetmap-carto (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 openstreetmap-carto-common
 openstreetmap-carto
E: Sub-process /usr/bin/dpkg returned an error code (1)


It seems indeed that by default the root user does not have access to
PostgreSQL databases, and only postgres user has superuser privileges.
So maybe this script should be run as postgres user.

I'd like to mention that I tried to install this package on an almost
completely fresh install of Debian 12. I followed this tutorial until
the end [1] before noticing that the openstreetmap-carto package was
part of Debian. But I donc think that it was the source of the issue.

[1] 
https://switch2osm.org/serving-tiles/manually-building-a-tile-server-debian-12/

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

Versions of packages openstreetmap-carto-common depends on:
ii  curl   7.88.1-10+deb12u1
ii  debconf [debconf-2.0]  1.5.82
ii  fonts-dejavu-core  2.37-6
pn  fonts-noto-cjk 
pn  fonts-noto-hinted  
pn  fonts-noto-unhinted
pn  fonts-unifont  
ii  gdal-bin   3.6.2+dfsg-1+b2
ii  mapnik-utils   3.1.0+ds-3+b1
ii  python33.11.2-1+b1
ii  unzip  6.0-28

openstreetmap-carto-common recommends no packages.

openstreetmap-carto-common suggests no packages.

Bug#1057648: synadm: Add bash completion script to synadm

[Nicolas Peugnet]

Package: synadm
Version: 0.43.1-1
Severity: wishlist
Tags: patch

Dear Maintainer,

In case you didn't see, I made a merge request on salsa [1] to generate
the bash completion script from Click and to add it to the binary
package.
I'm trying to also send the patch via reportbug, but as this is the
first time I am trying to do it I am not entirely sure to succeed.

[1] https://salsa.debian.org/matrix-team/synadm/-/merge_requests/1


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

Kernel: Linux 6.1.0-13-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.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 synadm depends on:
ii  python3 3.11.2-1+b1
pn  python3-click   
pn  python3-click-option-group  
pn  python3-dnspython   
ii  python3-requests2.28.1+dfsg-1
pn  python3-tabulate
ii  python3-yaml6.0-3+b2

synadm recommends no packages.

synadm suggests no packages.
>From 6bfcb55140b28ba438292e70bea5df8525bca9d6 Mon Sep 17 00:00:00 2001
From: Nicolas Peugnet 
Date: Sun, 3 Dec 2023 17:16:17 +0100
Subject: [PATCH] add click generated bash-completion script

---
 debian/clean   |  1 +
 debian/control |  1 +
 debian/patches/0001-add-main.patch | 12 
 debian/patches/series  |  1 +
 debian/rules   |  4 +++-
 5 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 debian/clean
 create mode 100644 debian/patches/0001-add-main.patch
 create mode 100644 debian/patches/series

diff --git a/debian/clean b/debian/clean
new file mode 100644
index 000..5d84c6b
--- /dev/null
+++ b/debian/clean
@@ -0,0 +1 @@
+debian/synadm.bash-completion
diff --git a/debian/control b/debian/control
index 86e33e4..2a07e89 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Maintainer: Matrix Packaging Team 

 Build-Depends: debhelper-compat (= 13),
dh-python,
+   bash-completion,
python3-all,
python3-click,
python3-click-option-group,
diff --git a/debian/patches/0001-add-main.patch 
b/debian/patches/0001-add-main.patch
new file mode 100644
index 000..7813d1c
--- /dev/null
+++ b/debian/patches/0001-add-main.patch
@@ -0,0 +1,12 @@
+Description: Add __main__.py to ba able to run package
+Author: Nicolas Peugnet 
+Forwarded: https://github.com/JOJ0/synadm/pull/138
+Last-Update: 2023-11-20
+---
+
+--- /dev/null
 synadm-0.43.1/synadm/__main__.py
+@@ -0,0 +1,3 @@
++from synadm.cli import root
++
++root()
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..bba785d
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-add-main.patch
diff --git a/debian/rules b/debian/rules
index d88e477..7212ef6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #! /usr/bin/make -f
 
 export PYBUILD_NAME=synadm
+export PYBUILD_AFTER_BUILD=_SYNADM_COMPLETE=bash_source {interpreter} 
{build_dir}/synadm > debian/synadm.bash-completion
+
 %:
-   dh $@ --with python3 --buildsystem=pybuild
+   dh $@ --with python3 --buildsystem=pybuild --with=bash-completion
-- 
2.39.2

Bug#1023483: systemd upgrade to 252-2 breaks suspend, suspend-then-hibernate

[Nicolas Peugnet]

If I am not mistaken this has been fixed in 252.4-1 (see 
 
and ).


Although I haven't tested it myself yet.
--
Nicolas P.

Bug#1085944: ITS: j4-dmenu-desktop

[Nicolas Peugnet]

Package: j4-dmenu-desktop
Version: 2.16-1.1
Severity: important
X-Debbugs-Cc: m...@qa.debian.org

Dear maintainer,

I would like to salvage this package because it is not maintained
anymore.

There are multiple new releases upstream.
Last upload is an NMU from more than 1 year ago.
Last maintainer upload was more than 5 years ago.
Last commit to git on salsa was on October 2018.

If no objection, I will first proceed to upload an opdate of the
current version in 21 days, followed by an update to the latest
upstream version.

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

Kernel: Linux 6.10.11-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

Versions of packages j4-dmenu-desktop depends on:
ii  libc6   2.40-3
ii  libgcc-s1   14.2.0-6
ii  libstdc++6  14.2.0-6

j4-dmenu-desktop recommends no packages.

j4-dmenu-desktop suggests no packages.

-- no debconf information
-- 
Nicolas Peugnet

Bug#1087736: libspdlog-dev should not depend on catch2

[Nicolas Peugnet]

Package: libspdlog-dev
Version: 1:1.12.0+ds-2+b3
Severity: normal

Dear Maintainer,

While trying to build a new version of j4-dmenu-desktop (that I am
currently updating) with the 'nocheck' build profile, I noticed that
catch2 was still installed, as a dependency of libspdlog-dev, which
in turn, seems to be the reason why j4-dmenu-desktop is not
crossbuild-able anymore [1].

I made a quick grep in the spdlog sources and did not find any
references to catch2 outside of the tests directory. So I don't
understand why should catch2 be a dependency of libspdlog-dev.

Could you please remove this dependency, or if it is really needed,
explain why it is the case?

[1] https://salsa.debian.org/debian/j4-dmenu-desktop/-/jobs/6609781#L748

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

Kernel: Linux 6.11.5-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

Versions of packages libspdlog-dev depends on:
ii  catch2 3.7.1-0.4
ii  libfmt-dev 10.1.1+ds1-4
ii  libspdlog1.12  1:1.12.0+ds-2+b3

libspdlog-dev recommends no packages.

Versions of packages libspdlog-dev suggests:
pn  libsystemd-dev  
ii  qtbase5-dev 5.15.15+dfsg-2

-- no debconf information

Bug#1088766: ITP: crazy-complete -- Generate shell completion files for all major shells

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: crazy-complete
  Version : 0.3.2-1
  Upstream Author : Benjamin Abendroth
* URL : https://github.com/crazy-complete/crazy-complete
* License : GPL-3.0
  Programming Lang: Python
  Description : Generate shell completion files for all major shells

 crazy-complete is a tool that generates shell completion scripts, based
 on a description of the command line interface. It supports many input
 formats, including YAML and JSON, but can also use the --help output of
 a command, or even directly the content of a Python script if it uses
 argparse.
 .
 Its output also supports multiple shells, including Bash, Fish and Zsh.
 The generated scripts are standalone, focus on robustness and do not
 depend on modified environment.

crazy-complete is a new build dependency of j4-dmenu-desktop.

Bug#1088966: debhelper: maybe use --interactive flag for meson test

[Nicolas Peugnet]

Source: debhelper
Version: 13.20
Severity: wishlist

Hello, in Bug#918066, Jeremy Bicha suggested to print the test log at 
least when the build tests fail.


On Wed, 2 Jan 2019 17:57:26 -0500 Jeremy Bicha  wrote:

I think it would be appropriate if debhelper's meson backend would > include in 
the build logs the content of
$(CURDIR)/obj-$(DEB_HOST_GNU_TYPE)/meson-logs/testlog.txt at least
when the build tests fail. This can help diagnose test failures
(especially on obscure architectures.)

I think this is encouraged by Debian Policy §4.9's paragraph about the
build being as verbose as possible.


Meson 1.5.0 (released on 10 July 2024) introduced a "--interactive" flag 
to "meson test", which allows to directly connect stdout, stdin and 
stderr to the running shell. This would print the whole test output in 
the logs. Wouldn't it be more in line with what is recommended in the 
policy?

This could also simplify the related code in debhelper.

I tested it myself with the following rule and it works as expected:

override_dh_auto_test:
dh_auto_test --buildsystem=meson+ninja -- --interactive

--
Nicolas Peugnet

Bug#1091346: ITP: ondelsolver -- Assembly Constraints and Multibody Dynamics code

[Nicolas Peugnet]

On Tue, 24 Dec 2024 17:15:45 +0100 Tobias Frost  wrote:

Control: tags -1 pending

The library is now in NEW.

The source can be found on salsa:
https://salsa.debian.org/science-team/ondelsolver


Maybe it is a little bit too late but you seem to have mistyped the name 
of the library with a missing "s". It should be ondselsolver, with a "s" 
after "ond".

--
Nicolas Peugnet

Bug#1095207: busybox: please enable httpd's proxy feature

[Nicolas Peugnet]

Package: busybox
Version: 1:1.35.0-4+b3
Severity: wishlist

Dear Maintainer,

While trying to use busybox httpd's proxy feature, I discovered that it
is not enabled in the Debian build [1].

Is there a reason why it is disabled? Could it be enabled? I find busybox
httpd a really simple and useful tool and would love to be able to use it
as a very basic reverse proxy in some projects.

[1] 
https://sources.debian.org/src/busybox/1%3A1.37.0-4/debian/config/pkg/deb/#L901

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

Kernel: Linux 6.1.0-30-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=fr_FR.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 busybox depends on:
ii  libc6  2.36-9+deb12u9

busybox recommends no packages.

busybox suggests no packages.

-- no debconf information

Bug#1095772: ITP: golang-github-compose-spec-compose-go -- Reference library for parsing and loading Compose YAML files

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: golang-github-compose-spec-compose-go
  Version : 2.4.7-1
  Upstream Author : Compose Specification
* URL : https://github.com/compose-spec/compose-go
* License : Apache-2.0
  Programming Lang: Go
  Description : Reference library for parsing and loading Compose YAML files

 Go reference library for parsing and loading Compose files as specified
 by the Compose specification (https://github.com/compose-spec/compose-spec).
 .
 Used by
 .
  * compose (https://github.com/docker/compose)
  * containerd/nerdctl (https://github.com/containerd/nerdctl)
  * compose-cli (https://github.com/docker/compose-cli)
  * tilt.dev (https://github.com/tilt-dev/tilt)
  * kompose (https://github.com/kubernetes/kompose)
  * kurtosis (https://github.com/kurtosis-tech/kurtosis/)
  * testcontainers-go's Compose module
(https://github.com/testcontainers/testcontainers-
go/tree/main/modules/compose)
  * compose2nix (https://github.com/aksiksi/compose2nix)
  * Defang (https://github.com/DefangLabs/defang)
  * score-compose (https://github.com/score-spec/score-compose)
  * CasaOS (https://github.com/IceWhaleTech/CasaOS)

This is a dependency of docker-buildx (Bug#989917) and other docker
related packages.

Bug#989917: RFP: docker-buildx -- docker CLI plugin for BuildKit

[Nicolas Peugnet]

On 02/02/2025 2:43 PM, Reinhard Tartler wrote:

On Sat, Feb 1, 2025 at 7:42 PM Nicolas Peugnet  wrote:

Then I realized that the docker.io package is in fact a "Multiple
Upstream Tarballs" package, and as the cli, engine and buildkit are all
inter-dependent of each other, I think it would probably be better to
add "moby/buildkit" in the docker.io source package.


So about this, what do you think? For now, I will continue to work on
the separated package for "moby/buildkit", but wouldn't it be better if
it were part of the docker.io package?



I took a look at the docker.io package, to refresh my recollection
on the topic of dependencies, and I think I agree with you.

If I understand things correctly, we currently get away with that by keeping
"buildkit" in the "vendor/" directory. You are suggesting to promote that
dependency as part of the MUT upload.


Yes, exactly.


That sounds reasonable. Can you work on a MR to modify the docker.io package
to incorporate this new tarball?


I'll try to do it, but I've never worked with MUT packages yet. I'll 
take look at the README.source.
In the meantime, I managed to build locally a docker-buildx package that 
seems to work quite well. It needs 3 more dependencies to be packaged in 
Debian in addition to "moby/buildkit".


I will post ITPs for them soon.
--
Nicolas Peugnet

Bug#1094973: ITP: golang-github-package-url-packageurl-go -- Go implementation of the package url spec

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: golang-github-package-url-packageurl-go
  Version : 0.1.3-1
  Upstream Author : package-url authors
* URL : https://github.com/package-url/packageurl-go
* License : Expat
  Programming Lang: Go
  Description : Go implementation of the package url spec

 packageurl-go
 .
 Go implementation of the package url spec, a minimal specification and
 implementation of purl aka. a Package "mostly universal" URL.

This is a dependency of buildkit (Bug#1094971)

Bug#1094976: ITP: golang-github-tonistiigi-vt100 -- An raw-mode vt100 screen reader

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: golang-github-tonistiigi-vt100
  Version : 0.0~git20240514.90bafcd-1
  Upstream Author : Tõnis Tiigi
* URL : https://github.com/tonistiigi/vt100
* License : Expat
  Programming Lang: Go
  Description : An raw-mode vt100 screen reader

 This project was based on jaguilar/vt100
 (https://github.com/jaguilar/vt100)
 .
 This is a vt100 screen reader. It seems to do a pretty decent job of
 parsing the nethack input stream, which is all I want it for anyway.
 .
 The features we currently support:
 .
  * Cursor movement
  * Erasing
  * Many of the text properties -- underline, inverse, blink, etc.
  * Sixteen colors
  * Cursor saving and unsaving
  * UTF-8
  * Scrolling
 .
 Not currently supported (and no plans to support):
 .
  * Prompts
  * Other cooked mode features
 .
 The API is not stable! This is a v0 package.

vt100 is a dependency of buildkit (Bug#1094971)

Bug#1094971: ITP: golang-github-moby-buildkit -- concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: golang-github-moby-buildkit
  Version : 0.14.1-1
  Upstream Author : Moby
* URL : https://github.com/moby/buildkit
* License : Apache-2.0
  Programming Lang: Go
  Description : concurrent, cache-efficient, and Dockerfile-agnostic 
builder toolkit

 BuildKit is a toolkit for converting source code to build artifacts in
 an efficient, expressive and repeatable manner.
 .
 Key features:
 .
  * Automatic garbage collection
  * Extendable frontend formats
  * Concurrent dependency resolution
  * Efficient instruction caching
  * Build cache import/export
  * Nested build job invocations
  * Distributable workers
  * Multiple output formats
  * Pluggable architecture
  * Execution without root privileges

buildkit is a dependency of docker-buildx (Bug#989917).

Bug#1094975: ITP: golang-github-tonistiigi-go-archvariant -- Go package to detect compatibility version of the current system

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: golang-github-tonistiigi-go-archvariant
  Version : 1.0.0-1
  Upstream Author : Tõnis Tiigi
* URL : https://github.com/tonistiigi/go-archvariant
* License : Expat
  Programming Lang: Go
  Description : Go package to detect compatibility version of the current 
system

 go-archvariant is a Go package for determining the maximum compatibility
 version of the current system. The main use case is to use this value in
 container platform definitions
 
(https://github.com/containerd/containerd/blob/v1.5.9/platforms/platforms.go#L55).
 .
 On x86-64 platforms this package returns the maximum current
 microarchitecture level as defined in (https://en.wikipedia.org/wiki/X86-
 64#Microarchitecture_levels) . This value can be used to configure
 compiler in LLVM since 12.0 (https://github.com/llvm/llvm-
 project/commit/012dd42e027e2ff3d183cc9dcf27004cf9711720) and GCC since
 11.0 (https://github.com/gcc-
 mirror/gcc/commit/324bec558e95584e8c1997575ae9d75978af59f1). Go1.18+
 (https://tip.golang.org/doc/go1.18#amd64) uses GOAMD64 environemnt to
 configure Go compiler with this value.

go-archvariant is a dependency of buildkit (Bug#1094971)

Bug#989917: RFP: docker-buildx -- docker CLI plugin for BuildKit

[Nicolas Peugnet]

On 01/02/2025 6:05 PM, Reinhard Tartler wrote:

On Wed, Jan 29, 2025 at 7:15 PM Nicolas Peugnet  wrote:

Thank you for the pointers. Indeed in the case of packages from
"docker/cli" and "docker/docker" it is just a matter of adding them to
the golang-github-docker-docker-dev.install file. But in the case of
"moby/buildkit", some of the packages are not present in the current
source packages, as they are there as part of the engine's vendor
directory, which is incomplete.


Cool, if these packages are easy to add and enable, let's start with that.
Can you send me a MR?


Yes, these were the two MRs that you merged just now.


So I figured "moby/buildkit" should really be fully packaged. I started
to do this in

https://salsa.debian.org/go-team/packages/golang-github-moby-buildkit/-/tree/debian/sid
.

With a few patches [1] to disable some features dependent on some
missing packages, the number of missing dependencies is only 3 [2]
(golang-github-spdx-tools-golang is in NEW).


Awesome, thanks!


Then I realized that the docker.io package is in fact a "Multiple
Upstream Tarballs" package, and as the cli, engine and buildkit are all
inter-dependent of each other, I think it would probably be better to
add "moby/buildkit" in the docker.io source package.


So about this, what do you think? For now, I will continue to work on 
the separated package for "moby/buildkit", but wouldn't it be better if 
it were part of the docker.io package?



The patches are not very descriptive and currently untested because of
the missing packages in golang-github-docker-docker-dev (see my two
MRs). But I also started to package the 3 missing dependencies. If you
are OK with this plan I can post the ITP for the 3 of them.


I've merged your MRs, let's upload that to experimental.


Just so you know, I built the docker.io package locally with my two MRs 
applied, and I can now build the "moby/buildkit" package. I also added a 
few patches to skip some failing tests due to missing permissions or 
mismatched dependencies so that the testsuite can pass.



Let's proceed with the ITPs and get them into experimental as well.


Okay! I filed the ITPs and pushed the packages on slasa. They are all 
building correctly, but that it. There is still quite some work to do. I 
will continue working on them when I have some time.



[1]
https://salsa.debian.org/go-team/packages/golang-github-moby-buildkit/-/commit/b585a0c1a1b9f3b63628d16136e85904cda04b84
[2]
https://salsa.debian.org/go-team/packages/golang-github-moby-buildkit/-/commit/fbe71b63a2a712275c8e805f1529029988aaf9c3


--
Nicolas Peugnet

Bug#1087370: docker-cli: no buildx in debian testing any more

[Nicolas Peugnet]

On Tue, 12 Nov 2024 10:53:46 +0100 Richard Ulrich 
 wrote:

Package: docker-cli
Version: 26.1.5+dfsg1-4
Severity: important
X-Debbugs-Cc: richi+deb...@ulrichard.ch

Dear Maintainer,

Most of my machines run on debian testing with docker installed form the debian 
repository. For the longest time I could build docker containers with buildkit 
enabled. But at some point it stopped working. At first I thought that would be 
a temporary thing with some packages updating. These things happen from time to 
time on debian testing, and usually they resolve after a couple of days or 
sometimes weeks. But this problem with buildx has now existed for at least two 
months.

Simple containers that don't require features from buildx still build.

I didn't really find useful information on how to resolve by searching the internet. 


To reproduce, on an up to date debian trixie installation execute the following:
DOCKER_BUILDKIT=1 docker build --output some_files
I get the following error:

ERROR: BuildKit is enabled but the buildx component is missing or broken.
   Install the buildx component to build images with BuildKit:
   https://docs.docker.com/go/buildx/

Since I installed docker from the repository I would prefer not having to 
install buildx manually.



It seems that this would require this additional component: 
https://github.com/docker/buildx


Was it really available in Debian's package of Docker previously? It 
seems strange since this component has not been packaged in the past. I 
don't remember having it working.

--
Nicolas Peugnet

Bug#989917: RFP: docker-buildx -- docker CLI plugin for BuildKit

[Nicolas Peugnet]

26 janv. 2025 00:08:01 Otto Kekäläinen :

Just out of curiosity, what are you using it for?

A large part of the FOSS community has moved to Podman instead of
Oracle affiliated Docker. Have you checked if a Podman BuildKit plugin
could do the same?


docker-buildx allows to build multi-platform images using 
cross-compilation [1], AFAIK podman cannot do this.


[1] 
https://www.docker.com/blog/faster-multi-platform-builds-dockerfile-cross-compilation-guide/


--
Nicolas Peugnet

Bug#989917: RFP: docker-buildx -- docker CLI plugin for BuildKit

[Nicolas Peugnet]

25 janv. 2025 18:36:15 Nicolas Peugnet :


On 25/01/2025 5:43 PM, Reinhard Tartler wrote:

that's awesome, thank you.
Let me know when you have a package ready, I'd be happy to take a look 
at

it. Maybe we can use it in an autopkgtest for the docker.io package?


It is still quite far from ready, but I am making progress. I have a 
question for you, as you seem to be involved in docker packaging. I saw 
that the golang-github-docker-docker-dev [1] seems to provide the 
source of multiple go modules, namely:

- github.com/docker/cli
- github.com/docker/docker
- github.com/moby/buildkit

All three of them are dependencies of docker-buildx.
I started from the version v0.15.1 of docker-buildx as it is the last 
one that explicitly requires the version v26.1.x for these packages 
(the current version in Debian unstable). But I still get some missing 
packages error for these modules. Do you have an idea why?


For example:

src/github.com/docker/buildx/util/confutil/config.go:8:2: cannot find 
package "github.com/docker/cli/cli/command" in any of:
    /usr/lib/go-1.23/src/github.com/docker/cli/cli/command (from 
$GOROOT)
    
/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/docker/cli/cli/command 
(from $GOPATH)
    
/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/util/tracing/delegated 
(from $GOPATH)
src/github.com/docker/buildx/driver/kubernetes/context/load.go:10:2: 
cannot find package "github.com/docker/cli/cli/context" in any of:
    /usr/lib/go-1.23/src/github.com/docker/cli/cli/context (from 
$GOROOT)
    
/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/docker/cli/cli/context 
(from $GOPATH)
src/github.com/docker/buildx/driver/kubernetes/context/load.go:11:2: 
cannot find package "github.com/docker/cli/cli/context/store" in any 
of:
    /usr/lib/go-1.23/src/github.com/docker/cli/cli/context/store (from 
$GOROOT)
    
/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/docker/cli/cli/context/store 
(from $GOPATH)
src/github.com/docker/buildx/util/dockerutil/api.go:5:2: cannot find 
package "github.com/docker/cli/cli/context/docker" in any of:
    /usr/lib/go-1.23/src/github.com/docker/cli/cli/context/docker (from 
$GOROOT)
    
/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/docker/cli/cli/context/docker 
(from $GOPATH)
src/github.com/docker/buildx/controller/pb/secrets.go:5:2: cannot find 
package "github.com/moby/buildkit/session/secrets/secretsprovider" in 
any of:
    
/usr/lib/go-1.23/src/github.com/moby/buildkit/session/secrets/secretsprovider 
(from $GOROOT)
    
/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/session/secrets/secretsprovider 
(from $GOPATH)
src/github.com/docker/buildx/controller/pb/ssh.go:5:2: cannot find 
package "github.com/moby/buildkit/session/sshforward/sshprovider" in 
any of:
    
/usr/lib/go-1.23/src/github.com/moby/buildkit/session/sshforward/sshprovider 
(from $GOROOT)
    
/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/session/sshforward/sshprovider 
(from $GOPATH)
src/github.com/docker/buildx/build/opt.go:28:2: cannot find package 
"github.com/moby/buildkit/session/upload/uploadprovider" in any of:
    
/usr/lib/go-1.23/src/github.com/moby/buildkit/session/upload/uploadprovider 
(from $GOROOT)
    
/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/session/upload/uploadprovider 
(from $GOPATH)
src/github.com/docker/buildx/build/build.go:39:2: cannot find package 
"github.com/moby/buildkit/util/progress/progresswriter" in any of:
    
/usr/lib/go-1.23/src/github.com/moby/buildkit/util/progress/progresswriter 
(from $GOROOT)
    
/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/util/progress/progresswriter 
(from $GOPATH)
src/github.com/docker/buildx/bake/bake.go:28:2: cannot find package 
"github.com/moby/buildkit/session/auth/authprovider" in any of:
    
/usr/lib/go-1.23/src/github.com/moby/buildkit/session/auth/authprovider 
(from $GOROOT)
    
/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/session/auth/authprovider 
(from $GOPATH)



[1] 
https://packages.debian.org/sid/all/golang-github-docker-docker-dev/filelist


Ok, I got it. The reason is that these sources come from "go mod vendor" 
which only bundles in the packages needed to build the current module, 
i.e. the docker engine and cli.


We will have to really package the full sources of github.com/docker/cli 
and github.com/moby/buildkit to be able to package 
github.com/docker/buildx. This will be a lot more work than what I 
originally imagined.


Also it will be more tricky to update the multiple Debian packages as the 
version requirements between each dependency are really tight.


--
Nicolas Peugnet

Bug#989917: RFP: docker-buildx -- docker CLI plugin for BuildKit

[Nicolas Peugnet]

On 26/01/2025 1:16 PM, Reinhard Tartler wrote:

On Sat, Jan 25, 2025 at 12:18 PM Nicolas Peugnet  wrote:


I started from the version v0.15.1 of docker-buildx as it is the last
one that explicitly requires the version v26.1.x for these packages (the
current version in Debian unstable). But I still get some missing
packages error for these modules. Do you have an idea why?

For example:

src/github.com/docker/buildx/util/confutil/config.go:8:2: cannot find
package "github.com/docker/cli/cli/command" in any of:
 /usr/lib/go-1.23/src/github.com/docker/cli/cli/command (from
$GOROOT)
 /build/reproducible-path/docker-buildx-0.15.1/_build/src/
github.com/docker/cli/cli/command (from $GOPATH)
 /build/reproducible-path/docker-buildx-0.15.1/_build/src/
github.com/moby/buildkit/util/tracing/delegated (from $GOPATH)



Just looking at this here, I think it is looking for sources that we have
in Debian in the docker.io source package here:

https://sources.debian.org/src/docker.io/26.1.5%2Bdfsg1-4/cli/cmd/docker/

However, they are not currently installed, checkout here:
https://sources.debian.org/src/docker.io/26.1.5%2Bdfsg1-4/debian/golang-github-docker-docker-dev.install/#L1-L4

It might be as easy as adding a few more lines to the
golang-github-docker-docker-dev.install file.

Can you give it a go and send me a MR on salsa with the source you need for
the docker buildx package?


I strongly suspect that adding new sources might pull in additional
dependencies that were not critical for getting the docker daemon and cli
to work in Debian. So let's be careful to only include packages that we
actually need. If docker-buildx requires those packages, let's try adding
them. Let me know what issues you run into.


Thank you for the pointers. Indeed in the case of packages from 
"docker/cli" and "docker/docker" it is just a matter of adding them to 
the golang-github-docker-docker-dev.install file. But in the case of 
"moby/buildkit", some of the packages are not present in the current 
source packages, as they are there as part of the engine's vendor 
directory, which is incomplete.


So I figured "moby/buildkit" should really be fully packaged. I started 
to do this in 
https://salsa.debian.org/go-team/packages/golang-github-moby-buildkit/-/tree/debian/sid.


With a few patches [1] to disable some features dependent on some 
missing packages, the number of missing dependencies is only 3 [2] 
(golang-github-spdx-tools-golang is in NEW).


Then I realized that the docker.io package is in fact a "Multiple 
Upstream Tarballs" package, and as the cli, engine and buildkit are all 
inter-dependent of each other, I think it would probably be better to 
add "moby/buildkit" in the docker.io source package.


The patches are not very descriptive and currently untested because of 
the missing packages in golang-github-docker-docker-dev (see my two 
MRs). But I also started to package the 3 missing dependencies. If you 
are OK with this plan I can post the ITP for the 3 of them.


[1] 
https://salsa.debian.org/go-team/packages/golang-github-moby-buildkit/-/commit/b585a0c1a1b9f3b63628d16136e85904cda04b84
[2] 
https://salsa.debian.org/go-team/packages/golang-github-moby-buildkit/-/commit/fbe71b63a2a712275c8e805f1529029988aaf9c3


--
Nicolas Peugnet

Bug#989917: RFP: docker-buildx -- docker CLI plugin for BuildKit

[Nicolas Peugnet]

On 25/01/2025 5:43 PM, Reinhard Tartler wrote:

that's awesome, thank you.

Let me know when you have a package ready, I'd be happy to take a look at
it. Maybe we can use it in an autopkgtest for the docker.io package?


It is still quite far from ready, but I am making progress. I have a 
question for you, as you seem to be involved in docker packaging. I saw 
that the golang-github-docker-docker-dev [1] seems to provide the source 
of multiple go modules, namely:

- github.com/docker/cli
- github.com/docker/docker
- github.com/moby/buildkit

All three of them are dependencies of docker-buildx.
I started from the version v0.15.1 of docker-buildx as it is the last 
one that explicitly requires the version v26.1.x for these packages (the 
current version in Debian unstable). But I still get some missing 
packages error for these modules. Do you have an idea why?


For example:

src/github.com/docker/buildx/util/confutil/config.go:8:2: cannot find 
package "github.com/docker/cli/cli/command" in any of:

/usr/lib/go-1.23/src/github.com/docker/cli/cli/command (from $GOROOT)

/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/docker/cli/cli/command
 (from $GOPATH)

/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/util/tracing/delegated
 (from $GOPATH)
src/github.com/docker/buildx/driver/kubernetes/context/load.go:10:2: 
cannot find package "github.com/docker/cli/cli/context" in any of:

/usr/lib/go-1.23/src/github.com/docker/cli/cli/context (from $GOROOT)

/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/docker/cli/cli/context
 (from $GOPATH)
src/github.com/docker/buildx/driver/kubernetes/context/load.go:11:2: 
cannot find package "github.com/docker/cli/cli/context/store" in any of:

/usr/lib/go-1.23/src/github.com/docker/cli/cli/context/store (from 
$GOROOT)

/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/docker/cli/cli/context/store
 (from $GOPATH)
src/github.com/docker/buildx/util/dockerutil/api.go:5:2: cannot find 
package "github.com/docker/cli/cli/context/docker" in any of:
	/usr/lib/go-1.23/src/github.com/docker/cli/cli/context/docker (from 
$GOROOT)


/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/docker/cli/cli/context/docker
 (from $GOPATH)
src/github.com/docker/buildx/controller/pb/secrets.go:5:2: cannot find 
package "github.com/moby/buildkit/session/secrets/secretsprovider" in 
any of:


/usr/lib/go-1.23/src/github.com/moby/buildkit/session/secrets/secretsprovider 
(from $GOROOT)

/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/session/secrets/secretsprovider
 (from $GOPATH)
src/github.com/docker/buildx/controller/pb/ssh.go:5:2: cannot find 
package "github.com/moby/buildkit/session/sshforward/sshprovider" in any of:


/usr/lib/go-1.23/src/github.com/moby/buildkit/session/sshforward/sshprovider 
(from $GOROOT)

/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/session/sshforward/sshprovider
 (from $GOPATH)
src/github.com/docker/buildx/build/opt.go:28:2: cannot find package 
"github.com/moby/buildkit/session/upload/uploadprovider" in any of:


/usr/lib/go-1.23/src/github.com/moby/buildkit/session/upload/uploadprovider 
(from $GOROOT)

/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/session/upload/uploadprovider
 (from $GOPATH)
src/github.com/docker/buildx/build/build.go:39:2: cannot find package 
"github.com/moby/buildkit/util/progress/progresswriter" in any of:


/usr/lib/go-1.23/src/github.com/moby/buildkit/util/progress/progresswriter 
(from $GOROOT)

/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/util/progress/progresswriter
 (from $GOPATH)
src/github.com/docker/buildx/bake/bake.go:28:2: cannot find package 
"github.com/moby/buildkit/session/auth/authprovider" in any of:
	/usr/lib/go-1.23/src/github.com/moby/buildkit/session/auth/authprovider 
(from $GOROOT)


/build/reproducible-path/docker-buildx-0.15.1/_build/src/github.com/moby/buildkit/session/auth/authprovider
 (from $GOPATH)


[1] 
https://packages.debian.org/sid/all/golang-github-docker-docker-dev/filelist


--
Nicolas Peugnet

Bug#989917: RFP: docker-buildx -- docker CLI plugin for BuildKit

[Nicolas Peugnet]

Hi,

I would be interested in packaging this component.

I did check the dependency tree and it should not be too difficult. I am 
currently packaging one of the missing dependencies: 
https://github.com/compose-spec/compose-go (will post the ITP soon).


--
Nicolas Peugnet

Bug#1095852: ITP: golang-github-hashicorp-go-cty-funcs -- go-cty specific functions; mainly used in HCL2 templates

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: golang-github-hashicorp-go-cty-funcs
  Version : 0.0~git20250210.dda7798-1
  Upstream Author : HashiCorp
* URL : https://github.com/hashicorp/go-cty-funcs
* License : MPL-2.0
  Programming Lang: Go
  Description : go-cty specific functions; mainly used in HCL2 templates

 go-cty is a dynamic type system for applications written in Go that need
 to represent user-supplied values without losing type information.
 The primary intended use is for implementing configuration languages
 .
 This package provides go-cty specific functions mainly used in HashiCorp
 configuration language (HCL2) tamplates.

This is a dependency of docker-buildx (Bug #989917).

Bug#1095781: ITP: golang-github-docker-cli-docs-tool -- Utilities to generate (reference) documentation for the docker CLI

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: golang-github-docker-cli-docs-tool
  Version : 0.8.0-1
  Upstream Author : Docker
* URL : https://github.com/docker/cli-docs-tool
* License : Apache-2.0
  Programming Lang: Go
  Description : Utilities to generate (reference) documentation for the 
docker CLI

 This is a library containing utilities to generate (reference)
 documentation for the docker CLI (https://github.com/docker/cli) on
 docs.docker.com (https://docs.docker.com/reference/).

It is also capable of generating manual pages. It is a dependency of
docker-buildx (Bug#989917), and docker-cli >= 27.0.

Bug#1040417: docker-compose V1 is depreciated

[Nicolas Peugnet]

On Sun, 19 Jan 2025 23:57:11 + Colin Watson  wrote:

On Sat, Jan 18, 2025 at 05:16:57AM +0900, Kenichiro Matohara wrote:
> In Debian sid, Python 3.13 has been updated and docker-compose no longer
> works.

I uploaded docker-compose 1.29.2-6.4 earlier today to fix that.  (I
can't help with packaging 2.x, though.)


I am currently working on packaging the v2 of docker-compose. As it is 
now a Go package, I will be maintaining it withing Debian's Go team.


It is not fully ready yet. I will see how to convert this bug into an ITP.
--
Nicolas Peugnet

Bug#1101131: icecast2: DoS vector using incorrect TLS teardown

[Nicolas Peugnet]

Package: icecast2
Version: 2.4.4-4+b1
Severity: important
Tags: upstream

Dear Maintainer,

Icecast2 in Debian is affected by this upstream issue with TLS
connections (https://gitlab.xiph.org/xiph/icecast-server/-/issues/2355):
> When in a TLS SOURCE connection the socket is closed without TLS
> teardown Icecast will read from the socket in a tight endless loop.
> This locks up the corresponding thread.

This has been visibly patched in upstream's VCS, in a 2.4.5 branch that
looks like it has not been released yet:
https://gitlab.xiph.org/xiph/icecast-server/-/commit/8662884447efc414e885b20b965f465d37a01fb5

I applied this patch by simply dowloading the txt version from GitLab:
https://gitlab.xiph.org/xiph/icecast-server/-/commit/8662884447efc414e885b20b965f465d37a01fb5.patch

I am currently running a patched version of icecast2 and the problems
seems to be fixed.

A reliable way to reproduce the issue is to enable TLS, create a stream
with BUTT and have at least one listener (e.g. with firefox), then click
the stop button of BUTT. This make icecast use 100% of a CPU while
beeing in a waiting state.

The bug did not happen back yet with the patched version.

Could you please add this patch to the patch series?
-- 
Nicolas Peugnet

Bug#1100991: docker-buildx: CVE-2025-0495

[Nicolas Peugnet]

On Fri, 21 Mar 2025 14:24:26 +0100 Moritz Mühlenhoff  
wrote:> The following vulnerability was published for docker-buildx.


CVE-2025-0495[0]:
| Buildx is a Docker CLI plugin that extends build capabilities using
| BuildKit.  Cache backends support credentials by setting secrets
| directly as attribute values in cache-to/cache-from configuration.
| When supplied as user input, these secure values may be
| inadvertently captured in OpenTelemetry traces as part of the
| arguments and flags for the traced CLI command. OpenTelemetry traces
| are also saved in BuildKit daemon's history records.   This
| vulnerability does not impact secrets passed to the Github cache
| backend via environment variables or registry authentication.

https://github.com/docker/buildx/security/advisories/GHSA-m4gq-fm9h-8q75
 


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


I pushed commit [b16d18a] to a branch as it is my first time fixing a 
CVE, I am not sure exactly what else I need to do.


From what I understand of the release notes [1], this commit should be 
enough to fix the CVE.


See also the diff for this release: 
https://github.com/docker/buildx/compare/v0.21.2...v0.21.3


[b16d18a]: 
https://salsa.debian.org/go-team/packages/docker-buildx/-/commit/b16d18af52c18d0a2d3499c7d0839d9da3a76f5b

[1]: https://github.com/docker/buildx/releases/tag/v0.21.3
--
Nicolas Peugnet

Bug#1096242: golang-k8s-kube-openapi: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 k8s.io/kube-openapi/cmd/openapi-gen [...] k8s.io/kube-openapi/test/integration/testutil returned

[Nicolas Peugnet]

On 13/03/2025 16:28, Nicolas Peugnet wrote:

After investigation, this panic also occurs from an upstream checkout:

$ git checkout ab13479
$ go test ./pkg/generators/
E0313 16:22:11.669135 3181592 openapi.go:322] Error when generating: 
StringToArray, StringToArray map[string]map[string]map[int]string
E0313 16:22:11.669232 3181592 openapi.go:322] Error when generating: 
StringToArray, StringToArray map[int]string
E0313 16:22:11.669297 3181592 openapi.go:322] Error when generating: 
Int, Int int
E0313 16:22:11.669358 3181592 openapi.go:322] Error when generating: 
Struct, Struct struct{foo int}
E0313 16:22:11.669424 3181592 openapi.go:322] Error when generating: 
List, List []base/foo.Item
E0313 16:22:11.669487 3181592 openapi.go:322] Error when generating: 
Map, Map map[string]base/foo.Item

--- FAIL: TestCustomDef (3.04s)
panic: can't find import for sync [recovered]
 panic: can't find import for sync

goroutine 69 [running]:
testing.tRunner.func1.2({0xb396c0, 0xc00baaf020})
 /usr/lib/go-1.24/src/testing/testing.go:1734 +0x21c
testing.tRunner.func1()
 /usr/lib/go-1.24/src/testing/testing.go:1737 +0x35e
panic({0xb396c0?, 0xc00baaf020?})
 /usr/lib/go-1.24/src/runtime/panic.go:787 +0x132
k8s.io/gengo/generator.golangTrackerLocalName({0xd7ce20, 0xc0018c7aa0}, 
{{0xc00b3aaa40, 0x4}, {0xc00b90839d, 0x3}, {0x0, 0x0}})
 /home/nicolas/go/pkg/mod/k8s.io/ 
gengo@v0.0.0-20230829151522-9cce18d56c01/generator/import_tracker.go:88 
+0x2b4
k8s.io/gengo/generator.NewImportTrackerForPackage.func2({{0xc00b3aaa40, 
0x4}, {0xc00b90839d, 0x3}, {0x0, 0x0}})
 /home/nicolas/go/pkg/mod/k8s.io/ 
gengo@v0.0.0-20230829151522-9cce18d56c01/generator/import_tracker.go:48 
+0x58
k8s.io/gengo/namer.(*DefaultImportTracker).AddSymbol(0xc0018c7aa0, 
{{0xc00b3aaa40, 0x4}, {0xc00b90839d, 0x3}, {0x0, 0x0}})
 /home/nicolas/go/pkg/mod/k8s.io/ 
gengo@v0.0.0-20230829151522-9cce18d56c01/namer/import_tracker.go:74 +0xe9
k8s.io/gengo/namer.(*DefaultImportTracker).AddType(0xc0018c7aa0, 
0xc00b9343c0)
 /home/nicolas/go/pkg/mod/k8s.io/ 
gengo@v0.0.0-20230829151522-9cce18d56c01/namer/import_tracker.go:94 +0x145

k8s.io/gengo/namer.(*rawNamer).Name(0xc0019596e0, 0xc00b9343c0)
 /home/nicolas/go/pkg/mod/k8s.io/ 
gengo@v0.0.0-20230829151522-9cce18d56c01/namer/namer.go:328 +0x4bb
k8s.io/gengo/namer.tList.Less({{0xd74920, 0xc0019596e0}, {0xc00b404808, 
0x655, 0x8ff}}, 0xc00ba95dd0?, 0x0)
 /home/nicolas/go/pkg/mod/k8s.io/ 
gengo@v0.0.0-20230829151522-9cce18d56c01/namer/order.go:71 +0x4e

sort.partition({0xd7a820, 0xc00ba95dd0}, 0x0, 0x655, 0x40f725?)
 /usr/lib/go-1.24/src/sort/zsortinterface.go:154 +0x175
sort.pdqsort({0xd7a820, 0xc00ba95dd0}, 0xbe3b80?, 0x41be01?, 0xc00ba95dd0?)
 /usr/lib/go-1.24/src/sort/zsortinterface.go:114 +0x225
sort.Sort({0xd7a820, 0xc00ba95dd0})
 /usr/lib/go-1.24/src/sort/sort.go:54 +0x54
k8s.io/gengo/namer.(*Orderer).OrderUniverse(0xc001993450?, 0xc5f5ba?)
 /home/nicolas/go/pkg/mod/k8s.io/ 
gengo@v0.0.0-20230829151522-9cce18d56c01/namer/order.go:50 +0x1d4
k8s.io/kube-openapi/pkg/generators.construct(0xc000103a40, 0xcc3cd0, 
{0xd74920, 0xc0019596e0})

 /tmp/kube-openapi/pkg/generators/openapi_test.go:47 +0x205
k8s.io/kube-openapi/pkg/generators.testOpenAPITypeWriter(0xc000103a40, 
{0xc965be, 0x138})

 /tmp/kube-openapi/pkg/generators/openapi_test.go:68 +0x32c
k8s.io/kube-openapi/pkg/generators.TestCustomDef(0xc000103a40)
 /tmp/kube-openapi/pkg/generators/openapi_test.go:987 +0x2b
testing.tRunner(0xc000103a40, 0xca3268)
 /usr/lib/go-1.24/src/testing/testing.go:1792 +0xf4
created by testing.(*T).Run in goroutine 1
 /usr/lib/go-1.24/src/testing/testing.go:1851 +0x413
FAIL    k8s.io/kube-openapi/pkg/generators    3.217s
FAIL

It seems that it comes in fact from [gengo], which has been bumped to v2 
at some point. The latest upstream version of kube-openapi does not 
exhibit such a panic, so we probably will have to import newer versions 
of both gengo and kube-openapi. I'll see what I can do.


[gengo]: https://github.com/kubernetes/gengo


I managed to update both [gengo] and [kube-openapi] to compatible 
versions that I pushed to their respective repository. I also made a bit 
of cleaning by the way.


I am in the process of running ratt on the 65 reverse dependencies, and 
for now, out of 55 done, all passed (except the ones already failing in 
unstable). So I am fairly confident that it won't break anything.


I still need someone to do the upload for me (I left the changelog as 
UNRELEASED for now).


[gengo]: https://salsa.debian.org/go-team/packages/golang-k8s-gengo
[kube-openapi]: 
https://salsa.debian.org/go-team/packages/golang-k8s-kube-openapi

--
Nicolas Peugnet

Bug#1101376: ITP: package-assembler -- CLI tool to create necessary files for a Debian package

[Nicolas Peugnet]

On 27/03/2025 13:50, Simon Josefsson wrote:

I've found the 'dh-make-golang make' tool incredibly useful to quickly
get a suitable debian/* template for a project.  I would find a similar
tool that isn't Go-specific which would could an upstream tarball and/or
a URL to a homepage and attempt to create a debian/* template a missing
tool to faciliate Debian package creation.


The thing is, there are already a lot of them:
https://wiki.debian.org/AutomaticPackagingTools
--
Nicolas Peugnet

Bug#1006956: Acknowledgement (tt-rss spits a lot of php warnings)

[Nicolas Peugnet]

On Fri, 3 Nov 2023 11:21:40 +0100 VA  wrote:> Are there 
any news on this? In just one week:


journalctl -S 2023-10-27 _SYSTEMD_UNIT=tt-rss.service | wc -l
1057249

And logs that are not about garbage:

journalctl -S 2023-10-27 _SYSTEMD_UNIT=tt-rss.service | grep -iv warning 
| grep -iv deprecated | wc -l

1051

So a whopping 99.9% of tt-rss logs are absolute garbage that just point 
at badly written code.
The best thing would be of course to fix those deprecation warnings, but 
at least we could hide them to avoid consuming disk space with 
completely useless stuff.
In our case, what I ended up doing is to filter all of these logs out 
using the LogFilterPatterns [1] of systemd v253+ (installed from 
bookworm-backports), by adding a systemd override file:


diff --git a/systemd/system/tt-rss.service.d/override.conf 
b/systemd/system/tt-rss.service.d/override.conf

new file mode 100644
index ..9f4f6479
--- /dev/null
+++ b/systemd/system/tt-rss.service.d/override.conf
@@ -0,0 +1,2 @@
+[Service]
+LogFilterPatterns=~E_WARNING|E_DEPRECATED|E_NOTICE|PHP Warning


[1]: 
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#LogFilterPatterns=

--
Nicolas Peugnet

Bug#1074600: openarc: abandoned upstream

[Nicolas Peugnet]

Hi,

On Mon, 1 Jul 2024 13:52:14 -0700 Matt Taggart  wrote:> 
* The upstream openarc project has not had a commit to master branch

since Sept 21, 2018. (there is a develop branch last Oct 16, 2020)
* There are many unresolved issues in it's issue tracker


The Archlinux Wiki's OpenARC page [1] made me discover this actively 
maintained fork: https://github.com/flowerysong/OpenARC


It may be interesting to switch to this upstream?

[1]: https://wiki.archlinux.org/title/OpenARC
--
Nicolas Peugnet

Bug#1040417: docker-compose V1 is depreciated

[Nicolas Peugnet]

On 18/02/2025 14:45, Colin Watson wrote:

On Tue, Feb 18, 2025 at 01:44:35PM +0100, Nicolas Peugnet wrote:

Maybe it would be good to have an entry in the NEWS.Debian file?


NEWS.Debian entries should be user-focused.  So if you write one (I
don't know whether it makes sense), it should be about things like
incompatible changes that a user of the package would need to know
about, as opposed to internal details such as which language the package
is now written in.


So about this, reading Docker Compose's migration docs [1], one of the 
most disruptive change seems that previously the command was run as 
"docker-compose" and now as "docker compose".


I was thinking that we should add something similar to what is explained 
in the "What does this mean for my projects..." section:

For most projects, switching to Compose V2 requires no changes to the Compose 
YAML or your development workflow.

It's recommended that you adapt to the new preferred way of running Compose V2, which is to use 
"docker compose" instead of "docker-compose". This provides additional 
flexibility and removes the requirement for a docker-compose compatibility alias.

However, Docker Desktop continues to support a "docker-compose" alias to redirect 
commands to "docker compose" for convenience and improved compatibility with third-party 
tools and scripts.


It is already quite good as is, but I did not understand at first that 
the alias was not provided by the Docker packages, and it was the users 
that had to add it themselves. I think we can be more precise than this 
and explain that one needs to create the alias.


[1] 
https://docs.docker.com/compose/releases/migrate/#what-are-the-differences-between-compose-v1-and-compose-v2

--
Nicolas Peugnet

Bug#1040417: docker-compose V1 is depreciated

[Nicolas Peugnet]

On 18/02/2025 14:45, Colin Watson wrote:

On Tue, Feb 18, 2025 at 01:44:35PM +0100, Nicolas Peugnet wrote:

Colin: do you have some advice on how to properly package docker-compose?


No, sorry.  I don't know Go particularly well, and I hardly ever use
Docker.


Also should I copy the content of the changelog from the v1 package?


IMO yes.


Ok, I just did it.


Maybe it would be good to have an entry in the NEWS.Debian file?


NEWS.Debian entries should be user-focused.  So if you write one (I
don't know whether it makes sense), it should be about things like
incompatible changes that a user of the package would need to know
about, as opposed to internal details such as which language the package
is now written in.


Thank you for your quick answer and your tips. Sorry, I noticed only 
after sending my email that you are not a maintainer of docker-compose.


One last question, the Debian developer reference states that:

It is not OK to simply take over a package without assent of the current 
maintainer — that would be package hijacking. You can, of course, contact the 
current maintainer and ask them for permission to take over the package.


So I am adding the persons listed as uploaders, to make sure they read 
this email.


As the v2 of docker-compose has been rewritten in Go, I started 
packaging it from scratch and I indent to maintain it within Debian's Go 
team. Do you agree to let me and the Debian Go team take over the package?


Is there anything else I would need to do in order to not do a "package 
hijack"?

--
Nicolas Peugnet

Bug#1040417: docker-compose V1 is depreciated

[Nicolas Peugnet]

On 16/02/2025 11:17, Nicolas Peugnet wrote:
On Sun, 19 Jan 2025 23:57:11 + Colin Watson  
wrote:

I uploaded docker-compose 1.29.2-6.4 earlier today to fix that.  (I
can't help with packaging 2.x, though.)


I am currently working on packaging the v2 of docker-compose. As it is 
now a Go package, I will be maintaining it withing Debian's Go team.


It is not fully ready yet. I will see how to convert this bug into an ITP.


So, here is my current packaging work: 
https://salsa.debian.org/go-team/packages/docker-compose


It still need one dependency not uploaded yet and one that is in NEW. 
But it compiles fine and seems to work OK. It still need a lot of 
polishing though and I plan to upload it first to experimental.


Colin: do you have some advice on how to properly package 
docker-compose? Also should I copy the content of the changelog from the 
v1 package? Maybe it would be good to have an entry in the NEWS.Debian file?

--
Nicolas Peugnet

Bug#1040417: docker-compose V1 is depreciated

[Nicolas Peugnet]

Hi,

On 18/02/2025 15:24, Andrej Shadura wrote:

On Tue, 18 Feb 2025, at 15:10, Nicolas Peugnet wrote:

As the v2 of docker-compose has been rewritten in Go, I started
packaging it from scratch and I indent to maintain it within Debian's Go
team. Do you agree to let me and the Debian Go team take over the package?

Is there anything else I would need to do in order to not do a "package
hijack"?


Please before you upload anything, publish your work in a Git repo on Salsa.
I would like to eventually join the effort (even though I haven’t had time to 
look at it so far).


Of course, here it is:
https://salsa.debian.org/go-team/packages/docker-compose

I would be glad if you joined me on this effort :)

As I said, it currently needs one dependency that is not yet uploaded, 
and one that is in NEW, respectively golang-github-r3labs-sse [1] and 
docker-buildx [2] (targeted at experimental for now).


[1] https://salsa.debian.org/go-team/packages/golang-github-r3labs-sse
[2] https://salsa.debian.org/go-team/packages/docker-buildx
--
Nicolas Peugnet

Bug#1096140: package new upstream and Go code?

[Nicolas Peugnet]

On 18/02/2025 01:21, Simon Josefsson wrote:

There is now a crude patch that add Go package to libcap2 here:

https://salsa.debian.org/jas/libcap2/-/commit/cc9f4c1554798f0baec9d2fe00d45a559458f866


As a suggestion, it would probably be good to add the nogolang build 
profile [1] to the generated go package and wrap the parts that build go 
files in a DEB_BUILD_PROFILES check.



Nicolas, you said libcap2's Go packages was used by docker-buildx.  Are
you able to test the libcap2 Go packages above with docker-buildx?  I'm
thinking that if you are also able to get something useful out of the
libcap2 Go packages, we are more likely to be on the right track.


I made a mistake, it was needed by (a test of) buildkit, not 
docker-buildx, but I'll take a look.


[1] https://wiki.debian.org/BuildProfileSpec#Registered_profile_names
--
Nicolas Peugnet

Bug#1100090: ITP: didder -- An extensive, fast, and accurate command-line image dithering tool.

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: didder
  Version : 1.3.0-1
  Upstream Author : makeworld
* URL : https://github.com/makeworld-the-better-one/didder
* License : GPL-3.0
  Programming Lang: Go
  Description : An extensive, fast, and accurate command-line image 
dithering tool.

 didder is an extensive, fast, and accurate command-line image dithering
 tool. It is designed to work well for both power users as well as
 pipeline scripting. It is backed by the author's dithering library
 (https://github.com/makeworld-the-better-one/dither), and is unique
 in its correctness and variety of dithering algorithms. It provides
 many options, while being correct (linearizing the image, weighting
 channels by luminance).
 .
 Types of dithering supported
 .
  * Random noise (in grayscale and RGB)
  * Ordered Dithering
* Bayer matrix of any size (as long as dimensions are powers of two)
* Clustered-dot - many different preprogrammed matrices
* Some unusual horizontal or vertical line matrices
* Yours? You can provide your own ordered dithering matrix in JSON format
  * Error diffusion dithering
* Simple 2D
* Floyd-Steinberg, False Floyd-Steinberg
* Jarvis-Judice-Ninke
* Atkinson
* Stucki
* Burkes
* Sierra/Sierra3, Sierra2, Sierra2-4A/Sierra-Lite
* Steven Pigeon (https://hbfs.wordpress.com/2013/12/31/dithering/)
* Yours? You can provide your own error diffusion matrix in JSON format
 .
 Features
 .
  * Set palette using RGB tuples, hex codes, number 0-255 (grayscale), or
SVG color names (https://www.w3.org/TR/SVG11/types.html#ColorKeywords)
  * Optionally recolor image with a different palette after dithering
  * Set dithering strength
  * Image is automatically converted to grayscale if palette is grayscale
  * Force image to grayscale with --grayscale
  * Change image saturation, brightness, or contrast before dithering
  * Read EXIF rotation tags by default (disabled with --no-exif-rotation)
  * Downscale image before dithering, keeping aspect ratio
  * Upscale image after dithering, without producing artifacts
  * Supports input image of types JPEG, GIF (static), PNG, BMP, TIFF
  * Output to PNG or GIF
  * Process multiple images with one command
  * Combine multiple images into an animated GIF
  * Uses all CPU cores when possible
  * Support images with transparency (alpha channel is kept the same)

This is a fine little CLI tool that is easy to use, and all of its
dependencies are already packaged in Debian.

Bug#1096242: golang-k8s-kube-openapi: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 k8s.io/kube-openapi/cmd/openapi-gen [...] k8s.io/kube-openapi/test/integration/testutil returned

[Nicolas Peugnet]

On Mon, 17 Feb 2025 17:35:20 +0100 Lucas Nussbaum  
wrote:> During a rebuild of all packages in sid, your package failed to 
build

on amd64.


Relevant part (hopefully):
> === RUN   TestCustomDef
> --- FAIL: TestCustomDef (2.61s)
> panic: can't find import for sync [recovered]
>panic: can't find import for sync
> [...]
> FAIL   k8s.io/kube-openapi/pkg/generators  3.213s
> === RUN   TestListTypeMissing
> --- PASS: TestListTypeMissing (0.00s)


After investigation, this panic also occurs from an upstream checkout:

$ git checkout ab13479
$ go test ./pkg/generators/
E0313 16:22:11.669135 3181592 openapi.go:322] Error when generating: 
StringToArray, StringToArray map[string]map[string]map[int]string
E0313 16:22:11.669232 3181592 openapi.go:322] Error when generating: 
StringToArray, StringToArray map[int]string
E0313 16:22:11.669297 3181592 openapi.go:322] Error when generating: 
Int, Int int
E0313 16:22:11.669358 3181592 openapi.go:322] Error when generating: 
Struct, Struct struct{foo int}
E0313 16:22:11.669424 3181592 openapi.go:322] Error when generating: 
List, List []base/foo.Item
E0313 16:22:11.669487 3181592 openapi.go:322] Error when generating: 
Map, Map map[string]base/foo.Item

--- FAIL: TestCustomDef (3.04s)
panic: can't find import for sync [recovered]
panic: can't find import for sync

goroutine 69 [running]:
testing.tRunner.func1.2({0xb396c0, 0xc00baaf020})
/usr/lib/go-1.24/src/testing/testing.go:1734 +0x21c
testing.tRunner.func1()
/usr/lib/go-1.24/src/testing/testing.go:1737 +0x35e
panic({0xb396c0?, 0xc00baaf020?})
/usr/lib/go-1.24/src/runtime/panic.go:787 +0x132
k8s.io/gengo/generator.golangTrackerLocalName({0xd7ce20, 0xc0018c7aa0}, 
{{0xc00b3aaa40, 0x4}, {0xc00b90839d, 0x3}, {0x0, 0x0}})


/home/nicolas/go/pkg/mod/k8s.io/gengo@v0.0.0-20230829151522-9cce18d56c01/generator/import_tracker.go:88
 +0x2b4
k8s.io/gengo/generator.NewImportTrackerForPackage.func2({{0xc00b3aaa40, 
0x4}, {0xc00b90839d, 0x3}, {0x0, 0x0}})


/home/nicolas/go/pkg/mod/k8s.io/gengo@v0.0.0-20230829151522-9cce18d56c01/generator/import_tracker.go:48
 +0x58
k8s.io/gengo/namer.(*DefaultImportTracker).AddSymbol(0xc0018c7aa0, 
{{0xc00b3aaa40, 0x4}, {0xc00b90839d, 0x3}, {0x0, 0x0}})


/home/nicolas/go/pkg/mod/k8s.io/gengo@v0.0.0-20230829151522-9cce18d56c01/namer/import_tracker.go:74
 +0xe9
k8s.io/gengo/namer.(*DefaultImportTracker).AddType(0xc0018c7aa0, 
0xc00b9343c0)


/home/nicolas/go/pkg/mod/k8s.io/gengo@v0.0.0-20230829151522-9cce18d56c01/namer/import_tracker.go:94
 +0x145
k8s.io/gengo/namer.(*rawNamer).Name(0xc0019596e0, 0xc00b9343c0)

/home/nicolas/go/pkg/mod/k8s.io/gengo@v0.0.0-20230829151522-9cce18d56c01/namer/namer.go:328
 +0x4bb
k8s.io/gengo/namer.tList.Less({{0xd74920, 0xc0019596e0}, {0xc00b404808, 
0x655, 0x8ff}}, 0xc00ba95dd0?, 0x0)


/home/nicolas/go/pkg/mod/k8s.io/gengo@v0.0.0-20230829151522-9cce18d56c01/namer/order.go:71
 +0x4e
sort.partition({0xd7a820, 0xc00ba95dd0}, 0x0, 0x655, 0x40f725?)
/usr/lib/go-1.24/src/sort/zsortinterface.go:154 +0x175
sort.pdqsort({0xd7a820, 0xc00ba95dd0}, 0xbe3b80?, 0x41be01?, 0xc00ba95dd0?)
/usr/lib/go-1.24/src/sort/zsortinterface.go:114 +0x225
sort.Sort({0xd7a820, 0xc00ba95dd0})
/usr/lib/go-1.24/src/sort/sort.go:54 +0x54
k8s.io/gengo/namer.(*Orderer).OrderUniverse(0xc001993450?, 0xc5f5ba?)

/home/nicolas/go/pkg/mod/k8s.io/gengo@v0.0.0-20230829151522-9cce18d56c01/namer/order.go:50
 +0x1d4
k8s.io/kube-openapi/pkg/generators.construct(0xc000103a40, 0xcc3cd0, 
{0xd74920, 0xc0019596e0})

/tmp/kube-openapi/pkg/generators/openapi_test.go:47 +0x205
k8s.io/kube-openapi/pkg/generators.testOpenAPITypeWriter(0xc000103a40, 
{0xc965be, 0x138})

/tmp/kube-openapi/pkg/generators/openapi_test.go:68 +0x32c
k8s.io/kube-openapi/pkg/generators.TestCustomDef(0xc000103a40)
/tmp/kube-openapi/pkg/generators/openapi_test.go:987 +0x2b
testing.tRunner(0xc000103a40, 0xca3268)
/usr/lib/go-1.24/src/testing/testing.go:1792 +0xf4
created by testing.(*T).Run in goroutine 1
/usr/lib/go-1.24/src/testing/testing.go:1851 +0x413
FAILk8s.io/kube-openapi/pkg/generators  3.217s
FAIL

It seems that it comes in fact from [gengo], which has been bumped to v2 
at some point. The latest upstream version of kube-openapi does not 
exhibit such a panic, so we probably will have to import newer versions 
of both gengo and kube-openapi. I'll see what I can do.


[gengo]: https://github.com/kubernetes/gengo
--
Nicolas Peugnet

Bug#1100409: ITP: golang-github-microsoft-hcsshim -- Windows - Host Compute Service Shim

[Nicolas Peugnet]

13 mars 2025 15:45:31 Roland Mas :


Package: wnpp
Severity: wishlist
Owner: Roland Mas 

* Package name    : golang-github-microsoft-hcsshim
  Version : 0.13.0~rc3-1
  Upstream Author : Microsoft
* URL : https://github.com/Microsoft/hcsshim
* License : Expat
  Programming Lang: Go
  Description : Windows - Host Compute Service Shim

hcsshim
.
[Image: Build status]
(https://github.com/microsoft/hcsshim/actions/workflows/ci.yml/badge.
svg?branch=master)
(https://github.com/microsoft/hcsshim/actions?query=branch%3Amaster)
.
This package contains the Golang interface for using the Windows Host
Compute Service

(https://techcommunity.microsoft.com/t5/containers/introducing-the-host-
compute-service-hcs/ba-p/382332) (HCS) to launch and manage Windows
Containers (https://docs.microsoft.com/en-
us/virtualization/windowscontainers/about/). It also contains other
helpers and functions for managing Windows Containers such as the 
Golang

interface for the Host Network Service (HNS), as well as code for the
guest agent (/internal/guest/README.md) (commonly referred to as the 
GCS

or Guest Compute Service in the codebase) used to support running Linux
Hyper-V containers.
.
It is primarily used in the Moby (https://github.com/moby/moby) and
Containerd (https://github.com/containerd/containerd) projects, but it
can be freely used by other projects as well.
.
Building
.
While this repository can be used as a library of sorts to call the HCS
apis, there are a couple binaries built out of the repository as well.
The main ones being the Linux guest agent, and an implementation of the
runtime v2 containerd shim api

(https://github.com/containerd/containerd/blob/master/runtime/v2/README.
md).
This is a windows specific library. You probably don't really need it in 
Debian and you should probably patch it out of the project that needs it, 
as it is done in Docker packages.


--
Nicolas Peugnet

Bug#1096131: ITP: golang-github-r3labs-sse -- Server Sent Events server and client for Golang

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: golang-github-r3labs-sse
  Version : 2.10.0-1
  Upstream Author : R3 Labs
* URL : https://github.com/r3labs/sse
* License : MPL-2.0
  Programming Lang: Go
  Description : Server Sent Events server and client for Golang

 With server-sent events, it's possible for a server to send new data
 to a web page at any time, by pushing messages to the web page.
 .
 This library provides a server and a client implementation of SSE for
 Go.

This is a dependency of docker-compose v2.

Bug#1096140: package new upstream and Go code?

[Nicolas Peugnet]

On 18/02/2025 15:59, Nicolas Peugnet wrote:

On 18/02/2025 01:21, Simon Josefsson wrote:

Nicolas, you said libcap2's Go packages was used by docker-buildx.  Are
you able to test the libcap2 Go packages above with docker-buildx?  I'm
thinking that if you are also able to get something useful out of the
libcap2 Go packages, we are more likely to be on the right track.


I made a mistake, it was needed by (a test of) buildkit, not docker- 
buildx, but I'll take a look.
I tried to enable back this test, it compiled fine but it couldn't run, 
as other parts of this particular tests also required to be root. I 
didn't find an easy way to run this test as root.


Maybe we should find a very simple example program that uses this library?
--
Nicolas Peugnet

Bug#1096213: golang-golang-x-exp: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 golang.org/x/exp/constraints golang.org/x/exp/ebnf golang.org/x/exp/ebnflint golang.org/x/exp/io/i2c

[Nicolas Peugnet]

On Mon, 17 Feb 2025 17:12:06 +0100 Lucas Nussbaum  
wrote:> Hi,


During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):

 [...]
=== RUN   TestAPIConsistency
typeparams_test.go:39: "*TypeList.Types": got func()(Seq[Type]) at 1.18+, 
but  at 1.17
typeparams_test.go:39: "*Union.Terms": got func()(Seq[*Term]) at 1.18+, but 
 at 1.17
typeparams_test.go:39: "*TypeParamList.TypeParams": got 
func()(Seq[*TypeParam]) at 1.18+, but  at 1.17
--- FAIL: TestAPIConsistency (0.86s)
FAIL


I just made a merge request on salsa that would fix this: 
https://salsa.debian.org/go-team/packages/golang-golang-x-exp/-/merge_requests/1


--
Nicolas Peugnet

Bug#1099026: prometheus: TestQueryConcurrency is flaky, at least on ppc64el

[Nicolas Peugnet]

Source: prometheus
Version: 2.53.3+ds1-1
Severity: normal

Dear Maintainer,

On Debian CI, one of the runs of prometheus failed because of a failure
of the test "TestQueryConcurrency":
https://ci.debian.net/packages/p/prometheus/testing/ppc64el/58296167/

578s === RUN   TestQueryConcurrency
578s engine_test.go:108: 
578sError Trace:
/tmp/autopkgtest-lxc.343aby_v/downtmp/autopkgtest_tmp/.build/src/github.com/prometheus/prometheus/promql/engine_test.go:108
578sError:  Query within concurrency threshold not being 
executed
578sTest:   TestQueryConcurrency
578s unexpected fault address 0x7fff39681389
578s fatal error: fault
578s [signal SIGSEGV: segmentation violation code=0x1 addr=0x7fff39681389 
pc=0x9f7b4]

This run was triggered by an update to golang-golang-x-exp that did not
change any of the non-testing related code. So it should not have any
incidence on the dependent packages.

I decided to run it once again with the same configuration and this time
it passed without issues:
https://ci.debian.net/packages/p/prometheus/testing/ppc64el/58300217/

So it seems this test is flaky, I am not sure what it the best way to
deal with it.

Bug#1100991: docker-buildx: CVE-2025-0495

[Nicolas Peugnet]

On 21/03/2025 18:05, Nicolas Peugnet wrote:
I pushed commit [b16d18a] to a branch as it is my first time fixing a 
CVE, I am not sure exactly what else I need to do.


 From what I understand of the release notes [1], this commit should be 
enough to fix the CVE.


See also the diff for this release: https://github.com/docker/buildx/ 
compare/v0.21.2...v0.21.3


[b16d18a]: https://salsa.debian.org/go-team/packages/docker-buildx/-/ 
commit/b16d18af52c18d0a2d3499c7d0839d9da3a76f5b

[1]: https://github.com/docker/buildx/releases/tag/v0.21.3


After taking a look at "Fixing CVEs on Debian: Everything you probably 
know already - DebConf24" [1], I made a few changes to my commit and 
created a draft pull request: 
https://salsa.debian.org/go-team/packages/docker-buildx/-/merge_requests/1


[1]: https://www.youtube.com/watch?v=XzNVVILVyUM
--
Nicolas Peugnet