Bug#1021711: rustc: Bootstrapping process only seems to work for amd64
On Thu, 13 Oct 2022 12:42:59 +0100 Christopher Obbard wrote: > Package: rustc > Version: 1.61.0+dfsg1-2 > Severity: normal > > Dear Maintainer, > > When following the bootstrapping process in d/README.source, it only > seems to generate a tarball with the amd64 binaries despite the variable > upstream_bootstrap_arch set to include more bootstrap architectures. > > I am running: > > $ upstream_bootstrap_arch="amd64 arm64" debian/rules source_orig-stage0 > ... > debian/make_orig-stage0_tarball.sh > downloading > https://static.rust-lang.org/dist/2022-04-07/rust-std-1.60.0-x86_64-unknown-linux-gnu.tar.xz > > 100.0% > extracting > rustc/build/cache/2022-04-07/rust-std-1.60.0-x86_64-unknown-linux-gnu.tar.xz > downloading > https://static.rust-lang.org/dist/2022-04-07/rustc-1.60.0-x86_64-unknown-linux-gnu.tar.xz > > 100.0% > extracting > rustc/build/cache/2022-04-07/rustc-1.60.0-x86_64-unknown-linux-gnu.tar.xz > downloading > https://static.rust-lang.org/dist/2022-04-07/cargo-1.60.0-x86_64-unknown-linux-gnu.tar.xz > > 100.0% > extracting > rustc/build/cache/2022-04-07/cargo-1.60.0-x86_64-unknown-linux-gnu.tar.xz > building stage0 tar file now, this will take a while... > > > orig-stage0 bootstrapping tarball created in > ../rustc_1.61.0+dfsg1.orig-stage0.tar.xz > containing the upstream compilers for amd64 arm64 > > You *probably* now want to do the following steps: > > 1. Add [!amd64 !arm64] to the rustc/cargo Build-Depends in d/control > 2. Update d/changelog > 3. Run `dpkg-source -b .` to generate a .dsc that includes this tarball. > > > > $ tar tvf ../rustc_1.61.0+dfsg1.orig-stage0.tar.xz > drwxr-xr-x root/root 0 2022-10-13 11:34 2022-04-07/ > -rw--- root/root 57248964 2022-04-07 14:44 > 2022-04-07/rustc-1.60.0-x86_64-unknown-linux-gnu.tar.xz > -rw--- root/root 6585328 2022-04-07 14:41 > 2022-04-07/cargo-1.60.0-x86_64-unknown-linux-gnu.tar.xz > -rw--- root/root 27569116 2022-04-07 14:44 > 2022-04-07/rust-std-1.60.0-x86_64-unknown-linux-gnu.tar.xz > -rw-r--r-- root/root 0 2022-10-13 11:34 > dpkg-source-dont-rename-parent-directory > > As you can see, only the x86_64 binary is present inside the stage0 tarball. > > To workaround this locally, I manually called > $ PYTHONPATH=src/bootstrap debian/get-stage0.py > then re-ran the source_orig-stage0 which packed the downloaded tarballs into > the stage0 tarball. since this came up in IRC a few times as well - I can reproduce the problem, and I think it stems from the interaction between the two architecture(-test).mk files and debian/rules, but I haven't had time to investigate more (yet).
Bug#1063435: geopandas: test fail with pandas 2.x on 32 bit - int32 vs int64 mismatch
Package: python3-geopandas Version: 0.14.3-1 Severity: serious Control: block 1043240 by -1 In pandas 2.x (now in unstable), there are a few places where geopandas uses native-size int but the plain pandas objects used as test references are always int64, failing the test: https://ci.debian.net/packages/p/python-geopandas/testing/armhf/42777226/ Probably a reasonable response is to ignore this (check_index_type=False/check_dtype=False) but I haven't looked carefully.
Bug#1061799: [PATCH] Migrate from using imp to importlib
Package: glueviz
Version: 1.0.1+dfsg-3
Tag: patch
I am attaching a patch that replaces the use of package imp by importlib.
Regards,
Pushkar
diff --git a/debian/patches/Replace-imp-by-importlib.patch b/debian/patches/Replace-imp-by-importlib.patch
new file mode 100644
index 000..fd5a5a0
--- /dev/null
+++ b/debian/patches/Replace-imp-by-importlib.patch
@@ -0,0 +1,37 @@
+Author: Pushkar Kulkarni
+Description: The "imp" package lets users implement the import statement,
+enabling dynamic loading of Python modules. The "imp" package was
+deprecated in an earlier version and removed in Python 3.12. The
+Python3 docs recommend moving to package "importlib" as a replacement.
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061799
+--- a/glue/config.py
b/glue/config.py
+@@ -1,8 +1,10 @@
+ import os
+-import imp
++import importlib
+ import sys
++import types
+ import warnings
+ from collections import namedtuple
++from importlib.machinery import SourceFileLoader
+
+ from glue.utils import format_choices
+
+@@ -994,13 +996,14 @@
+Exception, if no module was found
+ """
+ search_order = search_path or _default_search_order()
+-result = imp.new_module('config')
++# Create a new, empty module
++result = types.ModuleType('config')
+
+ for config_file in search_order:
+ dir = os.path.dirname(config_file)
+ try:
+ sys.path.append(dir)
+-config = imp.load_source('config', config_file)
++config = SourceFileLoader('config', config_file).load_module()
+ result = config
+ except IOError:
+ pass
diff --git a/debian/patches/series b/debian/patches/series
index 14a4a22..9e89a04 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ Install-in-proper-directory-.txt-file.patch
Add-Keywords-to-desktop-file.patch
Install-under-the-right-directory-the-package-data.patch
Pass-int-argument-to-QProgressBar.setValue.patch
+Replace-imp-by-importlib.patch
Bug#1061783: apprise fails its autopkg tests with Python 3.12
Control: reopen -1 Still failing with apprise/1.7.2-1 [1]. Please see one of the logs triggered by python3-defaults/3.12.1-1 from experimental. [1] https://ci.debian.net/packages/a/apprise/unstable/amd64/
Bug#1063434: src:389-ds-base: fails to migrate to testing for too long: FTBFS on 32 bits
Source: 389-ds-base Version: 2.3.4+dfsg1-1.1 Severity: serious Control: close -1 2.4.4+dfsg1-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:389-ds-base has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel, armhf and i386 (our 32 bit architectures). 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=389-ds-base OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063433: src:gjs: fails to migrate to testing for too long: FTBFS on mips64el
Source: gjs Version: 1.78.1-3 Severity: serious Control: close -1 1.78.3-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:gjs has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el. 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=gjs OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063432: src:linux-apfs-rw: fails to migrate to testing for too long: RC bug and autopkgtest failure
Source: linux-apfs-rw Version: 0.3.5-1 Severity: serious Control: close -1 0.3.7-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1060898 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:linux-apfs-rw has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable has an unresolved RC bug and fails its own autopkgtest. 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=linux-apfs-rw OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063431: src:r-cran-future.apply: fails to migrate to testing for too long: autopkgtest failure
Source: r-cran-future.apply Version: 1.11.0+dfsg-1 Severity: serious Control: close -1 1.11.1+dfsg-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:r-cran-future.apply has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest on armel, armhf and i386 (our 32 bits architectures). 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=r-cran-future.apply OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063430: src:seqan-needle: fails to migrate to testing for too long: FTBFS on amd64 and arm64
Source: seqan-needle Version: 1.0.2+ds-1 Severity: serious Control: close -1 1.0.2+ds-2 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:seqan-needle has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on amd64 and arm64. 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=seqan-needle OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063429: RFS: libfilezilla/0.46.0-1 -- build high-performing platform-independent programs (runtime lib)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libfilezilla": * Package name : libfilezilla Version : 0.46.0-1 Upstream contact : Tim Kosse * URL : https://lib.filezilla-project.org/ * License : GPL-2+ * Vcs : https://salsa.debian.org/debian/libfilezilla Section : libs The source builds the following binary packages: libfilezilla-dev - build high-performing platform-independent programs (development) libfilezilla-common - build high-performing platform-independent programs (translations) libfilezilla42 - build high-performing platform-independent programs (runtime lib) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libfilezilla/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.46.0-1.dsc Changes since the last upload: libfilezilla (0.46.0-1) unstable; urgency=medium . * New upstream version 0.46.0. * Soname bump rename package to libfilezilla42. * 'd/control'. - Update 'libgnutls28-dev' requitred version to minimum of 3.8.3. - Change 'Build-Depends' from obsolete 'pkg-config' to 'pkgconf'. Regards Phil -- Playing the game for the games sake. Web: * Debian Wiki: https://wiki.debian.org/PhilWyett * Website: https://kathenas.org * Social Debian: https://pleroma.debian.social/kathenas/ * Social Instagram: https://www.instagram.com/kathenasorg/ signature.asc Description: This is a digitally signed message part
Bug#1063426: src:node-websocket: fails to migrate to testing for too long: FTBFS on armel
Source: node-websocket Version: 1.0.34+~cs10.0.25-1 Severity: serious Control: close -1 1.0.34+~cs10.0.25-2 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:node-websocket has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build 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=node-websocket OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063428: src:iwyu: fails to migrate to testing for too long: waiting for BD clang-17 on mips64el
Source: iwyu Version: 8.18-2 Severity: serious Control: close -1 8.21-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:iwyu has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on several packages that are not available on mips64el. 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=iwyu OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063427: src:nng: fails to migrate to testing for too long: FTBFS on i386, ppc64el and s390x
Source: nng Version: 1.6.0-1 Severity: serious Control: close -1 1.7.2-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:nng has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build on i386, ppc64el and s390x. 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=nng OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063425: src:rust-gdk-pixbuf-sys: fails to migrate to testing for too long: autopkgtest failures
Source: rust-gdk-pixbuf-sys Version: 0.18.0-2 Severity: serious Control: close -1 0.18.0-3 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:rust-gdk-pixbuf-sys has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest as well as triggers other packages to fail theirs. 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=rust-gdk-pixbuf-sys OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063424: nmu: wlgreet_0.4.1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: wlgr...@packages.debian.org, 1061...@bugs.debian.org Control: affects -1 + src:wlgreet nmu wlgreet_0.4.1-3 . ANY . unstable . -m "Rebuild against rust-smithay-client-toolkit 0.16.1" This is needed to fix #1061421 (crash with recent sway versions). This is caused by the same underlying issue as #1061563 in alacritty, it was already fixed via binNMU there.
Bug#1063422: linux-image-6.1.0-18-amd64: F2FS rw mount at boot fails with "invalid zstd compress level: 6"
Control: tags -1 + upstream Control: severity -1 important Hi On Wed, Feb 07, 2024 at 10:43:47PM -0500, Dhya wrote: > Package: src:linux > Version: 6.1.76-1 > Severity: critical > Justification: breaks the whole system > > Dear Maintainer, > > After upgrade to linux-image-6.1.0-18-amd64 6.1.76-1 F2FS filesystem > fails to mount rw. Message in the boot journal: > > kernel: F2FS-fs (nvme0n1p6): invalid zstd compress level: 6 > > There was recently an f2fs patch to the 6.1 kernel tree which might be > related: https://www.spinics.net/lists/stable-commits/msg329957.html > > Was able to recover the system by doing: > > sudo mount -o > remount,rw,relatime,lazytime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,checkpoint_merge,fsync_mode=posix,compress_algorithm=lz4,compress_log_size=2,compress_mode=fs,atgc,discard_unit=block,memory=normal > /dev/nvme0n1p6 / > > under the running bad 6.1.0-18-amd64 kernel, then editing > /etc/default/grub: > > GRUB_DEFAULT="Advanced options for Debian GNU/Linux>Debian GNU/Linux, with > Linux 6.1.0-17-amd64" > > and running 'update-grub' and rebooting to boot the 6.1.0-17-amd64 > kernel. Thanks for the report. Can you please report your finding upstream and keep this downstream report in the loop as well please? Regards, Salvatore
Bug#1063423: obfs4proxy: adopt lyrebird to provide future obfs4proxy
Package: obfs4proxy Version: 0.0.14-1+b7 Severity: wishlist Dear Maintainer, The original obfs4proxy at https://git.torproject.org/pluggable-transports/obfs4.git and https://gitlab.com/yawning/obfs4 has ceased development, but The Tor Project has forked it, and renamed it to lyrebird at https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird . Could we adopt lyrebird, and make it "Replaces" and "Provides" obfs4proxy in the APT repository? -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (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 obfs4proxy depends on: ii libc6 2.37-15~deb13u1 obfs4proxy recommends no packages. obfs4proxy suggests no packages. -- no debconf information
Bug#1061783: Sorry, I ment pyrlp (Was: apprise fails its autopkg tests with Python 3.12)
Hi Ben, sorry for pointing at the wrong package. I intended to write pyrlp (while apprise was in my cut-n-paste buffer.) Please read the text below with s/apprise/pyrlp/ in mind. The bug in question is #1056442. Kind regards and thank you for your quick response anyway Andreas. Am Thu, Feb 08, 2024 at 09:17:17AM +1100 schrieb Ben Finney: > Howdy Andreas, > > On 07-Feb-2024, Andreas Tille wrote: > > Hi Ben, > > > > I noticed that apprise version 0.5.1-4 has a bug since its autopkgtest > > fails with Python3.12. I'd happily fix packages in Debian Python Team > > but your package is not team maintained. Do you have any reason for > > this? > > The package metadata for ‘apprise’ tells me its maintainer is: > > Maintainer: Debian Python Team > > http://deb.debian.org/debian/pool/main/a/apprise/apprise_1.7.2-1.dsc> > > so I think you might have the information mixed up? You are talking about > “version 0.5.1-4”, so maybe you are referring to a different package? > > -- > \ “Speech is human, silence is divine, yet also brutish and dead: | > `\ therefore we must learn both arts.” —Thomas Carlyle, 1830 | > _o__) | > Ben Finney -- http://fam-tille.de
Bug#1044079: [Help] augur: FTBFS with pandas 2.0
Control: tags -1 help Hi Rebecca, Étienne has forwarded the issue long ago but it seems upstream does not want to move to Pandas 2.x[1] and simply closed the issue. Since I do not see any good reason that we maintain two versions of Pandas I need to ask for some help in this issue. Kind regards Andreas. [1] https://github.com/nextstrain/augur/issues/1303 -- http://fam-tille.de
Bug#827171: [uptime] show container uptime
On Mon, 13 Jun 2016 at 20:09, Daniel Baumann < daniel.baum...@progress-technologies.com> wrote: > when using 'uptime' in containers (regardless what kind of containers), > it shows the uptime of the host system rather than the one of the > container. > > What we used locally here is to look at /dev/pts: > ps -o etimes 1 will do it too The upstream libproc2 now has a feature of providing container uptime and both w and uptime have the option either as a command line or environment variable. - Craig
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
06.02.2024 12:34, Helmut Grohne: ... An option I see here is to provide ABI-duality for libselinux: -extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file); +typedef unsigned long libselinux_ino_t; +typedef uint64_t libselinux_ino64_t; +extern int matchpathcon_filespec_add(libselinux_ino_t ino, int specind, const char *file); +#if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 && sizeof(unsigned long) < 8 It's good for a sketch to show an idea but it wont work in practice, - you can't use sizeof(foo) in a preprocessor condition. That's what WORDSIZE #defines are for. But it's a minor nit. glibc already has all the support for LFS which can be used directly, by copying code from any glibc header, like eg for lseek definition... +extern int matchpathcon_filespec_add64(libselinux_ino64_t ino, int specind, const char *file); +#define matchpathcon_filespec_add matchpathcon_filespec_add64 and keeping this #define here instead of using internal in-glibc symbol redirection stuff. And ofc we need to define the compat wrapper for matchpathcon_filespec_add to the source, and the new 64bit symbol to libselinux.map, with the same arch-specific condition. /mjt
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
07.02.2024 11:06, Helmut Grohne :
..
pam seems difficult:
| extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
| extern time_t pam_misc_conv_die_time; /* cut-off time for input */
Attached is a sketch to make pam compatible.
I had a more complete and *tested* fix 2 days ago but I forgot
it was in /tmp and I rebooted the machine, so had to do it again
yesterday.
The idea is to have both die_time and die_time64, and keep them
in sync (using minimum between two values which is !=0).
This is a sketch using a #define, though better is to use symbol
versioning here and have time32 compat stuff for old programs
and 64bit time stuff for new, using redirection at the link time,
instead of the #defines which makes whole thing rather difficult
to read, - that's extra several lines of code, also to the .map
file.
What the whole thing needs is the criteria to use to enable the
trick. Right now I used #ifdef NEED_TIME64_COMPAT which should
be defined somehow, - since I don't know the precise list of
architectures where this has to be done. This is an externally-
controlled thing, there's no way to determine this directly from
the .c code (short of using architecture list in the .h file),
so it must be some symbol substituted at the package build time,
like Provides: t64:Compat (or whatever it is) is substituted in
d/control.
This is a less-intrusve-to-original-code version of the sketch,
ie, I tried to keep all changes outside of the original code as
possible, keeping all the original logic as it is.
/mjtdiff --git a/libpam_misc/include/security/pam_misc.h b/libpam_misc/include/security/pam_misc.h
index fca2422..922341c 100644
--- a/libpam_misc/include/security/pam_misc.h
+++ b/libpam_misc/include/security/pam_misc.h
@@ -21,6 +21,15 @@ extern int misc_conv(int num_msg, const struct pam_message **msgm,
#include
+#if NEED_TIME64_COMPAT
+
+extern time32_t pam_misc_conv_warn_time;
+extern time32_t pam_misc_conv_die_time;
+#define pam_misc_conv_warn_time pam_misc_conv_warn_time64
+#define pam_misc_conv_die_time pam_misc_conv_die_time64
+
+#endif
+
extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
extern time_t pam_misc_conv_die_time; /* cut-off time for input */
extern const char *pam_misc_conv_warn_line; /* warning notice */
diff --git a/libpam_misc/misc_conv.c b/libpam_misc/misc_conv.c
index 908ee89..a02d491 100644
--- a/libpam_misc/misc_conv.c
+++ b/libpam_misc/misc_conv.c
@@ -30,6 +30,9 @@
time_t pam_misc_conv_warn_time = 0; /* time when we warn */
time_t pam_misc_conv_die_time = 0; /* time when we timeout */
+static void fixup_compat_time();
+static void reset_warn_time();
+
const char *pam_misc_conv_warn_line = N_("...Time is running out...\n");
const char *pam_misc_conv_die_line = N_("...Sorry, your time is up!\n");
@@ -96,6 +99,8 @@ static int get_delay(void)
expired = 0;/* reset flag */
(void) time();
+fixup_compat_time();
+
/* has the quit time past? */
if (pam_misc_conv_die_time && now >= pam_misc_conv_die_time) {
fprintf(stderr,"%s",pam_misc_conv_die_line);
@@ -107,7 +112,7 @@ static int get_delay(void)
/* has the warning time past? */
if (pam_misc_conv_warn_time && now >= pam_misc_conv_warn_time) {
fprintf(stderr, "%s", pam_misc_conv_warn_line);
- pam_misc_conv_warn_time = 0;/* reset warn_time */
+ reset_warn_time();
/* indicate remaining delay - if any */
@@ -399,3 +404,36 @@ failed_conversation:
return PAM_CONV_ERR;
}
+
+#ifdef NEED_TIME64_COMPAT
+
+#undef pam_misc_conv_warn_time
+#undef pam_misc_conv_die_time
+
+int pam_misc_conv_warn_time, pam_misc_conv_die_time;
+
+/* in compat 32/64 case, we have 2 values: time and time64.
+ We perform all operations with time64
+ But we try to keep them in sync, whiciever is smaller but !0 */
+#define fixup(t, t32) \
+if (t32 && (!t || t > t32)) t = t32; /* if t32 fires sooner */ \
+if (t < 0x7fff) t32 = t /* only if t can fit in t32 */
+
+static void fixup_compat_time() {
+fixup(pam_misc_conv_warn_time64, pam_misc_conv_warn_time);
+fixup(pam_misc_conv_die_time64, pam_misc_conv_die_time);
+}
+static void reset_warn_time() {
+ pam_misc_conv_warn_time = 0;
+ pam_misc_conv_warn_time64 = 0;
+}
+
+#else
+
+static void fixup_compat_time() {
+}
+static void reset_warn_time() {
+ pam_misc_conv_warn_time = 0;
+}
+
+#endif
Bug#1063422: mount options
Under the 6.1.0-17-amd64 kernel the mount command reports: /dev/nvme0n1p6 on / type f2fs (rw,relatime,lazytime,background_gc=on,gc_merge,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,checkpoint_merge,fsync_mode=posix,compress_algorithm=zstd:6,compress_log_size=2,compress_chksum,compress_mode=fs,atgc,discard_unit=block,memory=normal)
Bug#1063422: fstab
fstab entry: UUID=xxx/f2fs compress_algorithm=zstd:6,compress_chksum,atgc,gc_merge,lazytime 0 1 Allowable levels for zstd compression are 1-22: https://docs.kernel.org/filesystems/f2fs.html
Bug#1063422: linux-image-6.1.0-18-amd64: F2FS rw mount at boot fails with "invalid zstd compress level: 6"
Package: src:linux Version: 6.1.76-1 Severity: critical Justification: breaks the whole system Dear Maintainer, After upgrade to linux-image-6.1.0-18-amd64 6.1.76-1 F2FS filesystem fails to mount rw. Message in the boot journal: kernel: F2FS-fs (nvme0n1p6): invalid zstd compress level: 6 There was recently an f2fs patch to the 6.1 kernel tree which might be related: https://www.spinics.net/lists/stable-commits/msg329957.html Was able to recover the system by doing: sudo mount -o remount,rw,relatime,lazytime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,checkpoint_merge,fsync_mode=posix,compress_algorithm=lz4,compress_log_size=2,compress_mode=fs,atgc,discard_unit=block,memory=normal /dev/nvme0n1p6 / under the running bad 6.1.0-18-amd64 kernel, then editing /etc/default/grub: GRUB_DEFAULT="Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 6.1.0-17-amd64" and running 'update-grub' and rebooting to boot the 6.1.0-17-amd64 kernel. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Dell Inc. product_name: Wyse 7040 product_version: chassis_vendor: Dell Inc. chassis_version: bios_vendor: Dell Inc. bios_version: 1.20.0 board_vendor: Dell Inc. board_name: 0080PM board_version: A00 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:191f] (rev 07) Subsystem: Dell Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [1028:0727] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: skl_uncore Kernel modules: ie31200_edac 00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 07) (prog-if 00 [Normal decode]) Subsystem: Dell 6th-10th Gen Core Processor PCIe Controller (x16) [1028:0727] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Dell HD Graphics 530 [1028:0727] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:14.0 USB controller [0c03]: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI]) Subsystem: Dell 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller [1028:0727] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:14.2 Signal processing controller [1180]: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem [8086:a131] (rev 31) Subsystem: Dell 100 Series/C230 Series Chipset Family Thermal Subsystem [1028:0727] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: intel_pch_thermal Kernel modules: intel_pch_thermal 00:16.0 Communication controller [0780]: Intel Corporation 100 Series/C230 Series Chipset Family MEI Controller #1 [8086:a13a] (rev 31) Subsystem: Dell 100 Series/C230 Series Chipset Family MEI Controller [1028:0727] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me Kernel modules: mei_me 00:16.3 Serial controller [0700]: Intel Corporation 100 Series/C230 Series Chipset Family KT Redirection [8086:a13d] (rev 31) (prog-if 02 [16550]) Subsystem: Dell 100 Series/C230 Series Chipset Family KT Redirection [1028:0727] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: serial 00:17.0 SATA controller [0106]: Intel Corporation
Bug#1063421: Debian versions don't correspond to upstream versions
Package: gopls Version: 1:0.16.1+ds-1 Severity: wishlist Hi, It would appear that the versions of the gopls package version do not correspond to upstream versions. At the time of writing, the versions in Debian are * unstable: 1:0.17.0+ds-1 * testing: 1:0.16.1+ds-1 On the other hand, the latest upstream version of gopls is currently 0.14.2. It turns out that the upstream repository (tools) has two sets of tags: tags of the form "v0.17.0" are versions of the repository itself, while tags of the form "gopls/v0.14.2" are versions of the gopls tool. It would appear that Debian is using the repository tags rather than the gopls tags. If that is intentional, please document it in a README.Debian file. If that is not intentional, please consider switching to gopls releases. Thanks, -- Juliusz
Bug#1062678: (no subject)
The firmware is only used on mobile APUs (which contain graphics). So if needing to pick an existing binary package instead of a new one I can see a stronger argument to bundle it with the graphics package.
Bug#1063161: Processed: Re: Bug#1063161: Add amd_pmf module
Yes, please set CONFIG_AMDTEE and CONFIG_AMD_PMF both. The firmware is optional, certain functions for amd-pmf will be non-functional without it.
Bug#1063420: Working work around
A working work around in Debian is the following: media.encoder.webm.enabled true media.ffmpeg.encoder.enabled true media.webrtc.platformencoder true media.webrtc.platformencoder.sw_only false media.webrtc.software_encoder.fallback true from here: https://bugzilla.mozilla.org/show_bug.cgi?id=1875201 -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc https://keys.openpgp.org/vks/v1/by-fingerprint/A1306C5094B5E31B7721A3A66F4844C7CA7501AA mir datanom net https://keys.openpgp.org/vks/v1/by-fingerprint/0C14CD9479667E848770C8F98417B6C5E1BB093F mir miras org https://keys.openpgp.org/vks/v1/by-fingerprint/5F71405B571CB8EE2A414A4FC77C11E049A06E66 -- 'During times of universal deceit, telling the truth becomes a revolutionary act.' -George Orwell /usr/games/fortune -es says: Paul Revere was a tattle-tale. pgpD2xaq_Ljgh.pgp Description: OpenPGP digital signature
Bug#1063161: Add amd_pmf module
Control: tag -1 moreinfo On Monday, 5 February 2024 15:47:08 CET Nate wrote: > Would be possible to compile it as a module in the kernel ? > There may be technical limitations that I am not aware of. The kernel module depends on AMDTEE (Trusted Execution Environment) and I'm not sure if you'd need amdtee firmware for that. In https://bugs.debian.org/1062678 I requested that, but that is about AMD PMF TA (Trusted Application) and that *could* be something else. signature.asc Description: This is a digitally signed message part.
Bug#1063420: firefox: No video in jitsi
Package: firefox Version: 122.0.1-1 Severity: important Dear Maintainer, The package version in Debian is broken. Connecting to a jitsi meeting does not transfer video to other participants but only sound since jitsi is not able to find any video codecs despite codecs are available. Using the exact same version from mozilla's repository works as intended: 122.0.1~build1 1000 1000 https://packages.mozilla.org/apt mozilla/main amd64 Packages More info can be found here: https://github.com/jitsi/lib-jitsi-meet/pull/2394 where jitsi developers are available. My info here was from yesterday with Firefox 122.0 but todays update to 122.0.1 does not make any changes. -- Package-specific info: -- Addons package information -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'unstable-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox depends on: ii debianutils 5.16 ii fontconfig 2.14.2-6+b1 ii libasound2 1.2.10-3 ii libatk1.0-0 2.50.0-1+b1 ii libc62.37-15 ii libcairo-gobject21.18.0-1+b1 ii libcairo21.18.0-1+b1 ii libdbus-1-3 1.14.10-4 ii libevent-2.1-7 2.1.12-stable-8 ii libffi8 3.4.4-2 ii libfontconfig1 2.14.2-6+b1 ii libfreetype6 2.13.2+dfsg-1+b1 ii libgcc-s114-20240201-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3 ii libglib2.0-0 2.78.3-2 ii libgtk-3-0 3.24.41-1 ii libnspr4 2:4.35-1.1 ii libnss3 2:3.96.1-1 ii libpango-1.0-0 1.51.0+ds-4 ii libstdc++6 14-20240201-3 ii libvpx8 1.13.1-2 ii libx11-6 2:1.8.7-1 ii libx11-xcb1 2:1.8.7-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxrandr2 2:1.5.2-2+b1 ii procps 2:4.0.4-4 ii zlib1g 1:1.3.dfsg-3+b1 Versions of packages firefox recommends: ii libavcodec-extra57 7:3.4.3-1 ii libavcodec587:4.4.2-1+b3 ii libavcodec607:6.1.1-1 Versions of packages firefox suggests: ii fonts-lmodern 2.005-1 pn fonts-stix | otf-stix ii libcanberra0 0.30-11 ii libgssapi-krb5-2 1.20.1-5 pn pulseaudio -- no debconf information This mail was virus scanned and spam checked before delivery. This mail is also DKIM signed. See header dkim-signature.
Bug#1063206: papi: NMU diff for 64-bit time_t transition
On 05/02/2024 20.32, Andreas Beckmann wrote: Please don't upload to unstable, yet, until I've checked it in more detail (and maybe fixed it in experimental). Yes, there is a wrong dependency: │ │ │ │ Package: libpapi-dev │ │ │ │ Source: papi │ │ │ │ Version: 7.1.0-2.1~exp1 │ │ │ │ Architecture: amd64 │ │ │ │ Maintainer: Debian HPC Team │ │ │ │ Installed-Size: 1293 │ │ │ │ -Depends: libpapi7.1 (= 7.1.0-2.1~exp1), libsde1t64 (= 7.1.0-2.1~exp1) │ │ │ │ +Depends: libpapi7.1t64 (= 7.1.0-2.1~exp1), libsde1t64 (= 7.1.0-2.1~exp1) │ │ │ │ Section: libdevel │ │ │ │ Priority: optional │ │ │ │ Multi-Arch: same │ │ │ │ Homepage: https://icl.utk.edu/papi/ │ │ │ │ Description: PAPI development files (headers and API documentation) Preparing a fix ... Andreas
Bug#1063210: pari: NMU diff for 64-bit time_t transition
On Mon, Feb 05, 2024 at 02:43:30PM -0300, Lucas Kanashiro wrote: > Source: pari > Version: 2.15.4-2 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > pari as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for pari > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. Have you actually checked that pari will really be build with the relevant flags ? If there is a new ABI, then one should take the opportunity to remove CFLAGS_i386 := -mpc64 There is no need for a lintian override, this is a well-known lintian bug... Cheers, Bill
Bug#1063419: sugar-artwork: Please package version 0.121 needed by sugar-session
Source: sugar-artwork Version: 0.120-2 Severity: serious Control: affects -1 src:sugar X-Debbugs-CC: d...@jones.dk sugar-session in Unstable depends on sugar-themes (>= 0.121) but that version is not available in Unstable yet. Thank you, Jeremy Bícha
Bug#1063418: mdp ftbfs in unstable
Package: src:mdp
Version: 3.6-6
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12
tests fail with both Python 3.11 and 3.12.
Also with 3.12:
mdp/test/test_reload.py:4
/<>/mdp/test/test_reload.py:4: DeprecationWarning: the
imp module is deprecated in favour of importlib and slated for removal
in Python 3.12; see the module's documentation for alternative uses
from imp import reload
[...]
=== short test summary info
FAILED mdp/test/test_hinet_generic.py::test_dtype_consistency[FlowNode]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[SFA2Node]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[FDANode] -
Type...
FAILED
mdp/test/test_nodes_generic.py::test_dtype_consistency[GaussianClassifier]
FAILED
mdp/test/test_nodes_generic.py::test_dtype_consistency[LinearRegressionNode]
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[JADENode]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[XSFANode]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[iGSFANode]
- Ty...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[LLENode] -
Type...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[HLLENode]
- Typ...
FAILED
mdp/test/test_nodes_generic.py::test_dtype_consistency[CuBICANode] - T...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[FANode] -
TypeE...
FAILED
mdp/test/test_nodes_generic.py::test_dtype_consistency[FastICANode] - ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[GSFANode]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[ISFANode]
- Typ...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[PCANode] -
Type...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[SFANode] -
Type...
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[TDSEPNode]
- Ty...
FAILED
mdp/test/test_nodes_generic.py::test_dtype_consistency[VartimeSFANode]
FAILED mdp/test/test_nodes_generic.py::test_dtype_consistency[WhiteningNode]
== 20 failed, 823 passed, 16 skipped, 3 warnings in 158.17s
(0:02:38) ==
E: pybuild pybuild:391: test: plugin custom failed with: exit code=1:
python3.11 -m pytest --seed=725021957 mdp && python3.11 -m pytest
--seed=725021957 bimdp
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p
"3.12 3.11" returned exit code 13
Bug#1061783: apprise fails its autopkg tests with Python 3.12
Howdy Andreas, On 07-Feb-2024, Andreas Tille wrote: > Hi Ben, > > I noticed that apprise version 0.5.1-4 has a bug since its autopkgtest > fails with Python3.12. I'd happily fix packages in Debian Python Team > but your package is not team maintained. Do you have any reason for > this? The package metadata for ‘apprise’ tells me its maintainer is: Maintainer: Debian Python Team http://deb.debian.org/debian/pool/main/a/apprise/apprise_1.7.2-1.dsc> so I think you might have the information mixed up? You are talking about “version 0.5.1-4”, so maybe you are referring to a different package? -- \ “Speech is human, silence is divine, yet also brutish and dead: | `\ therefore we must learn both arts.” —Thomas Carlyle, 1830 | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file
Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca : > Dumping the encoded keymaps for pc105... > WARNING: Can not find "caps_switch" in "group". > WARNING: Can not find "caps_toggle" in "group". > gzip -9n >/Keyboard/pc105.ekbd > >/<>/Keyboard/pc105.ekbd.gz > /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such file > make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] Error 2 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:204: udeb-install] Error 2 > >Version 1.223 builds fine in unstable instead. Perhaps this is related >to the fact that 1.224 dropped the binary package console-setup-pc-ekbd? What makes you think, that this has happened? There is a merge request that includes the removal of said package, but it has not yet been merged. Holger -- Sent from /e/ OS on Fairphone3
Bug#1041858: ITP: tundra-nat64 -- A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux
noowner 1041858 thanks I've decided to focus on upstreaming a kernel based SIIT/NAT64 solution instead of packaging tundra. Initial packaging work is here if anyone wants to continue this anyhow: https://salsa.debian.org/dxld/tundra-nat64 Upstream issue asking for tagging release https://github.com/vitlabuda/tundra-nat64/issues/1 Patches: https://github.com/vitlabuda/tundra-nat64/pull/2 - adding a Makefile https://github.com/vitlabuda/tundra-nat64/pull/4 - hardening --Daniel signature.asc Description: PGP signature
Bug#1063368: kate: Shift-key not working
Hej, Am Mittwoch, 7. Februar 2024, 03:18:49 CET schrieb Dominik Huber: [...] > I've tried everything I know in trying to narrow the problem down, so > if you have any suggestions/questions I'd be happy to try/answer > them. 1.) Does the problem also occur with a new user on your native system ? 2.) You said that the problem also occurs with other applications. That points to that it's not a Kate problem but rather that the problem lies deeper in your system. What went wrong during your upgrade, one can only guess. Maybe, you can widen your search and see if others have the same problem. Don't limit yourself to Kate or Debian in that case. That's all I can recommend. -- Med vänliga hälsningar Patrick Franz
Bug#1063338: [regression 6.1.76] dlm: cannot start dlm midcomms -97 after backport of e9cdebbe23f1 ("dlm: use kernel_connect() and kernel_bind()")
Hi Alexander,
On Wed, Feb 07, 2024 at 04:27:48PM -0500, Alexander Aring wrote:
> Hi,
>
> On Wed, Feb 7, 2024 at 1:33 PM Jordan Rife wrote:
> >
> > On Wed, Feb 7, 2024 at 2:39 AM Salvatore Bonaccorso
> > wrote:
> > >
> > > Hi Valentin, hi all
> > >
> > > [This is about a regression reported in Debian for 6.1.67]
> > >
> > > On Tue, Feb 06, 2024 at 01:00:11PM +0100, Valentin Kleibel wrote:
> > > > Package: linux-image-amd64
> > > > Version: 6.1.76+1
> > > > Source: linux
> > > > Source-Version: 6.1.76+1
> > > > Severity: important
> > > > Control: notfound -1 6.6.15-2
> > > >
> > > > Dear Maintainers,
> > > >
> > > > We discovered a bug affecting dlm that prevents any tcp communications
> > > > by
> > > > dlm when booted with debian kernel 6.1.76-1.
> > > >
> > > > Dlm startup works (corosync-cpgtool shows the dlm:controld group with
> > > > all
> > > > expected nodes) but as soon as we try to add a lockspace dmesg shows:
> > > > ```
> > > > dlm: Using TCP for communications
> > > > dlm: cannot start dlm midcomms -97
> > > > ```
> > > >
> > > > It seems that commit "dlm: use kernel_connect() and kernel_bind()"
> > > > (e9cdebbe) was merged to 6.1.
> > > >
> > > > Checking the code it seems that the changed function
> > > > dlm_tcp_listen_bind()
> > > > fails with exit code 97 (EAFNOSUPPORT)
> > > > It is called from
> > > >
> > > > dlm/lockspace.c: threads_start() -> dlm_midcomms_start()
> > > > dlm/midcomms.c: dlm_midcomms_start() -> dlm_lowcomms_start()
> > > > dlm/lowcomms.c: dlm_lowcomms_start() -> dlm_listen_for_all() ->
> > > > dlm_proto_ops->listen_bind() = dlm_tcp_listen_bind()
> > > >
> > > > The error code is returned all the way to threads_start() where the
> > > > error
> > > > message is emmitted.
> > > >
> > > > Booting with the unsigned kernel from testing (6.6.15-2), which also
> > > > contains this commit, works without issues.
> > > >
> > > > I'm not sure what additional changes are required to get this working
> > > > or if
> > > > rolling back this change is an option.
> > > >
> > > > We'd be happy to test patches that might fix this issue.
> > >
> > > Thanks for your report. So we have a 6.1.76 specific regression for
> > > the backport of e9cdebbe23f1 ("dlm: use kernel_connect() and
> > > kernel_bind()") .
> > >
> > > Let's loop in the upstream regression list for tracking and people
> > > involved for the subsystem to see if the issue can be identified. As
> > > it is working for 6.6.15 which includes the commit backport as well it
> > > might be very well that a prerequisite is missing.
> > >
> > > # annotate regression with 6.1.y specific commit
> > > #regzbot ^introduced e11dea8f503341507018b60906c4a9e7332f3663
> > > #regzbot link: https://bugs.debian.org/1063338
> > >
> > > Any ideas?
> > >
> > > Regards,
> > > Salvatore
> >
> >
> > Just a quick look comparing dlm_tcp_listen_bind between the latest 6.1
> > and 6.6 stable branches,
> > it looks like there is a mismatch here with the dlm_local_addr[0] parameter.
> >
> > 6.1
> >
> >
> > static int dlm_tcp_listen_bind(struct socket *sock)
> > {
> > int addr_len;
> >
> > /* Bind to our port */
> > make_sockaddr(dlm_local_addr[0], dlm_config.ci_tcp_port, _len);
> > return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
> >addr_len);
> > }
> >
> > 6.6
> >
> > static int dlm_tcp_listen_bind(struct socket *sock)
> > {
> > int addr_len;
> >
> > /* Bind to our port */
> > make_sockaddr(_local_addr[0], dlm_config.ci_tcp_port, _len);
> > return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
> >addr_len);
> > }
> >
> > 6.6 contains commit c51c9cd8 (fs: dlm: don't put dlm_local_addrs on heap)
> > which
> > changed
> >
> > static struct sockaddr_storage *dlm_local_addr[DLM_MAX_ADDR_COUNT];
> >
> > to
> >
> > static struct sockaddr_storage dlm_local_addr[DLM_MAX_ADDR_COUNT];
> >
> > It looks like kernel_bind() in 6.1 needs to be modified to match.
> >
>
> makes sense. I tried to cherry-pick e9cdebbe23f1 ("dlm: use
> kernel_connect() and kernel_bind()") on v6.1.67 as I don't see it
> there. It failed and does not apply cleanly.
>
> Are we talking here about a debian kernel specific backport? If so,
> maybe somebody missed to modify those parts you mentioned.
Thanks all for looking into it.
No it's not a Debian specific backport, e9cdebbe23f1 ("dlm: use
kernel_connect() and kernel_bind()") got in fact backported upstream
in 6.1.76, 6.6.15 and 6.7.3. The respective commits are:
v6.1.76: e11dea8f503341507018b60906c4a9e7332f3663 dlm: use kernel_connect() and
kernel_bind()
v6.6.15: c018ab3e31b16ff97b9b95b69904104c9fcca95b dlm: use kernel_connect() and
kernel_bind()
v6.7.3: 4ecf1864f2076872b7aea29d463e785ef6fc9909 dlm: use kernel_connect() and
kernel_bind()
v6.8-rc1: e9cdebbe23f1aa9a1caea169862f479ab3fa2773 dlm: use kernel_connect()
and kernel_bind()
But for the 6.1.76 case there is the above regression (while it works
for 6.6.15 as confirmed by the reporter).
I'm very sorry I see where I have caused you
Bug#1063410: ros-bloom's autopkg tests fail with Python 3.12
Control: tag -1 moreinfo Hi Matthias, * Matthias Klose [2024-02-07 20:55]: Package: src:ros-bloom Version: 0.11.2-6 Severity: important Tags: sid trixie ftbfs User: debian-pyt...@lists.debian.org Usertags: python3.12 ros-bloom's autopkg tests fail with Python 3.12 [...] 578s /usr/lib/python3/dist-packages/rosdistro/distribution.py:35: in 578s from .manifest_provider.git import git_manifest_provider, git_source_manifest_provider 578s /usr/lib/python3/dist-packages/rosdistro/manifest_provider/git.py:44: in 578s from rosdistro.vcs import Git, ref_is_hash 578s /usr/lib/python3/dist-packages/rosdistro/vcs.py:39: in 578s from distutils.version import LooseVersion 578s E ModuleNotFoundError: No module named 'distutils' This looks like the same as #1061840 and was already fixed in ros-bloom and ros-rosdistro. Can you please retry with the versions in testing? I can't reproduce this and debci is also all green. Cheers Jochen signature.asc Description: PGP signature
Bug#1063338: [regression 6.1.67] dlm: cannot start dlm midcomms -97 after backport of e9cdebbe23f1 ("dlm: use kernel_connect() and kernel_bind()")
Hi,
On Wed, Feb 7, 2024 at 1:33 PM Jordan Rife wrote:
>
> On Wed, Feb 7, 2024 at 2:39 AM Salvatore Bonaccorso wrote:
> >
> > Hi Valentin, hi all
> >
> > [This is about a regression reported in Debian for 6.1.67]
> >
> > On Tue, Feb 06, 2024 at 01:00:11PM +0100, Valentin Kleibel wrote:
> > > Package: linux-image-amd64
> > > Version: 6.1.76+1
> > > Source: linux
> > > Source-Version: 6.1.76+1
> > > Severity: important
> > > Control: notfound -1 6.6.15-2
> > >
> > > Dear Maintainers,
> > >
> > > We discovered a bug affecting dlm that prevents any tcp communications by
> > > dlm when booted with debian kernel 6.1.76-1.
> > >
> > > Dlm startup works (corosync-cpgtool shows the dlm:controld group with all
> > > expected nodes) but as soon as we try to add a lockspace dmesg shows:
> > > ```
> > > dlm: Using TCP for communications
> > > dlm: cannot start dlm midcomms -97
> > > ```
> > >
> > > It seems that commit "dlm: use kernel_connect() and kernel_bind()"
> > > (e9cdebbe) was merged to 6.1.
> > >
> > > Checking the code it seems that the changed function dlm_tcp_listen_bind()
> > > fails with exit code 97 (EAFNOSUPPORT)
> > > It is called from
> > >
> > > dlm/lockspace.c: threads_start() -> dlm_midcomms_start()
> > > dlm/midcomms.c: dlm_midcomms_start() -> dlm_lowcomms_start()
> > > dlm/lowcomms.c: dlm_lowcomms_start() -> dlm_listen_for_all() ->
> > > dlm_proto_ops->listen_bind() = dlm_tcp_listen_bind()
> > >
> > > The error code is returned all the way to threads_start() where the error
> > > message is emmitted.
> > >
> > > Booting with the unsigned kernel from testing (6.6.15-2), which also
> > > contains this commit, works without issues.
> > >
> > > I'm not sure what additional changes are required to get this working or
> > > if
> > > rolling back this change is an option.
> > >
> > > We'd be happy to test patches that might fix this issue.
> >
> > Thanks for your report. So we have a 6.1.76 specific regression for
> > the backport of e9cdebbe23f1 ("dlm: use kernel_connect() and
> > kernel_bind()") .
> >
> > Let's loop in the upstream regression list for tracking and people
> > involved for the subsystem to see if the issue can be identified. As
> > it is working for 6.6.15 which includes the commit backport as well it
> > might be very well that a prerequisite is missing.
> >
> > # annotate regression with 6.1.y specific commit
> > #regzbot ^introduced e11dea8f503341507018b60906c4a9e7332f3663
> > #regzbot link: https://bugs.debian.org/1063338
> >
> > Any ideas?
> >
> > Regards,
> > Salvatore
>
>
> Just a quick look comparing dlm_tcp_listen_bind between the latest 6.1
> and 6.6 stable branches,
> it looks like there is a mismatch here with the dlm_local_addr[0] parameter.
>
> 6.1
>
>
> static int dlm_tcp_listen_bind(struct socket *sock)
> {
> int addr_len;
>
> /* Bind to our port */
> make_sockaddr(dlm_local_addr[0], dlm_config.ci_tcp_port, _len);
> return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
>addr_len);
> }
>
> 6.6
>
> static int dlm_tcp_listen_bind(struct socket *sock)
> {
> int addr_len;
>
> /* Bind to our port */
> make_sockaddr(_local_addr[0], dlm_config.ci_tcp_port, _len);
> return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
>addr_len);
> }
>
> 6.6 contains commit c51c9cd8 (fs: dlm: don't put dlm_local_addrs on heap)
> which
> changed
>
> static struct sockaddr_storage *dlm_local_addr[DLM_MAX_ADDR_COUNT];
>
> to
>
> static struct sockaddr_storage dlm_local_addr[DLM_MAX_ADDR_COUNT];
>
> It looks like kernel_bind() in 6.1 needs to be modified to match.
>
makes sense. I tried to cherry-pick e9cdebbe23f1 ("dlm: use
kernel_connect() and kernel_bind()") on v6.1.67 as I don't see it
there. It failed and does not apply cleanly.
Are we talking here about a debian kernel specific backport? If so,
maybe somebody missed to modify those parts you mentioned.
- Alex
Bug#1063416: libgit2: CVE-2024-24577: Arbitrary code execution due to heap corruption in `git_index_add`
Source: libgit2 Version: 1.7.1+ds-2 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Control: found -1 1.5.1+ds-1 Control: found -1 1.1.0+dfsg.1-4+deb11u1 Control: found -1 1.1.0+dfsg.1-4 Hi, The following vulnerability was published for libgit2. CVE-2024-24577[0]: | libgit2 is a portable C implementation of the Git core methods | provided as a linkable library with a solid API, allowing to build | Git functionality into your application. Using well-crafted inputs | to `git_index_add` can cause heap corruption that could be leveraged | for arbitrary code execution. There is an issue in the | `has_dir_name` function in `src/libgit2/index.c`, which frees an | entry that should not be freed. The freed entry is later used and | overwritten with potentially bad actor-controlled data leading to | controlled heap corruption. Depending on the application that uses | libgit2, this could lead to arbitrary code execution. This issue has | been patched in version 1.6.5 and 1.7.2. 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-2024-24577 https://www.cve.org/CVERecord?id=CVE-2024-24577 [1] https://github.com/libgit2/libgit2/security/advisories/GHSA-j2v7-4f6v-gpg8 [2] https://github.com/libgit2/libgit2/commit/eb4c1716cd92bf56f2770653a915d5fc01eab8f3 [3] https://github.com/libgit2/libgit2/commit/487af0cf6687dc48b0a960fa2f39894e2d84d77b Regards, Salvatore
Bug#1063415: libgit2: CVE-2024-24575: Denial of service attack in `git_revparse_single`
Source: libgit2 Version: 1.7.1+ds-2 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Control: found -1 1.5.1+ds-1 Hi, The following vulnerability was published for libgit2. CVE-2024-24575[0]: | libgit2 is a portable C implementation of the Git core methods | provided as a linkable library with a solid API, allowing to build | Git functionality into your application. Using well-crafted inputs | to `git_revparse_single` can cause the function to enter an infinite | loop, potentially causing a Denial of Service attack in the calling | application. The revparse function in `src/libgit2/revparse.c` uses | a loop to parse the user-provided spec string. There is an edge-case | during parsing that allows a bad actor to force the loop conditions | to access arbitrary memory. Potentially, this could also leak memory | if the extracted rev spec is reflected back to the attacker. As | such, libgit2 versions before 1.4.0 are not affected. Users should | upgrade to version 1.6.5 or 1.7.2. 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-2024-24575 https://www.cve.org/CVERecord?id=CVE-2024-24575 [1] https://github.com/libgit2/libgit2/security/advisories/GHSA-54mf-x2rh-hq9v [2] https://github.com/libgit2/libgit2/commit/c9d31b711e8906cf248566f43142f20b03e20cbf [3] https://github.com/libgit2/libgit2/commit/7f6f3dff9c41f3be7598693aa3c716c8354fba7f Regards, Salvatore
Bug#1063414: openexr: CVE-2023-5841
Source: openexr Version: 3.1.5-5 Severity: important Tags: security upstream Forwarded: https://github.com/AcademySoftwareFoundation/openexr/issues/1625 https://github.com/AcademySoftwareFoundation/openexr/pull/1627 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for openexr. CVE-2023-5841[0]: | Due to a failure in validating the number of scanline samples of a | OpenEXR file containing deep scanline data, Academy Software | Foundation OpenEX image parsing library version 3.2.1 and prior is | susceptible to a heap-based buffer overflow 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-5841 https://www.cve.org/CVERecord?id=CVE-2023-5841 [1] https://takeonme.org/cves/CVE-2023-5841.html [2] https://github.com/AcademySoftwareFoundation/openexr/issues/1625 [3] https://github.com/AcademySoftwareFoundation/openexr/commit/46944c3a87ebc6c5d9a9a4962a94569ba1082bc3 [4] https://github.com/AcademySoftwareFoundation/openexr/pull/1627 Regards, Salvatore -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.11-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file
Source: console-setup Version: 1.224 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: sid trixie ftbfs Dear Maintainer, console-setup 1.224 fails to build from source with the following error: Dumping the encoded keymaps for pc105... WARNING: Can not find "caps_switch" in "group". WARNING: Can not find "caps_toggle" in "group". gzip -9n >/Keyboard/pc105.ekbd >/<>/Keyboard/pc105.ekbd.gz /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such file make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:204: udeb-install] Error 2 Version 1.223 builds fine in unstable instead. Perhaps this is related to the fact that 1.224 dropped the binary package console-setup-pc-ekbd?
Bug#1063407: pybdsf fails to build with Python 3.12 as default
Control: forwarded -1 https://github.com/lofar-astron/PyBDSF/issues/214 While many (or even all) distutils were replaced by a migration to cmake (https://github.com/lofar-astron/PyBDSF/pull/204), the package is still not Python 3.12 compatible, and the solutions seems not trivial. Waiting for upstream here.
Bug#1026224: [patch] live-build: Option "-b netboot" fails on arm64 architecture
Hi!
This simple patch fixes the issue. I tried opening an MR on Salsa but it
seems Salsa has some issues currently (going to the merge request page
after the push leads to an error 500-something).
Cheers,
Thomas Goirand (zigo)
diff --git a/scripts/build/binary_netboot b/scripts/build/binary_netboot
index c88bc6296..d74a118f2 100755
--- a/scripts/build/binary_netboot
+++ b/scripts/build/binary_netboot
@@ -50,6 +50,7 @@ ROOT_DIR=${LB_MODE}-live
mv binary ${ROOT_DIR}
mkdir binary.tmp
+mkdir -p tftpboot
mv ${ROOT_DIR} tftpboot binary.tmp
cd binary.tmp
Bug#1063412: virulencefinder fails autopkg tests with Python 3.12
Package: src:virulencefinder Version: 2.0.4-4 Severity: important Tags: sid trixie ftbfs User: debian-pyt...@lists.debian.org Usertags: python3.12 [...] 692s autopkgtest [16:44:14]: test run-unit-test: [--- 699s Traceback (most recent call last): 699s File "/usr/bin/virulencefinder.py", line 7, in 699s from distutils.spawn import find_executable 699s ModuleNotFoundError: No module named 'distutils' 699s autopkgtest [16:44:21]: test run-unit-test: ---] 700s autopkgtest [16:44:22]: test run-unit-test: - - - - - - - - - - results - - - - - - - - - - 700s run-unit-testFAIL non-zero exit status 1 700s autopkgtest [16:44:22]: summary 700s run-unit-testFAIL non-zero exit status 1
Bug#1063411: spectral-cube fails autopkg tests with Python 3.12
Package: src:spectral-cube Version: 0.6.5-2 Severity: important Tags: sid trixie ftbfs User: debian-pyt...@lists.debian.org Usertags: python3.12 [...] 382s autopkgtest [15:52:48]: test command1: cd $AUTOPKGTEST_TMP && python3 -m pytest --pyargs spectral_cube 382s autopkgtest [15:52:48]: test command1: [--- 387s = test session starts == 387s platform linux -- Python 3.12.1, pytest-7.4.4, pluggy-1.4.0 387s rootdir: /tmp/autopkgtest.e6zDzM/autopkgtest_tmp 387s plugins: hypothesis-6.93.2, arraydiff-0.6.1, astropy-header-0.2.2, cov-4.1.0, doctestplus-1.1.0, filter-subpackage-0.1.2, mock-3.12.0, remotedata-0.4.1, astropy-0.11.0 387s collected 0 items / 1 error 387s 387s ERRORS 387s ERROR collecting test session _ 387s /usr/lib/python3.12/importlib/__init__.py:90: in import_module 387s return _bootstrap._gcd_import(name[level:], package, level) 387s :1387: in _gcd_import 387s ??? 387s :1360: in _find_and_load 387s ??? 387s :1310: in _find_and_load_unlocked 387s ??? 387s :488: in _call_with_frames_removed 387s ??? 387s :1387: in _gcd_import 387s ??? 387s :1360: in _find_and_load 387s ??? 387s :1331: in _find_and_load_unlocked 387s ??? 387s :935: in _load_unlocked 387s ??? 387s :994: in exec_module 387s ??? 387s :488: in _call_with_frames_removed 387s ??? 387s /usr/lib/python3/dist-packages/spectral_cube/__init__.py:5: in 387s from .spectral_cube import (SpectralCube, VaryingResolutionSpectralCube) 387s /usr/lib/python3/dist-packages/spectral_cube/spectral_cube.py:60: in 387s from distutils.version import LooseVersion 387s E ModuleNotFoundError: No module named 'distutils'
Bug#1062259: libcomps: NMU diff for 64-bit time_t transition
On Wed, Feb 07, 2024 at 04:25:17PM +, Luca Boccassi wrote: > Control: tags -1 -pending > Control: close -1 [...] > There are no mentions of 'time_t' in the public headers of this > library. The logs shows that it's a false positive, as the automated > tool simply wasn't able to build it: [...] > Closing as not applicable. thanks for closing this bug and thanks for the t64 transition in the first place! that said, someone needs to request the removal of src:libcomps from experimental now, and if this would only affect src:libcomps I would probably do that myself, but knowing there are several many cases of this: please also request removal of those packages from experimental which were accidently uploaded there! thanks for that too & already! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The past is over. signature.asc Description: PGP signature
Bug#1063410: ros-bloom's autopkg tests fail with Python 3.12
Package: src:ros-bloom
Version: 0.11.2-6
Severity: important
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12
ros-bloom's autopkg tests fail with Python 3.12
[...]
578s = test session starts
==
578s platform linux -- Python 3.12.1, pytest-7.4.4, pluggy-1.3.0
578s rootdir: /tmp/tmp.BgIMXvxH90
578s collected 2 items / 5 errors
578s
578s ERRORS
578s ERROR collecting test/system_tests/test_bloom_setup.py
578s /usr/lib/python3/dist-packages/bloom/rosdistro_api.py:60: in
578s import rosdistro
578s /usr/lib/python3/dist-packages/rosdistro/__init__.py:51: in
578s from .distribution import Distribution # noqa
578s /usr/lib/python3/dist-packages/rosdistro/distribution.py:35: in
578s from .manifest_provider.git import git_manifest_provider,
git_source_manifest_provider
578s
/usr/lib/python3/dist-packages/rosdistro/manifest_provider/git.py:44: in
578s from rosdistro.vcs import Git, ref_is_hash
578s /usr/lib/python3/dist-packages/rosdistro/vcs.py:39: in
578s from distutils.version import LooseVersion
578s E ModuleNotFoundError: No module named 'distutils'
578s
578s During handling of the above exception, another exception occurred:
578s test/system_tests/test_bloom_setup.py:13: in
578s from bloom.config import BLOOM_CONFIG_BRANCH
578s /usr/lib/python3/dist-packages/bloom/config.py:60: in
578s from bloom.rosdistro_api import get_non_eol_distros_prompt
578s /usr/lib/python3/dist-packages/bloom/rosdistro_api.py:67: in
578s error("rosdistro was not detected, please install it.",
file=sys.stderr,
578s /usr/lib/python3/dist-packages/bloom/logging.py:280: in error
578s sys.exit(msg)
578s E SystemExit: [31m[1mrosdistro was not detected, please install
it.[0m
578s __ ERROR collecting
test/system_tests/test_catkin_release.py ___
578s test/system_tests/test_catkin_release.py:12: in
578s from vcstools.vcs_abstraction import get_vcs_client
578s /usr/lib/python3/dist-packages/vcstools/__init__.py:47: in
578s from vcstools.git import GitClient
578s /usr/lib/python3/dist-packages/vcstools/git.py:63: in
578s from distutils.version import LooseVersion
578s E ModuleNotFoundError: No module named 'distutils'
578s
578s During handling of the above exception, another exception occurred:
578s test/system_tests/test_catkin_release.py:15: in
578s sys.exit(1)
578s E SystemExit: 1
578s --- Captured stderr
578s vcstools was not detected, please install it.
578s ___ ERROR collecting test/unit_tests/test_config.py
578s /usr/lib/python3/dist-packages/bloom/rosdistro_api.py:60: in
578s import rosdistro
578s /usr/lib/python3/dist-packages/rosdistro/__init__.py:51: in
578s from .distribution import Distribution # noqa
578s /usr/lib/python3/dist-packages/rosdistro/distribution.py:35: in
578s from .manifest_provider.git import git_manifest_provider,
git_source_manifest_provider
578s
/usr/lib/python3/dist-packages/rosdistro/manifest_provider/git.py:44: in
578s from rosdistro.vcs import Git, ref_is_hash
578s /usr/lib/python3/dist-packages/rosdistro/vcs.py:39: in
578s from distutils.version import LooseVersion
578s E ModuleNotFoundError: No module named 'distutils'
578s
578s During handling of the above exception, another exception occurred:
578s test/unit_tests/test_config.py:6: in
578s from bloom.config import validate_track_versions
578s /usr/lib/python3/dist-packages/bloom/config.py:60: in
578s from bloom.rosdistro_api import get_non_eol_distros_prompt
578s /usr/lib/python3/dist-packages/bloom/rosdistro_api.py:67: in
578s error("rosdistro was not detected, please install it.",
file=sys.stderr,
578s /usr/lib/python3/dist-packages/bloom/logging.py:280: in error
578s sys.exit(msg)
578s E SystemExit: [31m[1mrosdistro was not detected, please install
it.[0m
578s __ ERROR collecting test/unit_tests/test_packages.py
___
578s /usr/lib/python3/dist-packages/bloom/rosdistro_api.py:60: in
578s import rosdistro
578s /usr/lib/python3/dist-packages/rosdistro/__init__.py:51: in
578s from .distribution import Distribution # noqa
578s /usr/lib/python3/dist-packages/rosdistro/distribution.py:35: in
578s from .manifest_provider.git import git_manifest_provider,
git_source_manifest_provider
578s
/usr/lib/python3/dist-packages/rosdistro/manifest_provider/git.py:44: in
578s from rosdistro.vcs import Git, ref_is_hash
578s /usr/lib/python3/dist-packages/rosdistro/vcs.py:39: in
578s from distutils.version import LooseVersion
578s E ModuleNotFoundError: No module named 'distutils'
578s
578s During handling of the above exception, another exception occurred:
578s
Bug#1062805: RFS ping
Gently pinging about this upload. It fixes #1061792 which seems to impact the workflow of some users. Also, it fixes a logical error in the systemd service which is guaranteed to be present in all versions > 1.30.3. Kinds regards, Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1061813: add patch
Control: tags -1 + patch patch at http://launchpadlibrarian.net/713303806/mpi4py_3.1.5-4_3.1.5-4ubuntu1.diff.gz
Bug#1063409: mpi4py accesses the net for the build
Package: src:mpi4py
Version: 3.1.5-4
Severity: serious
Tags: sid trixie
at least the first repository should be available in the python3-doc
package.
[...]
make -C docs/source/usrman/ html man info latexpdf SPHINXOPTS="-D
today=\"January 14, 2024\""
make[2]: Entering directory '/<>/docs/source/usrman'
Running Sphinx v7.2.6
making output directory... done
[autosummary] generating autosummary for: appendix.rst, citing.rst,
index.rst, install.rst, intro.rst, mpi4py.MPI.rst, mpi4py.futures.rst,
mpi4py.rst, mpi4py.run.rst, mpi4py.util.dtlib.rst, mpi4py.util.pkl5.rst,
mpi4py.util.rst, overview.rst, reference.rst, tutorial.rst
[autosummary] generating autosummary for:
/<>/docs/source/usrman/reference/mpi4py.MPI.rst
loading intersphinx inventory from https://docs.python.org/3/objects.inv...
loading intersphinx inventory from
https://numpy.org/doc/stable/objects.inv...
WARNING: failed to reach any of the inventories with the following issues:
intersphinx inventory 'https://numpy.org/doc/stable/objects.inv' not
fetchable due to :
HTTPSConnectionPool(host='numpy.org', port=443): Max retries exceeded
with url: /doc/stable/objects.inv (Caused by ProxyError('Cannot connect
to proxy.', NewConnectionError('object at 0x7fec6bad3e90>: Failed to establish a new connection: [Errno
111] Connection refused')))
WARNING: failed to reach any of the inventories with the following issues:
intersphinx inventory 'https://docs.python.org/3/objects.inv' not
fetchable due to :
HTTPSConnectionPool(host='docs.python.org', port=443): Max retries
exceeded with url: /3/objects.inv (Caused by ProxyError('Cannot connect
to proxy.', NewConnectionError('object at 0x7fec6baa4550>: Failed to establish a new connection: [Errno
111] Connection refused')))
building [mo]: targets for 0 po files that are out of date
writing output...
building [html]: targets for 15 source files that are out of date
Bug#1022043: Info received (improved patch)
Try again - without the old patch at the top.diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..c53feb1 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,19 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+
+ lockuniq g{inProgressLock};
+
+ if (inProgress.contains(m_sFileLoc)) {
+// Check if another job is running. If so link to that.
+m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+USRDBG("Linked to other job");
+return;
+}
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnly,
@@ -697,8 +710,13 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
if(cfg::trackfileuse && fistate >= fileitem::FIST_DLGOTHEAD && fistate < fileitem::FIST_DLERROR)
m_pItem.get()->UpdateHeadTimestamp();
- if(fistate==fileitem::FIST_COMPLETE)
+ if(fistate==fileitem::FIST_COMPLETE) {
+ // Tell everybody downloading this url that we already
+ // have a job to download it and register a cleanup
+ // when this job completes.
+ setInProgress(m_sFileLoc);
return; // perfect, done here
+ }
if(cfg::offlinemode) { // make sure there will be no problems later in SendData or prepare a user message
// error or needs download but freshness check was disabled, so it's really not complete.
@@ -760,6 +778,10 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
return report_overload(__LINE__);
}
}
+ // Tell everybody downloading this url that we already have a
+ // job to download it and register a cleanup when this job
+ // completes.
+ setInProgress(m_sFileLoc);
}
catch (const std::bad_alloc&) // OOM, may this ever happen here?
{
@@ -1190,4 +1212,16 @@ void job::AppendMetaHeaders()
<< "\r\nServer: Debian Apt-Cacher NG/" ACVERSION "\r\n"
"\r\n";
}
+
+job::inProgressCleanup::~inProgressCleanup() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ USRDBG("url=" << url);
+ if (url.size()) {
+ inProgress.erase(url);
+ }
+}
+
+std::set job::inProgress;
+base_with_mutex job::inProgressLock;
}
diff --git a/src/job.h b/src/job.h
index cb162a6..c79459b 100644
--- a/src/job.h
+++ b/src/job.h
@@ -16,6 +16,24 @@ class header;
class job
{
+private:
+ // Lock controlling access to inProgress
+ static base_with_mutex inProgressLock;
+
+ // If there is an item in here then there is already a job downloading url
+ static std::set inProgress;
+
+ // Simple class which is destroyed when the job is destroyed. It deletes the entry from inProgress.
+ struct inProgressCleanup {
+ std::string url;
+ inProgressCleanup() { }
+ ~inProgressCleanup();
+ };
+
+ void setInProgress(const std::string& url_) {
+ m_ipc.url = url_;
+ inProgress.insert(url_);
+ }
public:
enum eJobResult : short
@@ -48,6 +66,7 @@ public:
} eActivity;
TFileItemHolder m_pItem;
+ inProgressCleanup m_ipc; // This MUST be destroyed before m_pItem
unique_fd m_filefd;
bool m_bIsHttp11 = true;
Bug#1061866: adns: NMU diff for 64-bit time_t transition
Control: severity -1 important
Ian Jackson writes ("Re: Bug#1061866: adns: NMU diff for 64-bit time_t
transition"):
> I have just got an alert saying adns is now scheduled for autoremoval
> due to #1061866.
>
> My understanding was that you were intending to NMU to unstable after
> "several days". I have been holding off making an upload myself so as
> not to interfere.
I'm not sure if I should:
(i) wait
(ii) apply that patch (on top of what's in experimental)
and upload to experimental
(iii) apply that patch on top of what's in experimental
and upload the result to sid.
For now I am going to downgrade this bug in the hope that the current
answer is (i).
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1061783: apprise fails its autopkg tests with Python 3.12
Hi Ben, I noticed that apprise version 0.5.1-4 has a bug since its autopkgtest fails with Python3.12. I'd happily fix packages in Debian Python Team but your package is not team maintained. Do you have any reason for this? BTW, upstream meanwhile released version 4.0.0. Is there any reason to stick to some pretty old version? Usually following upstream closely has a good chance to be compatible with recent Python versions and maybe a simple upgrade would solve this issue. Kind regards Andreas. -- http://fam-tille.de
Bug#1022043: improved patch
I've cleaned up the patch and got rid of a lot of the cruft that got
added while I was debugging.
Also found one more race condition in my original solution that I
believe is now fixed.
And I believe it's now safe even if different urls map to the same cache
file which the previous patch didn't get right.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..c53feb1 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,19 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+
+ lockuniq g{inProgressLock};
+
+ if (inProgress.contains(m_sFileLoc)) {
+// Check if another job is running. If so link to that.
+m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+USRDBG("Linked to other job");
+return;
+}
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnly,
@@ -697,8 +710,13 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
if(cfg::trackfileuse && fistate >= fileitem::FIST_DLGOTHEAD && fistate < fileitem::FIST_DLERROR)
m_pItem.get()->UpdateHeadTimestamp();
- if(fistate==fileitem::FIST_COMPLETE)
+ if(fistate==fileitem::FIST_COMPLETE) {
+ // Tell everybody downloading this url that we already
+ // have a job to download it and register a cleanup
+ // when this job completes.
+ setInProgress(m_sFileLoc);
return; // perfect, done here
+ }
if(cfg::offlinemode) { // make sure there will be no problems later in SendData or prepare a user message
// error or needs download but freshness check was disabled, so it's really not complete.
@@ -760,6 +778,10 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
return report_overload(__LINE__);
}
}
+ // Tell everybody downloading this url that we already have a
+ // job to download it and register a cleanup when this job
+ // completes.
+ setInProgress(m_sFileLoc);
}
catch (const std::bad_alloc&) // OOM, may this ever happen here?
{
@@ -1190,4 +1212,16 @@ void job::AppendMetaHeaders()
<< "\r\nServer: Debian Apt-Cacher NG/" ACVERSION "\r\n"
"\r\n";
}
+
+job::inProgressCleanup::~inProgressCleanup() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ USRDBG("url=" << url);
+ if (url.size()) {
+ inProgress.erase(url);
+ }
+}
+
+std::set job::inProgress;
+base_with_mutex job::inProgressLock;
}
diff --git a/src/job.h b/src/job.h
index cb162a6..b4df3de 100644
--- a/src/job.h
+++ b/src/job.h
@@ -16,6 +16,26 @@ class header;
class job
{
+private:
+ // Lock controlling access to inProgress
+ static base_with_mutex inProgressLock;
+
+ // If there is an item in here then there is already a job downloading url
+ static std::set inProgress;
+
+ // Simple class which is destroyed when the job is destroyed. It deletes the entry from inProgress.
+ struct inProgressCleanup {
+ std::string url;
+ inProgressCleanup() { }
+ ~inProgressCleanup();
+ };
+
+ void setInProgress(const std::string& url_) {
+ m_ipc.url = url_;
+ inProgress.insert(url_);
+ }
+
+ inProgressCleanup m_ipc;
public:
enum eJobResult : short
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..c53feb1 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,19 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+
+ lockuniq g{inProgressLock};
+
+ if (inProgress.contains(m_sFileLoc)) {
+// Check if another job is running. If so link to that.
+m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+USRDBG("Linked to other job");
+return;
+}
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnly,
@@
Bug#1031693: import-dsc: dangling pristine-tar treeish with multiple components
On Fri, 8 Dec 2023 15:52:30 + Huw Jones wrote: > Hi, > > Is there anything I can do to help resolve this issue? > > Kind regards, > Huw FWIW, this also affects plain "gbp import-orig" with component tar balls, and the patch from this bug fixes the issue for me when applied on top of 0.9.33 from sid.
Bug#1063338: [regression 6.1.67] dlm: cannot start dlm midcomms -97 after backport of e9cdebbe23f1 ("dlm: use kernel_connect() and kernel_bind()")
On Wed, Feb 7, 2024 at 2:39 AM Salvatore Bonaccorso wrote:
>
> Hi Valentin, hi all
>
> [This is about a regression reported in Debian for 6.1.67]
>
> On Tue, Feb 06, 2024 at 01:00:11PM +0100, Valentin Kleibel wrote:
> > Package: linux-image-amd64
> > Version: 6.1.76+1
> > Source: linux
> > Source-Version: 6.1.76+1
> > Severity: important
> > Control: notfound -1 6.6.15-2
> >
> > Dear Maintainers,
> >
> > We discovered a bug affecting dlm that prevents any tcp communications by
> > dlm when booted with debian kernel 6.1.76-1.
> >
> > Dlm startup works (corosync-cpgtool shows the dlm:controld group with all
> > expected nodes) but as soon as we try to add a lockspace dmesg shows:
> > ```
> > dlm: Using TCP for communications
> > dlm: cannot start dlm midcomms -97
> > ```
> >
> > It seems that commit "dlm: use kernel_connect() and kernel_bind()"
> > (e9cdebbe) was merged to 6.1.
> >
> > Checking the code it seems that the changed function dlm_tcp_listen_bind()
> > fails with exit code 97 (EAFNOSUPPORT)
> > It is called from
> >
> > dlm/lockspace.c: threads_start() -> dlm_midcomms_start()
> > dlm/midcomms.c: dlm_midcomms_start() -> dlm_lowcomms_start()
> > dlm/lowcomms.c: dlm_lowcomms_start() -> dlm_listen_for_all() ->
> > dlm_proto_ops->listen_bind() = dlm_tcp_listen_bind()
> >
> > The error code is returned all the way to threads_start() where the error
> > message is emmitted.
> >
> > Booting with the unsigned kernel from testing (6.6.15-2), which also
> > contains this commit, works without issues.
> >
> > I'm not sure what additional changes are required to get this working or if
> > rolling back this change is an option.
> >
> > We'd be happy to test patches that might fix this issue.
>
> Thanks for your report. So we have a 6.1.76 specific regression for
> the backport of e9cdebbe23f1 ("dlm: use kernel_connect() and
> kernel_bind()") .
>
> Let's loop in the upstream regression list for tracking and people
> involved for the subsystem to see if the issue can be identified. As
> it is working for 6.6.15 which includes the commit backport as well it
> might be very well that a prerequisite is missing.
>
> # annotate regression with 6.1.y specific commit
> #regzbot ^introduced e11dea8f503341507018b60906c4a9e7332f3663
> #regzbot link: https://bugs.debian.org/1063338
>
> Any ideas?
>
> Regards,
> Salvatore
Just a quick look comparing dlm_tcp_listen_bind between the latest 6.1
and 6.6 stable branches,
it looks like there is a mismatch here with the dlm_local_addr[0] parameter.
6.1
static int dlm_tcp_listen_bind(struct socket *sock)
{
int addr_len;
/* Bind to our port */
make_sockaddr(dlm_local_addr[0], dlm_config.ci_tcp_port, _len);
return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
addr_len);
}
6.6
static int dlm_tcp_listen_bind(struct socket *sock)
{
int addr_len;
/* Bind to our port */
make_sockaddr(_local_addr[0], dlm_config.ci_tcp_port, _len);
return kernel_bind(sock, (struct sockaddr *)_local_addr[0],
addr_len);
}
6.6 contains commit c51c9cd8 (fs: dlm: don't put dlm_local_addrs on heap) which
changed
static struct sockaddr_storage *dlm_local_addr[DLM_MAX_ADDR_COUNT];
to
static struct sockaddr_storage dlm_local_addr[DLM_MAX_ADDR_COUNT];
It looks like kernel_bind() in 6.1 needs to be modified to match.
-Jordan
Bug#1044079: augur 24 still ftbfs against pandas 2.1.4
Control: reopen -1 I must have mistaken something about pandas versions when uploading augur 24.0.0, because the error is still there and is now causing ftbfs again with at least pandas 2.1.4. This is still the same error in the same test: self = capsys = <_pytest.capture.CaptureFixture object at 0x7fc3d81d59d0> def test_fix_dates(self, capsys): full_date = "4-5-2020" > assert parse.fix_dates(full_date) == "2020-05-04" tests/test_parse.py:14: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ d = '4-5-2020', dayfirst = True def fix_dates(d, dayfirst=True): ''' attempt to parse a date string using pandas date parser. If ambiguous, the argument 'dayfirst' determines whether month or day is assumed to be the first field. Incomplete dates will be padded with XX. On failure to parse the date, the function will return the input. ''' try: from pandas.core.tools.datetimes import parsing > results = parsing.parse_time_string(d, dayfirst=dayfirst) E AttributeError: module 'pandas._libs.tslibs.parsing' has no attribute 'parse_time_string' Too bad things looked promising, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
> On 7 Feb 2024, at 18:27, Dima Kogan wrote: > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > bit, and it looks like it might have portability bug, at least on > big-endian architectures. For instance: > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 Thanks for having a look. I will take care. > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > nice to fix. Are you upstream or do you know upstream? Can yall fix > these? I will try to do a MR upstream > > Thanks! >
Bug#1063049: visp: NMU diff for 64-bit time_t transition
Dear, Thanks for this patch. If I understand well you will apply the patch. I don't have to apply it to the upstream. I'm right? Regards Fabien Le 04/02/2024 à 19:19, Steve Langasek a écrit : Source: visp Version: 3.6.0-2 Severity: serious Tags: patch pending sid trixie Justification: library ABI skew on upgrade User: debian-...@lists.debian.org Usertags: time-t NOTICE: these changes must not be uploaded to unstable yet! Dear maintainer, As part of the 64-bit time_t transition required to support 32-bit architectures in 2038 and beyond (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified visp as a source package shipping runtime libraries whose ABI either is affected by the change in size of time_t, or could not be analyzed via abi-compliance-checker (and therefore to be on the safe side we assume is affected). To ensure that inconsistent combinations of libraries with their reverse-dependencies are never installed together, it is necessary to have a library transition, which is most easily done by renaming the runtime library package. Since turning on 64-bit time_t is being handled centrally through a change to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is important that libraries affected by this ABI change all be uploaded close together in time. Therefore I have prepared a 0-day NMU for visp which will initially be uploaded to experimental if possible, then to unstable after packages have cleared binary NEW. Please find the patch for this NMU attached. If you have any concerns about this patch, please reach out ASAP. Although this package will be uploaded to experimental immediately, there will be a period of several days before we begin uploads to unstable; so if information becomes available that your package should not be included in the transition, there is time for us to amend the planned uploads. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1063408: ontospy's autopkg tests fail with Python 3.12
Package: src:ontospy Version: 2.1.1~dfsg2-3 Severity: important Tags: sid trixie ftbfs User: debian-pyt...@lists.debian.org Usertags: python3.12 [...] 996s autopkgtest [16:42:54]: test command5: python3 -m ontospy.tests.test_shapes 996s autopkgtest [16:42:54]: test command5: [--- 996s Traceback (most recent call last): 996s File "", line 189, in _run_module_as_main 996s File "", line 112, in _get_module_details 996s File "/tmp/autopkgtest.8QVB0F/build.806/src/ontospy/__init__.py", line 7, in 996s from .core.ontospy import Ontospy 996s File "/tmp/autopkgtest.8QVB0F/build.806/src/ontospy/core/__init__.py", line 9, in 996s from configparser import SafeConfigParser 996s ImportError: cannot import name 'SafeConfigParser' from 'configparser' (/usr/lib/python3.12/configparser.py). Did you mean: 'RawConfigParser'? 997s autopkgtest [16:42:55]: test command5: ---] 997s command5 FAIL non-zero exit status 1 that might not the only incompatibility with Python 3.12
Bug#1063407: pybdsf fails to build with Python 3.12 as default
Package: src:pybdsf
Version: 1.10.3-2
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12
Forwarded: https://github.com/lofar-astron/PyBDSF/issues/214
pybdsf fails to build with Python 3.12 as default, also the autopkg test
fails with:
290s autopkgtest [09:33:17]: test command1: [---
292s [31;1mWARNING[0m: Matplotlib pyplot could not be imported.
Plotting is disabled.
293s --> Loaded parameters from file 'tbdsf_process_image.in'.
293s Traceback (most recent call last):
293s File
"/tmp/autopkgtest.Z7dzWY/build.NDT/src/test/tbdsf_process_image.py",
line 5, in
293s img = bdsf.process_image('tbdsf_process_image.in', ncores=2)
293s ^^
293s File "/usr/lib/python3/dist-packages/bdsf/__init__.py", line 256,
in process_image
293s img.process(**kwargs)
293s File "/usr/lib/python3/dist-packages/bdsf/image.py", line 136, in
process
293s success = interface.process(self, **kwargs)
293s ^
293s File "/usr/lib/python3/dist-packages/bdsf/interface.py", line 66,
in process
293s _run_op_list(img, op_chain)
293s File "/usr/lib/python3/dist-packages/bdsf/__init__.py", line 155,
in _run_op_list
293s op(img)
293s File "/usr/lib/python3/dist-packages/bdsf/readimage.py", line 68,
in __call__
293s result = read_image_from_file(image_file, img, img.indir)
293s
293s File "/usr/lib/python3/dist-packages/bdsf/functions.py", line
1079, in read_image_from_file
293s from distutils.version import StrictVersion
293s ModuleNotFoundError: No module named 'distutils'
294s autopkgtest [09:33:21]: test command1: ---]
297s command1 FAIL non-zero exit status 1
Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
Hi. Thanks for your contribution. I looked at the upstream code a tiny bit, and it looks like it might have portability bug, at least on big-endian architectures. For instance: https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 This assumes that sizeof(long)==4. Maybe this is benign, but it would be nice to fix. Are you upstream or do you know upstream? Can yall fix these? Thanks!
Bug#839925: Set wontfix
Control: tags -1 wontfix Set wontfix since here is no real solution how to solve this bug. Thus cleaning up list of bugs a bit. -- http://fam-tille.de
Bug#1062654: openjdk-17-jre-headless: Segfault in jspawnhelper
On 2024-02-06 12:52:51 [-0500], Hubert Pineault wrote: > I got the same problem on bullseye. > > the package was upgraded from 17.0.9+9-1~deb11u1 to 17.0.10+7-1~deb11u1 > on the 6th of february (with unattended-upgrades). It broke my jenkins > instance because it could not fetch git repo anymore. > > Downgrading to 17.0.7+7-1~deb11u1 solve the problem. You can install the upgrade and then you need to restart everything java related that is still running and using the old java version. Reboot the machine to be safe. After that, everything works as intended. Sebastian
Bug#1063406: mate-desktop-environment: Monitor Preferences scaling is not persisted after a reboot (discrete only graphics)
Package: mate-desktop-environment Version: 1.26.0+1 Severity: normal X-Debbugs-Cc: jwaff...@gmail.com I'm submitting this because mate requires me to submit a debian bug report in order to submit an issue with them; my guess is, the mate team will need to address it. This is also a copy/paste of https://ubuntu-mate.community/t/monitor-preferences-scaling-is-not-persisted-after-a-reboot-discrete-only-graphics/27146 I'm running Debian 12.4.0 with my nvidia GPU in **discrete only** mode. The discrete only part may be crucial, I went into the BIOS and changed that, the default is hybrid which will use both the intel HD graphics and the nvidia card. Aside: I don't do Hybrid because back in the 2010s (not this laptop) if I didn't run a program with bumblebee that expected a GPU it'd hard freeze my whole computer, and it was a real pain to try and figure out what applications needed that and which ones didn't (there were some programs where it wasn't really clear at all whether they needed the nvidia chip). It was also a real pain to handle programs that called other programs, sometimes a script/etc didn't launch some subprocess with bumblebee like it should have, and then I had to track down that script or program and modify it. Maybe things got better since then, but it was such a terrible experience that I'm not really inclined to try it again. I'm not concerned about losing some battery life, I'd rather just simplify my life and force everything through the discrete card. Even on Windows I've had weird issues with Hybrid graphics sometimes. On boot the scaling on my computer (Lenovo P53) seems to be reverted to something scaled down significantly (as in, things are way too big on the screen). This is a pretty high resolution laptop, the default setting for Windows was to do this too. I can fix this just by going into Monitor Preferences and changing it from auto-detect to 100% or back, but I have to do that every time I turn on the computer. It seems like just changing something and hitting Apply fixes it The permanent fix that's working / persisting seems to be to edit `/etc/lightdm/lightdm.conf` and put this in it: ```conf [Seat:*] xserver-command=X -dpi 96 ``` I figured this out by adapting the solution from https://askubuntu.com/a/272172 Also... I guess while I'm here, there was one other customization I had to do for this P53, the Mate GUIs and keyboard keys for setting backlight brightness don't work and didn't work in any distro I tried on this laptop, but they do work on my Dell Latitude. My duct tapeish workaround for that is to manually edit this file: `/sys/class/backlight/nvidia_0/brightness`, this file just has one number in it. For example, 10 is 10% brightness. 100 is 100% brightness. This seems to work pretty well. Hope that helps PS: If this *is* a bug, what product should I report it against? Where does the source code for Monitor Preferences live? I know C/C++, I might be able to look into it. Update: I found a reddit thread that said the source for Monitor Preferences is here, but I did not validate this yet https://github.com/mate-desktop/mate-control-center/tree/master/capplets/display -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/12 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mate-desktop-environment depends on: ii mate-desktop-environment-core 1.26.0+1 Versions of packages mate-desktop-environment recommends: ii atril 1.26.0-2+b1 ii desktop-base 12.0.6+nmu1~deb12u1 ii engrampa 1.26.0-1 ii eom 1.26.0-2 ii ffmpegthumbnailer 2.2.2+git20220218+dfsg-1+b1 ii libcanberra-pulse 0.30-10 ii mate-applet-brisk-menu0.6.2-2 ii mate-applets 1.26.1-1 ii mate-backgrounds 1.26.0-1 ii mate-calc 1.26.0-1 ii mate-media1.26.0-2 ii mate-notification-daemon 1.26.0-1+deb12u1 ii mate-power-manager1.26.0-2+deb12u1 ii mate-screensaver 1.26.1-1 ii mate-system-monitor 1.26.0-1 ii mate-user-guide 1.26.0-1 ii mate-utils1.26.0-1 ii pluma 1.26.0-1 Versions of packages mate-desktop-environment suggests: ii bsd-mailx [mail-reader] 8.1.2-0.20220412cvs-1 pn mate-desktop-environment-extras ii network-manager-gnome1.30.0-2 pn x-www-browser | firefox -- no debconf information
Bug#1063405: sensible-utils: error "realpath: '': No such file or directory" / possible recursive loop
Package: sensible-utils
Version: 0.0.22
Severity: normal
After the upgrade to 0.0.22, I'm getting the following error with
sensible-pager:
realpath: '': No such file or directory
(the other sensible-* utilities are likely to have the same issue
since the related code is very similar).
This is due to
# Prevent recursive loops, where environment variables are set to this
script
[ x$(realpath "$(command -v "$candidate" || true)" || true) = x"$program" ]
&& return
where $candidate is a command with arguments. For instance,
I have PAGER="less -Lis". Hence the issue.
The full string for "command -v" is expected to be the executable name
(without arguments). So the executable is not found, and "command -v"
fails without any output, so that realpath outputs an error to stderr
for this reason.
There is the same issue when the command doesn't exist:
cventin:~> PAGER=foo sensible-pager
realpath: '': No such file or directory
PAGER: 1: foo: not found
Missing filename ("less --help" for help)
In any case, the "realpath: '': No such file or directory" just
concerns internals and should be hidden from the user.
The problem is actually worse than the error message as there can
be a loop:
cventin:~> PAGER="sensible-pager " sensible-pager
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
[...]
So I suggest 2 fixes:
1. In the candidate, take only everything until the first space,
i.e. use "${candidate%% *}" instead of "$candidate".
2. Redirect the realpath standard error to /dev/null in order to
avoid the error message when the executable is not found.
This gives:
# Prevent recursive loops, where environment variables are set to this
script
[ x$(realpath "$(command -v "${candidate%% *}" || true)" 2> /dev/null ||
true) = x"$program" ] && return
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.13-amd64 (SMP w/12 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), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
--
Vincent Lefèvre - Web:
Bug#1063404: power-profiles-daemon: Upstream repo location changed
Source: power-profiles-daemon Version: 0.12-1 Severity: minor Tags: upstream X-Debbugs-Cc: genpfa...@threadpitch.net Dear Maintainer, The 'Homepage' currently lists the 'hadess' repo: https://gitlab.freedesktop.org/hadess/power-profiles-daemon ...but that address now redirects to the 'upower' repo: https://gitlab.freedesktop.org/upower/power-profiles-daemon ...with this banner message: > Project 'hadess/power-profiles-daemon' was moved to > 'upower/power-profiles-daemon'. > Please update any links and bookmarks that may still have the old path. -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-13-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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#1043571: Bugs related to #1062189
Hello, After further investigations, my report is related to this : #1062189 Thank you.
Bug#1063403: libeegdev-dev,libeegdev0t64: both ship /usr/share/doc/libeegdev0/changelog.gz
Package: libeegdev-dev,libeegdev0t64
Version: 0.2-8.1~exp1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t
X-Debbugs-Cc: Michael Hudson-Doyle
Something weird happened after the package rename:
/usr/share/doc/libeegdev0/changelog.Debian.gz
/usr/share/doc/libeegdev0/changelog.gz
Are now shipped by libeegdev-dev and libeegdev0t64 while they should be
in none of these packages.
$ debdiff libeegdev-dev_0.2-8_amd64.deb libeegdev-dev_0.2-8.1~exp1_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /usr/share/doc/libeegdev0/changelog.Debian.gz
-rw-r--r-- root/root /usr/share/doc/libeegdev0/changelog.gz
Control files: lines which differ (wdiff format)
Depends: {+libeegdev0t64 (= 0.2-8.1~exp1),+} libeegdev0 (= [-0.2-8)-]
{+0.2-8.1~exp1)+}
Installed-Size: [-71-] {+87+}
Version: [-0.2-8-] {+0.2-8.1~exp1+}
Also the libeegdev0 dependency is still there ...
Andreas
Bug#1063402: libnuma1: get_mempolicy: Function not implemented
Package: libnuma1 Version: 2.0.17-2 Severity: normal Forwarded: https://github.com/numactl/numactl/issues/212 Tags: fixed-upstream After today's upgrade I noticed the error message get_mempolicy: Function not implemented appearing on my terminal and wondered where it comes from. It turns out that various procps programs dlopen() libnuma.so.1, and libnuma prints this message on stderr if NUMA support is not available in the kernel (CONFIG_NUMA is unset in my self-built kernel). There are many scripts which run ps(1), so this message can pop up quite often. For details see https://github.com/numactl/numactl/issues/212 which upstream claims has been fixed in numactl 2.0.18, so an upgrade to that version would be appreciated. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.77-nouveau (SMP w/2 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libnuma1 depends on: ii libc6 2.37-15 libnuma1 recommends no packages. libnuma1 suggests no packages. -- no debconf information
Bug#1063401: atm-tools: has gained /usr/share/doc/libatm1/changelog.*
Package: atm-tools
Version: 1:2.5.1-5.1~exp1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t
X-Debbugs-Cc: Steve Langasek
atm-tools/experimental has gained two unexpected files, causing file
conflicts on upgrades:
$ debdiff atm-tools_1%3a2.5.1-5_amd64.deb atm-tools_1%3a2.5.1-5.1~exp1_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /usr/share/doc/libatm1/changelog.Debian.gz
-rw-r--r-- root/root /usr/share/doc/libatm1/changelog.gz
Control files: lines which differ (wdiff format)
Depends: [-libatm1 (= 1:2.5.1-5),-] {+libatm1t64 (>= 2.4.1-17~),+} libc6 (>=
2.34), libfl2 (>= [-2.5.33)-] {+2.5.33), libatm1 (= 1:2.5.1-5.1~exp1)+}
Installed-Size: [-1197-] {+1243+}
Version: [-1:2.5.1-5-] {+1:2.5.1-5.1~exp1+}
There is still an libatm1 dependency, and the new libatm1t64 dependency
seems to miss the epoch.
Andreas
BTW, linux-atm is orphaned, so you should do QA instead of NMU uploads.
Bug#1062259: libcomps: NMU diff for 64-bit time_t transition
Control: tags -1 -pending Control: close -1 On Wed, 31 Jan 2024 21:02:50 + Steve Langasek wrote: > Source: libcomps > Version: 0.1.19-2.1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > libcomps as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for libcomps > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. There are no mentions of 'time_t' in the public headers of this library. The logs shows that it's a false positive, as the automated tool simply wasn't able to build it: https://adrien.dcln.fr/misc/armhf-time_t/2024-02-06T16%3A48%3A00/logs/libcomps-dev/base/log.txt Closing as not applicable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1062674: lua-compat53: NMU diff for 64-bit time_t transition
On Fri, Feb 02, 2024 at 04:18:01PM +, Graham Inggs wrote: > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. The 53 in lua-compat53 isn't related to the ABI. This Lua module provides a Lua 5.3 API surface that can be used in previous Lua versions. Lua module packages aren't generally named according to the SONAME (for reasons I'm not clear on). Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1062744: libzypp: NMU diff for 64-bit time_t transition
Control: tags -1 -pending Control: close -1 On Fri, 02 Feb 2024 23:01:04 + Steve Langasek wrote: > Source: libzypp > Version: 17.31.29-1 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > libzypp as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for libzypp > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. There are no mentions of 'time_t' in the public headers of this library. The logs shows that it's a false positive, as the automated tool simply wasn't able to build it: https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libzypp-dev/base/log.txt Closing as not applicable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1062632: libsolv: NMU diff for 64-bit time_t transition
Control: tags -1 -pending Control: close -1 On Fri, 02 Feb 2024 07:47:44 + Steve Langasek wrote: > Source: libsolv > Version: 0.7.28-1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > libsolv as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for libsolv > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. There are no mentions of 'time_t' in the public headers of this library. The logs shows that it's a false positive, as the automated tool simply wasn't able to build it: https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libsolvext-dev/base/log.txt Closing as not applicable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1063400: giza-dev: missing Conflicts: pgplot5t64
Package: giza-dev Version: 1.4.1-1 Severity: serious User: debian-...@lists.debian.org Usertags: time-t X-Debbugs-Cc: Lucas Kanashiro giza-dev already has Conflicts: pgplot5 there needs to be pgplot5t64 added ... The conflicting file is /usr/include/cpgplot.h Andreas
Bug#1062928: stlink: NMU diff for 64-bit time_t transition
Control: tags -1 -pending Control: close -1 On Sun, 04 Feb 2024 00:43:16 + Steve Langasek wrote: > Source: stlink > Version: 1.7.0+ds-2 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > stlink as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for stlink > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. There are no mentions of 'time_t' in the public headers of this library. The logs shows that it's a false positive, as the automated tool simply wasn't able to build it: https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libstlink-dev/base/log.txt Closing as not applicable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1058365: add patch
On Thu, Jan 11, 2024 at 12:00:13PM +0100, Matthias Klose wrote: > Control: tags -1 + patch > > patch at > https://launchpadlibrarian.net/708712831/python-jedi_0.18.2-1_0.18.2-1ubuntu1.diff.gz Hi Piotr, Are you able to upload a fixed or new version of python-jedi to address this serious bug? It is likely to soon pull spyder out of testing, which I am responsible for. I'm happy to do an NMU, uploading the new version of python-jedi (as that introduces compatibility with Python 3.12). I'll do so in a few days if I haven't heard back from you by then. At the same time, using the python3-typeshed package rather than vendoring it (#1039627) would also fix #1040094, but this might be a bit more work, as jedi/inference/gradual/utils.py would also need some attention, and some of the test_typeshed.py tests might no longer work. You could also drop python3-unittest2 without harm (#1058976). I'd be happy to have a go at these other bugs if you would like me to. Best wishes, Julian
Bug#1063399: kylin-process-manager-daemon: missing Breaks+Replaces: kylin-process-manager (<< 4)
Package: kylin-process-manager-daemon Version: 4.0.0.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'experimental' to 'sid'. It installed fine in 'experimental', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. This error may also be triggered by having a predecessor package from 'experimental' installed while installing the package from 'sid'. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../kylin-process-manager-daemon_4.0.0.0-1+b1_amd64.deb ... Unpacking kylin-process-manager-daemon (4.0.0.0-1+b1) ... dpkg: error processing archive /var/cache/apt/archives/kylin-process-manager-daemon_4.0.0.0-1+b1_amd64.deb (--unpack): trying to overwrite '/etc/kylin-process-manager/kylin-process-manager.json', which is also in package kylin-process-manager 3.0.0-1 Errors were encountered while processing: /var/cache/apt/archives/kylin-process-manager-daemon_4.0.0.0-1+b1_amd64.deb The files in conflict are: etc/kylin-process-manager/kylin-process-manager.json lib/systemd/system/kylin-process-manager-cleaner.service cheers, Andreas kylin-process-manager=3.0.0-1_kylin-process-manager-daemon=4.0.0.0-1+b1.log.gz Description: application/gzip
Bug#1063398: FTBFS: src/capng_swig.i:33: Error: Unknown directive '%except'
On 07.02.2024 16:27, Emanuele Rocca wrote: > Source: libcap-ng > Version: 0.8.4-1 > Severity: serious > Tags: sid trixie ftbfs > > Hi, > > libcap-ng currently FTBFS with the following error: > > make[6]: Entering directory '/<>/build-py3.11/bindings/python3' > cat /usr/include/linux/capability.h | grep '^#define CAP' | grep -v '[()]' > > caps.h > cat ../../../src/cap-ng.h | grep -v '_state' > capng.h > swig -o capng_wrap.c -python -I. -I../.. -I/usr/include/python3.11 > -I/usr/include/python3.11 ../../../bindings/python3/../src/capng_swig.i > ../../../bindings/python3/../src/capng_swig.i:33: Error: Unknown directive > '%except'. > make[6]: *** [Makefile:878: capng_wrap.c] Error 1 > make[6]: Leaving directory '/<>/build-py3.11/bindings/python3' > make[5]: *** [Makefile:595: all-recursive] Error 1 > make[5]: Leaving directory '/<>/build-py3.11/bindings/python3' > make[4]: *** [Makefile:390: all-recursive] Error 1 > make[4]: Leaving directory '/<>/build-py3.11/bindings' > make[3]: *** [Makefile:441: all-recursive] Error 1 > make[3]: Leaving directory '/<>/build-py3.11' > make[2]: *** [Makefile:373: all] Error 2 > make[2]: Leaving directory '/<>/build-py3.11' I believe upstream has fixed this with [1], I'll take a closer look, hopefully today, and get the package updated. -- Håvard [1] https://github.com/stevegrubb/libcap-ng/commit/30453b6553948cd05c438f9f509013e3bb84f25b
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Hi Andreas,
On Wed, Feb 07, 2024 at 03:47:37PM +0100, Andreas Metzler wrote:
> Package: libselinux1t64
> Replaces: libselinux1
> Provides: libselinux1 (= 3.5-2.1~exp1)
> Breaks: libselinux1 (<< 3.5-2.1~exp1)
>
> Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on
> "libselinux1 (>= 3.1~)". dpkg needs to be rebuilt and the rebuilt
> version gets a dep on "libselinux1t64 (>= 3.5)".
The *t64 libraries only break ABI on some architectures. Notably, on all
64bit architectures, i386 and x32, the ABI will not change. On the next
upload after the transition, library dependencies will move to the t64
variants, yes.
> Will ${t64:Provides} stop expanding to "libselinux1 = ${binary:Version
> for real t64-builds? (The ones in experimental are not.) If that is case
> this bug and this way of testing does not make sense.
No, the t64:Provides will remain that way for all architectures that do
not break ABI. In theory, we could have skipped the rename on those
architectures, but having architecture-dependent package names is
annoyingly hard. Hence, we rename them on e.g. amd64 as well even though
nothing changes there.
Hope this explains
Helmut
Bug#1063146: Problem with setup-storage
Here's the patch https://github.com/faiproject/fai/commit/cd33235318279a96267d3377661dbeba93eacac3 -- viele Grüße Thomas
Bug#1063398: FTBFS: src/capng_swig.i:33: Error: Unknown directive '%except'
Source: libcap-ng Version: 0.8.4-1 Severity: serious Tags: sid trixie ftbfs Hi, libcap-ng currently FTBFS with the following error: make[6]: Entering directory '/<>/build-py3.11/bindings/python3' cat /usr/include/linux/capability.h | grep '^#define CAP' | grep -v '[()]' > caps.h cat ../../../src/cap-ng.h | grep -v '_state' > capng.h swig -o capng_wrap.c -python -I. -I../.. -I/usr/include/python3.11 -I/usr/include/python3.11 ../../../bindings/python3/../src/capng_swig.i ../../../bindings/python3/../src/capng_swig.i:33: Error: Unknown directive '%except'. make[6]: *** [Makefile:878: capng_wrap.c] Error 1 make[6]: Leaving directory '/<>/build-py3.11/bindings/python3' make[5]: *** [Makefile:595: all-recursive] Error 1 make[5]: Leaving directory '/<>/build-py3.11/bindings/python3' make[4]: *** [Makefile:390: all-recursive] Error 1 make[4]: Leaving directory '/<>/build-py3.11/bindings' make[3]: *** [Makefile:441: all-recursive] Error 1 make[3]: Leaving directory '/<>/build-py3.11' make[2]: *** [Makefile:373: all] Error 2 make[2]: Leaving directory '/<>/build-py3.11'
Bug#1063397: virtualenvwrapper: Installation incomplete
Package: virtualenvwrapper Version: 4.8.4-4 Severity: normal Dear Maintainer, I am aware that upstream do tell its users to do "source /virtuelenvwrapper.sh". This is an unnecessary step. When using Debian package I would expect that "apt" will do this for me. The package do not work after "apt install". I still have to make this manual step. This is IMHO a bug on usability. Kind Christian Buhtz -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.1.0-17-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages virtualenvwrapper depends on: ii python3-virtualenvwrapper 4.8.4-4 ii virtualenv 20.17.1+ds-1 Versions of packages virtualenvwrapper recommends: ii bash-completion 1:2.11-6 Versions of packages virtualenvwrapper suggests: pn virtualenvwrapper-doc -- no debconf information
Bug#1063320: gretl: NMU diff for 64-bit time_t transition
On 6 February 2024 at 06:43, Steve Langasek wrote: | Source: gretl | Version: 2023c-2 | Severity: serious | Tags: patch pending sid trixie | Justification: library ABI skew on upgrade | User: debian-...@lists.debian.org | Usertags: time-t | | NOTICE: these changes must not be uploaded to unstable yet! | | Dear maintainer, | | As part of the 64-bit time_t transition required to support 32-bit | architectures in 2038 and beyond | (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified | gretl as a source package shipping runtime libraries whose ABI | either is affected by the change in size of time_t, or could not be | analyzed via abi-compliance-checker (and therefore to be on the safe | side we assume is affected). | | To ensure that inconsistent combinations of libraries with their | reverse-dependencies are never installed together, it is necessary to | have a library transition, which is most easily done by renaming the | runtime library package. | | Since turning on 64-bit time_t is being handled centrally through a change | to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is | important that libraries affected by this ABI change all be uploaded close | together in time. Therefore I have prepared a 0-day NMU for gretl | which will initially be uploaded to experimental if possible, then to | unstable after packages have cleared binary NEW. | | Please find the patch for this NMU attached. | | If you have any concerns about this patch, please reach out ASAP. Although | this package will be uploaded to experimental immediately, there will be a | period of several days before we begin uploads to unstable; so if information | becomes available that your package should not be included in the transition, | there is time for us to amend the planned uploads. Thanks, Steve. I applied the patch to my repo and committed to salsa. Gretl updates infrequently enough so that a transition to unstable is very likely to happen before a new upstream. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#698988: O: nvi - 4.4BSD re-implementation of vi
On Tue, Feb 06, 2024 at 06:38:18PM +0100, Paride Legovini wrote: > Hi Tobias! > > On 2024-02-05 10:43, Tobias Heider wrote: > > On Sat, Jan 26, 2013 at 12:38:07AM +, Stuart Prescott wrote: > >> > >> The maintainer for the "nvi" package has indicated that he is unable to > >> maintain this package for the time being. I'm marking this package as > >> orphaned > >> now. > > > > Looks like this is still orphaned over ten years later. > > > > As an active nvi user I would love to step up and help, but the biggest > > problem I see is that the choice of upstream project. Since the original > > is gone there isn't a clear successor. > > > > The BSDs all have their own forks which diverged over time (and those don't > > build on Linux). > > The other two options there are today are https://repo.or.cz/nvi.git which > > d/control currently points to and more recently > > https://github.com/lichray/nvi2. > > > > The first has a very low commit frequency (last commit was 2020, before > > that 2016) and sticks very closely to the original source. nvi2 has added > > new features such as multibyte support and is starting to receive bug fixes > > and features from the different *BSD forks. > > > > I have been thinking of proposing a new package for nvi2 but maybe it would > > make more sense to move this one to the more active upstream. It looks like > > some of the issues we are carrying patches for in Debian might be fixed > > there > > already and if not they seem active enough to merge our fixes. > > > > What would be the best way forward here? ITA and eventually switch the > > upstream > > or start a new package and let this one continue its slow death? > > I think making the O bug and ITA and switching upstream is right thing to > do here, maybe explaining the history of the package in README.source. > > I can't think think of a reasonable use case where nvi2 would not be > a suitable drop-in replacement for nvi; if neither can you (knowing > the editor way better than me!), then I'd say go for the switch. > > I'll be happy reviewing/sponsoring if needed. Thanks! Yours and Andreas' feedback give me enough confidence that it might be worth it, so I'll start hacking and see if it's doable. I think I'll ITA and check if I can fix some smaller things first before making the big move, since that will require more time and lots of testing to make sure everything still works. I'll let you know if I have something that needs sponsoring! > > Cheers, > > Paride >
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
On 2024-02-06 Helmut Grohne wrote:
> Package: libselinux1t64
[...]> This looks fairly innocuous. We create a minimal sid chroot and install
> libselinux1t64 using apt. What could possibly go wrong? Well, apt thinks
> that it would be a good idea to avoid coinstalling breaking packages and
> first removes libselinux1 before proceeding to install libselinux1t64.
> Unfortunately, libselinux1 is transitively essential and dpkg links it,
[...]
> both dpkg and tar are now broken. This is pretty bad. To make matters
> worse, the situation arises from the combination of Breaks + Provides
[...]
Hello,
color me stupid but isn't this fishy?
Package: libselinux1t64
Replaces: libselinux1
Provides: libselinux1 (= 3.5-2.1~exp1)
Breaks: libselinux1 (<< 3.5-2.1~exp1)
Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on
"libselinux1 (>= 3.1~)". dpkg needs to be rebuilt and the rebuilt
version gets a dep on "libselinux1t64 (>= 3.5)".
Will ${t64:Provides} stop expanding to "libselinux1 = ${binary:Version
for real t64-builds? (The ones in experimental are not.) If that is case
this bug and this way of testing does not make sense.
Otherwise the plan looks flawed.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Bug#1062427: ghmm: NMU diff for 64-bit time_t transition
Hi Lukas, Am Thu, Feb 01, 2024 at 11:27:43AM +0100 schrieb Lukas Märdian: > please note that ghmm seems to FTBFS for a reason unrelated to this NMU: > > dh_install > dh_install: warning: Cannot find (any matches for) > "usr/lib/python3*/site-packages/*" (tried in ., debian/tmp) > > dh_install: warning: ghmm missing files: usr/lib/python3*/site-packages/* > dh_install: error: missing files, aborting > make[1]: *** [debian/rules:15: override_dh_install] Error 255 > make[1]: Leaving directory '/home/slyon/time_t/ghmm-0.9~rc3' > make: *** [debian/rules:9: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 > > > The python files seem to be generated in wrong directory (see tree below). The uploaded package was lagging quite behind packaging in Git. Since I was able to upload a fixed package to unstable today I applied all your changes in another upload to experimental which I "sponsored" for you as ghmm_0.9~rc3-5.1~exp. Hope this contributes a bit to all your huge work for the time_t transition. Kind regards and thanks a lot for your work Andreas. PS: In case you notice in tracker.debian.org that "version in VCS is newer than in repository, is it time to upload?" is set it might be useful to contact the maintainers of the package. -- http://fam-tille.de
Bug#818547: ITA: vpnc -- Cisco-compatible VPN client
X-Debbugs-CC: Florian Schlichting , Samuel Henrique , Debian Security Tools Packaging Team , I forked the vpnc package from the Debian group [1] to my personal projects [2] and started to work on it. In the end I would like to maintain the package under the umbrella of the Debian Security Tools Packaging Team. @Samuel: When I am ready I intend to request a move of the repository from the Debian group to the Debian Security Tools Packaging Team. Let me know if you agree to this procedure. Sven [1] https://salsa.debian.org/debian/vpnc [2] https://salsa.debian.org/sven-geuer/vonc -- GPG Fingerprint 3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585 signature.asc Description: This is a digitally signed message part
Bug#1063396: lircd systemd service times out
Package: lirc Version: 0.10.2-0.5 Severity: important from the journal: Feb 07 00:04:05 ugly lircd-0.10.2[35370]: Notice: lircd(default) ready, using /var/run/lirc/lircd Feb 07 00:05:35 ugly systemd[1]: lircd.service: start operation timed out. Terminating. so lircd gets terminated despite everything being just fine. that's because the service type is specified as "notify", but clearly the daemon doesn't actually send a readiness notification. that's probably either because lirc was built without systemd support against intentions (missing build-dep?), or because it doesn't actually have support for systemd in the first place, and the service type should be "simple" (or maybe "exec", but nobody seems to use that). -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lirc depends on: ii libasound2 1.2.10-3 ii libc62.37-15 ii libftdi1-2 1.5-6+b3 ii libgcc-s114-20240201-3 ii liblirc-client0 0.10.2-0.5 ii liblirc0 0.10.2-0.5 ii libportaudio219.6.0-1.2 ii libstdc++6 14-20240201-3 ii libusb-0.1-4 2:0.1.12-35 ii libusb-1.0-0 2:1.0.27-1 ii python3 3.11.6-1 Versions of packages lirc recommends: ii gir1.2-vte-2.91 0.74.2-1 ii python3-gi 3.46.0-3 ii python3-yaml 6.0.1-2 ii systemd 255.3-2 Versions of packages lirc suggests: ii ir-keytable 1.26.1-3 pn lirc-compat-remotes pn lirc-doc pn lirc-drv-irman ii lirc-x 0.10.2-0.5 ii setserial2.17-53+b1 -- Configuration Files: /etc/lirc/lirc_options.conf changed [not included] /etc/lirc/lircd.conf.d/devinput.lircd.conf [Errno 2] No such file or directory: '/etc/lirc/lircd.conf.d/devinput.lircd.conf' /etc/lirc/lircmd.conf changed [not included] -- no debconf information
Bug#1063395: bash-doc: bash.html is invalid
Package: bash-doc
Version: 5.1-2+deb11u1
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I was trying to read Bash documentation.
* What exactly did you do (or not do) that was effective (or
ineffective)?
{ exec tidy declaration
* What outcome did you expect instead?
declaration
*** End of the template - remove these template lines ***
-- System Information:
Distributor ID: Bunsenlabs
Description:BunsenLabs GNU/Linux 11 (Beryllium)
Release:11
Codename: bullseye
Architecture: x86_64
Kernel: Linux 5.10.0-26-amd64 (SMP w/2 CPU threads)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bash-doc depends on:
ii dpkg 1.20.13
ii install-info 6.7.0.dfsg.2-6
bash-doc recommends no packages.
bash-doc suggests no packages.
-- no debconf information
Bug#1063369: aide: Don't require s-nail to send email, other setups (e.g. postfix+bsd-mailx) work as well
On Tue, Feb 06, 2024 at 10:22:35PM +0100, Timo Sigurdsson wrote:
> Package: aide
> Version: 0.18.3-1+deb12u2
Just for the record: Changing this in bookworm won't happen.
> since Debian Bookworm, aide refuses to send emails by default if
> s-nail is not installed.
This is not correct, MAILCMD is honored. Documentation says:
| The daily aide check will automatically select the method of sending
| mail according to the rules documented above. The variable MAILCMD in
| /etc/default/aide can be used to override these rules. If you know
| that your mail(1) works in a scenario where the automatism refuses to
| use mail(1), setting MAILCMD to the path to mail(1) manually will force
| the script to use mail(1). If you need more flexibility and/or would
| prefer to have additional methods of delivering the report supported
| by the package, please file a wishlist bug.
> The documentation (README.Debian.gz in aide-common) falsely claims
> that /usr/lib/sendmail requires suid and that this affects bsd-mailx.
> Well, first of all, bsd-mailx doesn't even provide /usr/lib/sendmail,
> so this is misleading.
as far as I know, bsd-mailx invokes /usr/lib/sendmail.
> In addition, there are (popular) MTAs that don't install
> /usr/lib/sendmail with the suid bit set, e.g. postfix.
The default MTA does it this way.
> I have postfix configured to send out mail via a smarthost only,
> without any local mail delivery. I also disabled the smtpd daemon
> listening on port 25, so mail is sent via mailx/sendmail. And that
> works just fine with aide, even as non-root under systemd. I have set
> MAILCMD="/usr/bin/mailx" in /etc/default/aide in order to "convince"
> aide to send mail despite not having s-nail installed.
That is the way it is documented to work, yes.
> The downside is
> that my custom MAILSUBJ is ignored now since Debian Bookworm.
MAILSUBJ is honored in the code of dailyaidecheck:
if [ -n "${MAILCMD:-}" ]; then
eval "${MAILCMD} -s \"${MAILSUBJ}\" \"${MAILTO}\"" || RET=$?
mailx is documented to honor the -s parameter. Please verify that mailx
is called correctly by our code and file an appropriate bug either
against aide or mailx.
> I would suggest to not hardcode a (soft) dependency on s-nail into the
> script. I think it would be better to merely warn people upon
> upgrading that sending mail may not work as non-root under systemd if
> the MTA requries suid and that s-nail might solve that. But don't add
> artificial restrictions or checks. If mail delivery breaks for some,
> then they know they need s-nail, but the rest can just keep using
> their known MTA setup.
This is impossible to get right since there are millions of ways to
configure local mail. Setting MAILCMD to a non-empty version is the
documented way to tell the script "use this, I know it works". Does this
work, or does it not work?
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1063394: hannah FTCBFS: hard codes the build architecture pkg-config
Source: hannah Version: 2.0.1+ds1-0.2 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs hannah fails to cross build from source, because the upstream Makefile.am hard codes the build architecture pkg-config. Using pkg-config in Makefile.am usually is a bad idea. Rather, such aspects should be detected at configure time and indeed the configure.ac performs the necessary detection already. All that is missing is transferring the detected values from configure.ac to Makefile.am. I'm attaching a patch for your convenience. Helmut --- hannah-2.0.1+ds1.orig/Makefile.am +++ hannah-2.0.1+ds1/Makefile.am @@ -11,7 +11,7 @@ # Additional CFLAGS AM_CPPFLAGS = $(SDL_CFLAGS) -DDATA_INSTALL_DIR=\"$(DATA_INSTALL_DIR)\" # LIBS comes after the G++ sources, so library files need to go here -LIBS = $(shell pkg-config --libs sdl2 SDL2_image SDL2_mixer SDL2_ttf) +LIBS = $(SDL2_image_LIBS) $(SDL2_mixer_LIBS) $(SDL2_ttf_LIBS) # the create_file_list.sh script generates the below include file listing all files and their output directories include hannah_files.mk # Additional files that need to be included in a release --- hannah-2.0.1+ds1.orig/configure.ac +++ hannah-2.0.1+ds1/configure.ac @@ -5,7 +5,10 @@ AC_PROG_CXX AM_PATH_SDL2([2.0.5]) PKG_CHECK_MODULES([SDL2_image], [SDL2_image]) +AC_SUBST([SDL2_image_LIBS]) PKG_CHECK_MODULES([SDL2_mixer], [SDL2_mixer]) +AC_SUBST([SDL2_mixer_LIBS]) PKG_CHECK_MODULES([SDL2_ttf], [SDL2_ttf]) +AC_SUBST([SDL2_ttf_LIBS]) AC_CONFIG_FILES(Makefile) AC_OUTPUT
Bug#1063393: systemd FTBFS with nocheck build profile: ../meson.build:1810:33: ERROR: Feature ukify cannot be enabled: Python >= 3.9 and pefile required
Source: systemd Version: 255.3-1 Severity: serious Tags: ftbfs trixie sid Hi, systemd fails to build from source when built with the nocheck build profile. Since trixie, such a failure is considered release-critical. The notable message probably is: | ../meson.build:1810:33: ERROR: Feature ukify cannot be enabled: Python >= 3.9 and pefile required I guess your python3-pefile dependency should not be tagged and it should probably be annotated :native until it becomes M-A:foreign. Helmut
Bug#1063392: zfsutils-linux has an undeclared file conflict on /usr/bin/arcstat
Package: zfsutils-linux Version: 2.2.2-5~exp2 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + nordugrid-arc-client zfsutils-linux has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/bin/arcstat is contained in the packages * nordugrid-arc-client * 6.10.2-1 as present in bullseye * 6.17.0-3 as present in bookworm * 6.18.0-1 as present in trixie|unstable * zfsutils-linux/2.2.2-5~exp2 as present in experimental These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
