Bug#1054206: ITP: lsprotocol -- Python implementation of the Language Server Protocol types

[Arto Jantunen]

Package: wnpp
Severity: wishlist
Owner: Arto Jantunen 
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: block 1054205 by -1

* Package name: lsprotocol
  Version : 2023.0.0b1
  Upstream Contact: Microsoft Corporation 
* URL : https://github.com/microsoft/lsprotocol
* License : MIT
  Programming Lang: Python
  Description : Python implementation of the Language Server Protocol types

lsprotocol is a Python implementation of object types used in the Language
Server Protocol (LSP).

This is needed as a dependency of python-lsp-ruff. I will maintain it under
the Python team.

Bug#1054205: ITP: python-lsp-ruff -- Ruff linting plugin for pylsp

[Arto Jantunen]

Package: wnpp
Severity: wishlist
Owner: Arto Jantunen 
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: block -1 by 1030835

* Package name: python-lsp-ruff
  Version : 1.5.3
  Upstream Contact: Julian Hossbach 
* URL : https://github.com/python-lsp/python-lsp-ruff/
* License : MIT
  Programming Lang: Python
  Description : Ruff linting plugin for pylsp

python-lsp-ruff is a plugin for python-lsp-server that adds linting, code
action and formatting capabilities that are provided by ruff, an extremely
fast Python linter written in Rust.

I will maintain it under the Python team.

Bug#970042: galera-4: FTBFS on powerpc: R_PPC_REL24 relocation at 0x00b16a7c for symbol `strcmp' out of range

[Otto Kekäläinen]

Last time this specific R_PPC_REL24 relocation failure was seen in
Debian build logs was for 26.4.6-1 in
https://buildd.debian.org/status/fetch.php?pkg=galera-4=powerpc=26.4.6-1=1604830153=0.

It has not occurred since and didn't happen on the latest 26.4.16-2
either, which had extra UBSAN issues fixed via
https://salsa.debian.org/mariadb-team/galera-4/-/commit/19f010d78a98d8c481b57de27b0b59cdad8b979d

Bug#970043: Info received (galera-4: FTBFS on ia64: [libgalera_smm.so] Error 1)

[Otto Kekäläinen]

Control: forwarded -1 https://github.com/codership/galera/issues/648

I uploaded to https://buildd.debian.org/status/package.php?p=galera-4
as 26.4.16-2 with the
https://github.com/codership/galera/commit/4433dbf94bbb8318ca5b7b84fbc4f0f070e66377
included.

The ia64 build is now failing visibly in
https://buildd.debian.org/status/fetch.php?pkg=galera-4=ia64=26.4.16-2=1697689924=0
with

[ 97%] Building CXX object
galera/tests/CMakeFiles/galera_check.dir/data_set_check.cpp.o
cd /<>/obj-ia64-linux-gnu/galera/tests && /usr/bin/c++
-DBOOST_DATE_TIME_POSIX_TIME_STD_CONFIG=1 -DGALERA_HAVE_SSL
-DGU_CRC32C_NO_HARDWARE -DHAVE_ASIO_HPP -DHAVE_BOOST_SHARED_PTR_HPP
-DHAVE_BYTESWAP_H -DHAVE_COMMON_H -DHAVE_ENDIAN_H -DHAVE_STD_ARRAY
-DHAVE_STD_UNORDERED_MAP -DNDEBUG -DOPENSSL_HAS_SET_ECDH_AUTO
-I/<> -I/<>/common
-I/<>/galera/src -I/<>/galerautils/src
-I/<>/gcache/src -I/<>/gcomm/src
-I/<>/gcs/src -I/<>/wsrep/src -isystem
/<>/asio -g -O2 -ffile-prefix-map=/<>=.
-specs=/usr/share/dpkg/pie-compile.specs -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra
-Woverloaded-virtual -g -std=gnu++11 -fPIE -Wno-conversion
-Wno-unused-parameter -MD -MT
galera/tests/CMakeFiles/galera_check.dir/data_set_check.cpp.o -MF
CMakeFiles/galera_check.dir/data_set_check.cpp.o.d -o
CMakeFiles/galera_check.dir/data_set_check.cpp.o -c
/<>/galera/tests/data_set_check.cpp
Checking library symbol visibility (hidden)
sh -c "! /usr/bin/objdump -T libgalera_smm.so | grep asio"
003c2f40 lDF .text 0680
_ZN4asio6detail16service_registry6createINS0_9schedulerENS_17execution_contextEEEPNS4_7serviceEPv
00400ec0 lDF .text 0590
_ZN4asio6detail16service_registry6createINS0_23reactive_socket_serviceINS_2ip3tcpEEENS_10io_contextEEEPNS_17execution_context7serviceEPv
003babc0 lDF .text 0220
_ZNK4asio6detail11timer_queueINS0_18chrono_time_traitsINSt6chrono3_V212steady_clockENS_11wait_traitsIS5_E18wait_duration_msecEl
00410c00 lDF .text 1430
_ZN4asio6detail25reactive_socket_accept_opINS_12basic_socketINS_2ip3tcpENS_8executorEEES4_N5boost3_bi6bind_tIvNS7_4_mfi3mf3IvN2gu17AsioAcceptorReactERKSt10shared_ptrINSC_15AsioStreamReactEERKSE_INSC_19AsioAcceptorHandlerEERKSt10error_codeEENS8_5list4INS8_5valueISE_ISD_EEENSS_ISG_EENSS_ISK_EEPFNS7_3argILi1EEEvENS0_18io_object_executorIS5_EEE11do_completeEPvPNS0_19scheduler_operationESP_m
003b8fc0 lDF .text 0060
_ZN4asio3ssl5error6detail15stream_categoryD1Ev
003b81c0 lDF .text 0010
_ZN4asio6detail10service_idINS0_22deadline_timer_serviceINS0_18chrono_time_traitsINSt6chrono3_V212steady_clockENS_11wait_traitsIS6_EEED1Ev
003d6200 lDF .text 0010
_ZN4asio6detail10service_idINS0_23reactive_socket_serviceINS_2ip3udpD1Ev
004001c0 lDF .text 0010
_ZN4asio6detail16reactive_wait_opIN5boost3_bi6bind_tIvNS2_4_mfi3mf3IvN2gu15AsioStreamReactERKSt10shared_ptrINS7_12AsioAcceptorEERKS9_INS7_19AsioAcceptorHandlerEERKSt10error_codeEENS3_5list4INS3_5valueIS9_IS8_EEENSN_ISB_EENSN_ISF_EEPFNS2_3argILi1EEEvENS0_18io_object_executorINS_8executor10do_performEPNS0_10reactor_opE
003b8dc0 lDF .text 0060
_ZN4asio5error6detail14netdb_categoryD1Ev
003b94c0 lDF .text 0060
_ZN4asio22service_already_existsD1Ev
003b95c0 lDF .text 0050
_ZN4asio6detail7tss_ptrINS0_10call_stackINS0_14thread_contextENS0_16thread_info_baseEE7contextEED1Ev
003db640 lDF .text 0330
_ZN4asio6detail17executor_functionINS0_7binder2IN5boost3_bi6bind_tIvNS3_4_mfi3mf3IvN2gu13AsioUdpSocketERKSt10shared_ptrINS8_25AsioDatagramSocketHandlerEERKSt10error_codemEENS4_5list4INS4_5valueISA_IS9_EEENSK_ISC_EEPFNS3_3argILi1EEEvEPFNSO_ILi2EEEvESF_mEESaIvEE11do_completeEPNS0_22executor_function_baseEb
003b8ec0 lDF .text 0060
_ZN4asio5error6detail17addrinfo_categoryD1Ev
003b92c0 lDF .text 0060
_ZN4asio12bad_executorD1Ev
003d6080 lDF .text 0010
_ZN4asio12placeholders17bytes_transferredEv
003c9a40 lDF .text 0050
_ZN4asio8executor4implINS_10io_context13executor_typeESaIvEE8dispatchEONS0_8functionE
0040eb40 lDF .text 03c0
_ZN4asio6detail17executor_functionINS0_7binder1IN5boost3_bi6bind_tIvNS3_4_mfi3mf3IvN2gu15AsioStreamReactERKSt10shared_ptrINS8_12AsioAcceptorEERKSA_INS8_19AsioAcceptorHandlerEERKSt10error_codeEENS4_5list4INS4_5valueISA_IS9_EEENSO_ISC_EENSO_ISG_EEPFNS3_3argILi1EEEvESJ_EESaIvEE11do_completeEPNS0_22executor_function_baseEb
003b83c0 lDF .text 0010
_ZNK4asio8executor4implINS_10io_context13executor_typeESaIvEE6targetEv
0040f580 lDF .text 0670

Bug#1036818: Acknowledgement (linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat)

[Otto Kekäläinen]

I just wanted to follow up that I disabled the workaround for this in
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/383f036c58fb0405fc25d89ff7ecf44a54c9afc9
and on Debian the armhf and armel builds pass and autopkgtest /
ci.debian.net pass, so that validates that this issue in lxcfs indeed
is fixed.

Bug#1031656: marked as done (MariaDB autopkgtest upstream test suite fails on disk / data corruption on ppc64el)

[Otto Kekäläinen]

Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-30728

The workaround in
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/b5e891039aa5a6ad6fa9573480bd3747dc5f6179
was reverted and this issue surfaced again.

See summary in 
https://jira.mariadb.org/browse/MDEV-30728?focusedCommentId=272230=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-272230

Bug#1029374: FTBFS update for MariaDB 10.11.5-3

[Otto Kekäläinen]

Note that this issue still exists, but is not visible and build is not
failing on it simply due to issue being skipped via the
unstable-tests.* in
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/

Bug#1053487: Acknowledgement (mariadb: FTBFS on hppa: Post-build test suite fails on multiple tests showing unexpected optimizer debug info)

[Otto Kekäläinen]

Note that hppa builds are now passing despite this issue, but this
issue still persists - it is simply skipped in the test list for hppa:
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/unstable-tests.hppa

Bug#1054204: mariadb: FTBFS on alpha: build passes but server instantly crashes/timeouts on post-build test

[Otto Kekäläinen]

Source: mariadb
Version: 1:10.11.5-1
Tags: help, ftbfs
User: debian-al...@lists.debian.org
Usertags: alpha
X-Debbugs-CC: debian-al...@lists.debian.org

The alpha build passed once in
https://buildd.debian.org/status/fetch.php?pkg=mariadb=alpha=1%3A10.11.2-1=1678215912=0
because the post-build tests were skipped. Other than that the alpha
build+test has always failed for MariaDB 10.11 series.

Currently the issue is that after the build is complete and basic test
runs, the server just timeouts/crashes.

This would need some alpha enthusiast to help debug what is going on
in the binary.

https://buildd.debian.org/status/fetch.php?pkg=mariadb=alpha=1%3A10.11.5-3=1697459406=0

# Run testsuite
cd builddir/mysql-test && \
export MTR_PRINT_CORE=detailed && \
./mtr --force --testcase-timeout=120 --suite-timeout=540 --retry=3 \
  --verbose-restart --max-save-core=1 --max-save-datadir=1 \
  --parallel=1 --skip-rpl --suite=main \
  --skip-test-list=/tmp/tmp.PlHSx9Dihs \

Logging: /<>/mysql-test/mariadb-test-run.pl  --force
--testcase-timeout=120 --suite-timeout=540 --retry=3 --verbose-restart
--max-save-core=1 --max-save-datadir=1 --parallel=1 --skip-rpl
--suite=main --skip-test-list=/tmp/tmp.PlHSx9Dihs
VS config:
vardir: /<>/builddir/mysql-test/var
Removing old var directory...
Creating var directory '/<>/builddir/mysql-test/var'...
Checking supported features...
MariaDB Version 10.11.5-MariaDB-3
 - SSL connections supported
Using suites: main
Collecting tests...
Installing system database...
E: Build killed with signal TERM after 600 minutes of inactivity

Bug#1054186: [Pkg-nagios-devel] Bug#1054186: icingadb: installs icingadb.service twice once dh_installsystemd installs to /usr

[Sebastiaan Couwenberg]

Control: tags -1 pending

Thanks for the patch, it's applied in git.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1054146: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b2

[Cyril Brulebois]

Scott Talbert  (2023-10-18):
> Indeed, libwx-perl has to be binMNU'd next.  Was waiting for the s390x build
> of libalien-wxwidgets-perl, but went ahead and submitted the binNMU request
> for libwx-perl anyway so we can get other arches fixed.

It would make sense to mention both packages from the get-go, we have
dep-waits to ensure one finishes before the other one starts?

> PS, what on the d-i uses libwx-perl?

The unifont-bin build-dep pulls it.


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


signature.asc
Description: PGP signature

Bug#1054146: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b2

[Scott Talbert]

On Thu, 19 Oct 2023, Cyril Brulebois wrote:


Scott Talbert  (2023-10-17):

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org
Control: affects -1 + src:libalien-wxwidgets-perl

nmu libalien-wxwidgets-perl_0.69+dfsg-6+b2 . ANY . unstable . -m "Rebuild against 
libwxgtk3.2-dev 3.2.3+dfsg-1"


While libalien-wxwidgets-perl shows up on the auto-upperlimit-libwxgtk3.2-dev
tracker, libwx-perl doesn't and this binNMU broke libwx-perl's installability,
also breaking d-i builds.

   Package: libalien-wxwidgets-perl
   Provides: wxperl-gtk-3-2-3-uni-gcc-3-4

   Package: libwx-perl
   Depends: […], wxperl-gtk-3-2-2-uni-gcc-3-4, […]


Indeed, libwx-perl has to be binMNU'd next.  Was waiting for the s390x 
build of libalien-wxwidgets-perl, but went ahead and submitted the binNMU 
request for libwx-perl anyway so we can get other arches fixed.


PS, what on the d-i uses libwx-perl?

Regards,
Scott

Bug#1054203: nmu: libwx-perl_1:0.9932-8+b1

[Scott Talbert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: libwx-p...@packages.debian.org
Control: affects -1 + src:libwx-perl

nmu libwx-perl_1:0.9932-8+b1 . ANY . unstable . -m "Rebuild against 
libwxgtk3.2-dev 3.2.3+dfsg-1"

Bug#1054108: apt-listchanges: Shows ancient NEWS for falkon and src:libdrm packages

[Jonathan Kamens]

I was unable to reproduce the libdrm issue or determine how it could 
have happened from attempting to reproduce it and examining the code. To 
be clear: I'm not disputing that it happened, just saying I can't figure 
out how so I can't figure out how to fix it. :-/


In the process of attempting to reproduce it I discovered and fixed 
three different bugs. Two of those bugs only impact debugging snapshots, 
and indeed, they prevented the snapshot you sent me from being complete, 
which is part of why I was unable to reproduce the issue. It's remotely 
possible that the third bug might explain the behavior you saw, but I 
can't figure out how.


All I can think to do at this point is to put out a new experimental 
version of apt-listchanges with these three fixes in it and then we'll 
see if the issue you encountered happens again. Because I can't 
reproduce the issue or figure out how it could have happened, I can't 
think of a better solution than that at this point.


  jik

On 10/17/23 02:36, Axel Beckert wrote:

Package: apt-listchanges
Version: 4.2
Severity: normal

Hi Jonathan,

two other cases of ancient NEWS items being show, this time with
apt-listchanges 4.2 and when upgrading falkon from 23.08.1-1 to
23.08.2-1 and multiple src:libdrm packages from 2.4.115-1 to 2.4.116-1:

$ dpkg -l 'libdrm*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Tr
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---===
ii  libdrm-amdgpu1:amd64  2.4.115-1amd64Userspace interface
ii  libdrm-amdgpu1:i386   2.4.115-1i386 Userspace interface
ii  libdrm-common 2.4.115-1all  Userspace interface
ii  libdrm-dev:amd64  2.4.115-1amd64Userspace interface
ii  libdrm-intel1:amd64   2.4.115-1amd64Userspace interface
ii  libdrm-intel1:i3862.4.115-1i386 Userspace interface
ii  libdrm-nouveau2:amd64 2.4.115-1amd64Userspace interface
ii  libdrm-nouveau2:i386  2.4.115-1i386 Userspace interface
ii  libdrm-radeon1:amd64  2.4.115-1amd64Userspace interface
ii  libdrm-radeon1:i386   2.4.115-1i386 Userspace interface
ii  libdrm2:amd64 2.4.115-1amd64Userspace interface
ii  libdrm2:i386  2.4.115-1i386 Userspace interface
ii  libdrm2-dbgsym:amd64  2.4.115-1amd64debug symbols for l

I got shown three NEWS entries, one from a few days ago (correct), one
from 2018 (falkon) and one from 2007, seemingly for libdrm2, but I
suspect that at least the multiarch setup (libdrm2:amd64 vs
libdrm2:i386, see above) might have played a role:

--- News for falkon ---

falkon (3.0.0-3) unstable; urgency=medium
   ===

   Falkon is a replacement for the former package Qupzilla. If you, or some
   other user of this computer were using Qupzilla formerly, it is possible
   to restore bookmarks which were gathered with Qupzilla, so they become
   available for Falkon users.

   Here is a method for user John Doe, in shell language:

   # USER_HOME=/home/johnDoe;
   # cp ${USER_HOME}/.config/qupzilla/profiles/default/bookmarks.json \
   ${USER_HOME}/.config/falkon/profiles/defaults/

   Please notice that doing so will erase any previous file
   ${USER_HOME}/.config/falkon/profiles/defaults/bookmarks.json

  -- Georges Khaznadar   Tue, 03 Apr 2018 18:26:55 +0200

[Inbetween was NEWS for xca 2.5.0-1 which was current as I upgraded from
2.4.0-2+b1]

--- News for libdrm2 ---

libdrm (2.3.0-4) experimental; urgency=low

   * We are now shipping libdrm with the default permissions set to 666,
 rather than the upstream default of 660. If you have untrusted users,
 you should configure the X server to explicitly use a mode of 660 in
 the xorg.conf.

  -- David Nusinow   Wed, 18 Apr 2007 22:44:21 -0400

-- Package-specific info:

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

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

Versions of packages apt-listchanges depends on:
ii  apt 2.7.6
ii  cdebconf [debconf-2.0]  0.271
ii  debconf [debconf-2.0]   1.5.82
ii  python3 3.11.4-5+b1
ii  python3-apt 2.6.0
ii  python3-debconf 1.5.82
ii  sensible-utils  0.0.20
ii  ucf 3.0043+nmu1

apt-listchanges recommends no packages.

Bug#1054146: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b2

[Cyril Brulebois]

Scott Talbert  (2023-10-17):
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org
> Control: affects -1 + src:libalien-wxwidgets-perl
> 
> nmu libalien-wxwidgets-perl_0.69+dfsg-6+b2 . ANY . unstable . -m "Rebuild 
> against libwxgtk3.2-dev 3.2.3+dfsg-1"

While libalien-wxwidgets-perl shows up on the auto-upperlimit-libwxgtk3.2-dev
tracker, libwx-perl doesn't and this binNMU broke libwx-perl's installability,
also breaking d-i builds.

Package: libalien-wxwidgets-perl
Provides: wxperl-gtk-3-2-3-uni-gcc-3-4

Package: libwx-perl
Depends: […], wxperl-gtk-3-2-2-uni-gcc-3-4, […]


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


signature.asc
Description: PGP signature

Bug#758068: mod_security bad performance due to misuse of apr allocator

[Nelson Elhage]

I have no idea, I'm afraid -- I haven't worked on that system in years

- Nelson

On Wed, Oct 18, 2023, 02:28 Alberto Gonzalez Iniesta 
wrote:

> Hello, Nelson.
>
> We were going over the opened bugs on modsecurity-apache and noticed
> this old one. Upstream did not update his forwarded bug either.
> Is this still relevant to the current version or can we close it?
>
> Thanks,
>
> Alberto
>
> --
> Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
> mailto/sip: a...@inittab.org | en GNU/Linux y software libre
> Encrypted mail preferred| http://inittab.com
>
> Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55
>

Bug#1053780: samba-common: conffiles not removed: /etc/dhcp/dhclient-enter-hooks.d/samba

[Paul Wise]

Control: reopen -1
Control: notfixed -1 2:4.19.2+dfsg-1

On Mon, 2023-10-16 at 15:51 +, Michael Tokarev wrote:

>    * d/samba-common.maintscript: remove obsolete conffile
>  /etc/dhcp/dhclient-enter-hooks.d/samba conffile (Closes: #1053780)

Unfortunately this didn't work, the obsolete conffile is still present.
This means the version is incorrect, it should be the uploaded version.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#902810: user-mode-linux: FTBFS in stretch (Hunk #1 FAILED in 07-remove-rpath.patch)

[Santiago Vila]

Version: 5.10um3

Hi. I'm closing my own bug because stretch is no longer supported.

Thanks.

Bug#902162: translate-toolkit: FTBFS in stretch (broken by change in Africa/Windhoek timezone)

[Santiago Vila]

Version: 2.3.1-3

I'm closing my own bug because stretch is no longer supported.

Thanks.

Bug#934036: sketch: FTBFS in stretch (LaTeX error)

[Santiago Vila]

Version: 1:0.3.7-11

Hi. Since stretch is no longer supported, I'm closing
my own bug using buster version.

Thanks.

Bug#1054202: prometheus-snmp-exporter FTBFS: FAIL: pg_setting_test.go:240: PgSettingSuite.TestMetric

[Adrian Bunk]

Source: prometheus-postgres-exporter
Version: 0.14.0-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=prometheus-postgres-exporter=0.14.0-2%2Bb1

...
FAIL: pg_setting_test.go:240: PgSettingSuite.TestMetric

pg_setting_test.go:254:
c.Check(m.Desc().String(), Equals, f.d)
... obtained string = "Desc{fqName: 
\"pg_settings_seconds_fixture_metric_seconds\", help: \"Server Parameter: 
seconds_fixture_metric [Units converted to seconds.]\", constLabels: {}, 
variableLabels: {}}"
... expected string = "Desc{fqName: 
\"pg_settings_seconds_fixture_metric_seconds\", help: \"Server Parameter: 
seconds_fixture_metric [Units converted to seconds.]\", constLabels: {}, 
variableLabels: []}"

