Bug#1060259: [Pkg-zfsonlinux-devel] Bug#1060259: zfs-dkms: Fails to build after upgrade to linux-image-6.1.0-17-amd64
Control: tags -1 + unreproducible Control: severity -1 normal Hi, > Building DKMS modules for zfs started to fail after upgrading to the latest > (6.1.0-17) kernel available for > Bookworm preventing successful configuration of following packages: > > linux-image-6.1.0-17-amd64 > linux-headers-6.1.0-17-amd64 I tried to install zfs-dkms 2.11-1 on 6.1.0-17-amd64 and no errors were found. I wander whether the source in dkms was somehow altered, and a reinstall may solve the problem. And installing a new version from bpo is, of course, a way of reinstallation. Thanks, Shengqi Chen
Bug#1060305: libifd-cyberjack6: Package is out of date. 3 new hardware devices are not supported, which are already supported in upstream
Package: libifd-cyberjack6 Version: 3.99.5final.sp14-2 Severity: important Tags: a11y upstream X-Debbugs-Cc: s...@kernelport.com, siret...@tauware.de, kreuzritter2...@gmx.de The current version available in the Debain Stable's (12) repository is 3.99.5final.sp14-2 and 3.99.5final.sp14-2+b1 in unstable (SID). But the manufacturer's version is 3.99.5final.sp16. See here for the upstream deb package: https://support.reiner-sct.de/downloads/LINUX/V3.99.5_SP16/libifd- cyberjack6_3.99.5final.sp16_amd64_d12.deb And the source release: https://support.reiner-sct.de/downloads/LINUX/V3.99.5_SP16/pcsc- cyberjack-3.99.5final.SP16.tar.bz2 The changelog of this much newer version 3.99.5final.sp16 shows the following: Begin changelog: pcsc-cyberjack (3.99.5final.sp16) unstable; urgency=low * add REINER SCT cyberJack RFID standard EN -- Frank Neuber Thu, 26 Oct 2023 22:46:54 +0200 pcsc-cyberjack (3.99.5final.sp15) unstable; urgency=low * add REINER SCT cyberJack wave HUN * add REINER SCT cyberJack RFID komfort FON -- Frank Neuber Fri, 01 Oct 2021 08:11:04 + pcsc-cyberjack (3.99.5final.sp14) unstable; urgency=low * Update to the Reiner-SCT repository rev cyberJack@1454 -- Frank Neuber Mon, 02 Dec 2019 16:57:46 +0100 ### End changelog This means, that the devices: * REINER SCT cyberJack RFID standard EN * REINER SCT cyberJack wave HUN and * REINER SCT cyberJack RFID komfort FON are not supported in the current version of Debian. The device REINER SCT cyberJack RFID komfort FON device is for users with disabilities. As of now, all three devices are not supported by Debian 12 because this package is out of date. You should also read bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010675 It might be related to this bug #1010675, because the new upstream version ships as .bz2 file and in the other bug report has someone mentioned, that the old uscan filter does only search for .tar.gz files. But this is definitely not a minor bug, like the this other bug report claims, when you can't use these new three devices. The devices * REINER SCT cyberJack wave HUN and * REINER SCT cyberJack RFID komfort FON got a patch in upstream on Fri, 01 Oct 2021. Debian stable was released in June 10, 2023. So it's high time that the new version is added to Debian SID and a Debian backport version for Debian 12 or an update with the next Debian 12 point release is added. After all, this is about driver support and support for new hardware. -- 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/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 libifd-cyberjack6 depends on: ii libc6 2.36-9+deb12u3 ii libgcc-s1 12.2.0-14 ii libstdc++612.2.0-14 ii libusb-1.0-0 2:1.0.26-1 ii pcscd 1.9.9-2 libifd-cyberjack6 recommends no packages. Versions of packages libifd-cyberjack6 suggests: ii pcsc-tools 1.6.2-1 -- no debconf information changelog.Debian.gz Description: application/gzip
Bug#1058083: Before I try to tackle this bug - can we move the package to DPT
Hi Ulises, Am Sun, Jan 07, 2024 at 09:18:46AM -0300 schrieb Ulises Vitulli: > Feel free to go ahead with my blessing right away! Bug fixed in a team upload on behalf of Debian Python Team. Kind regards Andreas. -- http://fam-tille.de
Bug#1059484: rasdaemon: autopkgtest failure: cannot access '/var/lib/rasdaemon/ras-mc_event.db'
I am enlightened by Paul https://lists.debian.org/debian-ci/2024/01/msg0.html and Simon https://lists.debian.org/debian-ci/2024/01/msg4.html . I will try to resolve this issue by introducing iso-machine and more portable tests. -tai On Wed, Dec 27, 2023 at 9:46 PM Taihsiang Ho (tai271828) wrote: > > Hi Paul, > > Thanks for reporting the issue. I will take a look. > > -tai > > On Tue, Dec 26, 2023 at 7:09 PM Paul Gevers wrote: > > > > Source: rasdaemon > > Version: 0.8.0-1 > > Severity: serious > > User: debian...@lists.debian.org > > Usertags: fails-always > > > > Dear maintainer(s), > > > > You recently added an autopkgtest to your package rasdaemon, great. > > However, it fails. Currently this failure is blocking the migration to > > testing [1]. Can you please investigate the situation and fix it? > > > > I copied some of the output at the bottom of this report. > > > > More information about this bug and the reason for filing it can be found on > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > > > Paul > > > > [1] https://qa.debian.org/excuses.php?package=rasdaemon > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/rasdaemon/40156577/log.gz > > > > 34s ls: cannot access '/var/lib/rasdaemon/ras-mc_event.db': No such > > file or directory > > 34s autopkgtest [11:52:08]: test ras-mc-ctl
Bug#1060259: Acknowledgement (zfs-dkms: Fails to build after upgrade to linux-image-6.1.0-17-amd64)
Tried upgrading to backports as suggested in Debian Wiki: https://wiki.debian.org/ZFS#Installation and issue seems to be fixed there. Using version (2.2.2-3~bpo12+1) After: apt install -t bookworm-backports zfsutils-linux zfs-dkms DKMS module builds for both 6.1.0-15-amd64 and 6.1.0-17-amd64 succeeded.
Bug#1060303: iperf3: a new version has released is 3.16 not 3.16-beta1
X-Debbugs-CC: ro...@debian.org On Tue, 09 Jan 2024 05:58:52 + Poao wrote: > Package: iperf3 > Version: 3.15-1+b1 > Severity: wishlist > X-Debbugs-Cc: zongb...@icloud.com > > this package latest version 3.16 is not beta since 2023-11-30. and its > upstream has released it since 2023-12-02. The proposed patch for debian/watch file is provided in the attachment. I am not tagging the "patch" tag since a new upload with new version is needed anyway. Meanwhile, it would be great if v3.16 is packaged given its new multithreading support and improved OpenSSL 3 support. Please check upstream release notes for details. Thanks, Boyuan Yang From b6e7c7bf0feb3403d452672d3be3a55ba318db5f Mon Sep 17 00:00:00 2001 From: Boyuan Yang Date: Tue, 9 Jan 2024 01:40:18 -0500 Subject: [PATCH] debian/watch: Handle version with dash --- debian/watch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/watch b/debian/watch index 2506a87..1a9d743 100644 --- a/debian/watch +++ b/debian/watch @@ -1,3 +1,3 @@ version=4 -opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/iperf-$1\.tar\.gz/ \ +opts="uversionmangle=s/-/~/,filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/iperf-$1\.tar\.gz/" \ https://github.com/esnet/iperf/tags .*/v?(\d\S+)\.tar\.gz -- 2.43.0 signature.asc Description: This is a digitally signed message part
Bug#1060304: zenity: bring back preselection of nonexisting file names with --save
Package: zenity Version: 4.0.1-1 Severity: normal X-Debbugs-Cc: rz49...@gmx.net Dear Maintainer, having used zenity sporadically (ie. in a self-written script wrapping scanimage and PDF generation from the scans for archiving of documents), I recently noticed that it is not possible anymore to preselect a not-yet- existing filename using the options combination --file-selection --save --filename=path/to/new-file (assuming the path/to directory exists) using zenity from sid. The file name field stays empty. I noticed this bevaviour in the past few days, so it had already been present in version 4.0.0-1. In the zenity version contained in bookworm (3.44.0), the suggested new file name appears in the dialog as expected, so this might be a regression caused by upstream changes. Kind regards Rainer -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zenity depends on: ii libadwaita-1-0 1.4.2-1+b1 ii libc6 2.37-13 ii libglib2.0-02.78.3-1 ii libgtk-4-1 4.12.4+ds-3 ii libpango-1.0-0 1.51.0+ds-3 ii zenity-common 4.0.1-1 zenity recommends no packages. zenity suggests no packages. -- no debconf information
Bug#1060288: locales: Please allow selection of C.UTF-8 when (re)configuring locales
Hi, On 2024-01-08 22:06, Axel Scheepers wrote: > Package: locales > Version: 2.36-9+deb12u3 > Severity: wishlist > Tags: d-i l10n > > Dear Maintainer, > > It would be nice to have C.UTF-8 in the list which dpkg-reconfigure locales > shows; When installing a desktop I usually select the C locale since the C.UTF-8 is not shown on purpose, because it doesn't need to be generated, it is always available on the system. What you want is probably to be able to select it as a default locale. The real issue is that the menu to select the default locale is only shown if there is a locale to generate. > others don't really apply and I'm unable to use a different locale setting > for date and lang. This however breaks gnome since it requires a utf-8 > locale and I'm unable to select C.UTF-8 at installation. > A workaround is to uncomment the C.UTF-8 locale in /etc/locale.gen > and run dpkg-reconfigure locales after installation. A better workaround is probably to select a random locale to be generated, then you should be able to select the C.UTF-8 locale as default. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1052902: yosys: FTBFS: make[2]: *** [Makefile:971: docs/gen_images] Error 2
On 03/12/23 at 19:00 +0100, Daniel Gröber wrote: > Hi Lucas, > > On Thu, Oct 26, 2023 at 09:45:53AM +0200, Lucas Nussbaum wrote: > > As an additional data point, I can still reproduce this. > > I cannot provide the buildinfo, as sbuild outputs it at the end of > > successful builds. > > Doh! Didn't think of that. Something to improve in sbuild I guess :) > > > However, in the build log there's the list of installed packages, which > > might be sufficient... > > Since I've sucessfully rebuilt yosys agains unstable and it's still failing > for you it's pretty much moot. I just thought you'd have the buildinfos at > hand. > > I'm essentially waiting for make 4.4 to make it into Debian as Santiago > pointed out it may help track this down, but if I can't repro this (and I > have still never seen this) there's not much I can do without access to a > system this repros on. > > If you can reliably reproduce this could you try doing a -j1 rebuild? That > should at least tell us if it's a concurrency issue or not. Hi, I confirm that it still fails, but succeeds when building with DEB_BUILD_OPTIONS=parallel=1 So yes, it's a concurrency issue. Lucas
Bug#1060303: iperf3: a new version has released is 3.16 not 3.16-beta1
Package: iperf3 Version: 3.15-1+b1 Severity: wishlist X-Debbugs-Cc: zongb...@icloud.com this package latest version 3.16 is not beta since 2023-11-30. and its upstream has released it since 2023-12-02. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-cloud-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iperf3 depends on: ii adduser3.137 ii debconf [debconf-2.0] 1.5.83 ii init-system-helpers1.66 ii libc6 2.37-13 ii libiperf0 3.15-1+b1 iperf3 recommends no packages. iperf3 suggests no packages. -- debconf information: * iperf3/start_daemon: false
Bug#1060299: libboost1.83-dev: After installing libboost-all-dev I can't perform an upgrade anymore
Hi, thanks for the bugreport. You have a nice mix of many third-party repos in the /etc/apt/sources.list, which can break the installation. Regards Anton Am Di., 9. Jan. 2024 um 03:00 Uhr schrieb Harald : > ~# apt-get update && apt-get upgrade > Get:1 > http://download.opensuse.org/repositories/home:/hawkeye116477:/waterfox/Debian_Unstable > InRelease [1,594 B] > Hit:2 http://security.debian.org testing-security InRelease > Get:3 > http://download.opensuse.org/repositories/home:/stevenpusser/Debian_10 > InRelease [1,547 B] > Hit:4 https://noone.org/conkeror-nightly-debs sid InRelease > Hit:5 https://deb.opera.com/opera-stable stable InRelease > Hit:6 http://packages.microsoft.com/repos/code stable InRelease > Hit:8 https://dl.winehq.org/wine-builds/debian trixie InRelease > Hit:9 https://updates.signal.org/desktop/apt xenial InRelease > Hit:10 http://ftp.de.debian.org/debian sid InRelease > Hit:7 https://debian.qgis.org/debian-nightly sid InRelease > :
Bug#1060302: RFS: quickemu/4.9.2-1 [RFP] -- quickly create and run optimised virtual machines
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: 1018...@bugs.debian.org, ben...@debian.org Dear mentors, I am looking for a sponsor for my package "quickemu": * Package name : quickemu Version : 4.9.2-1 Upstream contact : https://github.com/quickemu-project/quickemu/issues * URL : https://github.com/quickemu-project/quickemu * License : Expat * Vcs : https://salsa.debian.org/Maytha8/quickemu Section : utils The source builds the following binary packages: quickemu - quickly create and run optimised virtual machines To access further information about this package, please visit the following URL: https://mentors.debian.net/package/quickemu/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/q/quickemu/quickemu_4.9.2-1.dsc Changes for the initial release: quickemu (4.9.2-1) UNRELEASED; urgency=medium . * Initial release. (Closes: #1018072) Kind regards, Maytham signature.asc Description: This is a digitally signed message part
Bug#1060300: virt-v2v: needs to update OVMF x86_64 pflash images path to match the new 4MB images
Source: virt-v2v Version: 2.2.0-1 Severity: important Tags: upstream patch X-Debbugs-Cc: Lee Garrett Dear maintainer, With edk2 2023.11-2, the OVMF 2MB pflash images have been removed and replaced with their 4MB counterparts. See https://salsa.debian.org/qemu-team/edk2/-/blob/76f721d51f93647a8f3650f9f26593ff82089ad0/debian/ovmf.NEWS Currently, virt-v2v is unable to convert a Win 11 image (from ova to qcow2) since it is not able to find the UEFI files. ovmf 2023.11-3 is currently installed on my system. virt-v2v -v -x -i ova -o libvirt -of qcow2 -oo compressed -oc 'qemu:///system' ~/.cache/ansible_bootstrap_win11_vm/win11.zip -on win11 fails with: virt-v2v: error: cannot find firmware for UEFI guests. You probably need to install OVMF (x86-64), or AAVMF (aarch64) I can provide a full log, if needed A fix can be found in https://salsa.debian.org/santiago/virt-v2v/-/commits/OVMF-4M Cheers, -- Santiago -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information signature.asc Description: PGP signature
Bug#1060274: RFS: python-acora/2.4-1.1 [NMU] [RC] -- fast multi-keyword text search engine (Python 2)
tags -1 - moreinfo Hi, On Tue, Jan 9, 2024 at 5:15 AM Bastian Germann wrote: > > Control: tags -1 moreinfo > > Please check the archive before posting NMUs based on old versions. > Also, a new upstream version needs the NMU revision -0.1, not -1.1. Thanks for pushing updated upload to debian salsa repo. This is become easy to update upstream release. so Dear mentors, I am looking for a sponsor for my package "python-acora": * Package name : python-acora Version : 2.4-0.1 Upstream contact : [fill in name and email of upstream] * URL : https://pypi.python.org/pypi/acora * License : BSD-3-Clause * Vcs : https://salsa.debian.org/debian/python-acora Section : python The source builds the following binary packages: python3-acora - fast multi-keyword text search engine (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-acora/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-acora/python-acora_2.4-0.1.dsc Changes since the last upload: python-acora (2.4-0.1) unstable; urgency=medium . * Non-maintainer upload. [ Bastian Germann ] * Remove .git suffix from Vcs-Browser . [ Bo YU ] * New upstream version 2.4. (Closes: #1056849, #1055707) Please let me know any issues. BR, Bo >
Bug#1058106: python-ml-collections: FTBFS: ModuleNotFoundError: No module named 'imp'
Hi,
I have modified the previous patch in my last report to fix the
autopkgtest errors. Attaching the updated debdiff file.
Cheers!
diff -Nru python-ml-collections-0.1.1/debian/changelog
python-ml-collections-0.1.1/debian/changelog
--- python-ml-collections-0.1.1/debian/changelog2023-04-01
05:59:28.0 +
+++ python-ml-collections-0.1.1/debian/changelog2024-01-08
20:00:00.0 +
@@ -1,3 +1,16 @@
+python-ml-collections (0.1.1-3) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Included a patch for ml_collections/config_flags/config_flags.py
+to replace deprecated imp with importlib to fix ModuleNotFoundError
+in Python 3.12. (Closes: #1058106)
+ * Added python3-absl, python3-contextlib2, python3-yaml, python3-six
+to tests-depends.
+ * Added python3-six to Build-Depends and Depends in d/control.
+ * Disabled 2 bazel tests in autopkgtest.
+
+ -- Yogeswaran Umasankar Mon, 08 Jan 2024 20:00:00 +
+
python-ml-collections (0.1.1-2) unstable; urgency=medium
* Team Upload.
diff -Nru python-ml-collections-0.1.1/debian/control
python-ml-collections-0.1.1/debian/control
--- python-ml-collections-0.1.1/debian/control 2023-04-01 05:59:04.0
+
+++ python-ml-collections-0.1.1/debian/control 2024-01-08 20:00:00.0
+
@@ -7,6 +7,7 @@
dh-python,
python3-all,
python3-setuptools,
+ python3-six,
python3-absl ,
python3-contextlib2 ,
python3-yaml
@@ -22,7 +23,8 @@
Depends: ${python3:Depends}, ${misc:Depends},
python3-absl,
python3-contextlib2,
- python3-yaml
+ python3-yaml,
+ python3-six
Suggests: python-is-python3
Description: collections designed for ML usecases
The package provices two classes called ConfigDict and FrozenConfigDict that
diff -Nru
python-ml-collections-0.1.1/debian/patches/002_imp-module-replacement.patch
python-ml-collections-0.1.1/debian/patches/002_imp-module-replacement.patch
--- python-ml-collections-0.1.1/debian/patches/002_imp-module-replacement.patch
1970-01-01 00:00:00.0 +
+++ python-ml-collections-0.1.1/debian/patches/002_imp-module-replacement.patch
2024-01-08 20:00:00.0 +
@@ -0,0 +1,27 @@
+Description: Implemented importlib to fix ModuleNotFoundError with Python 3.12.
+Author: Yogeswaran Umasankar
+Last-Update: 2024-01-08
+
+--- a/ml_collections/config_flags/config_flags.py
b/ml_collections/config_flags/config_flags.py
+@@ -16,7 +16,7 @@
+ """Configuration commmand line parser."""
+
+ import errno
+-import imp
++import importlib.util
+ import os
+ import re
+ import sys
+@@ -450,8 +450,9 @@ def _LoadConfigModule(name: str, path: s
+
+ # Works for relative paths.
+ with ignoring_errors.Attempt('Relative path', path):
+-config_module = imp.load_source(name, path)
+-return config_module
++ spec = importlib.util.spec_from_file_location(name, path)
++ config_module = importlib.util.module_from_spec(spec)
++ spec.loader.exec_module(config_module)
+
+ # Nothing worked. Log the paths that were attempted.
+ raise IOError('Failed loading config file {}\n{}'.format(
diff -Nru python-ml-collections-0.1.1/debian/patches/series
python-ml-collections-0.1.1/debian/patches/series
--- python-ml-collections-0.1.1/debian/patches/series 2023-04-01
05:50:43.0 +
+++ python-ml-collections-0.1.1/debian/patches/series 2024-01-08
20:00:00.0 +
@@ -1 +1,2 @@
noRequirements.patch
+002_imp-module-replacement.patch
diff -Nru python-ml-collections-0.1.1/debian/tests/control
python-ml-collections-0.1.1/debian/tests/control
--- python-ml-collections-0.1.1/debian/tests/control2023-04-01
05:56:46.0 +
+++ python-ml-collections-0.1.1/debian/tests/control2024-01-08
20:00:00.0 +
@@ -1,3 +1,3 @@
Tests: run-unit-test
-Depends: @, bazel-bootstrap, python3-mock, python-is-python3
+Depends: @, bazel-bootstrap, python3-mock, python-is-python3, python3-absl,
python3-contextlib2, python3-yaml, python3-six
Restrictions: allow-stderr, skip-not-installable
diff -Nru python-ml-collections-0.1.1/debian/tests/run-unit-test
python-ml-collections-0.1.1/debian/tests/run-unit-test
--- python-ml-collections-0.1.1/debian/tests/run-unit-test 2023-04-01
05:50:43.0 +
+++ python-ml-collections-0.1.1/debian/tests/run-unit-test 2024-01-08
20:00:00.0 +
@@ -22,5 +22,6 @@
cp ${CUR_DIR}/debian/tests/data/BUILD.flags_examples
${pkg}/config_flags/examples/BUILD
cp ${CUR_DIR}/debian/tests/data/BUILD.test_flags
${pkg}/config_flags/tests/BUILD
-bazel test ml_collections/...
+bazel test ml_collections/...
--test_filter=-//ml_collections/config_dict/examples:examples_test,-//ml_collections/config_flags/tests:config_overriding_test
+#For time being disabled two tests in bazel to avoid autopkgtest error.
echo "PASS"
signature.asc
Description: PGP
Bug#1060299: libboost1.83-dev: After installing libboost-all-dev I can't perform an upgrade anymore
Package: libboost1.83-dev Version: 1.83.0-2 Severity: normal Dear Maintainer, after installing libboost-all-dev I can't perform an upgrade anymore. On 2023-12-27 I installed libboost-all-dev and removed everything from previous boost versions without getting an error or even a warning: >From /var/log/apt/history: """ Start-Date: 2023-12-27 14:20:04 Commandline: apt-get install libboost-all-dev ... Start-Date: 2023-12-27 14:23:48 Commandline: apt-get autoremove ... Start-Date: 2023-12-27 14:34:28 Commandline: apt-get remove libboost-filesystem1.74.0 libboost-iostreams1.74.0 libboost-thread1.74.0 ... Start-Date: 2023-12-27 14:23:48 Commandline: apt-get autoremove ... Start-Date: 2023-12-27 14:34:28 Commandline: apt-get remove libboost-filesystem1.74.0 libboost-iostreams1.74.0 libboost-thread1.74.0 ... Start-Date: 2023-12-27 14:41:09 Commandline: apt-get autoremove """ ~# apt-get update && apt-get upgrade Get:1 http://download.opensuse.org/repositories/home:/hawkeye116477:/waterfox/Debian_Unstable InRelease [1,594 B] Hit:2 http://security.debian.org testing-security InRelease Get:3 http://download.opensuse.org/repositories/home:/stevenpusser/Debian_10 InRelease [1,547 B] Hit:4 https://noone.org/conkeror-nightly-debs sid InRelease Hit:5 https://deb.opera.com/opera-stable stable InRelease Hit:6 http://packages.microsoft.com/repos/code stable InRelease Hit:8 https://dl.winehq.org/wine-builds/debian trixie InRelease Hit:9 https://updates.signal.org/desktop/apt xenial InRelease Hit:10 http://ftp.de.debian.org/debian sid InRelease Hit:7 https://debian.qgis.org/debian-nightly sid InRelease Fetched 3,141 B in 1s (3,176 B/s) Reading package lists... Done Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libboost1.83-dev : Conflicts: libboost1.81-dev but 1.81.0-7+b1 is to be installed E: Broken packages - additional information: ~# apt-cache policy libboost1.83-dev libboost1.83-dev: Installed: 1.83.0-2 Candidate: 1.83.0-2 Version table: *** 1.83.0-2 500 500 http://ftp.de.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status ~# apt-cache policy libboost1.81-dev libboost1.81-dev: Installed: (none) Candidate: 1.81.0-7+b1 Version table: 1.81.0-7+b1 500 500 http://ftp.de.debian.org/debian sid/main amd64 Packages Actually I don't have a single package from boost1.81 or earlier installed. All installed boost-packages contain 83: ~# dpkg -l *boost* |grep "^ii" |grep -v 83 ~# - Trying a dist-upgrade would seemingly fix the libboost issue. At least the "E: Broken packages" doesn't appear there. However, dry-running it (apt-get -s dist-upgrade), reveals the process would remove the package initscripts. It seems too risky to me to do so. Can I even be sure the systemwould come up? (Both /usr/sbin/init and /sbin/init are symlinks to /lib/systemd/systemd, so I assume I'm on systemd.) Since I'm not a weathered sysadmin I'm not sure whether I'd be able to handle a fully dysfunctional system. Can you please advise me on how to proceed? Thanks and cheers Harald PS: reportbug created this message but tried to send it with sendmail (not configured for remote sending)- So I reassembled the email from /var/spool/exim4 I hope I didn't miss anything important. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.8-amd64 (SMP w/24 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=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libboost1.83-dev depends on: ii libstdc++-13-dev 13.2.0-9 libboost1.83-dev recommends no packages. Versions of packages libboost1.83-dev suggests: ii libboost-atomic1.83-dev 1.83.0-2 ii libboost-chrono1.83-dev 1.83.0-2 ii libboost-container1.83-dev1.83.0-2 ii libboost-context1.83-dev 1.83.0-2 pn libboost-contract1.83-dev ii libboost-coroutine1.83-dev1.83.0-2 ii libboost-date-time1.83-dev1.83.0-2 ii libboost-exception1.83-dev1.83.0-2 ii libboost-fiber1.83-dev1.83.0-2 ii libboost-filesystem1.83-dev 1.83.0-2 ii libboost-graph-parallel1.83-dev 1.83.0-2 ii libboost-graph1.83-dev1.83.0-2 ii
Bug#1060298: pocl: update llvm version in debian/control
Source: pocl
Version: 4.0-3
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn
Dear Maintainer,
Please update llvm version in debian/control, thanks! The latest
version of LLVM is 16 in Debian. Convenient support for more new
architectures.
-- System Information:
Debian Release: trixie/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)
Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968)
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 318a56cba2c1fe681fc453fdf91858f6ca66e993 Mon Sep 17 00:00:00 2001
From: Zhang Na
Date: Mon, 8 Jan 2024 10:02:05 +
Subject: [PATCH] update llvm-16 in debian/control
---
debian/control | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/debian/control b/debian/control
index db25d45..a732143 100644
--- a/debian/control
+++ b/debian/control
@@ -7,10 +7,10 @@ Uploaders: Vincent Danjean ,
Build-Depends:
debhelper-compat (= 13),
gcc (>= 4:13),
- clang-15,
- libclang-15-dev,
- libclang-cpp15-dev,
- llvm-15-dev,
+ clang-16,
+ libclang-16-dev,
+ libclang-cpp16-dev,
+ llvm-16-dev,
cmake,
libhwloc-dev,
ocl-icd-dev,
--
2.43.0
--- debian/libpocl2.symbols (libpocl2_4.0-3_loong64)
+++ dpkg-gensymbolsd953pV 2024-01-08 10:12:19.307182559 +
@@ -25,40 +25,40 @@
_ZGVZNKSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb1ELb0EEclEcE5__nul@Base
3.0
_ZGVZNKSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb1ELb1EEclEcE5__nul@Base
3.0
_ZN4pocl23eraseFunctionAndCallersEPN4llvm8FunctionE@Base 1.8-3~visibility
-#MISSING: 1.8#
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE12emplace_backIJS5_EEEvDpOT_@Base
0.11
-#MISSING: 1.8#
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJRKS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
0.13-9~llvm3.8+gcc7
-#MISSING: 1.8#
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
0.13-9~llvm3.8+gcc7
-#MISSING: 1.8#
(optional=templinst)_ZNSt6vectorIPKcSaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
0.13-9~llvm3.8+gcc7
-#MISSING: 1.8#
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceE{size_t}{size_t}PKc{size_t}@Base
1.6-2~hardening
+#MISSING: 4.0-3#
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE12emplace_backIJS5_EEEvDpOT_@Base
0.11
+#MISSING: 4.0-3#
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJRKS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
0.13-9~llvm3.8+gcc7
+#MISSING: 4.0-3#
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
0.13-9~llvm3.8+gcc7
+#MISSING: 4.0-3#
(optional=templinst)_ZNSt6vectorIPKcSaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
0.13-9~llvm3.8+gcc7
+#MISSING: 4.0-3#
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceE{size_t}{size_t}PKc{size_t}@Base
1.6-2~hardening
#MISSING: 1.8#
(optional=templinst|arch=mipsel)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@Base
1.1-6~llvm6.0+gcc8
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE15_M_replace_coldEPc{size_t}PKc{size_t}{size_t}@Base
4.0-2~gcc13
-#MISSING: 1.8#
(optional=templinst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE4swapERS4_@Base
1.6-2~hardening
-#MISSING: 1.8#
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_appendEPKc{size_t}@Base
1.6-2~hardening
-#MISSING: 1.8#
(optional=templinst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_assignERKS4_@Base
1.6-2~hardening
-#MISSING: 4.0-2~gcc13#
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_mutateE{size_t}{size_t}PKc{size_t}@Base
4
- (optional=templinst|arch=amd64 arm64 mips64el ppc64el riscv64
sparc64)_ZNSt8_Rb_treeIN3spv10DecorationES1_St9_IdentityIS1_ESt4lessIS1_ESaIS1_EE16_M_insert_uniqueIRKS1_EESt4pairISt17_Rb_tree_iteratorIS1_EbEOT_@Base
4
-#MISSING: 1.8#
(optional=templinst)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE24_M_get_insert_unique_posERKS5_@Base
1.0
-#MISSING: 1.8#
Bug#1060297: acmetool's systemd timer is stopped when the package is upgraded
Package: acmetool Version: 0.2.2-2+b1 Severity: normal Dear Maintainer, I installed acmetool a while ago, with the systemd timer unit to keep my certificates refreshed, and I've generally been very happy with it. However, sometimes Let's Encrypt emails me that my certificates are about to expire, and when I check, the systemd timer unit is stopped, and I have been unable to figure out why. Today there was an updated acmetool package, and I caught it in the act. Before I ran "apt upgrade", acmetool was scheduled: ``` $ sudo systemctl list-timers --all NEXT LEFT LAST PASSED UNIT --- -- Tue 2024-01-09 12:27:46 AEDT 1h 18min Tue 2024-01-09 00:21:01 AEDT 10h ago acmetool.timer ``` I then ran "apt upgrade", which completed successfully without errors or warnings. Suddenly, the timer unit had been deactivated: ``` $ sudo systemctl list-timers --all NEXT LEFT LAST PASSED UNIT -- --- -- - - Tue 2024-01-09 00:21:01 AEDT 10h ago acmetool.timer ``` And sure enough, although the unit was still loaded and "enabled" (which I understand means "automatically activated") it was now inactive: ``` $ sudo systemctl status acmetool.timer ○ acmetool.timer - Reconcile Let's Encrypt certificates twice daily Loaded: loaded (/usr/lib/systemd/system/acmetool.timer; enabled; preset: enabled) Active: inactive (dead) since Tue 2024-01-09 11:09:26 AEDT; 1min 59s ago Duration: 3d 22h 57min 44.320s Trigger: n/a Triggers: ● acmetool.service Jan 05 12:11:41 boombah systemd[1]: Started acmetool.timer - Reconcile Let's Encrypt certificates twice daily. Jan 09 11:09:26 boombah systemd[1]: acmetool.timer: Deactivated successfully. Jan 09 11:09:26 boombah systemd[1]: Stopped acmetool.timer - Reconcile Let's Encrypt certificates twice daily. ``` I'm open to the possibility that I have somehow misconfigured systemd in a way that causes this unit (and no others) to be deactivated, but I did follow the instructions in the README.Debian.gz file to set it up. Thank you for packaging such a useful tool! -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 acmetool depends on: ii libc62.37-13 ii libcap2 1:2.66-4+b2 Versions of packages acmetool recommends: ii dialog 1.3-20231002-1 acmetool suggests no packages. -- no debconf information
Bug#1060296: virt-v2v: Wrong dependency on nbdkit-pthon-plugin
Package: virt-v2v
Version: 2.4.0-1
Severity: serious
Tags: patch
X-Debbugs-Cc: Lee Garrett
Dear maintainer,
virt-v2v 2.4.0-1 is not installable since it depends on a wrongly listed
package: nbdkit-python-plugin. The correct name is nbdkit-plugin-python.
I also suggests nbdkit-vddk-plugin, that doesn't exist.
I am preparing a MR that includes this fix. But the following simple
change solves the issue:
diff --git a/debian/control b/debian/control
index 313dba7..08de83e 100644
--- a/debian/control
+++ b/debian/control
@@ -33,7 +33,7 @@ Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends},
libnbd-bin,
nbdkit,
- nbdkit-python-plugin,
+ nbdkit-plugin-python,
qemu-utils,
Suggests: rhsrvany, nbdkit-vddk-plugin
-- System Information:
Debian Release: trixie/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'oldstable-updates'), (500,
'oldstable-security'), (500, 'oldoldstable-updates'), (500, 'oldoldstable'),
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages virt-v2v depends on:
ii libc62.37-13
ii libglib2.0-0 2.78.3-1
ii libguestfs0 1:1.50.1-4+b3
ii libjansson4 2.14-2
ii libnbd0 1.18.1-1
ii libosinfo-1.0-0 1.11.0-2
ii libpcre2-8-0 10.42-4
ii libvirt0 9.10.0-1
ii libxml2 2.9.14+dfsg-1.3+b1
virt-v2v recommends no packages.
virt-v2v suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
Bug#1060295: boost1.83: not have sufficient long double support issue on ppc64le
Source: boost1.83 Severity: important X-Debbugs-Cc: calcu...@rezozer.net Dear Maintainer, it appears that the current graph-tool package (version 2.59+ds-1) fails to build on ppc64le arch because a `static assertion (fails)`. The message from the compiler is: /usr/include/boost/math/tools/promotion.hpp:267:27: error: static assertion failed: \ Sorry, but this platform does not have sufficient long double support for the special \ functions to be reliably implemented. Best, Jerome System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 5.10.0-27-powerpc64le (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect
Bug#1057498: Additional information
Control: retitle 1057498 cryptacular: FTBFS with bouncycastle 1.72 Control: usertag 1057498 -default-java21 Dear Maintainers, The issue with ftbfs was caused by the API changes in bouncycastle 1.72. There are no Java 21 specific changes needed. Would it be possible to consider a merge request[1] that addresses this issue? Best Regards, Vladimir. [1] https://salsa.debian.org/java-team/cryptacular/-/merge_requests/1
Bug#1057497: Additional information
Dear Maintainers, Would it be possible to consider a merge request[1] that addresses this issue? Best Regards, Vladimir. [1] https://salsa.debian.org/java-team/commons-pool/-/merge_requests/2
Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
On Fri, Sep 01, 2023 at 12:06:40PM +0100, Simon McVittie wrote: > Package: spectrwm > Version: 3.4.1-3 > Severity: normal > User: xdg-desktop-por...@packages.debian.org > Usertags: portals.conf Hi Simon, apologies for taking a while to get back to you. I'm actively looking into this now. > Suggested fix > = > > Add a sequence of semicolon-separated desktop environment names to > /usr/share/xsessions/spectrwm.desktop, most likely just "spectrwm": > > DesktopNames=spectrwm; This makes perfect sense, and would also be totally suitable for upstream, where spectrwm.desktop already lives. I'll prepare a patch and propose it there. Just out of curiosity, is there any advantage to having the trailing semicolon in this case? We only have a single item in the list after all. > And then create a /usr/share/xdg-desktop-portal/spectrwm-portals.conf > with whatever portal backends are desired for a spectrwm session, > for example perhaps this: > > [preferred] > default=gtk; This feels more suitable for a downstream patch, would you agree? Gtk is probably the most reasonable choice: not only it matches the existing default, but it's also somewhat more lightweight in that it doesn't drag in a dozen libraries like the KDE implementation does. Honestly, neither quite fits with spectrwm's aesthetic... We'd probably want an old school, unthemed Gtk 2 implementation or something like that. Shame it doesn't seem to exist. Oh well :) By the way, while playing around with this to understand how the various pieces fit together I noticed that there seems to be a significant amount of caching going on. By this I mean that I have configured spectrwm to prefer Gtk and WindowMaker to prefer KDE, and after using one of the two, logging out and switching to the other one doesn't seems to be enough to get the other implementation to run: I have to reboot the machine, or at the very least kill all user processes even remotely related to the desktop portal. Is this expected? It certainly took me a bit to wrap my head around it, but I guess it's fine as long as users don't constantly hop between different sessions... -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1060294: python-cryptography: Please update for rust-pem 1.1
Source: python-cryptography Version: 41.0.7-1 Severity: serious Tags: ftbfs X-Debbugs-CC: kapo...@melix.org rust-pem 1.1 is now in Debian Unstable. Please drop the rust-pem 1.0 patch and update Build-Depends to build with this new version. Thank you, Jeremy Bícha
Bug#1060236: openjdk-8 adds zero build for loong64
Hi, >I hope this email finds you well. We would like to add openjdk-8 zero >build support for loong64. thank you, queued (in the next days there will be an update of that anyway). Why do you disable pulse? Does it not work? Or is it just because libpulse-dev was not available until yesterday? Or did something (like icedtea-sound) not build? Thanks, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#1059694: filezilla 3.63.0-1+deb12u3 flagged for acceptance
package release.debian.org tags 1059694 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: filezilla Version: 3.63.0-1+deb12u3 Explanation: prevent 'Terrapin' exploit [CVE-2023-48795]
Bug#1059693: filezilla 3.52.2-3+deb11u1 flagged for acceptance
package release.debian.org tags 1059693 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: filezilla Version: 3.52.2-3+deb11u1 Explanation: prevent 'Terrapin' exploit [CVE-2023-48795]
Bug#1060209: [Debian-iot-maintainers] Bug#1060209: libopenzwave1.6 install hundreds of data files and images in /etc
Hello, Le 2024-01-07 à 10 h 42, Gioele Barabucci a écrit : libopenzwave1.6 currently installs 1489 in /etc, including 635 PNG images, 9 JPEG images, and 1 Zip file. These files are obviously not conffiles but are treated as such. Could they be moved under /usr, for example under /usr/share/openzwave? I suggest instead not to install images or zip files, they are not relevant I think. I've updated the package in salsa with other changes, I'll run some tests on my own to make sure it works fine with my use cases. If all good, I'll upload the fixed package later then. /Nicolas
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote: > Hi Steve, > On 05-01-2024 17:36, Rene Engelhard wrote: > > Also a problem is that experimental also might already contain totally > > unrelated updates like new upstream versions... > I share this worry. Have you thought about how to handle the cases where you > don't have experimental to upload to? How big is this problem? > Another worry, how will you provide the required changes to the maintainers > of the packages? Via BTS? For those working on salsa: MR? Both? Something > else? Obviously we should not end in the situation that a new upload goes > back to the old name (or are the ftp-masters so keen on this transition that > that won't happen? But what about newer versions with the old name already > in experimental, conform the former worry?). I've seen NMU's being ignored > by subsequent uploads by the maintainer, even when they fixed RC issues > which were then reintroduced. I would intend to provide diffs via the BTS. This remains the standard policy for NMUs in Debian per the Developer's Reference, and as far as I know has worked effectively for all such previous ABI transitions. I think it is reasonable to expect maintainers to pay attention to their bug mail as our defined Debian process. I don't think it would be reasonable to expect people working on cross-archive toolchain transitions to cater to individual maintainer preference in this regard. If a maintainer ignores the NMU and drops the rename, they'll be introducing a new library transition again on 32-bit archs. Won't they also be caught again in binary NEW, for those packages that don't have the same runtime library package name in experimental? It seems to me there's ample opportunity to catch such mistakes if they happen. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1060292: Flash-kernel add Sipeed Lichee Pi 4A - merge request
Merge request: https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/54
Bug#1060293: gnome-nettool: Aborts with assert failure: *** stack smashing detected ***
Package: gnome-nettool Version: 42.0-1 Severity: important X-Debbugs-Cc: sudipm.mukher...@gmail.com Dear Maintainer, gnome-nettool crashes with the message "assert failure: *** stack smashing detected ***". Steps to reproduce: 1. Open gnome-nettool 2. Select the lookup tab 3. Enter "codethink.co.uk" in the space for Network address. 4. In the information type dropdown menu select "Any / All Information" 5. Click the "Lookup" button. Note: Other options in the "information type dropdown menu" works without any error. The issue is seen only with "Any / All Information". -- Regards Sudip
Bug#1060274: RFS: python-acora/2.4-1.1 [NMU] [RC] -- fast multi-keyword text search engine (Python 2)
Hi, On Tue, Jan 9, 2024 at 5:15 AM Bastian Germann wrote: > > Control: tags -1 moreinfo > > On Mon, 8 Jan 2024 23:13:52 +0800 Bo YU wrote: > > python-acora (2.4-1.1) unstable; urgency=medium > > . > >* Non-maintainer upload. > >* New upstream version 2.4. (Closes: #1056849, #1055707). > >* Remove python2 on B-D and pybuild. > >* Add extend-diff-ignore to fix dpkg-source -b check issue. > > Please check the archive before posting NMUs based on old versions. I guess the problem was raised by not pushing the update to the slasa repo with before several times NMUs. I just the do NMUs based on salsa repo. > Also, a new upstream version needs the NMU revision -0.1, not -1.1. Okak, thanks for reminding me. BR, bo >
Bug#1060292: Flash-kernel add Sipeed Lichee Pi 4A
Package: flash-kernel Version: 3.107 Severity: wishlist Please, add the Sipeed Lichee Pi 4A to the database: Machine: Sipeed Lichee Pi 4A Kernel-Flavors: any Boot-Script-Path: /boot/boot.scr DTB-Id: thead/th1520-lichee-pi-4a.dtb Boot-Script-Path: /boot/boot.scr U-Boot-Script-Name: bootscr.uboot-generic Required-Packages: u-boot-tools Best regards Heinrich
Bug#1060233: libc6: Missing libdl.so
Dear Aurelien, Thanks for the help. Please close this bug report. Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
Bug#1055955: transition: perl 5.38
Control: tags -1 confirmed On 2024-01-09 00:08:09 +0200, Niko Tyni wrote: > On Sat, Dec 09, 2023 at 01:15:26PM +0200, Niko Tyni wrote: > > On Tue, Nov 14, 2023 at 08:28:01PM +0200, Niko Tyni wrote: > > > > > this has taken me much longer than necessary for various reasons, but I > > > think we're almost ready to push Perl 5.38 to sid now. > > > > > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.38-transition;users=debian-p...@lists.debian.org > > > I think we're as ready as can reasonably be, assuming you're OK with the > > above testing removals. Please let me know when a suitable transition > > slot becomes available. > > Hi, gentle ping on this? Please go ahead. Cheers -- Sebastian Ramacher
Bug#1060291: ITP: python-nh3 -- Python bindings to the ammonia HTML sanitization library.
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-nh3 Version : 0.2.15 Upstream Contact: * URL : https://github.com/messense/nh3 * License : MIT Programming Lang: Pytthon Description : Python bindings to the ammonia HTML sanitization library. NH3 is an HTML sanitizing library that escapes or strips markup and attributes based on a white list. NH3 can also linkify text safely, applying filters that Django's urlize filter cannot, and optionally setting rel attributes, even on links already in the text. . NH3 is intended for sanitizing text from untrusted sources. If you find yourself jumping through hoops to allow your site administrators to do lots of things, you're probably outside the use cases. Either trust those users, or don't. Bleach is deprecated, NH3 is seen a valid successor. NH3 is neead to package the latest version of 'python-readme-renderer' https://github.com/mozilla/bleach/issues/698 https://daniel.feldroy.com/posts/2023-06-converting-from-bleach-to-nh3
Bug#1059891: linux-image-6.1.0-17-amd64: netfilter (nftables) breaks since bookworm
Hi, thank you for your answer. On 1/5/24 20:18, Salvatore Bonaccorso wrote: Control: tags -1 + moreinfo On Wed, Jan 03, 2024 at 07:35:23AM +0100, Daniel Haryo Sugondo wrote: Package: src:linux Version: 6.1.69-1 Severity: normal Dear Maintainer, since Debian 12 (Bookworm) the nft with named set ends with kernel trace and the nft stalled (D) # ps aux root 82373 0.0 0.0 0 0 ?DJan02 0:00 [nft] The message looks like: [ 3566.525419] [ cut here ] [ 3566.525424] kernel BUG at mm/slub.c:419! [ 3566.529834] invalid opcode: [#1] PREEMPT SMP PTI [ 3566.535474] CPU: 19 PID: 8146 Comm: kworker/19:0 Not tainted 6.1.0-17-amd64 #1 Debian 6.1.69-1 [ 3566.545182] Hardware name: /0X3D66, BIOS 2.2.2 01/16/2014 [ 3566.551304] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [ 3566.558609] RIP: 0010:__slab_free+0x118/0x2d0 [ 3566.563474] Code: 74 35 49 8b 06 48 89 4c 24 20 48 c1 e8 36 4c 8b a4 c3 d8 00 00 00 4c 89 e7 e8 74 6a 71 00 48 8b 4c 24 20 48 89 44 24 18 eb 8f <0f> 0b f7 43 08 00 0d 21 00 75 cd eb c6 80 4c 24 53 80 e9 75 ff ff [ 3566.584431] RSP: 0018:a76066effdb0 EFLAGS: 00010246 [ 3566.590262] RAX: 95430ba21930 RBX: 952b80043300 RCX: 802a001a [ 3566.598223] RDX: a76066effdd8 RSI: eed9a22e8840 RDI: a76066effe18 [ 3566.606189] RBP: 95430ba21900 R08: 0001 R09: c0d89ecc [ 3566.614152] R10: 0013 R11: 0001 R12: a76066effe50 [ 3566.622114] R13: 95430ba21900 R14: eed9a22e8840 R15: 95430ba21900 [ 3566.630079] FS: () GS:955a9fa4() knlGS: [ 3566.639107] CS: 0010 DS: ES: CR0: 80050033 [ 3566.645518] CR2: 7f255e9eb3d8 CR3: 002a6d410006 CR4: 001706e0 [ 3566.653479] Call Trace: [ 3566.656210] [ 3566.658552] ? __die_body.cold+0x1a/0x1f [ 3566.662928] ? die+0x2a/0x50 [ 3566.666144] ? do_trap+0xc5/0x110 [ 3566.669848] ? __slab_free+0x118/0x2d0 [ 3566.674029] ? do_error_trap+0x6a/0x90 [ 3566.678211] ? __slab_free+0x118/0x2d0 [ 3566.682393] ? exc_invalid_op+0x4c/0x60 [ 3566.686676] ? __slab_free+0x118/0x2d0 [ 3566.690857] ? asm_exc_invalid_op+0x16/0x20 [ 3566.695529] ? nf_tables_trans_destroy_work+0x1cc/0x250 [nf_tables] [ 3566.702532] ? __slab_free+0x118/0x2d0 [ 3566.706714] ? obj_cgroup_uncharge_pages+0xd0/0xd0 [ 3566.712066] nf_tables_trans_destroy_work+0x1cc/0x250 [nf_tables] [ 3566.718874] process_one_work+0x1c7/0x380 [ 3566.723351] worker_thread+0x4d/0x380 [ 3566.727436] ? rescuer_thread+0x3a0/0x3a0 [ 3566.731908] kthread+0xda/0x100 [ 3566.735417] ? kthread_complete_and_exit+0x20/0x20 [ 3566.740763] ret_from_fork+0x22/0x30 [ 3566.744759] [ 3566.747195] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter bridge 8021q garp stp mrp llc overlay bonding tls nft_nat nft_chain_nat nf_nat nft_log qrtr nft_limit nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink_log nfnetlink binfmt_misc intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp nls_ascii nls_cp437 coretemp kvm_intel vfat fat kvm ipmi_ssif irqbypass ghash_clmulni_intel sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel crypto_simd cryptd ipmi_si iTCO_wdt rapl intel_pmc_bxt ipmi_devintf joydev intel_cstate iTCO_vendor_support ipmi_msghandler sg acpi_power_meter watchdog intel_uncore mei_me mei pcspkr evdev parport_pc ppdev lp parport efi_pstore dm_mod fuse loop configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic hid_generic usbhid hid sr_mod cdrom sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif [ 3566.747268] crct10dif_generic mgag200 i2c_algo_bit drm_shmem_helper ahci drm_kms_helper libahci ehci_pci ehci_hcd libata crct10dif_pclmul megaraid_sas drm crct10dif_common crc32_pclmul crc32c_intel usbcore tg3 scsi_mod lpc_ich libphy usb_common scsi_common wmi button [ 3566.870202] ---[ end trace ]--- [ 3566.878075] RIP: 0010:__slab_free+0x118/0x2d0 [ 3566.882954] Code: 74 35 49 8b 06 48 89 4c 24 20 48 c1 e8 36 4c 8b a4 c3 d8 00 00 00 4c 89 e7 e8 74 6a 71 00 48 8b 4c 24 20 48 89 44 24 18 eb 8f <0f> 0b f7 43 08 00 0d 21 00 75 cd eb c6 80 4c 24 53 80 e9 75 ff ff [ 3566.903925] RSP: 0018:a76066effdb0 EFLAGS: 00010246 [ 3566.909772] RAX: 95430ba21930 RBX: 952b80043300 RCX: 802a001a [ 3566.917752] RDX: a76066effdd8 RSI: eed9a22e8840 RDI: a76066effe18 [ 3566.925747] RBP: 95430ba21900 R08: 0001 R09: c0d89ecc [ 3566.933714] R10: 0013 R11: 0001 R12: a76066effe50 [ 3566.941694] R13: 95430ba21900 R14: eed9a22e8840 R15: 95430ba21900 [ 3566.949670] FS: () GS:955a9fa4() knlGS: [ 3566.958717] CS: 0010 DS: ES: CR0: 80050033 [ 3566.965144] CR2:
Bug#1060290: bullseye-pu: package django-mailman3/1.3.5-2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Hello,
Some users brought to my attention that in bullseye, django-mailman3
doesn't scrub messages properly before passing them to any archiver, and
therefore some messages are not archived.
This PU patches django-mailman3 so that it processes messages having a
null-byte in their body properly.
[ Reason ]
The bug probably has existed all the time before the patch made upstream
there:
https://gitlab.com/mailman/django-mailman3/-/commit/5bc1f6e8ca4d95ea4e2be861821cb17f168f8d1b?merge_request_iid=121
[ Impact ]
Messages received by mailman3 might not be archived properly archived.
[ Tests ]
Tests were designed upstream, but require binary files to be added to
the code, which can't be done through a quilt patch, so I have not
included the tests.
[ Risks ]
The patch works properly. Should a bug arise due to the new code,
archiving would be broken.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Explicit replacement of nullbyte characters by '' in a message body when
scrubbing.
dpkg-source: avertissement: extraction d'un paquet source non signé
(/home/peb/git/debian/mailman-team/django-mailman3/django-mailman3_1.3.5-2.dsc)
dpkg-source: avertissement: extraction d'un paquet source non signé
(/home/peb/git/debian/mailman-team/django-mailman3/django-mailman3_1.3.5-2+deb11u1.dsc)
diff -Nru django-mailman3-1.3.5/debian/changelog
django-mailman3-1.3.5/debian/changelog
--- django-mailman3-1.3.5/debian/changelog 2021-03-04 00:23:46.0
+0100
+++ django-mailman3-1.3.5/debian/changelog 2024-01-08 22:32:29.0
+0100
@@ -1,3 +1,10 @@
+django-mailman3 (1.3.5-2+deb11u1) bullseye; urgency=medium
+
+ * d/p/0001: Fix archiving issues due to nullbytes in message body
+(Closes: #1033256)
+
+ -- Pierre-Elliott Bécue Mon, 08 Jan 2024 22:32:29 +0100
+
django-mailman3 (1.3.5-2) unstable; urgency=medium
* Compile django LC messages at build time
diff -Nru
django-mailman3-1.3.5/debian/patches/0001-Scrubber-now-removes-null-bytes-from-the-scrubbed-me.patch
django-mailman3-1.3.5/debian/patches/0001-Scrubber-now-removes-null-bytes-from-the-scrubbed-me.patch
---
django-mailman3-1.3.5/debian/patches/0001-Scrubber-now-removes-null-bytes-from-the-scrubbed-me.patch
1970-01-01 01:00:00.0 +0100
+++
django-mailman3-1.3.5/debian/patches/0001-Scrubber-now-removes-null-bytes-from-the-scrubbed-me.patch
2024-01-08 22:32:29.0 +0100
@@ -0,0 +1,43 @@
+From: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?=
+Date: Mon, 8 Jan 2024 22:40:38 +0100
+Subject: Scrubber now removes null bytes from the scrubbed message body.
+
+---
+ README.rst | 1 +
+ django_mailman3/lib/scrub.py | 5 -
+ 3 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/README.rst b/README.rst
+index 775b158..98264be 100644
+--- a/README.rst
b/README.rst
+@@ -17,6 +17,7 @@ NEWS
+ * Add a new method get_django_user to return Django User model. (See !99)
+ * Add ``delete_archives`` field to ``mailinglist_deleted`` Signal.
+ * Replaced deprecated ``ugettexy_lazy`` with ``gettext_lazy``. (Closes #37)
++* Scrubber now removes null bytes from the scrubbed message body.
+
+
+ 1.3.4 (2020-06-05)
+diff --git a/django_mailman3/lib/scrub.py b/django_mailman3/lib/scrub.py
+index f35761b..2be66c9 100644
+--- a/django_mailman3/lib/scrub.py
b/django_mailman3/lib/scrub.py
+@@ -248,6 +248,8 @@ class Scrubber():
+ next_part_match = NEXT_PART.search(result)
+ if next_part_match:
+ result = result[0:next_part_match.start(0)]
++# MAS Remove any null butes from the result.
++result = re.sub('\x00', '', result)
+ return result
+
+ def _get_text(self):
+@@ -276,6 +278,7 @@ class Scrubber():
+ if not part_content.endswith('\n'):
+ part_content += '\n'
+ text.append(part_content)
+-return '\n'.join(text)
++# MAS remove any null bytes from the text.
++return re.sub('\x00', '', '\n'.join(text))
+ else:
+ return self._get_text_one_part(self.msg)
diff -Nru django-mailman3-1.3.5/debian/patches/series
django-mailman3-1.3.5/debian/patches/series
--- django-mailman3-1.3.5/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ django-mailman3-1.3.5/debian/patches/series 2024-01-08 22:32:29.0
+0100
@@ -0,0 +1 @@
+0001-Scrubber-now-removes-null-bytes-from-the-scrubbed-me.patch
Bug#1058106: python-ml-collections: FTBFS: ModuleNotFoundError: No module named 'imp'
Hi,
Made a patch to fix the ModuleNotFoundError with Py 3.12. Attaching the
debdiff file.
Cheers!
diff -Nru python-ml-collections-0.1.1/debian/changelog
python-ml-collections-0.1.1/debian/changelog
--- python-ml-collections-0.1.1/debian/changelog2023-04-01
05:59:28.0 +
+++ python-ml-collections-0.1.1/debian/changelog2024-01-08
20:00:00.0 +
@@ -1,3 +1,13 @@
+python-ml-collections (0.1.1-3) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Included a patch for ml_collections/config_flags/config_flags.py
+to replace deprecated imp with importlib to fix ModuleNotFoundError
+in Python 3.12. (Closes: #1058106)
+ * Added python3-absl, python3-contextlib2, python3-yaml to test-deps.
+
+ -- Yogeswaran Umasankar Mon, 08 Jan 2024 20:00:00 +
+
python-ml-collections (0.1.1-2) unstable; urgency=medium
* Team Upload.
diff -Nru
python-ml-collections-0.1.1/debian/patches/002_imp-module-replacement.patch
python-ml-collections-0.1.1/debian/patches/002_imp-module-replacement.patch
--- python-ml-collections-0.1.1/debian/patches/002_imp-module-replacement.patch
1970-01-01 00:00:00.0 +
+++ python-ml-collections-0.1.1/debian/patches/002_imp-module-replacement.patch
2024-01-08 20:00:00.0 +
@@ -0,0 +1,24 @@
+Description: Implemented importlib to fix ModuleNotFoundError with Python 3.12.
+Author: Yogeswaran Umasankar
+Last-Update: 2024-01-08
+
+--- a/ml_collections/config_flags/config_flags.py
b/ml_collections/config_flags/config_flags.py
+@@ -16,7 +16,7 @@
+ """Configuration commmand line parser."""
+
+ import errno
+-import imp
++import importlib
+ import os
+ import re
+ import sys
+@@ -450,7 +450,7 @@ def _LoadConfigModule(name: str, path: s
+
+ # Works for relative paths.
+ with ignoring_errors.Attempt('Relative path', path):
+-config_module = imp.load_source(name, path)
++config_module = importlib.load_source(name, path)
+ return config_module
+
+ # Nothing worked. Log the paths that were attempted.
diff -Nru python-ml-collections-0.1.1/debian/patches/series
python-ml-collections-0.1.1/debian/patches/series
--- python-ml-collections-0.1.1/debian/patches/series 2023-04-01
05:50:43.0 +
+++ python-ml-collections-0.1.1/debian/patches/series 2024-01-08
20:00:00.0 +
@@ -1 +1,2 @@
noRequirements.patch
+002_imp-module-replacement.patch
diff -Nru python-ml-collections-0.1.1/debian/tests/control
python-ml-collections-0.1.1/debian/tests/control
--- python-ml-collections-0.1.1/debian/tests/control2023-04-01
05:56:46.0 +
+++ python-ml-collections-0.1.1/debian/tests/control2024-01-08
20:00:00.0 +
@@ -1,3 +1,3 @@
Tests: run-unit-test
-Depends: @, bazel-bootstrap, python3-mock, python-is-python3
+Depends: @, bazel-bootstrap, python3-mock, python-is-python3, python3-absl,
python3-contextlib2, python3-yaml
Restrictions: allow-stderr, skip-not-installable
signature.asc
Description: PGP signature
Bug#1057495: ca-certificates-java: FTBFS with default Java 21
Dear Maintainers, Would it be possible to consider a merge request[1] that addresses this issue? Best Regards, Vladimir. [1] https://salsa.debian.org/java-team/ca-certificates-java/-/merge_requests/11
Bug#1060289: linphone: why are there ringtones in mkv encapsulated opus and the only thing it is able to use are wav files?
Package: linphone Version: 4.2.5-3 Severity: important X-Debbugs-Cc: t...@treaki.tk Dear Maintainer, i tried to change the ringtone, because the default one was a big basic, i tried those wich are also there at /usr/share/sounds/linphone/rings but the only one tht worked was the default one i assumed that the one there would work, there where no error message but it wasnt ringing anymore eiterh. So i tryed to convert one of them using ffmpeg, to mp3 and opus (without some mkv container) but both didnt work, only thing that worked was converting it to microsoft .wav file so, strage i guess that it didnt work with anything else then the most basic audio file and the one provided with are more elaborated then anything normally there, i mean opus on its own is high but then also in an matroska container. At least i guess it should support de facto standarts like an basic mp3 files.. please fix that and if you cant, just convert those mkv files to wav thanks and keep up the good work -- System Information: Debian Release: 11.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linphone depends on: ii linphone-desktop 4.2.5-3 linphone recommends no packages. linphone suggests no packages. -- no debconf information
Bug#1060246: perl: proposed patch for perl ABI change due to 64-bit time_t
On Mon, Jan 08, 2024 at 12:35:32AM -0800, Steve Langasek wrote: > Package: perl > Version: 5.36.0-10 > Severity: normal > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu noble ubuntu-patch > > Hi Niko, Dominic, > > Please find attached a prospective patch for perl that would annotate the > perlapi provides for perl-base after a 64-bit time_t transition for 32-bit > architectures, on perl 5.36.0. I've tested that this does what's expected, > both for the Provides: of perl-base and the behavior of dh_perl. Thanks! Glad the perlabi thing is still working. It hasn't had much use. > It tries to retain compatibility with perlapi-5.36.0 on architectures where > this is appropriate (64-bit architectures + i386); it covers Debian release > architectures + riscv64, but does not attempt to be complete for all > architectures dpkg knows about. Is there a reason you're bumping the abi for all the architectures rather than just the affected ones? I'd expect this to be "opt in" so perlabi would be defined just for armhf, hppa and so forth. I'm thinking something like what we did for the s390x jmp_buf thing ifeq (s390x-linux-gnu,$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)) perlabi = 5.18.2d else perlabi = endif as per https://salsa.debian.org/perl-team/interpreter/perl/-/commit/a66f196c13108b04909f9ec0e05986983cb2ed19 > This is entirely optional anyway, as perl > 5.38 is just around the corner, at which point this patch should be dropped > completely (assuming time_t lands before perl 5.38 does). TBH I was hoping 5.38 would land first :) I'm just waiting for a transition slot. (Hm, it's been a month now, guess I should ping the bug.) OOC, have you got the perl test suite passing with time64? I just did a quick try on i386 with just DEB_BUILD_OPTIONS=abi=+time64 and I'm seeing Failed 7 tests out of 2623, 99.73% okay. ../cpan/DB_File/t/db-btree.t ../cpan/DB_File/t/db-hash.t ../cpan/DB_File/t/db-recno.t ../cpan/DB_File/t/db-threads.t ../cpan/Memoize/t/errors.t ../cpan/Memoize/t/tie.t porting/libperl.t but I guess that's because things like libdb5.3 need to be rebuilt first? -- Niko
Bug#1055955: transition: perl 5.38
On Sat, Dec 09, 2023 at 01:15:26PM +0200, Niko Tyni wrote: > On Tue, Nov 14, 2023 at 08:28:01PM +0200, Niko Tyni wrote: > > > this has taken me much longer than necessary for various reasons, but I > > think we're almost ready to push Perl 5.38 to sid now. > > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.38-transition;users=debian-p...@lists.debian.org > I think we're as ready as can reasonably be, assuming you're OK with the > above testing removals. Please let me know when a suitable transition > slot becomes available. Hi, gentle ping on this? -- Niko
Bug#977177: mm-common: reproducible builds: Generated tarball includes user, group and file mode
Control: found 977177 1.0.6-1 Hi, it seems the changes in the 1.0.5-1.1 NMU were not included in the most recent upload... would you please consider including them? live well, vagrant On 2023-12-05, Vagrant Cascadian wrote: > On 2023-11-29, Vagrant Cascadian wrote: >> On 2020-12-12, Simon McVittie wrote: >>> On Fri, 11 Dec 2020 at 20:45:09 -0800, Vagrant Cascadian wrote: >> With the patch, I managed to produce a bit-for-bit identical >> skeletonmm.tar.xz with the patch applied, both in a test environment >> where the umask was varied, and with a fairly "normal" umask which was >> bit-for-bit identical to the skeletonmm.tar.xz in the mm-common package >> in the Debian archive. So it should not cause regressions! >> >> With this patch applied, mm-common should become reproducible on >> tests.reproducible-builds.org infrastructure! >> >> Would an upload including this patch be considered soon, or would the >> maintainers be open to an NMU in the near future? > > Uploaded to DELAYED/10 using dgit, debdiff follows: > > diff -Nru mm-common-1.0.5/debian/changelog mm-common-1.0.5/debian/changelog > --- mm-common-1.0.5/debian/changelog 2022-12-15 12:25:29.0 -0800 > +++ mm-common-1.0.5/debian/changelog 2023-12-05 15:03:37.0 -0800 > @@ -1,3 +1,14 @@ > +mm-common (1.0.5-1.1) unstable; urgency=medium > + > + [ Vagrant Cascadian ] > + * Non-maintainer upload. > + > + [ Simon McVittie ] > + * util/meson_aux/skeletonmm-tarball.py: Use consistent mode on files in > +the generated tarball. (Closes: #977177) > + > + -- Vagrant Cascadian Tue, 05 Dec 2023 15:03:37 -0800 > + > mm-common (1.0.5-1) unstable; urgency=medium > >[ Jeremy Bicha ] > diff -Nru mm-common-1.0.5/debian/patches/series > mm-common-1.0.5/debian/patches/series > --- mm-common-1.0.5/debian/patches/series 2022-12-15 12:25:29.0 > -0800 > +++ mm-common-1.0.5/debian/patches/series 2023-12-05 15:03:37.0 > -0800 > @@ -0,0 +1 @@ > +utilmeson_auxskeletonmm-tarball.py-use-c.patch > diff -Nru > mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch > mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch > --- > mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch > 1969-12-31 16:00:00.0 -0800 > +++ > mm-common-1.0.5/debian/patches/utilmeson_auxskeletonmm-tarball.py-use-c.patch > 2023-12-05 15:03:37.0 -0800 > @@ -0,0 +1,34 @@ > +From: Simon McVittie > +Date: Tue, 28 Nov 2023 16:57:13 -0800 > +X-Dgit-Generated: 1.0.5-1.1 77d8a907867d87eb56f57cfd5d3226aba19355d8 > +Subject: util/meson_aux/skeletonmm-tarball.py: Use consistent mode on files > in > + > +the generated tarball. (Closes: #977177) > + > +Signed-off-by: Vagrant Cascadian > + > +--- > + > +diff --git a/util/meson_aux/skeletonmm-tarball.py > b/util/meson_aux/skeletonmm-tarball.py > +index 138184c..a87590e 100755 > +--- a/util/meson_aux/skeletonmm-tarball.py > b/util/meson_aux/skeletonmm-tarball.py > +@@ -10,6 +10,7 @@ import os > + import sys > + import shutil > + import tarfile > ++import stat > + > + if sys.argv[1] == 'check': > + # Called from run_command() during setup or configuration. > +@@ -42,6 +43,10 @@ else: > + def reset(tarinfo): > + tarinfo.uid = tarinfo.gid = 0 > + tarinfo.uname = tarinfo.gname = "root" > ++if tarinfo.isdir() or (tarinfo.mode & 0o111) != 0: > ++tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o755 > ++else: > ++tarinfo.mode = stat.S_IFMT(tarinfo.mode) | 0o644 > + return tarinfo > + > + > > > live well, > vagrant signature.asc Description: PGP signature
Bug#1050547: Info received (Similar stacktrace for this issue.)
This seems to be the same issue as this one upstream: https://gitlab.gnome.org/GNOME/mutter/-/issues/2815 The latest debian update made wayland work for me again, and I found the accessibility zoom feature was somehow active for my greeter session, some curious kids may have clicked on things. Turning it off and then disabling wayland has fixed it for me. I suspect this might be mitigated for other broken users with: mv /var/lib/gdm3/greeter-dconf-defaults /var/lib/gdm3/greeter-dconf-defaults.old On Sat, 25 Nov 2023 at 23:51, Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian GNOME Maintainers > > If you wish to submit further information on this problem, please > send it to 1050...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 1050547: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050547 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > >
Bug#1060274: RFS: python-acora/2.4-1.1 [NMU] [RC] -- fast multi-keyword text search engine (Python 2)
Control: tags -1 moreinfo On Mon, 8 Jan 2024 23:13:52 +0800 Bo YU wrote: python-acora (2.4-1.1) unstable; urgency=medium . * Non-maintainer upload. * New upstream version 2.4. (Closes: #1056849, #1055707). * Remove python2 on B-D and pybuild. * Add extend-diff-ignore to fix dpkg-source -b check issue. Please check the archive before posting NMUs based on old versions. Also, a new upstream version needs the NMU revision -0.1, not -1.1.
Bug#1060155: dbus: please usrmerge in unstable
Control: tags -1 + pending On Sat, 06 Jan 2024 at 15:47:34 +0100, Chris Hofstaedtler wrote: > I was about to send a patch for dbus to move libdbus into /usr, but > then noticed it's already done in experimental. > > Do you know about any open blockers to apply this in unstable? If > not, could I ask you to upload to unstable, please? No particular blockers, I was just letting it bake in experimental for a while, since any failure here would break end-user systems quite extensively (and I particularly didn't want to upload this while on vacation). smcv
Bug#1060288: locales: Please allow selection of C.UTF-8 when (re)configuring locales
Package: locales Version: 2.36-9+deb12u3 Severity: wishlist Tags: d-i l10n Dear Maintainer, It would be nice to have C.UTF-8 in the list which dpkg-reconfigure locales shows; When installing a desktop I usually select the C locale since the others don't really apply and I'm unable to use a different locale setting for date and lang. This however breaks gnome since it requires a utf-8 locale and I'm unable to select C.UTF-8 at installation. A workaround is to uncomment the C.UTF-8 locale in /etc/locale.gen and run dpkg-reconfigure locales after installation. Kind regards, Axel Scheepers -- 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/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 Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.82 ii libc-bin 2.36-9+deb12u3 ii libc-l10n 2.36-9+deb12u3 locales recommends no packages. locales suggests no packages. -- debconf information: * locales/locales_to_be_generated: C.UTF-8 UTF-8 * locales/default_environment_locale: C.UTF-8
Bug#1059892: qa.debian.org: uscan version too old and not using recent @ANY_VERSION@ expansion
Hi, Some more info in this IRC discussion 09:15 < adsb> without having checked the specifics, the likely answer is "get a newer devscripts into bullseye-backports", I suspect 09:46 < manphiz> adsb: I see. Would be great to upgrade the server to Bookworm to get more newer tools, but I guess that probably requires more work. 09:47 < doge-tech> manphiz: Yep, I was just taking a look at that but as a minimum it would require upgrading from postgresql 13 to 16. I may take another look when I've got a bit more time, unless lucas already has. 09:47 < doge-tech> Backporting devscripts will be easier and quicker, for sure 09:48 < adsb> well lucas also can't actually do the upgrade :) 09:49 < adsb> but yes, with the DSA hat on installing a single package backport is a thing we can easily do. upgrades are still a little less so sadly 09:49 < manphiz> ah db upgrade... 09:52 < doge-tech> Looks like there's already an updated devscripts in bullseye-backports-sloppy 09:54 < adsb> presumably from testing 09:54 < adsb> if bookworm's version is sufficient, then that could go to bullseye-backports, afair the policies 09:55 < adsb> and ullmann (udd.d.o) will already be configured to support that 09:55 < adsb> -sloppy less so 09:57 < doge-tech> bookworm has 2.23.4, which includes the "v?" check but not the "[Vv]?". Still a worthwhile improvement, IMO. 09:58 < adsb> if people care that much then maybe udd actually wants to run a local uscan copy. but I'm not a service admin, just a machine one 09:58 < adsb> (there are reasons not to do that as well of course) 10:00 < doge-tech> Not a bad idea. UDD could pull the latest uscan from the devscripts repo and use that instead. I'm not an anything admin though (just a guy who's interested), so I'm always happy to be shot down. :) 10:02 < doge-tech> There would be a risk to the stability of UDD in doing that, of course 10:06 < adsb> well, it's work for lucas, so he might not want to :) Lucas
Bug#1060222: aide-common: 31_aide_php-fpm defines PHPVERSION 2.2 instead of 8.2
Control: tag -1 confirmed Hi, On Sun, Jan 07, 2024 at 09:10:17PM +0100, Frederik Himpe wrote: > The config file 31_aide_php-fpm defines PHPVERSION as 2.2 instead of 8.2. thanks for spotting this. Pardon the stupid question, all PHP packages in a Debian version us the same PHP version, right? Maybe it would be a good idea to deliver PHPVERSION it its own config snippet just in case that multiple PHP related rules have to refer to the versioN? 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#1058083: yapsy: FTBFS: ModuleNotFoundError: No module named 'imp'
Control: tags -1 upstream Control: forwarded -1 https://github.com/tibonihoo/yapsy/issues/18 -- http://fam-tille.de
Bug#1060275: asterisk: Codec translation notice
Quoting List Support via Pkg-voip-maintainers (2024-01-08 19:35:12) > Le 08/01/2024 à 19:26, Jonas Smedegaard a écrit : > > If it is possible for you to try test your setup with > > upstream-distributed Asterisk, then it would help ensure that truly what > > you experience is a bug introduced by a Debian patch. > Yes, I have a test asterisk running Debian12+asterisk 20.5.2 compiled > from source, I could install a debian upstream Asterisk on it Sorry, I don't follow. Are you saying that when you build Debian-distributed Asterisk 20.5.2 the same way as Debian builds it, then this reported problem disappears? Or are you saying that when you build Debian-distributed Asterisk 20.5.2 somehow omitting to apply any of the Debian patches, then this reported problem disappears? Or some other scenario? Kind regards, and thanks for your help here, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1060287: awscli: new upstream (2.15.1) available
Package: awscli Version: 2.15.8-1 Severity: important Tags: newcomer I would have this as wishlist, but the current version in unstable (2.14) fails to install because of a versioned dependency on python- cryptography, is therefore unusable. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.9-amd64 (SMP w/8 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 awscli depends on: ii groff-base1.23.0-3 ii python3 3.11.6-1 ii python3-awscrt0.19.19+dfsg-1 ii python3-colorama 0.4.6-4 ii python3-cryptography 41.0.7-1 ii python3-dateutil 2.8.2-3 ii python3-distro1.9.0-1 ii python3-docutils 0.20.1+dfsg-3 ii python3-jmespath 1.0.1-1 ii python3-prompt-toolkit3.0.43-1 ii python3-pyasn10.4.8-4 ii python3-ruamel.yaml 0.17.21-1 ii python3-ruamel.yaml.clib 0.2.8-1 ii python3-urllib3 1.26.18-1 awscli recommends no packages. awscli suggests no packages. -- no debconf information
Bug#1053128: This is Bug 15170 on bugzilla.samba.org
Control: found -1 2:4.19.4+dfsg-2 Control: tag -1 + confirmed upstream On Thu, 5 Oct 2023 20:46:25 +0400 Dmitry Telegin wrote: I found this bug in samba: Bug 15170 - smbtree seg fault if using -N option. https://bugzilla.samba.org/show_bug.cgi?id=15170 I checked this error in CentOS Stream 9 (samba 4.18.6-100.el9) - successfully reproduced. This is still happening with 4.19.4, fwiw. /mjt
Bug#1060202: glibc - autopkgtest flacky on arm64
Hi, On 08-01-2024 01:45, Aurelien Jarno wrote: I am still not sure why it got killed on arm64 and not on other debci workers, there as still swap available. Actually looking at the munin plot, it seems that the arm64 debci workers stopped using swap around September 2023 contrary to the other architectures. This does seem to align with us upgrading from the bookworm kernel to the backports kernel because of bug 1050256. That still doesn't explain while the problem with glibc seems to have started one week ago. Indeed, but 4 GB of swap looks like it would help. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058924: gnome-software: does not list or find any apt package
On Mon, Jan 8, 2024 at 3:27 PM Patrice Duroux wrote: > Nop. Same after a reboot, here are the journalctl messages if it may help: Could you create a new bug? The original bug is fixed for me on both Ubuntu 24.04 and Debian Testing (after I installed gnome-software 45.3-2). Thank you, Jeremy Bícha
Bug#1060286: nextcloud-spreed-signaling: Not able to connect to MCU (payload does not contain a valid sdp)
Package: nextcloud-spreed-signaling
Version: 1.2.2-1~bpo12+1
Severity: normal
Dear Maintainer,
The backports version of nextcloud-spreed-signaling seems not to be able
to connect to janus-gateway, while the self-built signaling server from
the same version (1.2.2) works fine.
* What exactly did you do (or not do) that was effective (or ineffective)?
Installation of package (bookworm-backports) and testing the signaling
server with janus and nats-server, configured as described in the readme.
* What was the outcome of this action?
The nextcloud-spreed-signaling server as packed in the Debian package
cannot establish connection to MCU.
* What outcome did you expect instead?
Signaling server connecting to janus as MCU.
I tried to set up nextcloud-spreed-signaling server in conjunction with
janus (1.1.2-1) and nats-server (2.9.10-1).
The configs are as follows:
/etc/janus/janus.transport.websockets.jcfg contains:
general: {
json = "indented"
ws = true
ws_port = 8188
ws_interface = "lo"
wss = false
}
and the signaling configuration in
/etc/nextcloud-spreed-signaling/server.conf
[mcu]
type = janus
url = ws://127.0.0.1:8188
(Same with localhost:8188 as ws url) Janus seems to work as intended. I
have build nextcloud-spreed-signaling from source of the latest release
(1.2.2) which is the same version as the packed version. When running
the self-built signaling server with the same config files the signaling
server works fine.
When using the signaling server from the Debian (bookworm-backports)
package and attempting to connect, janus seems to work, reading from the
logs (when debug logging is turned on):
mcu_janus.go:292: Connected to Janus WebRTC Server 1.1.2 by Meetecho s.r.l.
mcu_janus.go:298: Found JANUS VideoRoom plugin 0.0.9 by Meetecho s.r.l.
mcu_janus.go:303: Data channels are supported mcu_janus.go:307:
Full-Trickle is enabled
mcu_janus.go:309: Maximum bandwidth 1048576 bits/sec per publishing stream
mcu_janus.go:310: Maximum bandwidth 2097152 bits/sec per screensharing
stream
mcu_janus.go:316: Created Janus session 6409739776862493
mcu_janus.go:323: Created Janus handle 2619322330759171
main.go:263: Using janus MCU
hub.go:387: Using a timeout of 10s for MCU requests
backend_server.go:98: Using configured TURN API key
backend_server.go:99: Using configured shared TURN secret
...
However, the nextcloud-spreed-signaling server shows not to be able to
connect:
clientsession.go:281: Permissions of session XY changed: [publish-audio
publish-video publish-screen control]
hub.go:2161: Session XY sent unsupported offer video, ignoring (payload
does not contain a valid sdp)
room.go:665: Session joined call XX
hub.go:2193: No MCU publisher found for session XY to send ...
As the self-built signaling server from the same version works fine, I
suspect there might be an error in the Debian package of the
nextcloud-spreed-signaling.
Best regards,
Gerald
-- 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/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)
LSM: AppArmor: enabled
Versions of packages nextcloud-spreed-signaling depends on:
ii adduser 3.134
ii libc6 2.36-9+deb12u3
Versions of packages nextcloud-spreed-signaling recommends:
ii janus 1.1.2-1
ii nats-server 2.9.10-1+b3
nextcloud-spreed-signaling suggests no packages.
-- Configuration Files:
/etc/nextcloud-spreed-signaling/server.conf changed [not included]
-- no debconf information
Bug#1058924: gnome-software: does not list or find any apt package
Nop. Same after a reboot, here are the journalctl messages if it may help: $ journalctl -xe | grep gnome-software janv. 08 21:19:01 kos-moceratops dbus-daemon[2728]: [session uid=1001 pid=2728] Activating via systemd: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.61' (uid=1001 pid=3467 comm="/usr/bin/gnome-software --gapplication-service") janv. 08 21:19:03 kos-moceratops dbus-daemon[889]: [system] Activating via systemd: service name='org.freedesktop.fwupd' unit='fwupd.service' requested by ':1.109' (uid=1001 pid=3467 comm="/usr/bin/gnome-software --gapplication-service") janv. 08 21:19:09 kos-moceratops gnome-software[3467]: Only 0 apps for recent list, hiding janv. 08 21:19:09 kos-moceratops gnome-software[3467]: failed to get featured apps: no apps to show janv. 08 21:19:09 kos-moceratops gnome-software[3467]: Only 0 apps for curated list, hiding janv. 08 21:20:01 kos-moceratops gnome-software[3467]: GtkLabel 0x556a105c2490 (label) reported min width 15 and natural width 14 in measure() with for_size=57; natural size must be >= min size janv. 08 21:20:01 kos-moceratops gnome-software[3467]: GtkLabel 0x556a1051f6a0 (label) reported min width 15 and natural width 14 in measure() with for_size=57; natural size must be >= min size Le lun. 8 janv. 2024 à 21:06, Jeremy Bícha a écrit : > > On Mon, Jan 8, 2024 at 2:57 PM Patrice Duroux > wrote: > > I do not see any change after the last update on my Sid system. > > Please try logging out and logging back in. > > Or you could run pkill gnome-software and then start the Software app > again. > > Thank you, > Jeremy Bícha
Bug#1060233: libc6: Missing libdl.so
On 2024-01-08 12:24, Paul Szabo wrote: > Dear Aurelien, > > > Starting with glibc 2.34, libdl is an empty library. Therefore only a > > libdl.a is provided to support linking with -ldl. > > At bullseye, I explicitly needed to use libdl e.g. with constructs like > > export LD_LIBRARY_PATH=/somewhere > export LD_PRELOAD='libdl.so gconf_client_get_string.so' > > with code using dlopen() to then replace (modify?) library calls. > You suggest that there is no longer a need to explicitly preload libdl: > great, will simplify all my instances. (Until then, the useless symlink > allows the scripts to work as before.) It's not clear to me what is this gconf_client_get_string.so and why libdl.so need to be preloaded before. It could be because gconf_client_get_string.so is not properly linked. In any case, that should not be needed anymore, and I guess a try should confirm that. > Also: why provide the "empty" libdl.so.2 object, still? It's empty in the sense it doesn't provide any function, given they have all been moved to libc.so.6. But some binaries still reference it because they haven't been rebuilt since the change, and we need to ensure they still work. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1060285: mptcpd: FTBFS with a segmentation fault in the testsuite when SCTP disabled and no /etc/protocols
Source: mptcpd
Version: 0.12-2
Severity: serious
Tags: ftbfs upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org
Dear maintainer,
On riscv64, mptcpd fails to build from source with a segmentation fault
in the test-mptcpwrap test:
| ===
|mptcpd 0.12: tests/test-suite.log
| ===
|
| # TOTAL: 19
| # PASS: 17
| # SKIP: 1
| # XFAIL: 0
| # FAIL: 1
| # XPASS: 0
| # ERROR: 0
|
| .. contents:: :depth: 2
|
| SKIP: test-start-stop
| =
|
| Running non-interactive sudo check...
| sudo: a password is required
| fail, skipping the test
| SKIP test-start-stop (exit status: 77)
|
| FAIL: test-mptcpwrap
|
|
| Test case 0: PASS
| Test case 1: Segmentation fault
| FAIL test-mptcpwrap (exit status: 139)
A full build log is available here:
https://buildd.debian.org/status/fetch.php?pkg=mptcpd=riscv64=0.12-2%2Bb1=1704714971=0
Investigation shows that 3 conditions are needed to trigger this issue:
- A recent kernel that supports mptcp, to be checked with
/proc/sys/net/mptcp/enabled
- Something that prevents SCTP to be used, for instance on the build
daemons /proc/sys/kernel/modules_disabled is set to 1, preventing the
sctp.ko module to be loaded
- A system without /etc/protocols, for instance without the netbase
package installed.
With this three conditions, this triggers the following code path from
the mptcpwrap-tester.c file:
| static void test_socket_data(struct socket_data const *data)
| {
| int const fd = socket(data->domain, data->type, data->protocol);
|
| if (fd == -1) {
| if (errno == EPROTONOSUPPORT) {
| struct protoent const *const p =
| getprotobynumber(data->protocol);
|
| fprintf(stderr,
| "WARNING: Ignoring unsupported "
| "protocol: %d - %s\n",
| data->protocol,
| p->p_name);
|
| return;
| }
The output of getprotobynumber() is used directly, without checking for
a NULL pointer in case of error, for instance because /etc/protocols
does not exist. This causes a segmentation fault when trying to
dereference it. A workaround is to build-depends on netbase, and a
proper fix to test for this error.
In the latest rebuild of mptpcd, the conditions where met only on the
riscv64 buildd, and riscv64 is not a release architecture. That said a
few mips64el buildds also met the 3 conditions and it will be the case
of more and more buildds once they are upgraded to bookworm. I am
therefore filling this issue as severity serious.
Regards
Aurelien
Bug#744843: john: amd64 fallback binaries
Package: john
Version: 1.9.0-2
Followup-For: Bug #744843
Tags: patch
Dear maintainer!
I've developed a patch that allows the package to generate fallback
binaries during the building process. Could you kindly review and
incorporate this update?
diff --git a/debian/rules b/debian/rules
index 455a0b9..acfb6ab 100755
--- a/debian/rules
+++ b/debian/rules
@@ -42,6 +42,8 @@ else ifeq ($(CPU),i386)
CFLAGS += -DCPU_FALLBACK
else ifeq ($(CPU),amd64)
TARGET := $(OS)-x86-64
+ # enabling amd64 fallbacks
+ CFLAGS += -DCPU_FALLBACK
else ifeq ($(CPU),powerpc)
TARGET := linux-ppc32
else ifeq ($(CPU),ppc64)
@@ -74,17 +76,13 @@ else
CFLAGS += -DCFG_FULL_NAME=\\\"/etc/john/john.conf\\\"
endif
-# testing i386 for mmx instructions and sse2 extensions
ifeq ($(CPU),i386)
ifneq ($(OS),hurd)
- MMX := $(shell grep -c '^flags.* mmx' /proc/cpuinfo)
- ifneq ($(MMX),0)
- HAVEMMX := 1
- endif
- SSE := $(shell grep -c '^flags.* sse2' /proc/cpuinfo)
- ifneq ($(SSE),0)
- HAVESSE := 1
- endif
+ I386_FALLBACK := 1
+ endif
+else ifeq ($(CPU),amd64)
+ ifneq ($(OS),hurd)
+ X86_64_FALLBACK := 1
endif
endif
@@ -94,17 +92,20 @@ endif
override_dh_auto_build:
# building the selected target
dh_auto_build -- clean $(TARGET)
-ifeq ($(HAVEMMX),1)
- # renaming the non-mmx binary
+ifeq ($(I386_FALLBACK),1)
mv run/john run/john-non-mmx
- # building i386-mmx optimized binary
dh_auto_build -- clean $(OS)-x86-mmx
-endif
-ifeq ($(HAVESSE),1)
- # renaming the non-sse2 binary
mv run/john run/john-non-sse
- # building i386-sse2 optimized binary
dh_auto_build -- clean $(OS)-x86-sse2
+else ifeq ($(X86_64_FALLBACK),1)
+ mv run/john run/john-non-avx
+ dh_auto_build -- clean $(OS)-x86-64-avx
+ mv run/john run/john-non-xop
+ dh_auto_build -- clean $(OS)-x86-64-xop
+ mv run/john run/john-non-avx2
+ dh_auto_build -- clean $(OS)-x86-64-avx2
+ mv run/john run/john-non-avx512
+ dh_auto_build -- clean $(OS)-x86-64-avx512
endif
override_dh_auto_install:
@@ -115,11 +116,14 @@ override_dh_auto_install:
mv -f '{}'.utf8 '{}' \;
# install fallbacks as needed
-ifeq ($(HAVEMMX),1)
+ifeq ($(I386_FALLBACK),1)
dh_install run/john-non-mmx /usr/lib/john
-endif
-ifeq ($(HAVESSE),1)
dh_install run/john-non-sse /usr/lib/john
+else ifeq ($(X86_64_FALLBACK),1)
+ dh_install run/john-non-avx /usr/lib/john
+ dh_install run/john-non-xop /usr/lib/john
+ dh_install run/john-non-avx2 /usr/lib/john
+ dh_install run/john-non-avx512 /usr/lib/john
endif
override_dh_auto_clean:
Bug#1060202: glibc - autopkgtest flacky on arm64
On 2024-01-08 19:50, Paul Gevers wrote: > Hi, > > On 08-01-2024 01:45, Aurelien Jarno wrote: > > I am still not sure why it got killed on arm64 and not on other debci > > workers, there as still swap available. Actually looking at the munin > > plot, it seems that the arm64 debci workers stopped using swap around > > September 2023 contrary to the other architectures. > > Can you tell me how you saw that? I neither spotted that, nor is not having > swap a conscious act, so rather a mistake. From the log you send, I was surprised that OOM happened while none of the swap has been used at all. So I looked at the munin link you gave me by IRC and realized that the Swap in/out plot is stuck as 0.00 for min/avg/max values since September 2023. This is not the case of the workers of the other architectures which use a bit of swap from time to time, and this have a maximum different of 0.00. That still doesn't explain while the problem with glibc seems to have started one week ago. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1056380: AW: Bug#1056380: AW: Bug#1056380: Same issue under Ubuntu 22.04, reprepro hangs on Ubuntu package, unzstd process waiting
Yes, of course. The following modification should be enough to solve the
hanging issue:
--- uncompression.c.orig2024-01-08 21:07:23.0 +0100
+++ uncompression.c 2024-01-08 21:07:52.0 +0100
@@ -1430,7 +1430,7 @@
0
};
unsigned char buffer[4096] = {};
- while ((e = poll(, 1, 0)) > 0) {
+ while ((e = poll(, 1, -1)) > 0) {
e = read(file->fd, buffer, 4096);
if (e <= 0)
break;
Regards,
Christoph
>-Ursprüngliche Nachricht-
>Von: Bastian Germann
>Gesendet: Montag, 8. Januar 2024 19:49
>An: Fiehe, Christoph ; 1056...@bugs.debian.org
>Betreff: Re: Bug#1056380: AW: Bug#1056380: Same issue under Ubuntu 22.04,
>reprepro hangs
>on Ubuntu package, unzstd process waiting
>
>Hi Christoph,
>
>Would you please post your change proposals as patches or Merge Requests?
>That makes it much more easy to review.
>
>Thanks,
>Bastian
Bug#1060284: ITP: laniakea -- Repository management suite for Debian-based OSes
Package: wnpp Owner: Matthias Klumpp Severity: wishlist Package name: laniakea Version : 0.1 Upstream Contact: Matthias Klumpp URL : https://github.com/lkhq/laniakea License : LGPL-3.0 Programming Lang: Python Description : Repository management suite for Debian-based OSes Laniakea is a software suite to manage Debian derivatives. It provides tooling to maintain an APT archive (and multiple individual package repositories), perform QA on it, autobuild packages, and provides various tools for better insight into the archive, such as web applications to view archive details, a Matrix bot and a ZeroMQ-based message bus to plug in custom tooling. In order to make this useful as a Debian package, quite a bit of preparation still has to be done upstream, especially some crucial parts need better documentation, so the project can be used by people outside its two original Debian derivatives, Tanglu and PureOS. Having a package for it will make the project a lot more accessible though. I expect packaging this to take a while, some dependencies like Mautrix are not yet in Debian, and JavaScript components are always a pain (fortunately, Laniakea only has few of those). Packaging will be maintained at https://salsa.debian.org/laniakea-team/laniakea Cheers, Matthias
Bug#1034891: closed by Timo Aaltonen (Re: [Pkg-freeipa-devel] Bug#1034891: 389-ds-base: CVE-2023-1055)
Hi, On Mon, Jan 08, 2024 at 07:06:10PM +0100, Salvatore Bonaccorso wrote: > Hi, > > On Mon, Jan 08, 2024 at 06:56:40PM +0100, Salvatore Bonaccorso wrote: > > > Source: 389-ds-base > > > Version: 2.3.4+dfsg1-1 > > > > > > Moritz Mühlenhoff kirjoitti 26.4.2023 klo 20.43: > > > > Source: 389-ds-base > > > > X-Debbugs-CC: t...@security.debian.org > > > > Severity: important > > > > Tags: security > > > > > > > > Hi, > > > > > > > > The following vulnerability was published for 389-ds-base. > > > > > > > > CVE-2023-1055[0]: > > > > | A flaw was found in RHDS 11 and RHDS 12. While browsing entries LDAP > > > > | tries to decode the userPassword attribute instead of the > > > > | userCertificate attribute which could lead into sensitive information > > > > | leaked. An attacker with a local account where the cockpit-389-ds is > > > > | running can list the processes and display the hashed passwords. The > > > > | highest threat from this vulnerability is to data confidentiality. > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2173517 > > > > > > > > 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-1055 > > > > https://www.cve.org/CVERecord?id=CVE-2023-1055 > > > > > > > > Please adjust the affected versions in the BTS as needed. > > > > > > this was fixed upstream in 2.3.2 > > > > Do you have a reference to an upstream issue and/or upstream changes > > in 2.3.2 which fixes the issue? > > Or is it actually more related to > https://github.com/389ds/389-ds-base/issues/5687 which then would be > in 2.3.5 instead? (and inline with fedora importing 2.3.5 and > addressing the CVE?) Looks it is https://github.com/389ds/389-ds-base/commit/8483d60de374be78ce3dd423ac7ad7a3cdc5eaca#diff-2cf572ab2e20b5e58a2f66fc7b07b00cd2781cd376aaf52e6d82bb351ed0d0e9L364-L371 in 2.3.3, and first included in 2.3.4+dfsg1-1. Regards, Salvatore
Bug#1058083: yapsy: ModuleNotFoundError: No module named 'imp'
Hi Thibauld,
Debian has packaged yapsy. We try to migrate to Python3.12. When testing yapsy
with Python3.12 in our CI[1] it fails with:
testActivationAndDeactivation
(test.test_SimplePlugin.SimpleTestCase.testActivationAndDeactivation)
Test if the activation procedure works. ... Unable to import plugin:
/builds/python-team/packages/yapsy/debian/output/source_dir/test/plugins/SimplePlugin
Traceback (most recent call last):
File
"/builds/python-team/packages/yapsy/debian/output/source_dir/yapsy/PluginManager.py",
line 518, in loadPlugins
candidate_module = PluginManager._importModule(plugin_module_name,
candidate_filepath)
^^^
File
"/builds/python-team/packages/yapsy/debian/output/source_dir/yapsy/PluginManager.py",
line 584, in _importModule
candidate_module =
imp.load_module(plugin_module_name,plugin_file,candidate_filepath+".py",("py","r",imp.PY_SOURCE))
^
AttributeError: type object 'Loader' has no attribute 'PY_SOURCE'
FAIL
...
You can find the full log in our CI[1].
It would be great if you could port yapsy to Python3.12.
Kind regards
Andreas.
[1] https://salsa.debian.org/python-team/packages/yapsy/-/jobs/5132141#L1187
--
http://fam-tille.de
Bug#1058924: gnome-software: does not list or find any apt package
On Mon, Jan 8, 2024 at 2:57 PM Patrice Duroux wrote: > I do not see any change after the last update on my Sid system. Please try logging out and logging back in. Or you could run pkill gnome-software and then start the Software app again. Thank you, Jeremy Bícha
Bug#1060283: node-babel7: missing dependency node module '@nicolo-ribaudo/eslint-scope-5-internals'
Package: node-babel7 Version: 7.20.15+ds1+~cs214.269.168-6 Severity: normal Dear Maintainer, Using eslint and specifying "@babel/eslint-parser" as parser in the configuration, eslint crashes with the following exception : Error: Failed to load parser '@babel/eslint-parser' declared in '../../../.eslintrc': Cannot find module '@nicolo-ribaudo/eslint-scope-5-internals' Require stack: - /usr/share/nodejs/@babel/eslint-parser/lib/analyze-scope.cjs - /usr/share/nodejs/@babel/eslint-parser/lib/index.cjs - /usr/share/nodejs/eslint/lib/cli-engine/config-array-factory.js - /usr/share/nodejs/eslint/lib/cli-engine/cascading-config-array-factory.js - /usr/share/nodejs/eslint/lib/cli-engine/cli-engine.js - /usr/share/nodejs/eslint/lib/cli-engine/index.js - /usr/share/nodejs/eslint/lib/cli.js - /usr/share/nodejs/eslint/bin/eslint.js at Module._resolveFilename (node:internal/modules/cjs/loader:1134:15) at Module._load (node:internal/modules/cjs/loader:975:27) at Module.require (node:internal/modules/cjs/loader:1225:19) at require (/usr/share/nodejs/v8-compile-cache/v8-compile-cache.js:159:20) at Object. (/usr/share/nodejs/@babel/eslint-parser/lib/analyze-scope.cjs:14:5) at Module._compile (/usr/share/nodejs/v8-compile-cache/v8-compile-cache.js:192:30) at Module._extensions..js (node:internal/modules/cjs/loader:1414:10) at Module.load (node:internal/modules/cjs/loader:1197:32) at Module._load (node:internal/modules/cjs/loader:1013:12) at Module.require (node:internal/modules/cjs/loader:1225:19) This, of course, prevents me from usint "babel" as parser. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 node-babel7 depends on: ii node-ampproject-remapping 2.2.0+~cs5.15.37-1 ii node-babel-plugin-add-module-exports1.0.4+dfsg1~cs5.8.0-4 ii node-babel-plugin-polyfill-corejs2 0.3.3~0~20220913+ds1-1 ii node-babel-plugin-polyfill-corejs3 0.6.0~0~20220913+ds1-1 ii node-babel-plugin-polyfill-regenerator 0.4.1~0~20220913+ds1-1 ii node-babel7-runtime 7.20.15+ds1+~cs214.269.168-6 ii node-browserslist 4.22.1+~cs6.1.27-1 ii node-chalk 5.3.0-1 ii node-clone-deep 4.0.1+~cs7.0.2-1 ii node-commander 9.4.1-1 ii node-convert-source-map 1.9.0+~1.5.2-1 ii node-core-js3.33.2-1 ii node-core-js-compat 3.33.2-1 ii node-core-js-pure 3.33.2-1 ii node-debug 4.3.4+~cs4.1.7-1 ii node-esutils2.0.3+~2.0.0-1 ii node-find-cache-dir 3.3.2+~3.2.1-1 ii node-fs-readdir-recursive 1.1.0+~1.1.0-1 ii node-glob 8.0.3+~cs8.4.15-4 ii node-globals13.23.0-1 ii node-js-tokens 8.0.0-2 ii node-jsesc 3.0.2+~3.0.1-1 ii node-json5 2.2.3+dfsg-1 ii node-lodash 4.17.21+dfsg+~cs8.31.198.20210220-9 ii node-lodash-packages4.17.21+dfsg+~cs8.31.198.20210220-9 ii node-make-dir 3.1.0-3 ii node-quick-lru 6.1.1-4 ii node-regenerator-transform 0.15.2+~0.10.8-1 ii node-regexpu-core 5.2.2-3 ii node-resolve1.22.1+~cs5.31.10-1 ii node-semver 7.5.4+~7.5.0-2 ii node-slash 4.0.0-3 ii node-source-map 0.7.0++dfsg2+really.0.6.1-15 ii node-source-map-support 0.5.21+ds+~0.5.4-1 ii node-to-fast-properties 3.0.1-3 ii node-v8flags3.2.0+~3.1.1-1 ii nodejs 18.19.0+dfsg-6 node-babel7 recommends no packages. Versions of packages node-babel7 suggests: pn node-babel-plugin-polyfill-es-shims pn node-babel7-debug -- no debconf information
Bug#1058924: gnome-software: does not list or find any apt package
Package: gnome-software Version: 45.3-2 Followup-For: Bug #1058924 Dear Maintainer, I do not see any change after the last update on my Sid system. There is still this suspicious message in journalctl: janv. 08 20:35:32 kos-moceratops gnome-software[34353]: plugin 'packagekit' failed to list apps: Unsupported query Could it be related? Thanks for all! Patrice -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.9-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-software depends on: ii appstream1.0.1-3 ii apt-config-icons 1.0.1-3 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b1 ii gnome-software-common45.3-2 ii gsettings-desktop-schemas45.0-2 ii libadwaita-1-0 1.4.2-1+b1 ii libappstream51.0.1-3 ii libc62.37-13 ii libcairo21.18.0-1+b1 ii libfwupd21.9.11-1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3 ii libglib2.0-0 2.78.3-1 ii libgtk-4-1 4.12.4+ds-3 ii libgtk3-perl 0.038-3 ii libgudev-1.0-0 238-3 ii libjson-glib-1.0-0 1.8.0-2 ii libmalcontent-0-00.11.1-1+b1 ii libpackagekit-glib2-18 1.2.8-1+b1 ii libpango-1.0-0 1.51.0+ds-3 ii libpolkit-gobject-1-0123-3 ii libsoup-3.0-03.4.4-2 ii libxmlb2 0.3.14-2 ii packagekit 1.2.8-1+b1 ii software-properties-gtk 0.99.30-4 Versions of packages gnome-software recommends: ii fwupd 1.9.11-1 Versions of packages gnome-software suggests: pn apt-config-icons-hidpi pn gnome-software-plugin-flatpak pn gnome-software-plugin-snap -- no debconf information
Bug#1060251: valgrind: apt autopkgtests on armhf fail with: Access not within mapped region
I've added more context to https://bugs.debian.org/1059352#38, but just to have some info here too this is the error: 722s ==221367== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. 722s ==221367== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info 722s ==221367== Command: /usr/bin/apt-get update -o Acquire::Queue-Mode=access 722s ==221367== 722s ==221367== 722s ==221367== Process terminating with default action of signal 11 (SIGSEGV) 722s ==221367== Access not within mapped region at address 0xFE7F2A9C 722s ==221367==at 0x4938838: ReadMessages(int, std::vector, std::allocator >, std::allocator, std::allocator > > >&) (in /usr/lib/arm-linux-gnueabihf/libapt-pkg.so.6.0.0) 722s ==221367== If you believe this happened as a result of a stack 722s ==221367== overflow in your program's main thread (unlikely but 722s ==221367== possible), you can try to increase the size of the 722s ==221367== main thread stack using the --main-stacksize= flag. 722s ==221367== The main thread stack size used in this run was 8388608. 722s ==221367== 722s ==221367== HEAP SUMMARY: 722s ==221367== in use at exit: 119,915 bytes in 1,882 blocks 722s ==221367== total heap usage: 11,673 allocs, 9,791 frees, 868,849 bytes allocated 722s ==221367== 722s ==221367== LEAK SUMMARY: 722s ==221367==definitely lost: 0 bytes in 0 blocks 722s ==221367==indirectly lost: 0 bytes in 0 blocks 722s ==221367== possibly lost: 0 bytes in 0 blocks 722s ==221367==still reachable: 119,915 bytes in 1,882 blocks 722s ==221367== suppressed: 0 bytes in 0 blocks 722s ==221367== Rerun with --leak-check=full to see details of leaked memory 722s ==221367== 722s ==221367== For lists of detected and suppressed errors, rerun with: -s 722s ==221367== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 42821 from 965) 722s Segmentation fault 722s FAIL: exitcode 139
Bug#1060208: ITP: dds-ktx -- header-only library for reading KTX format textures
On further inspection, I have noticed that several commits have been made since 1.1. To maintain compatibility with Citra I will therefore be bumping the version to 1.1~git20211021.c3ca8fe.
Bug#1012752: unattended-upgrades: regularly stuck in loop, eating CPU
Package: unattended-upgrades
Version: 2.9.1+nmu3
Followup-For: Bug #1012752
X-Debbugs-Cc: tomaxu...@gmail.com
Hello, I have also stumbled upon this bug. The strace is quite the same
as the original reporter mentions. Although without debugging symbols,
I got a backtrace with GDB:
0x7feac853a096 in debVersioningSystem::CheckDep(char const*, int, char
const*) () from /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
b(gdb) bt
#0 0x7feac853a096 in debVersioningSystem::CheckDep(char const*, int,
char const*) () from /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
#1 0x7feac85510e8 in pkgDepCache::CheckDep(pkgCache::DepIterator
const&, int, pkgCache::PkgIterator&) () from
/lib/x86_64-linux-gnu/libapt-pkg.so.6.0
#2 0x7feac85517c0 in
pkgDepCache::DependencyState(pkgCache::DepIterator const&) () from
/lib/x86_64-linux-gnu/libapt-pkg.so.6.0
#3 0x7feac8551bf4 in ?? () from /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
#4 0x7feac8558a95 in pkgDepCache::Update(OpProgress*) () from
/lib/x86_64-linux-gnu/libapt-pkg.so.6.0
#5 0x7feac855907a in pkgDepCache::Init(OpProgress*) () from
/lib/x86_64-linux-gnu/libapt-pkg.so.6.0
#6 0x7feac87ace12 in ?? () from
/usr/lib/python3/dist-packages/apt_pkg.cpython-311-x86_64-linux-gnu.so
#7 0x005206c8 in ?? ()
#8 0x00536950 in PyObject_Vectorcall ()
#9 0x00528559 in _PyEval_EvalFrameDefault ()
#10 0x0057d132 in ?? ()
#11 0x0057c9c4 in ?? ()
#12 0x00563868 in PyObject_Call ()
#13 0x0052c731 in _PyEval_EvalFrameDefault ()
#14 0x006046ff in PyEval_EvalCode ()
#15 0x0061e85b in ?? ()
#16 0x0061af33 in ?? ()
#17 0x0062d666 in ?? ()
#18 0x0062d3d1 in _PyRun_SimpleFileObject ()
#19 0x0062d1e8 in _PyRun_AnyFileObject ()
#20 0x0062b6bb in Py_RunMain ()
#21 0x005f7cab in Py_BytesMain ()
#22 0x7feaca6326ca in __libc_start_call_main (main=main@entry=0x5f7c10,
argc=argc@entry=3, argv=argv@entry=0x7ffd8ec55da8) at
../sysdeps/nptl/libc_start_call_main.h:58
#23 0x7feaca632785 in __libc_start_main_impl (main=0x5f7c10, argc=3,
argv=0x7ffd8ec55da8, init=, fini=,
rtld_fini=, stack_end=0x7ffd8ec55d98)
at ../csu/libc-start.c:360
#24 0x005f7b41 in _start ()
So it seems that the problem is actually in the libapt-pkg6.0 package.
I have installed libapt-pkg6.0-dbgsym if this repeats again. The
untattended-upgrades.log contains this:
2024-01-08 09:07:18,617 INFO Starting unattended upgrades script
2024-01-08 09:07:18,624 INFO Allowed origins are:
origin=Debian,codename=trixie,label=Debian,
origin=Debian,codename=trixie,label=Debian-Security,
origin=Debian,codename=trixie-security,label=Debian-Security
2024-01-08 09:07:18,624 INFO Initial blacklist:
2024-01-08 09:07:18,624 INFO Initial whitelist (not strict):
2024-01-08 19:59:49,586 WARNING SIGTERM received, will stop
My /etc/apt/apt.conf.d/50unattended-upgrades contains this:
Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};
Unattended-Upgrade::Package-Blacklist {
};
Unattended-Upgrade::Mail "root";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
I think this is all I can provide now.
Best wishes,
TomaS
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages unattended-upgrades depends on:
ii debconf [debconf-2.0] 1.5.83
ii lsb-base 11.6
ii lsb-release12.0-2
ii python33.11.4-5+b1
ii python3-apt2.7.0+b1
ii python3-dbus 1.3.2-5+b1
ii python3-distro-info1.7
ii sysvinit-utils [lsb-base] 3.08-5
ii ucf3.0043+nmu1
ii xz-utils 5.4.5-0.3
Versions of packages unattended-upgrades recommends:
ii anacron 2.3-39
ii cron [cron-daemon] 3.0pl1-181
ii systemd-sysv255.2-2
Versions of packages unattended-upgrades suggests:
pn bsd-mailx
ii exim4-daemon-light [mail-transport-agent] 4.97-3
ii needrestart3.6-7
ii powermgmt-base 1.37
ii python3-gi 3.46.0-1+b1
--
Bug#1060202: glibc - autopkgtest flacky on arm64
Hi all, On 08-01-2024 19:50, Paul Gevers wrote: Can you tell me how you saw that? I neither spotted that, nor is not having swap a conscious act, so rather a mistake. I just checked and it seems that on ci-worker-arm64-08 was not having swap. We did have /swap created as our other workers, but apparently that was never made a swap file and mounted. After fixing, now $(cat /proc/meminfo | grep SwapTotal) says: ci-worker-arm64-02: SwapTotal: 4084220 kB ci-worker-arm64-03: SwapTotal: 4084220 kB ci-worker-arm64-04: SwapTotal: 4084220 kB ci-worker-arm64-06: SwapTotal: 4084220 kB ci-worker-arm64-05: SwapTotal: 4084220 kB ci-worker-arm64-07: SwapTotal: 4084220 kB ci-worker-arm64-11: SwapTotal: 4084220 kB ci-worker-arm64-10: SwapTotal: 4084220 kB ci-worker-arm64-08: SwapTotal: 4084220 kB ci-worker-arm64-09: SwapTotal: 4084220 kB Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060275: asterisk: Codec translation notice
FYI we are running other servers with thé samedi setup but codec configuration is !all, alaw and alaw on provider side -eg no g722 involved- and they don' t show those notices Le 8 janv. 2024 à 19:30, à 19:30, Jonas Smedegaard a écrit: >Hi Daniel, > >Quoting Daniel via Pkg-voip-maintainers (2024-01-08 16:22:19) >> after upgrading from Debian11/asterisk 18.20.2 compiled from source >to Debian12/Asterisk 20.5.2 from unstable, we receive lots of NOTICE >logs like >> >> [2024-01-08 11:35:31] NOTICE[58221][C-028a]: translate.c:603 >ast_translate: 18182 lost frame(s) 48240/30057 (alaw@8000)->(ulaw@8000) >> [2024-01-08 11:35:31] NOTICE[58710][C-0298]: translate.c:603 >ast_translate: 1253 lost frame(s) 1254/0 >(slin@16000)->(slin@8000)->(alaw@8000) >> >> doesn't matter IAX2 or PJSIP endpoints. We are surprised to see such >notice between alaw & ulaw. Codecs used for PJSIP and IAX customers EP >are >> !all,g722,ulaw,alaw and for providers !all,ulaw,alaw >> >> We checked translation and tried by adding slin,slin16 on both sides, >no changes. On 18.20.2 we didn't have this behaviour. >> >> Answer we get from asterisk community list "If you’re using the >Debian package, then that includes patches which are not present in >Asterisk mainline. >> Those log messages, and some codec translation behavior, is from one >of those patches." > >Thanks for your bugreport. > >It is true that Debian-distributed Asterisk includes patches which may >indeed affect the above. But only possibly, not certainly. > >If it is possible for you to try test your setup with >upstream-distributed Asterisk, then it would help ensure that truly >what >you experience is a bug introduced by a Debian patch. > > > - Jonas > >-- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > * Sponsorship: https://ko-fi.com/drjones > > [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#1060282: rtpengine: install files into /usr (DEP17 M2)
Source: rtpengine
Version: 11.5.1.14-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2
Your package currently hard-codes the install path for two systemd
unit symlinks. Attached is a patch to have this based on systemd.pc.
The motivation for this is the currently ongoing UsrMerge effort
[1], and I figured you likely want the same source package to work
on earlier releases.
The patch has been build-tested and checked by dumat, piuparts and
autopkgtest.
If you don't need to support earlier releases, you can just
hard-code the path in /usr/lib.
Please consider uploading this sooner than later, but in any case it
should go in for trixie.
Chris
[1] https://wiki.debian.org/UsrMerge
diff -Nru rtpengine-11.5.1.14/debian/changelog rtpengine-11.5.1.14/debian/changelog
--- rtpengine-11.5.1.14/debian/changelog 2023-11-17 13:29:29.0 +0100
+++ rtpengine-11.5.1.14/debian/changelog 2024-01-08 14:11:28.0 +0100
@@ -1,3 +1,10 @@
+rtpengine (11.5.1.14-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Honor systemdsystemunitdir from systemd.pc (DEP17 M2) (Closes: #-1)
+
+ -- Chris Hofstaedtler Mon, 08 Jan 2024 14:11:28 +0100
+
rtpengine (11.5.1.14-1) unstable; urgency=medium
* New upstream version 11.5.1.14
diff -Nru rtpengine-11.5.1.14/debian/control rtpengine-11.5.1.14/debian/control
--- rtpengine-11.5.1.14/debian/control 2023-11-17 13:29:29.0 +0100
+++ rtpengine-11.5.1.14/debian/control 2024-01-08 14:09:18.0 +0100
@@ -52,8 +52,10 @@
libxtables-dev (>= 1.4) | iptables-dev (>= 1.4),
markdown,
pandoc,
+ pkgconf,
python3,
python3-websockets,
+ systemd-dev | systemd,
zlib1g-dev,
Testsuite: autopkgtest-pkg-dkms
diff -Nru rtpengine-11.5.1.14/debian/rtpengine-daemon.links rtpengine-11.5.1.14/debian/rtpengine-daemon.links
--- rtpengine-11.5.1.14/debian/rtpengine-daemon.links 2023-11-17 13:29:29.0 +0100
+++ rtpengine-11.5.1.14/debian/rtpengine-daemon.links 2024-01-08 14:10:41.0 +0100
@@ -1 +1 @@
-/lib/systemd/system/rtpengine-daemon.service /lib/systemd/system/rtpengine.service
+${env:deb_systemdsystemunitdir}/rtpengine-daemon.service ${env:deb_systemdsystemunitdir}/rtpengine.service
diff -Nru rtpengine-11.5.1.14/debian/rtpengine-recording-daemon.links rtpengine-11.5.1.14/debian/rtpengine-recording-daemon.links
--- rtpengine-11.5.1.14/debian/rtpengine-recording-daemon.links 2023-11-17 13:29:29.0 +0100
+++ rtpengine-11.5.1.14/debian/rtpengine-recording-daemon.links 2024-01-08 14:11:07.0 +0100
@@ -1 +1 @@
-/lib/systemd/system/rtpengine-recording-daemon.service /lib/systemd/system/rtpengine-recording.service
+${env:deb_systemdsystemunitdir}/rtpengine-recording-daemon.service ${env:deb_systemdsystemunitdir}/rtpengine-recording.service
diff -Nru rtpengine-11.5.1.14/debian/rules rtpengine-11.5.1.14/debian/rules
--- rtpengine-11.5.1.14/debian/rules 2023-11-17 13:29:29.0 +0100
+++ rtpengine-11.5.1.14/debian/rules 2024-01-08 14:10:17.0 +0100
@@ -19,6 +19,8 @@
export DEB_LDFLAGS_MAINT_SET =
endif
+export deb_systemdsystemunitdir = $(shell pkg-config --variable=systemdsystemunitdir systemd)
+
%:
dh $@
Bug#1060202: glibc - autopkgtest flacky on arm64
Hi, On 08-01-2024 01:45, Aurelien Jarno wrote: I am still not sure why it got killed on arm64 and not on other debci workers, there as still swap available. Actually looking at the munin plot, it seems that the arm64 debci workers stopped using swap around September 2023 contrary to the other architectures. Can you tell me how you saw that? I neither spotted that, nor is not having swap a conscious act, so rather a mistake. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056380: AW: Bug#1056380: Same issue under Ubuntu 22.04, reprepro hangs on Ubuntu package, unzstd process waiting
Hi Christoph, Would you please post your change proposals as patches or Merge Requests? That makes it much more easy to review. Thanks, Bastian
Bug#1060255: Instead of certain text, squares are displayed in the interface
tag 1060255 + unreproducible tag 1060255 + moreinfo thanks Hi, Am 08.01.24 um 11:32 schrieb Артём: Package: libreoffice-l10n-ru Version: 4:7.4.7-1+deb12u1 Severity: |important| |Tags: ||l10n| | | For example, in LibreOffice Start Center, some text in the options Which "text in the options"? You mean the buttons? does not display correctly. Works fine here, (assuming LANG=ru_RU.UTF-8. You omitted all of the helpful information reportbug would give.) FWIW, I just looked, for cyrillic languages I don't see "default fonts" defined. Neither in the configs inside libreoffice-l10n-ru: $ grep -i font /etc/libreoffice/registry/Langpack-ru.xcd /etc/libreoffice/registry/res/fcfg_langpack_ru.xcd /etc/libreoffice/registry/res/registry_ru.xcd /etc/libreoffice/registry/res/registry_ru.xcd: oor:name="private:resource/toolbar/fontworkobjectbar"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name="private:resource/toolbar/fontworkshapetype"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name="private:resource/toolbar/fontworkobjectbar"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name="private:resource/toolbar/fontworkshapetype"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name="ooo-emphasis-font"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name="ooo-emphasis-font-color"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name="ooo-emphasis-font-size"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name="ooo-emphasis-font-style"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkGalleryFloater"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkSameLetterHeights"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkAlignmentFloater"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkCharacterSpacingFloater"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-plain-text"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-wave"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-inflate"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-stop"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-curve-up"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-curve-down"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-triangle-up"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-triangle-down"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-fade-right"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-fade-left"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-fade-up"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-fade-down"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-slant-up"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-slant-down"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-fade-up-and-right"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-fade-up-and-left"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-chevron-up"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-chevron-down"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-arch-up-curve"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-arch-down-curve"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-arch-left-curve"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-arch-right-curve"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-circle-curve"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-open-circle-curve"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-arch-up-pour"> /etc/libreoffice/registry/res/registry_ru.xcd: oor:name=".uno:FontworkShapeType.fontwork-arch-down-pour"> /etc/libreoffice/registry/res/registry_ru.xcd:
Bug#1060275: asterisk: Codec translation notice
Hi Daniel, Quoting Daniel via Pkg-voip-maintainers (2024-01-08 16:22:19) > after upgrading from Debian11/asterisk 18.20.2 compiled from source to > Debian12/Asterisk 20.5.2 from unstable, we receive lots of NOTICE logs like > > [2024-01-08 11:35:31] NOTICE[58221][C-028a]: translate.c:603 > ast_translate: 18182 lost frame(s) 48240/30057 (alaw@8000)->(ulaw@8000) > [2024-01-08 11:35:31] NOTICE[58710][C-0298]: translate.c:603 > ast_translate: 1253 lost frame(s) 1254/0 > (slin@16000)->(slin@8000)->(alaw@8000) > > doesn't matter IAX2 or PJSIP endpoints. We are surprised to see such notice > between alaw & ulaw. Codecs used for PJSIP and IAX customers EP are > !all,g722,ulaw,alaw and for providers !all,ulaw,alaw > > We checked translation and tried by adding slin,slin16 on both sides, no > changes. On 18.20.2 we didn't have this behaviour. > > Answer we get from asterisk community list "If you’re using the Debian > package, then that includes patches which are not present in Asterisk > mainline. > Those log messages, and some codec translation behavior, is from one of those > patches." Thanks for your bugreport. It is true that Debian-distributed Asterisk includes patches which may indeed affect the above. But only possibly, not certainly. If it is possible for you to try test your setup with upstream-distributed Asterisk, then it would help ensure that truly what you experience is a bug introduced by a Debian patch. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1060280: linux-image-4.19.0-25-cloud-amd64: PCI ATS quirk patch needed for IDPF
Control: tags -1 moreinfo On Mon, Jan 08, 2024 at 05:48:46PM +, Andrew Jorgensen wrote: > The patch was released in Linux 6.7: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.7=a18615b1cfc04f00548c60eb9a77e0ce56e848fd > It's been backported to 5.15 in the LTS kernels, but customers may need > it in older kernels for Debian. It has been backported to 6.1, so Debian Bookworm will get it. Debian Bullseye will get a backport of the whole kernel. Further backports need at least f18b1137d38c091cc8c16365219f0a1d4a30b3d1. Please also do them via stable@ Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
Bug#1034891: closed by Timo Aaltonen (Re: [Pkg-freeipa-devel] Bug#1034891: 389-ds-base: CVE-2023-1055)
Hi, On Mon, Jan 08, 2024 at 06:56:40PM +0100, Salvatore Bonaccorso wrote: > > Source: 389-ds-base > > Version: 2.3.4+dfsg1-1 > > > > Moritz Mühlenhoff kirjoitti 26.4.2023 klo 20.43: > > > Source: 389-ds-base > > > X-Debbugs-CC: t...@security.debian.org > > > Severity: important > > > Tags: security > > > > > > Hi, > > > > > > The following vulnerability was published for 389-ds-base. > > > > > > CVE-2023-1055[0]: > > > | A flaw was found in RHDS 11 and RHDS 12. While browsing entries LDAP > > > | tries to decode the userPassword attribute instead of the > > > | userCertificate attribute which could lead into sensitive information > > > | leaked. An attacker with a local account where the cockpit-389-ds is > > > | running can list the processes and display the hashed passwords. The > > > | highest threat from this vulnerability is to data confidentiality. > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2173517 > > > > > > 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-1055 > > > https://www.cve.org/CVERecord?id=CVE-2023-1055 > > > > > > Please adjust the affected versions in the BTS as needed. > > > > this was fixed upstream in 2.3.2 > > Do you have a reference to an upstream issue and/or upstream changes > in 2.3.2 which fixes the issue? Or is it actually more related to https://github.com/389ds/389-ds-base/issues/5687 which then would be in 2.3.5 instead? (and inline with fedora importing 2.3.5 and addressing the CVE?) Regards, Salvatore
Bug#1034891: closed by Timo Aaltonen (Re: [Pkg-freeipa-devel] Bug#1034891: 389-ds-base: CVE-2023-1055)
> Source: 389-ds-base > Version: 2.3.4+dfsg1-1 > > Moritz Mühlenhoff kirjoitti 26.4.2023 klo 20.43: > > Source: 389-ds-base > > X-Debbugs-CC: t...@security.debian.org > > Severity: important > > Tags: security > > > > Hi, > > > > The following vulnerability was published for 389-ds-base. > > > > CVE-2023-1055[0]: > > | A flaw was found in RHDS 11 and RHDS 12. While browsing entries LDAP > > | tries to decode the userPassword attribute instead of the > > | userCertificate attribute which could lead into sensitive information > > | leaked. An attacker with a local account where the cockpit-389-ds is > > | running can list the processes and display the hashed passwords. The > > | highest threat from this vulnerability is to data confidentiality. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2173517 > > > > 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-1055 > > https://www.cve.org/CVERecord?id=CVE-2023-1055 > > > > Please adjust the affected versions in the BTS as needed. > > this was fixed upstream in 2.3.2 Do you have a reference to an upstream issue and/or upstream changes in 2.3.2 which fixes the issue? Regards, Salvatore
Bug#1053449: visidata package still has missing dependence on python3-pkg-resources
Yayyy! I'll be reaching out this weekend most likely. =))
On Mon, 8 Jan 2024 at 08:24, Martin wrote:
> Quoting Anja :
> > I am planning to package version 3 in the next week. When is the deadline
> > for Debian12?
>
> Debian 12.4 has been released on 2023-12-10 and I'm not aware of fixed date
> for 12.5. Anyway, version 3 cannot go into Debian 12 ("bookworm"), it can
> only target Debian 13 ("trixie").
>
> For Debian 12, we can do two things:
>
> 1. Fix the missing dependency in a package 2.11-1+deb12u1 for Debian 12.5
> (or, if things go wrong badly, for 12.6)
>
> 2. Prepare a backport of version 3, as soon as the package is in Debian
> testing (typically five days after upload to unstable)
>
> I can guide you through this jungle and later sponsor the uploads, np.
> It's easier than it might sound!
>
> Cheers, Martin
>
Bug#1060281: ITP: r-cran-marginaleffects -- GNU R predictions, comparisons, slopes, marginal means, and hypothesis
Package: wnpp Severity: wishlist Subject: ITP: r-cran-marginaleffects -- GNU R predictions, comparisons, slopes, marginal means, and hypothesis Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-marginaleffects Version : 0.17.0 Upstream Author : Vincent Arel-Bundock, Marcio Augusto Diniz, * URL : https://cran.r-project.org/package=marginaleffects * License : GPL-3+ Programming Lang: GNU R Description : GNU R predictions, comparisons, slopes, marginal means, and hypothesis Tests Compute and plot predictions, slopes, marginal means, and comparisons (contrasts, risk ratios, odds, etc.) for over 100 classes of statistical and machine learning models in R. Conduct linear and non- linear hypothesis tests, or equivalence tests. Calculate uncertainty estimates using the delta method, bootstrapping, or simulation-based inference. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-marginaleffects
Bug#1060280: linux-image-4.19.0-25-cloud-amd64: PCI ATS quirk patch needed for IDPF
Package: src:linux Version: 4.19.289-2 Severity: normal Dear Maintainer, Intel has introduced a new network card. They have submitted the driver to the upstream kernel. We don't know if it's reasonable to ask that this driver be backported to Debian, or to older versions of Debian, but in order to use an out-of-tree driver on older versions, a PCI ATS quirks patch is needed for some early versions of the hardware. Thus we're asking if it's possible to backport that quirks patch to older versions of Debian, so that users can use the out-of-tree driver. The patch was released in Linux 6.7: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.7=a18615b1cfc04f00548c60eb9a77e0ce56e848fd It's been backported to 5.15 in the LTS kernels, but customers may need it in older kernels for Debian. -- Package-specific info: ** Kernel log: boot messages should be attached -- System Information: Debian Release: 10.13 APT prefers oldoldstable-updates APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-24-cloud-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-4.19.0-25-cloud-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.133+deb10u1 ii kmod26-1 ii linux-base 4.6 Versions of packages linux-image-4.19.0-25-cloud-amd64 recommends: ii apparmor 2.13.2-10 ii firmware-linux-free 3.4 Versions of packages linux-image-4.19.0-25-cloud-amd64 suggests: pn debian-kernel-handbook ii grub-pc 2.06-3~deb10u4 pn linux-doc-4.19 Versions of packages linux-image-4.19.0-25-cloud-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#1060279: ITP: r-cran-nanoarrow -- GNU R interface to the 'nanoarrow' 'C' Library
Package: wnpp Severity: wishlist Subject: ITP: r-cran-nanoarrow -- GNU R interface to the 'nanoarrow' 'C' Library Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-nanoarrow Version : 0.3.0.1 Upstream Author : Dewey Dunnington, * URL : https://cran.r-project.org/package=nanoarrow * License : Apache-2.0 Programming Lang: GNU R Description : GNU R interface to the 'nanoarrow' 'C' Library Provides an 'R' interface to the 'nanoarrow' 'C' library and the 'Apache Arrow' application binary interface. Functions to import and export 'ArrowArray', 'ArrowSchema', and 'ArrowArrayStream' 'C' structures to and from 'R' objects are provided alongside helpers to facilitate zero-copy data transfer among 'R' bindings to libraries implementing the 'Arrow' 'C' data interface. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-nanoarrow
Bug#1060278: gnome-backgrounds: Update to 46
Source: gnome-backgrounds Version: 45.0-1 Severity: wishlist Control: block -1 by 1001786 Control: affects -1 src:gsettings-desktop-schemas gnome-backgrounds 46 is switching several of its provided wallpaper images to the JPEG XL format. These wallpapers will not be displayed in the GNOME 46 desktop unless the jpeg-xl gdk-pixbuf support is installed. Therefore, we need to have something depend on the jpeg-xl gdk-pixbuf package once it's available in Debian Unstable (it is not available yet). Meanwhile, we need to revert the gsettings-desktop-schemas default wallpaper filename to continue using the GNOME 45 version until gnome-backgrounds 46 is in Debian Unstable. Thank you, Jeremy Bícha
Bug#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf
Control: retitle -1 valgrind: Access not within mapped region on armhf Hello Paul and Julian, On 2023-12-24 07:31, Paul Gevers wrote: > On 23-12-2023 20:40, Julian Andres Klode wrote: > > the logs for well known bugs so that you don't end up filing bugs > > against every package broken by valgrind's missing support for the new > > NOP sequences in binutils. > > I do *some* minor triaging, but I didn't know this to be a common problem. Note that there are three distinct valgrind problems mentioned here: - on armhf, flagging accesses below the stack pointer as illegal. This came up after enabling stack-clash-protection on armhf. I added a suppression for this problem in valgrind 1:3.20.0-2, so we shouldn't be seeing those anymore. For reference: https://lists.debian.org/debian-arm/2023/12/msg7.html - on i386, valgrind was failing due to new nop patterns that it didn't know about. This is https://bugs.debian.org/1057693 and was fixed by Aurelien in 1:3.20.0-2.1 - on armhf, a segfault when testing apt. I don't think this issue is widespread at all: in fact I'm not aware of any other instances except for apt. After going through all armhf CI failures caused by segfaults, apt seems to be the only one with valgrind in the picture. Just to be clear: I'm not saying that the problem is trivial, just that AFAIK it's not widespread. I'm including the relevant CI logs below for reference. Also I'm attaching the horrible script I've written to fetch all armhf CI failures in case anyone wants to poke around. 722s ==221367== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. 722s ==221367== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info 722s ==221367== Command: /usr/bin/apt-get update -o Acquire::Queue-Mode=access 722s ==221367== 722s ==221367== 722s ==221367== Process terminating with default action of signal 11 (SIGSEGV) 722s ==221367== Access not within mapped region at address 0xFE7F2A9C 722s ==221367==at 0x4938838: ReadMessages(int, std::vector, std::allocator >, std::allocator, std::allocator > > >&) (in /usr/lib/arm-linux-gnueabihf/libapt-pkg.so.6.0.0) 722s ==221367== If you believe this happened as a result of a stack 722s ==221367== overflow in your program's main thread (unlikely but 722s ==221367== possible), you can try to increase the size of the 722s ==221367== main thread stack using the --main-stacksize= flag. 722s ==221367== The main thread stack size used in this run was 8388608. 722s ==221367== 722s ==221367== HEAP SUMMARY: 722s ==221367== in use at exit: 119,915 bytes in 1,882 blocks 722s ==221367== total heap usage: 11,673 allocs, 9,791 frees, 868,849 bytes allocated 722s ==221367== 722s ==221367== LEAK SUMMARY: 722s ==221367==definitely lost: 0 bytes in 0 blocks 722s ==221367==indirectly lost: 0 bytes in 0 blocks 722s ==221367== possibly lost: 0 bytes in 0 blocks 722s ==221367==still reachable: 119,915 bytes in 1,882 blocks 722s ==221367== suppressed: 0 bytes in 0 blocks 722s ==221367== Rerun with --leak-check=full to see details of leaked memory 722s ==221367== 722s ==221367== For lists of detected and suppressed errors, rerun with: -s 722s ==221367== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 42821 from 965) 722s Segmentation fault 722s FAIL: exitcode 139 armhf-ci-segfaults.sh Description: Bourne shell script
Bug#1060269: /lib/cryptsetup/askpass: coordinated move to /usr for DEP17
On Mon, Jan 08, 2024 at 02:56:16PM +0100, Helmut Grohne wrote:
> I've done a similar conversion for molly-guard/systemd and have prepared
> patches for cryptsetup-nuke-password and cryptsetup. Notably:
I actually forgot to attach the patches (thanks Raphael), so here go the
patches.
What I also forgot to mention is that I applied quite some testing. You
cannot test these patches with piuparts, because they need to be
upgraded in lockstep, so I wrote a kind of mini-piuparts based on
debhelper that specifically validates all kinds of upgrades and checks
for correct diversions. Also attaching the tests.
Hope this is good to upload now.
Helmut
diff --minimal -Nru cryptsetup-2.6.1/debian/changelog
cryptsetup-2.6.1/debian/changelog
--- cryptsetup-2.6.1/debian/changelog 2023-12-05 17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/changelog 2024-01-05 18:56:40.0 +0100
@@ -1,3 +1,10 @@
+cryptsetup (2:2.6.1-6.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * DEP17: Move fles to /usr. (Closes: #-1)
+
+ -- Helmut Grohne Fri, 05 Jan 2024 18:56:40 +0100
+
cryptsetup (2:2.6.1-6) unstable; urgency=medium
[ Kevin Locke ]
diff --minimal -Nru cryptsetup-2.6.1/debian/control
cryptsetup-2.6.1/debian/control
--- cryptsetup-2.6.1/debian/control 2023-12-05 17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/control 2024-01-05 18:56:40.0 +0100
@@ -63,6 +63,7 @@
Architecture: linux-any
Multi-Arch: foreign
Depends: ${misc:Depends}, ${shlibs:Depends}
+Conflicts: cryptsetup-nuke-password (<< 4+nmu2~)
Description: disk encryption support - command line tools
Cryptsetup provides an interface for configuring encryption on block
devices (such as /home or swap partitions), using the Linux kernel
diff --minimal -Nru cryptsetup-2.6.1/debian/cryptsetup-bin.install
cryptsetup-2.6.1/debian/cryptsetup-bin.install
--- cryptsetup-2.6.1/debian/cryptsetup-bin.install 2023-12-05
17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/cryptsetup-bin.install 2024-01-05
18:56:40.0 +0100
@@ -1,5 +1,5 @@
-sbin/cryptsetup
-sbin/integritysetup
-sbin/veritysetup
+usr/sbin/cryptsetup
+usr/sbin/integritysetup
+usr/sbin/veritysetup
usr/lib/tmpfiles.d/cryptsetup.conf
usr/share/locale/*/*/*
diff --minimal -Nru cryptsetup-2.6.1/debian/cryptsetup-ssh.install
cryptsetup-2.6.1/debian/cryptsetup-ssh.install
--- cryptsetup-2.6.1/debian/cryptsetup-ssh.install 2023-12-05
17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/cryptsetup-ssh.install 2024-01-05
18:56:40.0 +0100
@@ -1,2 +1,2 @@
-lib/${DEB_HOST_MULTIARCH}/cryptsetup/libcryptsetup-token-ssh.so
-sbin/cryptsetup-ssh
+usr/lib/${DEB_HOST_MULTIARCH}/cryptsetup/libcryptsetup-token-ssh.so
+usr/sbin/cryptsetup-ssh
diff --minimal -Nru cryptsetup-2.6.1/debian/cryptsetup-suspend.install
cryptsetup-2.6.1/debian/cryptsetup-suspend.install
--- cryptsetup-2.6.1/debian/cryptsetup-suspend.install 2023-12-05
17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/cryptsetup-suspend.install 2024-01-05
18:56:40.0 +0100
@@ -1,5 +1,5 @@
-debian/scripts/suspend/cryptsetup-suspend /lib/cryptsetup/scripts/suspend/
-debian/scripts/suspend/cryptsetup-suspend-wrapper
/lib/cryptsetup/scripts/suspend/
-debian/scripts/suspend/cryptsetup-suspend.shutdown
/lib/systemd/system-shutdown/
+debian/scripts/suspend/cryptsetup-suspend /usr/lib/cryptsetup/scripts/suspend/
+debian/scripts/suspend/cryptsetup-suspend-wrapper
/usr/lib/cryptsetup/scripts/suspend/
+debian/scripts/suspend/cryptsetup-suspend.shutdown
/usr/lib/systemd/system-shutdown/
debian/scripts/suspend/suspend.conf /etc/cryptsetup/
-debian/scripts/suspend/systemd/cryptsetup-suspend.conf
/lib/systemd/system/systemd-suspend.service.d/
+debian/scripts/suspend/systemd/cryptsetup-suspend.conf
/usr/lib/systemd/system/systemd-suspend.service.d/
diff --minimal -Nru cryptsetup-2.6.1/debian/cryptsetup-udeb.install
cryptsetup-2.6.1/debian/cryptsetup-udeb.install
--- cryptsetup-2.6.1/debian/cryptsetup-udeb.install 2023-12-05
17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/cryptsetup-udeb.install 2024-01-05
18:56:40.0 +0100
@@ -1,7 +1,7 @@
-debian/askpass /lib/cryptsetup/
-debian/checks/* /lib/cryptsetup/checks/
-debian/cryptdisks-functions /lib/cryptsetup/
-debian/functions/lib/cryptsetup/
-debian/scripts/decrypt_*/lib/cryptsetup/scripts/
-debian/scripts/passdev /lib/cryptsetup/scripts/
-sbin/cryptsetup
+debian/askpass /usr/lib/cryptsetup/
+debian/checks/* /usr/lib/cryptsetup/checks/
+debian/cryptdisks-functions /usr/lib/cryptsetup/
+debian/functions/usr/lib/cryptsetup/
+debian/scripts/decrypt_*/usr/lib/cryptsetup/scripts/
+debian/scripts/passdev /usr/lib/cryptsetup/scripts/
+usr/sbin/cryptsetup
diff --minimal -Nru cryptsetup-2.6.1/debian/cryptsetup.install
cryptsetup-2.6.1/debian/cryptsetup.install
--- cryptsetup-2.6.1/debian/cryptsetup.install 2023-12-05
Bug#1060100: r-cran-rstanarm: FTBFS: Error: segfault from C stack overflow
Control: tags -1 moreinfo Control: tags -1 unreproducible Hi Sebastian, I tried to reproduce the problem in a (pbuilder) chroot locally but here all went fine. Please note that r-cran-rstanarm is a quite resource-hungry build. Could you please make sure there are sufficient resources available for the build? Kind regards Andreas. -- http://fam-tille.de
Bug#1060277: pdfproctools: typo in setpdfmetadata man page
Package: pdfproctools Version: 1.9.4-1 Severity: minor Dear Maintainer, There is a typo in man page of setpdfmetadata: title Subject Sets the document subject to the given value. It should probably be "subject Subject" instead of "title Subject". -- 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/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pdfproctools depends on: ii ghostscript 10.0.0~dfsg-11+deb12u3 ii libpdf-api2-perl 2.044-1 ii perl 5.36.0-7+deb12u1 ii qpdf 11.3.0-1+deb12u1 pdfproctools recommends no packages. pdfproctools suggests no packages.
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Mon, Jan 08, 2024 at 04:12:42PM +0100, Julian Andres Klode wrote: > > - once these packages have all cleared binary NEW, the new dpkg defaults > > will be uploaded to unstable > What happened to the plan to workaround this by doing dak database > shenanigans prior to uploading to avoid binary-NEW altogether, that > I chatted about with mhy/#debian-ftp and you? Did that not work out? That wasn't called out here but is part of the implementation details of the plan. The intention is still to go through binary NEW in experimental before copying to unstable, because it will take time to get all the binary uploads done (longer than it will take to get the sourceful uploads to unstable done), so it's better to stage in experimental to minimize the window in unstable when uploads can be broken. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1053449: visidata package still has missing dependence on python3-pkg-resources
Quoting Anja :
I am planning to package version 3 in the next week. When is the deadline
for Debian12?
Debian 12.4 has been released on 2023-12-10 and I'm not aware of fixed date
for 12.5. Anyway, version 3 cannot go into Debian 12 ("bookworm"), it can
only target Debian 13 ("trixie").
For Debian 12, we can do two things:
1. Fix the missing dependency in a package 2.11-1+deb12u1 for Debian 12.5
(or, if things go wrong badly, for 12.6)
2. Prepare a backport of version 3, as soon as the package is in Debian
testing (typically five days after upload to unstable)
I can guide you through this jungle and later sponsor the uploads, np.
It's easier than it might sound!
Cheers, Martin
Bug#1056471: python-fabio: debdiff with patch from upstream recommendation
This looks good to be. Thanks for your contribution. Cheers, -- Jérôme Kieffer
Bug#1053449: visidata package still has missing dependence on python3-pkg-resources
I am planning to package version 3 in the next week. When is the deadline for Debian12? On Mon, 8 Jan 2024 at 06:21, John wrote: > Package: visidata > Version: 2.11-1 > Followup-For: Bug #1053449 > > Dear Maintainer, > > -- System Information: > Debian Release: 12 up to date at 13:00 1Jan2024 > > After installing the visidata package, the command vd gave output > ModuleNotFoundError: No module named 'pkg_resources' > > The visidata pkg should have a dependence on python3-pkg-resources > With that package installed, it works. > > This was reported 4 Oct 2023 Debian Bug report #1053449 > > Anja wrote on 15 Dec 2023 > We actually are going to address this in the next release: > v3.0 is slated for in the next 2-4 weeks. > > Will Debian12 get version 3? If not, the bug will persist in Debian12. > > John >
Bug#1060276: pygalmesh: autopkgtest regression in testing
Source: pygalmesh
Version: 0.10.6-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime between 2023-11-08 and 2023-12-06, pygalmesh's autopkgtests
started to fail in testing [1][2]. I've copied what I hope is the
relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/packages/p/pygalmesh/testing/amd64/
[2] https://ci.debian.net/packages/p/pygalmesh/testing/armhf/
98s === FAILURES
===
98s ___ test_inr
___
98s
98s def test_inr():
98s this_dir = pathlib.Path(__file__).resolve().parent
98s # mesh = pygalmesh.generate_from_inr(
98s # this_dir / "meshes" / "skull_2.9.inr",
max_cell_circumradius=5.0, verbose=False
98s # )
98s with tempfile.TemporaryDirectory() as tmp:
98s out_filename = str(pathlib.Path(tmp) / "out.vtk")
98s pygalmesh._cli.cli(
98s [
98s "from-inr",
98s str(this_dir / "meshes" / "sphere.inr"),
98s out_filename,
98s "--max-cell-circumradius",
98s "1.0",
98s "--quiet",
98s ]
98s )
98s mesh = meshio.read(out_filename)
98s
98s vals_refs = [
98s (max(mesh.points[:, 0]), 9.00478554e00),
98s (min(mesh.points[:, 0]), -4.25843196e-03),
98s (max(mesh.points[:, 1]), 9.00332642e00),
98s (min(mesh.points[:, 1]), -4.41271299e-03),
98s (max(mesh.points[:, 2]), 9.00407982e00),
98s (min(mesh.points[:, 2]), -3.98639357e-03),
98s ]
98s for val, ref in vals_refs:
98s > assert abs(val - ref) < 1.0e-3 * (1.0 + abs(ref)), f"{val:.8e}
!= {ref:.8e}"
98s E AssertionError: -4.99461079e-03 != -3.98639357e-03
98s E assert 0.0010082172201632787 < (0.001 * (1.0 + 0.00398639357))
98s E + where 0.0010082172201632787 = abs((-0.004994611 - -0.00398639357))
98s E + and 0.00398639357 = abs(-0.00398639357)
98s
98s tests/test_inr.py:38: AssertionError
Bug#1060275: asterisk: Codec translation notice
Package: asterisk Version: 1:20.5.2~dfsg+~cs6.13.40431414-1 Severity: normal Tags: upstream Dear Maintainer, after upgrading from Debian11/asterisk 18.20.2 compiled from source to Debian12/Asterisk 20.5.2 from unstable, we receive lots of NOTICE logs like [2024-01-08 11:35:31] NOTICE[58221][C-028a]: translate.c:603 ast_translate: 18182 lost frame(s) 48240/30057 (alaw@8000)->(ulaw@8000) [2024-01-08 11:35:31] NOTICE[58710][C-0298]: translate.c:603 ast_translate: 1253 lost frame(s) 1254/0 (slin@16000)->(slin@8000)->(alaw@8000) doesn't matter IAX2 or PJSIP endpoints. We are surprised to see such notice between alaw & ulaw. Codecs used for PJSIP and IAX customers EP are !all,g722,ulaw,alaw and for providers !all,ulaw,alaw We checked translation and tried by adding slin,slin16 on both sides, no changes. On 18.20.2 we didn't have this behaviour. Answer we get from asterisk community list "If you’re using the Debian package, then that includes patches which are not present in Asterisk mainline. Those log messages, and some codec translation behavior, is from one of those patches." Thanks for your support -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.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 asterisk depends on: ii adduser 3.134 ii asterisk-config 1:20.5.2~dfsg+~cs6.13.40431414-1 ii asterisk-core-sounds-en 1.6.1-1 ii asterisk-modules 1:20.5.2~dfsg+~cs6.13.40431414-1 ii init-system-helpers 1.65.2 ii libc62.36-9+deb12u3 ii libcap2 1:2.66-4 ii libcrypt11:4.4.33-2 ii libedit2 3.1-20221030-2 ii libjansson4 2.14-2 ii libpopt0 1.19+dfsg-1 ii libsqlite3-0 3.40.1-2 ii libssl3 3.0.11-1~deb12u2 ii libsystemd0 252.19-1~deb12u1 ii liburiparser10.9.7+dfsg-2 ii libuuid1 2.38.1-5+b1 ii libxml2 2.9.14+dfsg-1.3~deb12u1 ii libxslt1.1 1.1.35-1 Versions of packages asterisk recommends: ii asterisk-moh-opsound-gsm 2.03-1.1 ii sox 14.4.2+git20190427-4 Versions of packages asterisk suggests: pn asterisk-dahdi pn asterisk-dev pn asterisk-doc pn asterisk-ooh323 pn asterisk-opus -- no debconf information
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hey Steve,
On Sat, Jan 06, 2024 at 07:38:42PM -0800, Steve Langasek wrote:
> On Sat, Jan 06, 2024 at 09:25:52AM +0100, Rene Engelhard wrote:
> > Hi,
>
> > Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > > - dpkg will be uploaded to experimental with 64-bit time_t in the
> > > > > default
> > > > > flags
> > > [...]
> > > What about the suggestion to not push changes to experimental for packages
> > > that already have new versions in experimental, and do the binary package
> > > renames in unstable instead, leaving the package in experimental alone?
>
> > How does that play together with the needed dpkg only in experimental?
>
> > You can't build stuff for unstable involving experimental packages (except
> > manually with binary upload, which would block testing migration)
>
> The ordering here would be:
>
> - dpkg will be uploaded to experimental with 64-bit time_t in the default
> flags
>
> - the source packages which need an ABI change
> ("source-packages"+"lfs-and-depends-time_t") and do not already have
> versions in experimental, will have sourceful NMUs to experimental with
> the new binary package names in order to clear binary NEW, in coordination
>
> - once these packages have all cleared binary NEW, the new dpkg defaults
> will be uploaded to unstable
What happened to the plan to workaround this by doing dak database
shenanigans prior to uploading to avoid binary-NEW altogether, that
I chatted about with mhy/#debian-ftp and you? Did that not work out?
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
signature.asc
Description: PGP signature
Bug#1060274: RFS: python-acora/2.4-1.1 [NMU] [RC] -- fast multi-keyword text search engine (Python 2)
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "python-acora": * Package name : python-acora Version : 2.4-1.1 Upstream contact : [fill in name and email of upstream] * URL : https://pypi.python.org/pypi/acora * License : BSD-3-Clause * Vcs : https://salsa.debian.org/debian/python-acora.git Section : python The source builds the following binary packages: python-acora - fast multi-keyword text search engine (Python 2) python3-acora - fast multi-keyword text search engine (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-acora/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-acora/python-acora_2.4-1.1.dsc Changes since the last upload: python-acora (2.4-1.1) unstable; urgency=medium . * Non-maintainer upload. * New upstream version 2.4. (Closes: #1056849, #1055707). * Remove python2 on B-D and pybuild. * Add extend-diff-ignore to fix dpkg-source -b check issue. -- Regards, -- Bo YU signature.asc Description: PGP signature
Bug#1060265: Acknowledgement (ITP: python-django-ansible-base -- Reusable base for Ansible applications using Django)
django-ansible-base is not yet published on pypi, so for now it'll stay embedded in awx.
