Bug#1052634: linux-image-6.5.5-1-siduction-amd64: systemctl poweroff doesn't POWEROFF the PC with Kernel 6.5
Package: src:linux-siduction Version: 6.5-5 Severity: normal X-Debbugs-Cc: ch-hani...@t-online.de Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: ** Version: Linux version 6.5.5-1-siduction-amd64 (t...@siduction.org) (gcc-13 (Debian 13.2.0-4) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC siduction 6.5-5 (2023-09-24) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.5.5-1-siduction-amd64 root=UUID=6e94a92b-67e4-4a5b-aef9-e3e4f9bdf178 ro intel_iommu=igfx_off quiet resume=LABEL=SWAP systemd.show_status=1 ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [ 24.188723] intel_rapl_common: Found RAPL domain package [ 24.188738] intel_rapl_common: Found RAPL domain core [ 24.188742] intel_rapl_common: Found RAPL domain uncore [ 24.361650] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUG disabled [ 24.361657] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled [ 24.361667] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled [ 24.361669] iwlwifi :03:00.0: Detected Intel(R) Centrino(R) Wireless-N 1000 BGN, REV=0x6C [ 24.401448] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [ 24.453012] iwlwifi :03:00.0 wlp3s0: renamed from wlan0 [ 24.668005] Adding 6860796k swap on /dev/sdb6. Priority:-2 extents:1 across:6860796k FS [ 25.142425] i915 :00:02.0: vgaarb: deactivate vga console [ 25.142877] Console: switching to colour dummy device 80x25 [ 25.144658] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [ 25.175445] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on minor 0 [ 25.175762] ACPI: video: [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS [ 25.175798] ACPI: video: Video Device [PEGP] (multi-head: yes rom: yes post: no) [ 25.175860] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2b/LNXVIDEO:00/input/input15 [ 25.176345] ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 25.176431] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input16 [ 25.176522] snd_hda_intel :00:1b.0: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 25.409633] fbcon: i915drmfb (fb0) is primary device [ 25.779253] alsactl[605]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set [ 26.330085] Console: switching to colour frame buffer device 200x56 [ 26.352065] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device [ 26.465192] snd_hda_codec_realtek hdaudioC0D0: ALC665: SKU not ready 0x598301f0 [ 26.465686] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC665: line_outs=1 (0x15/0x0/0x0/0x0/0x0) type:speaker [ 26.465700] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 26.465708] snd_hda_codec_realtek hdaudioC0D0:hp_outs=2 (0x1b/0x19/0x0/0x0/0x0) [ 26.465716] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [ 26.465720] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x1e/0x0 [ 26.465725] snd_hda_codec_realtek hdaudioC0D0:inputs: [ 26.465731] snd_hda_codec_realtek hdaudioC0D0: Mic=0x1a [ 26.465737] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 [ 26.480065] input: HDA Intel PCH Mic as /devices/pci:00/:00:1b.0/sound/card0/input17 [ 26.480151] input: HDA Intel PCH Headphone as /devices/pci:00/:00:1b.0/sound/card0/input18 [ 26.480255] input: HDA Intel PCH Headphone as /devices/pci:00/:00:1b.0/sound/card0/input19 [ 26.480334] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1b.0/sound/card0/input20 [ 26.508129] EXT4-fs (sdb8): mounting ext3 file system using the ext4 subsystem [ 26.543987] EXT4-fs (sdb8): mounted filesystem 716b1346-b46f-4d2e-aa06-f10d9257854c r/w with ordered data mode. Quota mode: none. [ 27.697047] RPC: Registered named UNIX socket transport module. [ 27.697058] RPC: Registered udp transport module. [ 27.697062] RPC: Registered tcp transport module. [ 27.697064] RPC: Registered tcp-with-tls transport module. [ 27.697067] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 27.791757] audit: type=1400 audit(1695647717.978:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=720 comm="apparmor_parser" [ 27.793082] audit: type=1400 audit(1695647717.979:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=723 comm="apparmor_parser" [ 27.793098] audit: type=1400 audit(1695647717.979:4): apparmor="STATUS" operation="profile_load" profile="unconfined"
Bug#1051971: owncloud-client-cmd: Error transfering https://BLAH/owncloud/remote.php/webdav/status.php - server replied: Forbidden
On Thu, Sep 14, 2023 at 09:07:38PM -0600, Sergio Mendoza wrote: > Package: owncloud-client-cmd > Version: 3.2.0.10193+dfsg-1 > Severity: important > > Dear mainteiner, > > With the new unstable version ( 3.2.0.10193+dfsg-1 ) of owncloudcmd, > when I try to sync with the onwcloud server I get the following error: > > 23-09-14 20:45:05:955 [ warning sync.checkserverjob ]: error: status.php > replied 403 > 23-09-14 20:45:05:955 [ fatal default ]:Failed to resolve > https://BLAH/owncloud/remote.php/webdav Error: Error transferring > https://BLAH/owncloud/remote.php/webdav/status.php - server replied: > Forbidden. > Aborted Hi, For the records, that version has been working in my sid box until last Thursday, where, after server upgrade from 10.12.1.3 to 10.13.1.3, this error started to appear Server replied "403 Forbidden" to PROPFIND https://xxx.xxx.es/remote.php/webdav (Unsupported client version) Contacting my institution support they told me that they are having problems after that upgrade with client versions lower that 3.2 (I would not expect 3.2.0 to fail, but ...). ¿Has your server been recently upgraded? A colleage using Ubuntu installed last version (4.2.0) from owncloud.com and claims that it made it work again. While there are Debian packages there, I would prefer not to use them, but wait for 4.2.0 to be officially packaged for Debian. Regards, PS: Having owncloud-client 4.2.0 in Debian would be nice ;-) -- Agustin
Bug#1052633: certmonger FTBFS when systemd.pc changes systemdsystemunitdir
Source: certmonger
Version: 0.79.17-2
Severity: normal
Tags: ftbfs patch
User: helm...@debian.org
Usertags: dep17m2
We want to change the value of systemdsystemunitdir in systemd.pc to
point below /usr. certmonger's upstream build system consumes this
value, but the Debian packaging hard codes its current value. When it
changes, certmonger FTBFS. Consider applying the attached patch to avoid
that from happening.
Helmut
diff -Nru certmonger-0.79.17/debian/certmonger.install
certmonger-0.79.17/debian/certmonger.install
--- certmonger-0.79.17/debian/certmonger.install2023-03-18
09:37:33.0 +0100
+++ certmonger-0.79.17/debian/certmonger.install2023-09-25
13:48:41.0 +0200
@@ -1,6 +1,6 @@
etc/certmonger/certmonger.conf
etc/dbus-1/system.d/*
-lib/systemd/system/
+${env:systemdsystemunitdir}
usr/bin/*
usr/sbin/*
usr/share/dbus-1/*
diff -Nru certmonger-0.79.17/debian/changelog
certmonger-0.79.17/debian/changelog
--- certmonger-0.79.17/debian/changelog 2023-03-18 13:33:47.0 +0100
+++ certmonger-0.79.17/debian/changelog 2023-09-25 13:49:08.0 +0200
@@ -1,3 +1,10 @@
+certmonger (0.79.17-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Do not FTBFS when systemd.pc changes systemdsystemunitdir. (Closes: #-1)
+
+ -- Helmut Grohne Mon, 25 Sep 2023 13:49:08 +0200
+
certmonger (0.79.17-2) unstable; urgency=medium
* control: Respect nocheck, thanks Chris Lamb! (Closes: #1032058)
diff -Nru certmonger-0.79.17/debian/rules certmonger-0.79.17/debian/rules
--- certmonger-0.79.17/debian/rules 2023-03-18 09:37:14.0 +0100
+++ certmonger-0.79.17/debian/rules 2023-09-25 13:49:06.0 +0200
@@ -9,6 +9,8 @@
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
+export systemdsystemunitdir = $(shell pkg-config
--variable=systemdsystemunitdir systemd | sed s,^/,,)
+
override_dh_auto_configure:
dh_auto_configure -- \
--libexecdir=/usr/lib \
Bug#1052632: clevis FTBFS when systemd.pc changes systemdsystemunitdir
Source: clevis
Version: 19-3
Severity: normal
Tags: ftbfs patch
User: helm...@debian.org
Usertags: dep17m2
We want to change the value of systemdsystemunitdir in systemd.pc to
point below /usr. clevis' upstream build system consumes this value, but
the debian packaging hard codes its current value. When it changes,
clevis will fail to build from source. Consider applying the attached
patch to avoid that.
Helmut
diff -Nru clevis-19/debian/changelog clevis-19/debian/changelog
--- clevis-19/debian/changelog 2023-07-23 12:04:17.0 +0200
+++ clevis-19/debian/changelog 2023-09-25 13:52:04.0 +0200
@@ -1,3 +1,10 @@
+clevis (19-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Do not FTBFS when systemd.pc changes systemdsystemunitdir. (Closes: #-1)
+
+ -- Helmut Grohne Mon, 25 Sep 2023 13:52:04 +0200
+
clevis (19-3) unstable; urgency=medium
* Retire versioned dependencies met even in oldstable
diff -Nru clevis-19/debian/clevis-systemd.install
clevis-19/debian/clevis-systemd.install
--- clevis-19/debian/clevis-systemd.install 2023-01-28 11:43:54.0
+0100
+++ clevis-19/debian/clevis-systemd.install 2023-09-25 13:51:26.0
+0200
@@ -1,5 +1,5 @@
-lib/systemd/system/clevis-luks-askpass.path
-lib/systemd/system/clevis-luks-askpass.service
+${env:systemdsystemunitdir}/clevis-luks-askpass.path
+${env:systemdsystemunitdir}/clevis-luks-askpass.service
usr/libexec/clevis-luks-askpass
diff -Nru clevis-19/debian/control clevis-19/debian/control
--- clevis-19/debian/control2023-07-23 11:53:08.0 +0200
+++ clevis-19/debian/control2023-09-25 13:51:46.0 +0200
@@ -22,6 +22,7 @@
libssl-dev,
libudisks2-dev,
meson,
+pkgconf,
systemd,
tang,
tpm2-tools,
diff -Nru clevis-19/debian/rules clevis-19/debian/rules
--- clevis-19/debian/rules 2023-01-28 11:43:54.0 +0100
+++ clevis-19/debian/rules 2023-09-25 13:52:03.0 +0200
@@ -4,6 +4,8 @@
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk
+export systemdsystemunitdir = $(shell pkgconf --variable=systemdsystemunitdir
systemd | sed s,^/,,)
+
%:
dh $@ --with=bash-completion
Bug#1052631: bluez-alsa FTBFS when systemd.pc changes systemdsystemunitdir
Source: bluez-alsa
Version: 4.0.0-2
Tags: ftbfs patch
User: helm...@debian.org
Usertags: dep17m2
We want to change the value of systemdsystemunitdir in systemd.pc to
point to /usr. The upstream build system of bluez-alsa consumes this
value, but the debian packaging hard codes the current value. When
changing it, bluez-alsa fails to build from source. Consider applying
the attached patch to avoid that from happening.
Helmut
diff -Nru bluez-alsa-4.0.0/debian/bluez-alsa-utils.install
bluez-alsa-4.0.0/debian/bluez-alsa-utils.install
--- bluez-alsa-4.0.0/debian/bluez-alsa-utils.install2023-02-15
22:36:59.0 +0100
+++ bluez-alsa-4.0.0/debian/bluez-alsa-utils.install2023-09-25
12:41:37.0 +0200
@@ -1,6 +1,6 @@
-#! /usr/bin/dh-exec --with-scripts=install-rename
+#! /usr/bin/dh-exec --with-scripts=install-rename,subst-env
etc/*
usr/bin/*
debian/bluez-alsa.default => etc/default/bluez-alsa
-lib/systemd/system/bluealsa.service
-lib/systemd/system/bluealsa-aplay.service
+${systemdsystemunitdir}/bluealsa.service
+${systemdsystemunitdir}/bluealsa-aplay.service
diff -Nru bluez-alsa-4.0.0/debian/changelog bluez-alsa-4.0.0/debian/changelog
--- bluez-alsa-4.0.0/debian/changelog 2023-02-15 22:36:59.0 +0100
+++ bluez-alsa-4.0.0/debian/changelog 2023-09-25 12:42:20.0 +0200
@@ -1,3 +1,11 @@
+bluez-alsa (4.0.0-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Do not FTBFS when systemdsystemunitdir changes in systemd.pc. (Closes:
+#-1)
+
+ -- Helmut Grohne Mon, 25 Sep 2023 12:42:20 +0200
+
bluez-alsa (4.0.0-2) unstable; urgency=medium
* Enable libopenaptx.
diff -Nru bluez-alsa-4.0.0/debian/control bluez-alsa-4.0.0/debian/control
--- bluez-alsa-4.0.0/debian/control 2023-02-15 22:36:59.0 +0100
+++ bluez-alsa-4.0.0/debian/control 2023-09-25 12:41:51.0 +0200
@@ -14,6 +14,7 @@
libldacbt-abr-dev (>= 2.0.0),
libopenaptx-dev (>= 0.2.0),
python3-docutils,
+ pkg-config,
systemd
Rules-Requires-Root: no
Standards-Version: 4.6.1
diff -Nru bluez-alsa-4.0.0/debian/rules bluez-alsa-4.0.0/debian/rules
--- bluez-alsa-4.0.0/debian/rules 2023-02-15 22:36:59.0 +0100
+++ bluez-alsa-4.0.0/debian/rules 2023-09-25 12:42:18.0 +0200
@@ -3,6 +3,8 @@
# DEB_BUILD_PROFILES='nodoc'
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export systemdsystemunitdir = $(shell pkg-config
--variable=systemdsystemunitdir systemd | sed s,^/,,)
+
CONFIGURE_FLAGS := \
--enable-ldac \
--enable-libopenaptx \
Bug#1052630: 2ping: please do not hard code the location of systemd units
Source: 2ping Version: 4.5-1.1 Tags: patch User: helm...@debian.org Usertags: dep17m2 We want to finish this /usr-merge transition and 2ping is part of it, because it installs a systemd unit to /lib. This needs to move to /usr/lib eventually. Currently debian/rules hard codes this location. I propose changing that to let dh_installsystemd handle the installation (and thus choose the location) such that we can perform the conversion using a binNMU. To achieve that, we can turn debian/2ping.service into a symlink, but debdiff cannot represent such a patch, so I'm giving the patch as shell code: ln -s ../2ping.service debian/2ping.service sed -i -e /systemd.system/d debian/rules For now, this will not produce any difference in the built package. But it allows us to later change dh_installsystemd and then binNMU 2ping. Helmut
Bug#1052627: gitaly FTBFS in unstable
Source: gitaly Version: 16.0.7+ds1-3 Tags: ftbfs Severity: serious Building gitaly fails in unstable on amd64. It is not clear to me where exactly the failure is, henc the log is fairly long. | dpkg-buildpackage: info: source package gitaly | dpkg-buildpackage: info: source version 16.0.7+ds1-3 | dpkg-buildpackage: info: source distribution unstable | dpkg-buildpackage: info: source changed by Pirate Praveen | dpkg-source --before-build . | dpkg-buildpackage: info: host architecture amd64 | fakeroot debian/rules clean | dh clean --buildsystem=golang --with=golang --package=golang-gitlab-gitlab-org-gitaly-dev \ | --builddirectory=_build |debian/rules override_dh_auto_clean | make[1]: Entering directory '/<>' | rm -rf ruby/proto/gitaly/*_pb.rb | dh_auto_clean -O--buildsystem=golang -O--package=golang-gitlab-gitlab-org-gitaly-dev \ | -O--builddirectory=_build | dh_auto_clean -O--buildsystem=ruby -O--package=ruby-gitaly | dh_auto_clean: warning: No packages to build. Possible architecture mismatch: amd64, want: all any | make[1]: Leaving directory '/<>' |dh_autoreconf_clean -O--buildsystem=golang -O--package=golang-gitlab-gitlab-org-gitaly-dev -O--builddirectory=_build |dh_clean -O--buildsystem=golang -O--package=golang-gitlab-gitlab-org-gitaly-dev -O--builddirectory=_build | dh clean --buildsystem=ruby --with=ruby --package=ruby-gitaly |debian/rules override_dh_auto_clean | make[1]: Entering directory '/<>' | rm -rf ruby/proto/gitaly/*_pb.rb | dh_auto_clean -O--buildsystem=golang -O--package=golang-gitlab-gitlab-org-gitaly-dev \ | -O--builddirectory=_build | dh_auto_clean: warning: No packages to build. Possible architecture mismatch: amd64, want: all any | dh_auto_clean -O--buildsystem=ruby -O--package=ruby-gitaly | dh_ruby --clean | W: XS-Ruby-Versions is deprecated, and will be ignored | make[1]: Leaving directory '/<>' |dh_autoreconf_clean -O--buildsystem=ruby -O--package=ruby-gitaly |dh_clean -O--buildsystem=ruby -O--package=ruby-gitaly | dh clean --package=gitlab-common |debian/rules override_dh_auto_clean | make[1]: Entering directory '/<>' | rm -rf ruby/proto/gitaly/*_pb.rb | dh_auto_clean -O--buildsystem=golang -O--package=golang-gitlab-gitlab-org-gitaly-dev \ | -O--builddirectory=_build | dh_auto_clean: warning: No packages to build. Possible architecture mismatch: amd64, want: all any | dh_auto_clean -O--buildsystem=ruby -O--package=ruby-gitaly | dh_auto_clean: warning: No packages to build. Possible architecture mismatch: amd64, want: all any | make[1]: Leaving directory '/<>' |dh_autoreconf_clean -O--package=gitlab-common |dh_clean -O--package=gitlab-common | dh clean --package=gitaly |debian/rules override_dh_auto_clean | make[1]: Entering directory '/<>' | rm -rf ruby/proto/gitaly/*_pb.rb | dh_auto_clean -O--buildsystem=golang -O--package=golang-gitlab-gitlab-org-gitaly-dev \ | -O--builddirectory=_build | dh_auto_clean: warning: No packages to build. Possible architecture mismatch: amd64, want: all any | dh_auto_clean -O--buildsystem=ruby -O--package=ruby-gitaly | dh_auto_clean: warning: No packages to build. Possible architecture mismatch: amd64, want: all any | make[1]: Leaving directory '/<>' |dh_autoreconf_clean -O--package=gitaly |dh_clean -O--package=gitaly | debian/rules build | dh build --buildsystem=golang --with=golang --package=golang-gitlab-gitlab-org-gitaly-dev \ | --builddirectory=_build |dh_update_autotools_config -O--buildsystem=golang -O--package=golang-gitlab-gitlab-org-gitaly-dev -O--builddirectory=_build |dh_autoreconf -O--buildsystem=golang -O--package=golang-gitlab-gitlab-org-gitaly-dev -O--builddirectory=_build |debian/rules override_dh_auto_configure | make[1]: Entering directory '/<>' | dh_auto_configure -O--buildsystem=golang -O--package=golang-gitlab-gitlab-org-gitaly-dev \ | -O--builddirectory=_build | make[1]: Leaving directory '/<>' |debian/rules override_dh_auto_build | make[1]: Entering directory '/<>' | dh_auto_build -O--buildsystem=golang -O--package=golang-gitlab-gitlab-org-gitaly-dev \ | -O--builddirectory=_build -- \ |-ldflags "-X gitlab.com/gitlab-org/gitaly/v16/internal/version.version=16.0.7+ds1 -X gitlab.com/gitlab-org/gitaly/v16/internal/version.moduleVersion=v16" -tags "static,system_libgit2" \ |gitlab.com/gitlab-org/gitaly/v16/cmd/gitaly-ssh gitlab.com/gitlab-org/gitaly/v16/cmd/gitaly-lfs-smudge gitlab.com/gitlab-org/gitaly/v16/cmd/gitaly-hooks gitlab.com/gitlab-org/gitaly/v16/cmd/gitaly-git2go | cd _build && go generate -v -ldflags "-X gitlab.com/gitlab-org/gitaly/v16/internal/version.version=16.0.7+ds1 -X gitlab.com/gitlab-org/gitaly/v16/internal/version.moduleVersion=v16" -tags static,system_libgit2 gitlab.com/gitlab-org/gitaly/v16/cmd/gitaly-ssh gitlab.com/gitlab-org/gitaly/v16/cmd/gitaly-lfs-smudge gitlab.com/gitlab-org/gitaly/v16/cmd/gitaly-hooks gitlab.com/gitlab-org/gitaly/v16/cmd/gitaly-git2go
Bug#1052628: acpid: please let dh_installsystemd install acpid.path
Source: acpid Version: 1:2.0.33-2 Tags: patch User: helm...@debian.org Usertags: dep17m2 The acpid source package contains debian/acpid.path. dh_installsystemd will normally install this unit. However, it also is listed in debian/acpid.install and explicitly installed to /lib. We need to move it to /usr/lib eventually, so this needs to change. I propose dropping it from debian/acpid.install such that dh_installsystemd can do its thing. We can then later change dh_installsystemd and binNMU acpid to complete the transition without involving you then. Please consider applying the attached patch. Helmut diff -Nru acpid-2.0.33/debian/acpid.install acpid-2.0.33/debian/acpid.install --- acpid-2.0.33/debian/acpid.install 2022-07-19 13:13:31.0 +0200 +++ acpid-2.0.33/debian/acpid.install 2023-09-25 14:41:09.0 +0200 @@ -6,4 +6,3 @@ debian/examples/ac.sh usr/share/doc/acpid/examples/ acpi_listenusr/bin acpid usr/sbin -debian/acpid.path lib/systemd/system/ diff -Nru acpid-2.0.33/debian/changelog acpid-2.0.33/debian/changelog --- acpid-2.0.33/debian/changelog 2022-07-19 13:13:31.0 +0200 +++ acpid-2.0.33/debian/changelog 2023-09-25 14:41:13.0 +0200 @@ -1,3 +1,10 @@ +acpid (1:2.0.33-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Let dh_installsystemd install acpid.path. (Closes: #-1) + + -- Helmut Grohne Mon, 25 Sep 2023 14:41:13 +0200 + acpid (1:2.0.33-2) unstable; urgency=medium * Add directive to avoid monitoring of acpi.path on containers. Thanks
Bug#1052626: 389-ds-base FTBFS: clap package not found
Source: 389-ds-base Version: 2.3.4+dfsg1-1 Severity: serious Tags: ftbfs 389-ds-base fails to build from source in unstable. A build ends with: | dh_auto_build | make -j8 | make[2]: Entering directory '/<>' | ./ldap/servers/slapd/mkDBErrStrs.py -i ./ldap/servers/slapd/back-ldbm -o . | RUST_BACKTRACE=1 RUSTC_BOOTSTRAP=1 \ | CARGO_TARGET_DIR=/<>/rs/rslapd \ | SLAPD_DYLIB_DIR=/<>/ \ | SLAPD_HEADER_DIR=/<>/ \ | cargo rustc --offline --manifest-path=./src/librslapd/Cargo.toml \ | --release --verbose -- -C debuginfo=2 | RUST_BACKTRACE=1 RUSTC_BOOTSTRAP=1 \ | CARGO_TARGET_DIR=/<>/rs/rnsslapd \ | SLAPD_DYLIB_DIR=/<>/ \ | SLAPD_HEADER_DIR=/<>/ \ | cargo rustc --offline --manifest-path=./src/librnsslapd/Cargo.toml \ | --release --verbose -- -C debuginfo=2 | Blocking waiting for file lock on package cache | error: no matching package found | searched package name: `clap` | perhaps you meant: cc, cexpr, glob, ... | location searched: registry `crates-io` | required by package `cbindgen v0.24.5` | ... which satisfies dependency `cbindgen = "0.*"` of package `librslapd v0.1.0 (/<>/src/librslapd)` | As a reminder, you're using offline mode (--offline) which can sometimes cause surprising resolution failures, if this error is too confusing you may wish to retry without the offline flag. | make[2]: *** [Makefile:13002: /<>/rs/rslapd/release/librslapd.a] Error 101 | make[2]: *** Waiting for unfinished jobs | error: no matching package found | searched package name: `clap` | perhaps you meant: cc, cexpr, glob, ... | location searched: registry `crates-io` | required by package `cbindgen v0.24.5` | ... which satisfies dependency `cbindgen = "0.*"` of package `librslapd v0.1.0 (/<>/src/librslapd)` | As a reminder, you're using offline mode (--offline) which can sometimes cause surprising resolution failures, if this error is too confusing you may wish to retry without the offline flag. | make[2]: *** [Makefile:13013: /<>/rs/rnsslapd/release/librnsslapd.a] Error 101 | make[2]: Leaving directory '/<>' | dh_auto_build: error: make -j8 returned exit code 2 | make[1]: *** [debian/rules:52: override_dh_auto_build] Error 25 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:18: build] Error 2 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Helmut
Bug#1052625: cluster-glue FTBFS when systemd.pc changes systemdsystemunitdir
Source: cluster-glue
Version: 1.0.12-21
Severity: normal
Tags: ftbfs patch
User: helm...@debian.org
Usertags: dep17m2
We want to change the value of systemdsystemunitdir in systemd.pc to
point below /usr. cluster-glue's upstream build system consumes this
value but its packaging hard codes the current value. When we change it,
cluster-glue will FTBFS. Consider applying the attached patch to avoid
that.
Helmut
diff -Nru cluster-glue-1.0.12/debian/changelog
cluster-glue-1.0.12/debian/changelog
--- cluster-glue-1.0.12/debian/changelog2022-04-10 16:17:14.0
+0200
+++ cluster-glue-1.0.12/debian/changelog2023-09-25 14:10:50.0
+0200
@@ -1,3 +1,10 @@
+cluster-glue (1.0.12-21.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS when systemd.pc changes systemdsystemunitdir. (Closes: #-1)
+
+ -- Helmut Grohne Mon, 25 Sep 2023 14:10:50 +0200
+
cluster-glue (1.0.12-21) unstable; urgency=medium
[ Lucas Kanashiro ]
diff -Nru cluster-glue-1.0.12/debian/cluster-glue.install
cluster-glue-1.0.12/debian/cluster-glue.install
--- cluster-glue-1.0.12/debian/cluster-glue.install 2020-04-05
16:32:52.0 +0200
+++ cluster-glue-1.0.12/debian/cluster-glue.install 2023-09-25
14:10:33.0 +0200
@@ -85,7 +85,7 @@
usr/share/cluster-glue/openais_conf_support.sh
usr/share/cluster-glue/ha_log.sh
usr/lib/stonith/plugins/xen0-ha-dom0-stonith-helper
-lib/systemd/system/logd.service
+${env:systemdsystemunitdir}/logd.service
usr/share/man/man8/meatclient.8
usr/share/man/man8/hb_report.8
usr/share/man/man8/ha_logd.8
diff -Nru cluster-glue-1.0.12/debian/control cluster-glue-1.0.12/debian/control
--- cluster-glue-1.0.12/debian/control 2022-04-10 15:59:44.0 +0200
+++ cluster-glue-1.0.12/debian/control 2023-09-25 14:09:44.0 +0200
@@ -32,6 +32,7 @@
libxml2-utils,
openssh-client ,
perl,
+ pkgconf,
psmisc,
python3,
systemd [linux-any],
diff -Nru cluster-glue-1.0.12/debian/rules cluster-glue-1.0.12/debian/rules
--- cluster-glue-1.0.12/debian/rules2020-06-27 12:54:34.0 +0200
+++ cluster-glue-1.0.12/debian/rules2023-09-25 14:10:50.0 +0200
@@ -9,6 +9,8 @@
# lib tool gets it's chance to do anything.
# export DEB_LDFLAGS_MAINT_APPEND=-Wl,-z,defs
+export systemdsystemunitdir = $(shell pkgconf --variable=systemdsystemunitdir
systemd | sed s,^/,,)
+
# main packaging script based on dh7 syntax
%:
dh $@ --with python3
Bug#962078: apt-listchanges: feature request: combine identical changelog entries from multiple packages
I have a fix pending which merges changelog entries which are _entirely_ identical, which I implemented as part of addressing bug #383803, but I gather that fix won't work here. If I'm understanding correctly, the issue discussed here is the content of the changelog entry being identical but the package name in the changelog entry (just to be clear: we're talking about the package name written in the entry in the changelog file, not the package that the entry is found in, right?) or its date being different. Can you perhaps provide me of an example of two specific deb files somewhere I can download online which demonstrate this phenomenon so I can reproduce the issue? I suspect with a reproducible test case in hand it will be relatively straightforward to add a fix for this issue to the fix I already have pending for the other one.
Bug#1051088: [PATCH] Remove extraneous words left behind by commit 522837f.
On 9/4/23 4:50 AM, James Youngman wrote: --- utils/mount/nfs.man | 1 - 1 file changed, 1 deletion(-) Committed... steved. diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man index 7a410422..c9850f29 100644 --- a/utils/mount/nfs.man +++ b/utils/mount/nfs.man @@ -986,7 +986,6 @@ file. See .BR nfsmount.conf(5) for details. .SH EXAMPLES -mount option. To mount using NFS version 3, use the .B nfs
Bug#1052624: debbugs: forwarded messages break DMARC, DKIM, SPF
Package: debbugs Severity: normal Debbugs forwards messages from bug maintainers with their From lines intact, which is quite problematic for senders whose domains use DMARC, DKIM, and/or SPF. SPF: Since the forwarded messages aren't coming from one of the sender's domain's mailservers, they violate the domain's SPF policy, if any. DKIM: debbugs modifies the forwarded messages in ways that break their DKIM signatures. DMARC: because SPF and DKIM are both broken in the forward, these messages can't possibly be compliant with domain DMARC policies. As a result, transmission and distribution of these messages is quite unreliable. At the very least these signals make the messages more likely to be interpreted as spam. At most they are completely bounced by some recipients' mail servers. The most obvious solution to this is straightforward: the From line in these messages should be modified to contain the email address of the bug, not the email address of the original sender. The original sender's address can be put in Reply-To and/or indicated in the header in a number of other ways. For example, sometimes something like this is done: From: Jonathan Kamens becomes: From: "Jonathan Kamens via" <###@bugs.debian.org> Reply-To: ###@bugs.debian.org, j...@kamens.us There are different implications of the various ways this can be done, so some thinking does need to go into the best way to do it, but it's not an unsolvable problem. If there is resistance to making this change across the board, then another possibility is to only modify the headers on messages which have DMARC policies and/or restrictive SPF policies. MailMan has a mode which behaves this way. In any case the original DKIM signature from the sender should be removed since the messages is being modified. I'm not sure whether debbugs already does this. I would be happy to "put my money where my mouth is" and work on fixing this and submitting a patch. However, I am reluctant to just "jump in" and send in a patch without some engagement from the debbugs maintainers first, because (a) as noted above, some consideration needs to be given to the ramifications of various solutions before one is chosen, and I don't think I'm in any position to do that unilaterally, and (b) because this is a relatively old problem with a relatively straightforward solution, I suspect that there may be non-technical reasons why a fix hasn't been implemented. I'm reluctant to do work that is not going to be accepted for philosophical or political reasons. Jonathan Kamens -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1052623: openjpa: FTBFS with OpenJDK 21 due to type inference changes
Source: openjpa Version: 2.4.2-8 Severity: important Tags: ftbfs sid trixie User: debian-j...@lists.debian.org Usertags: default-java21 openjpa fails to build with OpenJDK 21, probably due to type inference changes when using source/target level 8: [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /<>/openjpa-persistence/src/main/java/org/apache/openjpa/persistence/criteria/CriteriaQueryImpl.java:[234,72] incompatible types: bad type in conditional expression java.util.Set cannot be converted to java.util.Set> [INFO] 1 error [INFO] -
Bug#1052622: jboss-logging-tools: FTBFS with OpenJDK 21 due to javax.lang.model.element.ExecutableElement changes
Source: jboss-logging-tools Version: 2.2.1-3 Severity: important Tags: ftbfs sid trixie User: debian-j...@lists.debian.org Usertags: default-java21 jboss-logging-tools fails to build with OpenJDK 21 because new abstract methods were added to javax.lang.model.element.ExecutableElement: [INFO] --- maven-compiler-plugin:3.10.1:compile (default-compile) @ jboss-logging-processor --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 61 source files to /<>/processor/target/classes [INFO] /<>/processor/src/main/java/org/jboss/logging/processor/apt/TranslationFileGenerator.java: /<>/processor/src/main/java/org/jboss/logging/processor/apt/TranslationFileGenerato r.java uses or overrides a deprecated API that is marked for removal. [INFO] /<>/processor/src/main/java/org/jboss/logging/processor/apt/TranslationFileGenerator.java: Recompile with -Xlint:removal for details. [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /<>/processor/src/main/java/org/jboss/logging/processor/model/MessageMethod.java:[35,8] types org.jboss.logging.processor.model.DelegatingElement and javax.lang.model.element.ExecutableElement are incompatible; interface org.jboss.logging.processor.model.MessageMethod inherits abstract and default for getEnclosingElement() from types org.jboss.logging.processor.model.DelegatingElement and javax.lang.model.element.ExecutableElement [ERROR] /<>/processor/src/main/java/org/jboss/logging/processor/model/DelegatingExecutableElement.java:[39,8] types org.jboss.logging.processor.model.DelegatingElement and javax.lang.model.element.ExecutableElement are incompatible; interface org.jboss.logging.processor.model.DelegatingExecutableElement inherits abstract and default for getEnclosingElement() from types org.jboss.logging.processor.model.DelegatingElement and javax.lang.model.element.ExecutableElement [ERROR] /<>/processor/src/main/java/org/jboss/logging/processor/apt/MessageMethodBuilder.java:[288,20] org.jboss.logging.processor.apt.MessageMethodBuilder.AptMessageMethod is not abstract and does not override abstract method getEnclosingElement() in javax.lang.model.element.ExecutableElement [INFO] 3 errors
Bug#704435: varnish: Pushing vcls failed:#012CLI communication error (hdr)
On Apr 01, "Rune K. Svendsen" wrote: > Apr 1 06:40:17 raspberrypi varnishd[28809]: Pushing vcls failed:#012CLI > communication error (hdr) This bug is 10 years old: can you still reproduce this? -- ciao, Marco signature.asc Description: PGP signature
Bug#1052621: ITP: mts-esp -- microtuning support to audio and MIDI plugins
Package: wnpp Owner: Andrius Merkys Severity: wishlist Control: block 1025206 by -1 * Package name: mts-esp Version : 0.0~git20230110.9df9a9c Upstream Author : ODDSound Ltd. * URL : https://github.com/ODDSound/MTS-ESP * License : 0BSD Programming Lang: C Description : microtuning support to audio and MIDI plugins The MTS-ESP library is a simple but versatile C/C++ library for adding microtuning support to audio and MIDI plugins. It allows for a single master plugin to simultaneously control the tuning of any number of connected client plugins across a DAW session. Connection between a master and clients is automatic and invisible. MTS-ESP is needed by bespokesynth (ITP #1025206) Remark: This package is to be maintained with Debian Multimedia Maintainers at https://salsa.debian.org/multimedia-team/mts-esp
Bug#1052431: RFP: rust-tonic -- rust implementation of gRPC
On 9/22/23 1:42 PM, Jonas Smedegaard wrote: Quoting Reinhard Tartler (2023-09-22 13:09:08) How about I take care of hyper-timeout and prettyplease in debcargo-conf (i.e., the rust team mass-packaging repo), and try to assist you with packaging the workspace builds of tonic (which includes tonic-build, cf. https://github.com/hyperium/tonic/tree/master/tonic-build) and axum? Deal! :-) hyper-timeout: https://ftp-master.debian.org/new/rust-hyper-timeout_0.4.1-1.html prettyplease: https://tracker.debian.org/pkg/rust-prettyplease both versions currently in the archive should satisfy requirements for tonic. Let me know what other dependencies are missing, happy to add them to debcargo-conf.git -rt
Bug#1052620: javamorph: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7
Source: javamorph Version: 0.0.20100201-3 Severity: important Tags: ftbfs User: debian-j...@lists.debian.org Usertags: default-java21 Dear Maintainers, The package javamorph ftbfs with default Java 21. The relevant part of the build log: --- make[1]: Entering directory '/<>' javac -source 7 -target 7 -d . javamorph/*.java warning: [options] bootstrap class path not set in conjunction with -source 7 error: Source option 7 is no longer supported. Use 8 or later. error: Target option 7 is no longer supported. Use 8 or later. make[1]: *** [debian/rules:7: override_dh_auto_build] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:4: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 --- -- System Information: Debian Release: trixie/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.108-1-pve (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1052619: ITP: pydantic-core -- Rust implementation of pydantic core functionality
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: pydantic-core Version : 2.9.0 Upstream Author : Samuel Colvin * URL : https://github.com/pydantic/pydantic-core * License : Expat Programming Lang: Python, Rust Description : Rust implementation of pydantic core functionality pydantic uses type hinting (PEP 484) and variable annotation (PEP 526) to validate that untrusted data takes the desired form. There is also support for an extension to dataclasses where the input data is validated. The core library is implemented in Rust and up to seventeen times faster than the original pure Python implementation. This is a new dependency for pydantic 2. The package will probably be team-maintained under the umbrella of the Debian Python Team . -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmURdfQACgkQ+C8H+466 LVkUawwAjCO9wWXpdir5lVlaQa0b5niJ/JGEWC2qg6bZxBELJHyniYlyUtAl+qeb AsySa6hSQ+4nCgQEinCo9JHwwhERlY9MlceVeez4EuP1Xt4udbvx8l9RUUAlUP7b BYxgw8GAWMQsrn+ZCPdv0jjvzjI9u1LOzJqwV8w6E0XpuQTi7ZsqNegKsEg0jfVk NKUGaCyWKvEmhh1rfn7iPO0QGiufbsjp568JCA1LGX/OKL8oXD3LEu+ji9P9gCRq ym6iqrmrRtNH3vIBi29chaQUkEZRQvkzAocWXF5F8Ba6j2B9dMiuNsPT7ylBFGF/ tEbg+9ELAHlV7Ab9yAH2VPM1gpmblOs9rpp0+F+fCfW+raTH3OByXYGgMbyryOeD P+YtP2awBSpQSrS6YGjK83MTPRxrv0UflK6+XL3eDHN7GsMMQuAv4TkA9HX7BDUf 7+JP2urP0gjL4sdkRtZncHQWhEIc2HWHGUW3OAlJEClMyu/HVslomsEcS8zxKIUk UCc5c91X =J7bx -END PGP SIGNATURE-
Bug#1052365: systemd: DHCP client fails if multiple DHCP servers on network
Michael, On 9/23/23 11:39, Michael Biebl wrote: Hi Alexandre Am 21.09.23 um 01:59 schrieb Alexandre Ferreira: DHCP client on systemd-networkd sends requests as broadcast so if there is more than one DHCP server on the network all but one will answer NAK: wrong server-ID. DHCP client stops at the first NAK and ignores the ACK that will be sent. THe attached patch included a test refusing any NAK that does not come from the same IP that the request was sent. Patches like this one, should be submitted upstream and reviewed there. Can you please create a PR at https://github.com/systemd/systemd/pulls Thanks, Michael Thank you, I added a PR and it was merged yesterday. sd-dhcp-client: reject NAKs from servers that we did not send an offer to (#29290) (https://github.com/systemd/systemd/pull/29290) This change will only be valid for 255. How can we backport it to 252 up to 254?. Thanks, -- Alexandre Peixoto Ferreira --- Any girl can be glamorous; all you have to do is stand still and look stupid. -- Hedy Lamarr
Bug#1052618: tightvnc-java: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7
Source: tightvnc-java Version: 1.3.10-4 Severity: important Tags: ftbfs User: debian-j...@lists.debian.org Usertags: default-java21 Dear Maintainers, The package tightvnc-java ftbfs with default Java 21. The relevant part of the build log: --- make -j4 "INSTALL=install --strip-program=true" make[1]: Entering directory '/<>' javac -source 1.7 -target 1.7 -O VncViewer.java RfbProto.java AuthPanel.java VncCanvas.java VncCanvas2.java OptionsFrame.java ClipboardFrame.java ButtonPanel.java DesCipher.java CapabilityInfo.java CapsContainer.java RecordingFrame.java SessionRecorder.java SocketFactory.java HTTPConnectSocketFactory.java HTTPConnectSocket.java ReloginPanel.java InStream.java MemInStream.java ZlibInStream.java javac -source 1.7 -target 1.7 -O VncViewer.java RfbProto.java AuthPanel.java VncCanvas.java VncCanvas2.java OptionsFrame.java ClipboardFrame.java ButtonPanel.java DesCipher.java CapabilityInfo.java CapsContainer.java RecordingFrame.java SessionRecorder.java SocketFactory.java HTTPConnectSocketFactory.java HTTPConnectSocket.java ReloginPanel.java InStream.java MemInStream.java ZlibInStream.java javac -source 1.7 -target 1.7 -O VncViewer.java RfbProto.java AuthPanel.java VncCanvas.java VncCanvas2.java OptionsFrame.java ClipboardFrame.java ButtonPanel.java DesCipher.java CapabilityInfo.java CapsContainer.java RecordingFrame.java SessionRecorder.java SocketFactory.java HTTPConnectSocketFactory.java HTTPConnectSocket.java ReloginPanel.java InStream.java MemInStream.java ZlibInStream.java javac -source 1.7 -target 1.7 -O VncViewer.java RfbProto.java AuthPanel.java VncCanvas.java VncCanvas2.java OptionsFrame.java ClipboardFrame.java ButtonPanel.java DesCipher.java CapabilityInfo.java CapsContainer.java RecordingFrame.java SessionRecorder.java SocketFactory.java HTTPConnectSocketFactory.java HTTPConnectSocket.java ReloginPanel.java InStream.java MemInStream.java ZlibInStream.java warning: [options] bootstrap class path not set in conjunction with -source 7 error: Source option 7 is no longer supported. Use 8 or later. error: Target option 7 is no longer supported. Use 8 or later. warning: [options] bootstrap class path not set in conjunction with -source 7 error: Source option 7 is no longer supported. Use 8 or later. error: Target option 7 is no longer supported. Use 8 or later. make[1]: *** [Makefile:35: AuthPanel.class] Error 2 make[1]: *** Waiting for unfinished jobs warning: [options] bootstrap class path not set in conjunction with -source 7 error: Source option 7 is no longer supported. Use 8 or later. make[1]: *** [Makefile:35: VncCanvas.class] Error 2 error: Target option 7 is no longer supported. Use 8 or later. warning: [options] bootstrap class path not set in conjunction with -source 7 error: Source option 7 is no longer supported. Use 8 or later. error: Target option 7 is no longer supported. Use 8 or later. make[1]: *** [Makefile:35: RfbProto.class] Error 2 make[1]: *** [Makefile:35: VncViewer.class] Error 2 make[1]: Leaving directory '/<>' dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true" returned exit code 2 make: *** [debian/rules:10: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 --- -- System Information: Debian Release: trixie/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.108-1-pve (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1052562: ITP: eza -- Modern replacement for ls
* Sylvestre Ledru [230924 15:57]: > Package: wnpp > Severity: wishlist > Owner: Sylvestre Ledru > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: eza > * URL : https://github.com/eza-community/eza > * License : MIT > > it is a replacement of exa (dead upstream). > it will break/replace it. Why? If they are not co-installable, this is the correct dependency. Also, if you are the maintainer of the old package, and you are planning to remove the old package after the next release, and are doing this to automatically upgrade users from the old package to the new package, then this, as well as the rest of the advice at https://wiki.debian.org/RenamingPackages, is appropriate. However, just because eza is the _logical_ replacement for a dead-upstream package is not a reason for it to have a Debian package dependency forcing the removal of the old package when installing the new. If they are co-installable, and the removal of the old package is not imminent, I would simply coordinate with the maintainer of the old package (if he/she is amenable), and when yours is uploaded, add a sentence to the bottom of the old package description stating that the package is obsolete and naming your package as the preferred, actively maintained replacement. Also add a NEWS entry with that info in the old package. ...Marvin
Bug#1052617: xml-commons-external: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7
Source: xml-commons-external Version: 1.4.01-5 Severity: important Tags: ftbfs User: debian-j...@lists.debian.org Usertags: default-java21 Dear Maintainers, The package xml-commons-external ftbfs with default Java 21. The relevant part of the build log: --- make[1]: Entering directory '/<>' # Build all classes mkdir classes javac -source 7 -target 7 -d classes `find org/ javax/ -name '*.java'` warning: [options] bootstrap class path not set in conjunction with -source 7 error: Source option 7 is no longer supported. Use 8 or later. error: Target option 7 is no longer supported. Use 8 or later. make[1]: *** [debian/rules:11: override_dh_auto_build] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:6: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 --- -- System Information: Debian Release: trixie/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.108-1-pve (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1052616: RFS: python-control/0.9.4-1 [ITP] -- Python control systems library
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-control": * Package name : python-control Version : 0.9.4-1 Upstream contact : > * URL : http://python-control.org/ * License : BSD-3-Clause * Vcs : https://salsa.debian.org/krvprashanth/python-control Section : python The source builds the following binary packages: python3-control - Python control systems library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-control/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-control/python-control_0.9.4-1.dsc Changes for the initial release: python-control (0.9.4-1) unstable; urgency=low . * Initial release, Closes: #1052421 Regards, -- Kurva Prashanth
Bug#1052562: ITP: eza -- Modern replacement for ls
Le 25/09/2023 à 13:40, Marvin Renich a écrit : * Sylvestre Ledru [230924 15:57]: Package: wnpp Severity: wishlist Owner: Sylvestre Ledru X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: eza * URL : https://github.com/eza-community/eza * License : MIT it is a replacement of exa (dead upstream). it will break/replace it. Why? If they are not co-installable, this is the correct dependency. Also, if you are the maintainer of the old package, and you are planning to remove the old package after the next release, and are doing this to automatically upgrade users from the old package to the new package, then this, as well as the rest of the advice at https://wiki.debian.org/RenamingPackages, is appropriate. yeah, i know :) I am the maintainer of the two Cheers Sylvestre
Bug#1052462: parted: libparted2 package dependencies (dmidecode) differ between arm64 and amd64
Thank you for the background. This can be marked as invalid. On Fri, 22 Sept 2023 at 16:12, Colin Watson wrote: > On Fri, Sep 22, 2023 at 03:41:53PM +0100, Phil Roche wrote: > > While working on new arm64 Ubuntu 23.10 Mantic minimal cloud images > > (http://cloud-images.ubuntu.com/minimal/daily/mantic/) we discovered > that > > `dmidecode` was not being installed in the arm64 images. > > > > In debugging, I found that the package dependencies of the libparted2 > > package > > differ between arm64 and amd64. arm64 `libparted2` does not depend on > > `dmidecode` but on amd64 it does. > > This is intentional, because libparted only uses dmidecode for > identifying old Intel Macs with special GPT quirks, and that's only > relevant on x86. I don't personally see why this needs to be extended > to arm64, although of course if somebody comes forward and explicitly > confirms that it's relevant to partitioning on Apple Silicon or whatever > then we could do that - but I wouldn't do it just for architectural > symmetry. > > If you explicitly need dmidecode to be on your images, then I think you > should have an explicit dependency or similar to ensure that, rather > than relying on a dependency via libparted (which is an implementation > detail). Is that a problem? > > -- > Colin Watson (he/him) [cjwat...@debian.org] > -- Phil Roche Staff Software Engineer Canonical Public Cloud
Bug#1052615: gnome-shell: Keyboard layout indicator does not change when switch layouts
Package: gnome-shell Version: 44.5-1 Severity: normal X-Debbugs-Cc: george.shuk...@gmail.com Steps to reproduce: 1. Configure layout switching using Gnome tweaks as 'Caps to first layout', 'Shift-caps to second layout' 2. Switch layout Expected behavior: layout indicator displays current layout (language of layout) Actual behavior: 1. Layout switches as expected 2. Layout indicator does not change Note: Selecting language via indicator changes both layout and icon, whist keyboard shortcut does not. -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gir1.2-accountsservice-1.0 23.13.9-4 ii gir1.2-adw-1 1.4.0-1 ii gir1.2-atk-1.0 2.50.0-1 ii gir1.2-atspi-2.0 2.50.0-1 ii gir1.2-freedesktop 1.78.1-1 ii gir1.2-gcr-3 3.41.1-3 ii gir1.2-gdesktopenums-3.0 45.0-1 ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1 ii gir1.2-gdm-1.0 45.0.1-1 ii gir1.2-geoclue-2.0 2.7.1-1 ii gir1.2-glib-2.0 1.78.1-1 ii gir1.2-gnomebg-4.0 44.0-2 ii gir1.2-gnomebluetooth-3.042.6-1 ii gir1.2-gnomedesktop-4.0 44.0-2 ii gir1.2-graphene-1.0 1.10.8-1 ii gir1.2-gstreamer-1.0 1.22.5-1 ii gir1.2-gtk-4.0 4.12.2+ds-1 ii gir1.2-gweather-4.0 4.4.0-1 ii gir1.2-ibus-1.0 1.5.29~rc1-1 ii gir1.2-mutter-12 44.5-1 ii gir1.2-nm-1.01.44.0-1 ii gir1.2-nma4-1.0 1.10.6-1 ii gir1.2-pango-1.0 1.51.0+ds-2 ii gir1.2-polkit-1.0123-1 ii gir1.2-rsvg-2.0 2.54.7+dfsg-2 ii gir1.2-soup-3.0 3.4.3-1 ii gir1.2-upowerglib-1.01.90.2-4 ii gir1.2-webkit2-4.1 2.42.0-1 ii gnome-backgrounds45.0-1 ii gnome-settings-daemon45.0-1 ii gnome-shell-common 44.5-1 ii gsettings-desktop-schemas45.0-1 ii gstreamer1.0-pipewire0.3.80-2 ii libatk-bridge2.0-0 2.50.0-1 ii libatk1.0-0 2.50.0-1 ii libc62.37-10 ii libcairo21.18.0-1 ii libecal-2.0-23.50.0-1 ii libedataserver-1.2-273.50.0-1 ii libgcr-base-3-1 3.41.1-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgirepository-1.0-11.78.1-1 ii libgjs0g 1.76.2-4 ii libgles2 1.6.0-1 ii libglib2.0-0 2.78.0-2 ii libglib2.0-bin 2.78.0-2 ii libgnome-autoar-0-0 0.4.4-2 ii libgnome-desktop-4-2 44.0-2 ii libgraphene-1.0-01.10.8-1 ii libgtk-3-0 3.24.38-5 ii libgtk-4-1 4.12.2+ds-1 ii libical3 3.0.16-1+b1 ii libjson-glib-1.0-0 1.8.0-1 ii libmutter-12-0 44.5-1 ii libnm0 1.44.0-1 ii libpango-1.0-0 1.51.0+ds-2 ii libpolkit-agent-1-0 123-1 ii libpolkit-gobject-1-0123-1 ii libpulse-mainloop-glib0 16.1+dfsg1-2+b1 ii libpulse016.1+dfsg1-2+b1 ii libsecret-1-00.21.1-1 ii libsystemd0 254.4-1 ii libx11-6 2:1.8.6-1 ii libxfixes3 1:6.0.0-2 ii python3 3.11.4-5+b1 Versions of packages gnome-shell recommends: ii bolt 0.9.6-1 ii chrome-gnome-shell 42.1-4 ii
Bug#1050913: sway: please provide a sway-portals.conf for xdg-desktop-portal
On Thu, 31 Aug 2023 at 12:32:32 +0100, Simon McVittie wrote: > If I'm reading correctly, I think sway uses XDG_CURRENT_DESKTOP="sway"? If > that's the case, then it should provide a sway-portals.conf so that > individual users aren't required to set this up for themselves. ... > The desktop environment (either sway or some larger metapackage) should > probably also have a Recommends, or at least a Suggests, on whatever > portals would be most appropriate for it. I see that it already Suggests > xdg-desktop-portal-wlr, but not -gtk. FYI, here is the equivalent of the requested change in openSUSE: https://build.opensuse.org/request/show/1113340 smcv
Bug#1020217: S3-backed snapshot implementation on AWS?
Hi, On 24/09/23 at 16:09 -0700, Noah Meyerhans wrote: > On Fri, Sep 22, 2023 at 05:12:21PM +0200, Bastian Blank wrote: > > > Could we use the Debian AWS account to host that service? > > > > I would assume that a service like snapshot would be within the scope > > for our AWS usage. Noah? > > It makes sense and I will look into it. Let's not start anything until > we hear definitive confirmation. Do we have a sense of how much > outgoing traffic the current snapshot service generates? >From #debian-admin: lucas: https://munin.debian.org/debian.org/sallinen.debian.org/ip_193_62_202_27.html and https://munin.debian.org/debian.org/sallinen.debian.org/ip_2001_630_206_4000_1a1a_0_c13e_ca1b.html I think, so average of 35Mbit/sec over the last week. > > However we need to talk about that "one […] VM", because this sounds > > like you intend to use AWS as VM hosting, which it is not. > > > > Please think about this in form of services and there should be at least > > two: > > - the injestor, which can only exist once and writes, and > > - the web frontend, which should be able to exist several times and only > > reads. > > > > So you want to plan with running the multiple web frontends with load > > balancers and maybe even cloudfront. > > I agree that it would be best to design something more cloud-oriented. > However, if there's an existing infrastructure that can be moved as a > "lift & shift" into AWS now, with architectural refactoring happening > later, that's an OK place to start. Yes, that would be the plan I think: start with moving to AWS and replacing the filesystem-backed storage backend to an S3-backed on. Then look at other aspects. Lucas
Bug#967312: dia: depends on deprecated GTK 2
Control: tags -1 + fixed-upstream On Tue, 04 Aug 2020 at 11:35:55 +0100, s...@debian.org wrote: > This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces > binary packages with a Depends on GTK 2. I happened to notice a mention on planet.gnome.org that this is fixed in upstream git for versions labelled 0.98 or later, which are GTK-3-based (there seems to be no such release yet, only snapshots). smcv
Bug#1052614: RFP: python-skbuild-core -- next generation Python CMake adaptor and Python API for plugins
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-pyt...@lists.debian.org, eam...@debian.org Control: affects -1 src:fenics-basix * Package name: scikit-build-core Version : 0.5.1 Upstream Contact: Henry Schreiner * URL : https://github.com/scikit-build/scikit-build-core * License : Apache2 Programming Lang: Python Description : next generation Python CMake adaptor and Python API for plugins Scikit-build-core is a ground-up rewrite of the classic Scikit-build, a bridge between Python package build systems and CMake, the most popular compiled language build system. The key features of scikit-build classic (which is setuptools based) are also present here: -Great support for or by most OSs, compilers, IDEs, and libraries -Support for C++ features and other languages like Fortran -Support for multithreaded builds -Simple CMakeFiles.txt instead of up to thousands of lines of fragile setuptools/distutils code -Cross-compile support for Apple Silicon and Windows ARM Scikit-build-core is required by the future version of Basix. The Debian Pythom Team is a natural home for the package. cc: Emmanuel Arias in his role as Uploader for the old scikit-build package.
Bug#1052218: bookworm-pu: package monitoring-plugins/2.3.3-5+deb12u1
Am 23.09.23 um 21:42 schrieb Adam D. Barratt: Control: tags -1 confirmed On Tue, 2023-09-19 at 08:35 +0200, Jan Wagner wrote: As reported in #1051768, check_disk has gotten very slow on a machine with a huge number of mount points (in excess of 16000). [ Impact ] check_disk used to take around 10 seconds on bullseye in this scenario, now it is more than one hour Please go ahead. monitoring-plugins_2.3.3-5+deb12u1 was uploaded to proposed-updates. with best regards, Jan
Bug#1052613: Keepalived occasionally fails SSL_CHECK
Package: keepalived
Version: 1:2.2.7-1
I'm upgrading our servers from Bullseye to Bookworm. Some of them act as load
balancers using keepalived.
Right now I have one Bullseye and one Bookworm with the same configuration
checking the same services.
Several of our services are running on HTTPS therefore I'm using SSL_CHECK.
I can see that the Bookworm one occasionally fails SSL_CHECK for several
seconds on one service while the
Bullseye does not report any problem at all.
It's quite rare - not even once per hour with 2s loop delay.
I was looking for possible reason and I've found
https://github.com/openssl/openssl/issues/20365
https://github.com/pjsip/pjproject/issues/3632
https://stackoverflow.com/questions/18179128/how-to-manage-the-error-queue-in-openssl-ssl-get-error-and-err-get-error
They are all basically saying that you can have multiple SSL errors left in
error queue and you are supposed to
run|ERR_get_error() before calling |SSL_* functions.
I've tried to patch keepalived sources (see attachment) and the problem seems
to disappear.
I have no idea why is Bullseye package unaffected. It might be related to
different OpenSSL version.
What do you think about this?
--
Pavel Matěja
--- keepalived-2.2.7.orig/keepalived/check/check_ssl.c
+++ keepalived-2.2.7/keepalived/check/check_ssl.c
@@ -257,6 +257,7 @@ ssl_connect(thread_ref_t thread, int new
#endif
}
+ ERR_clear_error();
ret = SSL_connect(req->ssl);
return ret;
@@ -269,6 +270,7 @@ ssl_send_request(SSL * ssl, const char *
while (true) {
err = 1;
+ ERR_clear_error();
r = SSL_write(ssl, str_request, request_len);
if (SSL_ERROR_NONE != SSL_get_error(ssl, r))
break;
@@ -306,6 +308,7 @@ ssl_read_thread(thread_ref_t thread)
}
/* read the SSL stream - allow for terminating the data with '\0 */
+ ERR_clear_error();
r = SSL_read(req->ssl, req->buffer + req->len, (int)(MAX_BUFFER_LENGTH - 1 - req->len));
req->error = SSL_get_error(req->ssl, r);
Bug#1052612: qml6-module-qt5compat-graphicaleffects: missing dependency on 'qml6-module-qtquick-window'
Package: qml6-module-qt5compat-graphicaleffects
Version: 6.4.2-3
Severity: normal
Dear Maintainer,
The 'qml6-module-qt5compat-graphicaleffects' provides a "GaussianBlur"
definition (in
/usr/lib/${DEB_HOST_MULTIARCH}/qt6/qml/Qt5Compat/GraphicalEffects/GaussianBlur.qml),
which depends on "QtQuick.Window", which in turn is provided by the
'qml6-module-qtquick-window' package.
However, no relation to this dependency is declared.
I understand that 'qml6-module-qt5compat-graphicaleffects' provides more than
just the "GaussianBlur" definition, and the other qml files do not have the
dependency, so you probably think this is an *optional* dependency.
Which is fine, and for this we have the "Recommends" (or even "Suggests") field.
However, i think *one* of these fields ought to contain a reference to
'qml6-module-qtquick-window'.
The missing dependency broke the 'jacktrip-gui' package, which would only show
a blank window if the 'qml6-module-qtquick-window' was not installed.
Hunting down the cause of this failure was more complicated than it should be,
because of this missing reference.
So I would go for "Depends" or "Recommends".
thanks for your consideration.
Bug#979466: dh-sysuser: Create users in preinst instead of postinst
Hi, Well, you can write your code after the #DEBHELPER# token.. but I guess this doesn't work for your use case? Exactly. The use case is: - create a system user - chown a directory (e.g. for logs) - start the service The DEBHELPER token expands into too many tasks including starting the service which would fail if the directory does not have the correct permissions. Do you have the same problem as Lars - " move the `#DEBHELPER#` marker to the top of the postinst script. But this would lead to related services being restarted (via the other debhelper snippets) before the directory permissions are configured. " Yes - same problem. Yeah that was the idea, but then I realized that writing in preinstall doesn't work with this package design: the preinstall snippet will call sysuser-helper which is not guaranteed to be installed yet :( Ah, because it is an extra package. The clearest solution to me would be to ship sysuser-helper with the debhelper package. That would make sure the needed helper script is already installed and can be called in DEBHELPER - voila! So far I can think of the following: 1. The code can be written entirely in the preinstall but this defeats the idea of having the code in a separate binary (sysuser-helper) which has drawbacks like this bug but also has other advantages that I would like not to give up; maybe there can be a specific option to do this? I also like the idea of putting the code to create a new user into a separate binary so that all packages which use this method can directly benefit from it. 2. dh-sysuser can grow an interface similar to systemd-tempfiles but less complex and specialized in changing mode and ownership to files and dirs and makes sure that the snippet in postinstall is run after the creation of the user (I'm not particularly eager to do this..) This also sounds clever: If the control file for dh_sysuser also includes the optional information which files or directories should get chown'ed this task could also be taken over by the helper which then would guarantee the right order of execution. In case 1. is not feasible, do you dislike 2? Would it work for your use case? I still think the best solution would be to include the helper script in debhelper. Then you would move creating the user in preinst. You could also add the chown of files and/or directories into postinst. Doing it this way should enable all package maintainers the maximum flexibility. But for me options 1 and 2 would also work. I neglected a bit this package during the last cycle, hopefully I'll manage to do better in this cycle Thank you for your work! Cheers, Christopher -- == Dipl.-Ing. Christopher Odenbach Zentrum fuer Informations- und Medientechnologien Universitaet Paderborn Raum N5.308 odenb...@uni-paderborn.de Tel.: +49 5251 60 5315 == smime.p7s Description: Kryptografische S/MIME-Signatur
Bug#1013356: fzf: Bash completions not active by default
Hey. A workaround would be what the git package does with: /etc/bash_completion.d/git-prompt which sources: /usr/lib/git-core/git-sh-prompt which in turn provides: __git_ps1() and some others that are thereby unconditionally loaded by every bash instance. I've asked upstream whether there are means to have files in /usr/ sourced unconditionally, perhaps that would be a better approach - at least if there'd be also a way to mask that again: https://github.com/scop/bash-completion/issues/1055 Cheers, Chris.
Bug#1052611: bullseye-pu: package roundcube/1.4.14+dfsg.1-1~deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: roundc...@packages.debian.org
Control: affects -1 + src:roundcube
[ Reason ]
roundcube 1.4.13+dfsg.1-1~deb11u1 is vulnerable to CVE-2023-43770:
cross-site scripting (XSS) vulnerability in handling of linkrefs in
plain text messages.
The Security Team decided not to issue a DSA for that CVE, but it's now
fixed in buster-security (1.3.17+dfsg.1-1~deb10u3) as well as
testing/sid (1.6.3+dfsg-1), so it makes sense to fix it via (o)s-pu
too.
[ Impact ]
Roundcube users will remain vulnerable to the XSS issue. For users
uprading from buster-security to bullseye, that would be a security
regression.
[ Tests ]
The XSS fix is covered by automated tests (phpunit) at build time, and I
also manually tested the fix.
[ Risks ]
I believe the regression risk is very low, given the diff is fairly
simple, and this is not a backport but an official upstream release from
the LTS branch.
[ 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 oldstable
[x] the issue is verified as fixed in unstable
[ Changes ]
* New security/bugfix upstream release:
+ Fix CVE-2023-43770: cross-site scripting (XSS) vulnerability in handling
of linkrefs in plain text messages. (Closes: #1052059)
+ Enigma: Fix initial synchronization of private keys.
* d/u/signing-key.asc: Add Alec's key BEE674A019359DC1.
* Refresh d/patches.
[ Other info ]
bullseye(-security) has been following the upstream 1.4 branch, so I
propose to upload 1.4.14+dfsg.1-1~deb11u1 rather than cherry-pick the
CVE-2023-43770 fix on top of 1.4.13+dfsg.1-1~deb11u1.
--
Guilhem.
diffstat for roundcube-1.4.13+dfsg.1 roundcube-1.4.14+dfsg.1
CHANGELOG |8
composer.json-dist |5
debian/changelog| 11
debian/patches/fix-FTBFS-with-phpunit-8.5.13-1.patch|4
debian/patches/fix-FTBFS-with-phpunit-9.5.0-1.patch |8
debian/patches/fix-install-path.patch |4
debian/patches/hint-at-which-packages-needs-installing-under-PHP8.patch |2
debian/patches/update-composer.patch|9
debian/patches/update-script.patch |2
debian/upstream/signing-key.asc | 199
+++---
index.php |2
installer/index.php |2
plugins/enigma/lib/enigma_driver_gnupg.php |7
program/include/iniset.php |2
program/lib/Roundcube/bootstrap.php |2
program/lib/Roundcube/rcube_string_replacer.php |4
public_html/index.php |2
public_html/plugins/enigma/lib/enigma_driver_gnupg.php |7
tests/Framework/StringReplacer.php | 12
tests/Framework/Text2Html.php | 17
20 files changed, 223 insertions(+), 86 deletions(-)
diff -Nru roundcube-1.4.13+dfsg.1/CHANGELOG roundcube-1.4.14+dfsg.1/CHANGELOG
--- roundcube-1.4.13+dfsg.1/CHANGELOG 2021-12-29 23:45:05.0 +0100
+++ roundcube-1.4.14+dfsg.1/CHANGELOG 2023-09-16 22:01:19.0 +0200
@@ -1,5 +1,9 @@
-CHANGELOG Roundcube Webmail
-===
+# Changelog Roundcube Webmail
+
+RELEASE 1.4.14
+--
+- Fix cross-site scripting (XSS) vulnerability in handling of linkrefs in
plain text messages
+- Enigma: Fix initial synchronization of private keys
RELEASE 1.4.13
--
diff -Nru roundcube-1.4.13+dfsg.1/composer.json-dist
roundcube-1.4.14+dfsg.1/composer.json-dist
--- roundcube-1.4.13+dfsg.1/composer.json-dist 2021-12-29 23:45:05.0
+0100
+++ roundcube-1.4.14+dfsg.1/composer.json-dist 2023-09-16 22:01:19.0
+0200
@@ -27,5 +27,10 @@
"suggest": {
"kolab/net_ldap3": "~1.1.1 required for connecting to LDAP",
"mkopinsky/zxcvbn-php": "^4.4.2 required for Zxcvbn password strength
driver"
+},
+"config": {
+"allow-plugins": {
+"roundcube/plugin-installer": true
+}
}
}
diff -Nru roundcube-1.4.13+dfsg.1/debian/changelog
roundcube-1.4.14+dfsg.1/debian/changelog
--- roundcube-1.4.13+dfsg.1/debian/changelog2022-01-06 08:51:41.0
+0100
+++ roundcube-1.4.14+dfsg.1/debian/changelog2023-09-25 11:32:59.0
+0200
@@ -1,3 +1,14 @@
+roundcube
Bug#988652: Issue is now gone
Hi, The virtual machine that was having this issue, is now working correctly. We did nothing (that we are aware of) to fix the issue. Server is patched regularly, but I see no new rsyslog version installed in dpkg.log. Thanks Eneko Lacunza Zuzendari teknikoa | Director técnico Binovo IT Human Project Tel. +34 943 569 206 | https://www.binovo.es Astigarragako Bidea, 2 - 2º izda. Oficina 10-11, 20180 Oiartzun https://www.youtube.com/user/CANALBINOVO https://www.linkedin.com/company/37269706/
Bug#988462: Trac 1.6 released
Hi, FYI Trac 1.6 has been published. https://trac.edgewall.org/wiki/TracDownload Cheers Eneko Lacunza Zuzendari teknikoa | Director técnico Binovo IT Human Project Tel. +34 943 569 206 | https://www.binovo.es Astigarragako Bidea, 2 - 2º izda. Oficina 10-11, 20180 Oiartzun https://www.youtube.com/user/CANALBINOVO https://www.linkedin.com/company/37269706/
Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable
On 2023-09-25, at 10:31:57 +0200, Arturo Borrero Gonzalez wrote: > On 9/24/23 13:48, Salvatore Bonaccorso wrote: > > The work for bookworm has been done, but for bullseye: would you be > > able to help here and prepare the fixes? Unfortunatlly the fixes will > > not apply cleanly. If we fear to much breakage, maybe upstream can be > > convinced to help? > > > > Hi Salvatore, > > I don't think I will have a lot of time to work on this in the next few weeks. > > I'm sorry :-( I can pick it up. I took a look at the patches yesterday evening and it wasn't much work to fix them up for Bullseye. I'll run the test-suites and check for regressions. J. signature.asc Description: PGP signature
Bug#1052610: u-boot-rockchip: not possible to boot from SSDs connected to SATA PCIe DeLOCK 9049
Package: u-boot-rockchip Version: 2023.07+dfsg-1_arm64 Severity: normal Hardware: RockPro64/4GB + DeLOCK 90498 SATA PCIe + 2 SATA SSDs It's not possible to boot of the connected disks. u-boot consoles output on a failed boot (falling back to eMMC): ``` Hit any key to stop autoboot: 0 => pci BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1d87 0x0100 Bridge device 0x04 01.00.00 0x197b 0x0585 Mass storage controller 0x06 => scsi scan scanning bus for devices... SATA link 0 timeout. SATA link 1 timeout. Target spinup took 0 ms. Target spinup took 0 ms. SATA link 4 timeout. AHCI 0001.0301 32 slots 5 ports 6 Gbps 0x1f impl SATA mode flags: 64bit ncq stag pm led clo pmp fbss pio slum part ccc apst boh Device 0: (2:0) Vendor: ATA Prod.: HP SSD S700 250G Rev: SN10 Type: Hard Disk Capacity: 238475.1 MB = 232.8 GB (488397168 x 512) Device 1: (3:0) Vendor: ATA Prod.: TOSHIBA THNSNH25 Rev: HTFA Type: Hard Disk Capacity: 244198.3 MB = 238.4 GB (500118192 x 512) => boot Card did not respond to voltage select! : -110 ** Booting bootflow 'mmc@fe33.bootdev.part_1' with script Boot script loaded from mmc 0 ``` On the other hand it is possible to use the connected SATA SSDs from an Armbian 23.8.1 Bullseye with Linux 4.4.213-legacy-rockchip64. Here's part of the dmesg showing the important part of the initialisation: ``` rockchip-pcie f800.pcie: missing "memory-region" property PCI host bridge /pcie@f800 ranges: rockchip-pcie f800.pcie: invalid power supply rockchip-pcie f800.pcie: wait 1000 ms (from device tree) before bus scan rockchip-pcie f800.pcie: PCI host bridge to bus :00 pci_bus :00: root bus resource [bus 00-1f] pci_bus :00: root bus resource [mem 0xfa00-0xfbdf] pci_bus :00: root bus resource [io 0x-0xf] (bus address [0xfbe0-0xfbef]) ``` **But** this only works if u-boot didn't try to initialise the card first. If u-boot already failed to use the card the according dmesg looks like the following and neither the PCIe card nor the SSDs are visible to Linux: ``` rockchip-pcie f800.pcie: missing "memory-region" property PCI host bridge /pcie@f800 ranges: rockchip-pcie f800.pcie: invalid power supply rockchip-pcie f800.pcie: PCIe link training gen1 timeout! rockchip-pcie f800.pcie: deferred probe failed rockchip-pcie: probe of f800.pcie failed with error -110 ehci-pci: EHCI PCI platform driver vcc3v3_pcie: disabling ```
Bug#1052609: Package linux-image: "systemctl poweroff" don't POWEROFF the PC with Kernel 6.5
package: linux-image-siduction-amd64 since Kernel 6.5 from package linux-image in Debian/Sid the command "systemctl poweroff" don't POWEROFF the PC - only HALT. Kernel 6.5 is incompatible with my Hardware DELL XPS L702x. with regards Ch. Hanisch -- Mein öffentlicher Schlüssel ist auf dem Keyserver 'https://keys.openpgp.org' unterch-hani...@t-online.de (E53DF487)
Bug#1052608: RM: gtkguitune -- ROM; Dead upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: gtkguit...@packages.debian.org, a.k...@bobek.cz, 1052...@bugs.debian.org Control: affects -1 + src:gtkguitune Hola, would like to request removal of gtkguitune from the repository. It is abandoned by upstream and also depends on gtk2. It is also not Good replacement is `lingot`. Also got the request from QA team at 1052518 by Bastian. Thanks, Antonin signature.asc Description: PGP signature
Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable
On 9/24/23 13:48, Salvatore Bonaccorso wrote: The work for bookworm has been done, but for bullseye: would you be able to help here and prepare the fixes? Unfortunatlly the fixes will not apply cleanly. If we fear to much breakage, maybe upstream can be convinced to help? Hi Salvatore, I don't think I will have a lot of time to work on this in the next few weeks. I'm sorry :-(
Bug#1052459: mini-buildd: Problems with unnecessarily doubled slashes
Hi Magnus,
On Fri, 2023-09-22 at 15:37 +0200, Magnus Holmgren wrote:
> Package: mini-buildd
> Version: 2.0.7~bpo12+1
>
> mini-buildd requires (in Archive.clean) that all archive URLs end in
> a slash.
> Yet it (always?) adds another slash before 'dists' (e.g.
> Archive.ReleaseFile(f"{archive.url}/dists/{self.codename}/") in
> Source.mbd_check). With behaving servers, this shouldn't be a
hmm yes, that's indeed unnecessary ;). Fix pending.
Thx!
Stephan
signature.asc
Description: This is a digitally signed message part
Bug#1052607: pxdvi can not use haranoaji fonts
Package: xdvik-ja Version: 22.87.05+j1.42-2 Dear Maintainer, If kanjix.map is generated to use haranoaji fonts (default) by kanji-config-updmap, dvipdfmx works fine, but pxdvi can not display japanese characters.
Bug#1003192: marked as pending in debian-edu-config
The changes in debian-edu-config, debian-edu-install, and pam-mklocaluser should cover new installations, but how should upgrades be handled? -- Guido Berhoerster
Bug#1052606: python3-pyroute2: pyroute2.__version__ is "unknown"
Package: python3-pyroute2 Version: 0.7.7-1 Severity: minor Dear Maintainer, python3 -c 'from pyroute2 import __version__; print(__version)' returns "unknown" instead of the pyroute2 version number. We need to determine the actual pyroute2 version to determine how to handle some aspects of its API. When I add diff --git a/debian/rules b/debian/rules index dd0e300..f94599c 100755 --- a/debian/rules +++ b/debian/rules @@ -13,6 +13,7 @@ override_dh_auto_clean: rm -rf build .stestr *.egg-info .pybuild find . -iname '*.pyc' -delete for i in $$(find . -type d -iname __pycache__) ; do rm -rf $$i ; done + rm -f pyroute2/config/version.py override_dh_auto_test: ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS))) @@ -25,6 +26,7 @@ endif override_dh_auto_build: echo $$OSLO_PACKAGE_VERSION > VERSION + $(MAKE) VERSION dh_auto_build override_dh_installchangelogs: pyroute2.__version__ contains the expected version number. Thanks for packaging pyroute2!! Kind regards, Nicolas -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.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 python3-pyroute2 depends on: ii python3 [python3-supported-min] 3.11.4-5+b1 ii python3-psutil 5.9.4-1+b1 python3-pyroute2 recommends no packages. python3-pyroute2 suggests no packages. -- no debconf information
Bug#1052584: linux-image-6.5.0-1-amd64: NFS4 stopped working in 6.5 with SELinux error
Control: tags -1 + moreinfo Hi Michal, On Mon, Sep 25, 2023 at 12:52:16AM +0200, Michal Kaspar wrote: > Package: src:linux > Version: 6.5.3-1 > Severity: normal > > Dear Maintainer, > After upgrading to kernel version 6.5.0-1-amd64, the NFS4 stopped > working on the station. Whe trying to mount nf4 FS, the mount fails with > error: > mount.nfs: an incorrect mount option was specified for > The kernel log contains error message: > kernel: SELinux: Unable to set superblock options before the security server > is initialized > This puzzles me a bit as I've got SELinux disabled (don't even have > SELinux userspace installed, /sys/fs/selinux/enforce says 0). Tried > booting with selinux=0 boot parameter but with the same result. > Rebooting wih previou (6.4.0-4-amd64) kernel version fixes the problem > immediately. I suspect this is fixed by https://git.kernel.org/linus/ccf1dab96be4caed7c5235b1cfdb606ac161b996 in 6.6-rc2, and which went into 6.5.5 (will be included on next unstable upload). Can you apply the patch on top to confirm if that fixes the issue for you? Regards, Salvatore
Bug#927228: supervisor.log is not rotated
I tried with supervisor package (4.2.5-1) and I failed to get a
rotation automatically. The configuration file is not modified so the
default values should be used by supervisord.
Steps:
1. fill /var/log/supervisor/supervisord.log file under 50M:
$ ls -l /var/log/supervisor/supervisord.log
-rw-rw-rw- 1 root root 49994043 24 sept. 10:04
/var/log/supervisor/supervisord.log
$ ls -lh /var/log/supervisor/supervisord.log
-rw-rw-rw- 1 root root 48M 24 sept. 10:04 /var/log/supervisor/supervisord.log
2. Restart supervisord:
$ sudo systemctl stop supervisor.service
$ sudo systemctl start supervisor.service
3. Force supervisor to write on supervisord.log with a crashing daemon:
$ for i in $(seq 1 3000); do {sudo supervisorctl start demo; sleep 10}; done
'demo' crashes everytime. The loop restarts 'demo' because otherwise
'supervisord' set 'demo' process as BACKOFF status after several
attempts. Then, supervisord does not try to restart it again (which is
probably a good strategy).
4. See results:
$ ls -la /var/log/supervisor/supervisord.log
-rw-rw-rw- 1 root root 51476910 25 sept. 09:07
/var/log/supervisor/supervisord.log
$ ls -lh /var/log/supervisor/supervisord.log
-rw-rw-rw- 1 root root 50M 25 sept. 09:07 /var/log/supervisor/supervisord.log
The file is over 50M but there is no rotation:
$ sudo find /var/log -name "supervisord.log*"
/var/log/supervisor/supervisord.log
'/var/log/supervisor/supervisord.log.1' does not exist.
I plan to read source code and probably raise an issue on supervisor
github repository if needed.
--
Stéphane
Bug#1052605: pyroute2: Vcs-Git refers to non-public repository
Source: pyroute2 Severity: wishlist Dear Maintainer, can you please consider to open the pyroute2 Debian git repository for public read-only access? The pyroute2 source package's Vcs-Git URL refers to stable (0.7.2-2): https://salsa.debian.org/third-party/pyroute2.git testing, unstable (0.7.3-4), experimental (0.7.7-1): https://salsa.debian.org/openstack/third-party/pyroute2.git But both repositories are not publicly accessible. (Actually neither the 'third-party' nor 'openstack' projects are visible for unauthorized access.) For collaboration it would be nice, if read-only access could be provided. Kind regards, Nicolas
Bug#1052604: intelrdfpmath: Please add LoongArch architecture support.
Source: intelrdfpmath Version: 2.0u2-8 Severity: normal Tags: patch User: debian-de...@lists.debian.org Usertags: loongarch64 X-Debbugs-Cc: sangm...@loongson.cn Dear Maintainer, intelrdfpmath is lacking LoongArch architecture support, and it cannot compile successfully in the Debian Package Auto-Building environment[1]. Please consider using the attached patch to add LoongArch architecture support. [1]:https://buildd.debian.org/status/logs.php?pkg=intelrdfpmath=2.0u2-8=loong64 thanks, Meng Sang >From 64a7e06b7941b83e32eebe84f4288749db221118 Mon Sep 17 00:00:00 2001 From: Meng Sang Date: Mon, 25 Sep 2023 06:56:30 + Subject: [PATCH] Add loongarch64 support --- LIBRARY/makefile.iml_head | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/LIBRARY/makefile.iml_head b/LIBRARY/makefile.iml_head index 4a1b16b..2e04c93 100755 --- a/LIBRARY/makefile.iml_head +++ b/LIBRARY/makefile.iml_head @@ -177,7 +177,7 @@ GenTypeVarList = $(call PrefixSuffix,$1,$(if $2, \ # returned # == -__INDICES__ = 1 2 3 4 5 6 7 8 9 10 11 12 13 14 +__INDICES__ = 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 GetIndex = $(strip $(word 1,$(if $(word $(words $(__INDICES__)),$2), \ $(error "List too large. Adjust __INDICES__"), \ @@ -344,9 +344,9 @@ else endif endif -ARCH_ALIAS := x86 ia64 EM64T x86_64 i686 amd64 Intel64 sun4u arm aarch64 powerpc64le riscv64 s390x -ARCH_LIST := IA32 IA64 EFI2 EFI2 IA32 EFI2 EFI2EFI2 IA32 EFI2 EFI2EFI2S390X -ARCH_TYPE := IA32 IA64 EFI2 EFI2 IA32 EFI2 EFI2EFI2 IA32 EFI2 EFI2EFI2S390X +ARCH_ALIAS := x86 ia64 EM64T x86_64 i686 amd64 Intel64 sun4u arm aarch64 powerpc64le riscv64 s390x loongarch64 +ARCH_LIST := IA32 IA64 EFI2 EFI2 IA32 EFI2 EFI2EFI2 IA32 EFI2 EFI2EFI2S390X EFI2 +ARCH_TYPE := IA32 IA64 EFI2 EFI2 IA32 EFI2 EFI2EFI2 IA32 EFI2 EFI2EFI2S390X EFI2 ARCH_TYPES := IA32 IA64 EFI2 S390X UARCH_LIST := SSE GSSE LRB LRB2 -- 2.40.1
Bug#1052603: (no subject)
the upstream pr : https://bitbucket.org/odedevs/ode/pull-requests/11/add-support-for-loongarch
Bug#1052603: ode: Please add loongarch64 support .
Source: ode Version: 2:0.16.2-1 Severity: normal Tags: patch loongarch64 Hello! The package build failed in buildd and The ode upstream has support loongarch64 ,Please help to fix this . Thanks, JiaLing -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: loong64 (loongarch64) Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Description: ode upstream has support loongarch64. Author: JiaLing Zhang --- ode-0.16.2.orig/include/ode/odeconfig.h +++ ode-0.16.2/include/ode/odeconfig.h @@ -84,6 +84,7 @@ #if defined(__aarch64__) || defined(__alpha__) || defined(__ppc64__) \ || defined(__s390__) || defined(__s390x__) || defined(__zarch__) \ || defined(__mips__) || defined(__powerpc64__) || defined(__riscv) \ +|| defined(__loongarch64) \ || (defined(__sparc__) && defined(__arch64__)) #include typedef int64_t dint64;
Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
Manphiz writes: > Nicholas D Steeves writes: > >> Hi manphiz, >> >> Manphiz writes: >> >>> Xiyue Deng writes: >>> >>> Hi sten, >>> >>> When trying to pick a new upstream to rebase, I found that pulling >>> either upstream repo will result in an incompatible git history versus >>> the current debian/master branch on salsa. >> >> This is expected, but please merge from upstream. >> >>> I wonder how I should handle this? >> >> The commit of the upstream source you import should be tagged. If >> upstream hasn't made a tagged release, then you'll need to: >> >> 1. With a the upstream of your choice set in the watch file, "gbp >> import-orig --uscan" will do the right thing in this repository. This >> is one reason why a functioning watch file that defines the correct >> upstream is useful. It should also save time to do this once, and >> then switch to a tag merging workflow for the next upstream import. >> >> OR >> >> I. Ask upstream to tag a stable release (probably NA to GNU ELPA's >> monorepo) >> II. Merge that tag to either the upstream branch, or directly to the >> Debian packaging branch. See the merge note at §i. >> III. Do fixup work to make "git diff tag -- !(debian)" clean. >> >> OR >> >> i. Merge new upstream commit to the upstream branch (which will also >> merge its history), because tags of detached HEADS behave unreliably >> through remotes; ie the tag needs to be of a commit on a branch. See >> git merge man page about what to about unrelated histories. >> ii. Create an annotated tag in the format you defined in debian/watch >> (note substitutions for special characters). I've always done this >> manually with a "Tag upstream snapshot for Debian use" annotation, but >> NOTE: There is probably a better way to create these tags by now. >> iii. Merge your annotated tag to the Debian packaging branch. >> iv. Do fixup work to make "git diff tag -- !(debian)" clean. >> >> In every case, you'll need to insure that the upstream tag is pushed to >> Salsa. >> >>> Is it OK to force push to master? >> >> No. >> >> Best, >> Nicholas >> > > Thanks Nicholas, David! I found that "git merge upstream/externals/muse > --allow-unrelated-histories" did what I wanted. However, as this merged > pulled in the whole history of upstream repo it now has 1000+ commits > since the current debian/master. To be cautious, I have created a merge > request[1] which also has the packaging updates to the latest head. > PTAL. > > [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/4 Friendly ping for comments. Or should I prepare a package and upload to mentors directly for review? -- Manphiz signature.asc Description: PGP signature
Bug#1052602: bind9-host should have versioned Depends on bind9-libs
Package: bind9-host Version: 1:9.16.42-1~deb11u1 Severity: normal Dear Maintainer, when updating only package bind9 and then trying to use the host command from bind9-host (as our ansible-based upgrade procedure does, doing the latter to check if the local named is still working as expected), you get to see $ host debian.org host: error while loading shared libraries: libdns-9.16.42-Debian.so: cannot open shared object file: No such file or directory No big issue, but I guess this means there should be a versioned dependency declared. Cheers Wolfgang *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-25-amd64 (SMP w/1 CPU thread) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bind9-host depends on: ii bind9-libs 1:9.16.44-1~deb11u1 ii libc6 2.31-13+deb11u6 ii libidn2-0 2.3.0-5 bind9-host recommends no packages. bind9-host suggests no packages. -- no debconf information
Bug#1052601: Fix Description so everybody can understand it
Package: remind-tools Version: 04.02.06-1 Severity: minor >Description: sophisticated calendar and alarm program - rem2ps, 2pdf, 2html >tools > Remind allows you to remind yourself of upcoming events and appointments. > Each reminder or alarm can consist of a message sent to standard output, or a > program to be executed. > It also features: sophisticated date calculation, moon phases, > sunrise/sunset, Hebrew calendar, alarms, PostScript output, tcl/tk front-end > and proper handling of holidays. > Tools to convert the remind output to ps, pdf or html as well as > example files. I would change the last sentence to say: < This remind-tools package provides tools to convert the remind output < to ps, pdf or html as well as example files.
Bug#1052600: libxss: No uploader
Source: libxss Version: 1:1.2.3-1 Severity: important X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, There is no uploader at this moment, it is required in this case I think. Debian Policy Manual, Release 4.6.2.0 3.3 The maintainer of a package If the maintainer of the package is a team of people with a shared email address, the Uploaders control field must be present and must contain at least one human with their personal email address. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052599: No uploader
Source: libxshmfence Version: 1.3-1 Severity: important X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, There is no uploader at this moment, it is required in this case I think. Debian Policy Manual, Release 4.6.2.0 3.3 The maintainer of a package If the maintainer of the package is a team of people with a shared email address, the Uploaders control field must be present and must contain at least one human with their personal email address. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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