pg_setting_test.go:254:
c.Check(m.Desc().String(), Equals, f.d)
... obtained string = "Desc{fqName: 
\"pg_settings_milliseconds_fixture_metric_seconds\", help: \"Server Parameter: 
milliseconds_fixture_metric [Units converted to seconds.]\", constLabels: {}, 
variableLabels: {}}"
... expected string = "Desc{fqName: 
\"pg_settings_milliseconds_fixture_metric_seconds\", help: \"Server Parameter: 
milliseconds_fixture_metric [Units converted to seconds.]\", constLabels: {}, 
variableLabels: []}"

pg_setting_test.go:254:
c.Check(m.Desc().String(), Equals, f.d)
... obtained string = "Desc{fqName: 
\"pg_settings_eight_kb_fixture_metric_bytes\", help: \"Server Parameter: 
eight_kb_fixture_metric [Units converted to bytes.]\", constLabels: {}, 
variableLabels: {}}"
... expected string = "Desc{fqName: 
\"pg_settings_eight_kb_fixture_metric_bytes\", help: \"Server Parameter: 
eight_kb_fixture_metric [Units converted to bytes.]\", constLabels: {}, 
variableLabels: []}"

pg_setting_test.go:254:
c.Check(m.Desc().String(), Equals, f.d)
... obtained string = "Desc{fqName: 
\"pg_settings_16_kb_real_fixture_metric_bytes\", help: \"Server Parameter: 
16_kb_real_fixture_metric [Units converted to bytes.]\", constLabels: {}, 
variableLabels: {}}"
... expected string = "Desc{fqName: 
\"pg_settings_16_kb_real_fixture_metric_bytes\", help: \"Server Parameter: 
16_kb_real_fixture_metric [Units converted to bytes.]\", constLabels: {}, 
variableLabels: []}"

pg_setting_test.go:254:
c.Check(m.Desc().String(), Equals, f.d)
... obtained string = "Desc{fqName: 
\"pg_settings_16_mb_real_fixture_metric_bytes\", help: \"Server Parameter: 
16_mb_real_fixture_metric [Units converted to bytes.]\", constLabels: {}, 
variableLabels: {}}"
... expected string = "Desc{fqName: 
\"pg_settings_16_mb_real_fixture_metric_bytes\", help: \"Server Parameter: 
16_mb_real_fixture_metric [Units converted to bytes.]\", constLabels: {}, 
variableLabels: []}"

pg_setting_test.go:254:
c.Check(m.Desc().String(), Equals, f.d)
... obtained string = "Desc{fqName: 
\"pg_settings_32_mb_real_fixture_metric_bytes\", help: \"Server Parameter: 
32_mb_real_fixture_metric [Units converted to bytes.]\", constLabels: {}, 
variableLabels: {}}"
... expected string = "Desc{fqName: 
\"pg_settings_32_mb_real_fixture_metric_bytes\", help: \"Server Parameter: 
32_mb_real_fixture_metric [Units converted to bytes.]\", constLabels: {}, 
variableLabels: []}"

pg_setting_test.go:254:
c.Check(m.Desc().String(), Equals, f.d)
... obtained string = "Desc{fqName: 
\"pg_settings_64_mb_real_fixture_metric_bytes\", help: \"Server Parameter: 
64_mb_real_fixture_metric [Units converted to bytes.]\", constLabels: {}, 
variableLabels: {}}"
... expected string = "Desc{fqName: 
\"pg_settings_64_mb_real_fixture_metric_bytes\", help: \"Server Parameter: 
64_mb_real_fixture_metric [Units converted to bytes.]\", constLabels: {}, 
variableLabels: []}"

pg_setting_test.go:254:
c.Check(m.Desc().String(), Equals, f.d)
... obtained string = "Desc{fqName: \"pg_settings_bool_on_fixture_metric\", 
help: \"Server Parameter: bool_on_fixture_metric\", constLabels: {}, 
variableLabels: {}}"
... expected string = "Desc{fqName: \"pg_settings_bool_on_fixture_metric\", 
help: \"Server Parameter: bool_on_fixture_metric\", constLabels: {}, 
variableLabels: []}"

pg_setting_test.go:254:
c.Check(m.Desc().String(), Equals, f.d)
... obtained string = "Desc{fqName: \"pg_settings_bool_off_fixture_metric\", 
help: \"Server Parameter: bool_off_fixture_metric\", constLabels: {}, 
variableLabels: {}}"
... expected string = "Desc{fqName: \"pg_settings_bool_off_fixture_metric\", 
help: \"Server Parameter: bool_off_fixture_metric\", constLabels: {}, 
variableLabels: []}"

pg_setting_test.go:254:
c.Check(m.Desc().String(), Equals, f.d)
... obtained string = "Desc{fqName: 
\"pg_settings_special_minus_one_value_seconds\", help: \"Server Parameter: 
special_minus_one_value [Units converted to seconds.]\", constLabels: {}, 
variableLabels: {}}"
... expected string = "Desc{fqName: 
\"pg_settings_special_minus_one_value_seconds\", help: \"Server Parameter: 
special_minus_one_value [Units converted to seconds.]\", constLabels: {}, 
variableLabels: []}"

pg_setting_test.go:254:

Bug#770171: sshd jail fails when system solely relies on systemd journal for logging

[Stefaan Vanheesbeke]

Confirmed that this is still annoying. I (as a moderate linux user) had 
to search several hours, during several days until finding the fix.


It works fine in a debian11 fresh install, not in a debian12. So I 
suppose it was fixed some time before, but came back an issue recently.


After adding "backend=systemd" to the jail.d/defaults-debian.conf in the 
ssh section should be the simplest solution for having back some safety 
in a default apt-get install.


An extra burden is that you need to manually install python3-systemd 
also. If not, it will not work after a fresh install. This should be a 
dependency on the jail2ban installation.


For me, it is not the extra work to do to make it work that is the 
problem, the big issue is that people may rely on the fact that they 
installed fail2ban, and think their safety increased, however it doesn't 
work out of the box! I wonder how they make all these tutorials.


Have a nice day,

Stefaan



On Sun, 24 Sep 2023 19:52:07 +0200 Stefan Weil  wrote:

> This bug report from 2014 is meanwhile more important than ever.
>
> With the latest stable release Debian marked rsyslog as deprecated (see
> https://wiki.debian.org/Rsyslog).
>
> If a user removes the rsyslog package without removing the related
> logfiles in /var/log, fail2ban silently stops doing its job, because
> it looks for failed ssh logins in /var/log/auth which no longer gets
> updates. The same applies to other jails which were activated by local
> settings.
>
> If the user not only removes rsyslog but also removes all old files in
> /var/log/, fail2ban no longer runs at all but silently fails.
>
> If fail2ban is not working as expected or not running at all, that can
> effect the security of a Debian system. Therefore I suggest to increase
> the priority of this bug report.
>
> My fix for this issue (and also for issue 1024305) is a small
> modification of jail.d/defaults-debian.conf:
>
> --
>
> # cat /etc/fail2ban/jail.d/defaults-debian.conf
> [DEFAULT]
> allowipv6 = auto
> dovecot_backend = systemd
> postfix_backend = systemd
> sshd_backend = systemd
> # ... add more affected backends here
>
> [sshd]
> enabled = true
>
> --
>
> I only added the backends which where required for my Debian system.
> Maybe some other jails also must use the systemd backend.
>
> I suggest to update jail.d/defaults-debian.conf and distribute that as a
> security fix.
>
> In addition, rsyslog could be removed from the list of suggested
> packages in future Debian releases.
>
> Stefan
>
>
>

Bug#1054201: einstein: Game window is too small and unchangeable to allow pleasant play

[Bjarni Ingi Gislason]

Package: einstein
Version: 2.0.dfsg.2-10+b1
Severity: normal

Dear Maintainer,

  The game window can't be moved nor its size changed.
The mouse cursor can't go beyond the game window.

  Happened after another software was updated some months ago.

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

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

Versions of packages einstein depends on:
ii  libc62.37-12
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s1 [libgcc1]  13.2.0-4
ii  libsdl-mixer1.2  1.2.12-17+b3
ii  libsdl-ttf2.0-0  2.0.11-6
ii  libsdl1.2debian  1.2.68-1
ii  libstdc++6   13.2.0-4
ii  zlib1g   1:1.2.13.dfsg-3

einstein recommends no packages.

einstein suggests no packages.

-- no debconf information

Bug#1054200: libkf5sysguard-bin is not a part of the default KDE installation

[Ant]

Package: libkf5sysguard-bin
Version: 4:5.27.8-1
Severity: normal
X-Debbugs-Cc: antkaid+deb...@gmail.com

Dear Maintainer,

In KDE System Monitor, there's a very nice feature of displaying the per-app 
network stats, e.g. Firefox consuming 1 MB/s out of the overall network 
bandwidth.

This feature requires an extra executable to work, ksgrd_network_helper, which 
is provided by the package libkf5sysguard-bin.

libkf5sysguard-bin is not a part of the default KDE installation in Debian. I 
didn't get it after installing KDE.

Thus, installing a default Debian KDE suite gets you the System Monitor with 
this feature broken: the app-specific Network chart on the "Applications" tab 
stays silent without any explanations.

It can be fixed by simply installing libkf5sysguard-bin, but for the regular 
user:
1) it's hard to figure this out;
2) it's not friendly, as the user just wants the System Monitor to fully work, 
not a manual installation (and selection in apt) of the specific package 
libkf5sysguard-bin.

I'm not sure where exactly this package should be wired into the KDE packages 
tree. But I believe the per-app stats are really an important part of the 
current KDE experience.

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

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

Versions of packages libkf5sysguard-bin depends on:
ii  libc62.37-12
ii  libgcc-s113.2.0-4
ii  libkf5authcore5  5.107.0-1
ii  libkf5coreaddons55.107.0-1
ii  libkf5i18n5  5.107.0-1+b1
ii  libkf5sysguard-data  4:5.27.8-1
ii  libnl-3-200  3.7.0-0.2+b1
ii  libpcap0.8   1.10.4-4
ii  libprocesscore9  4:5.27.8-1
ii  libqt5core5a 5.15.10+dfsg-3
ii  libstdc++6   13.2.0-4

libkf5sysguard-bin recommends no packages.

libkf5sysguard-bin suggests no packages.

-- no debconf information

Bug#1054199: prometheus-snmp-exporter FTBFS: FAIL: TestPduToSample

[Adrian Bunk]

Source: prometheus-snmp-exporter
Version: 0.24.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=prometheus-snmp-exporter=0.24.1-1%2Bb2

...
ok  github.com/prometheus/snmp_exporter 0.021s
=== RUN   TestPduToSample
collector_test.go:539: Got metric:  Desc{fqName: 
"TestMetricNameExtension", help: "HelpText (regex extracted)", constLabels: {}, 
variableLabels: {}} gauge:{value:5}
collector_test.go:545: Expected metric: Desc{fqName: 
"TestMetricNameExtension", help: "HelpText (regex extracted)", constLabels: {}, 
variableLabels: []} gauge:{value:5}, but was not returned.
collector_test.go:539: Got metric:  Desc{fqName: 
"TestMetricNameStatus", help: "HelpText (regex extracted)", constLabels: {}, 
variableLabels: {}} gauge:{value:5}
collector_test.go:545: Expected metric: Desc{fqName: 
"TestMetricNameStatus", help: "HelpText (regex extracted)", constLabels: {}, 
variableLabels: []} gauge:{value:5}, but was not returned.
collector_test.go:539: Got metric:  Desc{fqName: 
"TestMetricNameExtension", help: "HelpText (regex extracted)", constLabels: {}, 
variableLabels: {}} gauge:{value:5}
collector_test.go:539: Got metric:  Desc{fqName: 
"TestMetricNameMultipleRegexes", help: "HelpText (regex extracted)", 
constLabels: {}, variableLabels: {}} gauge:{value:999}
collector_test.go:539: Got metric:  Desc{fqName: 
"TestMetricNameTemplate", help: "HelpText (regex extracted)", constLabels: {}, 
variableLabels: {}} gauge:{value:4.42}
collector_test.go:545: Expected metric: Desc{fqName: 
"TestMetricNameExtension", help: "HelpText (regex extracted)", constLabels: {}, 
variableLabels: []} gauge:{value:5}, but was not returned.
collector_test.go:545: Expected metric: Desc{fqName: 
"TestMetricNameMultipleRegexes", help: "HelpText (regex extracted)", 
constLabels: {}, variableLabels: []} gauge:{value:999}, but was not returned.
collector_test.go:545: Expected metric: Desc{fqName: 
"TestMetricNameTemplate", help: "HelpText (regex extracted)", constLabels: {}, 
variableLabels: []} gauge:{value:4.42}, but was not returned.
collector_test.go:539: Got metric:  Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: {}} counter:{value:2}
collector_test.go:545: Expected metric: Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: []} counter:{value:2}, but was 
not returned.
collector_test.go:539: Got metric:  Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: {}} gauge:{value:2}
collector_test.go:545: Expected metric: Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: []} gauge:{value:2}, but was 
not returned.
collector_test.go:539: Got metric:  Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: {test_metric}} 
label:{name:"test_metric" value:"-2"} gauge:{value:1}
collector_test.go:545: Expected metric: Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: [{test_metric }]} 
label:{name:"test_metric" value:"-2"} gauge:{value:1}, but was not returned.
collector_test.go:539: Got metric:  Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: {}} gauge:{value:3}
collector_test.go:545: Expected metric: Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: []} gauge:{value:3}, but was 
not returned.
collector_test.go:539: Got metric:  Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: {}} gauge:{value:3}
collector_test.go:545: Expected metric: Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: []} gauge:{value:3}, but was 
not returned.
collector_test.go:539: Got metric:  Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: {foo}} label:{name:"foo" 
value:"AA"} gauge:{value:3}
collector_test.go:545: Expected metric: Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: [{foo }]} 
label:{name:"foo" value:"AA"} gauge:{value:3}, but was not returned.
collector_test.go:539: Got metric:  Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: {test_metric}} 
label:{name:"test_metric" value:"4.5.6.7"} gauge:{value:1}
collector_test.go:545: Expected metric: Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: [{test_metric }]} 
label:{name:"test_metric" value:"4.5.6.7"} gauge:{value:1}, but was not 
returned.
collector_test.go:539: Got metric:  Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: {test_metric}} 
label:{name:"test_metric" value:"4.5.6.7"} gauge:{value:1}
collector_test.go:545: Expected metric: Desc{fqName: "test_metric", help: 
"Help string", constLabels: {}, variableLabels: [{test_metric }]} 

Bug#1054198: ncbi-entrez-direct FTBFS: No rule to make target '/<>/obj-aarch64-linux-gnu/src/golang.org/x/net', needed by '/<>/obj-aarch64-linux-gnu/src/github.com/klauspost/

