Bug#1024471: cloudpickle FTBFS: multiple tests fail
Source: cloudpickle Severity: important Tag: ftbfs Dear Maintainer, I've tried to build your package in a local sid chroot environment but the process ends up in a failure (log attached). After packaging 2.2.0 from pypi [1], most of autokgtest failures vanishe and only two test still fail as reported upstream [2]. There is a opened PR to address those and I can confirm that it solves the issue. Side notes: 1) reproducible-builds doesn't catch yet full failures because the build happened before python3.11 [3] 2) Severity "important" since this issue is unconfirmed by others different than me Kind Regards [1] https://pypi.org/project/cloudpickle/ [2] https://github.com/cloudpipe/cloudpickle/pull/486 [3] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cloudpickle.html ftbfs.log.tar.gz Description: application/gzip
Bug#1024470: ITP: golang-github-hirochachacha-go-smb2 -- SMB2/3 client library written in Go.
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: golang-github-hirochachacha-go-smb2 Version : 1.1.0-1 Upstream Author : xHiroshi Ioka * URL : https://github.com/hirochachacha/go-smb2 * License : BSD-2-clause Programming Lang: Go Description : SMB2/3 client library written in Go. SMB2/3 client implementation for the Go language. Required by the latest version of rclone To be maintained by the Debian Go Team.
Bug#1023046: zabbix: FTBFS: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
On Sat, Oct 29, 2022 at 04:51:19PM +, Mathias Gibbens wrote: > Source: zabbix > Version: 1:6.0.9+dfsg-1.1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > > While rebuilding the reverse build dependencies of another golang > package I'm updating, I noticed that zabbix fails to build in a clean > sid chroot. I suspect this was likely caused by the recent update of > the golang-golang-x-sys package, but I haven't investigated further. > > > on.compileArch=`go env GOARCH` -X main.applicationName=zabbix_web_service" > > -o bin zabbix.com/cmd/zabbix_web_service > > > > [snip] > > > > golang.org/x/text/unicode/norm > > # golang.org/x/sys/unix > > vendor/golang.org/x/sys/unix/syscall.go:83:16: unsafe.Slice requires go1.17 > > or later (-lang was set to go1.16; check go.mod) > > vendor/golang.org/x/sys/unix/syscall_linux.go:2255:9: unsafe.Slice requires > > go1.17 or later (-lang was set to go1.16; check go.mod) > > vendor/golang.org/x/sys/unix/syscall_unix.go:118:7: unsafe.Slice requires > > go1.17 or later (-lang was set to go1.16; check go.mod) > > vendor/golang.org/x/sys/unix/sysvshm_unix.go:33:7: unsafe.Slice requires > > go1.17 or later (-lang was set to go1.16; check go.mod) > > zabbix.com/pkg/procfs > > # golang.org/x/sys/unix > > vendor/golang.org/x/sys/unix/syscall.go:83:16: unsafe.Slice requires go1.17 > > or later (-lang was set to go1.16; check go.mod) > > vendor/golang.org/x/sys/unix/syscall_linux.go:2255:9: unsafe.Slice requires > > go1.17 or later (-lang was set to go1.16; check go.mod) > > vendor/golang.org/x/sys/unix/syscall_unix.go:118:7: unsafe.Slice requires > > go1.17 or later (-lang was set to go1.16; check go.mod) > > vendor/golang.org/x/sys/unix/sysvshm_unix.go:33:7: unsafe.Slice requires > > go1.17 or later (-lang was set to go1.16; check go.mod) This comes from the new version of golang-golang-x-sys, see also [1]. cu Adrian [1] https://tracker.debian.org/news/1384566/accepted-golang-golang-x-sys-010-1bpo111-source-into-bullseye-backports/
Bug#1023647: gdal: add jpeg-xl support
On 11/8/22 09:46, Sebastiaan Couwenberg wrote: On 11/8/22 09:33, Mathieu Malaterre wrote: Please add jpeg-xl support: * https://github.com/libjxl/libjxl/blob/main/doc/software_support.md#image-libraries GDAL: supported since 3.4.0 as a TIFF codec, and 3.6.0 as standalone format We don't use the internal copy of libtiff for the gdal package. From the 3.6.0 NEWS: " libjxl: for JPEGXL driver (it was already a potential dependency in past versions, when using internal libtiff, to get the JXL TIFF codec) " The above triggered this change: https://salsa.debian.org/debian-gis-team/gdal/-/commit/c0e50be811b65f4112c55e03ced35bbb03e16a1c And because jpeg-xl is not available on s390x (#1023746), the driver has been disabled again. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1024469: lib/debian/tests/test_debfile.py::TestDebFile::test_control fails when tar(1) is not GNU tar
Package: python-debian
Version: 0.1.49
When tar(1) executable is a non-GNU implementation of tar (bsdtar from
libarchive here), test_control fails trying to pass unsupported `--
warning=no-timestamp` option:
```
=== FAILURES ===
___ TestDebFile.test_control ___
self =
sample_deb = '/tmp/portage/dev-python/python-debian-
0.1.49/temp/test_debfile.cwjvb8xc/test.ar'
@pytest.mark.skipif(not _dpkg_deb_path, reason="dpkg-deb not
installed")
def test_control(self, sample_deb):
# type: (str) -> None
""" test for control contents equality """
with os.popen("dpkg-deb -f %s" % sample_deb) as dpkg_deb:
filecontrol = "".join(dpkg_deb.readlines())
with debfile.DebFile(sample_deb) as deb:
ctrl = deb.control.get_content("control")
assert ctrl is not None
> assert ctrl.decode("utf-8") == filecontrol
[... cut long diff between expcected and "" ...]
deb=
dpkg_deb =
filecontrol = ''
sample_deb = '/tmp/portage/dev-python/python-debian-
0.1.49/temp/test_debfile.cwjvb8xc/test.ar'
self =
lib/debian/tests/test_debfile.py:623: AssertionError
- Captured stderr call -
tar: Option --warning=no-timestamp is not supported
Usage:
List:tar -tf
Extract: tar -xf
Create: tar -cf [filenames...]
Help:tar --help
dpkg-deb: error: tar subprocess returned error exit status 1
```
This is Gentoo Linux/amd64 with libarchive-3.6.1. GNU tar is available
as `gtar` if you really need it. I suspect the same problem applies to
*BSD systems.
--
Best regards,
Michał Górny
Bug#1024468: gpgme1.0: diff for NMU version 1.18.0-2.1
Package: gpgme1.0
Version: 1.18.0-2
Severity: normal
Tags: patch
Dear maintainer,
I've prepared an NMU for gpgme1.0 (versioned as 1.18.0-2.1) and
uploaded it to unstable. Please also see
https://salsa.debian.org/debian/gpgme/-/merge_requests/9
kind regards
Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru gpgme1.0-1.18.0/debian/changelog gpgme1.0-1.18.0/debian/changelog
--- gpgme1.0-1.18.0/debian/changelog 2022-11-02 15:54:12.0 +0100
+++ gpgme1.0-1.18.0/debian/changelog 2022-11-20 07:16:46.0 +0100
@@ -1,3 +1,16 @@
+gpgme1.0 (1.18.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Cherrypicked from upstream GIT:
++ 0015-build-Prefer-gpgrt-config-when-available.patch,
+ 0016-gpgme.m4-Include-_AM_PATH_GPGRT_CONFIG-implementatio.patch: Update
+ gpgme.m4 to prefer gpgrt-config even if gpgme-config was available and
+ to find gpgrt-config when AM_PATH_GPG_ERROR was not used.
++ 0017-doc-Update-documentation-for-gpgme.pc-and-pkg-config.patch:
+ Document pkg-config instead of gpgme-config in manual.
+
+ -- Andreas Metzler Sun, 20 Nov 2022 07:16:46 +0100
+
gpgme1.0 (1.18.0-2) unstable; urgency=medium
[ Andreas Metzler ]
diff -Nru gpgme1.0-1.18.0/debian/patches/0015-build-Prefer-gpgrt-config-when-available.patch gpgme1.0-1.18.0/debian/patches/0015-build-Prefer-gpgrt-config-when-available.patch
--- gpgme1.0-1.18.0/debian/patches/0015-build-Prefer-gpgrt-config-when-available.patch 1970-01-01 01:00:00.0 +0100
+++ gpgme1.0-1.18.0/debian/patches/0015-build-Prefer-gpgrt-config-when-available.patch 2022-11-20 06:53:26.0 +0100
@@ -0,0 +1,59 @@
+From 9f55dceca0cf2926d14cb4a70bd0cdc454d89f03 Mon Sep 17 00:00:00 2001
+From: NIIBE Yutaka
+Date: Wed, 2 Nov 2022 10:08:52 +0900
+Subject: [PATCH] build: Prefer gpgrt-config when available.
+
+* src/gpgme.m4: Overriding the decision by --with-gpgme-prefix,
+use gpgrt-config gpgme when gpgrt-config is available.
+
+--
+
+This may offer better migration.
+
+GnuPG-bug-id: 5034
+Signed-off-by: NIIBE Yutaka
+---
+ src/gpgme.m4 | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/gpgme.m4 b/src/gpgme.m4
+index c749a5dd..09a282d0 100644
+--- a/src/gpgme.m4
b/src/gpgme.m4
+@@ -5,15 +5,15 @@
+ # unlimited permission to copy and/or distribute it, with or without
+ # modifications, as long as this notice is preserved.
+ #
+ # This file is distributed in the hope that it will be useful, but
+ # WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
+ # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ #
+-# Last-changed: 2020-11-20
++# Last-changed: 2022-11-02
+
+
+ AC_DEFUN([_AM_PATH_GPGME_CONFIG],
+ [ AC_ARG_WITH(gpgme-prefix,
+ AS_HELP_STRING([--with-gpgme-prefix=PFX],
+[prefix where GPGME is installed (optional)]),
+ gpgme_config_prefix="$withval", gpgme_config_prefix="")
+@@ -33,15 +33,15 @@ AC_DEFUN([_AM_PATH_GPGME_CONFIG],
+AC_MSG_WARN([Ignoring \$SYSROOT as it is not an absolute path.])
+;;
+esac
+ fi
+ fi
+
+ use_gpgrt_config=""
+- if test x"${GPGME_CONFIG}" = x -a x"$GPGRT_CONFIG" != x -a "$GPGRT_CONFIG" != "no"; then
++ if test x"$GPGRT_CONFIG" != x -a "$GPGRT_CONFIG" != "no"; then
+ if $GPGRT_CONFIG gpgme --exists; then
+ GPGME_CONFIG="$GPGRT_CONFIG gpgme"
+ AC_MSG_NOTICE([Use gpgrt-config as gpgme-config])
+ use_gpgrt_config=yes
+ fi
+ fi
+ if test -z "$use_gpgrt_config"; then
+--
+2.35.1
+
diff -Nru gpgme1.0-1.18.0/debian/patches/0016-gpgme.m4-Include-_AM_PATH_GPGRT_CONFIG-implementatio.patch gpgme1.0-1.18.0/debian/patches/0016-gpgme.m4-Include-_AM_PATH_GPGRT_CONFIG-implementatio.patch
--- gpgme1.0-1.18.0/debian/patches/0016-gpgme.m4-Include-_AM_PATH_GPGRT_CONFIG-implementatio.patch 1970-01-01 01:00:00.0 +0100
+++ gpgme1.0-1.18.0/debian/patches/0016-gpgme.m4-Include-_AM_PATH_GPGRT_CONFIG-implementatio.patch 2022-11-20 06:53:26.0 +0100
@@ -0,0 +1,144 @@
+From abd51848bdc8a5ea5929f9cfb819a408dc53d463 Mon Sep 17 00:00:00 2001
+From: NIIBE Yutaka
+Date: Tue, 15 Nov 2022 13:40:57 +0900
+Subject: [PATCH 1/2] gpgme.m4: Include _AM_PATH_GPGRT_CONFIG implementation.
+
+* src/gpgme.m4 (_AM_PATH_GPGRT_CONFIG): New.
+(_AM_PATH_GPGME_CONFIG): Require _AM_PATH_GPGRT_CONFIG.
+
+--
+
+GnuPG-bug-id: 6273
+Signed-off-by: NIIBE Yutaka
+---
+ src/gpgme.m4 | 101 ---
+ 1 file changed, 95 insertions(+), 6 deletions(-)
+
+diff --git a/src/gpgme.m4 b/src/gpgme.m4
+index 09a282d0..363a84f3 100644
+--- a/src/gpgme.m4
b/src/gpgme.m4
+@@ -1,25 +1,114 @@
+ # gpgme.m4 - autoconf macro to detect GPGME.
+-# Copyright (C) 2002, 2003, 2004, 2014, 2018 g10 Code GmbH
++# Copyright (C) 2002, 2003, 2004, 2014, 2018, 2022 g10 Code GmbH
+ #
+ # This file is free
Bug#1024467: monitoring-plugins-contrib: update-check_libs-status is referenced but missing
Package: monitoring-plugins-contrib Version: 37.20211217~bpo11+1 Severity: normal Dear Maintainer, update-check_libs-status is referenced but missing. looking through the snapshot.debian.org source packages, it appears that /usr/lib/nagios/cronjobs/update-check_libs-status was included in 26.20200508 but not in 27.20200511. however, its removal is not noted in the changelog and it is still referenced in /etc/check_multi/check_apt.cmd. when copied from a buster system onto a bullseye system it seems to work. if it was removed in error, could it be re-added? if it was removed on purpose, the reference to it should also probably be removed. thanks in advance. andy -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/6 CPU threads) 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 monitoring-plugins-contrib depends on no packages. Versions of packages monitoring-plugins-contrib recommends: ii bind9-host 1:9.16.33-1~deb11u1 ii binutils 2.35.2-2 ii curl 7.74.0-1.3+deb11u3 ii debsecan 0.4.20.1 ii file 1:5.39-3 ii freeipmi-tools 1.6.6-4+deb11u1 ii libc62.31-13+deb11u5 ii libdata-validate-domain-perl 0.10-1.1 ii libdata-validate-ip-perl 0.30-1 ii libdate-manip-perl 6.83-1 ii libdbd-mysql-perl4.050-3+b1 ii libio-socket-ssl-perl2.069-1 ii libipc-run-perl 20200505.0-1 ii liblocale-gettext-perl 1.07-4+b1 ii liblwp-useragent-determined-perl 1.07-1.1 ii libmail-imapclient-perl 3.42-1 ii libmemcached11 1.0.18-4.2 ii libmonitoring-plugin-perl0.40-1 ii libnet-cups-perl 0.64-1+b3 ii libnet-dns-perl 1.29-1 ii libnet-dns-sec-perl 1.18-1+b1 ii libnet-smtp-ssl-perl 1.04-1 ii libnet-smtp-tls-perl 0.12-3 ii libnet-smtpauth-perl 0.08-4.1 ii libnet-snmp-perl 6.0.1-6 ii libnet-ssleay-perl 1.88-3+b1 ii libreadonly-perl 2.050-3 ii libredis-perl2:1.9980-2 ii libtimedate-perl 2.3300-2 ii libwebinject-perl1.94-1 ii libxml-simple-perl 2.25-1 ii lz4 1.9.3-2 ii lzop 1.04-2 ii monitoring-plugins-basic [nagios-plugins-basic] 2.3.1-1 ii openssl 1.1.1n-0+deb11u3 ii perl 5.32.1-4+deb11u2 ii perl-base [libsocket-perl] 5.32.1-4+deb11u2 ii python3 3.9.2-3 ii python3-pymongo 3.11.0-1+b1 ii ruby 1:2.7+2 ii snmp 5.9+dfsg-4+deb11u1 ii whois5.5.10 Versions of packages monitoring-plugins-contrib suggests: pn backuppc ii bind9-dnsutils [dnsutils] 1:9.16.33-1~deb11u1 pn cciss-vol-status ii dnsutils 1:9.16.33-1~deb11u1 pn expect ii iproute2 5.10.0-4 pn libsys-virt-perl ii moreutils 0.65-1 pn mpt-status ii nagios-plugin-check-multi 0.26-4 pn percona-toolkit ii perl-doc 5.32.1-4+deb11u2 pn python3-boto pn smstools -- no debconf information
Bug#1024431: libgccjit0: missing Depends: libc6-dev
Hello gcc maintainers, I believe that you won't have seen any messages to this bug yet, if I recall correctly how reassignment works with the BTS. On Sat 19 Nov 2022 at 12:16PM +01, Andreas Beckmann wrote: > The Dependency chain is emacs-gtk -> libgccjit0 -> libgcc-12-dev > libgcc-12-dev has a Recommends: libc6-dev but that seems to be insufficient > for libgccjit0. > (one of the errors was 'libgccjit.so: error: error invoking gcc driver' so > that seems to be out of the realm of emacs. > > IMO, the real bug seems to be "libgccjit0: missing Depends: libc6-dev" > Cloning/reassigning/blocking accordingly. > > The only other user of libgccjit0 is python3-gccjit which may or may not have > the same problem. libgccjit0 already transitively recommends libc6-dev, and it looks like this needs to be upgraded to a hard dependency. This is the last remaining known RC bug before Emacs 28 can finally migrate. Could you make the change, please? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1010170: FTBFS: lisp/net/tramp-archive-tests.log contains unexpected results
Control: fixed 1010170 1:28.2+1-6 Control: fixed 1000744 1:28.2+1-6 emacs FTBFS bugs seem to be already fixed in sid. Thanks, -- Tatsuya Kinoshita pgpMbbPWB1kdL.pgp Description: PGP signature
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
I just want to add that there has been no improvement in the situation with 6.0.0-3 as well as 6.0.0-4. After a poweroff, I boot 5.18.0-3 (after I connect my PS2 keyboard via a USB dongle so I can navigate the GRUB menu) and then *reboot* to the latest kernel. This way, the firmware file is loaded by 5.18.0-3 and stays in the hardware's memory during the reboot so I get to use that latest kernel with my Bluetooth-only keyboard. Cumbersome, at best. Hope this helps, -- Olaf Meeuwissen
Bug#1024346: cdrom: debian-11.5.0-amd64-netinst.iso boots to Grub CLI on Dell Optiplex 5090
Thanks for the detailed message. I started everything over to try to reproduce the problem. I wiped out the NVMe drive again (wipefs -a and dd if=/dev/zero of=/dev/sdb bs=512 count=10), and re-installed Pop!OS 22.04 non-NVidia version, which was successful. The computer was operating normally and booting into Pop!OS, no problem. I then downloaded a new Debian 11.5.0 netinst ISO, checked the SHA512, wrote it to the USB drive with extra parameters mentioned earlier. I powered off the computer, inserted the USB 3.0 stick into a USB 3.0 port and powered on. I hit F12 to reach the Dell one-time boot menu and chose the USB stick to boot from. It immediately boots into the Grub CLI as I described before. So either the presence of the Pop!OS partition or the presence of the entry in the UEFI boot table seems to be confusing the Debian USB stick. --- Original Message --- On Saturday, November 19th, 2022 at 17:10, Steve McIntyre wrote: > > > Hi Rob, > > I see Andy has been helping you! > > On Sat, Nov 19, 2022 at 03:38:33PM +, r...@tekhax.io wrote: > > > Thanks, after messing with it for quite awhile, I finally got it to work > > with the standard ISO. > > > > I booted with the Arch live image and did: > > > > wipefs -a /dev/nvme0n1 > > dd if=/dev/zero of=/dev/nvme0n1 bs=512 count=10 > > > > then I used efibootmgr to delete all existing entries. > > > > Once I did that, the netinst booted into the installer > > immediately. Not sure if it was the actual existence of valid > > partitions on the drive, or just the existence of EFI entries in the > > table. > > > If your system has (had) existing EFI boot entries, then the firmware > would normally attempt to boot those. AIUI you selected the USB stick > and that failed to boot? > > The partitioning on Debian images is slightly complex, to make them > work as a so-called "isohybrid". (This means that you can use the same > image both when written to optical media and when written to a USB > stick.) But the partitions should still show up. For example, looking > at the netinst image file here: > > $ fdisk -l debian-11.5.0-amd64-netinst.iso > Disk debian-11.5.0-amd64-netinst.iso: 382 MiB, 400556032 bytes, 782336 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: dos > Disk identifier: 0x5004a58b > > Device Boot Start End Sectors Size Id Type > debian-11.5.0-amd64-netinst.iso1 * 0 782335 782336 382M 0 Empty > debian-11.5.0-amd64-netinst.iso2 4064 9247 5184 2.5M ef EFI (FAT-12/16/32) > > The first partition covers the whole of the image; the second one is > just the EFI boot setup that you've seen already. If you're only > seeing the second partition then it appears there is some other > problem here. > > Checking your original report here, you said you wrote to the USB > stick using dd if= of=/dev/sdb. Did you run "sync" or > > similar to make 100% sure that the image was all flushed to the USB > stick before removing it / booting it? Unless you tell it otherwise, > Linux will cache writes to USB drives and it can appear that writes > have completed well before the data is actually written to the > drive. This is a common cause of confusion for people in this > situation, I'm afraid. > > Andy already mentioned a different way to force writing data, using > the "oflag=sync" option to dd. Using that with "bs=4M" should also > give good performance when writing out an image to a USB stick. > > Could you possibly retry this and check if it works for you please? > > -- > Steve McIntyre, Cambridge, UK. st...@einval.com > < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Bug#1024053: Ordering
My guess is that you want a Wants= and After= in your sshd.service override. You might try that and see. - John
Bug#1024466: ITP: libpass-otp-perl -- Perl implementation of HOTP / TOTP algorithms
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libpass-otp-perl Version : 1.5 Upstream Author : Jan Baier * URL : https://metacpan.org/release/Pass-OTP * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl implementation of HOTP / TOTP algorithms The Pass::OTP module provides implementation of HOTP and TOTP algorithms according to the RFC 4226 and RFC 6238. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1020335:
See also the thread I started a few days ago on libc-alpha, "On time64 and Large File Support" [0]. [0] https://sourceware.org/pipermail/libc-alpha/2022-November/143386.html signature.asc Description: Message signed with OpenPGP
Bug#995148: closed by Debian FTP Masters (Bug#1000941: Removed package(s) from unstable)
reopen 995148 reassign 995148 clang-14 thanks On 19 nov. 2022 15:41, "Debian Bug Tracking System" wrote: > This is an automatic notification regarding your Bug report > which was filed against the clang-11 package: > > #995148: clang-11: fatal error: Cannot select: intrinsic %llvm.arm.hint under > armel This bug still exist in clang-14 Christian
Bug#1024396: brewtarget: reproducible builds: Embeds kernel version in /usr/bin/brewtarget
On 2022-11-19, Paul Wise wrote: > On Fri, 18 Nov 2022 10:44:29 -0800 Vagrant Cascadian wrote: > >> - "Built at" << BUILD_TIMESTAMP << "on" << CMAKE_HOST_SYSTEM << >> "for" << CMAKE_SYSTEM << "with" << >> + "Built at" << BUILD_TIMESTAMP << > > Wouldn't it be better to just remove this line entirely, since with > reproducible builds, the "build timestamp" will always be the same, > so isn't really a build timestamp but a source code change timestamp? That is a reasonable argument! There are no timestamps quite like no timestamps... definitely preferred for reproducible builds to remove the timestamps entirely if possible! For a debian package, the version of the installed package is usually known, so the packaging changelog, https://buildd.debian.org, .buildinfo file, etc. can be used to get various relevent timestamps. That said, I do not know exactly how this is used in the code, so making it empty or non-existent would require further verification, and at least it seems to respect SOURCE_DATE_EPOCH for the moment for a deterministic timestamp. live well, vagrant signature.asc Description: PGP signature
Bug#1019638: ruby-memory-profiler: diff for NMU version 0.9.14-4.1
Control: tags 1019638 + patch
Control: tags 1019638 + pending
Dear maintainer,
I've prepared an NMU for ruby-memory-profiler (versioned as 0.9.14-4.1)
and uploaded it to DELAYED/15. Please feel free to tell me if I should
cancel it.
cu
Adrian
diff -Nru ruby-memory-profiler-0.9.14/debian/changelog ruby-memory-profiler-0.9.14/debian/changelog
--- ruby-memory-profiler-0.9.14/debian/changelog 2021-11-08 01:42:01.0 +0200
+++ ruby-memory-profiler-0.9.14/debian/changelog 2022-11-20 02:14:54.0 +0200
@@ -1,3 +1,10 @@
+ruby-memory-profiler (0.9.14-4.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Add upstream fixes for Ruby 3.1. (Closes: #1019638)
+
+ -- Adrian Bunk Sun, 20 Nov 2022 02:14:54 +0200
+
ruby-memory-profiler (0.9.14-4) unstable; urgency=low
* Team upload.
diff -Nru ruby-memory-profiler-0.9.14/debian/patches/0001-Fix-normalize_path-and-guess_gem-to-support-Ruby-3.patch ruby-memory-profiler-0.9.14/debian/patches/0001-Fix-normalize_path-and-guess_gem-to-support-Ruby-3.patch
--- ruby-memory-profiler-0.9.14/debian/patches/0001-Fix-normalize_path-and-guess_gem-to-support-Ruby-3.patch 1970-01-01 02:00:00.0 +0200
+++ ruby-memory-profiler-0.9.14/debian/patches/0001-Fix-normalize_path-and-guess_gem-to-support-Ruby-3.patch 2022-11-20 02:14:02.0 +0200
@@ -0,0 +1,39 @@
+From dcc4464d1766046712a406b32651a00a64d7e592 Mon Sep 17 00:00:00 2001
+From: Benoit Daloze
+Date: Tue, 25 Oct 2022 15:06:10 +0200
+Subject: Fix normalize_path and guess_gem to support Ruby 3+
+
+---
+ lib/memory_profiler/helpers.rb | 2 +-
+ lib/memory_profiler/results.rb | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/memory_profiler/helpers.rb b/lib/memory_profiler/helpers.rb
+index d894ffa..c008cd1 100644
+--- a/lib/memory_profiler/helpers.rb
b/lib/memory_profiler/helpers.rb
+@@ -16,7 +16,7 @@ module MemoryProfiler
+ gemname
+ elsif /\/rubygems[\.\/]/ =~ path
+ "rubygems"
+-elsif /ruby\/2\.[^\/]+\/(?[^\/\.]+)/ =~ path
++elsif /ruby\/\d\.[^\/]+\/(?[^\/\.]+)/ =~ path
+ stdlib
+ elsif /(?[^\/]+\/(bin|app|lib))/ =~ path
+ app
+diff --git a/lib/memory_profiler/results.rb b/lib/memory_profiler/results.rb
+index 5630977..d6fad8d 100644
+--- a/lib/memory_profiler/results.rb
b/lib/memory_profiler/results.rb
+@@ -172,7 +172,7 @@ module MemoryProfiler
+ @normalize_path[path] ||= begin
+ if %r!(/gems/.*)*/gems/(?[^/]+)(?.*)! =~ path
+ "#{gemname}#{rest}"
+-elsif %r!ruby/2\.[^/]+/(?[^/.]+)(?.*)! =~ path
++elsif %r!ruby/\d\.[^/]+/(?[^/.]+)(?.*)! =~ path
+ "ruby/lib/#{stdlib}#{rest}"
+ elsif %r!(?[^/]+/(bin|app|lib))(?.*)! =~ path
+ "#{app}#{rest}"
+--
+2.30.2
+
diff -Nru ruby-memory-profiler-0.9.14/debian/patches/0002-Adapt-tests-for-Ruby-3.0.patch ruby-memory-profiler-0.9.14/debian/patches/0002-Adapt-tests-for-Ruby-3.0.patch
--- ruby-memory-profiler-0.9.14/debian/patches/0002-Adapt-tests-for-Ruby-3.0.patch 1970-01-01 02:00:00.0 +0200
+++ ruby-memory-profiler-0.9.14/debian/patches/0002-Adapt-tests-for-Ruby-3.0.patch 2022-11-20 02:14:02.0 +0200
@@ -0,0 +1,51 @@
+From 499480ce9820f7df21a4e7ca30c1bbd78564be2e Mon Sep 17 00:00:00 2001
+From: Benoit Daloze
+Date: Tue, 25 Oct 2022 15:18:49 +0200
+Subject: Adapt tests for Ruby 3.0
+
+---
+ test/test_reporter.rb | 19 +++
+ 1 file changed, 15 insertions(+), 4 deletions(-)
+
+diff --git a/test/test_reporter.rb b/test/test_reporter.rb
+index 55c440f..c10efd6 100644
+--- a/test/test_reporter.rb
b/test/test_reporter.rb
+@@ -232,7 +232,15 @@ class TestReporter < Minitest::Test
+ end
+ end
+
+-assert_equal(45, results.total_allocated, "45 strings should be allocated")
++if RUBY_VERSION < '3'
++ # 3 times "0", 2 times for interpolated strings
++ total_allocated = 5 * (3 + 2 + 2 + 2)
++else
++ # 3 times "0", 2 times for short interpolated strings, 3 times for long interpolated strings
++ total_allocated = 5 * (3 + 2 + 3 + 3)
++end
++
++assert_equal(total_allocated, results.total_allocated, "#{total_allocated} strings should be allocated")
+ assert_equal(20, results.strings_allocated.size, "20 unique strings should be observed")
+ assert_equal(0, results.strings_retained.size, "0 unique strings should be retained")
+ end
+@@ -244,11 +252,14 @@ class TestReporter < Minitest::Test
+ string.to_sym
+ end
+
+-assert_equal(3, results.total_allocated)
+-assert_equal(0, results.total_retained)
++strings_allocated = RUBY_VERSION < '3' ? 2 : 1
++assert_equal(strings_allocated + 1, results.total_allocated)
++assert_includes(0..1, results.total_retained)
+ assert_equal(1, results.strings_allocated.size)
++
+ assert_equal('String', results.allocated_objects_by_class[0][:data])
+-assert_equal(2, results.allocated_objects_by_class[0][:count])
++
Bug#923014: Add systemd unit - allow usage without cron installed
On Fri, 2022-11-18 at 16:06 +0100, Bill Allombert wrote: > But then the user would not be able to configure it anymore, > so I do not see the upside. I just discovered an alternative that preserves the current location and the conffile status of the cron.daily script. The script stays the same, except it exits under systemd when the first argument isn't a option indicating that the script should continue under systemd. The systemd service then passes that option as the only parameter. An example from the exim4-base package: $ head -n8 /etc/cron.daily/exim4-base #!/bin/sh EX4SYSTEMDTIMER=$1 # skip in favour of systemd timer if called from cron.daily if [ -d /run/systemd/system ] && [ "$EX4SYSTEMDTIMER" != "systemd-timer" ]; then exit 0 fi $ systemctl cat exim4-base.service exim4-base.timer # /lib/systemd/system/exim4-base.service [Unit] Description=exim4-base housekeeping Documentation=man:exim4(8) ConditionACPower=true Before=logrotate.service [Service] Type=oneshot ExecStart=/etc/cron.daily/exim4-base systemd-timer # performance options Nice=19 IOSchedulingClass=best-effort IOSchedulingPriority=7 # /lib/systemd/system/exim4-base.timer [Unit] Description=Daily exim4-base housekeeping Documentation=man:exim4(8) Before=logrotate.timer [Timer] OnCalendar=daily AccuracySec=12h Persistent=true [Install] WantedBy=timers.target -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1022181: pygccjit: diff for NMU version 0.4-12.1
Control: tags 1022181 + patch Control: tags 1022181 + pending Dear maintainer, I've prepared an NMU for pygccjit (versioned as 0.4-12.1) and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru pygccjit-0.4/debian/changelog pygccjit-0.4/debian/changelog --- pygccjit-0.4/debian/changelog 2021-09-15 14:23:21.0 +0300 +++ pygccjit-0.4/debian/changelog 2022-11-20 01:51:51.0 +0200 @@ -1,3 +1,10 @@ +pygccjit (0.4-12.1) unstable; urgency=low + + * Non-maintainer upload. + * Build using gcc 12. (Closes: #1022181) + + -- Adrian Bunk Sun, 20 Nov 2022 01:51:51 +0200 + pygccjit (0.4-12) unstable; urgency=medium * Stop building the python3-pygccjit-dbg package. Closes: #994329. diff -Nru pygccjit-0.4/debian/control pygccjit-0.4/debian/control --- pygccjit-0.4/debian/control 2021-09-15 14:22:28.0 +0300 +++ pygccjit-0.4/debian/control 2022-11-20 01:51:35.0 +0200 @@ -5,7 +5,7 @@ Build-Depends: debhelper (>= 13), dh-python, python3-all-dev, cython3, python3-setuptools, - libgccjit-10-dev, gcc-10, + libgccjit-12-dev, gcc-12, python3-sphinx Standards-Version: 4.6.0 Homepage: https://github.com/davidmalcolm/pygccjit diff -Nru pygccjit-0.4/debian/rules pygccjit-0.4/debian/rules --- pygccjit-0.4/debian/rules 2021-09-15 14:23:18.0 +0300 +++ pygccjit-0.4/debian/rules 2022-11-20 01:51:46.0 +0200 @@ -1,7 +1,7 @@ #!/usr/bin/make -f -export CC = gcc-10 -export LDSHARED = gcc-10 -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro +export CC = gcc-12 +export LDSHARED = gcc-12 -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro export PYBUILD_DESTDIR_python3=debian/python3-gccjit/
Bug#1022681: haskell-clientsession build depends on haskell-cipher-aes and haskell-cprng-aes
On Mon, Oct 24, 2022 at 01:36:11PM +0300, Adrian Bunk wrote:
> Source: haskell-clientsession
> Version: 0.9.1.2-7
> Severity: serious
> Control: affects -1 src:haskell-cipher-aes src:haskell-cprng-aes
>
> haskell-clientsession build depends on haskell-cipher-aes
> and haskell-cprng-aes that have "intend to remove" bugs.
Ilias, this bug is the reason why your removal notices for
haskell-{cipher,cprng}-aes are about to kick git-annex out
of bookworm.
To keep git-annex in bookworm, it's either applying one of the two
upstream MRs for haskell-clientsessionor postponing the removal notices
for haskell-{cipher,cprng}-aes.
cu
Adrian
Bug#1024465: ITP: pyfastx -- fast random access to sequences from FASTA/Q file
Package: wnpp Severity: wishlist Owner: Étienne Mollier X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-...@lists.debian.org * Package name: pyfastx Version : 0.8.4 Upstream Author : Lianming Du * URL : https://github.com/lmdu/pyfastx/ * License : Expat Programming Lang: C, Python3 Description : fast random access to sequences from FASTA/Q file The pyfastx is a lightweight Python C extension that enables users to randomly access to sequences from plain and gzipped FASTA/Q files. This module aims to provide simple APIs for users to extract sequence from FASTA and reads from FASTQ by identifier and index number. The pyfastx will build indexes stored in a sqlite3 database file for random access to avoid consuming excessive amount of memory. In addition, the pyfastx can parse standard (sequence is spread into multiple lines with same length) and nonstandard (sequence is spread into one or more lines with different length) FASTA format. . It features: . * a single file for the Python extension; * lightweight, memory efficient FASTA/Q file parsing; * fast random access to sequences from gzipped FASTA/Q file; * sequences reading from FASTA file line by line; * N50 and L50 calculation of sequences in FASTA file; * GC content and nucleotides composition calculation; * reverse, complement and antisense sequences extraction; * excellent compatibility: support for parsing nonstandard FASTA file; * support for FASTQ quality score conversion; * a command line interface for splitting FASTA/Q file. This package is required for upgrading to augur 18.2.0. It will be maintained in the Debian Med team. The packaging occurs in the Debian Med group on Salsa[1]. [1]: https://salsa.debian.org/med-team/pyfastx Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/4, please excuse my verbosity. signature.asc Description: PGP signature
Bug#1022551: llvm-15's cmake now requires clang-tools-15, clang-tidy-15, clangd-15, even if unused
control: fixed -1 1:15.0.5-1 control: close -1 On Mon, 24 Oct 2022 10:13:01 +0200 Matthias Klose wrote: Control: reopen -1 Control: found -1 15.0.3-1 > it is fixed in experimental no, it is not. As said on IRC, there's a reproducer to build cvise 2.6.0-1 without the extra dependencies clang-tools-15, clang-tidy-15, clangd-15 and the build fails. I downloaded cvise, installed build-deps in a sid chroot apt remove clang-tools-15 clang-tidy-15 clangd-15 dpkg-buildpackage -d dh_auto_configure -- \ -DCMAKE_PREFIX_PATH=/usr/lib/llvm-15 \ -DCLANG_FORMAT=clang-format-15 \ -DCMAKE_INSTALL_LIBEXECDIR=lib cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCMAKE_PREFIX_PATH=/usr/lib/llvm-15 -DCLANG_FORMAT=clang-format-15 -DCMAKE_INSTALL_LIBEXECDIR=lib .. -- The C compiler identification is GNU 12.2.0 -- The CXX compiler identification is GNU 12.2.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Performing Test HAVE_FFI_CALL -- Performing Test HAVE_FFI_CALL - Success -- Found FFI: /usr/lib/x86_64-linux-gnu/libffi.so -- Performing Test Terminfo_LINKABLE -- Performing Test Terminfo_LINKABLE - Success -- Found Terminfo: /usr/lib/x86_64-linux-gnu/libtinfo.so -- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) -- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.9.14") -- Found LLVM 15.0.5 -- Using LLVMConfig.cmake in /usr/lib/llvm-15/cmake -- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) -- Using ClangConfig.cmake in /usr/lib/llvm-15/lib/cmake/clang -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.10.8", minimum required is "3.6") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- Looking for dlfcn.h -- Looking for dlfcn.h - found -- Looking for inttypes.h -- Looking for inttypes.h - found -- Looking for memory.h -- Looking for memory.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stdlib.h -- Looking for stdlib.h - found -- Looking for strings.h -- Looking for strings.h - found -- Looking for string.h -- Looking for string.h - found -- Looking for sys/stat.h -- Looking for sys/stat.h - found -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for unistd.h -- Looking for unistd.h - found -- Performing Test SUPPORTS_FVISIBILITY_INLINES_HIDDEN_FLAG -- Performing Test SUPPORTS_FVISIBILITY_INLINES_HIDDEN_FLAG - Success -- Using clang-format in /usr/bin/clang-format-15 -- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project: CMAKE_EXPORT_NO_PACKAGE_REGISTRY CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY FETCHCONTENT_FULLY_DISCONNECTED [...] cd /cvise-2.6.0/obj-x86_64-linux-gnu/clang_delta && /usr/bin/c++ -DHAVE_CONFIG_H -I/cvise-2.6.0/obj-x86_64-linux-gnu -I/cvise-2.6.0/clang_delta -I/usr/lib/llvm-15/include -g -O2 -ffile-prefix-map=/cvise-2.6.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -fno-rtti -fno-strict-aliasing -Wall -Wextra -Wno-unused-parameter -Werror -Wno-error=maybe-uninitialized -fvisibility-inlines-hidden -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -MD -MT clang_delta/CMakeFiles/clang_delta.dir/ExpressionDetector.cpp.o -MF CMakeFiles/clang_delta.dir/ExpressionDetector.cpp.o.d -o CMakeFiles/clang_delta.dir/ExpressionDetector.cpp.o -c /cvise-2.6.0/clang_delta/ExpressionDetector.cpp [ 13%] Building CXX object clang_delta/CMakeFiles/clang_delta.dir/InstantiateTemplateParam.cpp.o cd /cvise-2.6.0/obj-x86_64-linux-gnu/clang_delta && /usr/bin/c++ -DHAVE_CONFIG_H -I/cvise-2.6.0/obj-x86_64-linux-gnu -I/cvise-2.6.0/clang_delta -I/usr/lib/llvm-15/include -g -O2 -ffile-prefix-map=/cvise-2.6.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -fno-rtti -fno-strict-aliasing -Wall -Wextra -Wno-unused-parameter -Werror -Wno-error=maybe-uninitialized -fvisibility-inlines-hidden -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -MD -MT clang_delta/CMakeFiles/clang_delta.dir/InstantiateTemplateParam.cpp.o -MF
Bug#944028: ITP: git-delta -- A syntax-highlighting pager for git
Hey Jonas :-) On Thu, 2022-11-17 at 18:45 +0100, Jonas Smedegaard wrote: > sorry if I was too terse previously No worries... all is fine :-) > but I disagree that introducing another prefix/suffix helps > much. I guess you're right... > What helps the most, and also seems possibly, is to name it > "delta" - just not right now - and with that long-term plan I think > it > is double confusing to introduce a _third_ name (since the name > "git-delta" has already been introduced by some downstreams). Well the best would be if upstream could give another name, but if that's unlikely... this might be the best option. > Oke way you can help is to initiate the process of (attempting to) > kick > out (or alternatively rename) current package "delta" from Debian. I'm not really sure whether I like this either. ;-) I had a small look at the current "delta" package, and while the package is maintained by the QA group and the upstream website (http://delta.tigris.org/) named in the copyright file seems dead... the program might be still useful to some people... and it had the name first. Asking them now to rename,... well even if done politely, they may feel somehow obligated to do... or even drop the package at all, which I think would be bad. Thanks, Chris.
Bug#1023386: Ready for upload
Control: notforwarded -1 Control: tags -1 +pending +bullseye Hello, All required changes for the backport of this package are completed and all that's needed is an upload to bullseye-backports. The package is still available at previously mentioned places (Mentors and Salsa branch debian/bullseye). Thanks, -- Ben Westover OpenPGP_signature Description: PGP signature
Bug#1002964: netpanzer: diff for NMU version 0.8.7+ds-4.1
Control: tags 1002964 + pending
Dear maintainer,
I've prepared an NMU for netpanzer (versioned as 0.8.7+ds-4.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I should
cancel it.
cu
Adrian
diff -Nru netpanzer-0.8.7+ds/debian/changelog netpanzer-0.8.7+ds/debian/changelog
--- netpanzer-0.8.7+ds/debian/changelog 2021-10-22 00:16:42.0 +0300
+++ netpanzer-0.8.7+ds/debian/changelog 2022-11-20 00:32:24.0 +0200
@@ -1,3 +1,11 @@
+netpanzer (0.8.7+ds-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patch from László Böszörményi to fix FTBFS with SCons >= 4.2.0.
+(Closes: #1002964)
+
+ -- Adrian Bunk Sun, 20 Nov 2022 00:32:24 +0200
+
netpanzer (0.8.7+ds-4) unstable; urgency=medium
* Team upload.
diff -Nru netpanzer-0.8.7+ds/debian/patches/netpanzer_SCons_fix.patch netpanzer-0.8.7+ds/debian/patches/netpanzer_SCons_fix.patch
--- netpanzer-0.8.7+ds/debian/patches/netpanzer_SCons_fix.patch 1970-01-01 02:00:00.0 +0200
+++ netpanzer-0.8.7+ds/debian/patches/netpanzer_SCons_fix.patch 2022-11-20 00:31:50.0 +0200
@@ -0,0 +1,19 @@
+Description: SCons 4.2.0 no longer has env.has_key()
+ Check env as an array.
+Author: Laszlo Boszormenyi (GCS)
+Forwarded: no
+Last-Update: 2022-01-01
+
+---
+
+--- netpanzer-0.8.7+ds.orig/SConstruct
netpanzer-0.8.7+ds/SConstruct
+@@ -237,7 +237,7 @@ npdirs = """
+ """
+
+ env.Append( NPSOURCES = globSources(env, 'src/NetPanzer', npdirs, "*.cpp") )
+-if env.has_key('WINICON'):
++if 'WINICON' in env:
+ env.Append( NPSOURCES = env['WINICON'] )
+
+ env.Prepend( LIBS = ['np2d','lua5.1','npnetwork','nplibs','physfs'] )
diff -Nru netpanzer-0.8.7+ds/debian/patches/series netpanzer-0.8.7+ds/debian/patches/series
--- netpanzer-0.8.7+ds/debian/patches/series 2021-10-22 00:16:42.0 +0300
+++ netpanzer-0.8.7+ds/debian/patches/series 2022-11-20 00:32:20.0 +0200
@@ -6,3 +6,4 @@
reproducible-build.patch
scons.patch
gcc11.patch
+netpanzer_SCons_fix.patch
Bug#1024464: ITP: golang-github-muesli-combinator -- slice generator for all possible combinations of values
Package: wnpp Severity: wishlist Owner: Ryan Kavanagh Control: blocks -1 1012721 * Package name: golang-github-muesli-combinator Version : 0.3.0-1 Upstream Author : Christian Muehlhaeuser * URL : https://github.com/muesli/combinator * License : Expat Programming Lang: Go Description : slice generator for all possible combinations of values Generates a slice of all possible value combinations for any given struct and a set of its potential member values. This can be used to generate extensive test matrixes among other things. -- |)|/ Ryan Kavanagh | 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Bug#1024463: ITP: golang-github-twpayne-go-shell -- platform-independent library for determining a user's shell
Package: wnpp Severity: wishlist Owner: Ryan Kavanagh Control: block 1012721 by -1 * Package name: golang-github-twpayne-go-shell Version : 0.3.1-1 Upstream Author : Tom Payne * URL : https://github.com/twpayne/go-shell * License : Expat Programming Lang: Go Description : platform-independent library for determining a user's shell A go library that returns a user's shell on Darwin, Plan9, POSIX, and Windows systems. -- |)|/ Ryan Kavanagh | 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Bug#1024447: grub-efi-amd64: No box border characters in boot menu
Hi Chris, On Sat, Nov 19, 2022 at 05:28:27PM +0100, Chris Nospam wrote: >Package: grub-efi-amd64 >Version: 2.06-5 >Severity: normal >X-Debbugs-Cc: chris...@gmx.de > >Dear Maintainer, > >I am running debian testing/bookworm. After the updates from grub 2.06-4 to >grub 2.06-5 (about November 18th) in the grub boot menu the box border >characters are not shown as they should. Insteadn one sees only a boxed >question mark for each character. Further, an error message is shown as text >for a fraction of a second directly before the boot menu arsises: >"error: prohibited by secure boot policy." >I believe this is new in 2.06-5. >When I disable secure boot with the mainboard firmware, the characters/boot >menu shows >up correctly. > >I can trigger this in my kvm virtualized installtion and on my bare metal >machine with an ASUS H170 Gaming main board (and latest firmware). ACK. Thanks for your bug report! This is due to a change in Secure Boot setup that came with the latest GRUB security fixes, to reduce the possibility of security issues in font handling. With SB enabled, GRUB will now only allow the use of fonts directly embedded within the signed image. We didn't have the time to fully convert Debian's GRUB configuration to match this new world before publishing these security fixes, hence you're seeing these issues. Sorry. :-( I'm working to get this fixed up, but it's taking a little longer than I hoped. -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Bug#1024435: dracut-core: missing Breaks+Replaces: dracut-network (<< 057+157-2)
On 19/11/2022 21.58, Thomas Lange wrote: On Sat, 19 Nov 2022 13:29:52 +0100, Andreas Beckmann said: >> From the attached log (scroll to the bottom...): > Preparing to unpack .../dracut-core_057+157-2_amd64.deb ... > Unpacking dracut-core (057+157-2) over (056-3) ... > dpkg: error processing archive /var/cache/apt/archives/dracut-core_057+157-2_amd64.deb (--unpack): >trying to overwrite '/usr/lib/dracut/modules.d/95virtfs/module-setup.sh', which is also in package dracut-network 056-3 > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > Errors were encountered while processing: >/var/cache/apt/archives/dracut-core_057+157-2_amd64.deb I can understand the problem (and the fix to add the breaks relation), but I wonder why I should define a replaces to dracut-network? dracut-core does not replace dracut-network. It only breaks dracut-network (<< 057+157-2). Can you please tell me what correct way is to fix it. Some files moved from -network to -core (the files that were in both packages in yesterdays bug). In order to properly handle that on upgrades, you need both versioned Breaks and Replaces. The Replaces s.t. dpkg will move file ownership if -core gets unpacked first, the Breaks to prevent partial upgrades (and subsequent partial removals or downgrades, that's where the fun usually starts) of the packages involved in the file move. Andreas
Bug#1019610: ruby-ahoy-email: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: cannot load such file -- net/smtp (LoadError)
Control: reassign -1 ruby-actionmailer 2:6.1.7+dfsg-2 Control: affects -1 src:ruby-ahoy-email On Sun, Nov 06, 2022 at 08:31:39PM +0200, Adrian Bunk wrote: > On Fri, Oct 07, 2022 at 02:16:35PM -0300, Antonio Terceiro wrote: > >... > > But nothing in ruby-ahoy-email codebase uses net/smtp explicitly, so > > this is a bit weird. > >... > > $ cat > /usr/share/rubygems-integration/all/gems/actionmailer-6.1.7/lib/action_mailer/mail_with_error_handling.rb > # frozen_string_literal: true > > begin > require "mail" > rescue LoadError => error > if error.message.match?(/net\/smtp/) > $stderr.puts "You don't have net-smtp installed in your application. > Please add it to your Gemfile and run bundle install" > raise > end > end > $ > > > There is also something that might be related in > https://sources.debian.org/src/rails/2%3A6.1.7%2Bdfsg-2/Gemfile/#L140 > > Is there a bug in rails? >... I am reassigning this to rails since it is likely that the problem is there. cu Adrian
Bug#1024346: cdrom: debian-11.5.0-amd64-netinst.iso boots to Grub CLI on Dell Optiplex 5090
Hi Rob, I see Andy has been helping you! On Sat, Nov 19, 2022 at 03:38:33PM +, r...@tekhax.io wrote: >Thanks, after messing with it for quite awhile, I finally got it to work with >the standard ISO. > >I booted with the Arch live image and did: > >wipefs -a /dev/nvme0n1 >dd if=/dev/zero of=/dev/nvme0n1 bs=512 count=10 > >then I used efibootmgr to delete all existing entries. > >Once I did that, the netinst booted into the installer >immediately. Not sure if it was the actual existence of valid >partitions on the drive, or just the existence of EFI entries in the >table. If your system has (had) existing EFI boot entries, then the firmware would normally attempt to boot those. AIUI you selected the USB stick and that failed to boot? The partitioning on Debian images is slightly complex, to make them work as a so-called "isohybrid". (This means that you can use the same image both when written to optical media and when written to a USB stick.) But the partitions should still show up. For example, looking at the netinst image file here: $ fdisk -l debian-11.5.0-amd64-netinst.iso Disk debian-11.5.0-amd64-netinst.iso: 382 MiB, 400556032 bytes, 782336 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x5004a58b Device Boot StartEnd Sectors Size Id Type debian-11.5.0-amd64-netinst.iso1 *0 782335 782336 382M 0 Empty debian-11.5.0-amd64-netinst.iso2 4064 92475184 2.5M ef EFI (FAT-12/16/32) The first partition covers the whole of the image; the second one is *just* the EFI boot setup that you've seen already. If you're only seeing the second partition then it appears there is some other problem here. Checking your original report here, you said you wrote to the USB stick using dd if= of=/dev/sdb. Did you run "sync" or similar to make 100% sure that the image was all flushed to the USB stick before removing it / booting it? Unless you tell it otherwise, Linux will cache writes to USB drives and it can appear that writes have completed well before the data is actually written to the drive. This is a common cause of confusion for people in this situation, I'm afraid. Andy already mentioned a different way to force writing data, using the "oflag=sync" option to dd. Using that with "bs=4M" should also give good performance when writing out an image to a USB stick. Could you possibly retry this and check if it works for you please? -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Bug#1022287: poldi: diff for NMU version 0.4.2+git20161115.553060d-1.1
Control: tags 1022287 + patch Control: tags 1022287 + pending Dear maintainer, I've prepared an NMU for poldi (versioned as 0.4.2+git20161115.553060d-1.1) and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru poldi-0.4.2+git20161115.553060d/debian/changelog poldi-0.4.2+git20161115.553060d/debian/changelog --- poldi-0.4.2+git20161115.553060d/debian/changelog 2016-11-11 09:07:45.0 +0200 +++ poldi-0.4.2+git20161115.553060d/debian/changelog 2022-11-19 23:57:43.0 +0200 @@ -1,3 +1,11 @@ +poldi (0.4.2+git20161115.553060d-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Delete m4/gpg-error.m4 to get the latest version from +libgpg-error-dev instead. (Closes: #1022287) + + -- Adrian Bunk Sat, 19 Nov 2022 23:57:43 +0200 + poldi (0.4.2+git20161115.553060d-1) unstable; urgency=medium * New upstream. diff -Nru poldi-0.4.2+git20161115.553060d/debian/clean poldi-0.4.2+git20161115.553060d/debian/clean --- poldi-0.4.2+git20161115.553060d/debian/clean 1970-01-01 02:00:00.0 +0200 +++ poldi-0.4.2+git20161115.553060d/debian/clean 2022-11-19 23:57:36.0 +0200 @@ -0,0 +1 @@ +m4/gpg-error.m4
Bug#982145: RFS: fuzzel/1.5.1-1 [ITP] -- Application launcher for wlroots based Wayland compositors
Control: tag -1 +pending That all looks good to me, i'll upload shortly. -- To be naive and easily deceived is impermissible, today more than ever, when the prevailing untruths may lead to a catastrophe because they blind people to real dangers and real possibilities. - Erich Fromm
Bug#988384: smartd-runner bug causes loss of email recipients
forcemerge 661485 988384 stop These two bugs are really identical, and as the reporter of the 2nd already indicated in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988384#10 they should be made duplicates.
Bug#661485: smartd-runner bug causes loss of email recipients
Control: tags -1 + patch Hey. I've made a number of PRs in salsa, which fixes this issue: https://salsa.debian.org/debian/smartmontools/-/merge_requests/5 and do some more improvements: https://salsa.debian.org/debian/smartmontools/-/merge_requests/6 The latter would need to be coordinated with smart-notifier: https://salsa.debian.org/debian/smart-notifier/-/merge_requests/2 Cheers, Chris. PS: Sorry if there is some duplicate mail,.. not sure if the first one went out
Bug#988384: smartd-runner bug causes loss of email recipients
Control: tags -1 + patch Hey. I've made a number of PRs in salsa, which fixes this issue: https://salsa.debian.org/debian/smartmontools/-/merge_requests/5 and do some more improvements: https://salsa.debian.org/debian/smartmontools/-/merge_requests/6 The latter would need to be coordinated with smart-notifier: https://salsa.debian.org/debian/smart-notifier/-/merge_requests/2 Cheers, Chris.
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
On Sat, Nov 19, 2022 at 06:43:01PM +0100, Niels Thykier wrote: > Jelmer Vernooij: > > Package: wnpp > > Severity: wishlist > > Owner: Jelmer Vernooij > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: setuptools-gettext > >Version : 0.0.1 > >Upstream Author : Breezy Team > > * URL : https://github.com/jelmer/setuptools-gettext > > * License : GPL > >Programming Lang: Python > >Description : Compile .po files into .mo files > > > > This extension for setuptools compiles gettext .po files > > found in the source directory into .mo files and installs them. > > > > FYI: The upstream URL is a 404. Maybe there is a typo or the repo is still > private? Ah, thanks. It's actually https://github.com/breezy-team/setuptools-gettext
Bug#1024457: "apt changelog" fails to display the complete changelog
Control: severity -1 important On Sat, Nov 19, 2022 at 10:42:01PM +0200, Adrian Bunk wrote: > Severity: serious Well, no. You haven't provided a reason and I fail to find an obvious one as apt's key functionality is hardly effected by a not (by default) working changelog sub-command… could Debian release with this "bug" unfixed? Certainly, given that it might/likely fails for other reasons like the online repository not actually providing changelogs. That said, severity hardly makes a difference for us anyhow as somehow assigning severity doesn't magically assign free time as well (at "best" higher values have a negative effect), so grave or wishlist doesn't really matter, but I suppose important is closer to your hope of getting that fixed before the release some way. > debhelper recently started removing older changelog entries from > binary packages, but the way to get them with apt does not work: https://salsa.debian.org/apt-team/apt/-/merge_requests/261 Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1024462: pki-base-java depends on openjdk-11-jre-headless that will not be in bookworm
Package: pki-base-java Version: 11.0.3-4 Severity: serious Please update the dependency to default-jre-headless.
Bug#1024461: i2p-router: Please change the dependency to default-jre-headless | java11-runtime-headless
Package: i2p-router Version: 0.9.48-1.1 Severity: important The first option of dependencies should be available, but it is not. Changing the dependency to default-jre-headless | java11-runtime-headless will default to installing the default JRE (Java 17 in bookworm) while allowing users to use other JREs instead.
Bug#1024460: arduino: Please change the Java dependency back to default-jre | java6-runtime
Package: arduino Version: 2:1.8.13+dfsg1-1~exp1 Severity: normal X-Debbugs-Cc: Carsten Schoenert arduino (2:1.8.13+dfsg1-1~exp1) experimental; urgency=medium ... Replacing java6-runtime by openjdk-11-jre, the former package isn't available any more. ... -- Carsten Schoenert Fri, 08 Jan 2021 12:42:57 +0100 java6-runtime was never a package, it is a Provides that is provided by all JREs >= Java 6 (e.g. openjdk-11-jre).
Bug#982145: RFS: fuzzel/1.5.1-1 [ITP] -- Application launcher for wlroots based Wayland compositors
On Fri, Nov 18, 2022 at 01:18:05PM -0500, Antoine Beaupré wrote: > It looks like it ships a third-party library, nanosvg. I don't know if > that's already packaged in Debian, but it might make the FTP-masters > unhappy, especially since it's not mentioned in debian/copyright. So the > latter should be fixed, at the very least, and we might consider > packaging that library separately... > > ... that said, it looks like many other packages do ship a copy of that > library, maybe it's the way it's designed to be shipped? > > https://codesearch.debian.net/search?q=nanosvg=1 > > wxwidgets just vendors it, but does mention it in the debian/copyright, > however: > > https://sources.debian.org/src/wxwidgets3.2/3.2.1%2Bdfsg-1/debian/copyright/#L28 > > So there's that: at least add that to the debian/copyright. Thanks for your patch! I posted a note regarding nanosvg: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982140#12 > Also, I've had trouble reproducing the upstream tarball. I tried to > build the package with git-buildpackage: > > gbp buildpackage --git-debian-branch=main --git-upstream-tag=1.8.2 > > ... but that gives me a different tarball than > upstream. git-buildpackage generates a tarball with foot-1.8.2/ as a > top directory, while upstream has foot/. I'm not sure how to resolve > this, but you should at least provide the upstream tarball ... somewhere > so that it can be uploaded safely. > > You might want to configure git-buildpackage or some other git-building > tool in the package as well, since it seems that (git) is what you rely > on to build this. I checked UPSTREAM TARBALL CREATION OPTIONS in gbp-buildpackage(1) for an option to set the prefix that could be used in gbp.conf, but could not find anything. The default might have been chosen to match GitHub. I use debuild with lintian in buildah to build Debian packages: https://www.debian.org/doc/manuals/maint-guide/build.en.html#debuild https://tauware.blogspot.com/2020/04/building-packages-with-buildah-in-debian.html > I can probably just live with the upstream tarball for now, but that > might be something you want to consider documenting in > debian/README.source or something. I have documented to obtain the tarball with origtargz: https://salsa.debian.org/swaywm-team/fuzzel/-/commit/777f02bbb38f229016bb41fc90ebfc923da46e98 # sha256sum ../fuzzel_1.8.2.orig.tar.gz 2e7debba9d56a989921e0ce518a026152d9fbea33abafe384a4aad074db89de8 ../fuzzel_1.8.2.orig.tar.gz > Otherwise this is almost ready to go, as far as I'm concerned, and I'll > be happy to sponsor this once it has a proper debian/copyright. Try > running decopy on the source to see what comes up... Thanks for your review! This is latest commit of the package: https://salsa.debian.org/swaywm-team/fuzzel/-/commit/ccc1a63f6289c33560f0ff85a5143e0e47daa529 Regards, Peter
Bug#1024435: dracut-core: missing Breaks+Replaces: dracut-network (<< 057+157-2)
> On Sat, 19 Nov 2022 13:29:52 +0100, Andreas Beckmann > said: >> From the attached log (scroll to the bottom...): > Preparing to unpack .../dracut-core_057+157-2_amd64.deb ... > Unpacking dracut-core (057+157-2) over (056-3) ... > dpkg: error processing archive /var/cache/apt/archives/dracut-core_057+157-2_amd64.deb (--unpack): >trying to overwrite '/usr/lib/dracut/modules.d/95virtfs/module-setup.sh', which is also in package dracut-network 056-3 > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > Errors were encountered while processing: >/var/cache/apt/archives/dracut-core_057+157-2_amd64.deb I can understand the problem (and the fix to add the breaks relation), but I wonder why I should define a replaces to dracut-network? dracut-core does not replace dracut-network. It only breaks dracut-network (<< 057+157-2). Can you please tell me what correct way is to fix it. -- regards Thomas
Bug#1020242: wireplumber: volume on default sink is too high after waking from suspend
Control: fixed -1 0.4.12-1 Hi, Le ven. 18 nov. 2022 à 17:30, Eric Cooper a écrit : > > It doesn't seem to have happened again. > Thanks. I am marking it as fixed since 0.4.12-1, but will keep this bug report open for a while just in case. Best, Dylan
Bug#1024459: uwsgi: Build and runtime dependencies on openjdk-11 that will not be in bookworm
Source: uwsgi Version: 2.0.20-4 Severity: serious openjdk-11 (and therefore uwsgi) is already on the autoremoval list and will not be in bookworm (only openjdk-17 will be in bookworm). The uwsgi-plugin-*-openjdk-11 packages need removing to uwsgi-plugin-*-openjdk-17 (or removal). I also wonder whether uwsgi-plugin-*-openjdk might be an option, with a build dependency on default-jdk and a runtime dependency that is generated at build time (see the jcc package for an example). Something similar is already done for the uwsgi-plugin*-python3 packages that do not have version specific names, and the same would also make sense for uwsgi-plugin-rack-ruby3.0.
Bug#1024400: net-luminis-build-plugin: broken maintainer field
Hi Adam! On Fri, Nov 18, 2022 at 07:49:20PM +, Adam D. Barratt wrote: [...] > > I'm assuming the second line is a failed attempt at removing the > Uploaders field, as mentioned in the changelog, which originally read: > > Uploaders: Mathieu Malaterre > > Amongst other things, this breaks the scripts in the BTS which generate > lists of RC bugs in unstable and testing for britney, meaning that > those lists have not been updated since Monday morning. > First, I apologize for what happened. I was working on changing the Maintainer field of orphaned packages to QA Group. I started the work by looking at page [1] to get the list of packages. I did the change for ~166 packages. In this list, on 27 packages, I removed the Uploaders field. I checked every package and this mistake occurred on this package and the packages statcvs and closure-compiler, which were already fixed (thanks Jochen). [1] https://qa.debian.org/orphaned.html Again, very sorry for that. Best Regards, mt signature.asc Description: PGP signature
Bug#1009482: sphinxcontrib-autoprogram: diff for NMU version 0.1.7-2.1
Control: tags 1009482 + pending
Dear maintainer,
I've prepared an NMU for sphinxcontrib-autoprogram (versioned as 0.1.7-2.1)
and uploaded it to DELAYED/15. Please feel free to tell me if I should
cancel it.
cu
Adrian
diff -Nru sphinxcontrib-autoprogram-0.1.7/debian/changelog sphinxcontrib-autoprogram-0.1.7/debian/changelog
--- sphinxcontrib-autoprogram-0.1.7/debian/changelog 2022-01-03 15:29:42.0 +0200
+++ sphinxcontrib-autoprogram-0.1.7/debian/changelog 2022-11-19 22:29:45.0 +0200
@@ -1,3 +1,11 @@
+sphinxcontrib-autoprogram (0.1.7-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add proposed fix for FTBFS with Python >= 3.10.
+(Closes: #1009482)
+
+ -- Adrian Bunk Sat, 19 Nov 2022 22:29:45 +0200
+
sphinxcontrib-autoprogram (0.1.7-2) unstable; urgency=medium
* Move package to Debian Python Team
diff -Nru sphinxcontrib-autoprogram-0.1.7/debian/patches/0001-Fix-argparse-output-for-Python-3.10-compatibility.patch sphinxcontrib-autoprogram-0.1.7/debian/patches/0001-Fix-argparse-output-for-Python-3.10-compatibility.patch
--- sphinxcontrib-autoprogram-0.1.7/debian/patches/0001-Fix-argparse-output-for-Python-3.10-compatibility.patch 1970-01-01 02:00:00.0 +0200
+++ sphinxcontrib-autoprogram-0.1.7/debian/patches/0001-Fix-argparse-output-for-Python-3.10-compatibility.patch 2022-11-19 22:00:30.0 +0200
@@ -0,0 +1,29 @@
+From 5f8cd70a0edcc804d305f360b6b6022767b2fcea Mon Sep 17 00:00:00 2001
+From: Karthikeyan Singaravelan
+Date: Thu, 28 Jan 2021 15:02:19 +
+Subject: Fix argparse output for Python 3.10 compatibility.
+
+---
+ sphinxcontrib/autoprogram.py | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/sphinxcontrib/autoprogram.py b/sphinxcontrib/autoprogram.py
+index c60cf68..1f051bb 100644
+--- a/sphinxcontrib/autoprogram.py
b/sphinxcontrib/autoprogram.py
+@@ -476,7 +476,11 @@ class ScannerTestCase(unittest.TestCase):
+ # section: default optionals
+ program, options, group = sections[1]
+ self.assertEqual([], program)
+-self.assertEqual("optional arguments", group.title)
++# See https://github.com/sphinx-contrib/autoprogram/issues/24
++if sys.version_info >= (3, 10):
++self.assertEqual('options', group.title)
++else:
++self.assertEqual('optional arguments', group.title)
+ self.assertEqual(None, group.description)
+ self.assertEqual(2, len(options))
+ self.assertEqual(
+--
+2.30.2
+
diff -Nru sphinxcontrib-autoprogram-0.1.7/debian/patches/series sphinxcontrib-autoprogram-0.1.7/debian/patches/series
--- sphinxcontrib-autoprogram-0.1.7/debian/patches/series 1970-01-01 02:00:00.0 +0200
+++ sphinxcontrib-autoprogram-0.1.7/debian/patches/series 2022-11-19 22:29:45.0 +0200
@@ -0,0 +1 @@
+0001-Fix-argparse-output-for-Python-3.10-compatibility.patch
Bug#1024458: seqan-needle: binary-all FTBFS
Source: seqan-needle Version: 1.0.1.0.0.git.3011926+ds-2 Severity: serious https://buildd.debian.org/status/fetch.php?pkg=seqan-needle=all=1.0.1.0.0.git.3011926%2Bds-2=1668618292=0 ... debian/rules override_dh_auto_build-indep make[1]: Entering directory '/<>' cd obj-* && /usr/bin/make doc /bin/sh: 1: cd: can't cd to obj-* make[1]: *** [debian/rules:26: override_dh_auto_build-indep] Error 2
Bug#1024457: "apt changelog" fails to display the complete changelog
Package: apt Version: 2.5.4 Severity: serious X-Debbugs-Cc: Debhelper Maintainers debhelper recently started removing older changelog entries from binary packages, but the way to get them with apt does not work: $ zcat /usr/share/doc/apt/changelog.gz | tail -5 -- Julian Andres Klode Mon, 05 Aug 2019 21:26:10 +0200 # Older entries have been removed from this changelog. # To read the complete changelog use `apt changelog apt`. $ apt changelog apt | tail -5 WARNING: apt does not have a stable CLI interface. Use with caution in scripts. -- Julian Andres Klode Mon, 05 Aug 2019 21:26:10 +0200 # Older entries have been removed from this changelog. # To read the complete changelog use `apt changelog apt`. Fetched 42.8 kB in 0s (0 B/s) $ Somehow apt fails to download the other 21 years of changelog entries, and performs the useless task of showing the truncated shipped changelog.
Bug#1024456: rust-proc-macro-crate: please update to v1.2.1
Source: rust-proc-macro-crate Version: 1.1.0-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to newer upstream release v1.2.1. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmN5PqwACgkQLHwxRsGg ASHtnA/+OkjJ80yRCBwt8Xbmoj83JCge2oDh6zz5kfFjl5w/J/eB9xv6nlz6c+X/ mnZbV6Qkd4bPnYWFG7dThZ8/Bg+JyP8847Ckq2T2jKibQ1O2aNndKYDRwJu7PfuX rldbJPbRdaeZS7Mzw3WidoE9wXKQgIMAthD0ywFXe7x6zPpAQ/XXw7ZnsEpYfcvM Bt8uTMW2/VqcjnVnEIKybLoMdNL3yZH8aKIZ5jkuQJpJXzE/ik1TI6yrxpIFKpwR t6NwUlMCIm5q2lpDLl/QmpONwFevdJ1wqtebp42rKHySz7aIUNsBDGyqTEs64XnV UoCCGj4ZvpAftaRVTFE/9h68c3iFASl6h/hECVvQms441F9O6LLruH7eQX5KTdJE FOZnb5qfChonqaCK1K352EmiJjFJ0RxjHCFKPwkZRW3ktfl6LT0FShH1ek4EpN7/ peMfvAr9kaNDApwDXW8H3tC9J/ORF60b9lNlXavI2tLcvHXHCv3Ec6G39tGFsmGf GtPxmRysKph/f1tclOOPd7KPQWUQfG3x5vE4eIdc5sXbzUa3hU4q3Q2A0+7zfPQl 9JK89GBAyouNXXfAiWeErsXxps/iTSQLePuNYvdTuOqRD3ESo4AwW+rIdxfnzb0M C83aLft42JppvDH1G6ExhsnqTx2aKh2mglEdzq8dGxiW/UoYO1s= =Mo6C -END PGP SIGNATURE-
Bug#982140: ITP: fuzzel -- Wayland-native application launcher
Dear FTP Team, Regarding the embedded copy of nanosvg, please see the investigation into prior occurrences in the Debian archive [1], and the reasoning for why the use of nanosvg is preferable over librsvg [2]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982145#74 [2] https://salsa.debian.org/swaywm-team/fuzzel/-/commit/9f111d2252e0047a14459254a77d3d04e5c1b57e Thanks, Peter
Bug#900821: Found working and failing 5.10 versions and got kernel crash, report from BSP Tilburg (https://deb.li/iiOID)
user debian-rele...@lists.debian.org
usertag 900821 + bsp-2022-11-nl-tilburg
found 900821 5.10.70-1
fixed 900821 5.10.84-1
thanks
We have/had a BSP in Tilburg today and I went to work on this bug.
With success :-)
I first created a new Bullseye VM with virt-manager using the
debian-11.5.0-amd64-netinst.iso installation media and installed only
the Standard System Utilities and SSH Server.
Upon reboot I installed vim (ofc) and followed the excellent instructions
from OP and installed the packages:
"apt-get install samba apache2 cifs-utils"
Then I added the `[ftp]` block to /etc/samba/smb.conf and created the
`/srv/ftp/100Mzero` file consisting of only zero's.
As I'd be rebooting often, I made mounting easy by adding to `/etc/fstab/`:
//localhost/ftp /var/www/html cifs
username=debian,password=root,noauto,user 0 0
Then I created the following script:
```
debian@debian-bullseye:~$ cat bug900821
#!/bin/sh
#/srv/ftp/100Mzero
SHA256_STORED="20492a4d0d84f8beb1767f6616229f85d44c2827b64bdbfb260ee12fa1109e0e"
echo "sha256sum should be:"
echo " $SHA256_STORED"
echo ""
i=0
while [ $i -ne 100 ]
do
i=$((i + 1))
#printf "$i "
printf ". "
SHA256_CALC="$(wget http://localhost/100Mzero -O - 2>/dev/null |
sha256sum | awk '{ print $1 }')"
if [ "$SHA256_CALC" != "$SHA256_STORED" ] ; then
printf "\nBug 900821 triggered! Calculated SHA256: %s\n"
"$SHA256_CALC"
exit 1
fi
done
printf "\nTest completed\n"
```
I tried it out on the installed kernel, 5.10.149-2 aka 5.10.0-19-amd64, and
found out it all worked as expected. Idem ditto for 5.10.140-1/5.10.0-18-amd64.
I then tried 5.10.28-1/5.10.0-6-amd64 and got a kernel crash \o/
I then went on to narrow down which version worked and which next lower version
did fail and it turned out 5.10.70-1 failed, while 5.10.84-1 succeeded.
What was both odd and interesting was what happened during a crash.
With 5.10.28-1 I got this:
debian@debian-bullseye:~$ ./bug900821
sha256sum should be:
20492a4d0d84f8beb1767f6616229f85d44c2827b64bdbfb260ee12fa1109e0e
.
Message from syslogd@debian-bullseye at Nov 19 18:43:22 ...
kernel:[ 40.266711] usercopy: Kernel memory exposure attempt detected from
SLUB object 'vm_area_struct' (offset 0, size 117)!
That killed my SSH session. I don't know if it was the case each time, but
at least twice I was able to directly log in to the VM ... and I was able
to secure `dmesg` which shows the kernel crash :-)
I have attached both that dmesg output as the Konsole output from my
BSP session wrt this bug.
I don't know if it's useful to do a (lengthy!) git-bisect session as I'm quite
sure the issue is fixed.
I've updated the metadata, but I haven't closed it (yet?).
Cheers,
Diederik[0.00] Linux version 5.10.0-9-amd64 (debian-ker...@lists.debian.org)
(gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian)
2.35.2) #1 SMP Debian 5.10.70-1 (2021-09-30)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-9-amd64
root=UUID=a7893f33-27c0-4b56-8d49-b0e98db7f84a ro quiet
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64
[0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960
bytes, using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x3ffdbfff] usable
[0.00] BIOS-e820: [mem 0x3ffdc000-0x3fff] reserved
[0.00] BIOS-e820: [mem 0xb000-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.8 present.
[0.00] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
1.16.0-debian-1.16.0-4 04/01/2014
[0.00] Hypervisor detected: KVM
[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[0.00] kvm-clock: cpu 0, msr 2c4b3001, primary cpu clock
[0.00] kvm-clock: using sched offset of 1463003892121 cycles
[
Bug#1024117: RM: ember -- ROM; unstable upstream, unsuitable for Debian
hi Olek, On Mon, Nov 14, 2022 at 06:58:17PM -0500, Olek Wojnar wrote: > Package: ftp.debian.org > Severity: normal > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Upstream agrees with removal: \https://bugs.debian.org/cgi- > bin/bugreport.cgi?bug=950926#49 It was removed from unstable, but should it be removed as well from experimental? ember | 0.6.2+dfsg-2.1 | oldoldoldstable | source, amd64, armel, armhf, i386 ember | 0.7.2+dfsg-1 | oldoldstable | source ember | 0.7.2+dfsg-1+b1 | oldoldstable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x ember | 0.8.0~snap2~exp1 | experimental/contrib | source, amd64 Regards, Salvatore
Bug#997145: autoconf2.69: diff for NMU version 2.69-3.1
Control: tags 997145 + pending Dear maintainer, I've prepared an NMU for autoconf2.69 (versioned as 2.69-3.1) and uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru autoconf2.69-2.69/debian/changelog autoconf2.69-2.69/debian/changelog --- autoconf2.69-2.69/debian/changelog 2021-09-17 18:52:26.0 +0300 +++ autoconf2.69-2.69/debian/changelog 2022-11-19 21:40:11.0 +0200 @@ -1,3 +1,11 @@ +autoconf2.69 (2.69-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Backport upstream fix for FTBFS with recent texinfo. +(Closes: #997145) + + -- Adrian Bunk Sat, 19 Nov 2022 21:40:11 +0200 + autoconf2.69 (2.69-3) unstable; urgency=medium * Don't apply the add-runstatedir backport, not needed in the context diff -Nru autoconf2.69-2.69/debian/patches/0001-doc-port-to-Texinfo-6.3.patch autoconf2.69-2.69/debian/patches/0001-doc-port-to-Texinfo-6.3.patch --- autoconf2.69-2.69/debian/patches/0001-doc-port-to-Texinfo-6.3.patch 1970-01-01 02:00:00.0 +0200 +++ autoconf2.69-2.69/debian/patches/0001-doc-port-to-Texinfo-6.3.patch 2022-11-19 21:40:11.0 +0200 @@ -0,0 +1,28 @@ +From d7e0164f857408dbce186d97dc6ff67b5a276d89 Mon Sep 17 00:00:00 2001 +From: Paul Eggert +Date: Tue, 13 Sep 2016 17:51:18 -0700 +Subject: doc: port to Texinfo 6.3 + +* doc/autoconf.texi: Remove obsolete @setcontentsaftertitlepage +that provokes a warning from Texinfo 6.3. +--- + doc/autoconf.texi | 3 --- + 1 file changed, 3 deletions(-) + +diff --git a/doc/autoconf.texi b/doc/autoconf.texi +index 34ca2137..79f65412 100644 +--- a/doc/autoconf.texi b/doc/autoconf.texi +@@ -5,9 +5,6 @@ + @include version.texi + @settitle Autoconf + @setchapternewpage odd +-@ifnothtml +-@setcontentsaftertitlepage +-@end ifnothtml + @finalout + + @c @ovar(ARG) +-- +2.30.2 + diff -Nru autoconf2.69-2.69/debian/patches/series autoconf2.69-2.69/debian/patches/series --- autoconf2.69-2.69/debian/patches/series 2021-09-17 18:52:26.0 +0300 +++ autoconf2.69-2.69/debian/patches/series 2022-11-19 21:40:09.0 +0200 @@ -6,4 +6,4 @@ #add-runstatedir.patch unescaped-left-brace-warning-fix.patch mmap-leak-fix.patch - +0001-doc-port-to-Texinfo-6.3.patch
Bug#1019731: gitlab: failed to fetch comments in merge requests (500 Internal Server Error)
> My bad, I mixed things up: the 500 error I am experiencing is the one from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019403 (undefined method `h' for LabelsHelper:Module). Yeah, these two seem quite similar. The workaround for 1019403 has to be repeated after every update, though, while this one only needs to be implemented once.
Bug#1024451: transition: coq-elpi
Control: tags -1 confirmed Hi Julien On 2022-11-19 18:31:07 +0100, julien.pu...@gmail.com wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: jpu...@debian.org > X-Debbugs-Cc: Debian OCaml Maintainers > > > Hi, > > there is a new version of coq-elpi ; it requires > rebuilding other packages: > > nmu coq-hierarchy-builder_1.4.0-2+b2 . ANY . -m 'Rebuild because of > upload of coq-elpi=1.16.0-1' > dw coq-hierarchy-builder_1.4.0-2+b2 . ANY . -m 'coq-elpi >= 1.16.0-1' > nmu mathcomp-algebra-tactics_1.0.0-8+b2 . ANY . -m 'Rebuild because of > upload of coq-elpi=1.16.0-1' > dw mathcomp-algebra-tactics_1.0.0-8+b2 . ANY . -m 'coq-elpi >= 1.16.0- > 1' > nmu mathcomp-analysis_0.5.4-3+b2 . ANY . -m 'Rebuild because of upload > of coq-elpi=1.16.0-1 coq-hierarchy-builder=1.4.0-2+b2' > dw mathcomp-analysis_0.5.4-3+b2 . ANY . -m 'coq-elpi >= 1.16.0-1' > dw mathcomp-analysis_0.5.4-3+b2 . ANY . -m 'coq-hierarchy-builder >= > 1.4.0-2+b2' > > > I'm waiting for your approval to upload coq-elpi 1.16.0-1. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1024380: transition: simdjson
Control: tags -1 confirmed On 2022-11-18 09:42:10 -0500, M. Zhou wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear release team, > > There was some minor API updates in the latest version of simdjson, > which resulted an SOVERSION bump from 13 to 14. I've tried to build > its reverse dependencies locally on an amd64 host, and the results > are all good: > > cloudflare-ddns [ok] > pcm [ok] > > I'd like to transit and let the next stable release > ship the latest version. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1024184: transition: alkimia
Control: tags -1 confirmed On 2022-11-15 22:09:46 +0100, Hefee wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: he...@debian.org, pkg-kde-t...@lists.alioth.debian.org > > A easy transition as it has only one package depdens on alkimia: > > kmymoney (successfully builds with old and new version of alkimia). > > The new version of alkimia depends on serveral new libriaries, it is > hard to say if the new version will compile on all archs as before. It > seems like the last Qt transition is still challangeing some buildds. So > we may loose some archs with this transtion. Please go ahead Cheers > > hefee > > > Ben file: > > title = "alkimia"; > is_affected = .depends ~ "libalkimia5-7" | .depends ~ "libalkimia5-8"; > is_good = .depends ~ "libalkimia5-8"; > is_bad = .depends ~ "libalkimia5-7"; > -- Sebastian Ramacher
Bug#1023550: transition: qcustomplot
Hi Filippo On 2022-11-11 10:56:08 +0100, Filippo Rusconi wrote: > Greetings Sebastian, > > Thank your for your message. > > On Thu, Nov 10, 2022 at 11:04:54PM +0100, Sebastian Ramacher wrote: > > Control: tags -1 moreinfo > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-qcustomplot.html > > > > Hi Filippo > > > > On 2022-11-06 15:29:32 +0100, Filippo Rusconi wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > X-Debbugs-Cc: lopi...@debian.org, gl...@debian.org, > > > debian-science-maintain...@lists.alioth.debian.org > > > > > > (please explain about the transition: impacted packages, reason, ... > > > for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) > > > > > > Greetings, > > > > > > Fundamental reason: Qt5 and Qt6 are in the archive. > > > > > > I am requesting a transition from package libqcustomplot2.0 to > > > libqcustomplot2.1. Source package is qcustomplot. The change involves a > > > change > > > in the library name itself, from libqcustomplot2.0 to both > > > libQCustomPlot2.1 and > > > libQCustomPlotQt6.so.2.1.0 (see below). > > > > > > I have prepared the packaging in the following git repos branch: > > > > > > https://salsa.debian.org/science-team/qcustomplot/-/tree/qt5-and-qt6 > > [...] > > > > For the libs under my control, the transition is already prepared and > > > these > > > projects are going to be linking against the Qt6-built library, contrary > > > to all > > > the other packages detailed below. > > > > > > For the other libs listed above, I have already checked that they would > > > build if > > > some modifications were performed. I have already git branches ready for > > > the > > > packages under git VCS. For the others (source deb), I have patches > > > available. > > > > > > The modifications are lean: change -lqcustomplot to -lQCustomPlot for > > > many and > > > also sometimes use the CMake-based configuration involving first > > > find_package(QCustomPlot) and second the QCustomPlot::QCustomPlot > > > formalism for > > > the linker. > > > > > > That is: almost one- or two-liner patches. > > > > Could you please file bugs for those so that maintainers are aware? > > Yes, I'll do that. I have already informed them individually of the process > and > provided them with the relevant patch. Thanks! Please go ahead with the transition. Cheers -- Sebastian Ramacher
Bug#1023846: transition: gdal
Control: tags -1 confirmed Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Hi Bas, On 2022-11-11 11:55:45 +0100, Bas Couwenberg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-gdal.html > Control: block -1 by 1023480 1023506 1004795 998833 984398 1023520 1012950 > > For the Debian GIS team I'd like to transition to GDAL 3.6.0. Please go ahead Cheers > > Most reverse dependencies rebuilt successfully with GDAL 3.6.0 from > experimental as summarized below. > > > rasterio (1.3.3-1) FTBFS due to test failures (#1023480), this is fixed in > rasterio (1.3.3-2). > > libgdal-grass (1:1.0.1-1) FTBFS due to compile errors (#1023506), this is > fixed in libgdal-grass (1:1.0.1-2). > > gazebo (11.10.1+dfsg-2) FTBFS due to unrelated issues (#1004795). > > mysql-workbench (8.0.26+dfsg-1) FTBFS due to unrelated issues (#998833). > > vtk6 (6.3.0+dfsg2-8.1) FTBFS due to unrelated issues (#984398). > > sumo (1.12.0+dfsg1-1) FTBFS due to unrelated issues (#1023520). > > otb (8.0.1+dfsg-1) FTBFS due to unrelated issues (#1012950). > > > The bugreports can be found via the gdal-3.6 usertag: > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org=gdal-3.6 > > > Transition: gdal > > libgdal31 (3.5.3+dfsg-1) -> libgdal32 (3.6.0~rc1+dfsg-1~exp1) > > The status of the most recent rebuilds is as follows. > > cloudcompare(2.11.3-7) OK > fiona (1.8.22-1) OK > gazebo (11.10.1+dfsg-2)FTBFS (#1004795) > gmt (6.4.0+dfsg-1) OK > grass (8.2.0-2) OK > libcitygml (2.4.3-1) OK > libosmium (2.18.0-1) OK > mapcache(1.12.1-1) OK > mapnik (3.1.0+ds-2)OK > mapproxy(1.15.1-1) OK > mapserver (8.0.0-2) OK > merkaartor (0.19.0+ds-3) OK > mysql-workbench (8.0.26+dfsg-1) FTBFS (#998833) > ncl (6.6.2-12) OK > octave-mapping (1.4.2-2) OK > openorienteering-mapper (0.9.5-3) OK > openscenegraph (3.6.5+dfsg1-8) OK > paraview(5.11.0~rc1+dfsg-1) OK > pgsql-ogr-fdw (1.1.3-1) OK > pktools (2.6.7.6+ds-3) OK > postgis (3.3.1+dfsg-2) OK > python-django (3:3.2.16-1)OK > qmapshack (1.16.1-1) OK > r-cran-rgdal(1.5-32+dfsg-1) OK > r-cran-sf (1.0-8+dfsg-1) OK > r-cran-terra(1.6-17-1) OK > rasterio(1.3.3-2) OK > saga(8.4.0+dfsg-1) OK > vtk6(6.3.0+dfsg2-8.1) FTBFS (#984398) > vtk7(7.1.1+dfsg2-10.2) OK > vtk9(9.1.0+really9.1.0+dfsg2-4) OK > > libgdal-grass (1:1.0.2-2) OK > opencv (4.6.0+dfsg-7) OK > osmcoastline(2.3.1-1) OK > qgis(3.22.12+dfsg-1)OK > sumo(1.12.0+dfsg1-1)FTBFS (#1023520) > > otb (8.0.1+dfsg-1) FTBFS (#1012950) > > > Kind Regards, > > Bas > -- Sebastian Ramacher
Bug#1022404: raqm: diff for NMU version 0.7.0-4.1
Control: tags 1022404 + patch Control: tags 1022404 + pending Dear maintainer, I've prepared an NMU for raqm (versioned as 0.7.0-4.1) and uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru raqm-0.7.0/debian/changelog raqm-0.7.0/debian/changelog --- raqm-0.7.0/debian/changelog 2019-12-17 11:08:26.0 +0200 +++ raqm-0.7.0/debian/changelog 2022-11-19 21:15:45.0 +0200 @@ -1,3 +1,10 @@ +raqm (0.7.0-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add upstream fix for FTBFS with recent HarfBuzz. (Closes: #1022404) + + -- Adrian Bunk Sat, 19 Nov 2022 21:15:45 +0200 + raqm (0.7.0-4) unstable; urgency=medium * debian/tests/libssh-server: Use the correct compiler for proposed diff -Nru raqm-0.7.0/debian/patches/0001-Update-text-expectation.patch raqm-0.7.0/debian/patches/0001-Update-text-expectation.patch --- raqm-0.7.0/debian/patches/0001-Update-text-expectation.patch 1970-01-01 02:00:00.0 +0200 +++ raqm-0.7.0/debian/patches/0001-Update-text-expectation.patch 2022-11-19 19:32:08.0 +0200 @@ -0,0 +1,29 @@ +From 17170a1eeb63807b4035427f3ca2b3e475c8f42b Mon Sep 17 00:00:00 2001 +From: Khaled Hosny +Date: Wed, 25 Aug 2021 16:58:25 +0200 +Subject: Update text expectation + +--- + tests/cursor_position_GB8a.test | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/tests/cursor_position_GB8a.test b/tests/cursor_position_GB8a.test +index bef963e..d161691 100644 +--- a/tests/cursor_position_GB8a.test b/tests/cursor_position_GB8a.test +@@ -32,9 +32,9 @@ glyph [0] x_offset: 0 y_offset: 0 x_advance: 748 font: Amiri + glyph [0] x_offset: 0 y_offset: 0 x_advance: 748 font: Amiri + glyph [0] x_offset: 0 y_offset: 0 x_advance: 748 font: Amiri + +-UTF-32 clusters: 00 01 02 03 +-UTF-8 clusters: 00 04 08 12 ++UTF-32 clusters: 00 00 02 02 ++UTF-8 clusters: 00 00 08 08 + +-The position is 2992 at index 12 ++The position is 2244 at index 8 + + The start-index is 4 at position 1000 +-- +2.30.2 + diff -Nru raqm-0.7.0/debian/patches/series raqm-0.7.0/debian/patches/series --- raqm-0.7.0/debian/patches/series 2019-12-17 11:08:26.0 +0200 +++ raqm-0.7.0/debian/patches/series 2022-11-19 21:15:36.0 +0200 @@ -1 +1,2 @@ use_py3.diff +0001-Update-text-expectation.patch
Bug#1024455: Missing PDF mimetype icon
Package: tango-icon-theme Version: 0.8.90-11 Severity: wishlist Hello, I miss an icon for easily identifying PDF files. As far as I can see, currently the Tango Icon Theme does not contain a proper/true file for PDF documents, just a soft link to generic SVG file which makes difficult to distinguish between plain text or document files from PDF. sm01@stt008:~$ ls -la /usr/share/icons/Tango/scalable/mimetypes/ | grep pdf lrwxrwxrwx 1 root root21 ago 12 2020 gnome-mime-application-pdf.svg -> x-office-document.svg PDFs deserve a REAL icon! :-) A good candidate can be Nuvola icon from old Gnome Themes Extra¹ which looks and renders pretty nice². ¹https://download.gnome.org/sources/gnome-themes-extras/0.9/ ²https://commons.wikimedia.org/wiki/File:Gnome-mime-application-pdf.svg P.S. Maybe this bug is suitable to be forwarded to Tango project. Greetings, -- Camaleón
Bug#1024314: python-msgpack: b-d on python3-all-dev, but not built for all supported Python3
Hi, What's happening is that this package fails to build the Python 3.11 (because of some compilation errors), but does this gracefully, as this is only an optional acceleration. As a consequence, I'm downgrading this severity to important, as I believe the package will continue to work in the current form (only in a degraded way). I'll see what I can do to repair the build. Cheers, Thomas Goirand (zigo)
Bug#1024454: rust-chrono: Please update to v0.4.23
Source: rust-chrono Version: 0.4.22-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to newer upstream release v0.4.23. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmN5JMYACgkQLHwxRsGg ASGbAA//YVWnS+k060cdWl3+NuRTTTMcuSZWQ42Ex2HDslL2RtMkfLgdx/5dkGN1 UNnOTK2E6hV7xHsblXAoZ4s4sPqzUqiyh0BgiKLRKiVRuaHAGqr+woZRc8FNeQRO yeyopMuu3pSdUXl0e/f+YgYumFYG6siSHGoGnyT06AhEUiAwGz+cjqHjxcfY8UDc hiI/y/jZ3dTJPrb0/DtyXB+u3uvMRYgzFZZ9QPPCMZfwTqh2KQj3gERR+H8P82gU 7KLSqRXENq1fB2KDMxPaSm+nG463Eg7X4AER0TxWKBCm4ERl7fWdCcTPp6AnDY91 U+KGNXpdWAzGO+r02G7MyQsweM85Mc9IFcjTfYW+MmnInUaiyBXDYNl3QA1YWzmy JBgzPTomWuqYhoTFee4+j4OAZy6OGKAGQoIlutIRwkYbk0fLsMhcaxgGzLVDFkRs EFchyo9tGQIDy9+2ZfGDQmrjvnwzxnQHHjxa/+8XTIKn0qHPy/Nm6eD+0aOALs2z RDCFTFnoyKaEGXq8mKSdV3QtH+fiSF2PMtmApuT44TUqU2V80JUE1z6FRXg90kXK MDutxmjf1/aWNnQKXsQH/HU+NZEKkFtOoRXm7z5vG5IfW+R9R30ll6KGkT/fJrh5 NP3QCMm6Q7a+67r37hm6YqkQdIR4rjVWECbh6byRLHIsM4/jMkw= =3Fps -END PGP SIGNATURE-
Bug#1024453: mediathek: fails to start with openjdk 17
Control: reassign -1 java-wrappers 0.3 Control: affects -1 mediathekview On 2022-11-19 19:18:14 +0100, Sebastian Ramacher wrote: > Package: mediathekview > Version: 13.2.1+ds-1 > Severity: grave > X-Debbugs-Cc: sramac...@debian.org > > Since the switch to openjre-17 as default, mediathekview nolonger > starts: > > $ mediathekview > [warning] /usr/bin/mediathekview: No java runtime was found This is an issue in java-wrappers. It does not know about version 17. Cheers > > > Cheers > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable-debug > APT policy: (650, 'unstable-debug'), (650, 'unstable'), (601, 'testing'), > (600, 'experimental-debug'), (600, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.0.0-4-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=en_US:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages mediathekview depends on: > ii default-jre [java9-runtime] 2:1.17-73 > ii java-wrappers 0.3 > ii libcommons-compress-java1.21-1 > ii libcommons-configuration2-java 2.8.0-1 > ii libcommons-dbcp2-java 2.9.0-1 > ii libcommons-lang3-java 3.12.0-2 > ii libcommons-pool2-java 2.11.1-1 > ii libcontrolsfx-java 11.0.0-1 > ii libguava-java 29.0-6 > ii libjackson2-core-java 2.14.0-2 > ii libjchart2d-java3.2.2+dfsg2-3 > ii libjiconfont-font-awesome-java 4.7.0.1-1 > ii libjiconfont-java 1.0.0-2 > ii libjiconfont-swing-java 1.0.1-2 > ii libjide-oss-java3.7.6+dfsg-2 > ii liblog4j2-java 2.17.2-1 > ii libmbassador-java 1.3.1-2 > ii libmiglayout-java 5.1-3 > ii libokhttp-java 3.13.1-3 > ii libopenjfx-java 11.0.11+1-1.1 > ii libslf4j-java 1.7.32-1 > ii libswingx-java 1:1.6.2-4 > ii libxz-java 1.9-1 > ii openjdk-17-jre [java9-runtime] 17.0.5+8-2 > > Versions of packages mediathekview recommends: > pn flvstreamer > ii mpv 0.35.0-2 > ii vlc 3.0.18~rc2-1+b1 > > Versions of packages mediathekview suggests: > ii ffmpeg 7:5.1.2-1 > > -- no debconf information > > -- > Sebastian Ramacher -- Sebastian Ramacher
Bug#1024391: gtk4: FTBFS on big-endian: some dependency made border-image-excess-size reftest regress
Control: severity -1 normal Control: tags -1 - ftbfs On Fri, 18 Nov 2022 at 18:08:29 +, Simon McVittie wrote: > I'll ignore this test failure for now and downgrade these bugs to non-RC. gtk+3.0_3.24.34-5 and gtk4_4.8.2+ds-3 ignore this test failure on big-endian, and were built successfully on all release architectures. smcv
Bug#1022365: reproduction
This seems to be the source of the problem: pdsh@ip-10-84-234-180: module path "/<>/src/modules/.libs" insecure. pdsh@ip-10-84-234-180: "/build": Owner not root, current uid, or pdsh executable owner pdsh@ip-10-84-234-180: Couldn't load any pdsh modules Indeed, I can reproduce by building in a directory that has an ancestor directory owned by a user that is neither root, nor myself. I've not been clever enough to workaround this. Two options would be to (1) disable the failing tests or (2) avoid the failures by linking the plugins statically. Neither seems ideal.
Bug#1024453: mediathek: fails to start with openjdk 17
Package: mediathekview Version: 13.2.1+ds-1 Severity: grave X-Debbugs-Cc: sramac...@debian.org Since the switch to openjre-17 as default, mediathekview nolonger starts: $ mediathekview [warning] /usr/bin/mediathekview: No java runtime was found Cheers -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (650, 'unstable-debug'), (650, 'unstable'), (601, 'testing'), (600, 'experimental-debug'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-4-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=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages mediathekview depends on: ii default-jre [java9-runtime] 2:1.17-73 ii java-wrappers 0.3 ii libcommons-compress-java1.21-1 ii libcommons-configuration2-java 2.8.0-1 ii libcommons-dbcp2-java 2.9.0-1 ii libcommons-lang3-java 3.12.0-2 ii libcommons-pool2-java 2.11.1-1 ii libcontrolsfx-java 11.0.0-1 ii libguava-java 29.0-6 ii libjackson2-core-java 2.14.0-2 ii libjchart2d-java3.2.2+dfsg2-3 ii libjiconfont-font-awesome-java 4.7.0.1-1 ii libjiconfont-java 1.0.0-2 ii libjiconfont-swing-java 1.0.1-2 ii libjide-oss-java3.7.6+dfsg-2 ii liblog4j2-java 2.17.2-1 ii libmbassador-java 1.3.1-2 ii libmiglayout-java 5.1-3 ii libokhttp-java 3.13.1-3 ii libopenjfx-java 11.0.11+1-1.1 ii libslf4j-java 1.7.32-1 ii libswingx-java 1:1.6.2-4 ii libxz-java 1.9-1 ii openjdk-17-jre [java9-runtime] 17.0.5+8-2 Versions of packages mediathekview recommends: pn flvstreamer ii mpv 0.35.0-2 ii vlc 3.0.18~rc2-1+b1 Versions of packages mediathekview suggests: ii ffmpeg 7:5.1.2-1 -- no debconf information -- Sebastian Ramacher
Bug#1024452: RFS: cbonsai/1.3.1-1 -- terminal-based bonsai tree generator
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "cbonsai": * Package name : cbonsai Version : 1.3.1-1 Upstream contact : https://gitlab.com/jallbrit/cbonsai/-/issues * URL : https://gitlab.com/jallbrit/cbonsai * License : GPL-3 * Vcs : https://salsa.debian.org/rgson/cbonsai Section : games The source builds the following binary packages: cbonsai - terminal-based bonsai tree generator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/cbonsai/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/cbonsai/cbonsai_1.3.1-1.dsc Changes since the last upload: cbonsai (1.3.1-1) unstable; urgency=medium . [ Matthias Geiger ] * New upstream version 1.3.1 * Added myself to Uploaders * Imported upstream patch for manpage section * Switched to scdoc in d/control for generating the manpage * Updated year in d/copyright . [ Debian Janitor ] * Set upstream metadata fields * Update standards version to 4.6.1, no changes needed. . [ Robin Gustafsson ] * Restore debian/manpages * Remove rebuild in cross-arch builds * Build manpage with upstream's Makefile * Wrap-and-sort control files Regards, Robin
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
Jelmer Vernooij: Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: setuptools-gettext Version : 0.0.1 Upstream Author : Breezy Team * URL : https://github.com/jelmer/setuptools-gettext * License : GPL Programming Lang: Python Description : Compile .po files into .mo files This extension for setuptools compiles gettext .po files found in the source directory into .mo files and installs them. FYI: The upstream URL is a 404. Maybe there is a typo or the repo is still private? ~Niels
Bug#1023576: Need to change the way raku-api is built (will breaks modules)
Hi Following bug #1023576 and [1], the dependency between raku modules and rakudo version needs to be tightened. Until now, every raku-module depends on raku-api- (currently is raku-api-2022-07). The idea is to lock the pre-compiled files contained in a raku-module package to a specific rakudo version. Turns out this is not enough. The pre-compiled files are specific to raku compiler id, which changes whenever nqp or rakudo sources are changed. This source change occurred only on nqp or rakudo upgrades, until I had to patch rakudo source code to fix a bug (#1019579). To fix this, I need to make sure that a module is dependent on a rakudo version with a matching compiler-id. I see no other solution than to change the way rakudo is built to include the compiler id in raku-api (well, only the first 8 chars, because compiler id is quite long). I.e. the next version of rakudo will have this in its control file: Provides: raku-api-2022.07+a6fe09f2 And dh-raku-build will be modified to inject this dependency in raku modules. E.g.: Depends: raku-api-2022.07+a6fe09f2 So, the plan is: - upload a new dh-raku (which will produce non installable raku module package until rakudo is updated) - upload a new version of rakudo in experimental - trigger a transition so that all raku modules are rebuilt with new rakudo and new dh-raku Until the transition is complete, raku in Debian/unstable will be a mess. If anyone has a better idea, I'm all ears ... Dod [1] https://github.com/rakudo/rakudo/issues/5099
Bug#972566: python3-opencv: build python extensions for all supported python versions
Package: python3-opencv Followup-For: Bug #972566 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 With the addition of Python 3.11 as a supported version, it became easier for me to try this. I have created a patch and opened a merge request on Salsa: https://salsa.debian.org/science-team/opencv/-/merge_requests/3 Regards, Victor Westerhuis -BEGIN PGP SIGNATURE- iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmN5Dd8THHZpY3RvckB3 ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+zvPEACg8BGXXuB0NmNJuO8GatN0l4VkceiI s8+vSPMeZCwxfLSXrrCbjumdTrNI7KuiUvs2q2NCGZdqPxYPY+K/pb+SkMpN7bev LXmAJyDWhimP3k7A8p/4isN/7V2UWVnDrgYa8xrgG/M7Gkd92k9Xb54eX6HTzamh U9VftxqtGm4dNBJJYDt/KND4YA2PRp9lnRRdFagdmzrosdDSVZhI5AK/Ll+XKYOL bCakGXTHTws+oyUzGiVyDL2AW1yH06uBDMIB8bBDTbsV2fGvivgqP2UiKMpVUKNS Y9134m+FiYC2gTs0L1H0VDGZyMdfm8s5jboRzHqLM/Z7lk1NnhZwExuWu6vfnX8g UvN+xo78/AfGkKEf/a2AmANm/yWs6oPm36hIg59Ur+6I41NRsYFbU9RXWcMRvlem //BliPvaEdTHbsjIv9P+IkGA1q+fK4IpHvZL4CDsemf4+T0zJEOt4zkt7e+XR2Wf zyPoRQkw5Uv8XgCvrVqbe7OKoN1eKwcctxjhBmtjpe1b3k99bCz4wK6UsIkPdg0M wVEFdtoJKmhMs4gifj2RgxitK3RaJQHP1HkuZA8IIbmwVcfsJaWkHdZu4cIh5vOu 2C/ue2FU7IvQUnFQWMgbPR97dPNMVmYfQecdkbOqIVd68VVscjd5NkJEIdlVXHdK k0CMYMhghrva1w== =2UPQ -END PGP SIGNATURE-
Bug#1024451: transition: coq-elpi
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers Hi, there is a new version of coq-elpi ; it requires rebuilding other packages: nmu coq-hierarchy-builder_1.4.0-2+b2 . ANY . -m 'Rebuild because of upload of coq-elpi=1.16.0-1' dw coq-hierarchy-builder_1.4.0-2+b2 . ANY . -m 'coq-elpi >= 1.16.0-1' nmu mathcomp-algebra-tactics_1.0.0-8+b2 . ANY . -m 'Rebuild because of upload of coq-elpi=1.16.0-1' dw mathcomp-algebra-tactics_1.0.0-8+b2 . ANY . -m 'coq-elpi >= 1.16.0- 1' nmu mathcomp-analysis_0.5.4-3+b2 . ANY . -m 'Rebuild because of upload of coq-elpi=1.16.0-1 coq-hierarchy-builder=1.4.0-2+b2' dw mathcomp-analysis_0.5.4-3+b2 . ANY . -m 'coq-elpi >= 1.16.0-1' dw mathcomp-analysis_0.5.4-3+b2 . ANY . -m 'coq-hierarchy-builder >= 1.4.0-2+b2' I'm waiting for your approval to upload coq-elpi 1.16.0-1. Cheers, J.Puydt
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: setuptools-gettext Version : 0.0.1 Upstream Author : Breezy Team * URL : https://github.com/jelmer/setuptools-gettext * License : GPL Programming Lang: Python Description : Compile .po files into .mo files This extension for setuptools compiles gettext .po files found in the source directory into .mo files and installs them.
Bug#900928: RFP: fractal -- Matrix group messaging app
5.0.0~~git20221105 draft 5 needs embedding 140 crates (73 missing, 3 broken, 49 outdated, 15 ahead); works fine. Main tasks now are to keep package up-to-date with upstream releases, and wait for Rust team to upgrade GTK and GStreamer crates. Here's how you can help: As user running Debian, you can test this draft package: Either build it yourself from source or tell (by posting to this bugreport) if you prefer testing the binary packages I built - then I will share those. As developer (but no need to be official member of Debian!), you can join the Debian Rust team and help package these missing crates: https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1023149: pandoc: diff for NMU version 2.17.1.1-1.1
Control: tags 1023149 + patch Control: tags 1023149 + pending Dear maintainer, I've prepared an NMU for pandoc (versioned as 2.17.1.1-1.1) and uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru pandoc-2.17.1.1/debian/changelog pandoc-2.17.1.1/debian/changelog --- pandoc-2.17.1.1/debian/changelog 2022-08-13 17:45:31.0 +0300 +++ pandoc-2.17.1.1/debian/changelog 2022-11-19 15:13:51.0 +0200 @@ -1,3 +1,10 @@ +pandoc (2.17.1.1-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Workaround i386 FTBFS with -O0. (Closes: #1023149) + + -- Adrian Bunk Sat, 19 Nov 2022 15:13:51 +0200 + pandoc (2.17.1.1-1) unstable; urgency=medium [ upstream ] diff -Nru pandoc-2.17.1.1/debian/rules pandoc-2.17.1.1/debian/rules --- pandoc-2.17.1.1/debian/rules 2022-08-13 17:27:42.0 +0300 +++ pandoc-2.17.1.1/debian/rules 2022-11-19 15:13:49.0 +0200 @@ -192,6 +192,10 @@ DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-optc--param -optcggc-min-expand=10 -O0" endif +ifneq (,$(filter $(DEB_HOST_ARCH_CPU), i386)) +DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-O0" +endif + DEB_SETUP_GHC_CONFIGURE_ARGS += $(if $(filter nocheck,$(DEB_BUILD_OPTIONS)),,-ftests) DEB_INSTALL_DOCS_ALL += README.md
Bug#1024245: network-manager: after upgrade - can't modify or add connections
There's a workaround for this case which worked for me: You need to edit "/usr/share/glib-2.0/schemas/org.gnome.nm-applet.eap.gschema.xml" and just change one line like you can see here: https://gitlab.gnome.org/GNOME/libnma/-/merge_requests/44/diffs from: path="/org/gnome/nm-applet/eap/"gettext-domain="nm-applet"> to: After that you need to run: sudo glib-compile-schemas /usr/share/glib-2.0/schemas/ and your done. Good luck.
Bug#1024449: ITP: libdevel-mat-perl -- Perl Memory Analysis Tool
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libdevel-mat-perl Version : 0.49 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Devel-MAT * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl Memory Analysis Tool The Devel::MAT ecosystem allows developers of perl programs to inspect and analyse memory-related problems such as memory leaks, unexpected memory consumption, or odd state. This is an "offline" analysis system, in the sense that the analysis tools all run in a different process, possibly at a later time, than the perl process that is being analysed. The basic workflow consists of two main stages: first a heap dump file is generated from the perl process being debugged, at or around the time that the problem becomes apparent, and secondly this file is loaded by an analysis tool in order to inspect the contents. To generate the heap dump file that captures the contents of the heap, the Devel::MAT::Dumper (libdevel-mat-dumper-perl) module is used. Now that we have a .pmat file, we can load it and start to inspect the contents. A lot of the smaller, simpler tools are built as plugins for the main pmat command shell (contained in libdevel-mat-perl, together with Devel::MAT), so we can start by loading the heap file there. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#997366: speedcrunch: FTBFS: TypeError: 'SpeedCrunchSessionLexer' object is not callable
On Sat, 29 Oct 2022 at 10:57, Felix Geyer wrote: > I've prepared a fix for building against Sphinx >= 4 and uploaded it to > DELAYED/5. > Please feel free to tell me if I should cancel it. The debdiff is attached. Nah, it's great, thanks for fixing this. I pushed the fix to the repo and upstream as well.
Bug#1024447: grub-efi-amd64: No box border characters in boot menu
Package: grub-efi-amd64
Version: 2.06-5
Severity: normal
X-Debbugs-Cc: chris...@gmx.de
Dear Maintainer,
I am running debian testing/bookworm. After the updates from grub 2.06-4 to
grub 2.06-5 (about November 18th) in the grub boot menu the box border
characters are not shown as they should. Insteadn one sees only a boxed
question mark for each character. Further, an error message is shown as text
for a fraction of a second directly before the boot menu arsises:
"error: prohibited by secure boot policy."
I believe this is new in 2.06-5.
When I disable secure boot with the mainboard firmware, the characters/boot
menu shows
up correctly.
I can trigger this in my kvm virtualized installtion and on my bare metal
machine with an ASUS H170 Gaming main board (and latest firmware).
Best,
Chris
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/sda2 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda1 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
/dev/sdb1 /bak ext4 rw,relatime,errors=remount-ro 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
a959f586-d0e1-4254-84f7-5350df65edb3
else
search --no-floppy --fs-uuid --set=root a959f586-d0e1-4254-84f7-5350df65edb3
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=de_DE
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
a959f586-d0e1-4254-84f7-5350df65edb3
else
search --no-floppy --fs-uuid --set=root a959f586-d0e1-4254-84f7-5350df65edb3
fi
insmod png
if background_image /usr/share/desktop-base/homeworld-theme/grub/grub-16x9.png;
then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-a959f586-d0e1-4254-84f7-5350df65edb3' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
a959f586-d0e1-4254-84f7-5350df65edb3
else
search --no-floppy --fs-uuid --set=root
a959f586-d0e1-4254-84f7-5350df65edb3
Bug#1024448: ITP: libcommandable-perl -- utilities for commandline-based programs
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libcommandable-perl Version : 0.08 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Commandable * License : Artistic or GPL-1+ Programming Lang: Perl Description : utilities for commandline-based programs The Commandable distribution contains a collection of utilities extracted from various commandline-based programs, in the hope of trying to find a standard base to build these from in future. "Commandline" does not necessarily mean "plain-text running in a terminal"; simply that the mode of operation is that the user types a textual representation of some action, and the program parses this text in order to perform it. This could equally apply to a command input text area in a GUI program. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1024446: ITP: libstring-tagged-terminal-perl -- module to format terminal output using String::Tagged
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libstring-tagged-terminal-perl Version : 0.05 Upstream Author : Paul Evans * URL : https://metacpan.org/release/String-Tagged-Terminal * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to format terminal output using String::Tagged String::Tagged::Terminal is subclass of String::Tagged and provides a method, build_terminal, for outputting the formatting tags embedded in the string as terminal escape sequences, to render the output in the appropriate style. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1024084: tar: missing licenses
user debian-rele...@lists.debian.org usertag 1024084 + bsp-2022-11-nl-tilburg thank you -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F
Bug#1024445: ITP: gokrb5 -- Pure Go Kerberos library for clients and services
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: golang-github-jcmturner-gokrb5 Version : 8.4.3-1 Upstream Author : Jonathan Turner * URL : https://github.com/jcmturner/gokrb5 * License : Apache-2.0 Programming Lang: Go Description : Pure Go Kerberos library for clients and services * Server Side * HTTP handler wrapper implements SPNEGO Kerberos authentication * HTTP handler wrapper decodes Microsoft AD PAC authorization data * Client Side * Client that can authenticate to an SPNEGO Kerberos authenticated web service * Ability to change client's password * General * Kerberos libraries for custom integration * Parsing Keytab files * Parsing krb5.conf files * Parsing client credentials cache files such as /tmp/krb5cc_$(id -u $(whoami)) v5 of this package is already available in golang-gopkg-jcmturner-gokrb5.v5-dev but the latest version of rclone requires gokrb5 v8. This package is intended to provide the latest version of gokrb5 (without using a -v version tag) To be maintained by the Debian Go Team.
Bug#1024437: rust-fragile: please upgrade to v2
Quoting Jonas Smedegaard (2022-11-19 14:06:02) > Please upgrade to newer upstream branch v2. This should possibly only be done in concert with fixing bug#1020409, as the need is for gst-plugin-gtk4 v0.9: https://lib.rs/crates/gst-plugin-gtk4/versions - 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#1024444: spamd: systemd hardening flags prevents bayes access to per-user dirs
Package: spamd Version: 4.0.0~rc3-3 Severity: important X-Debbugs-Cc: none, Michael Welsh Duggan Dear Maintainer, The addition of the ProtectSystem=full clause to the spamd service module prevents spamd from writing to user bayes files. Here is a log from spamd: -- Nov 19 10:19:04 maru2 spamd[1992427]: spamd: connection from 192.168.177.3 [192. 168.177.3]:46636 to port 783, fd 6 Nov 19 10:19:04 maru2 spamd[1992427]: spamd: connection from 192.168.177.3 [192. 168.177.3]:46636 to port 783, fd 6 Nov 19 10:19:04 maru2 spamd[1992427]: spamd: setuid to md5i succeeded Nov 19 10:19:04 maru2 spamd[1992427]: spamd: setuid to md5i succeeded Nov 19 10:19:04 maru2 spamd[1992427]: plugin: eval failed: bayes: (in learn) loc ker: safe_lock: cannot create tmp lockfile /home/md5i/.spamassassin/bayes.lock.m aru2.md5i.com.1992427 for /home/md5i/.spamassassin/bayes.lock: Read-only file sy stem Nov 19 10:19:04 maru2 spamd[1992427]: plugin: eval failed: bayes: (in learn) loc ker: safe_lock: cannot create tmp lockfile /home/md5i/.spamassassin/bayes.lock.m aru2.md5i.com.1992427 for /home/md5i/.spamassassin/bayes.lock: Read-only file sy stem Nov 19 10:19:04 maru2 spamd[1992427]: spamd: Tell: Did nothing for md5i:1000 in 0.0 seconds, 1124 bytes Nov 19 10:19:04 maru2 spamd[1992427]: spamd: Tell: Did nothing for md5i:1000 in 0.0 seconds, 1124 bytes Nov 19 10:19:04 maru2 spamd[1992427]: plugin: eval failed: bayes: (in learn) loc ker: safe_lock: cannot create tmp lockfile /home/md5i/.spamassassin/bayes.lock.m aru2.md5i.com.1992427 for /home/md5i/.spamassassin/bayes.lock: Read-only file sy stem Nov 19 10:19:04 maru2 spamd[1992415]: prefork: child states: II Nov 19 10:19:04 maru2 spamd[1992415]: prefork: child states: II -- Removing the ProtectSystem=full clause causes this to work again. I do not know is removing this clause is the correct fix or adding a form of ReadWritePaths is correct. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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 spamd depends on: ii init-system-helpers 1.65.2 ii rsyslog [system-log-daemon] 8.2208.0-1 ii spamassassin 4.0.0~rc3-3 ii systemd 251.5-1 spamd recommends no packages. spamd suggests no packages. -- Configuration Files: /etc/default/spamd changed: OPTIONS="--create-prefs --max-children 5 --helper-home-dir --allow-tell --listen=* --allowed-ips=192.168.177.3,127.0.0.1,::1" PIDFILE="/var/run/spamd.pid" -- no debconf information -- Michael Welsh Duggan (m...@md5i.com)
Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup
I am also experiencing this, using the latest linux-image-6.0.0-4-amd64 -- *Thomas van Gulick* tho...@van.gulick.nl Telegram: http://t0mm1e.t.me WhatsApp: http://wa.me/31651202680 Messenger: http://m.me/t0mm1e
Bug#1024084: tar: missing licenses
user debian-rele...@lists.debian.org usertag 1024084 + bsp-2022-11-nl-tilburg thank you -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F
Bug#1024425: [Debian-med-packaging] Bug#1024425: python-pysam: FTBFS with Python 3.11 as a supported version
Control: forwarded -1 https://github.com/pysam-developers/pysam/issues/1151 Hi Graham, Graham Inggs, on 2022-11-19: > python-pysam FTBFS during the recent rebuild adding Python 3.11 as a > supported version [1]. Thanks for the notice, I informed upstream as my own investigations did not allow me to tell whether this would come for the module itself, or from the interpreter (or from something else I might have missed). Will see how it goes; if nothing, it will still be possible to stick to python3.10 for Debian 12 I guess. Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/5, please excuse my verbosity. signature.asc Description: PGP signature
Bug#1024346: cdrom: debian-11.5.0-amd64-netinst.iso boots to Grub CLI on Dell Optiplex 5090
Thanks, after messing with it for quite awhile, I finally got it to work with the standard ISO. I booted with the Arch live image and did: wipefs -a /dev/nvme0n1 dd if=/dev/zero of=/dev/nvme0n1 bs=512 count=10 then I used efibootmgr to delete all existing entries. Once I did that, the netinst booted into the installer immediately. Not sure if it was the actual existence of valid partitions on the drive, or just the existence of EFI entries in the table. I can further test to see which scenario it is. I would still consider this a bug? --- Original Message --- On Saturday, November 19th, 2022 at 07:48, Andrew M.A. Cater wrote: > > > Rob - see below, you might want to subscribe to the bug too. > > Suggestion is to use firmware .iso and a more verbose dd line to ensure > you've actually written the whole image correctly. > > Also, I would suggest enabling TPM and secure boot unless you are absolutely > sure that you don't need them. Secure boot is well supported in Debian. > > Hope this helps, > > Andy Cater > > On Fri, Nov 18, 2022 at 08:33:29PM +0100, Franco Martelli wrote: > > > On 17/11/22 at 23:11, Andrew M.A. Cater wrote: > > > > > On Thu, Nov 17, 2022 at 04:46:30PM -0500, Rob Klingsten wrote: > > > > > > > Package: cdrom > > > > Severity: important > > > > Tags: d-i > > > > > > > > Dear Maintainer, > > > > > > > > *** Reporter, please consider answering these questions, where > > > > appropriate *** > > > > > > > > * What led up to the situation? > > > > * What exactly did you do (or not do) that was effective (or > > > > ineffective)? > > > > * What was the outcome of this action? > > > > * What outcome did you expect instead? > > > > > > > > *** End of the template - remove these template lines *** > > > > > > > > Downloaded debian-11.5.0-amd64-netinst.iso, verified SHA512 signature > > > > and flashed to USB stick (dd if= of=/dev/sdb). The > > > > Dell Optiplex 5090 is a UEFI-only system. In the BIOS, I previously > > > > disabled TPM, Secure Boot and Absolute (computer Lojack). > > > > > > > > Booting from the netinst USB stick, the computer boots into the Grub > > > > CLI. 'ls' shows the following: > > > > > > > > (proc) (hd0) (hd0,gpt4) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (cd0) > > > > (cd0,msdos2) > > > > > > > > There does not appear to be any usable partition detected on the USB > > > > stick that contains a kernel. The contents of (cd0,msdos2) are > > > > just an 'efi' directory. > > > > > > > > I have tried multiple USB sticks, downloaded the ISO several times all > > > > with a good SHA512, tried dd and also cp /dev/sdb, makes > > > > no difference. I've tried the live Gnome image as well, same problem. > > > > > > > > I expect the computer to boot properly into the Debian installer. > > > > > > First of all: > > > > > > It may be better to use a longer dd line and also to use the unofficial > > > firmware image available at > > > https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.5.0+nonfree/amd64/iso-cd/firmware-11.5.0-amd64-netinst.iso > > > > > > dd if=firmware-11.5.0-amd64-netinst.iso of=/dev/sdb bs=4M oflag=sync > > > status=progress > > > > > > That makes absolutely sure that the transfer is synced to ensure that it > > > is > > > written to the stick and also gives you some idea of how well the transfer > > > is going. > > > > > > Using the firmware .iso will potentially solve any problems with missing > > > firmwware. > > > > > > The writing to a stick should work well. > > > > > > All the very best, as ever, > > > > > > Andy Cater > > > > I'm not sure but maybe Rob Klingsten is not on the list so I'm not sure that > > he has read your reply please consider to re-send your answer to > > 1024...@bugs.debian.org > > > > kind regards > > -- > > Franco Martelli
Bug#1024443: asterisk-modules no longer includes chan_sip which breaks existing configs
Package: asterisk-modules Version: 1:20.0.0~dfsg+~cs6.12.40431414-2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: james.bottom...@hansenpartnership.com The package asterisk-module no longer contains chan_sip.so which means that all existing SIP configuration with chan_sip stop functioning. I realise a migration to chan_pjsip is eventually required, but that requires at least notice of when chan_sip will be deprecated This actually seems to be a simple configuration error. chan_sip can be built by adding it to ADDONS_ENABLE in debian/rules -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages asterisk-modules depends on: ii libc-client2007e 8:2007f~dfsg-7+b2 ii libc6 2.36-5 ii libcodec2-1.0 1.0.5-1 ii libcurl4 7.86.0-1 ii libglib2.0-0 2.74.1-2 ii libgmime-3.0-03.2.13+dfsg-2 ii libgsm1 1.0.22-1 ii libical3 3.0.16-1+b1 ii libiksemel3 1.4-4 ii libjack0 [libjack-0.125] 1:0.126.0-1 ii libldap-2.5-0 2.5.13+dfsg-2+b1 ii liblua5.2-0 5.2.4-2 ii libneon27 0.32.4-1 ii libodbc2 2.3.11-2 ii libogg0 1.3.5-1 ii libopencore-amrnb00.1.6-1 ii libopencore-amrwb00.1.6-1 ii libopusfile0 0.12-2 ii libportaudio2 19.6.0-1.2 ii libpq515.1-1 ii libradcli41.2.11-1+b2 ii libresample1 0.1.3-5 ii libsnmp40 5.9.3+dfsg-1+b2 ii libspandsp2 0.0.6+dfsg-2 ii libspeex1 1.2.1-1 ii libspeexdsp1 1.2.1-1 ii libsqlite3-0 3.39.4-1 ii libsrtp2-12.4.2-3 ii libssl3 3.0.7-1 ii libsybdb5 1.3.6-1.1 ii libunbound8 1.17.0-1 ii libvo-amrwbenc0 0.1.3-2 ii libvorbis0a 1.3.7-1 ii libvorbisenc2 1.3.7-1 ii libvorbisfile31.3.7-1 ii libxml2 2.9.14+dfsg-1.1+b2 ii zlib1g1:1.2.11.dfsg-4.1 asterisk-modules recommends no packages. asterisk-modules suggests no packages. -- no debconf information
Bug#1024442: ITP: hdfs -- A native go client for HDFS
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: golang-github-colinmarc-hdfs Version : 2.3.0-1 Upstream Author : Colin Marc * URL : https://github.com/colinmarc/hdfs * License : Expat Programming Lang: Go Description : A native go client for HDFS This is a native golang client for hdfs. It connects directly to the namenode using the protocol buffers API. . It tries to be idiomatic by aping the stdlib os package, where possible, and implements the interfaces from it, including os.FileInfo and os.PathError. . Along with the library, this repo contains a commandline client for HDFS. Like the library, its primary aim is to be idiomatic, by enabling your favorite unix verbs: Required by the latest version of rclone. To be maintained by the Debian Go Team.
Bug#1024434: osslsigncode: Fails to sign code with pkcs12
On Sat, 19 Nov 2022 14:59:57 +0100, Stefan Weil wrote: > Am 19.11.22 um 14:03 schrieb Stephen Kitt: > > Since you have a working build, could you run ldd on it and reply with the > > result? > [...] > > That differs from the non-working one which does not use > libcrypto.so.1.1 (that's the only difference). > > It looks like libcrypto.so.1.1 is essential: after libssl1.1 (which > provides libcrypto.so.1.1) was uninstalled, a fresh build also produces > a failing osslsigncode. > > So it works with libssl1, but not with libssl3. Thanks! This is an upstream bug: https://github.com/mtrojnar/osslsigncode/issues/178 libssl1.1 is no longer available for packages to build against, so we’ll have to wait for an upstream fix. Regards, Stephen pgp5ieSH2z7XQ.pgp Description: OpenPGP digital signature
Bug#1024434: osslsigncode: Fails to sign code with pkcs12
I could now debug the code and at least see which function fails: PKCS12_parse failed with error:0308010C:digital envelope routines::unsupported. libssl3 no longer provides support by default for some old and unsecure algorithms. Such algorithms can be loaded by function OSSL_PROVIDER_load or by adding the right "providers" to the configuration of libssl. I tried that, but failed so far. Maybe Sebastian (cc'ed) can help. Stefan
Bug#1024441: python-jsonschema: New upstream version 4.17.0 available
Source: python-jsonschema Version: 4.7.2-3 Severity: wishlist X-Debbugs-Cc: car...@debian.org Hi There is a new upstream version available for python-jsonschema. Can you please package it to unstable? Thanks in advance, Regards, Salvatore
Bug#1023876: linux-image-5.19.0-0.deb11.2-amd64: infinite loop whit RAID1 when shutting down
Em sáb., 19 de nov. de 2022 às 11:36, Salvatore Bonaccorso
escreveu:
>
> Hi
>
> On Fri, Nov 11, 2022 at 06:33:23PM -0300, Joao Eriberto Mota Filho wrote:
> > Package: src:linux
> > Version: 5.19.11-1~bpo11+1
> > Severity: important
> >
> > Dear maintainer,
> >
> > I have a desktop with 3 polls over RAID1 (2 SSD, 2 HDD, plus 2 SSD). The
> > current kernel on BPO creates an infinite loop when shutting down the
> > system. I
> > can see several messages like:
> >
> > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > systemd-shutdown[1]: Stopping MD devices.
> > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > md: md2 stopped.
> > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > systemd-shutdown[1]: Stopping MD devices.
> > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > md: md2 stopped.
> > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > systemd-shutdown[1]: Stopping MD devices.
> > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > md: md2 stopped.
> > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > systemd-shutdown[1]: Stopping MD devices.
> > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > [...]
> > block device autoloading is deprecated and will be removed
> > block device autoloading is deprecated and will be removed
> > block device autoloading is deprecated and will be removed
> > block device autoloading is deprecated and will be removed
> > block device autoloading is deprecated and will be removed
> > block device autoloading is deprecated and will be removed
> > block device autoloading is deprecated and will be removed
> > block device autoloading is deprecated and will be removed
> > [...]
> > md: md2 stopped.
> > md: md2 stopped.
> > md: md2 stopped.
> > md: md2 stopped.
> > md: md2 stopped.
> > md: md2 stopped.
> > md: md2 stopped.
> > [...]
> > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > systemd-shutdown[1]: Stopping MD devices.
> > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > md: md2 stopped.
> > systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> > systemd-shutdown[1]: Stopping MD devices.
> > systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> > md: md2 stopped.
> > [...]
> >
> > There is a solution from Arch Linux[1]:
> >
> > "Arch disabled BLOCK_LEGACY_AUTOLOAD for 5.18 which broke mdraid".
> >
> > [1] https://bbs.archlinux.org/viewtopic.php?id=279383
> >
> > Please, consider disabling the deprecated BLOCK_LEGACY_AUTOLOAD, enabled by
> > default in current kernel on Debian:
> >
> > $ cat /boot/config-5.19.0-0.deb11.2-amd64 | grep BLOCK_LEGACY_AUTOLOAD
> > CONFIG_BLOCK_LEGACY_AUTOLOAD=y
> >
> > Thanks in advance.
>
> I'm not sure, can we can do that (yet)? Some context about this is in
> https://lore.kernel.org/all/yhe%2fc0k0fn9j8...@bombadil.infradead.org/
> . In fact back for 5.18-rc1 upstream has weakened the removal schedule
> for block device autoloading and with 451f0b6f4c44 ("block: default
> BLOCK_LEGACY_AUTOLOAD to y")[1].
>
> Initially it was planned to make it for 5.19, see fbdee71bb5d8
> ("block: deprecate autoloading based on dev_t")[2].
>
> [1]: https://git.kernel.org/linus/451f0b6f4c44d7b649ae609157b114b71f6d7875
> [2]: https://git.kernel.org/linus/fbdee71bb5d8d054e1bdb5af4c540f2cb86fe296
>
> Regards,
> Salvatore
Thanks for the clarification Salvatore. Currently, this is a nightmare
for me because I am being compelled to power off my computer via the
energy switch.
Regards,
Eriberto
Bug#1024353: asterisk: segfault with the latest security update
Am Samstag, dem 19.11.2022 um 16:14 +0400 schrieb sergio: > On 18/11/2022 17:32, Markus Koschany wrote: > > > thanks for reporting. I wonder if the segfault is related to the extra > > package > > asterisk-opus. What happens if you remove this package and start asterisk > > without it? > > Commeting out codec_opus_open_source, format_ogg_opus_open_source and > format_vp8 > in modules.conf (autoload=no) changes nothing. I believe the problem here is that the opus codec is embedded in Asterisk itself now and asterisk-opus conflicts with the new setup. Did you remove asterisk-opus as well? > > all debug files > > How to get them? I have a dumped core file, is it enough? https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information I need more details how you trigger the segfault, a step by step explanation, because I cannot reproduce the problem with a new installation of Asterisk. You have to turn on verbose or debug logging and send me your log files. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1023876: linux-image-5.19.0-0.deb11.2-amd64: infinite loop whit RAID1 when shutting down
Hi
On Fri, Nov 11, 2022 at 06:33:23PM -0300, Joao Eriberto Mota Filho wrote:
> Package: src:linux
> Version: 5.19.11-1~bpo11+1
> Severity: important
>
> Dear maintainer,
>
> I have a desktop with 3 polls over RAID1 (2 SSD, 2 HDD, plus 2 SSD). The
> current kernel on BPO creates an infinite loop when shutting down the system.
> I
> can see several messages like:
>
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> md: md2 stopped.
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> md: md2 stopped.
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> md: md2 stopped.
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> [...]
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> block device autoloading is deprecated and will be removed
> [...]
> md: md2 stopped.
> md: md2 stopped.
> md: md2 stopped.
> md: md2 stopped.
> md: md2 stopped.
> md: md2 stopped.
> md: md2 stopped.
> [...]
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> md: md2 stopped.
> systemd-shutdown[1]: Not all MD devices stopped. 1 left.
> systemd-shutdown[1]: Stopping MD devices.
> systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
> md: md2 stopped.
> [...]
>
> There is a solution from Arch Linux[1]:
>
> "Arch disabled BLOCK_LEGACY_AUTOLOAD for 5.18 which broke mdraid".
>
> [1] https://bbs.archlinux.org/viewtopic.php?id=279383
>
> Please, consider disabling the deprecated BLOCK_LEGACY_AUTOLOAD, enabled by
> default in current kernel on Debian:
>
> $ cat /boot/config-5.19.0-0.deb11.2-amd64 | grep BLOCK_LEGACY_AUTOLOAD
> CONFIG_BLOCK_LEGACY_AUTOLOAD=y
>
> Thanks in advance.
I'm not sure, can we can do that (yet)? Some context about this is in
https://lore.kernel.org/all/yhe%2fc0k0fn9j8...@bombadil.infradead.org/
. In fact back for 5.18-rc1 upstream has weakened the removal schedule
for block device autoloading and with 451f0b6f4c44 ("block: default
BLOCK_LEGACY_AUTOLOAD to y")[1].
Initially it was planned to make it for 5.19, see fbdee71bb5d8
("block: deprecate autoloading based on dev_t")[2].
[1]: https://git.kernel.org/linus/451f0b6f4c44d7b649ae609157b114b71f6d7875
[2]: https://git.kernel.org/linus/fbdee71bb5d8d054e1bdb5af4c540f2cb86fe296
Regards,
Salvatore
Bug#1023413: dh-cargo: should prevent dh_clean from removing Cargo.toml.orig
On Thu, 03 Nov 2022 12:13:43 -0400 Daniel Kahn Gillmor
wrote:
Package: dh-cargo
Version: 28
Control: affects -1 debhelper src:rust-document-features debcargo
Hi,
When packaging Rust crates, the rust-team typically packages from the
bundles published on crates.io. Those are published with a modified
version of Cargo.toml, and the original upstream source for Cargo.toml
is present as Cargo.toml.orig.
debhelper's dh_clean by default removes all files matching *.orig, which
means that the upstream Cargo.toml.orig is getting stripped before the
build happens. (dh_clean is typically invoked before a build)
Would it be possible to use a different name for it (like
Cargo.toml.upstream or even Cargo.toml.original)? Something that
dh_clean does not remove by default?
This is problematic for tools like the document-features crate, which
relies on comments in Cargo.toml.orig to extract documention about the
features of any given crate.
See the upstream discussion at
https://github.com/slint-ui/document-features/issues/15
If dh-cargo were able to force the exclusion Cargo.toml.orig, that would
be great, but i tried hacking on the clean() function in cargo.pm to
push something into @{dh{EXCLUDE}} and i couldn't get it to work. Maybe
someone who knows debhelper or dh-cargo better than me can figure out
how to do it.
In theory, a dh addon *can* add an option to dh_clean by default (i.e.,
if dh_clean is not overridden). That said, it does mean that the
sequence can no longer be conditional (e.g., only used in
Build-Depends-Arch).
Or, maybe a newer version of debhelper itself could just generically
avoid destroying Cargo.toml.orig in the top-level of any source tree,
even though it removes all the other *.orig files ?
Special-casing Cargo.toml.orig also feels weird to me. But also, I do
not want every language special-case to cascade into "core" debhelper -
then debhelper becomes an unmaintainable soup of random things I cannot
keep track (like are they still relevant).
[...]
If the dh-cargo folks think it should be fixed in either debhelper or
debcargo, feel free to reassign this bug report.
Thanks,
--dkg
The removal of .orig is been around for ages (to support cleaning up
after patches with merge conflicts). I am not inclined to remove that
from debhelper.
I hope we can use another name for the file or that dh-cargo can handle
the special-casing via a debhelper add-on.
Thanks,
~Niels
Bug#1024440: Debian Bookworm no sound
Package: firmware-sof-signed Version: 2.2.2-1 Dear Maintainer: I downloaded firmware-sof-signed 2.2.2-1 with apt, but it doesn't work, the earphone is not recognized. $ sudo dmesg | egrep "audio|sof|snd" [0.036269] software IO TLB: area num 4. [0.454014] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [0.454015] software IO TLB: mapped [mem 0x6a17f000-0x6e17f000] (64MB) [3.747683] snd_hda_intel :00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 [4.282577] sof-audio-pci-intel-icl :00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 [4.282687] sof-audio-pci-intel-icl :00:1f.3: enabling device ( -> 0002) [4.283011] sof-audio-pci-intel-icl :00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100 [4.290212] sof-audio-pci-intel-icl :00:1f.3: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [4.297501] sof-audio-pci-intel-icl :00:1f.3: use msi interrupt mode [4.328142] sof-audio-pci-intel-icl :00:1f.3: NHLT_DEVICE_I2S detected, ssp_mask 0x1 [4.328152] sof-audio-pci-intel-icl :00:1f.3: hda codecs found, mask 4 [4.329737] sof-audio-pci-intel-icl :00:1f.3: firmware: direct-loading firmware intel/sof/sof-jsl.ri [4.329753] sof-audio-pci-intel-icl :00:1f.3: Firmware info: version 2:2:0-57864 [4.329756] sof-audio-pci-intel-icl :00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0 [4.329763] sof-audio-pci-intel-icl :00:1f.3: unknown sof_ext_man header type 3 size 0x30 [4.435634] sof-audio-pci-intel-icl :00:1f.3: Firmware info: version 2:2:0-57864 [4.435640] sof-audio-pci-intel-icl :00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0 $ lspci | grep audio 00:1f.3 Multimedia audio controller: Intel Corporation Jasper Lake HD Audio (rev 01) $ aplay -l aplay: device_list:275: no soundcards found... I'm still in "/etc/modprobe.d/alsa-base.conf" file attempts "options snd-intel-dspcfg dsp_driver=1" and "options snd-intel-dspcfg dsp_driver=3" options, no sound. any advise is welcome! thanks Debian Release: Bookworm Architecture: amd64 (x86_64) Kernel: Linux6.0.8-1 Desktop: Gnome43.1