[Adrian Bunk]

Source: ncbi-entrez-direct
Version: 19.2.20230331+dfsg-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=ncbi-entrez-direct=19.2.20230331%2Bdfsg-2%2Bb1

...
ln -s /usr/share/gocode/src/golang.org/x/crypto 
/<>/obj-aarch64-linux-gnu/src/golang.org/x/crypto
make[1]: *** No rule to make target 
'/<>/obj-aarch64-linux-gnu/src/golang.org/x/net', needed by 
'/<>/obj-aarch64-linux-gnu/src/github.com/klauspost/cpuid'.  Stop.
make[1]: Leaving directory '/<>'
make: *** [debian/rules:17: binary-arch] Error 2

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

[sergio]

Hi Julian,

thank you for the answer and explanation.

Best regards,
Sergio Zamora Molffe
Analista Programador Computacional

El jue, 12 de oct de 2023 a las 10:54:55 AM, Julian Gilbey 
 escribió:

On Wed, Oct 11, 2023 at 06:56:02PM -0300, sergio wrote:
 El jue, 17 de ago de 2023 a las 11:36:58 AM, Julian Gilbey 
mailto:jul...@d-and-j.net>>

 escribi

   spyder

 Hi Julian,
 any way of doing this from the stable release ? I've installed from 
testing some
 very, very minimal/specific packages before, but looks like this is 
going to
 update some other packages on stable release. Any possible arrive 
to backports

 repository in the near future ?
 Thank you for time
 Regards.
 Sergio


Hi Sergio,

As you say, spyder has a lot of dependencies, and I don't know exactly
which ones would need backporting to get a working spyder in
backports, and how many of these backports might break other things in
other packages along the way.  I don't have the capacity to take on
this level of responsibility for backports, so I do not intend to
backport spyder.

If someone else would like to take on this task, though, they are more
than welcome to do so!

(If this bug is really annoying you, you can always run the PyPI
version of spyder in a virtual environment.)

Best wishes,

   Julian

Bug#1054197: hcloud-cli FTBFS: cannot use cert.ID (variable of type int64) as int value in argument to strconv.Itoa

[Adrian Bunk]

Source: hcloud-cli
Version: 1.30.3-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=hcloud-cli=1.30.3-1%2Bb8

...
# github.com/hetznercloud/cli/internal/hcapi
src/github.com/hetznercloud/cli/internal/hcapi/certificate.go:27:24: cannot use 
cert.ID (variable of type int64) as int value in argument to strconv.Itoa
src/github.com/hetznercloud/cli/internal/hcapi/datacenter.go:27:24: cannot use 
dc.ID (variable of type int64) as int value in argument to strconv.Itoa
src/github.com/hetznercloud/cli/internal/hcapi/firewall.go:27:24: cannot use 
firewall.ID (variable of type int64) as int value in argument to strconv.Itoa
src/github.com/hetznercloud/cli/internal/hcapi/floatingip.go:27:24: cannot use 
fip.ID (variable of type int64) as int value in argument to strconv.Itoa
src/github.com/hetznercloud/cli/internal/hcapi/image.go:27:24: cannot use 
img.ID (variable of type int64) as int value in argument to strconv.Itoa
src/github.com/hetznercloud/cli/internal/hcapi/iso.go:28:24: cannot use iso.ID 
(variable of type int64) as int value in argument to strconv.Itoa
src/github.com/hetznercloud/cli/internal/hcapi/loadbalancer.go:36:24: cannot 
use lb.ID (variable of type int64) as int value in argument to strconv.Itoa
src/github.com/hetznercloud/cli/internal/hcapi/loadbalancer.go:57:23: cannot 
use lb.ID (variable of type int64) as int value in argument to strconv.Itoa
src/github.com/hetznercloud/cli/internal/hcapi/loadbalancer.go:98:13: cannot 
use lb.ID (variable of type int64) as int value in map index
src/github.com/hetznercloud/cli/internal/hcapi/location.go:27:24: cannot use 
loc.ID (variable of type int64) as int value in argument to strconv.Itoa
src/github.com/hetznercloud/cli/internal/hcapi/location.go:27:24: too many 
errors
# github.com/hetznercloud/cli/internal/cmd/util
src/github.com/hetznercloud/cli/internal/cmd/util/util.go:212:25: cannot use 
hcloud.Int(image.BoundTo.ID) (value of type *int) as *int64 value in assignment
src/github.com/hetznercloud/cli/internal/cmd/util/util.go:212:36: cannot use 
image.BoundTo.ID (variable of type int64) as int value in argument to hcloud.Int
# github.com/hetznercloud/cli/internal/hcapi2
src/github.com/hetznercloud/cli/internal/hcapi2/certificate.go:37:24: cannot 
use dc.ID (variable of type int64) as int value in argument to strconv.Itoa
src/github.com/hetznercloud/cli/internal/hcapi2/client.go:63:46: cannot use 
 (value of type *hcloud.CertificateClient) as 
CertificateClientBase value in argument to NewCertificateClient: 
*hcloud.CertificateClient does not implement CertificateClientBase (wrong type 
for method GetByID)
have GetByID(context.Context, int64) (*hcloud.Certificate, 
*hcloud.Response, error)
want GetByID(context.Context, int) (*hcloud.Certificate, 
*hcloud.Response, error)
src/github.com/hetznercloud/cli/internal/hcapi2/client.go:72:44: cannot use 
 (value of type *hcloud.DatacenterClient) as 
DatacenterClientBase value in argument to NewDatacenterClient: 
*hcloud.DatacenterClient does not implement DatacenterClientBase (wrong type 
for method GetByID)
have GetByID(context.Context, int64) (*hcloud.Datacenter, 
*hcloud.Response, error)
want GetByID(context.Context, int) (*hcloud.Datacenter, 
*hcloud.Response, error)
src/github.com/hetznercloud/cli/internal/hcapi2/client.go:81:40: cannot use 
 (value of type *hcloud.FirewallClient) as FirewallClientBase 
value in argument to NewFirewallClient: *hcloud.FirewallClient does not 
implement FirewallClientBase (wrong type for method GetByID)
have GetByID(context.Context, int64) (*hcloud.Firewall, 
*hcloud.Response, error)
want GetByID(context.Context, int) (*hcloud.Firewall, 
*hcloud.Response, error)
src/github.com/hetznercloud/cli/internal/hcapi2/client.go:90:44: cannot use 
 (value of type *hcloud.FloatingIPClient) as 
FloatingIPClientBase value in argument to NewFloatingIPClient: 
*hcloud.FloatingIPClient does not implement FloatingIPClientBase (wrong type 
for method GetByID)
have GetByID(context.Context, int64) (*hcloud.FloatingIP, 
*hcloud.Response, error)
want GetByID(context.Context, int) (*hcloud.FloatingIP, 
*hcloud.Response, error)
src/github.com/hetznercloud/cli/internal/hcapi2/client.go:99:42: cannot use 
 (value of type *hcloud.PrimaryIPClient) as 
PrimaryIPClientBase value in argument to NewPrimaryIPClient: 
*hcloud.PrimaryIPClient does not implement PrimaryIPClientBase (wrong type for 
method GetByID)
have GetByID(context.Context, int64) (*hcloud.PrimaryIP, 
*hcloud.Response, error)
want GetByID(context.Context, int) (*hcloud.PrimaryIP, 
*hcloud.Response, error)
src/github.com/hetznercloud/cli/internal/hcapi2/client.go:108:34: cannot use 
 (value of type *hcloud.ImageClient) as ImageClientBase value in 
argument to NewImageClient: *hcloud.ImageClient does not implement 
ImageClientBase (wrong type 

Bug#1054195: cppgir FTBFS: ERROR could not find GIR for GObject-2.0

[Adrian Bunk]

Source: cppgir
Version: 0~git20231003.e856d76-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=cppgir=0~git20231003.e856d76-1

...
[ 39%] Generating wrapper code for: GObject-2.0;Gio-2.0;Gst-1.0;Gtk-3.0
cd "/<>" && "/<>/obj-aarch64-linux-gnu/cppgir" 
--class --class-full --optional --ignore 
data/cppgir.ignore:data/cppgir_unix.ignore --output /tmp/gi GObject-2.0 Gio-2.0 
Gst-1.0 Gtk-3.0
ERROR could not find GIR for GObject-2.0
make[3]: *** [CMakeFiles/wrappers.dir/build.make:78: /tmp/gi] Error 1

Bug#1054177: [Debichem-devel] Bug#1054177: src:cp2k: fails to migrate to testing for too long: no longer buildable on armel

[Paul Gevers]

Hi,

On 18-10-2023 21:46, Michael Banck wrote:

On Wed, Oct 18, 2023 at 07:28:14PM +0200, Paul Gevers wrote:

If you believe your package is unable to migrate to testing due to issues
beyond your control, don't hesitate to contact the Release Team.


I am not sure it is out of my control or not, but the issue seems to be
that armel is not able to run the dbcsr testsuite without timing out, so
a cp2k Build-Depends is missing.


If it *feels* out of control, you should just file a bug against 
ftp.debian.org and ask for the removal of the binaries of cp2k from 
armel. Once dbcsr is fixed, cp2k will be tried again on armel and might 
come back.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054170: graphviz: dot generates unreproducible pdfs with embedded timestamps

[Daniel Gröber]

On Wed, Oct 18, 2023 at 09:24:11PM +0200, László Böszörményi (GCS) wrote:
> On Wed, Oct 18, 2023 at 5:45 PM Daniel Gröber  wrote:
> > dot appears to embed CreationDate in the pdf and this cannot be
> > controlled with SOURCE_DATE_EPOCH.
> Can you please test it with the Graphviz version 9.0 in experimental?
> I don't expect it to be different, but I would like to be sure.

Seems -Tpdf doesn't work for with 9.0 some reason, is a configure option
for that missing perhaps?:

$ SOURCE_DATE_EPOCH=60 dot -T pdf test.dot -o test.pdf
Format: "pdf" not recognized. Use one of: canon cmap cmapx cmapx_np dot
dot_json eps fig gd gd2 gif gv imap imap_np ismap jpe jpeg jpg json
json0 mp pic plain plain-ext png pov ps ps2 svg svgz tk vrml wbmp xdot
xdot1.2 xdot1.4 xdot_json

--Daniel


signature.asc
Description: PGP signature

Bug#1054177: [Debichem-devel] Bug#1054177: src:cp2k: fails to migrate to testing for too long: no longer buildable on armel

[Michael Banck]

Hi,

On Wed, Oct 18, 2023 at 07:28:14PM +0200, Paul Gevers wrote:
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.

I am not sure it is out of my control or not, but the issue seems to be
that armel is not able to run the dbcsr testsuite without timing out, so
a cp2k Build-Depends is missing.


Michael

Bug#1052693: sisu Re: live-manual-pdf: PDF manual is unreadable

[Ralph Amissah]

Summary:
- the "cause" of failure of sisu and hence live-manual to produce pdf
output is that sisu's latex output is out of date and needs
updating...,
- I am on it and am making headway :-)
- changes have not yet been uploaded upstream, I will report when they are.

The longer story :-)

I thought it time to post an update since I am looking at this, though
I have been procrastinating :-(

A week ago I was back on a my old debian box, forgotten password reset
and dist-updated.

My assumption as to where the fault was likely to lie proved
incorrect, 2 or three .sty files had moved, but they were all
installed by sisu-pdf or sisu-complete and available on the system.

So, ... minor surprise, Debian (testing/unstable at least) is using a
newer version of texlive (2023) than NixOS (texlive 2022-final) and
somewhere therein lies the problem, of the issue not having come up
for me.

sisu.spine the not-shared D lang version of sisu in its rewrite has
more recently "developed" latex output and, though not developed or
tested previously on texlive 2023 is not afflicted to the same extent
as sisu.ruby that we fixing here. This meant, I had something to look
at and could no minor (very incomplete) backporting for output and
make headway in solving the sisu-pdf issue reported for live-manual
pdf output.

In short, progress has been made, I do have some output.

Current status, though checking will be necessary, I do have portrait
pdf output for languages other than Chinese, Japanese, Korean (are
made to work in an updated way on sisu.spine.d i.e. not using CJK.sty
whatever that sty that is claimed to be obsolete is called... have not
looked at yet, but should be doable). For landscape pdf output, I
expect the effort to be relatively minor, just it all takes a bit of
time (especially with a procrastinator, I am plodding towards getting
it done though).

I will report again when I have got further or better yet, when I
upload a first set of changes to sisudoc.org

This bug, should be cross-assigned to sisu.

Bug#1054193: arpwatch: installs arpwatch@.service twice once dh_installsystemd installs to /usr

[Helmut Grohne]

Source: arpwatch
Version: 2.1a15-8
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd to install to /usr to finalize the
/usr-merge transition via DEP17. Once doing so, arpwatch will contain
/usr/lib/systemd/system/arpwatch@.service (via dh_installsystemd) and
/lib/systemd/system/arpwatch@.service (via dh_install). This is a policy
violation. I'm attaching a patch for your convenience. Once I upload
debhelper, this bug will become release critical.

Helmut
diff -Nru arpwatch-2.1a15/debian/arpwatch.install 
arpwatch-2.1a15/debian/arpwatch.install
--- arpwatch-2.1a15/debian/arpwatch.install 2021-01-31 17:44:03.0 
+0100
+++ arpwatch-2.1a15/debian/arpwatch.install 2023-10-18 13:28:51.0 
+0200
@@ -1,7 +1,6 @@
 arp2ethers   usr/sbin/
 arpfetch usr/sbin/
 *.awkusr/lib/arpwatch/
-debian/arpwatch@.service lib/systemd/system
 debian/etc/READMEetc/arpwatch/
 debian/ieee-data-update/arpwatch var/lib/ieee-data/update.d/
 debian/sbin/*usr/sbin/
diff -Nru arpwatch-2.1a15/debian/changelog arpwatch-2.1a15/debian/changelog
--- arpwatch-2.1a15/debian/changelog2021-01-31 17:44:03.0 +0100
+++ arpwatch-2.1a15/debian/changelog2023-10-18 13:30:20.0 +0200
@@ -1,3 +1,10 @@
+arpwatch (2.1a15-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install arpwatch@.service only once. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Oct 2023 13:30:20 +0200
+
 arpwatch (2.1a15-8) unstable; urgency=medium
 
   * Team Upload

Bug#1054194: lsp-plugins: comp-delay: segfault on startup

[Roman Lebedev]

Package: lsp-plugins
Version: 1.2.11-1
Severity: normal
Tags: patch upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer, comp-delay plugin immediately crashes upon startup:
https://github.com/sadko4u/lsp-plugins/issues/348

Please consider backporting a fix: (yet to be released in 1.2.13)
https://github.com/lsp-plugins/lsp-plugins-comp-delay/commit/78dde4177a6c9cb818d3c04d10da6affa4aedfb1

(Also, regardless, it may be good to update to LSP 1.2.12 release.)

Roman.

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

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

Versions of packages lsp-plugins depends on:
ii  lsp-plugins-clap1.2.11-1
ii  lsp-plugins-jack1.2.11-1
ii  lsp-plugins-ladspa  1.2.11-1
ii  lsp-plugins-lv2 1.2.11-1
ii  lsp-plugins-vst 1.2.11-1

lsp-plugins recommends no packages.

Versions of packages lsp-plugins suggests:
pn  dgedit  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+UikBxeiu50LOdFYgbqkFMWfZdAFAmUwNisACgkQgbqkFMWf
ZdAfvA//WIrE0jV7RDw3raO8PBDp9nIoDqKF0G9xgqCPxWjhaPs6nlorzu9GOcIH
h2TjoOOZIcbu8wp0I6/JRv+Bq8LdtCYjM1K50Yr1M6BURW0rf83wL2POgJbSmVAE
J5NVbfZQdIp6RixuNYcaRUOZ4/o8AgjK+jxyLCLQQSFsG8alQ0quqIjPX6jjYTYY
cZxAy9k4ou3RvrxhFEepcn+fJM7Ud14jbDym5aB2kPTwiWX7UNWaCkEopb4RtlOY
LHQ8m8mL+MdG8foozitys85Yc2Ggn63snk/YXHLVnxj05TzRuH/kX57TBjnO/chu
LJ0lFjfDWW5o9lBrDM5xkkrWMFROwNyg40heVWOnZdf02UllLNrKzPPpdv63NGcc
DWjGujSRHs/l5bqxcodY6YNIdRcun3DCNisnemuKob1KC3B1MCK9EYz7C7tk2cHW
IXSq70FxKXkzD73qFiwsybq6ofQc9o0lzAxb1sa0sd1HOia0OQ4yrw6S1bnfj/co
VD8Oo2u/2Cmxy3Dz6PaULi6254o1FCQte5jXwCs7jTpvX8z1JdnGlFbj/MGe6ZQf
5b16BYjbZeTIv93c0PEsaSubJE2/BPlEpOCECz9oDo5cD8CFH+DkXa08+n/zQbtQ
zhrq+IKtkFiqmPl5swFEMAfNv4Un3beuX28a7GpL980TdOTo8R0=
=Ct8T
-END PGP SIGNATURE-

Bug#1054192: acmetool: installs units twice once dh_installsystemd installs to /usr

[Helmut Grohne]

Source: acmetool
Version: 0.2.2-1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd to install units to /usr to finalize
the /usr-merge transition via DEP17. When doing so, acmetool will end up
with units in both /usr/lib/systemd/system (via dh_installsystemd) and
/lib/systemd/system (via dh_install). This consititutes a policy
violation. I'm attaching a patch to install the units only once (via
dh_installsystemd). Once I upload debhelper, this bug will become RC.

Helmut
diff -Nru acmetool-0.2.2/debian/acmetool.install 
acmetool-0.2.2/debian/acmetool.install
--- acmetool-0.2.2/debian/acmetool.install  2023-02-06 04:30:40.0 
+0100
+++ acmetool-0.2.2/debian/acmetool.install  2023-10-18 12:31:13.0 
+0200
@@ -1,4 +1,2 @@
-debian/acmetool.service lib/systemd/system
-debian/acmetool.timer lib/systemd/system
 debian/nginx/acmetool.conf etc/nginx/snippets
 debian/rsyslog/acmetool.conf etc/rsyslog.d
diff -Nru acmetool-0.2.2/debian/changelog acmetool-0.2.2/debian/changelog
--- acmetool-0.2.2/debian/changelog 2023-02-06 04:30:40.0 +0100
+++ acmetool-0.2.2/debian/changelog 2023-10-18 12:31:16.0 +0200
@@ -1,3 +1,11 @@
+acmetool (0.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd units only once when dh_installsystemd moves to /usr.
+(Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Oct 2023 12:31:16 +0200
+
 acmetool (0.2.2-1) unstable; urgency=medium
 
   * New upstream version 0.2.2

Bug#1054191: memlockd: installs an empty /lib/systemd/system once dh_installsystemd installs to /usr

[Helmut Grohne]

Source: memlockd
Version: 1.3.1-1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd such that it installs units below
/usr to finalize the /usr-merge transition via DEP17. While
memlockd.service is installed using dh_installsystemd and thus moved by
this change, it also install the directory /lib/systemd/system, which
will then become empty. Please stop shipping this directory.

Helmut
diff -Nru memlockd-1.3.1/debian/changelog memlockd-1.3.1/debian/changelog
--- memlockd-1.3.1/debian/changelog 2023-09-30 03:49:17.0 +0200
+++ memlockd-1.3.1/debian/changelog 2023-10-18 21:27:44.0 +0200
@@ -1,3 +1,10 @@
+memlockd (1.3.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not install a possibly empty /lib/systemd/system. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Oct 2023 21:27:44 +0200
+
 memlockd (1.3.1-1) unstable; urgency=medium
 
   * Convert to source format 3.0, closes: #1043214
diff -Nru memlockd-1.3.1/debian/dirs memlockd-1.3.1/debian/dirs
--- memlockd-1.3.1/debian/dirs  2012-06-16 07:33:33.0 +0200
+++ memlockd-1.3.1/debian/dirs  2023-10-18 21:17:08.0 +0200
@@ -2,4 +2,3 @@
 etc/default
 etc/memlockd.d
 usr/share/man/man8
-lib/systemd/system

Bug#1054189: bullseye-pu: package debian-security-support/1:11+2023.10.17

[Santiago Ruano Rincón]

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

Dear release team,

[ Reason ]
The reasons for this proposed update are:
* Fix two bugs already solved in bookworm (#986581 and #986333)
* Include samba in the list of packages with limited support (#1053109).

Currently, because of #986581 and #986333, d-d-s's check-support-status
silently ignores "golang*" packages, so users don't get any warning
about their limited support status.

[ Impact ]
Bullseye users will continue to don't get any warning about the limited
support regarding the golang.* packages installed in their systems.

As for the samba-related change, without the upload, users will lose a
change to get informed about its security support situation.

[ Tests ]
The changes include tests to verify #986581 and #986333 have been fixed.
I have also manually verified on a bullseye container how the current
and the proposed packages behave, and I can confirm the issues are
fixed, and I didn't identify any regression.

[ Risks ]
The relevant code has been included in bookworm since its release. They
were fully included in 1:12+2021.09.30:
https://tracker.debian.org/news/1263114/accepted-debian-security-support-11220210930-source-into-unstable/

The only difference in check-suppor-status.in between the proposed
update and bookworm is:

git diff HEAD bookworm -- check-support-status.in
diff --git a/check-support-status.in b/check-support-status.in
index 3ebf5e9..86b080a 100755
--- a/check-support-status.in
+++ b/check-support-status.in
@@ -13,7 +13,7 @@ VERSION='[% VERSION %]'
 # Oldest Debian version included in debian-security-support
 DEB_LOWEST_VER_ID=9
 # Version ID for next Debian stable
-DEB_NEXT_VER_ID=12
+DEB_NEXT_VER_ID=13

 if [ -z "$DEBIAN_VERSION" ] ; then
 DEBIAN_VERSION="$(cat /etc/debian_version | grep '[0-9.]' | cut -d. -f1)"

So the risk of regression is miminum.


Regarding the change of adding samba in the list of packages with
limited support. That doesn't represent any risk.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

From d/changelog:

  * Mark samba support limited to non-AD DC uses cases (Closes: #1053109)

The explanation is found here: https://www.debian.org/security/2021/dsa-5015

  * Drop version-based check (Closes: #986581) and update test suite
accordingly. Backport changes made by Sylvain Beucler.
  * Match ecosystems with limited support, test case updated. (Closes: #986333)
Backport changes by Sylvain Beucler.

These changes are reflected in check-support-status.in. The tests to
check them are found in t/check-support-status. To fix the relevant
bugs, the changes needed to remove a conditional to avoid comparing
against an installed version. Check that is kind of obsolete, and
didn't have any sense to compare against package name patters.
Second, the changes included the fix to compare against a regex
pattern, and avoid misidentifying packages whose name would match
the non-optimal "golang*". And that is the reason for:

* Use golang.* (as regex) instead of golang* in security-support-limited

[ Other info ]

N/A

Cheers,

 -- Santiago
diff -Nru debian-security-support-11+2023.05.04/check-support-status.in 
debian-security-support-11+2023.10.17/check-support-status.in
--- debian-security-support-11+2023.05.04/check-support-status.in   
2023-05-04 14:27:19.0 -0300
+++ debian-security-support-11+2023.10.17/check-support-status.in   
2023-10-17 13:08:20.0 -0300
@@ -175,12 +175,11 @@
 
 # Create intersection
 LEFT="$TEMPDIR/left"
-RIGHT="$TEMPDIR/right"
 INTERSECTION_LIST="$TEMPDIR/intersection"
 [% AWK %] -F'\t' '{print $3}' "$INSTALLED_LIST" | LC_ALL=C sort -u >"$LEFT"
-grep -v '^#' "$LIST" | LC_ALL=C sort | [% AWK %] '{print $1}' >"$RIGHT"
+PATTERNS=$(grep -vP '^(#|$)' "$LIST" | [% AWK %] '{print $1}' | paste -sd'|')
 
-LC_ALL=C comm -12 "$LEFT" "$RIGHT" >"$INTERSECTION_LIST"
+LC_ALL=C grep -P -x -e "$PATTERNS" "$LEFT" >"$INTERSECTION_LIST" || true
 if [ ! -s "$INTERSECTION_LIST" ] ; then
 # nothing to do
 exit 0
@@ -190,9 +189,14 @@
 mkdir -p "$TD"
 
 cat "$INTERSECTION_LIST" | while read SRC_NAME ; do
+LINE=$(grep -vP '^(#|$)' "$LIST" | while read pattern rest ; do
+if echo $SRC_NAME | grep -q -P -x -e "$pattern" ; then
+echo "$pattern $rest"
+break
+fi
+done)
 IFS="$(printf '\nx')"
 IFS="${IFS%x}"
-LINE="$([% AWK %] '($1=="'"$SRC_NAME"'"){print}' "$LIST" | head -1)"
 case "$TYPE" in
 earlyend)
 TMP_WHEN="$(echo "$LINE" | [% AWK %] '{print $3}')"
@@ -256,34 +260,28 @@
   

Bug#1054190: arpon: installs arpon@.service twice once dh_installsystemd installs to /usr

[Helmut Grohne]

Source: arpon
Version: 3.0-ng+dfsg1-4
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd to install units to /usr to finalize
the /usr-merge transition via DEP17. Once doing so, arpon will ship both
/usr/lib/systemd/system/arpon@.service (via dh_installsystemd) and
/lib/systemd/system/arpon@.service (via dh_install). Doing so is a
policy violation. I'm attaching a patch for your convenience. This bug
will become release critical once I upload debhelper.

Helmut
diff -Nru arpon-3.0-ng+dfsg1/debian/arpon.install 
arpon-3.0-ng+dfsg1/debian/arpon.install
--- arpon-3.0-ng+dfsg1/debian/arpon.install 2021-02-01 19:41:17.0 
+0100
+++ arpon-3.0-ng+dfsg1/debian/arpon.install 1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-debian/arpon@.service lib/systemd/system
diff -Nru arpon-3.0-ng+dfsg1/debian/changelog 
arpon-3.0-ng+dfsg1/debian/changelog
--- arpon-3.0-ng+dfsg1/debian/changelog 2021-02-01 19:41:17.0 +0100
+++ arpon-3.0-ng+dfsg1/debian/changelog 2023-10-18 12:42:25.0 +0200
@@ -1,3 +1,10 @@
+arpon (3.0-ng+dfsg1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd units only once. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Oct 2023 12:42:25 +0200
+
 arpon (3.0-ng+dfsg1-4) unstable; urgency=medium
 
   [ Samuel Henrique ]

Bug#1054187: dico: installs systemd units twice once dh_installsystemd installs to /usr

[Helmut Grohne]

Package: dicod
Version: 2.11-3
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd to install units to /usr to finalize
the /usr-merge transition via DEP17. When doing so, the dicod will
install some of its units twice. They'll be present in
/usr/lib/systemd/system (via dh_installsystemd) and in
/lib/systemd/system (via dh_install). Doing so is a policy violation.
I'm attaching a patch for your convenience. Once I upload debhelper,
this bug will become release-critical.

Helmut
diff -Nru dico-2.11/debian/changelog dico-2.11/debian/changelog
--- dico-2.11/debian/changelog  2023-06-30 05:52:24.0 +0200
+++ dico-2.11/debian/changelog  2023-10-18 15:00:02.0 +0200
@@ -1,3 +1,10 @@
+dico (2.11-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd units only once. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Oct 2023 15:00:02 +0200
+
 dico (2.11-3) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru dico-2.11/debian/dicod.install dico-2.11/debian/dicod.install
--- dico-2.11/debian/dicod.install  2023-06-30 05:52:24.0 +0200
+++ dico-2.11/debian/dicod.install  2023-10-18 14:59:43.0 +0200
@@ -16,6 +16,4 @@
 usr/lib/*/dico/pcre.so
 usr/lib/*/dico/pam.so
 usr/lib/*/dico/metaphone2.so
-debian/dicod@.service lib/systemd/system/
-debian/dicod.socket lib/systemd/system/
 debian/xinetd/dicod etc/xinetd.d/
diff -Nru dico-2.11/debian/dicod.links dico-2.11/debian/dicod.links
--- dico-2.11/debian/dicod.links2023-06-30 05:52:24.0 +0200
+++ dico-2.11/debian/dicod.links2023-10-18 15:00:02.0 +0200
@@ -1,4 +1,3 @@
 usr/bin/dicodconfig usr/sbin/dictdconfig
 usr/share/man/man8/dicodconfig.8.gz usr/share/man/man8/dictdconfig.8.gz
 etc/init.d/dicod etc/init.d/dictd
-lib/systemd/system/dicod.service lib/systemd/system/dictd.service
diff -Nru dico-2.11/debian/rules dico-2.11/debian/rules
--- dico-2.11/debian/rules  2023-06-30 05:52:24.0 +0200
+++ dico-2.11/debian/rules  2023-10-18 15:00:02.0 +0200
@@ -47,3 +47,6 @@
 override_dh_auto_test:
mkdir -p $(TEST_HOME)
HOME=$(TEST_HOME) dh_auto_test || cat dicod/tests/testsuite.log
+
+execute_after_dh_installsystemd:
+   ln -s dicod.service debian/dicod/`test -e 
debian/dicod/lib/systemd/system/dicod.service || echo 
usr/`lib/systemd/system/dictd.service

Bug#1054188: debci: installs systemd unit twice once dh_installsystemd installs to /usr

[Helmut Grohne]

Source: debci
Version: 3.6
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd to install units to /usr to finalize
the /usr-merge transition via DEP17. When doing so, at least one unit is
installed to both /usr/lib/systemd/system (via dh_installsystemd) and
/lib/systemd/system (via dh_install). Doing so is a policy violation.
I'm attaching a patch for your convenience. Once I upload debhelper,
this bug will become release critical.

Helmut
diff -Nru debci-3.6/debian/changelog debci-3.6+nmu1/debian/changelog
--- debci-3.6/debian/changelog  2023-02-26 16:08:48.0 +0100
+++ debci-3.6+nmu1/debian/changelog 2023-10-18 14:23:50.0 +0200
@@ -1,3 +1,10 @@
+debci (3.6+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install units with dh_installsystemd only. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Oct 2023 14:23:50 +0200
+
 debci (3.6) unstable; urgency=medium
 
   [ Louis-Philippe Véronneau ]
diff -Nru debci-3.6/debian/debci-collector.debci-update.service 
debci-3.6+nmu1/debian/debci-collector.debci-update.service
--- debci-3.6/debian/debci-collector.debci-update.service   1970-01-01 
01:00:00.0 +0100
+++ debci-3.6+nmu1/debian/debci-collector.debci-update.service  2023-02-26 
16:08:48.0 +0100
@@ -0,0 +1,10 @@
+[Unit]
+Description=debci index generator
+Documentation=https://ci.debian.net/doc/
+
+[Service]
+Type=oneshot
+User=debci
+Group=debci
+ExecStart=/bin/sleep 1s
+ExecStart=/usr/bin/debci update
diff -Nru debci-3.6/debian/debci-collector.debci-update.timer 
debci-3.6+nmu1/debian/debci-collector.debci-update.timer
--- debci-3.6/debian/debci-collector.debci-update.timer 1970-01-01 
01:00:00.0 +0100
+++ debci-3.6+nmu1/debian/debci-collector.debci-update.timer2023-02-26 
16:08:48.0 +0100
@@ -0,0 +1,8 @@
+[Unit]
+Description=debci update timer
+
+[Timer]
+OnCalendar=*:0/5
+
+[Install]
+WantedBy=timers.target
diff -Nru debci-3.6/debian/debci-collector.install 
debci-3.6+nmu1/debian/debci-collector.install
--- debci-3.6/debian/debci-collector.install2023-02-26 16:08:48.0 
+0100
+++ debci-3.6+nmu1/debian/debci-collector.install   2023-10-18 
14:22:54.0 +0200
@@ -1,6 +1,3 @@
-debian/debci-update.service  lib/systemd/system/
-debian/debci-update.timerlib/systemd/system/
-
 bin/debci-expireusr/share/debci/bin
 bin/debci-updateusr/share/debci/bin
 bin/debci-statususr/share/debci/bin
diff -Nru debci-3.6/debian/debci-update.service 
debci-3.6+nmu1/debian/debci-update.service
--- debci-3.6/debian/debci-update.service   2023-02-26 16:08:48.0 
+0100
+++ debci-3.6+nmu1/debian/debci-update.service  1970-01-01 01:00:00.0 
+0100
@@ -1,10 +0,0 @@
-[Unit]
-Description=debci index generator
-Documentation=https://ci.debian.net/doc/
-
-[Service]
-Type=oneshot
-User=debci
-Group=debci
-ExecStart=/bin/sleep 1s
-ExecStart=/usr/bin/debci update
diff -Nru debci-3.6/debian/debci-update.timer 
debci-3.6+nmu1/debian/debci-update.timer
--- debci-3.6/debian/debci-update.timer 2023-02-26 16:08:48.0 +0100
+++ debci-3.6+nmu1/debian/debci-update.timer1970-01-01 01:00:00.0 
+0100
@@ -1,8 +0,0 @@
-[Unit]
-Description=debci update timer
-
-[Timer]
-OnCalendar=*:0/5
-
-[Install]
-WantedBy=timers.target
diff -Nru debci-3.6/debian/debci-worker.install 
debci-3.6+nmu1/debian/debci-worker.install
--- debci-3.6/debian/debci-worker.install   2023-02-26 16:08:48.0 
+0100
+++ debci-3.6+nmu1/debian/debci-worker.install  1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-debian/debci-worker@.service lib/systemd/system/
diff -Nru debci-3.6/debian/rules debci-3.6+nmu1/debian/rules
--- debci-3.6/debian/rules  2023-02-26 16:08:48.0 +0100
+++ debci-3.6+nmu1/debian/rules 2023-10-18 14:23:24.0 +0200
@@ -19,6 +19,9 @@
 override_dh_installinit:
@true
 
+execute_after_dh_installsystemd:
+   dh_installsystemd -pdebci-collector --name=debci-update
+
 override_dh_install:
dh_install
debian/sanity-check

Bug#1054186: icingadb: installs icingadb.service twice once dh_installsystemd installs to /usr

[Helmut Grohne]

Source: icingadb
Version: 1.1.1-1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd such that it installs units below
/usr to finalize the /usr-merge transition via DEP17. When doing so,
icingadb.service is installed to both /usr/lib/systemd/system (via
dh_installsystemd) and /lib/systemd/system (via dh_install). Doing so is
a policy violation. I'm attaching a patch for your convenience. Once I
upload debhelper, this bug will become release-critical.

Helmut
diff -Nru icingadb-1.1.1/debian/changelog icingadb-1.1.1/debian/changelog
--- icingadb-1.1.1/debian/changelog 2023-08-09 15:11:20.0 +0200
+++ icingadb-1.1.1/debian/changelog 2023-10-18 21:04:27.0 +0200
@@ -1,3 +1,10 @@
+icingadb (1.1.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd unit only once. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Oct 2023 21:04:27 +0200
+
 icingadb (1.1.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru icingadb-1.1.1/debian/install icingadb-1.1.1/debian/install
--- icingadb-1.1.1/debian/install   2022-11-09 16:07:33.0 +0100
+++ icingadb-1.1.1/debian/install   2023-10-18 21:04:25.0 +0200
@@ -1,4 +1,3 @@
 #!/usr/bin/dh-exec
 config.example.yml   => etc/icingadb/config.yml
-debian/icingadb.service lib/systemd/system
 schema  usr/share/icingadb

Bug#1054185: goiardi: installs goiardi.service twice when dh_installsystemd installs to /usr

[Helmut Grohne]

Source: goiardi
Version: 0.11.10-1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd to install units to /usr to finalize
the /usr-merge transition via DEP17. When doing so, goiardi.service is
installed both to /usr/lib/systemd/system (via dh_installsystemd) and to
/lib/systemd/system (via dh_install). Doing so is a policy violation.
I'm attaching a patch for your convenience. When I upload debhelper,
this bug will become release-critical.

Helmut
diff -Nru goiardi-0.11.10/debian/changelog goiardi-0.11.10/debian/changelog
--- goiardi-0.11.10/debian/changelog2019-11-06 15:41:53.0 +0100
+++ goiardi-0.11.10/debian/changelog2023-10-18 20:29:51.0 +0200
@@ -1,3 +1,10 @@
+goiardi (0.11.10-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install goiardi.service only once. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 18 Oct 2023 20:29:51 +0200
+
 goiardi (0.11.10-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru goiardi-0.11.10/debian/goiardi.install 
goiardi-0.11.10/debian/goiardi.install
--- goiardi-0.11.10/debian/goiardi.install  2019-11-06 14:54:04.0 
+0100
+++ goiardi-0.11.10/debian/goiardi.install  2023-10-18 20:29:49.0 
+0200
@@ -1,5 +1,4 @@
 debian/goiardi.conf etc/goiardi
-debian/goiardi.service lib/systemd/system
 sql-files usr/share/goiardi/sql-files
 scripts usr/share/goiardi/scripts
 usr/bin

Bug#1054184: patroni: duplicate unit once dh_installsystemd installs to /usr

[Helmut Grohne]

Package: patroni
Version: 3.1.2-1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd such that it installs units below
/usr to finalize the /usr-merge transition via DEP17. When doing so,
patroni installs a unit to both /usr/lib/systemd/system (via
dh_installsystemd) and /lib/systemd/system (via dh_install). Doing so is
a policy violation. I've prepared a patch, but it is not representable
by debdiff due to the use of symlinks:

ln -s ../extras/startup-scripts/patroni.service debian/
sed -i -e /systemd/d debian/patroni.install 

Once I upload debhelper, this bug will become release-critical.

Helmut

Bug#1054183: RFP: pdfbox -- PDF utilities (based on Apache PDFBox)

[Stephen Eisenhauer]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: bhs2...@gmail.com

* Package name: pdfbox
  Version : 3.0.0
  Upstream Contact: PDFBox Users Mailing List 
* URL : https://pdfbox.apache.org/
* License : Apache License 2.0
  Programming Lang: Java
  Description : PDF utilities (based on Apache PDFBox)

The Apache PDFBox® library is an open source Java tool for working with PDF
documents. This project allows creation of new PDF documents, manipulation of
existing documents and the ability to extract content from documents.

This package would provide the PDFBox command-line utility
(https://pdfbox.apache.org/3.0/commandline.html), including a
desktop launcher for the 'debug' subcommand which invokes the
graphical PDF Debugger application.

Debian already packages the PDFBox library (as libpdfbox-java
and libpdfbox2-java), but does not yet package these utilities
or the included PDF Debugger. This project shares similarities
with Poppler, but contains some valuable features which Poppler
alone does not.

Bug#1054170: graphviz: dot generates unreproducible pdfs with embedded timestamps

[GCS]

Hi Daniel,

On Wed, Oct 18, 2023 at 5:45 PM Daniel Gröber  wrote:
> dot appears to embed CreationDate in the pdf and this cannot be
> controlled with SOURCE_DATE_EPOCH.
Can you please test it with the Graphviz version 9.0 in experimental?
I don't expect it to be different, but I would like to be sure.

Thanks,
Laszlo/GCS

Bug#1054182: ITP: python-scramp -- Python implementation of the SCRAM protocol

[Alexander Sulfrian]

Package: wnpp
Severity: wishlist
Owner: Alexander Sulfrian 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-scramp
  Version : 1.4.4
  Upstream Author : Tony Locke 
* URL : https://github.com/tlocke/scramp
* License : MIT-0
  Programming Lang: Python
  Description : Python implementation of the SCRAM protocol

A Python implementation of the SCRAM authentication protocol.

python-scramp is a dependency for recent versions of python-pg8000.

I plan to package it inside the Debian Python Team, but I will need a
sponsor.

Bug#1054139: file conflict between python3-ledger-dbgsym and ledger-dbgsym

[Marcin Owsiany]

reassign 1054139 debhelper
thanks

I guess this means there should be a way to influence the auto-generated
control file for dbgsym packages?

Marcin

śr., 18 paź 2023, 11:57 użytkownik David Bremner 
napisał:

>
> Control: tag -1 wontfix
>
> Marcin Owsiany  writes:
>
> > Package: python3-ledger-dbgsym
> > Version: 3.3.0-3
> > Severity: normal
> >
> > I got the following error when trying to install ledger-dbgsym while
> > python3-ledger-dbgsym is already installed:
> >
> > Przygotowywanie do rozpakowania pakietu
> .../ledger-dbgsym_3.3.0-3_amd64.deb ...
> > Rozpakowywanie pakietu ledger-dbgsym (3.3.0-3) ...
> > dpkg: błąd przetwarzania archiwum
> /var/cache/apt/archives/ledger-dbgsym_3.3.0-3_amd64.deb (--unpack):
> >  próba nadpisania
> "/usr/lib/debug/.build-id/bb/b9da531167728c34db6adc7a5ace6f0d21a6d2.debug",
> który istnieje także w pakiecie python3-ledger-dbgsym 3.3.0-3
> > Wystąpiły błędy podczas przetwarzania:
> >  /var/cache/apt/archives/ledger-dbgsym_3.3.0-3_amd64.deb
> >
>
> For future reference, it is better to generate such output with LANG=C
>
> > I guess the packages should conflict with each other?
> >
>
> Probably, but since they are automatically generated, I have no idea how
> to do that.
>
>

Bug#1052470: [Pkg-javascript-devel] Bug#1052470: nodejs: Please fix testsuite for openssl-3.1

[Sebastian Andrzej Siewior]

On 2023-10-17 22:08:07 [+0200], Jérémy Lal wrote:
> I did not forget about this. Really sorry for the delay.
> Currently I'd be more willing to help someone maintain nodejs than doing it
> myself.
> However, I'll probably deal with the next 18.x update very soon, including
> your patch.

Thank you. I just uploaded m2crypto to delayed-5 queue which is the
other blocker. And I might be busy otherwise the next week and week
after so no need to rush ;)

> Jérémy

Sebastian

Bug#1054181: libjs-bootstrap5: please provide scss files independently

[William Desportes]

Source: node-bootstrap
Severity: wishlist

Currently there is no way to have the scss sources (node-bootstrap) with 
phpunit that requires the old bootstrap 3.

Explained:
- phpunit pulls php-codecoverage that pulls libjs-bootstrap4
- https://packages.debian.org/sid/all/libjs-bootstrap4/filelist installs files 
in /usr/share/sass/bootstrap/
- https://packages.debian.org/sid/all/node-bootstrap/filelist installs files in 
/usr/share/sass/bootstrap/
- They exclude itself some installing, so far so good.

I currently can have libjs-bootstrap5 for the the js and css files, but I need 
the scss files too.

But given this impossible configuration I have to keep the contents of your 
node-bootstrap /usr/share/sass/bootstrap/ in my debian/missing-sources/
In order to have the phpunit that I need to run tests on my package and have 
the sources I need to build the package.

The package is: phpmyadmin

I am not sure how this can be improved, but I would like to have the scss files 
without breaking everything :)

--
William

Bug#1054180: openssl: FTBFS on loong64

[Sebastian Andrzej Siewior]

Package: openssl
Version: 3.1.2-1
Severity: wishlist
Tags: ftbfs
User:debian-de...@lists.debian.org
Usertags: loongarch64

OpenSSL 3.1.x in experimental FTBFS on loong64:

|crypto/aes/vpaes-loongarch64.S: Assembler messages:
|crypto/aes/vpaes-loongarch64.S:24: Error: no match insn: vori.b
$vr1,$vr9,0
|crypto/aes/vpaes-loongarch64.S:26: Error: no match insn: vld   $vr2,$r12,0
|crypto/aes/vpaes-loongarch64.S:27: Error: no match insn: vandn.v   
$vr1,$vr1,$vr0
…

Latest build log

https://buildd.debian.org/status/fetch.php?pkg=openssl=loong64=3.1.3-1=1695145526=0

My guess is that either binutils support is missing or a flag/ CPU
switch is missing to recognise the vector opcodes.

Sebastian

Bug#1051795: m2crypto: diff for NMU version 0.38.0-4.1

[Sebastian Andrzej Siewior]

Control: tags 1051795 + patch
Control: tags 1051795 + pending

Dear maintainer,

I've prepared an NMU for m2crypto (versioned as 0.38.0-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.
Sebastian
diff -Nru m2crypto-0.38.0/debian/changelog m2crypto-0.38.0/debian/changelog
--- m2crypto-0.38.0/debian/changelog	2022-11-17 03:32:27.0 +0100
+++ m2crypto-0.38.0/debian/changelog	2023-10-17 21:44:49.0 +0200
@@ -1,3 +1,10 @@
+m2crypto (0.38.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Adapt testsuite to OpenSSL 3.1 error codes (Closes: #1051795).
+
+ -- Sebastian Andrzej Siewior   Tue, 17 Oct 2023 21:44:49 +0200
+
 m2crypto (0.38.0-4) unstable; urgency=high
 
   [ Stefano Rivera ]
diff -Nru m2crypto-0.38.0/debian/patches/0005-Force-enable-tlsv1-for-the-tls1-tests.patch m2crypto-0.38.0/debian/patches/0005-Force-enable-tlsv1-for-the-tls1-tests.patch
--- m2crypto-0.38.0/debian/patches/0005-Force-enable-tlsv1-for-the-tls1-tests.patch	2022-11-17 03:32:27.0 +0100
+++ m2crypto-0.38.0/debian/patches/0005-Force-enable-tlsv1-for-the-tls1-tests.patch	2023-10-17 21:44:49.0 +0200
@@ -16,7 +16,7 @@
  with warnings.catch_warnings():
  warnings.simplefilter('ignore', DeprecationWarning)
  ctx = SSL.Context('tlsv1')
-+ctx.set_cipher_list('DEFAULT@SECLEVEL=1')
++ctx.set_cipher_list('DEFAULT@SECLEVEL=0')
  s = SSL.Connection(ctx)
  with six.assertRaisesRegex(self, SSL.SSLError,
 r'version|unexpected eof'):

Bug#1054179: pg_upgradecluster: please pass -j to analyze hook

[Chris Hofstaedtler]

Package: postgresql-common
Version: 254
Severity: wishlist

Dear Maintainer,

thanks for implementing automatic ANALYZE after pg_upgrade, as
/etc/postgresql-common/pg_upgradecluster.d/analyze.

It would be very useful, if vacuumdb would run with -j, if
pg_upgradecluster itself was called with -j.

On large databases this can save a lot of time.

Thanks for considering,
Chris

Bug#636108: Still a problem

[Ed Siefker]

Can we revisit this issue?  Upstream lightdm sources .profile, I don't
understand why Debian changes it.

Even if .profile shouldn't be used for graphical shells, ~/.local/bin
should clearly be in PATH out of the box.
If sourcing .profile is unacceptable, the contents of .profile should
be moved somewhere they will get sourced.
It's 12 years later, and this issue is still inconveniencing users.

Thanks
-Ed

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Luca Boccassi]

On Wed, 18 Oct 2023 at 18:36, Johannes Schauer Marin Rodrigues
 wrote:
>
> Hi Luca,
>
> Quoting Luca Boccassi (2023-10-18 19:17:40)
> > On Wed, 18 Oct 2023 at 18:04, Johannes Schauer Marin Rodrigues
> >  wrote:
> > >
> > > Hi,
> > >
> > > Quoting Santiago Vila (2023-10-12 17:56:04)
> > > > Johannes has asked the RMs in this thread:
> > > >
> > > > https://lists.debian.org/debian-release/2023/10/msg00425.html
> > > >
> > > > if they are ready to consider the bugs as RC. I believe it would be 
> > > > better
> > > > if we can make the bugs "factually" RC by uploading the fixed 
> > > > debootstrap first.
> > >
> > > I do not have a strong opinion on what should happen first but in that 
> > > thread,
> > > Holger and Sam also support the idea to first upload debootstrap.
> >
> > We can do an upload, but note that it won't have any effect on package
> > builds, given the buildds use stable/oldstable - and this is not
> > material for p-u, given the effect. Of course it will affect local
> > builds, in case they are done via debootstrap, from testing/unstable
> > users.
>
> Yes, I'm aware of that. But I think having this in unstable/testing already
> will help because several maintainers replied to the bugs saying they are
> unable to reproduce it. Having debootstrap with this change in 
> unstable/testing
> will make this a) much easier and b) convince people that they need to include
> this change or otherwise their package will really FTBFS on the buildds with
> the trixie release.
>
> And this should probably go without saying but just to make sure: if this
> change causes any weird bugs, please message me so that I can supply a fix.

Thanks - I'll merge and do an upload over the weekend then

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer Marin Rodrigues]

Hi Luca,

Quoting Luca Boccassi (2023-10-18 19:17:40)
> On Wed, 18 Oct 2023 at 18:04, Johannes Schauer Marin Rodrigues
>  wrote:
> >
> > Hi,
> >
> > Quoting Santiago Vila (2023-10-12 17:56:04)
> > > Johannes has asked the RMs in this thread:
> > >
> > > https://lists.debian.org/debian-release/2023/10/msg00425.html
> > >
> > > if they are ready to consider the bugs as RC. I believe it would be better
> > > if we can make the bugs "factually" RC by uploading the fixed debootstrap 
> > > first.
> >
> > I do not have a strong opinion on what should happen first but in that 
> > thread,
> > Holger and Sam also support the idea to first upload debootstrap.
> 
> We can do an upload, but note that it won't have any effect on package
> builds, given the buildds use stable/oldstable - and this is not
> material for p-u, given the effect. Of course it will affect local
> builds, in case they are done via debootstrap, from testing/unstable
> users.

Yes, I'm aware of that. But I think having this in unstable/testing already
will help because several maintainers replied to the bugs saying they are
unable to reproduce it. Having debootstrap with this change in unstable/testing
will make this a) much easier and b) convince people that they need to include
this change or otherwise their package will really FTBFS on the buildds with
the trixie release.

And this should probably go without saying but just to make sure: if this
change causes any weird bugs, please message me so that I can supply a fix.

Thank you!

cheers, josch

signature.asc
Description: signature

Bug#1054169: ares 132-1 fails to build on many architectures

[Benjamin Drung]

On Wed, 2023-10-18 at 16:45 +, Tobias Frost wrote:
> Control: severity -1 important
> 
> (this is not RC as it never has been built on those architectures before) 

Note: ares 126-3 has been built for armhf, riscv64, and s390x on Ubuntu
in the past: https://launchpad.net/ubuntu/+source/ares/126-3

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1053822: Acknowledgement (openssh-client: consider patch for allow GSSAPI to use default ccache or unique)

[Christoph Anton Mitterer]

FYI: Ubuntu is apparently also consider to add this:
https://github.com/openssh-gsskex/openssh-gsskex/issues/24#issuecomment-1768955946


Cheers,
Chris.

Bug#1053723: Acknowledgement (RFE backporting #1022126 (mpt3sas) fix to bookworm kernel (6.1.0-x))

[Tru Huynh]

I have tried today's netboot daily kernel, by connecting through the netconsole
and using mirror/suite=testing.

~ # uname -a
Linux sillage2 6.5.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.6-1 (2023-10-07) 
x86_64 GNU/Linux

~ # dmesg |grep mpt
[0.00] DMI: empty empty/S2927, BIOS 080014  10/11/2007
[0.015253]   Device   empty
[0.185227] Dynamic Preempt: voluntary
[0.185349] rcu: Preemptible hierarchical RCU implementation.
[  259.413730] mpt3sas version 43.100.00.00 loaded
[  259.414719] mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem 
(10246396 kB)
[  274.426680] mpt2sas_cm0: failure at 
drivers/scsi/mpt3sas/mpt3sas_scsih.c:12347/_scsih_probe()!

~ # modinfo mpt3sas|head
filename:   
/lib/modules/6.5.0-2-amd64/kernel/drivers/scsi/mpt3sas/mpt3sas.ko
alias:  mpt2sas
version:43.100.00.00
license:GPL
description:LSI MPT Fusion SAS 3.0 Device Driver
author: Avago Technologies 
srcversion: 66B89FF9BF29D51F17BE7B1
alias:  pci:v1000d00E7sv*sd*bc*sc*i*
alias:  pci:v1000d00E4sv*sd*bc*sc*i*
alias:  pci:v117Cd00E6sv*sd*bc*sc*i*

~ # lspci -nn -k
02:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS2008 
PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] (rev 03)
Subsystem: Broadcom / LSI 9211-8i [1000:3020]
Kernel modules: mpt3sas


Thanks

Tru
-- 
Tru Huynh (PhD) | mailto:t...@pasteur.fr | tel +33 1 45 68 87 37
https://research.pasteur.fr/en/team/structural-bioinformatics/
Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 France  

Bug#1054178: src:octave-ltfat: fails to migrate to testing for too long: FTBFS on armel

[Paul Gevers]

Source: octave-ltfat
Version: 2.5.0+dfsg-2
Severity: serious
Control: close -1 2.6.0+dfsg-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:octave-ltfat has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug. The version in unstable 
fails to build from source on armel.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=octave-ltfat



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054119: data loss patch for qpdf targeted at stable (11.3.0)

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Wed, 2023-10-18 at 11:31 -0400, Jay Berkenbilt wrote:
> On Tue, Oct 17, 2023, at 12:15 PM, Adam D. Barratt wrote:
> > 
[...]
> > Close, but a few rough edges. :-)
> > 
> 
> Ah, thanks for helping me get past my brain rot. When I used to
> maintain several packages, including tiff and icu, which had lots of
> security updates, I was much more familiar with this. It's funny how
> we can forget something so thoroughly that we can forget we knew it
> at one time. The doc reference was perfect and jogged my memory.
> 

Great. :)

A small style thought:

+ this->val += char(this->char_code % 256);
+ this->state = st_in_string;
+-return;
++if (!handled) {
++inString(ch);
++}

You've lost the explicit "return" there. So far as I can see there's no
practical impact, I just wasn't sure if you wanted it stylistically.

Either way, please go ahead.

Regards,

Adam

Bug#1054177: src:cp2k: fails to migrate to testing for too long: no longer buildable on armel

[Paul Gevers]

Source: cp2k
Version: 2023.1-2
Severity: serious
Control: close -1 2023.2-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:cp2k has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. The version in unstable can no 
longer be build on armel because libdbcsr-dev isn't build on armel. 
Please either help the dbcsr maintainer to build dbcsr on armel, or ask 
the ftp masters to remove cp2k from armel (in unstable).


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=cp2k



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Luca Boccassi]

On Wed, 18 Oct 2023 at 18:04, Johannes Schauer Marin Rodrigues
 wrote:
>
> Hi,
>
> Quoting Santiago Vila (2023-10-12 17:56:04)
> > Johannes has asked the RMs in this thread:
> >
> > https://lists.debian.org/debian-release/2023/10/msg00425.html
> >
> > if they are ready to consider the bugs as RC. I believe it would be better
> > if we can make the bugs "factually" RC by uploading the fixed debootstrap 
> > first.
>
> I do not have a strong opinion on what should happen first but in that thread,
> Holger and Sam also support the idea to first upload debootstrap.

We can do an upload, but note that it won't have any effect on package
builds, given the buildds use stable/oldstable - and this is not
material for p-u, given the effect. Of course it will affect local
builds, in case they are done via debootstrap, from testing/unstable
users.

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Santiago Vila (2023-10-12 17:56:04)
> Johannes has asked the RMs in this thread:
> 
> https://lists.debian.org/debian-release/2023/10/msg00425.html
> 
> if they are ready to consider the bugs as RC. I believe it would be better
> if we can make the bugs "factually" RC by uploading the fixed debootstrap 
> first.

I do not have a strong opinion on what should happen first but in that thread,
Holger and Sam also support the idea to first upload debootstrap.

My thought process behind asking the release team about the bug severity was,
that I found it unlikely for the remaining bugs to go down to zero without the
release team declaring that those bugs are indeed of significant severity.

Paul Gevers suggested that I should NMU to DELAYED/10 without raising the
severity.

There are not many packages remaining, so I'm impartial on how this is moved
forward.

On a different topic: this change in debootstrap will break mmdebstrap because
mmdebstrap compares its own output against the output of debootstrap to verify
that it does the right thing. Here is the patch to mmdebstrap that fixes this
issue:

@@ -2955,15 +2966,15 @@ sub run_install() {
 
 my @pkgs_to_install = (@{ $options->{include} });
 if ($options->{variant} eq 'buildd') {
-push @pkgs_to_install, 'build-essential';
+push @pkgs_to_install, 'build-essential', 'apt';
 }
 if (any { $_ eq $options->{variant} }
-('required', 'important', 'standard', 'buildd')) {
+('required', 'important', 'standard')) {
 # Many of the priority:required packages are also essential:yes. We
 # make sure not to select those here to avoid useless "xxx is already
 # the newest version" messages.
 my $priority;
-if (any { $_ eq $options->{variant} } ('required', 'buildd')) {
+if (any { $_ eq $options->{variant} } ('required')) {
 $priority = '?and(?priority(required),?not(?essential))';
 } elsif ($options->{variant} eq 'important') {
 $priority = '?and(?or(?priority(required),?priority(important)),'

I verified that the patch from the MR indeed ends up doing the same as above
patch to mmdebstrap.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1054169: ares 132-1 fails to build on many architectures

[Tobias Frost]

Control: severity -1 important

(this is not RC as it never has been built on those architectures before)

Bug#1054176: node-rollup-plugin-typescript: failing dh_auto_test

[Tianyu Chen]

Source: node-rollup-plugin-typescript
Version: 11.1.2~ds+~1.0.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: sweetyf...@deepin.org

Hi,

During a rebuild of your package in unstable, your package fails to
build from source.

Full log can be accessed at:


https://build.opensuse.org/package/live_build_log/home:utsweetyfish:node-202309/node-rollup-plugin-typescript/Debian_Unstable/aarch64

Tail of log for your package:

not ok 81 one.js
  ---
operator: ok
expected: true
actual:   false
at: Test. 
(/usr/src/packages/BUILD/packages/typescript/test/test.js:927:9)
stack: |-
  Error: one.js
  at Test.assert [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:312:48)
  at Test.bound [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:95:17)
  at Test.assert (/usr/share/nodejs/tape/lib/test.js:431:7)
  at Test.bound [as true] 
(/usr/share/nodejs/tape/lib/test.js:95:17)
  at Test. 
(/usr/src/packages/BUILD/packages/typescript/test/test.js:927:9)
  ...
not ok 82 /* eslint-disable */ function one() { console.log('one'); } 
export { one }; 
  ---
operator: ok
expected: true
actual:   false
at: Test. 
(/usr/src/packages/BUILD/packages/typescript/test/test.js:928:9)
stack: |-
  Error: /* eslint-disable */
  function one() {
  console.log('one');
  }
  
  export { one };
  
  at Test.assert [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:312:48)
  at Test.bound [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:95:17)
  at Test.assert (/usr/share/nodejs/tape/lib/test.js:431:7)
  at Test.bound [as true] 
(/usr/share/nodejs/tape/lib/test.js:95:17)
  at Test. 
(/usr/src/packages/BUILD/packages/typescript/test/test.js:928:9)
  ...
...
1..105
# tests 105
# pass  103
# fail  2

dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit 
code 1
make: *** [debian/rules:5: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2

Thanks!
Tianyu Chen @ deepin

Bug#1054175: node-require-main-filename: failing dh_auto_test

[Tianyu Chen]

Source: node-require-main-filename
Version: 2.0.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: sweetyf...@deepin.org

Hi,

During a rebuild of your package in unstable, your package fails to
build from source.

Full log can be accessed at:


https://build.opensuse.org/package/live_build_log/home:utsweetyfish:node-202309/node-require-main-filename/Debian_Unstable/aarch64

Tail of log for your package:

# Subtest: should default to process.cwd() if require.main is 
undefined
not ok 1 - expected '/usr/src/packages/BUILD' to match 
/(?:.*autopkgtest.*|require-main-filename)/
  ---
  stack: |
Test. (test.js:34:36)
Test. 
(/usr/share/nodejs/tap/lib/mocha.js:93:20)
Test.cb (/usr/share/nodejs/libtap/lib/test.js:127:40)
/usr/share/nodejs/libtap/lib/test.js:369:21
Test.main (/usr/share/nodejs/libtap/lib/test.js:376:7)
Test.runMain 
(/usr/share/nodejs/libtap/lib/base.js:178:15)
/usr/share/nodejs/libtap/lib/test.js:490:13
Test.writeSubComment 
(/usr/share/nodejs/libtap/lib/test.js:561:5)
Test. 
(/usr/share/nodejs/libtap/lib/test.js:489:14)
loop (/usr/share/nodejs/function-loop/index.js:19:13)
Test. 
(/usr/share/nodejs/libtap/lib/test.js:892:9)
loop (/usr/share/nodejs/function-loop/index.js:19:13)
TAP.runBeforeEach 
(/usr/share/nodejs/libtap/lib/test.js:898:7)
Test.runBeforeEach 
(/usr/share/nodejs/libtap/lib/test.js:891:19)
Test.processSubtest 
(/usr/share/nodejs/libtap/lib/test.js:488:12)
Test.process 
(/usr/share/nodejs/libtap/lib/test.js:405:14)
Test.sub (/usr/share/nodejs/libtap/lib/test.js:234:10)
Test.test (/usr/share/nodejs/libtap/lib/test.js:258:17)
it (/usr/share/nodejs/tap/lib/mocha.js:92:5)
Suite.fn (test.js:33:3)
Test. 
(/usr/share/nodejs/tap/lib/mocha.js:33:24)
Test.cb (/usr/share/nodejs/libtap/lib/test.js:127:40)
/usr/share/nodejs/libtap/lib/test.js:369:21
Test.main (/usr/share/nodejs/libtap/lib/test.js:376:7)
Test.runMain 
(/usr/share/nodejs/libtap/lib/base.js:178:15)
/usr/share/nodejs/libtap/lib/test.js:490:13
TAP.writeSubComment 
(/usr/share/nodejs/libtap/lib/test.js:561:5)
Test. 
(/usr/share/nodejs/libtap/lib/test.js:489:14)
loop (/usr/share/nodejs/function-loop/index.js:19:13)
TAP.runBeforeEach 
(/usr/share/nodejs/libtap/lib/test.js:898:7)
TAP.processSubtest 
(/usr/share/nodejs/libtap/lib/test.js:488:12)
TAP.process 
(/usr/share/nodejs/libtap/lib/test.js:405:14)
TAP.sub (/usr/share/nodejs/libtap/lib/test.js:234:10)
TAP.test (/usr/share/nodejs/libtap/lib/test.js:258:17)
Suite.run (/usr/share/nodejs/tap/lib/mocha.js:29:7)
new Suite (/usr/share/nodejs/tap/lib/mocha.js:24:10)
describe (/usr/share/nodejs/tap/lib/mocha.js:8:3)
Object. (test.js:8:1)
Module.replacementCompile 
(/usr/share/nodejs/append-transform/index.js:60:13)
Object. 
(/usr/share/nodejs/append-transform/index.js:64:4)
  at:
line: 34
column: 36
file: test.js
function: Test.
  type: AssertionError
  showDiff: false
  actual: /usr/src/packages/BUILD
  expected: null
  operator: strictEqual
  tapCaught: testFunctionThrow
  test: should default to process.cwd() if require.main is 
undefined
  source: >2
  it('should default to process.cwd() if require.main 
is undefined', function () {

requireMainFilename({}).should.match(/(?:.*autopkgtest.*|require-main-filename)/)
---^
  })
})
  ...

1..1
# failed 1 test
not ok 4 - should default to process.cwd() if require.main is 
undefined # time=55.202ms

1..4
# failed 1 of 4 tests
  

Bug#1054174: node-clean-css: failed dh_auto_test

[Tianyu Chen]

Source: node-clean-css
Version: 5.3.1+~5.6.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: sweetyf...@deepin.org

Hi,

During a rebuild of your package in unstable, your package fails to
build from source.

Full log can be accessed at:


https://build.opensuse.org/package/live_build_log/home:utsweetyfish:node-202309/node-clean-css/Debian_Unstable/x86_64

Tail of log for your package:

  ✗ Errored » Asynchronous Error
  in protocol imports
  in 
test/protocol-imports-test.js/usr/src/packages/BUILD/test/protocol-imports-test.js:706
  this.proxyServer.destroy();
   ^

TypeError: Cannot read properties of undefined (reading 'destroy')
at Object.teardown 
(/usr/src/packages/BUILD/test/protocol-imports-test.js:706:24)
at runTeardown (/usr/share/nodejs/vows/lib/vows/suite.js:382:37)
at Object.tryEnd (/usr/share/nodejs/vows/lib/vows/suite.js:362:17)
at EventEmitter. 
(/usr/share/nodejs/vows/lib/vows.js:94:18)
at EventEmitter.emit (node:events:525:35)
at options.Emitter.emit (/usr/share/nodejs/vows/lib/vows.js:241:24)
at /usr/share/nodejs/vows/lib/vows/context.js:31:52
at process.processTicksAndRejections 
(node:internal/process/task_queues:77:11)

Node.js v18.13.0
dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit 
code 1
make: *** [debian/rules:8: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2

Thanks!
Tianyu Chen @ deepin

Bug#1054173: schroot: manpages mention bouncing mailinglist

[Daniel Gröber]

Package: schroot
Version: 1.6.13-3+b2
Severity: normal
X-Debbugs-Cc: d...@darkboxed.org

Hi Christoph,

The schroot manages mention the
buildd-tools-de...@lists.alioth.debian.org mailinglist all over the
place, but it doesn't seem to exist anymore and mail bounces.

Is there a new ML? If so please update the address in the documentation.

Thanks,
--Daniel

Bug#1054172: nextcloud-desktop: Header of main window displays black zone without widgets (XFCE)

[Olivier Berger]

Package: nextcloud-desktop
Version: 3.10.0-1
Severity: normal

Dear Maintainer,

I'm running Nextcloud-Desktop on XFCE, and just noticed that a recent update of 
my testing system caused the main dialog to display weirdly.

The zone which usually contains a dropbox allowing to switch the current 
account is display as a fully black zone (see attached screenshot).

Ths makes it quite difficult to use.

Hope this helps,

Best regards,

-- System Information:
Debian Release: trixie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable'), (100, 'bullseye-fasttrack'), (100, 
'bullseye-backports-staging')
Architecture: amd64 (x86_64)

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

Versions of packages nextcloud-desktop depends on:
ii  libc6  2.37-12
ii  libcloudproviders0 0.3.4-1
ii  libgcc-s1  13.2.0-4
ii  libglib2.0-0   2.78.0-2
ii  libkf5archive5 5.107.0-1
ii  libnextcloudsync0  3.10.0-1
ii  libqt5core5a   5.15.10+dfsg-3
ii  libqt5dbus55.15.10+dfsg-3
ii  libqt5gui5 5.15.10+dfsg-3
ii  libqt5keychain10.14.1-1
ii  libqt5network5 5.15.10+dfsg-3
ii  libqt5qml5 5.15.10+dfsg-2
ii  libqt5quick5   5.15.10+dfsg-2
ii  libqt5quickcontrols2-5 5.15.10+dfsg-2
ii  libqt5sql5-sqlite  5.15.10+dfsg-3
ii  libqt5svg5 5.15.10-2
ii  libqt5webenginecore5   5.15.15+dfsg-2+b1
ii  libqt5webenginewidgets55.15.15+dfsg-2+b1
ii  libqt5widgets5 5.15.10+dfsg-3
ii  libssl33.0.11-1
ii  libstdc++6 13.2.0-4
ii  nextcloud-desktop-common   3.10.0-1
ii  nextcloud-desktop-l10n 3.10.0-1
ii  qml-module-qt-labs-platform5.15.10+dfsg-2
ii  qml-module-qtgraphicaleffects  5.15.10-2
ii  qml-module-qtqml   5.15.10+dfsg-2
ii  qml-module-qtqml-models2   5.15.10+dfsg-2
ii  qml-module-qtquick-controls2   5.15.10+dfsg-2
ii  qml-module-qtquick-dialogs 5.15.10-2
ii  qml-module-qtquick-layouts 5.15.10+dfsg-2
ii  qml-module-qtquick-window2 5.15.10+dfsg-2
ii  qml-module-qtquick25.15.10+dfsg-2

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  3.10.0-1

nextcloud-desktop suggests no packages.

-- debconf-show failed

-- 
Olivier BERGER
https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#797781: schroot: /dev/shm line is commented out by default but it's required by a lot of stuff

[Daniel Gröber]

Hi,

I'd like to add here that I just ran into this in a different way. I do my
development in profile=destkop chroots which are also missing the /dev/shm
line in fstat like the default profile.

In my case upstream was using faketime(1) to tame some unreproducibility,
but this needs access to /dev/shm to function at all. Curiously the
permissions of /dev/shm were such that only root could write there:

(unstable-amd64-dekstop):~$ ls -ld /dev/shm
drwxr-xr-x 2 root root 40 Oct 16 10:36 /dev/shm

Adding the fstab line fixes this as tmpfs seems to set the mount point to
mode 777.

FYI: I build my sbuild and "desktop" chroots with sbuild-createchroot(8).

--Daniel

Bug#1054171: python3-pika: please package v1.3.2

[Alexandre Detiste]

Package: python3-pika
Version: 1.2.0-1
Severity: normal

Dear Maintainer,

Please package a new version of python3-pika.

The library itself is getting fairly stable,
but 1.20. is lacking typing annotations
and that make it harder to develop for this library.

Greetings,


Alexandre Detiste


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pika depends on:
ii  python3  3.11.4-5+b1

python3-pika recommends no packages.

Versions of packages python3-pika suggests:
pn  python-pika-doc  

-- no debconf information

Bug#1054170: graphviz: dot generates unreproducible pdfs with embedded timestamps

[Daniel Gröber]

Package: graphviz
Version: 2.42.2-7+b3
Severity: normal
X-Debbugs-Cc: d...@darkboxed.org

Hi Laszlo,

my package yosys uses `dot` as part of it's documentaion build, I've
been battling reproducibility issues in that part of the packaging for
a while now and I think I've finally tracked it down to a problem in
graphviz.

dot appears to embed CreationDate in the pdf and this cannot be
controlled with SOURCE_DATE_EPOCH.

Repro:

$ echo 'digraph { a -> b }' > test.dot
$ SOURCE_DATE_EPOCH=60 dot -Tpdf test.dot -o test.pdf
$ dumppdf -adt test.pdf 2>/dev/null | grep 'CreationDate' -A1
CreationDate
D:20231018173926+0200

Note: dumppdf is from python3-pdfminer.

Thanks,
--Daniel

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

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

Versions of packages graphviz depends on:
ii  libann01.1.2+doc-9+b1
ii  libc6  2.36-9+deb12u3
ii  libcdt52.42.2-7+b3
ii  libcgraph6 2.42.2-7+b3
ii  libexpat1  2.5.0-1
ii  libgcc-s1  12.2.0-14
ii  libgd3 2.3.3-9
ii  libglib2.0-0   2.74.6-2
ii  libgts-0.7-5   0.7.6+darcs121130-5+b1
ii  libgvc62.42.2-7+b3
ii  libgvpr2   2.42.2-7+b3
ii  liblab-gamut1  2.42.2-7+b3
ii  libstdc++6 12.2.0-14
ii  libx11-6   2:1.8.4-2+deb12u1
ii  libxaw72:1.0.14-1
ii  libxmu62:1.1.3-3
ii  libxt6 1:1.2.1-1.1

Versions of packages graphviz recommends:
ii  fonts-liberation2  2.1.5-1

Versions of packages graphviz suggests:
pn  graphviz-doc  
ii  gsfonts   2:20200910-7

-- no debconf information

Bug#1054169: ares 132-1 fails to build on many architectures

[Benjamin Drung]

Source: ares
Version: 126-3
Severity: serious
Justification: FTBFS
X-Debbugs-Cc: bdr...@debian.org

Dear Maintainer,

ares 132-1 fails to build on many architectures (like armhf, i386, etc):

```
 debian/rules clean
dh clean --sourcedirectory=desktop-ui
   dh_auto_clean -O--sourcedirectory=desktop-ui
 cd desktop-ui && make -j4 distclean
make[1]: Entering directory '/<>/desktop-ui'
../nall/GNUmakefile:123: *** unknown arch, please specify manually.. Stop.
make[1]: Leaving directory '/<>/desktop-ui'
```

dh_auto_build is called with arch='$(ares_arch)'. So dh_auto_clean
should be called with that parameter as well.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1054119: data loss patch for qpdf targeted at stable (11.3.0)

[Jay Berkenbilt]

On Tue, Oct 17, 2023, at 12:15 PM, Adam D. Barratt wrote:
> # bcc control@bugs.d.o
> user release.debian@packages.debian.org
> usertags 1054119 pu
> tags 1054119 bookworm moreinfo
> retitle 1054119 bookworm-pu: package qpdf/11.3.0-1
> thanks

Thanks for fixing the tags. I'll reply to this instead of starting
over.

> On Tue, 2023-10-17 at 07:32 -0400, Jay Berkenbilt wrote:
> > The attached patch to qpdf 11.3.0 fixes a bug that could potentially
> > result in loss of data. I'd like permission from the release team to
> > . . .
> >
>
> Close, but a few rough edges. :-)
>

Ah, thanks for helping me get past my brain rot. When I used to
maintain several packages, including tiff and icu, which had lots of
security updates, I was much more familiar with this. It's funny how
we can forget something so thoroughly that we can forget we knew it at
one time. The doc reference was perfect and jogged my memory.

> As noted in the dev-ref section, please use "reportbug
> release.debian.org" for p-u requests, or set equivalent metadata. That
> helps ensure that the request ends up in the correct section of our BTS
> web view, where uncategorised bugs may get overlooked for some time.
> I've fixed up the relevant bits for this request (see the start of my
> reply).

Thanks for fixing it up. Rather than starting over, I am replying with
the information from reportbug. I'll let you remove the moreinfo tag
assuming I have provided enough information.

--

[ Reason ]
Between qpdf 10.6.3 and 11.0.0, a contributor did substantial
refactoring and performance optimizations on qpdf, ultimately
achieving better than a 2x performance boost. In spite of careful
testing and review, a bug to the lexical layer of qpdf snuck in. From
the changelog:

 Fix data loss bug introduced in 11.0.0 and fixed in 11.6.3. The bug
 causes the qpdf tokenizer to discard the character after a one-digit
 or two-digit quoted octal string. Most writers don't create these, and
 they are rare outside of content streams. By default, qpdf doesn't
 parse content streams. The most common place for this to occur would
 be in a document's /ID string, but in the worst case, this bug could
 cause silent damage to some strings in a PDF file's metadata, such as
 bookmark names or form field values.

The fix is in upstream version 11.6.3 which has been uploaded to
unstable and has migrated to testing.

Given that this bug can cause potential data loss, updating stable is
warranted. The version in oldstable is not affected by this bug.

[ Impact ]
In rare cases, qpdf may silently corrupt data in the user's PDF file.

[ Tests ]
The commit that includes the fix:
https://github.com/qpdf/qpdf/commit/1ecc6bb29e24a4f89470ff91b2682b46e0576ad4
includes a number of new automated tests to specifically exercise this
bug. (I have not included the additional automated tests in the
patch.) Additionally, the user who reported the original upstream bug:
https://github.com/qpdf/qpdf/issues/1050 has confirmed that the issue
is fixed. I also verified with the user's file.

[ Risks ]
This is a very low-risk patch. The fix is small and targeted. qpdf has
a rigorous test suite and a very good track record for stability. A
bug of this sort is a very rare event.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
The character following the short octal quoted character was used to
cause a state transition in the tokenizer but not reprocessed in the
new state. The bug fixes this. Prior to refactoring, the code did not
suffer from this logic error because a different mechanism was used to
re-process a character used in a state transition.

[ Other info ]
Note: I am the upstream author of qpdf as well as the debian
maintainer of the package. The user who submitted the pull request
that contained this bug is a reliable and steady contributor to qpdf
who has made great improvements to the code base. Heavy refactoring
carries risks. qpdf processes millions of pages a day in commercial
and open source applications. It is very important to get this fix out
to avoid silent and hard-to-detect damage to PDF files.


qpdf_11.30.0-1--11.30.0-1+deb12u1.debdiff
Description: Binary data

Bug#1054168: adwaita-icon-theme: Legacy icons edit-clear and window-close break applications

[Colomban Wendling]

Package: adwaita-icon-theme
Version: 43-1
Severity: normal

Dear Maintainer,

Some legacy icons are distributed in only a subset of sizes, whereas
there is a symbolic version with all sizes.  Unfortunately, GTK's
symbolic fallback will not kick in if the icon exists non-symbolic at
any size, leading to weird broken UI for applications using those.

Namely, Geany still uses GTK_STOCK_CLEAR ("edit-clear" icon) and
GTK_STOCK_CLOSE ("window-close" icon), and Adwaita (v43) only has sizes
48 for the former, and 24 and 48 for the latter.  This leads to a silly
UI wasting lots of screen estate.

Yes, Geany could be updated to use the symbolic icons, and upstream
will probably do so in the future, but it's unlikely it is the only app
affected.  Moreover, it's unnoticeable with most other themes, that
don't show the issue.

Adwaita 45.0 currently in testing/unstable does not have them anymore,
fixing the issue as GTK will fall back on the symbolic icons, which are
available at reasonable sizes.  However, this doesn't fix apps in
stable.

File list from 43:

$ find /usr/share/icons/Adwaita/ -name window-close.png -o -name edit-clear.png
/usr/share/icons/Adwaita/48x48/legacy/window-close.png
/usr/share/icons/Adwaita/48x48/legacy/edit-clear.png
/usr/share/icons/Adwaita/24x24/legacy/window-close.png

Note that removing/moving those away and updating the icon cache fixes
the issue for Geany.  Maybe other icons affect other apps however.

It could be interesting to review the sizes in which icons are
distributed, as it might have similar effect if only a subset of sizes
is available (esp. if 16 or 24 is missing).

Attached Python program shows the behavior when used in a button and in
an entry, in three variants: GtkStock API, icon-name and
symbolic-icon-name.  You can easily see that they get better in that
order; and if you remove the offending icons from the theme, they all
magically work nicely.

I think this should be considered for Bookworm as it affects standard
installation of regular packages (GNOME + Geany, and possibly others).

Regards,
Colomban


PS: admittedly, I'm not entirely neutral in the matter, being a Geany
developer.  But still :)


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

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

Versions of packages adwaita-icon-theme depends on:
ii  gtk-update-icon-cache  3.24.38-2~deb12u1
ii  hicolor-icon-theme 0.17-2

Versions of packages adwaita-icon-theme recommends:
ii  librsvg2-common  2.54.7+dfsg-1~deb12u1

adwaita-icon-theme suggests no packages.

-- no debconf information
#!/usr/bin/env python3

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk


if __name__ == '__main__':
# force use of Adwaita icon theme
Gtk.Settings.get_default().set_property("gtk-icon-theme-name", "Adwaita")

box = Gtk.Box(orientation=Gtk.Orientation.HORIZONTAL, visible=True)

box.add(Gtk.Button(child=Gtk.Image(stock="gtk-clear",
   icon_size=Gtk.IconSize.BUTTON,
   visible=True), visible=True))
box.add(Gtk.Button(child=Gtk.Image(icon_name="edit-clear",
   icon_size=Gtk.IconSize.BUTTON,
   visible=True), visible=True))
box.add(Gtk.Button(child=Gtk.Image(icon_name="edit-clear-symbolic",
   icon_size=Gtk.IconSize.BUTTON,
   visible=True), visible=True))

box.add(Gtk.Entry(primary_icon_stock="gtk-close",
  secondary_icon_stock="gtk-clear",
  visible=True))
box.add(Gtk.Entry(primary_icon_name="window-close",
  secondary_icon_name="edit-clear",
  visible=True))
box.add(Gtk.Entry(primary_icon_name="window-close-symbolic",
  secondary_icon_name="edit-clear-symbolic",
  visible=True))

window = Gtk.Window(child=box, visible=True)
window.connect('destroy', Gtk.main_quit)

Gtk.main()

Bug#1054155: gnome-clocks: Missing dependency on libgtk-4-media-gstreamer

[Jeremy Bícha]

On Wed, Oct 18, 2023 at 10:52 AM Simon McVittie  wrote:
> In the longer term, we could consider making debian/libgtk-4-1.symbols.in
> generate a dependency on "libgtk-4-1 #MINVER#, libgtk-4-media-gstreamer"
> for dependent packages that refer to gtk_media_* symbols? But the cost
> of that would be that gir1.2-gtk-4.0 would probably pick up a hard
> dependency on libgtk-4-media-gstreamer, even though only a minority of
> GIR users are actually using the media APIs.

I imagine we could use a dh_shlibdeps override to strip that
dependency from gir1.2-gtk-4.0 (similar to the workaround we used to
let things like desktop themes avoid a hard GTK2 dependency).

Thank you,
Jeremy Bícha

Bug#1054155: gnome-clocks: Missing dependency on libgtk-4-media-gstreamer

[Simon McVittie]

Control: retitle -1 gnome-clocks: Missing dependency on libgtk-4-media-gstreamer

On Wed, 18 Oct 2023 at 08:41:49 -0400, Jeremy Bícha wrote:
> GTK4 (specifically libgtk-4-1) Recommends libgtk-4-media-streamer.
> Please install Recommends or you will experience unusual bugs like
> this one.
> 
> Marco, I see that you made that dependency a Recommends in gtk4
> 4.10.1+ds-2. Should we make it a Depends instead?

That would be a circular dependency: libgtk-4-media-gstreamer links to GTK 4
and therefore Depends on libgtk-4-1.

However, the contents of libgtk-4-media-gstreamer can't simply be included
in libgtk-4-1 without a Policy violation, because they don't include the
SONAME in their installation path, causing trouble for a hypothetical
future libgtk-4-2 (although I hope that in practice, libgtk-4-1 will be
the only SONAME used until it's superseded by GTK 5).

In the short term, I think a Recommends in libgtk-4-1, and a Depends in
packages like this one that are known to be active users of the media
parts of the API, is probably proportionate.

In the longer term, we could consider making debian/libgtk-4-1.symbols.in
generate a dependency on "libgtk-4-1 #MINVER#, libgtk-4-media-gstreamer"
for dependent packages that refer to gtk_media_* symbols? But the cost
of that would be that gir1.2-gtk-4.0 would probably pick up a hard
dependency on libgtk-4-media-gstreamer, even though only a minority of
GIR users are actually using the media APIs.

That could also cause problems for -ports architectures if GStreamer
starts depending on things like Rust, similar to the situation we have
with SVG support, where we would ideally have a hard dependency on
librsvg2-common but -ports architectures can't accept that.

smcv

Bug#1039116: ardour: Please repack without third party library

[IOhannes m zmoelnig]

Source: ardour
Followup-For: Bug #1039116

I was looking into this for ardour8, only to discover that ardour upstream
patches the lua engine to work around garbage collection issues in a realtime
context like ardour.

So: I'm afraid that i will not be able to drop the embedded lua library for now.

we will have to re-investigate once upstream switches to a newer lua version.

thanks

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

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

Bug#1054167: ftbfs: AssertionError in tests

[Tianyu Chen]

Source: node-grunt-legacy-log
Version: 1.0.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: sweetyf...@deepin.org

Hi,

During a rebuild of your package in unstable, your package fails to
build from source.

Full log can be accessed at:


https://build.opensuse.org/package/live_build_log/home:utsweetyfish:node-202309/node-grunt-legacy-log/Debian_Unstable/x86_64

Tail of log for your package:

[31m✖ Log instance - writeflags[39m

AssertionError: 'Flags: a, b\n' == 'Flags: \x1B[36ma\x1B[39m, 
\x1B[36mb\x1B[39m\n'
at Object.equal (/usr/share/nodejs/nodeunit/lib/types.js:83:39)
at stdoutEqual (/usr/src/packages/BUILD/test/index.js:26:8)
at Object.writeflags (/usr/src/packages/BUILD/test/index.js:210:5)
at /usr/share/nodejs/nodeunit/lib/core.js:232:20
at /usr/share/javascript/async/async.js:254:17
at /usr/share/javascript/async/async.js:157:25
at /usr/share/javascript/async/async.js:251:21
at /usr/share/javascript/async/async.js:615:34
at Object.setUp (/usr/src/packages/BUILD/test/index.js:57:5)
at /usr/share/nodejs/nodeunit/lib/core.js:260:35

AssertionError: 'Prefix: a, b\n' == 'Prefix: \x1B[36ma\x1B[39m, 
\x1B[36mb\x1B[39m\n'
at Object.equal (/usr/share/nodejs/nodeunit/lib/types.js:83:39)
at stdoutEqual (/usr/src/packages/BUILD/test/index.js:26:8)
at Object.writeflags (/usr/src/packages/BUILD/test/index.js:213:5)
at /usr/share/nodejs/nodeunit/lib/core.js:232:20
at /usr/share/javascript/async/async.js:254:17
at /usr/share/javascript/async/async.js:157:25
at /usr/share/javascript/async/async.js:251:21
at /usr/share/javascript/async/async.js:615:34
at Object.setUp (/usr/src/packages/BUILD/test/index.js:57:5)
at /usr/share/nodejs/nodeunit/lib/core.js:260:35

AssertionError: 'Prefix: a, b=false, c=0, d=null\n' == 'Prefix: 
\x1B[36ma\x1B[39m, \x1B[36mb=false\x1B[39m, \x1B[36mc=0\x1B[39m, 
\x1B[36md=null\x1B[39m\n'
at Object.equal (/usr/share/nodejs/nodeunit/lib/types.js:83:39)
at stdoutEqual (/usr/src/packages/BUILD/test/index.js:26:8)
at Object.writeflags (/usr/src/packages/BUILD/test/index.js:216:5)
at /usr/share/nodejs/nodeunit/lib/core.js:232:20
at /usr/share/javascript/async/async.js:254:17
at /usr/share/javascript/async/async.js:157:25
at /usr/share/javascript/async/async.js:251:21
at /usr/share/javascript/async/async.js:615:34
at Object.setUp (/usr/src/packages/BUILD/test/index.js:57:5)
at /usr/share/nodejs/nodeunit/lib/core.js:260:35

Thanks!
Tianyu Chen @ deepin

Bug#1050665: clutter-1.0: FTBFS on riscv64 due to test timeout

[Bo YU]

Source: clutter-1.0
Followup-For: Bug #1050665

Dear Maintainer,

It seems the package has the same issue like #1050818 and the package is
a very key package also, so do you have a plan to upload it and apply
the patch?

Many thanks for supporting riscv64 port here.

BR,
Bo

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


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1054165: ffmpeg: FTBFS when trying to bootstrap with pkg.ffmpeg.stage1

[Christian Marillat]

On 18 oct. 2023 15:43, John Paul Adrian Glaubitz  
wrote:

> Source: ffmpeg
> Version: 6.0-7
> Severity: normal
> User: debian-powe...@lists.debian.org
> Usertags: ppc64
> X-Debbugs-Cc: debian-powe...@lists.debian.org

[...]

> This can be fixed by manually installing libcjson-dev into the chroot, so 
> adding the
> build dependency "libcjson-dev [pkg.ffmpeg.stage1]" to debian/control should 
> fix this
> bug.

The problem comes from librist not ffmpeg as libcjson is listed in the
Requires.private: field in librist.pc

Christian

Bug#1054166: ruby-appraiser-rubocop 1.0.1-2 has invalid dependencies

[Benjamin Drung]

Package: ruby-appraiser-rubocop
Version: 1.0.1-2
Severity: serious
Justification: uninstallable
X-Debbugs-Cc: bdr...@debian.org

Dear Maintainer,

ruby-appraiser-rubocop 1.0.1-2 has invalid dependencies:

```
The following packages have unmet dependencies:
 ruby-appraiser-rubocop : Depends: ruby-rubocop (>= 0.9) but it is not 
installable
  Depends: ruby-ruby-appraiser (>= 1.0.3) but it is not 
installable
```

The dependencies should probably be rubocop and ruby-appraiser instead.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1054165: ffmpeg: FTBFS when trying to bootstrap with pkg.ffmpeg.stage1

[Sebastian Ramacher]

Control: reassign -1 librist-dev 0.2.9+dfsg-1
Control: affects -1 src:ffmpeg
Control: retitle -1 librist-dev: missing dependency on libcjson-dev

On 2023-10-18 15:43:40 +0200, John Paul Adrian Glaubitz wrote:
> Source: ffmpeg
> Version: 6.0-7
> Severity: normal
> User: debian-powe...@lists.debian.org
> Usertags: ppc64
> X-Debbugs-Cc: debian-powe...@lists.debian.org
> 
> Hello!
> 
> I just tried to rebootstrap ffmpeg for all Debian Ports architectures and 
> noticed that
> this no longer works due to the build dependency libcjson-dev missing for 
> build profile
> "pkg.ffmpeg.stage1":
> 
>  pkg-config --exists --print-errors librist >= 0.2.7
>  Package libcjson was not found in the pkg-config search path.
>  Perhaps you should add the directory containing `libcjson.pc'
>  to the PKG_CONFIG_PATH environment variable
>  Package 'libcjson', required by 'librist', not found
>  ERROR: librist >= 0.2.7 not found using pkg-config

This is a bug in librist-dev. Reassigning accordingy.

Cheers

> 
> This can be fixed by manually installing libcjson-dev into the chroot, so 
> adding the
> build dependency "libcjson-dev [pkg.ffmpeg.stage1]" to debian/control should 
> fix this
> bug.
> 
> Thanks,
> Adrian
> 
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 

-- 
Sebastian Ramacher

Bug#1054165: ffmpeg: FTBFS when trying to bootstrap with pkg.ffmpeg.stage1

[John Paul Adrian Glaubitz]

Source: ffmpeg
Version: 6.0-7
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hello!

I just tried to rebootstrap ffmpeg for all Debian Ports architectures and 
noticed that
this no longer works due to the build dependency libcjson-dev missing for build 
profile
"pkg.ffmpeg.stage1":

 pkg-config --exists --print-errors librist >= 0.2.7
 Package libcjson was not found in the pkg-config search path.
 Perhaps you should add the directory containing `libcjson.pc'
 to the PKG_CONFIG_PATH environment variable
 Package 'libcjson', required by 'librist', not found
 ERROR: librist >= 0.2.7 not found using pkg-config

This can be fixed by manually installing libcjson-dev into the chroot, so 
adding the
build dependency "libcjson-dev [pkg.ffmpeg.stage1]" to debian/control should 
fix this
bug.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1054164: libowasp-antisamy-java: CVE-2023-43643

[Salvatore Bonaccorso]

Source: libowasp-antisamy-java
Version: 1.5.3+dfsg-1.1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libowasp-antisamy-java.

Note: The severity is set to RC, though 'important' would better fit.
It looks that in each supported version in Debian we are still at
1.5.3. Is the library still maintained within Debian?

CVE-2023-43643[0]:
| AntiSamy is a library for performing fast, configurable cleansing of
| HTML coming from untrusted sources. Prior to version 1.7.4, there is
| a potential for a mutation XSS (mXSS) vulnerability in AntiSamy
| caused by flawed parsing of the HTML being sanitized. To be subject
| to this vulnerability the `preserveComments` directive must be
| enabled in your policy file and also allow for certain tags at the
| same time. As a result, certain crafty inputs can result in elements
| in comment tags being interpreted as executable when using
| AntiSamy's sanitized output. This issue has been patched in AntiSamy
| 1.7.4 and later.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-43643
https://www.cve.org/CVERecord?id=CVE-2023-43643
[1] https://github.com/nahsra/antisamy/security/advisories/GHSA-pcf2-gh6g-h5r2
[2] 
https://github.com/nahsra/antisamy/commit/05c52b98bb845b8175b8406bd2f391ce334a05d6

Regards,
Salvatore

Bug#1054163: fastdds: CVE-2023-42459

[Salvatore Bonaccorso]

Source: fastdds
Version: 2.11.2+ds-5
Severity: important
Tags: security upstream
Forwarded: https://github.com/eProsima/Fast-DDS/issues/3207
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for fastdds.

CVE-2023-42459[0]:
| Fast DDS is a C++ implementation of the DDS (Data Distribution
| Service) standard of the OMG (Object Management Group). In affected
| versions specific DATA submessages can be sent to a discovery
| locator which may trigger a free error. This can remotely crash any
| Fast-DDS process. The call to free() could potentially leave the
| pointer in the attackers control which could lead to a double free.
| This issue has been addressed in versions 2.12.0, 2.11.3, 2.10.3,
| and 2.6.7. Users are advised to upgrade. There are no known
| workarounds for this vulnerability.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-42459
https://www.cve.org/CVERecord?id=CVE-2023-42459
[1] https://github.com/eProsima/Fast-DDS/issues/3207
[2] https://github.com/eProsima/Fast-DDS/security/advisories/GHSA-gq8g-fj58-22gm

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1053131: Status Update

[Reinhard Tartler]

I've started packaging all dependencies up to buildah and have updated the
repository for 4.7.1 in the branch debian/experimental, commit e71d62879

Here is where I'm currently at:

src/github.com/containers/podman/pkg/machine/fcos.go:17:2: cannot find package 
"github.com/coreos/stream-metadata-go/fedoracoreos" in any of:
/usr/lib/go-1.21/src/github.com/coreos/stream-metadata-go/fedoracoreos 
(from $GOROOT)

/<>/_output/src/github.com/coreos/stream-metadata-go/fedoracoreos 
(from $GOPATH)
src/github.com/containers/podman/pkg/machine/fcos.go:18:2: cannot find package 
"github.com/coreos/stream-metadata-go/release" in any of:
/usr/lib/go-1.21/src/github.com/coreos/stream-metadata-go/release (from 
$GOROOT)

/<>/_output/src/github.com/coreos/stream-metadata-go/release (from 
$GOPATH)
src/github.com/containers/podman/pkg/machine/fcos.go:19:2: cannot find package 
"github.com/coreos/stream-metadata-go/stream" in any of:
/usr/lib/go-1.21/src/github.com/coreos/stream-metadata-go/stream (from 
$GOROOT)

/<>/_output/src/github.com/coreos/stream-metadata-go/stream (from 
$GOPATH)
src/github.com/containers/podman/pkg/checkpoint/crutils/checkpoint_restore_utils.go:12:2:
 cannot find package "github.com/checkpoint-restore/checkpointctl/lib" in any 
of:
/usr/lib/go-1.21/src/github.com/checkpoint-restore/checkpointctl/lib 
(from $GOROOT)

/<>/_output/src/github.com/checkpoint-restore/checkpointctl/lib 
(from $GOPATH)
src/github.com/containers/podman/libpod/plugin/volume_api.go:19:2: cannot find 
package "github.com/docker/go-plugins-helpers/sdk" in any of:
/usr/lib/go-1.21/src/github.com/docker/go-plugins-helpers/sdk (from 
$GOROOT)
/<>/_output/src/github.com/docker/go-plugins-helpers/sdk 
(from $GOPATH)
src/github.com/containers/podman/libpod/plugin/volume_api.go:20:2: cannot find 
package "github.com/docker/go-plugins-helpers/volume" in any of:
/usr/lib/go-1.21/src/github.com/docker/go-plugins-helpers/volume (from 
$GOROOT)

/<>/_output/src/github.com/docker/go-plugins-helpers/volume (from 
$GOPATH)
package github.com/containers/podman/pkg/checkpoint: build constraints exclude 
all Go files in 
/<>/_output/src/github.com/containers/podman/pkg/checkpoint
package github.com/containers/podman/pkg/specgen/generate: build constraints 
exclude all Go files in 
/<>/_output/src/github.com/containers/podman/pkg/specgen/generate
package github.com/containers/podman/pkg/specgen/generate/kube: build 
constraints exclude all Go files in 
/<>/_output/src/github.com/containers/podman/pkg/specgen/generate/kube
src/github.com/containers/podman/pkg/domain/infra/abi/play.go:41:2: cannot find 
package "k8s.io/kubernetes/third_party/forked/golang/expansion" in any of:

/usr/lib/go-1.21/src/k8s.io/kubernetes/third_party/forked/golang/expansion 
(from $GOROOT)

/<>/_output/src/k8s.io/kubernetes/third_party/forked/golang/expansion
 (from $GOPATH)


I'm not really sure what changed from the previous version, but this needs ot
be resolved one way or another. Please reach out to me if you are interested in
helping out here.

-rt

Bug#1054162: util-linux stage1 FTBFS

[Helmut Grohne]

Source: util-linux
Version: 2.39.2-2.2
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi,

When submitting my patch for the systemd.pc move, I failed to check the
stage1 profile. debhelper is very unhappy about not finding a
substitution variable that it does not know it does not need. The
obvious workaround is setting it. I'm attaching a patch for your
convenience. Setting severity important as this breaks architecture
bootstrap for all architectures. Sorry for not having properly tested
this earlier.

Helmut
diff --minimal -Nru util-linux-2.39.2/debian/changelog 
util-linux-2.39.2/debian/changelog
--- util-linux-2.39.2/debian/changelog  2023-10-09 21:21:34.0 +0200
+++ util-linux-2.39.2/debian/changelog  2023-10-14 23:04:34.0 +0200
@@ -1,3 +1,10 @@
+util-linux (2.39.2-2.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS in stage1 (regression of #1052981). (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 14 Oct 2023 23:04:34 +0200
+
 util-linux (2.39.2-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru util-linux-2.39.2/debian/rules 
util-linux-2.39.2/debian/rules
--- util-linux-2.39.2/debian/rules  2023-10-09 21:21:34.0 +0200
+++ util-linux-2.39.2/debian/rules  2023-10-14 22:56:12.0 +0200
@@ -55,6 +55,8 @@
 
 ifeq ($(filter stage1,$(DEB_BUILD_PROFILES))-$(DEB_HOST_ARCH_OS),-linux)
 export deb_systemdsystemunitdir = $(shell pkg-config 
--variable=systemdsystemunitdir systemd | sed s,^/,,)
+else
+export deb_systemdsystemunitdir = debhelper needs this variable even when it 
doesn't need it
 endif
 
 %:

Bug#986225: fixed in put-dns 0.0.2-6

[Andreas Beckmann]

Control: reopen -1

On Sat, 18 Feb 2023 22:11:52 + Debian FTP Masters 
 wrote:

 put-dns (0.0.2-6) unstable; urgency=medium
 .
   * Add Frecn debconf translation Closes:#986225


Wrong bugnumber closed here ...

Andreas

Bug#1054155: Missing new needed dependency on libgtk-4-media-gstreamer

[Jeremy Bícha]

Control: affects -1 src:gtk4

On Wed, Oct 18, 2023 at 6:45 AM  wrote:
> Package: gnome-clocks
> Version: 45.0-1
>
> Since the merge of
> https://gitlab.gnome.org/GNOME/gnome-clocks/-/merge_requests/253, GNOME
> Clocks uses GTK MediaStream, which is provided by
> libgtk-4-media-gstreamer, but that package has not been added to the
> dependencies of gnome-clocks in Debian. This results in no sound for
> events (alarms, countdown timers). Manually installing the package fixes
> the issue.

GTK4 (specifically libgtk-4-1) Recommends libgtk-4-media-streamer.
Please install Recommends or you will experience unusual bugs like
this one.

Marco, I see that you made that dependency a Recommends in gtk4
4.10.1+ds-2. Should we make it a Depends instead?

Thank you,
Jeremy Bícha

Bug#1054101: webkit2gtk: No provider of eglCreateImage found. Requires one of: EGL 15, yelp can't start

[Alberto Garcia]

On Wed, Oct 18, 2023 at 11:01:31AM +0800, xiao sheng wen wrote:
> > > No provider of eglCreateImage found.  Requires one of:
> > >  EGL 15
> > > Aborted
> > Do you have the egl library installed?
> Yes.

Ok, can you open webkit://gpu and send me the output?

   /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser webkit://gpu

Also, do you think you can obtain a stack trace of that abort?

Thanks,

Berto

Bug#1053690: ceph: CVE-2023-43040: Improperly verified POST keys

[Salvatore Bonaccorso]

Hi Thomas,

On Mon, Oct 09, 2023 at 05:53:29PM +0200, Thomas Goirand wrote:
> On 10/8/23 21:58, Salvatore Bonaccorso wrote:
> > Source: ceph
> > Version: 16.2.11+ds-4
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://github.com/ceph/ceph/pull/53714
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerability was published for ceph.
> > 
> > CVE-2023-43040[0]:
> > | Improperly verified POST keys
> > 
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2023-43040
> >  https://www.cve.org/CVERecord?id=CVE-2023-43040
> > [1] https://www.openwall.com/lists/oss-security/2023/09/26/10
> > [2] https://github.com/ceph/ceph/pull/53714
> > 
> > Please adjust the affected versions in the BTS as needed.
> > 
> > Regards,
> > Salvatore
> 
> Hi Salvatore,
> 
> Do you think this deserves a DSA, or should I deal with the stable release
> team?
> 
> FYI, Sid is fixed, and I built already the update for bookworm (but didn't
> upload as I need your input as per above).

Sorry for the late reply (due to various reasons). No the issue does
not warrant a DSA and might be fixed in the next point releases (if so
that would be very welcome!).

Regards,
Salvatore

Bug#1053664: marked as done (general: Plugging or unplugging USB device sometimes causes the system to lockup.)

[rhys]

Interesting. I have an FTDI device. I will try it on my bullseye and bookworm 
systems and see what they do. If they have trouble, I can gather lsusb, dmesg, 
and other data from it. 

--J

Sent from my mobile device.

From: Debian Bug Tracking System 
Sent: Wednesday, October 18, 2023 06:39
To: Tomas Pospisek
Subject: Bug#1053664: marked as done (general: Plugging or unplugging USB 
device sometimes causes the system to lockup.)

Your message dated Wed, 18 Oct 2023 12:57:27 +0200 (CEST) 
with message-id <436febb7-775-290-45a4-7a98acfb...@sourcepole.ch> 
and subject line closing, not enough infos 
has caused the Debian Bug report #1053664, 
regarding general: Plugging or unplugging  USB device sometimes causes the 
system to lockup. 
to be marked as done. 

This means that you claim that the problem has been dealt with. 
If this is not the case it is now your responsibility to reopen the 
Bug report if necessary, and/or fix the problem forthwith. 

(NB: If you are a system administrator and have no idea what this 
message is talking about, this may indicate a serious mail system 
misconfiguration somewhere. Please contact ow...@bugs.debian.org 
immediately.) 


-- 
1053664: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053664 
Debian Bug Tracking System 
Contact ow...@bugs.debian.org with problems
Package: general 
Severity: important 
X-Debbugs-Cc: cmclr...@gmail.com 

Dear Maintainer, 
plugging in a FTDI device caused lockup ( keyboard,mouse unresponsive) . Also 
unplugging and replugging wireless lan caused same condition. 
Hello clinton, 

your bug reports doesn't contain enough informations to be actionable. 
Therefore I am closing it. Please contact one of the Debian support 
channels to sort your problem out and possibly add useful informations to 
the bug report. 

See https://www.debian.org/support for support options. 

Thanks, 
*t

Bug#1054161: node-ast-types: ftbfs: error TS18028: Private identifiers are only available when targeting ECMAScript 2015 and higher

[Tianyu Chen]

Source: node-ast-types
Version: 0.15.2-3
Severity: important
Tags: ftbfs

Hi,

During a rebuild of your package in unstable, your package fails to
build from source.

Full log can be accessed at:


https://build.opensuse.org/package/live_build_log/home:utsweetyfish:node-ast-types/node-ast-types/Debian_Unstable/x86_64

Tail of log for your package:

dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
Link ./node_modules/@babel/types -> /usr/share/nodejs/@babel/types
Link ./node_modules/tslib -> /usr/share/nodejs/tslib
Link ./node_modules/@types/estree -> /usr/share/nodejs/@types/estree
Not found
### @types/minimatch is required by debian/nodejs/./extlinks but not 
available
# Typescript definition detected, Fallback to main module
### You SHOULD update your debian/nodejs/./extlinks file!
Link ./node_modules/minimatch -> /usr/share/nodejs/minimatch
Link ./node_modules/@types/mocha -> /usr/share/nodejs/@types/mocha
Link ./node_modules/@types/node -> /usr/share/nodejs/@types/node
Copy /usr/share/nodejs/@babel/parser -> ./node_modules/@babel
Copy /usr/share/nodejs/@types/esprima -> ./node_modules/@types
Copy /usr/share/nodejs/@types/glob -> ./node_modules/@types
   debian/rules override_dh_auto_build
make[1]: Entering directory '/usr/src/packages/BUILD'
tsc
../../../share/nodejs/minimatch/dist/cjs/ast.d.ts(4,5): error TS18028: 
Private identifiers are only available when targeting ECMAScript 2015 and 
higher.
make[1]: *** [debian/rules:7: override_dh_auto_build] Error 2
make[1]: Leaving directory '/usr/src/packages/BUILD'
make: *** [debian/rules:4: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2

Thanks!
Tianyu Chen @ deepin

Bug#1054160: RM: glusterfs/experimental -- RoQA; NVIU; 32-bit architectures were dropped

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Hi,

please remove the outdated glusterfs packages from experimental.
Automatic cruft removal does not catch these since there are still some
32-bit builds left which are no longer in unstable.


Andreas

Bug#1054159: paraview: build and provide gmsh plugin

[Drew Parsons]

Package: paraview
Version: 5.11.0+dfsg-2
Severity: normal

paraview offers a GMSH plugin, providing the capability to visualise
gmsh meshes.  It's not built by default, can it be added to the debian
paraview package?

Actually there's two of them,
https://salsa.debian.org/science-team/paraview/-/tree/debian/latest/Plugins/GmshIO
https://salsa.debian.org/science-team/paraview/-/tree/debian/latest/Plugins/GmshReader

GmshIO is the newer one and should be preferred.

I'm not sure if it would be constructive to build both of them, though
it could be done.

Bug#1054158: Data loss bug affecting qpdf 11.0.0 through 11.6.2 has upstream fix in 1ecc6bb2

[Jay Berkenbilt]

Package: qpdf
Version: 11.3.0-1
Severity: important
Tags: upstream
X-Debbugs-Cc: q...@debian.org

Note: I am the upstream author and debian maintainer for qpdf.

Upstream bug https://github.com/qpdf/qpdf/issues/1050 revealed a bug
in qpdf's lexical layer that would cause qpdf to discard the character
in a binary string following an octal quoted character with 1 or 2
digits. The PDF spec allows octal digits to be \d, \dd, or \ddd, and
allows the first two forms if the next character is other than an
octal digit. Most PDF writers never use the \d or \dd forms, but some
do. With default options, qpdf does not parse or alter strings inside
content streams, so this bug is not likely to affect page content.
However, binary strings of this sort are common in the document /ID
and may also appear in metadata for encrypted files. In some cases,
such as the file in #1050, this bug can cause error, in this case,
because the discarded character was the string end delimiter. In most
case, this bug results in silent data loss. The fix is very small and
locally contained. The upstream fix includes several new test cases,
but the patch I will include to fix the issue only includes the
relevant code change. I am not attaching a patch to the bug report
because I am the package maintainer and intend to immediately follow
this with a fix targeted to bookworm.

Please note: I am composing this bug from a system running Ubuntu
23.04 I have edited the package version in the bug pseudo-headers, but
the system information below pertains to the system I am running
reportbug from, which is not the system that is broken.

-- System Information:
Debian Release: bookworm/sid
  APT prefers lunar-updates
  APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'), 
(100, 'lunar-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages qpdf depends on:
ii  libc6   2.37-0ubuntu2.1
ii  libgcc-s1   13.1.0-2ubuntu2~23.04
ii  libqpdf29   11.6.3-1~bpo23.04.1~ppa1
ii  libstdc++6  13.1.0-2ubuntu2~23.04

qpdf recommends no packages.

qpdf suggests no packages.

-- no debconf information

Bug#1054157: mdevctl: env-logger should be strict enough for the requirement

[Adrian Bunk]

Source: mdevctl
Version: 1.2.0-4
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=mdevctl=arm64=1.2.0-4%2Bb3=1697626199=0

...
Merged Build-Depends: ..., librust-env-logger+default-dev,
...
The following NEW packages will be installed:
...
  librust-env-logger-0.7+default-dev librust-env-logger-0.7-dev
...
error: failed to select a version for the requirement `env_logger = "^0.10.0"`
...


librust-env-logger-0.7+default-dev providing librust-env-logger+default-dev
is also a bug (#1054156), but when mdevctl only accepts 0.10.0 the build
dependency should express this by using librust-env-logger-0.10.0+default-dev
instead of librust-env-logger+default-dev so that building is not even
attempted with an incompatible version.

Bug#1054156: librust-env-logger-0.7+default-dev shouldn't provide librust-env-logger+default-dev

[Adrian Bunk]

Package: librust-env-logger-0.7+default-dev
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=mdevctl=arm64=1.2.0-4%2Bb3=1697626199=0

...
Merged Build-Depends: ..., librust-env-logger+default-dev,
...
The following NEW packages will be installed:
...
  librust-env-logger-0.7+default-dev librust-env-logger-0.7-dev
...
error: failed to select a version for the requirement `env_logger = "^0.10.0"`
...


This is due to:
  librust-env-logger+default-dev reverse Provides:
  librust-env-logger-0.7+default-dev 0.7.1-4 (= 0.7.1-4)
  librust-env-logger-dev 0.10.0-2 (= 0.10.0-2)


I'll file a separate bug for mdevctl having a too loose build dependency.