Bug#1032177: faketime doesn't fake time (on i386)
On Wed, Mar 01, 2023 at 08:30:12AM +0100, Jakub Wilk wrote: > Package: faketime > Version: 0.9.10-2.1 > Severity: grave > > faketime no longer works on i386: > >$ faketime -f '2008-12-24 08:15:42' date -R >Wed, 01 Mar 2023 08:25:58 +0100 The reason here is that date uses __clock_gettime64() (i.e. the 64-bit time_t variant of clock_gettime) while libfaketime doesn't provide an override for this symbol and so the result isn't faked. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1064555: faketime: FTBFS on 32 bit architectures: Test Suites summary: 3 succeeded, 1 failed
On Sat, Feb 24, 2024 at 09:59:48AM +0100, Sebastian Ramacher wrote: > Source: faketime > Version: 0.9.10-2.1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: sramac...@debian.org > > https://buildd.debian.org/status/fetch.php?pkg=faketime=armel=0.9.10-2.1%2Bb1=1704500126=0 > > gcc -c -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong > -fstack-clash-protection -Wformat -Werror=format-security -DMULTI_ARCH > -DFAKE_RANDOM -DFAKE_PID -std=gnu99 -Wall -DFAKE_STAT -Werror -Wextra > timetest.c > ./testframe.sh functests > # Begin Test Suites in functests > > # Begin functests/test_exclude_mono.sh > # PLATFORM=linuxlike > gcc -o timetest timetest.o -Wl,-z,relro -Wl,-z,now -lrt -lpthread > out=193535.427098546 When not faking monotonic time, timestamps should be > different ref=193536.51863104 - ok > # functests/test_exclude_mono.sh summary: 1 succeeded, 0 failed > # End functests/test_exclude_mono.sh - OK When building faketime on armhf and then run make test this results in: ... # Begin Test Suites in functests # Begin functests/test_exclude_mono.sh # PLATFORM=linuxlike *** stack smashing detected ***: terminated ... The command that is run there is (a bit simplified): $ LD_PRELOAD=src/libfaketime.so.1 /bin/bash -c 'perl -w -MTime::HiRes=clock_gettime,CLOCK_MONOTONIC -E '\''say clock_gettime(CLOCK_MONOTONIC)'\''; ' *** stack smashing detected ***: terminated Aborted The same happens with $ LD_PRELOAD=src/libfaketime.so.1 /bin/bash -c 'true' *** stack smashing detected ***: terminated Aborted I think that's because bash still uses 32bit time_t and calls gettimeofday from libc (which on armhf uses 32bit time_t) but the gettimeofday that it MITMed by libfaketime.so.1 uses 64bit time_t and so writes to a bigger memory chunk than is handed in by bash's struct timeval *tv. So to get it right faketime must be made aware that on platforms that have __gettimeofday64 in libc gettimeofday uses 32bit time_t. (And the same on various other functions.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1060584: rauc: Please switch Build-Depends to systemd-dev
On Mon, Jan 22, 2024 at 12:37:13PM +0100, Michael Biebl wrote: > Am 22.01.24 um 12:09 schrieb Uwe Kleine-König: > > On Thu, Jan 11, 2024 at 11:36:53PM +0100, bi...@debian.org wrote: > > > Source: rauc > > > Version: 1.11-1 > > > Severity: normal > > > User: pkg-systemd-maintain...@lists.alioth.debian.org > > > Usertags: systemd-dev > > > > > > your package rauc declares a Build-Depends on systemd and/or udev. > > > > Since version 1.10.1-2 rauc build-depends on: > > > > systemd, systemd-dev | systemd (<< 254.1-3~) > > > > Is it deliberate, that you kept the Build-Depends on the "full" systemd > package, i.e. do you need resources from systemd during build other than > udev.pc/systemd.pc? I thought there was a reason to keep it. Just dropping systemd doesn't result in a build problem. I'll have to investigate that. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#991259: b4: fails with dns.exception.Timeout
Hello Ricardo, On 14.01.24 23:42, Ricardo Ribalda wrote: Since version 0.7, b4 does not use its own dnsfunc, and does not crashes on DNS errors... Could you try with your ISP DNS using the latest version of b4 in the Debian tree? It seems my ISP fixed their DNS server and reply to TCP queries, so I cannot (easily and) reliably test if the problem is gone. I willing to believe you that b4 improved here, so feel free to close the bug. Best regards Uwe
Bug#1042646: dh-virtualenv: FTBFS with Sphinx 7.1, docutils 0.20: error: invalid command 'build_sphinx'
Hello,
to make the package build in a buildd chroot some more adaptions are
needed:
- Depend on python3-docutils (which was pulled in before by
python3-sphinx)
- Drop debian/dh-virtualenv.doc-base as the documentation is missing
now
- Don't call dh with --with sphinxdoc
The complete deb diff now is:
dpkg-source: warning: extracting unsigned source package
(/home/uwe/debsrc/dh-virtualenv_1.2.2-1.4.dsc)
diff -Nru dh-virtualenv-1.2.2/debian/changelog
dh-virtualenv-1.2.2/debian/changelog
--- dh-virtualenv-1.2.2/debian/changelog2023-02-02 20:10:21.0
+0100
+++ dh-virtualenv-1.2.2/debian/changelog2023-11-17 19:40:18.0
+0100
@@ -1,3 +1,10 @@
+dh-virtualenv (1.2.2-1.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop Sphinx docs (Closes: #1042646)
+
+ -- Uwe Kleine-König Fri, 17 Nov 2023 19:40:18 +0100
+
dh-virtualenv (1.2.2-1.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru dh-virtualenv-1.2.2/debian/control dh-virtualenv-1.2.2/debian/control
--- dh-virtualenv-1.2.2/debian/control 2022-08-25 21:00:57.0 +0200
+++ dh-virtualenv-1.2.2/debian/control 2023-11-17 19:40:18.0 +0100
@@ -2,26 +2,24 @@
Section: python
Priority: optional
Maintainer: Jyrki Pulliainen
-Build-Depends: debhelper-compat (= 12), python3,
- python3-setuptools, python3-sphinx, python3-mock, dh-exec,
- dh-python, libjs-jquery, libjs-underscore,
-# python-sphinx-rtd-theme doesn't exist in distributions
-# predating Debian Jessie and Ubuntu Xenial. On these legacy
-# systems:
-# 1. Comment the dependency below.
-# 2. pip install sphinx_rtd_theme.
-# 3. Proceed with your build process (typically dpkg-build).
-# See https://github.com/spotify/dh-virtualenv/issues/230
- python3-sphinx-rtd-theme
+Build-Depends:
+ debhelper-compat (= 12),
+ python3,
+ python3-docutils,
+ python3-setuptools,
+ python3-mock,
+ dh-exec,
+ dh-python,
+ libjs-jquery,
+ libjs-underscore,
Standards-Version: 4.5.0
Homepage: https://www.github.com/spotify/dh-virtualenv
Rules-Requires-Root: no
Package: dh-virtualenv
Architecture: all
-Depends: ${python3:Depends}, ${perl:Depends}, ${misc:Depends},
${sphinxdoc:Depends},
+Depends: ${python3:Depends}, ${perl:Depends}, ${misc:Depends},
virtualenv | python3-virtualenv (>= 1.7) | python${pyversion}-venv
-Built-Using: ${sphinxdoc:Built-Using}
Description: wrap and build Python packages using virtualenv
This package provides a dh sequencer that helps you to deploy your
virtualenv wrapped installation inside a Debian package.
diff -Nru dh-virtualenv-1.2.2/debian/dh-virtualenv.doc-base
dh-virtualenv-1.2.2/debian/dh-virtualenv.doc-base
--- dh-virtualenv-1.2.2/debian/dh-virtualenv.doc-base 2022-08-25
21:00:57.0 +0200
+++ dh-virtualenv-1.2.2/debian/dh-virtualenv.doc-base 1970-01-01
01:00:00.0 +0100
@@ -1,9 +0,0 @@
-Document: dh-virtualenv
-Title: dh-virtualenv documentation
-Author: Spotify
-Abstract: This manual describes dh-virtualenv and how to use it.
-Section: Programming
-
-Format: HTML
-Index: /usr/share/doc/dh-virtualenv/html/index.html
-Files: /usr/share/doc/dh-virtualenv/html/*.html
diff -Nru dh-virtualenv-1.2.2/debian/rules dh-virtualenv-1.2.2/debian/rules
--- dh-virtualenv-1.2.2/debian/rules2022-08-25 21:00:57.0 +0200
+++ dh-virtualenv-1.2.2/debian/rules2023-11-17 19:40:18.0 +0100
@@ -1,9 +1,6 @@
#!/usr/bin/make -f
DH_ARGS ?=
-ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
- DH_ARGS += --with sphinxdoc
-endif
PYTHON_VERSION := $(shell python3 -c 'import sys; print("%s.%s" %
sys.version_info[:2])')
@@ -22,9 +19,3 @@
override_dh_gencontrol:
dh_gencontrol -- -Vpyversion=$(PYTHON_VERSION)
-
-ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
-override_dh_installdocs:
- python3 setup.py build_sphinx
- dh_installdocs doc/_build/html
-endif
I'll upload that to DELAYED/7 after sending this mail.
Best regards
Uwe
signature.asc
Description: PGP signature
Bug#1042646: dh-virtualenv: FTBFS with Sphinx 7.1, docutils 0.20: error: invalid command 'build_sphinx'
On Sun, Jul 30, 2023 at 08:22:59PM +0200, Lucas Nussbaum wrote:
> Source: dh-virtualenv
> Version: 1.2.2-1.3
> Severity: important
> Tags: ftbfs
> User: python-modules-t...@lists.alioth.debian.org
> Usertags: sphinx7.1
>
> Hi,
>
> dh-virtualenv fails to build with Sphinx 7.1 and docutils 0.20, both of which
> are currently available in experimental.
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > python3 setup.py build_sphinx
> > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
> >or: setup.py --help [cmd1 cmd2 ...]
> >or: setup.py --help-commands
> >or: setup.py cmd --help
> >
> > error: invalid command 'build_sphinx'
> > make[1]: *** [debian/rules:28: override_dh_installdocs] Error 1
This bug resulted in dh-virtualenv being dropped from trixie.
The easy workaround is to drop the sphinx documentation.
The following debdiff makes the package build again:
dpkg-source: warning: extracting unsigned source package
(/home/uwe/debsrc/dh-virtualenv_1.2.2-1.4.dsc)
diff -Nru dh-virtualenv-1.2.2/debian/changelog
dh-virtualenv-1.2.2/debian/changelog
--- dh-virtualenv-1.2.2/debian/changelog2023-02-02 20:10:21.0
+0100
+++ dh-virtualenv-1.2.2/debian/changelog2023-11-17 19:40:18.0
+0100
@@ -1,3 +1,10 @@
+dh-virtualenv (1.2.2-1.4) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop Sphinx docs (Closes: #1042646)
+
+ -- Uwe Kleine-König Fri, 17 Nov 2023 19:40:18 +0100
+
dh-virtualenv (1.2.2-1.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru dh-virtualenv-1.2.2/debian/control dh-virtualenv-1.2.2/debian/control
--- dh-virtualenv-1.2.2/debian/control 2022-08-25 21:00:57.0 +0200
+++ dh-virtualenv-1.2.2/debian/control 2023-11-17 19:40:18.0 +0100
@@ -3,25 +3,16 @@
Priority: optional
Maintainer: Jyrki Pulliainen
Build-Depends: debhelper-compat (= 12), python3,
- python3-setuptools, python3-sphinx, python3-mock, dh-exec,
+ python3-setuptools, python3-mock, dh-exec,
dh-python, libjs-jquery, libjs-underscore,
-# python-sphinx-rtd-theme doesn't exist in distributions
-# predating Debian Jessie and Ubuntu Xenial. On these legacy
-# systems:
-# 1. Comment the dependency below.
-# 2. pip install sphinx_rtd_theme.
-# 3. Proceed with your build process (typically dpkg-build).
-# See https://github.com/spotify/dh-virtualenv/issues/230
- python3-sphinx-rtd-theme
Standards-Version: 4.5.0
Homepage: https://www.github.com/spotify/dh-virtualenv
Rules-Requires-Root: no
Package: dh-virtualenv
Architecture: all
-Depends: ${python3:Depends}, ${perl:Depends}, ${misc:Depends},
${sphinxdoc:Depends},
+Depends: ${python3:Depends}, ${perl:Depends}, ${misc:Depends},
virtualenv | python3-virtualenv (>= 1.7) | python${pyversion}-venv
-Built-Using: ${sphinxdoc:Built-Using}
Description: wrap and build Python packages using virtualenv
This package provides a dh sequencer that helps you to deploy your
virtualenv wrapped installation inside a Debian package.
diff -Nru dh-virtualenv-1.2.2/debian/rules dh-virtualenv-1.2.2/debian/rules
--- dh-virtualenv-1.2.2/debian/rules2022-08-25 21:00:57.0 +0200
+++ dh-virtualenv-1.2.2/debian/rules2023-11-17 19:39:38.0 +0100
@@ -22,9 +22,3 @@
override_dh_gencontrol:
dh_gencontrol -- -Vpyversion=$(PYTHON_VERSION)
-
-ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
-override_dh_installdocs:
- python3 setup.py build_sphinx
- dh_installdocs doc/_build/html
-endif
I intend to nmu this package in a week from now with the above changes.
Best regards
Uwe
signature.asc
Description: PGP signature
Bug#1055529: pdns-server: Spams journal after installation because it is configured to automatically restart
Hello Chris, On 11/11/23 01:20, Chris Hofstaedtler wrote: * Uwe Kleine-König [231107 22:06]: on installation of pdns-server the pdns.service is automatically started. However in my case port 53 is already bound and so it fails to start. (That might also happen if port 53 isn't blocked because the default config isn't suitable to successfully run pdns? I didn't check.) [..] to the journal. If you don't notice this immediately and stop the service this effectively spams your journal in a very short time. IMHO the above mentioned settings are not suitable as a default for a distribution's package even if the default configuration worked. It should be an administrator's choice to configure such a behaviour. I respectfully disagree. If users have pdns-server installed and running, they want it restarted ASAP. This is the correct behaviour. That's a subjective assumption. At least I don't want that pdns (or any other service) is restarted once per second without rate limit and spamming my machine's journal. I personally prefer a problematic service to die (which I notice by proper monitoring). I assume the systemd developers on my side as the default for Restart is "no", and the default for StartLimitInterval is 10s. In my experience high-frequency automatic restart has very little benefits. If there is a problem that makes a certain service fail to start, you have only problems with such a rogue service (journal spamming; maybe high load; if the problem is too little system memory, you might make it hard for an admin to login; ...) If the problem is that a remote user can trigger a crash, it might be annoying to not have the service running, but maybe the next remote user can trigger a RCE if you automatically give unlimited tries for such remote users? So not restarting might be safer. And if it's only an occasional problem, at least some rate limiting doesn't hurt. Having said that, I still think that the restart behaviour should be the administrator's choice with the package defaulting to no special configuration. Looking at pdns's fellow contenders and how they configure automatic restart: - knot: Restart=on-abort no burst settings - bind9: Restart=on-failure no burst settings - unbound: Restart=on-failure no burst settings So while these consider themself important enough, too, to Restart on problems, at least they don't disable systemd's ratelimiting. Now, I believe Debian's default of "start various daemons on install" is just wrong nowadays. For a long time there was nothing we could do in pdns-server (and pdns-recursor) to change this without breaking existing installs, but I'll think about passing --no-enable to dh_installsystemd. I think this should be safe for upgrades, and new installs then need to systemctl enable pdns-server.service explicitly. This at least makes the situation better directly after package installation, so that's very welcome. (But IMHO that's only third best compared to dropping Restart=on-failure and at least not modifying StartLimitInterval. I'm sure you still disagree.) Best regards Uwe
Bug#1055529: pdns-server: Spams journal after installation because it is configured to automatically restart
Package: pdns-server Version: 4.4.1-1 Severity: normal Hello, on installation of pdns-server the pdns.service is automatically started. However in my case port 53 is already bound and so it fails to start. (That might also happen if port 53 isn't blocked because the default config isn't suitable to successfully run pdns? I didn't check.) Because of Restart=on-failure RestartSec=1 StartLimitInterval=0 in pdns.service the systemd tries to start pdns once per second and for each try logs something like: Nov 07 21:41:55 algol systemd[1]: Starting PowerDNS Authoritative Server... Nov 07 21:41:55 algol pdns_server[2329737]: Loading '/usr/lib/x86_64-linux-gnu/pdns/libbindbackend.so' Nov 07 21:41:55 algol pdns_server[2329737]: This is a standalone pdns Nov 07 21:41:55 algol pdns_server[2329737]: Listening on controlsocket in '/run/pdns/pdns.controlsocket' Nov 07 21:41:55 algol pdns_server[2329737]: UDP server bound to 0.0.0.0:53 Nov 07 21:41:55 algol pdns_server[2329737]: UDP server bound to [::]:53 Nov 07 21:41:55 algol pdns_server[2329737]: Unable to bind to TCP socket 0.0.0.0:53: Address already in use Nov 07 21:41:55 algol pdns_server[2329737]: Fatal error: Unable to bind to TCP socket Nov 07 21:41:55 algol systemd[1]: pdns.service: Main process exited, code=exited, status=1/FAILURE Nov 07 21:41:55 algol systemd[1]: pdns.service: Failed with result 'exit-code'. Nov 07 21:41:55 algol systemd[1]: Failed to start PowerDNS Authoritative Server. Nov 07 21:41:56 algol systemd[1]: pdns.service: Scheduled restart job, restart counter is at 23. Nov 07 21:41:56 algol systemd[1]: Stopped PowerDNS Authoritative Server. to the journal. If you don't notice this immediately and stop the service this effectively spams your journal in a very short time. IMHO the above mentioned settings are not suitable as a default for a distribution's package even if the default configuration worked. It should be an administrator's choice to configure such a behaviour. Best regards Uwe -- System Information: Debian Release: 11.8 APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pdns-server depends on: ii adduser 3.118+deb11u1 ii libboost-program-options1.74.0 1.74.0-9 ii libc6 2.31-13+deb11u7 ii libcurl47.74.0-1.3+deb11u10 ii libgcc-s1 10.2.1-6 ii libluajit-5.1-2 2.1.0~beta3+dfsg-5.3 ii libp11-kit0 0.23.22-1 ii libsodium23 1.0.18-1 ii libsqlite3-03.34.1-3 ii libssl1.1 1.1.1w-0+deb11u1 ii libstdc++6 10.2.1-6 ii libsystemd0 247.3-7+deb11u4 Versions of packages pdns-server recommends: ii pdns-backend-bind 4.4.1-1 Versions of packages pdns-server suggests: ii pdns-backend-bind [pdns-backend] 4.4.1-1 ii pdns-backend-pgsql [pdns-backend] 4.4.1-1 -- Configuration Files: /etc/powerdns/pdns.conf [Errno 13] Permission denied: '/etc/powerdns/pdns.conf' -- no debconf information
Bug#1015871: Enabling PCI_P2PDMA for distro kernels?
Hello, in https://bugs.debian.org/1015871 the Debian kernel team got a request to enable PCI_P2PDMA. Given the description of the feature and also the "If unsure, say N." I wonder if you consider it safe to enable this option. Assuming this option isn't completely free of security concerns, a kernel option to explicitly enable would be nice for a distro kernel. This way the option could be enabled (but dormant and so safe) and users who want to benefit from it despite the concerns can still do so. Some side information: - According to Emanuele Rocca this option is enabled in Fedora Server 38 and openSUSE Tumbleweed - I already asked in #linux-pci for feedback, Krzysztof Wilczyński recommended there to bring this topic forward via mail and pointed out a (paywalled) ACM paper about this topic (https://dl.acm.org/doi/10.1145/3409963.3410491). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1015871: Please enable CONFIG_PCI_P2PDMA
Hello, On Fri, Jul 22, 2022 at 10:06:54PM +0200, Simon Richter wrote: > would it be possible to enable this option to allow PCIe devices to do > direct data transfers? Enabling it for amd64 and ppc64el would be done by the following change: diff --git a/debian/config/amd64/config b/debian/config/amd64/config index 42ac252164f1..c4b37af83061 100644 --- a/debian/config/amd64/config +++ b/debian/config/amd64/config @@ -194,6 +194,7 @@ CONFIG_NVDIMM_PFN=y ## ## file: drivers/pci/Kconfig ## +CONFIG_PCI_P2PDMA=y CONFIG_PCI_HYPERV=y ## diff --git a/debian/config/kernelarch-powerpc/config-arch-64-le b/debian/config/kernelarch-powerpc/config-arch-64-le index 14a2e754d39e..d0503b3e17f6 100644 --- a/debian/config/kernelarch-powerpc/config-arch-64-le +++ b/debian/config/kernelarch-powerpc/config-arch-64-le @@ -28,6 +28,11 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y ## CONFIG_CXL_BUS=y +## +## file: drivers/pci/Kconfig +## +CONFIG_PCI_P2PDMA=y + ## ## file: drivers/pcmcia/Kconfig ## @@ -38,3 +43,8 @@ CONFIG_CXL_BUS=y ## #. See #789070 # CONFIG_HIBERNATION is not set + +## +## file: mm/Kconfig +## +CONFIG_ZONE_DEVICE=y ZONE_DEVICE is a direct dependency of PCI_P2PDMA that isn't currently enabled on ppc64el. I hesitate to actually enable it because I don't understand PCI good enough to judge it's a safe choice for the Debian kernel. Also I wonder about "If unsure, say N" in the Kconfig help text. Is this only because people who benefit from this setting are expected to be sure? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1033656: closed by Debian FTP Masters (reply to Mathieu Malaterre ) (Bug#1033656: fixed in highway 1.0.7-1)
Hello, On Thu, Aug 31, 2023 at 10:39:05AM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the src:highway package: > > #1033656: illegal hardware instruction cjxl > > It has been closed by Debian FTP Masters > (reply to Mathieu Malaterre ). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > (reply to Mathieu Malaterre > ) by > replying to this email. Given this affects stable and breaks other packages (at least libjxl-tools, minidlna, but I guess all (transitive) rdepends of libhwy1), I wonder if this should be fixed for stable, too?! Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1043079: btrfs filesystem usage errors out on 6.1 kernel (?)
Hello,
On 8/5/23 22:30, Uwe Kleine-König wrote:
Package: btrfs-progs
Version: 6.2-1
Severity: normal
X-Debbugs-Cc: uklei...@debian.org
Hello,
root@crater:~# btrfs fi us /srv
ERROR: unexpected number of devices: 0 != 1
ERROR: cannot get space info on '/srv': No such file or directory
running above command under strace, it ends with:
ioctl(3, BTRFS_IOC_FS_INFO, {max_id=1, num_devices=1,
fsid=fa02b5e9-5456-48fe-b8a6-a67252d798af, nodesize=16384, sectorsize=4096,
clone_alignment=4096, flags=0}) = 0
ioctl(3, BTRFS_IOC_DEV_INFO, {devid=makedev(0, 0)}) = -1 ENODEV (No
such device)
ioctl(3, BTRFS_IOC_DEV_INFO, {devid=makedev(0, 0x1)} =>
{uuid=65b29ebe-fd15-4f0a-bc13-530741e65d32, bytes_used=1662227841024,
total_bytes=199336448, path="/dev/sda1"}) = 0
ioctl(3, BTRFS_IOC_FS_INFO, {max_id=1, num_devices=1,
fsid=fa02b5e9-5456-48fe-b8a6-a67252d798af, nodesize=16384, sectorsize=4096,
clone_alignment=4096, flags=0}) = 0
openat(AT_FDCWD,
"/sys/fs/btrfs/fa02b5e9-5456-48fe-b8a6-a67252d798af/devinfo/1/fsid",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
write(2, "ERROR: ", 7) = 7
write(2, "unexpected number of devices: 0 "..., 36) = 36
write(2, "\n", 1) = 1
ioctl(3, BTRFS_IOC_SPACE_INFO, {space_slots=0} => {total_spaces=4}) = 0
ioctl(3, BTRFS_IOC_SPACE_INFO, {space_slots=4} => {total_spaces=4,
...}) = 0
write(2, "ERROR: ", 7) = 7
write(2, "cannot get space info on '/srv':"..., 58) = 58
write(2, "\n", 1) = 1
close(3)= 0
exit_group(1) = ?
+++ exited with 1 +++
The directory
/sys/fs/btrfs/fa02b5e9-5456-48fe-b8a6-a67252d798af/devinfo/1/ exists,
but it only contains the following files:
in_fs_metadata
missing
replace_target
writeable
I suspect btrfs-progs 6.2 depend on a newer kernel than the one in
Debian stable? Or maybe a kernel switch is missing?
Note that btrfs 5.10.1-2 from bullseye works fine:
root@crater:~# btrfs-5.10.1-2 fi us /srv
Overall:
Device size: 1.82TiB
Device allocated: 1.51TiB
Device unallocated: 314.57GiB
Device missing: 0.00B
Used: 1.47TiB
Free (estimated):347.22GiB (min: 189.93GiB)
Free (statfs, df): 347.21GiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Multiple profiles: no
Data,single: Size:1.50TiB, Used:1.46TiB (97.87%)
/dev/sda1 1.50TiB
Metadata,DUP: Size:8.00GiB, Used:5.73GiB (71.65%)
/dev/sda1 16.00GiB
System,DUP: Size:32.00MiB, Used:192.00KiB (0.59%)
/dev/sda1 64.00MiB
Unallocated:
/dev/sda1 314.57GiB
As expressed in the Subject line I thought I run a 6.1 kernel, but
indeed I will still on 5.10 from bullseye :-\. Booting a 6.1 kernel made
btrfs fi us work as expected.
So this is not as worse as I thought, but maybe still cherry-pick
https://github.com/kdave/btrfs-progs/commit/8e11c0726976797e1c2c2fe93011038722c56a22
for stable?
Best regards
Uwe
Bug#1043079: btrfs filesystem usage errors out on 6.1 kernel (?)
Package: btrfs-progs
Version: 6.2-1
Severity: normal
X-Debbugs-Cc: uklei...@debian.org
Hello,
root@crater:~# btrfs fi us /srv
ERROR: unexpected number of devices: 0 != 1
ERROR: cannot get space info on '/srv': No such file or directory
running above command under strace, it ends with:
ioctl(3, BTRFS_IOC_FS_INFO, {max_id=1, num_devices=1,
fsid=fa02b5e9-5456-48fe-b8a6-a67252d798af, nodesize=16384, sectorsize=4096,
clone_alignment=4096, flags=0}) = 0
ioctl(3, BTRFS_IOC_DEV_INFO, {devid=makedev(0, 0)}) = -1 ENODEV (No
such device)
ioctl(3, BTRFS_IOC_DEV_INFO, {devid=makedev(0, 0x1)} =>
{uuid=65b29ebe-fd15-4f0a-bc13-530741e65d32, bytes_used=1662227841024,
total_bytes=199336448, path="/dev/sda1"}) = 0
ioctl(3, BTRFS_IOC_FS_INFO, {max_id=1, num_devices=1,
fsid=fa02b5e9-5456-48fe-b8a6-a67252d798af, nodesize=16384, sectorsize=4096,
clone_alignment=4096, flags=0}) = 0
openat(AT_FDCWD,
"/sys/fs/btrfs/fa02b5e9-5456-48fe-b8a6-a67252d798af/devinfo/1/fsid",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
write(2, "ERROR: ", 7) = 7
write(2, "unexpected number of devices: 0 "..., 36) = 36
write(2, "\n", 1) = 1
ioctl(3, BTRFS_IOC_SPACE_INFO, {space_slots=0} => {total_spaces=4}) = 0
ioctl(3, BTRFS_IOC_SPACE_INFO, {space_slots=4} => {total_spaces=4,
...}) = 0
write(2, "ERROR: ", 7) = 7
write(2, "cannot get space info on '/srv':"..., 58) = 58
write(2, "\n", 1) = 1
close(3)= 0
exit_group(1) = ?
+++ exited with 1 +++
The directory
/sys/fs/btrfs/fa02b5e9-5456-48fe-b8a6-a67252d798af/devinfo/1/ exists,
but it only contains the following files:
in_fs_metadata
missing
replace_target
writeable
I suspect btrfs-progs 6.2 depend on a newer kernel than the one in
Debian stable? Or maybe a kernel switch is missing?
Note that btrfs 5.10.1-2 from bullseye works fine:
root@crater:~# btrfs-5.10.1-2 fi us /srv
Overall:
Device size: 1.82TiB
Device allocated: 1.51TiB
Device unallocated: 314.57GiB
Device missing: 0.00B
Used: 1.47TiB
Free (estimated):347.22GiB (min: 189.93GiB)
Free (statfs, df): 347.21GiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Multiple profiles: no
Data,single: Size:1.50TiB, Used:1.46TiB (97.87%)
/dev/sda1 1.50TiB
Metadata,DUP: Size:8.00GiB, Used:5.73GiB (71.65%)
/dev/sda1 16.00GiB
System,DUP: Size:32.00MiB, Used:192.00KiB (0.59%)
/dev/sda1 64.00MiB
Unallocated:
/dev/sda1 314.57GiB
Best regards
Uwe
-- System Information:
Debian Release: 12.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500,
'oldstable-updates'), (500, 'oldstable-security'), (500, 'stable'), (500,
'oldstable')
Architecture: armhf (armv7l)
Kernel: Linux 5.10.0-22-armmp (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages btrfs-progs depends on:
ii libblkid12.38.1-5+b1
ii libc62.36-9+deb12u1
ii libcom-err2 1.47.0-2
ii libext2fs2 1.47.0-2
ii liblzo2-22.10-2
ii libudev1 252.12-1~deb12u1
ii libuuid1 2.38.1-5+b1
ii libzstd1 1.5.4+dfsg2-5
ii zlib1g 1:1.2.13.dfsg-1
btrfs-progs recommends no packages.
Versions of packages btrfs-progs suggests:
pn duperemove
-- no debconf information
Bug#1043021: /usr/bin/debchange: dch in bookwork should know about bookworm-proposed-updates, bookworm-security and bookworm
Package: devscripts
Version: 2.23.4
Severity: wishlist
File: /usr/bin/debchange
Control: tag -1 bookworm
Control: notfound -1 2.23.5
Hello,
bookworm's dch doesn't know about the distributions based on bookworm:
$ dch -D bookworm-security -r
dch warning: Recognised distributions are:
experimental, unstable, testing, stable, oldstable, oldoldstable,
{bullseye,buster,stretch,jessie,wheezy}-proposed-updates,
{testing,stable,oldstable,oldoldstable}-proposed-updates,
{bullseye,buster,stretch,jessie,wheezy}-security,
{testing,stable,oldstable,oldoldstable}}-security, bullseye-backports,
bookworm-backports and UNRELEASED.
Using your request anyway.
dch: Did you see that warning? Press RETURN to continue...
Given that uploads targeting bookworm-proposed-updates,
bookworm-security (and maybe "bookworm"?) are likely be done based on
bookworm, it would be great to get the change "debchange: Update to
current Debian distributions"[1] that is part of 2.23.5 into
bookworm's devscripts package.
Best regards
Uwe
[1]
https://salsa.debian.org/debian/devscripts/-/commit/7d954c887c5184ff553a9c7032badebabfa590d1
Bug#1033656: bt full with dbgsym
Control: affects -1 + minidlna
The same bug affects minidlna:
uwe@crater:~$ gdb /usr/sbin/minidlnad
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/minidlnad...
Reading symbols from
/usr/lib/debug/.build-id/8d/c7b6b6d717dcb1c814fff9a3e5a4dba526.debug...
(gdb) run
Starting program: /usr/sbin/minidlnad
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.
hwy::(anonymous namespace)::robust_statistics::CountingSort
(values=0xbeffecb8, num_values=256)
at ./hwy/nanobenchmark.cc:214
214 ./hwy/nanobenchmark.cc: No such file or directory.
(gdb) disassemble
Dump of assembler code for function hwy::(anonymous
namespace)::robust_statistics::CountingSort(unsigned long
long*, size_t):
0xb546afb0 <+0>: stmdb sp!, {r4, r5, r6, r7, r8, r9, r10, r11, lr}
0xb546afb4 <+4>: mov r9, r1
0xb546afb6 <+6>: ldr r1, [pc, #492] @ (0xb546b1a4 (unsigned long
long*, size_t)+500>)
0xb546afb8 <+8>: sub sp, #52 @ 0x34
0xb546afba <+10>:ldr r2, [pc, #492] @ (0xb546b1a8 (unsigned long
long*, size_t)+504>)
0xb546afbc <+12>:add r1, pc
=> 0xb546afbe <+14>:vmov.i32d16, #0 @ 0x
0xb546afc2 <+18>:movsr6, #0
0xb546afc4 <+20>:str r6, [sp, #16]
0xb546afc6 <+22>:ldr r2, [r1, r2]
0xb546afc8 <+24>:ldr r2, [r2, #0]
0xb546afca <+26>:str r2, [sp, #44] @ 0x2c
0xb546afcc <+28>:mov.w r2, #0
0xb546afd0 <+32>:vstrd16, [sp, #8]
0xb546afd4 <+36>:cmp.w r9, #0
0xb546afd8 <+40>:beq.w 0xb546b180 (unsigned long
long*, size_t)+464>
0xb546afdc <+44>:mov r4, r0
0xb546afde <+46>:mov r5, r6
0xb546afe0 <+48>:mov r8, r6
0xb546afe2 <+50>:mov.w r10, #1
0xb546afe6 <+54>:add.w r11, sp, #24
0xb546afea <+58>:sub.w r3, r0, #8
0xb546afee <+62>:str r3, [sp, #4]
0xb546aff0 <+64>:ldr r2, [sp, #4]
0xb546aff2 <+66>:subsr3, r5, r6
0xb546aff4 <+68>:mov.w r12, r3, asr #6
0xb546aff8 <+72>:asrsr0, r3, #4
0xb546affa <+74>:ldr.w r1, [r2, #8]!
0xb546affe <+78>:cmp.w r12, #0
0xb546b002 <+82>:str r2, [sp, #4]
0xb546b004 <+84>:ldr r2, [r2, #4]
0xb546b006 <+86>:ble.w 0xb546b19a (unsigned long
long*, size_t)+490>
0xb546b00a <+90>:add.w r12, r6, r12, lsl #6
0xb546b00e <+94>:mov r3, r6
0xb546b010 <+96>:b.n 0xb546b03c (unsigned long
long*, size_t)+140>
0xb546b012 <+98>:ldrdr0, r7, [r3, #16]
--Type for more, q to quit, c to continue without paging--q
Quit
(gdb) bt
#0 hwy::(anonymous namespace)::robust_statistics::CountingSort (values=0xbeffecb8, num_values=256)
at ./hwy/nanobenchmark.cc:214
#1 0xb546b256 in hwy::(anonymous namespace)::robust_statistics::Mode (num_values=256, values=0xbeffecb8)
at ./hwy/nanobenchmark.cc:286
#2 hwy::(anonymous namespace)::robust_statistics::Mode (values=...) at ./hwy/nanobenchmark.cc:292
#3 hwy::platform::TimerResolution () at ./hwy/nanobenchmark.cc:480
#4 0xb5469e0e in __static_initialization_and_destruction_0 (__priority=65535,
__initialize_p=1) at ./hwy/nanobenchmark.cc:488
#5 _GLOBAL__sub_I_nanobenchmark.cc(void) () at ./hwy/nanobenchmark.cc:763
#6 0xb6fe444c in call_init (env=0xbefff53c, argv=0xbefff534, argc=1,
l=) at dl-init.c:70
#7 call_init (l=, argc=1, argv=0xbefff534, env=0xbefff53c) at
dl-init.c:26
#8 0xb6fe44f2 in _dl_init (main_map=0xb6fffa68, argc=1, argv=0xbefff534,
env=0xbefff53c) at dl-init.c:117
#9 0xb6ff17cc in _dl_start_user () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
I installed 1.0.5~git20230620.ed184dc-3 from expermental, that doesn't
fix the problem.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Bug#1039615: ssh/_scp_remote_files adds to many backslashes for rsync
Package: bash-completion Version: 1:2.11-6 Severity: normal X-Debbugs-Cc: uklei...@debian.org Hello, uwe@taurus:~$ echo content > 'file with space' After that uwe@taurus:~$ rsync localhost:fil completes to: uwe@taurus:~$ rsync localhost:file\\\ with\\\ space . Adding a target path and pressing Enter then results in: uwe@taurus:~$ rsync localhost:file\\\ with\\\ space /tmp rsync: [sender] link_stat "/home/uwe/file\ with\ space" failed: No such file or directory (2) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1865) [Receiver=3.2.7] rsync: [Receiver] write error: Broken pipe (32) The right quoting is: uwe@taurus:~$ rsync localhost:file\ with\ space /tmp Interesting side note: uwe@taurus:~$ scp localhost:file\\\ with\\\ space /tmp uwe@taurus:~$ scp localhost:file\ with\ space /tmp uwe@taurus:~$ scp localhost:file\ with\\\ space /tmp all result in the same file being transferred. Best regards Uwe -- System Information: Debian Release: 12.0 APT prefers testing-debug APT policy: (800, 'testing-debug'), (800, 'testing'), (700, 'stable-security'), (700, 'stable-debug'), (700, 'stable'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-debug'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1031236: ifupdown: diff for NMU version 0.8.41+nmu1
Hello Santiago, On 6/21/23 19:58, Santiago Ruano Rincón wrote: El 21/06/23 a las 19:10, Uwe Kleine-König escribió: Control: tags 1031236 + pending Dear maintainer, I've prepared an NMU for ifupdown (versioned as 0.8.41+nmu1) and intend to upload it to DELAYED/10 once I properly tested the patch. (Unfortunately I locked myself out of the affected machine while reconfiguring the network devices. So testing will have to wait until I find someone with physical access to that machine.) The change is effectively what Ken Milmore proposed. Thanks for this. Would you like to prepare a MR instead. I would like to handle the switch to dependency on dhcpcd-base along. Sure: https://salsa.debian.org/debian/ifupdown/-/merge_requests/20 Best regards Uwe
Bug#1031236: ifupdown: diff for NMU version 0.8.41+nmu1
Control: tags 1031236 + pending
Dear maintainer,
I've prepared an NMU for ifupdown (versioned as 0.8.41+nmu1) and intend
to upload it to DELAYED/10 once I properly tested the patch.
(Unfortunately I locked myself out of the affected machine while
reconfiguring the network devices. So testing will have to wait until I
find someone with physical access to that machine.)
The change is effectively what Ken Milmore proposed.
Best regards
Uwe
diff -Nru ifupdown-0.8.41/debian/changelog ifupdown-0.8.41+nmu1/debian/changelog
--- ifupdown-0.8.41/debian/changelog 2023-01-24 14:07:32.0 +0100
+++ ifupdown-0.8.41+nmu1/debian/changelog 2023-06-21 18:18:20.0 +0200
@@ -1,3 +1,12 @@
+ifupdown (0.8.41+nmu1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix if-up.d/resolved hook to properly work with nameservers and search
+domains. Thanks to Dmytro Kolesnykov and Ken Milmore for the bug report
+and a proposed patch. (Closes: #1031236)
+
+ -- Uwe Kleine-König Wed, 21 Jun 2023 18:18:20 +0200
+
ifupdown (0.8.41) unstable; urgency=high
* networking.service: Improve how to handle hotplug devices. Thanks to kibi,
diff -Nru ifupdown-0.8.41/debian/if-up.d/resolved ifupdown-0.8.41+nmu1/debian/if-up.d/resolved
--- ifupdown-0.8.41/debian/if-up.d/resolved 2022-12-09 21:37:03.0 +0100
+++ ifupdown-0.8.41+nmu1/debian/if-up.d/resolved 2023-06-21 18:17:47.0 +0200
@@ -43,11 +43,11 @@
fi
if [ -n "$NEW_DNS" ]; then
cat <"$mystatedir/ifupdown-${ADDRFAM}-$interface"
-"$DNS"="$NEW_DNS"
+$DNS="$NEW_DNS"
EOF
if [ -n "$NEW_DOMAINS" ]; then
cat <>"$mystatedir/ifupdown-${ADDRFAM}-$interface"
-"$DOMAINS"="$NEW_DOMAINS"
+$DOMAINS="$NEW_DOMAINS"
EOF
fi
fi
@@ -66,7 +66,7 @@
# ignore errors due to nonexistent file
md5sum "$mystatedir/isc-dhcp-v4-$interface" "$mystatedir/isc-dhcp-v6-$interface" "$mystatedir/ifupdown-inet-$interface" "$mystatedir/ifupdown-inet6-$interface" > "$newstate" 2> /dev/null || true
if ! cmp --silent "$oldstate" "$newstate" 2>/dev/null; then
-DNS DNS6 DOMAINS DOMAINS6 DEFAULT_ROUTE
+unset DNS DNS6 DOMAINS DOMAINS6 DEFAULT_ROUTE
# v4 first
if [ -e "$mystatedir/isc-dhcp-v4-$interface" ]; then
. "$mystatedir/isc-dhcp-v4-$interface"
signature.asc
Description: PGP signature
Bug#1037143: netcat-openbsd: nc -t should quote IAC (i.e. '\xff')
Package: netcat-openbsd Version: 1.219-1 Severity: normal X-Debbugs-Cc: uklei...@debian.org Hello, if netcat is talking to a remote peer that implements a telnet-like protocol (e.g. rfc2217 in my case), IAC should be quoted. That is printf '01234\xff\xfb\x015678' | nc -t ::1 12345 should actually send 01234\xff\xff\xfb\x015678 because otherwise the stream is interpreted on the other side as a command. On the receiving side the matching unquoting should happen. (Look at the effect if the other side happens to be nc -t -l :: 12345 . The problem is that nc assumes it never sent a WILL request and so should safely reply to the DONT reply with a WONT. The fix is to quote the IAC such that the assumption "nc never sent a WILL request" becomes true. See https://www.rfc-editor.org/rfc/rfc854, GENERAL CONSIDERATIONS for more details.) Best regards Uwe
Bug#1037046: lrzsz: yet another typo in a manpage
Package: lrzsz Version: 0.12.21-10+b1 Severity: minor Tags: patch X-Debbugs-Cc: uklei...@debian.org Hello, lrz(1) has: Default ist 32768, [...] which is probably originating by a German author. In proper English it has to read: Default is 32768, [...] . The following patch to the debian source fixes that: diff --git a/debian/patches/mantypos.diff b/debian/patches/mantypos.diff index 6a6a4b23eaf9..46d09b16f4a2 100644 --- a/debian/patches/mantypos.diff +++ b/debian/patches/mantypos.diff @@ -47,3 +47,14 @@ The environment variable ZNULLS may be used to specify the number of nulls to send before a ZDATA frame. Values of 101 for a 4.77 mHz PC and 124 for an AT are typical. +--- lrzsz-0.12.21.orig/man/lrz.1 lrzsz-0.12.21/man/lrz.1 +@@ -172,7 +172,7 @@ + .B "-B NUMBER, --bufsize NUMBER" + Buffer + .B NUMBER +-bytes before writing to disk. Default ist 32768, which should be enough ++bytes before writing to disk. Default is 32768, which should be enough + for most situations. If you have a slow machine or a bad disk interface + or suffer from other hardware problems you might want to increase + the buffersize. Best regards Uwe
Bug#1035432: blhc: Warnings for Linux 6.3 build
Control: retitle -1 support more than one ignore-line-regexp line Control: severity -1 wishlist Hello Simon, On 5/3/23 18:50, Simon Ruderich wrote: On Wed, May 03, 2023 at 12:21:02PM +0200, Uwe Kleine-König wrote: Do you have a nice idea how to fix the test that does involve neither disabling the blhc tests nor disabling the perf tests? One idea is to not check debug builds (-Og or -O0) for the fortify stuff. Another is to allow specifying a regexp of (possible) false positives. Hi Uwe, the method suggested by Diederik [1] is the recommended way to handle false positives in blhc. It's documented in the blhc man page: man blhc | less -p 'FALSE POSITIVES': To suppress false positives you can embed the following string in the build log: blhc: ignore-line-regexp: REGEXP All lines fully matching REGEXP (see --ignore-line for details) will be ignored. [...] That's how we did it now. I thought I checked the docs but somehow missed that before reporting the bug. As Diederik pointed out there was already a ignore-line regexp in the kernel. As it addresses several different thing, it's a long and ugly regexp. I tried the following simplification: index b39c230a94a6..909d53c8dfdf 100755 --- a/debian/rules +++ b/debian/rules @@ -35,14 +35,25 @@ build: build-arch build-indep build-arch: debian/control dh_testdir + # The perf-read-vdso* programs are built for different architectures, # without standard flags, but are not exposed to untrusted input. + @printf '%s\n' 'blhc: ignore-line-regexp: .* -o *[^ ]*/perf-read-vdso.*' + # Kernel code needs different hardening options that blhc doesn't know # about. + @printf '%s\n' 'blhc: ignore-line-regexp: .* -D__KERNEL__ .*' + # We need to use terse builds in CI due to the log size limit. This # mostly affects the output for builds of kernel code, which need # different options for hardening anyway. - @printf '%s\n' 'blhc: ignore-line-regexp: (.* -o *[^ ]*/perf-read-vdso.*|.* -D__KERNEL__ .*$(if $(filter terse,$(DEB_BUILD_OPTIONS)),| *(CC(LD)?|LD|LINK)\b.*))' +ifeq ($(filter terse,$(DEB_BUILD_OPTIONS)),) + @printf '%s\n' 'blhc: ignore-line-regexp: *(CC(LD)?|LD|LINK)\b.*))' +endif (Let's hope thunderbird keeps the diff as pretty after sending as it looks now :-) The idea is to have several ignore-line-regexp specs, where each is simpler and can be documented individually. However that doesn't work as blhc only uses one of them (don't remember, probably the first or the last). I would consider it a very nice feature of blhc to support using them all. Now that the original bug is degraded to a RTFM, I made this bug a wishlist item for this feature. Best regards Uwe
Bug#1035432: blhc: Warnings for Linux 6.3 build
Package: blhc Version: 0.13-5 Severity: normal X-Debbugs-Cc: didi.deb...@cknow.org, uklei...@debian.org Hello, Diederik de Haas prepared importing Linux 6.3 in the Debian kernel repository. The salsa test pipeline fails with an issue reported by blhc as can be seen on https://salsa.debian.org/diederik/linux/-/pipelines/524434/failures The problem is that some binaries that are only used for testing the perf binary are (deliberately) compiled with -O0 and so without -D_FORTIFY_SOURCE=2. Given that the binaries are not included in the resulting packages, IMHO the best way forward would be to somehow tell blhc that these few builds are false positives. However I didn't find a way to do that (which might be related to me not taking much time and only having limited Perl knowledge). Do you have a nice idea how to fix the test that does involve neither disabling the blhc tests nor disabling the perf tests? One idea is to not check debug builds (-Og or -O0) for the fortify stuff. Another is to allow specifying a regexp of (possible) false positives. Best regards Uwe -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (700, 'testing-security'), (700, 'testing-debug'), (700, 'stable-security'), (700, 'stable-debug'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-8-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages blhc depends on: ii libdpkg-perl 1.21.21 blhc recommends no packages. blhc suggests no packages. -- no debconf information
Bug#1022246: device-tree-compiler: FTBFS on hppa - assembler issues
Control: tag -1 + fixed-upstream Hello, On Sat, Oct 22, 2022 at 05:08:03PM +, John David Anglin wrote: > Source: device-tree-compiler > Version: 1.6.1-4 > Severity: normal > Tags: ftbfs patch > > Dear Maintainer, > > Build fails here: > AS tests/trees.o > tests/trees.S: Assembler messages: > tests/trees.S:256: Error: junk at end of line, first unrecognized character > is `'' > tests/trees.S:257: Error: junk at end of line, first unrecognized character > is `'' > tests/trees.S:258: Error: junk at end of line, first unrecognized character > is `'' > tests/trees.S:219: Error: invalid operands (*UND* and .data sections) for `-' > I tried to compile upstream's main branch on hppa and couldn't reproduce it. I guess it was fixed by https://git.kernel.org/pub/scm/utils/dtc/dtc.git/commit/?id=d24cc189dca6148eedf9dc9e2d45144b3851dae0 which is included in v1.7.0. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1034631: lintian: Warn for 32bit time_t / Y2038 problems
Hello Russ, On 4/20/23 19:40, Russ Allbery wrote: Uwe Kleine-König writes: to help making package maintainers aware of the Y2038 problem I implemented a lintian check that triggers if a symbol from glibc is used that uses a 32bit time_t type. The code is available in a MR on the lintian packaging repository at https://salsa.debian.org/lintian/lintian/-/merge_requests/463 I have no objections to adding this as an experimental tag. The detection component to determine the size of the problem is certainly useful. > However, more generally, do we know yet how Debian intends to handle this transition? Changing to 64-bit time_t will change the ABI of shared libraries and thus is not a safe change to make without an SONAME transition unless we're going to do something architecture-wide, such as introducing a new version of the i386 architecture where everything is built with 64-bit time_t. I'm not aware of a decision how this should be handled. The lintian tag is a step to measure the actual problem by identifying the packages that need some love. Also independent of a global effort I expect that a big number of leaf packages can simply be converted. Further it probably helps to spread awareness and maintainers might tackle the update if a soname bump has to be done for other reasons anyhow. I know there's a caution in there already about this, but I'm concerned about maintainers acting on this tag by blindly adding the Autoconf flags or macros to switch to 64-bit time_t and thus creating numerous uncoordinated shared library transitions, possibly without knowing they need to change the SONAME. And it's not clear to me that we want to do the migration by changing the SONAME of every shared library in Debian that uses time_t has part of its public API (which is a lot of them). I wonder if there is a list already of such libs. I know of at least one package (and I am certain that there will be more) where this change will also change on-disk data formats in a way that is not backward-compatible, which is even less safe. The current caution should probably be stronger: it's only safe to do this transition for leaf packages that do not call any shared library functions with time_t parameters and that do not use time_t in any binary data structures stored on disk (possibly including caches, depending on the situation). In other situations, this is something that's going to require some distribution-wide coordination that I don't think we've started yet. I expanded the tag's description to point out that converting to time64 probably needs some care. If you have a concrete proposal to improve it further, I'm open for feedback. Best regards Uwe
Bug#1008656: linux-image-5.10.0-13-cloud-amd64: Consider AHCI SATA support in cloud kernels
Control: tags -1 + patch There is a MR for this bug on https://deb.li/Xe0A Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1034574: uscan: support OpenPGP signature verification without requiring a saved upstream signing key
Hello, On Tue, Apr 18, 2023 at 05:25:58PM +, John Scott wrote: > I know if you're looking at the subject line alone you'll think I'm proposing > introducing a security vulnerability, but let me explain. > > There are some problems with storing an upstream signing key inside the > package. It might get stale, not incorporating additional subkeys necessary > for signature verification or revocations. Also, it requires manual work on > the part of the maintainer and can't be done automatically. > > Folks outside the OpenPGP ecosystem might not know this, but the Web of Trust > is now not the only way of doing things. There are ways, like Web Key > Directory, DANE, and LDAP, to not only discover an OpenPGP key, but also > verify that it really belongs to the person in the user ID. > > First, we save in some metadata file somewhere (debian/upstream/metadata?) > the user IDs (aka names and email addresses) of upstream, or perhaps mappings > of key IDs to email addresses. When uscan goes to verify the signature, it > will know the key ID of the signer but might not know their user ID, so it > will look in the mapping table. > > Then it will fetch the key using an authenticated method and use it to verify > the signature. > > I hope that makes sense. Unfortunately I only know C, so I don't think I'll > be able to contribute this. My personal objective opinion to that is: I prefer manual key handling over such automatisms. To get the key belonging to a certain email address the mentioned mechanisms like WKD and DANE are reasonably good. But I want to authenticate a certain person, not someone in control of a certain email address (which can change). So if such a mechanism existed, I wouldn't opt-in to it and prefer to continue occasionally updating the upstream key after manual verification. My 0.02€, Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1034631: lintian: Warn for 32bit time_t / Y2038 problems
Package: lintian Version: 2.116.3 Severity: normal Tags: patch X-Debbugs-Cc: uklei...@debian.org Hello, to help making package maintainers aware of the Y2038 problem I implemented a lintian check that triggers if a symbol from glibc is used that uses a 32bit time_t type. The code is available in a MR on the lintian packaging repository at https://salsa.debian.org/lintian/lintian/-/merge_requests/463 Thanks for considering Uwe
Bug#1034547: manpages-dev: *stat might return EOVERFLOW also for time related fields
Hello,
I did some more research about this issue, so I'm adding some more
information.
On Mon, Apr 17, 2023 at 11:46:38PM +0200, Uwe Kleine-König wrote:
> Package: manpages-dev
> Version: 6.03-1
> Severity: normal
> X-Debbugs-Cc: uklei...@debian.org
>
> Hello,
>
> the manpage for stat, fstat, lstat and fstatat specify that the error
> EOVERLFLOW means:
>
> pathname or fd refers to a file whose size, inode number, or
> number of blocks cannot be represented in, respectively, the
> types off_t, ino_t, or blkcnt_t. This error can occur when, for
> example, an application compiled on a 32-bit platform without
> -D_FILE_OFFSET_BITS=64 calls stat() on a file whose size exceeds
> (1<<31)-1 bytes.
>
> However at least in libc6-2.35 and later EOVERFLOW is also returned if
> st_atim.tv_sec, st_mtim.tv_sec or st_ctim.tv_sec don't fit into an
> int32_t on platforms with __TIME_SIZE == 32.
This happens since commit 4c4e90ccf8e4 ("linux: Implement
fstatat with __fstatat64_time64") in glibc, that's between 2.33.9000 and
2.34. Commit aa03f722f3b994aaf81e72a8904bf33196780930 that was added for
2.33 is also slightly relevant (for platforms with LFS but 32 bit
time_t).
There are a few more calls that can return an undocumented EOVERFLOW:
- clock_gettime
(since commit ec138c67cbda ("sysdeps/clock_gettime: Use clock_gettime64 if
avaliable")
that is already in glibc 2.31)
- ftime
(since commit 5d8aa97da233 ("time: Add 64-bit time_t support for ftime")
that is included in glibc 2.33)
- gettimeofday
(since commit 7455b700279e ("y2038: linux: Provide __gettimeofday64
implementation")
that is included in glibc 2.31)
- sched_rr_get_interval
(since commit b112f53e9d0f ("y2038: linux: Provide __sched_rr_get_interval64
implementation")
that is included in glibc 2.32)
- time
(since commit 75c4044b9a49 ("y2038: linux: Provide __time64 implementation")
included in glibc 2.33)
- timespec_get
(since commit f1c314d27552 ("y2038: linux: Provide __timespec_get64
implementation")
included in glibc 2.32)
I didn't find documenation about this function in manpages-dev, seems
to have appeard for isoc11.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Bug#1034547: manpages-dev: *stat might return EOVERFLOW also for time related fields
Package: manpages-dev Version: 6.03-1 Severity: normal X-Debbugs-Cc: uklei...@debian.org Hello, the manpage for stat, fstat, lstat and fstatat specify that the error EOVERLFLOW means: pathname or fd refers to a file whose size, inode number, or number of blocks cannot be represented in, respectively, the types off_t, ino_t, or blkcnt_t. This error can occur when, for example, an application compiled on a 32-bit platform without -D_FILE_OFFSET_BITS=64 calls stat() on a file whose size exceeds (1<<31)-1 bytes. However at least in libc6-2.35 and later EOVERFLOW is also returned if st_atim.tv_sec, st_mtim.tv_sec or st_ctim.tv_sec don't fit into an int32_t on platforms with __TIME_SIZE == 32. Best regards Uwe -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (700, 'testing-security'), (700, 'testing-debug'), (700, 'stable-security'), (700, 'stable-debug'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages manpages-dev depends on: ii manpages 6.03-1 manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.11.2-2 -- no debconf information
Bug#1034451: evince: Dies with an assertion error when trying to print
Package: evince Version: 43.1-2+b1 Severity: normal X-Debbugs-Cc: u...@kleine-koenig.org Hello, when trying to print a certain document (note to myself: plusquemaproprevie.pdf), evince dies with: evince: ../../../../src/cairo-array.c:182: _cairo_array_index: Assertion `index < array->num_elements' failed. backtrace looks as follows: #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x7f8b4a2aed2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x7f8b4a25fef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x7f8b4a24a472 in __GI_abort () at ./stdlib/abort.c:79 #4 0x7f8b4a24a395 in __assert_fail_base (fmt=0x7f8b46b8e8f2 "%s%s%s:%u: %s%sZusicherung »%s« nicht erfüllt.\n%n", assertion=assertion@entry=0x7f8b4a8b338e "index < array->num_elements", file=file@entry=0x7f8b4a8b3370 "../../../../src/cairo-array.c", line=line@entry=182, function=function@entry=0x7f8b4a8b3430 <__PRETTY_FUNCTION__.2> "_cairo_array_index") at ./assert/assert.c:92 #5 0x7f8b4a258df2 in __GI___assert_fail (assertion=assertion@entry=0x7f8b4a8b338e "index < array->num_elements", file=file@entry=0x7f8b4a8b3370 "../../../../src/cairo-array.c", line=line@entry=182, function=function@entry=0x7f8b4a8b3430 <__PRETTY_FUNCTION__.2> "_cairo_array_index") at ./assert/assert.c:101 #6 0x7f8b4a7e74a3 in _cairo_array_index (index=557, array=) at ../../../../src/cairo-array.c:182 #7 0x7f8b4a7e7609 in _cairo_array_index (array=, index=index@entry=557) at ../../../../src/cairo-array.c:167 #8 0x7f8b4a8581d4 in cairo_cff_parse_charstring (font=font@entry=0x55b5c22bec20, charstring=, length=, glyph_id=glyph_id@entry=0, need_width=1) at ../../../../src/cairo-cff-subset.c:1580 #9 0x7f8b4a85b063 in cairo_cff_find_width_and_subroutines_used (subset_id=0, glyph_id=0, length=, charstring=, font=0x55b5c22bec20) at ../../../../src/cairo-cff-subset.c:1661 #10 cairo_cff_font_subset_charstrings_and_subroutines (font=0x55b5c22bec20) at ../../../../src/cairo-cff-subset.c:1778 #11 cairo_cff_font_subset_font (font=0x55b5c22bec20) at ../../../../src/cairo-cff-subset.c:1959 #12 cairo_cff_font_generate (length=, data=, font=) at ../../../../src/cairo-cff-subset.c:2572 #13 _cairo_cff_subset_init (cff_subset=cff_subset@entry=0x7ffe2c68b3f0, subset_name=subset_name@entry=0x7ffe2c68b460 "CairoFont-2-0", font_subset=font_subset@entry=0x7ffe2c68b560) at ../../../../src/cairo-cff-subset.c:2949 #14 0x7f8b4a8a96e1 in _cairo_pdf_surface_emit_cff_font_subset (font_subset=0x7ffe2c68b560, surface=0x55b5c2508000) at ../../../../src/cairo-pdf-surface.c:5643 #15 _cairo_pdf_surface_emit_unscaled_font_subset (font_subset=0x7ffe2c68b560, closure=0x55b5c2508000) at ../../../../src/cairo-pdf-surface.c:6358 #16 0x7f8b4a85ca98 in _cairo_sub_font_collect (closure=0x7ffe2c68b510, entry=0x55b5c2326770) at ../../../../src/cairo-scaled-font-subsets.c:746 #17 _cairo_scaled_font_subsets_foreach_internal (font_subsets=, font_subset_callback=font_subset_callback@entry=0x7f8b4a8a9670 <_cairo_pdf_surface_emit_unscaled_font_subset>, closure=closure@entry=0x55b5c2508000, type=type@entry=CAIRO_SUBSETS_FOREACH_UNSCALED) at ../../../../src/cairo-scaled-font-subsets.c:1067 #18 0x7f8b4a85d807 in _cairo_scaled_font_subsets_foreach_unscaled (font_subsets=, font_subset_callback=font_subset_callback@entry=0x7f8b4a8a9670 <_cairo_pdf_surface_emit_unscaled_font_subset>, closure=closure@entry=0x55b5c2508000) at ../../../../src/cairo-scaled-font-subsets.c:1095 #19 0x7f8b4a8a7638 in _cairo_pdf_surface_emit_font_subsets (surface=0x55b5c2508000) at ../../../../src/cairo-pdf-surface.c:6408 #20 _cairo_pdf_surface_finish (abstract_surface=0x55b5c2508000) at ../../../../src/cairo-pdf-surface.c:2220 #21 0x7f8b4a845c52 in _cairo_surface_finish (surface=surface@entry=0x55b5c2508000) at ../../../../src/cairo-surface.c:1030 --Type for more, q to quit, c to continue without paging-- #22 0x7f8b4a8469bb in INT_cairo_surface_finish (surface=0x55b5c2508000) at ../../../../src/cairo-surface.c:1079 #23 INT_cairo_surface_finish (surface=0x55b5c2508000) at ../../../../src/cairo-surface.c:1063 #24 0x7f8b4a814075 in _cairo_paginated_surface_finish (abstract_surface=0x55b5c1920800) at ../../../../src/cairo-paginated-surface.c:214 #25 0x7f8b4a845c52 in _cairo_surface_finish (surface=surface@entry=0x55b5c1920800) at ../../../../src/cairo-surface.c:1030 #26 0x7f8b4a8469bb in INT_cairo_surface_finish (surface=0x55b5c1920800) at ../../../../src/cairo-surface.c:1079 #27 INT_cairo_surface_finish (surface=0x55b5c1920800) at ../../../../src/cairo-surface.c:1063 #28 0x7f8b4ada0e37 in unix_end_run (op=0x55b5c18a12a0, wait=0, cancelled=0) at ../../../gtk/gtkprintoperation-unix.c:374 #29 0x7f8b4ac60739 in print_pages_idle (user_data=0x55b5c24da240) at
Bug#1030434: rauc: FTBFS: tests failed writing: Error opening file ?/tmp/tmp.I4dlWcaK4g/notexisting/out.raucb?: No such file or directory
Control: reassign 1030434 src:opensc 0.23.0-0.1 Control: tag 1030434 + fixed-upstream Control: affects 1030434 + rauc Hello, On Sat, Feb 04, 2023 at 08:39:04AM +0100, Lucas Nussbaum wrote: > Source: rauc > Version: 1.8-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230203 ftbfs-bookworm > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > The full build log is available from: > http://qa-logs.debian.net/2023/02/03/rauc_1.8-2_unstable.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230203;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20230203=lu...@debian.org=1=1=1=1#results This is a regression in opensc with openssl3 support. This is fixed upstream by the following commits: 9294183e07ff pkcs11-tool: Fix private key import cff91cf61677 pkcs11-tool: Log more information on OpenSSL errors With these two fixes applied, rauc should build fine again as is. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#619442: mtd-utils: please include in armel installer
Hello, On Mon, Sep 06, 2021 at 10:08:51AM +0200, Uwe Kleine-König wrote: > On Thu, Sep 24, 2020 at 07:45:04PM +0200, Bastian Germann wrote: > > On Wed, 26 Nov 2003 18:56:57 -0500 Jonathan Lane > > wrote: > > > I'm running Debian Squeeze on a Marvell Sheevaplug, and I'd really like > > > to install Debian directly to NAND memory. The mtd-utils package > > > contains all the tools needed to do that that aren't already in the > > > installer, and the existing method of putting a Debian install on the > > > internal NAND is a pain in the rear. I'm in no real hurry to get this > > > fixed right now, but it would be nice for future releases like Wheezy. > > > > Would you like the package to have a udeb version like the one that is > > referenced at https://wiki.debian.org/DebianInstaller/MTD#MTD_utils ? > > > > Is there still interest in this? > > I have interest. I'm working to unbrick my NAS and having the mtd-utils > available in the installer would simplify this. Just quickly talked about this issue in #debian-boot. kibi pointed out that this would likely require a second build to not introduce a dependeny on selinux. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1017082: neomutt: (security) The sender’s timezone is exposed in the Date: header
Hello, On Sat, Aug 13, 2022 at 11:41:49AM +0200, debbug.neom...@sideload.33mail.com wrote: > Package: neomutt > Version: 20201127+dfsg.1-1.2 > Severity: normal > Tags: upstream > X-Debbugs-Cc: debbug.neom...@sideload.33mail.com > > The “Date:” field is added after the user instructs neomutt to send > their message, so there is no opportunity for the user to edit the > timestamp of the message. Perhaps rightly so, for RFC-compliance. But > the timestamp that mutt generates exposes the timezone of the > author. It’s too much information. E.g. this reveals to the recipient > and all mail servers enroute that the sender is physically in the > central Europe timezone: > > Date: Fri, 12 Aug 2022 13:21:24 +0200 > > This exposes the presence of senders in the eastern US timezone: > > Date: Fri, 12 Aug 2022 13:21:24 -0400 I suggest to unset the local_date_header configuration option. From the manual: 3.171. local_date_header Type: boolean Default: yes If set, the date in the Date header of emails that you send will be in your local timezone. If unset a UTC date will be used instead to avoid leaking information about your current location. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1025704: neomutt: Segfault when resuming postponed message from cmdline
Package: neomutt
Version: 20220429+dfsg1-4
Severity: normal
Tags: patch upstream fixed-upstream
X-Debbugs-Cc: uklei...@debian.org
Control: forwarded -1 https://github.com/neomutt/neomutt/issues/3268
Hello,
under some condition, calling
neomutt -p
segfaults.
See the upstream bug report for some more details. It's fixed upstream
in:
https://github.com/neomutt/neomutt/commit/d03cc941019fc030ac99ce3826e8a1648dc4c779
Best regards
Uwe
-- Package-specific info:
NeoMutt 20220429
Copyright (C) 1996-2022 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.
System: Linux 6.0.0-4-amd64 (x86_64)
ncurses: ncurses 6.3.20220423 (compiled with 6.3.20220423)
libidn: 1.41 (compiled with 1.41)
GPGME: 1.18.0
GnuTLS: 3.7.8
libnotmuch: 5.6.0
storage: tokyocabinet
Configure options: --build=x86_64-linux-gnu --prefix=/usr
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man}
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
{--libdir=${prefix}/lib/x86_64-linux-gnu} --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking --mandir=/usr/share/man
--libexecdir=/usr/libexec --with-mailpath=/var/mail --gpgme --lua --notmuch
--with-ui --gsasl --gnutls --gss --idn --mixmaster --tokyocabinet --sqlite
--autocrypt --pkgconf
Compilation CFLAGS: -g -O2
-ffile-prefix-map=/build/neomutt-F8xOKh/neomutt-20220429+dfsg1=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include/lua5.4
-I/usr/include -DNCURSES_WIDECHAR -I/usr/include/p11-kit-1 -isystem
/usr/include/mit-krb5
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
+autocrypt +fcntl -flock -fmemopen +futimens +getaddrinfo +gnutls +gpgme
+gsasl +gss +hcache -homespool +idn +inotify -locales_hack +lua +mixmaster
+nls +notmuch -openssl +pgp +regex -sasl +smime +sqlite +sun_attachment
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"
To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to:
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (700, 'testing-debug'), (700, 'stable-security'), (700,
'stable-debug'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500,
'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500,
'oldoldstable'), (500, 'oldstable'), (499, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages neomutt depends on:
ii libc6 2.36-5
ii libgnutls30 3.7.8-4
ii libgpg-error0 1.46-1
ii libgpgme111.18.0-1
ii libgsasl182.2.0-1
ii libgssapi-krb5-2 1.20.1-1
ii libidn12 1.41-1
ii liblua5.4-0 5.4.4-3
ii libncursesw6 6.3+20220423-2
ii libnotmuch5 0.37-1
ii libsqlite3-0 3.40.0-1
ii libtinfo6 6.3+20220423-2
ii libtokyocabinet9 1.4.48-15
ii sensible-utils0.0.17
Versions of packages neomutt recommends:
ii locales 2.36-5
ii mailcap 3.70+nmu1
Versions of packages neomutt suggests:
ii aspell 0.60.8-4+b1
ii ca-certificates20211016
ii exim4-daemon-light [mail-transport-agent] 4.96-9
ii gnupg 2.2.40-1
ii ispell 3.4.05-1
pn mixmaster
ii openssl3.0.7-1
pn urlview
Versions of packages neomutt is related to:
ii neomutt 20220429+dfsg1-4
-- no debconf information
Bug#1023653: coccinelle: Picks up wrong Python
Control: tag -1 +patch
Hello Julia,
On 11/8/22 15:44, Julia Lawall wrote:
Hello,
when I run
/usr/bin/spatch -D report --no-show-diff --very-quiet --cocci-file
scripts/coccinelle/api/kfree_mismatch.cocci --no-includes
--include-headers
--dir . -I ./arch/x86/include -I ./arch/x86/include/generated -I
./include -I
./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I
./include/uapi
-I ./include/generated/uapi --include ./include/linux/compiler-version.h
--include ./include/linux/kconfig.h --jobs 4 --chunksize 1
in the kernel source tree (which is also what
make coccicheck COCCI=scripts/coccinelle/api/kfree_mismatch.cocci
does), I get:
Cannot find Python library
When running that under strace I see it tries to execute "python":
$ strace -f -e execve,openat /usr/bin/spatch -D report --no-show-diff
--very-quiet --cocci-file scripts/coccinelle/api/kfree_mismatch.cocci
--no-includes --include-headers --dir . -I ./arch/x86/include -I
./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I
./arch/x86/include/generated/uapi -I ./include/uapi -I
./include/generated/uapi
--include ./include/linux/compiler-version.h --include
./include/linux/kconfig.h --jobs 4 --chunksize 1
execve("/usr/bin/spatch", ["/usr/bin/spatch", "-D", "report",
"--no-show-diff",
"--very-quiet", "--cocci-file", "scripts/coccinelle/api/kfree_mis"...,
"--no-includes", "--include-headers", "--dir", ".", "-I",
"./arch/x86/include",
"-I", "./arch/x86/include/generated", "-I", "./include", "-I",
"./arch/x86/include/uapi", "-I", "./arch/x86/include/generated/uap"...,
"-I",
"./include/uapi", "-I", "./include/generated/uapi", "--include",
"./include/linux/compiler-version"..., "--include",
"./include/linux/kconfig.h", "--jobs", "4", "--chunksize", ...],
0x7fffea5dc7a8
/* 49 vars */) = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpcre.so.3",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC)
= 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0",
O_RDONLY|O_CLOEXEC) =
3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC)
= 3
openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC)
= 3
openat(AT_FDCWD, "/dev/urandom", O_RDONLY) = 3
openat(AT_FDCWD, "scripts/coccinelle/api/kfree_mismatch.cocci",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, ".cocciconfig", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/usr/lib/coccinelle/standard.h", O_RDONLY|O_CLOEXEC)
= 4
openat(AT_FDCWD, "scripts/coccinelle/api/kfree_mismatch.cocci",
O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "scripts/coccinelle/api/kfree_mismatch.cocci",
O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/usr/lib/coccinelle/standard.iso",
O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/usr/lib/coccinelle/standard.iso",
O_RDONLY|O_CLOEXEC) = 4
strace: Process 122721 attached
-> [pid 122721] execve("/bin/sh", ["/bin/sh", "-c", "command -v \"python\""],
0x55c019d188b0 /* 50 vars */) = 0
[pid 122721] openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) =
3
[pid 122721] openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6",
O_RDONLY|O_CLOEXEC) = 3
[pid 122721] +++ exited with 127 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=122721,
si_uid=1000,
si_status=127, si_utime=0, si_stime=0} ---
strace: Process 122722 attached
[pid 122722] execve("/bin/sh", ["/bin/sh", "-c", "ldconfig -p"],
0x55c019d188b0
/* 50 vars */) = 0
[pid 122722] openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) =
3
[pid 122722] openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6",
O_RDONLY|O_CLOEXEC) = 3
[pid 122722] +++ exited with 127 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=122722,
si_uid=1000,
si_status=127, si_utime=0, si_stime=0} ---
Cannot find Python library
+++ exited with 255 +++
When installing python-is-python3 the spatch command above start to do
something sensible. I'm not entirely sure but I think this is a problem
in the coccinelle binary and not the cocci patch. As coccinelle depends
on python3:any it should better try to call python3 explicitly.
Perhaps you didn't rerun make distclean, autogen and configure after removing
python 2.7?
Note this is a bug report about a binary package as provided by Debian.
So I obviously didn't run distclean and autogen, I only did
apt install coccinelle
and the spatch executable installed this way
Bug#1023653: coccinelle: Picks up wrong Python
Package: coccinelle
Version: 1.1.1.deb-1+b2
Severity: normal
X-Debbugs-Cc: uklei...@debian.org, nicolas.pa...@univ-grenoble-alpes.fr,
julia.law...@inria.fr
Hello,
when I run
/usr/bin/spatch -D report --no-show-diff --very-quiet --cocci-file
scripts/coccinelle/api/kfree_mismatch.cocci --no-includes --include-headers
--dir . -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I
./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi
-I ./include/generated/uapi --include ./include/linux/compiler-version.h
--include ./include/linux/kconfig.h --jobs 4 --chunksize 1
in the kernel source tree (which is also what
make coccicheck COCCI=scripts/coccinelle/api/kfree_mismatch.cocci
does), I get:
Cannot find Python library
When running that under strace I see it tries to execute "python":
$ strace -f -e execve,openat /usr/bin/spatch -D report --no-show-diff
--very-quiet --cocci-file scripts/coccinelle/api/kfree_mismatch.cocci
--no-includes --include-headers --dir . -I ./arch/x86/include -I
./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I
./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi
--include ./include/linux/compiler-version.h --include
./include/linux/kconfig.h --jobs 4 --chunksize 1
execve("/usr/bin/spatch", ["/usr/bin/spatch", "-D", "report",
"--no-show-diff", "--very-quiet", "--cocci-file",
"scripts/coccinelle/api/kfree_mis"..., "--no-includes", "--include-headers",
"--dir", ".", "-I", "./arch/x86/include", "-I", "./arch/x86/include/generated",
"-I", "./include", "-I", "./arch/x86/include/uapi", "-I",
"./arch/x86/include/generated/uap"..., "-I", "./include/uapi", "-I",
"./include/generated/uapi", "--include", "./include/linux/compiler-version"...,
"--include", "./include/linux/kconfig.h", "--jobs", "4", "--chunksize", ...],
0x7fffea5dc7a8 /* 49 vars */) = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpcre.so.3",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC)
= 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC)
= 3
openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC)
= 3
openat(AT_FDCWD, "/dev/urandom", O_RDONLY) = 3
openat(AT_FDCWD, "scripts/coccinelle/api/kfree_mismatch.cocci",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, ".cocciconfig", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/usr/lib/coccinelle/standard.h", O_RDONLY|O_CLOEXEC)
= 4
openat(AT_FDCWD, "scripts/coccinelle/api/kfree_mismatch.cocci",
O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "scripts/coccinelle/api/kfree_mismatch.cocci",
O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/usr/lib/coccinelle/standard.iso",
O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/usr/lib/coccinelle/standard.iso",
O_RDONLY|O_CLOEXEC) = 4
strace: Process 122721 attached
-> [pid 122721] execve("/bin/sh", ["/bin/sh", "-c", "command -v
\"python\""], 0x55c019d188b0 /* 50 vars */) = 0
[pid 122721] openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) =
3
[pid 122721] openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6",
O_RDONLY|O_CLOEXEC) = 3
[pid 122721] +++ exited with 127 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=122721,
si_uid=1000, si_status=127, si_utime=0, si_stime=0} ---
strace: Process 122722 attached
[pid 122722] execve("/bin/sh", ["/bin/sh", "-c", "ldconfig -p"],
0x55c019d188b0 /* 50 vars */) = 0
[pid 122722] openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) =
3
[pid 122722] openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6",
O_RDONLY|O_CLOEXEC) = 3
[pid 122722] +++ exited with 127 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=122722,
si_uid=1000, si_status=127, si_utime=0, si_stime=0} ---
Cannot find Python library
+++ exited with 255 +++
When installing python-is-python3 the spatch command above start to do
something sensible. I'm not entirely sure but I think this is a problem
in the coccinelle binary and not the cocci patch. As coccinelle depends
on python3:any it should better try to call python3 explicitly.
Best regards
Uwe
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (700, 'testing-debug'), (700, 'stable-security'), (700,
'stable-debug'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500,
'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500,
'oldoldstable'), (500, 'oldstable'), (499, 'experimental')
Architecture: amd64 (x86_64)
Foreign
Bug#1021345: ddclient: makes use of "ifconfig" which isn't available in recent installations
Package: ddclient Version: 3.9.1-7 Severity: normal X-Debbugs-Cc: uklei...@debian.org Hello, root@sleazy:~# /usr/sbin/ddclient -query Can't exec "ifconfig": No such file or directory at /usr/sbin/ddclient line 1540. WARNING: cannot connect to ipdetect.dnspark.com:80 socket: IO::Socket::INET: Bad hostname 'ipdetect.dnspark.com' WARNING: found neither ipv4 nor ipv6 address use=web, web=dnspark address is NOT FOUND use=web, web=dyndns address is xx.xx.xx.xx use=web, web=loopia address is xx.xx.xx.xx Using something like ip -json a show dev $if as source would be more appropriate as the iproute2 package (which provides the ip command) has "Priority: important". Compared to that net-tools (which provides ifconfig) has only "Priority: optional". Also a Recommends on the package in use would be suitable IMHO. Best regards Uwe -- System Information: Debian Release: 11.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.16.0-rc4-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ddclient depends on: ii debconf [debconf-2.0] 1.5.77 ii init-system-helpers 1.60 ii libdata-validate-ip-perl 0.30-1 ii lsb-base 11.1.0 ii perl 5.32.1-4+deb11u2 Versions of packages ddclient recommends: pn libdigest-sha-perl ii libio-socket-inet6-perl 2.72-2.1 ii libio-socket-ssl-perl2.069-1 ii perl [libjson-pp-perl] 5.32.1-4+deb11u2 ddclient suggests no packages. -- debconf information excluded
Bug#1004979: isync: Passwords are limited to 80 chars with PassCmd, need to backport upstream patches
Control: fixed -1 1.4.3-1 Hello, > Q: Proposed solution. > A: Newer versions of isync have very trivial patches[1][2] that increase > the length of the buffer used for PassCmd. Please, consider backporting > those patches so that users of long passwords and (possibly) XOAUTH2 > could benefit from PassCmd feature on Debian Bullseye. If this is not > possible due to versions being frozen after the release, it would be > nice to at least have it in the bullseye-backports repository. > > [1]: https://sourceforge.net/p/isync/mailman/message/36721460/ > [2]: https://sourceforge.net/p/isync/mailman/message/37077329/ > > Note: I am running Devuan Chimaera which is a fork of Debian Bullseye, > but this package comes directly from Debian repositories and I have > confirmed this issue exists in Debian by inspecting the source code from > https://packages.debian.org/bullseye/isync. Note that the patches referenced above are included in v1.3.3 upstream. (v1.3.2~22 and v1.3.3~5 respectively.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1017821: /usr/share/bash-completion/completions/git: git: bash-completion doesn't know about git log --ancestry-path
Package: git Version: 1:2.37.2-1 Severity: normal File: /usr/share/bash-completion/completions/git X-Debbugs-Cc: uklei...@debian.org Hello, when pressing in bash after having typed git log --an this gets completed to --anchored, however there is also --ancestry-path. Best regards Uwe -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'stable-security'), (700, 'stable-debug'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable'), (499, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-trunk-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git depends on: ii git-man 1:2.37.2-1 ii libc62.34-3 ii libcurl3-gnutls 7.84.0-2 ii liberror-perl0.17029-1 ii libexpat12.4.8-1 ii libpcre2-8-0 10.40-1 ii perl 5.34.0-5 ii zlib1g 1:1.2.11.dfsg-4 Versions of packages git recommends: ii ca-certificates 20211016 ii less 590-1 ii openssh-client [ssh-client] 1:9.0p1-1+b1 ii patch2.7.6-7 Versions of packages git suggests: ii gettext-base 0.21-6 pn git-cvs pn git-daemon-run | git-daemon-sysvinit pn git-doc ii git-email 1:2.37.2-1 ii git-gui 1:2.37.2-1 pn git-mediawiki ii git-svn 1:2.37.2-1 ii gitk 1:2.37.2-1 pn gitweb -- no debconf information
Bug#705566: date does not read the timezone from the environment variable TZ, and there is no other way to view from the CLI times in other timezones.
On Sun, May 05, 2013 at 05:43:38PM -0600, Bob Proulx wrote: > severity 705566 normal > thanks > > Laurence Maddox wrote: > > I get this output: > > Current default time zone: 'America/Chicago' > > Local time is now: Tue Apr 16 14:45:29 CDT 2013. > > Universal Time is now: Tue Apr 16 19:45:29 UTC 2013. > > Looks okay. What output did you expect? > > > I need to view on the CLI the time in various timezones. > > ... > > I have searched for the "right" way to complete my task, and found a link > > here: > > http://www.linuxquestions.org/questions/programming-9/display-different-timezones-in-command-line-927660/ > > > > That link recommends that I complete my task using a command like this one: > > TZ=UTC date && TZ=CDT date && TZ=IST date > > The concept is reasonable but you must pick a correct timezone for > what you want to accomplish. UTC is okay. But CDT and IST are > meaningless to libc. The GNU libc has no concept of invalid > timezones. If a timezone doesn't match anything else then the default > is that it is a name for UTC. So basically you have asked for UTC > three times in a row. I stumbled about a similar thing just now and would consider this behaviour at least inconsistent: uwe@taurus:/usr/share/zoneinfo$ TZ=Europe/London date Fri Aug 12 11:13:34 AM BST 2022 uwe@taurus:/usr/share/zoneinfo$ TZ=BST date Fri Aug 12 10:13:38 AM BST 2022 The first one is the right one, but there is no way to determine the latter to be wrong. Apart from the offset the output is identical and if you're not aware that TZ=BST is wrong you have no chance to notice that. If it at least said "Fri Aug 12 11:13:38 AM UTC 2022" or (better yet) dies with an error code that would be highly convenient. And given that the timezone specifier in the output is "BST" (in both cases!) noticing that TZ=BST is wrong isn't as trivial as it should be. Note that using -R doesn't help here either because then I have to notice that "+" is wrong, but to find the offset from me to BST was the actual task to solve here ... Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1013288: gnupg: Doesn't show uid expiry
Package: gnupg Version: 2.2.35-2 Severity: normal X-Debbugs-Cc: uklei...@debian.org Hello, uwe@taurus:~$ export GNUPGHOME=$(mktemp -d) uwe@taurus:~$ curl -s https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/plain/keys/6637D326999B862C.asc | gpg --import gpg: keybox '/tmp/tmp.S4Xeh1pmja/pubring.kbx' created gpg: key 6637D326999B862C: 3 signatures not checked due to missing keys gpg: /tmp/tmp.S4Xeh1pmja/trustdb.gpg: trustdb created gpg: key 6637D326999B862C: public key "Philipp Zabel " imported gpg: Total number processed: 1 gpg: imported: 1 gpg: no ultimately trusted keys found uwe@taurus:~$ gpg --with-colons --check-sigs 6637D326999B862C tru::1:1655760525:0:3:1:5 pub:-:4096:1:6637D326999B862C:1402826245:1664799531::-:::scESC::23::0: fpr:27C6398DC5B132E22A8D2B516637D326999B862C: uid:-1633263532::645CAC3041C5B2B3F7D7169DC0216C1B2ACB8711::Philipp Zabel ::0: sig:?::1:0BE9E3157A1E2C64:1403019369:10x:2: sig:!::1:6637D326999B862C:1633263532Philipp Zabel :13x::27C6398DC5B132E22A8D2B516637D326999B862C:::8: uid:-1599034236::834E8111DE69C80CC6C776EEBD2DD3BB50DCD452::Philipp Zabel ::0: sig:?::1:0BE9E3157A1E2C64:1403019369:10x:2: sig:!::1:6637D326999B862C:1599034236Philipp Zabel :13x::27C6398DC5B132E22A8D2B516637D326999B862C:::8: uid:-1633263531::46A0A420CBEFD71A9CE3EFCCDC59B187D056C137::Philipp Zabel ::0: sig:?::1:0BE9E3157A1E2C64:1403019369:10x:2: sig:!::1:6637D326999B862C:1633263531Philipp Zabel :13x::27C6398DC5B132E22A8D2B516637D326999B862C:::8: sub:-:4096:1:8FCC408DE8F7F370:1402826245:1664799540:e::23: fpr:40ACEFA243542A5ADBFA706C8FCC408DE8F7F370: sig:!::1:6637D326999B862C:1633263540Philipp Zabel :18x::27C6398DC5B132E22A8D2B516637D326999B862C:::8: sub:-:4096:1:50C2881C709E60EB:1402828631:1664799540:s::23: fpr:06C071855D4568AC17B8238150C2881C709E60EB: sig:!::1:6637D326999B862C:1633263540Philipp Zabel :18x::27C6398DC5B132E22A8D2B516637D326999B862C:::8: sub:-:255:22:D585A725183762C0:1526278694:1664799540:s:ed25519:: fpr:513BA17A59DA47D51D2F1A26D585A725183762C0: sig:!::1:6637D326999B862C:1633263540Philipp Zabel :18x::27C6398DC5B132E22A8D2B516637D326999B862C:::8: so the key seems to have three valid uids. However the pengutronix.de uid isn't valid any more according to hokey (marked with an arrow): uwe@taurus:~$ gpg --export 6637D326999B862C | hokey lint hokey (hopenpgp-tools) 0.23.6 Copyright (C) 2012-2021 Clint Adams hokey comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. Key has potential validity: good Key has fingerprint: 27C6 398D C5B1 32E2 2A8D 2B51 6637 D326 999B 862C Checking to see if key is OpenPGPv4: V4 Checking the strength of your primary asymmetric key: RSA 4096 Checking user-ID- and user-attribute-related items: Philipp Zabel : Self-sig hash algorithms: [SHA-256] Preferred hash algorithms: [SHA-512, SHA-384, SHA-256, SHA-224] --> Key expiration times: [7y2m18d25991s = Thu Sep 2 08:10:36 UTC 2021] Key usage flags: [[sign-data, certify-keys]] Philipp Zabel : Self-sig hash algorithms: [SHA-256] Preferred hash algorithms: [SHA-512, SHA-384, SHA-256, SHA-224] Key expiration times: [8y3m18d67886s = Mon Oct 3 12:18:51 UTC 2022] Key usage flags: [[sign-data, certify-keys]] Philipp Zabel : Self-sig hash algorithms: [SHA-256] Preferred hash algorithms: [SHA-512, SHA-384, SHA-256, SHA-224] Key expiration times: [8y3m18d67886s = Mon Oct 3 12:18:51 UTC 2022] Key usage flags: [[sign-data, certify-keys]] Checking subkeys: one of the subkeys is encryption-capable: True fpr: 40AC EFA2 4354 2A5A DBFA 706C 8FCC 408D E8F7 F370 version: v4 timestamp: 20140615-095725 algo/size: RSA 4096 binding sig hash algorithms: [SHA-256] usage flags: [[encrypt-storage, encrypt-communications]] embedded cross-cert: False cross-cert hash algorithms: [SHA-256] fpr: 06C0 7185 5D45 68AC 17B8 2381 50C2 881C 709E 60EB version: v4 timestamp: 20140615-103711 algo/size: RSA 4096 binding sig hash algorithms: [SHA-256] usage flags: [[sign-data]] embedded cross-cert: True cross-cert hash algorithms: [SHA-256] fpr: 513B A17A 59DA 47D5 1D2F 1A26 D585 A725 1837 62C0 version: v4
Bug#1013263: abcde: Suggest to install opus-tools
Package: abcde Version: 2.9.3-1 Severity: normal X-Debbugs-Cc: uklei...@debian.org Hello, $ abcde -o opus -d myinput [ERROR] abcde: opusenc is not in your path. [INFO] Define the full path to the executable if it exists on your system. [INFO] Hint: sudo apt-get install I suggest to add "opus-tools" to the last line. Best regards Uwe -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'stable-security'), (700, 'stable-debug'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable'), (499, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages abcde depends on: ii cd-discid 1.4-1+b1 ii cdparanoia 3.10.2+debian-14 ii flac1.3.4-2 ii libmusicbrainz-discid-perl 0.06-1+b2 ii libwebservice-musicbrainz-perl 1.0.4-2 ii opus-tools 0.1.10-1.1 ii sensible-utils 0.0.17 ii vorbis-tools1.4.2-1 ii wget1.21.3-1+b2 Versions of packages abcde recommends: ii bsd-mailx8.1.2-0.20220412cvs-1 ii glyrc1.0.10-1 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3+b2 ii perl [libdigest-sha-perl]5.34.0-4 ii vorbis-tools 1.4.2-1 Versions of packages abcde suggests: pn atomicparsley pn distmp3 ii eject2.38-4 pn eyed3 pn id3 pn id3v2 pn mkcue pn mp3gain pn normalize-audio pn vorbisgain -- no debconf information
Bug#1006568: rauc: FTBFS with OpenSSL 3.0
On Mon, Feb 28, 2022 at 09:16:45AM +0100, Jan Lübbe wrote: > On Sun, 27 Feb 2022 22:15:45 +0100 Sebastian Andrzej Siewior > wrote: > > Your package is failing to build using OpenSSL 3.0 with the > > following error: > > > > |Creating bundle in 'plain' format > > |C08ACC46967F:error:12800067:DSO support routines:DSO_load:could not > > load the shared library:../crypto/dso/dso_lib.c:152: > > |C08ACC46967F:error:1384:engine routines:dynamic_load:dso not > > found:../crypto/engine/eng_dyn.c:422: > > |C08ACC46967F:error:1374:engine routines:ENGINE_by_id:no such > > engine:../crypto/engine/eng_list.c:430:id=pkcs11 > > |not ok 20 - rauc bundle with PKCS11 (key 1) > > |FAIL: test/rauc.t 20 - rauc bundle with PKCS11 (key 1) > > This seems to be caused by a missing PKCS#11 OpensSSL engine. RAUC's test > suite > uses SoftHSM to test the PKCS#11 support, so it needs a working PKCS#11 engine > and module matching the active OpenSSL. In Debian, the engine is provided by > libp11 (in libengine-pkcs11-openssl) and the module is provided by SoftHSM (in > libsofthsm2). > > Neither of libp11 nor SoftHSM have been updated to OpenSSL 3 in Debian yet, so > the PKCS#11 tests can't work. Without PKCS#11 support, RAUC should already > work > with OpenSSL 3, though. As soon as the dependencies are updated, PKCS#11 in > RAUC > should work as well without further changes to RAUC. I just confirmed that. I built libp11 in sid + openssl3. With the resulting packages installed rauc just builds fine against openssl3. So I'm unsure what I should do about this bug. Close it? Reassign to libp11? Just wait until it resolves itself? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#1010147: mutt 2.x broke workflow in mailbox handling with history changes
Package: mutt Version: 2.0.2-1 Severity: normal Tags: upstream fixed-upstream X-Debbugs-Cc: r.schwe...@pengutronix.de Control: forwarded -1 https://gitlab.com/muttmua/mutt/-/issues/396 Control: fixed -1 2.2.3-1 Hello, mutt 2.x broke some workflow here, which is explained in detail in the upstream bug report available at https://gitlab.com/muttmua/mutt/-/issues/396. The gist is that the edit-fcc and the save-to prompt use different histories. This was also fixed upstream in commit bce2c294b27808f9373afa1ada61719f57d20e59 for master and stable. So upstream is fixed since 2.2.2 and the affected versions in Debian are 2.0.5-4.1 in bullseye/stable and 2.0.2-1~bpo10+1 in old-bpo. I'd like to have that fixed in Debian---ideally in stable--- and wonder what is the best way forward. The obvious options are a) apply the patch to 2.0.5-4.1 and upload to proposed updates b) add a backport or 2.2.3-1 to bpo Given that upstream considered this change worth to be applied to their stable branch, I would consider option a) justified. What is your opionion here? I can prepare an nmudiff for option a) if you're ok with that option and also offer to actually to nmu. (But having you upload would be my preferred way.) Best regards Uwe
Bug#1008002: installation-reports: wifi hardware not available, otherwise fine
Hello, On 3/20/22 13:38, Uwe Kleine-König wrote: the builtin wifi hardware (broadcom) wasn't autodetected. I didn't look into it yet, doesn't work out-of-the-box in the installed system either. FTR: The right driver is contained in the broadcom-sta-dkms package. With that the hardware seems to work fine. Best regards Uwe OpenPGP_signature Description: OpenPGP digital signature
Bug#1008002: installation-reports: wifi hardware not available, otherwise fine
Package: installation-reports Severity: normal X-Debbugs-Cc: u...@kleine-koenig.org Boot method: SD card Image version: firmware-11.2.0-amd64-i386-netinst Date: 2022-03-20 Machine: Apple MacBook Air Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Hello, the builtin wifi hardware (broadcom) wasn't autodetected. I didn't look into it yet, doesn't work out-of-the-box in the installed system either. After the installation noticed there is no network device available, I plugged in an usb wifi dongle. I couldn't make this work, but when I restarted the installation with the wifi dongle plugged in from the start it worked fine. I didn't record the error messages, but if you want to investigate I can reproduce and provide some logging contents. Best regards Uwe -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u2" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux autonoe 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 09) lspci -knn: Subsystem: Apple Inc. Device [106b:011b] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a26] (rev 09) lspci -knn: Subsystem: Apple Inc. Device [106b:011b] lspci -knn: 00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller [8086:0a0c] (rev 09) lspci -knn: Subsystem: Apple Inc. Device [106b:011b] lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) lspci -knn: Subsystem: Intel Corporation Apple MacBookAir6,2 / MacBookPro11,1 [8086:7270] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:15.0 DMA controller [0801]: Intel Corporation 8 Series Low Power Sub-System DMA [8086:9c60] (rev 04) lspci -knn: 00:15.4 Serial bus controller [0c80]: Intel Corporation 8 Series SPI Controller #1 [8086:9c66] (rev 04) lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 8 Series HECI #0 [8086:9c3a] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 8 Series HD Audio Controller [8086:9c20] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 1 [8086:9c10] (rev e4) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 3 [8086:9c14] (rev e4) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 5 [8086:9c18] (rev e4) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.5 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 6 [8086:9c1a] (rev e4) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller [8086:9c43] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller [8086:9c22] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 02:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03) lspci -knn: Subsystem: Apple Inc. Device [106b:0117] lspci -knn: Kernel driver in use: bcma-pci-bridge lspci -knn: Kernel modules: bcma lspci -knn: 03:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SS9183 PCIe SSD Controller [1b4b:9183] (rev 14) lspci -knn: Subsystem: Marvell Technology Group Ltd. 88SS9183 PCIe SSD Controller [1b4b:9183] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -knn: 04:00.0 PCI bridge [0604]: Intel Corporation DSL3510 Thunderbolt Controller [Cactus Ridge 4C 2012] [8086:1547] (rev 03) lspci -knn: Kernel driver in use: pcieport lspci -knn: 05:00.0 PCI bridge [0604]: Intel Corporation DSL3510 Thunderbolt Controller [Cactus Ridge 4C 2012]
Bug#1006766: reprepro: Duplicated keyid in error message on signing failure
Package: reprepro
Version: 4.4.0-1
Severity: normal
Tags: patch upstream
Hello,
on the host I use reprepro on there is some (not yet debugged) problem
with gpg. reprepro emits:
Error: gpgme returned NULL unexpectedly for gpgme_op_sign_result
This most likely means gpg is confused or produces some error libgpgme
is
not able to understand. Try running
gpg -u 'EEE8DC4DCFBE7252' -u 'EEE8DC4DCFBE7252' --output
'some-other-file' --detach-sign 'some-file'
for hints what this error might have been. (Sometimes just running
it once manually seems also to help...)
The irritating thing is that the option -u 'EEE8DC4DCFBE7252' is printed
twice.
The following patch fixes it and emits the right key ids:
diff --git a/signedfile.c b/signedfile.c
index 08efac91d888..2dfa348aeb96 100644
--- a/signedfile.c
+++ b/signedfile.c
@@ -57,7 +57,7 @@ static retvalue check_signature_created(bool clearsign, bool
willcleanup, /*@nul
uidoptions != NULL && i < options->count ;
i++) {
char *u = mprintf("%s -u '%s'", uidoptions,
- options->values[0]);
+ options->values[i]);
free(uidoptions);
uidoptions = u;
}
The problem was introduced in b344a0710f030c5eace3f0cee663583da74789e8
(= reprepro-4.4.0~8)
Best regards
Uwe
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (700, 'testing-debug'), (700, 'stable-security'), (700,
'stable-debug'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500,
'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500,
'oldoldstable'), (500, 'oldstable'), (499, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64
Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages reprepro depends on:
ii libarchive13 3.5.2-1
ii libbz2-1.0 1.0.8-5
ii libc6 2.33-5
ii libdb5.3 5.3.28+dfsg1-0.8
ii libgpg-error0 1.43-3
ii libgpgme11 1.16.0-1.2
ii liblzma5 5.2.5-2
ii zlib1g 1:1.2.11.dfsg-2
ii zstd 1.4.8+dfsg-3
Versions of packages reprepro recommends:
ii apt 2.3.15
Versions of packages reprepro suggests:
ii gnupg-agent 2.2.27-3
ii gpg-agent [gnupg-agent] 2.2.27-3
pn inoticoming
ii lzip 1.22-5
ii pinentry-curses 1.1.0-4
-- no debconf information
Bug#1005939: libccid: invoke-rc.d pcscd restart might fail in postinst
Hello Ludovic, On 2/18/22 10:47, Ludovic Rousseau wrote: Le 17/02/2022 à 16:33, Uwe Kleine-König a écrit : I think the fix is to not restart pcscd when libccid is updated. Other libs also don't care for their consumers and it's a well-known (to me at least) duty to check for binaries using old versions of an updated lib after a package update. I restart pcscd so that the list of supported smart card readers is reloaded by pcscd. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995814#15 I understand that here is an upside to restarting pcscd. But IMHO the downsides outweight that. Why do you install pcscd if you mask it? What is your use case? I have pcscd since I installed yubikey-manager. I masked pcscd because it sometimes interfered with yubikey usage. I don't remember the exact details, it's some time ago already. Best regards Uwe OpenPGP_signature Description: OpenPGP digital signature
Bug#1005939: libccid: invoke-rc.d pcscd restart might fail in postinst
Package: libccid Version: 1.5.0-1 Severity: important Hello, I currently encounter: uwe@taurus:~$ sudo apt install Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 626 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up libccid (1.5.0-1) ... Failed to restart pcscd.service: Unit pcscd.socket is masked. invoke-rc.d: initscript pcscd, action "restart" failed. ○ pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; vendor preset: enabled) Active: inactive (dead) Docs: man:pcscd(8) dpkg: error processing package libccid (--configure): installed libccid package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: libccid E: Sub-process /usr/bin/dpkg returned an error code (1) This is similar to #1001155, but a bit more hairy to fix, because libccid restarts a service that isn't "owned" by the package. I think the fix is to not restart pcscd when libccid is updated. Other libs also don't care for their consumers and it's a well-known (to me at least) duty to check for binaries using old versions of an updated lib after a package update. (Side note: libccid doesn't even transitively depend on pcscd, so I can even make libccid's postinst fail with: invoke-rc.d: unknown initscript, /etc/init.d/pcscd not found. .) Best regards Uwe -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'stable-security'), (700, 'stable-debug'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable'), (499, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libccid depends on: ii libc6 2.33-5 ii libusb-1.0-0 2:1.0.24-3 libccid recommends no packages. Versions of packages libccid suggests: pn pcmciautils -- no debconf information
Bug#1004469: yamllint: Dies with a TypeError
Package: yamllint
Version: 1.26.3-1
Severity: normal
Hello,
$ cat l.yaml
---
mylist:
- |
blablub
};
$ yamllint l.yaml
Traceback (most recent call last):
File "/usr/bin/yamllint", line 33, in
sys.exit(load_entry_point('yamllint==1.26.3', 'console_scripts',
'yamllint')())
File "/usr/lib/python3/dist-packages/yamllint/cli.py", line 210, in
run
prob_level = show_problems(problems, file, args_format=args.format,
File "/usr/lib/python3/dist-packages/yamllint/cli.py", line 106, in
show_problems
for problem in problems:
File "/usr/lib/python3/dist-packages/yamllint/linter.py", line 203,
in _run
for problem in get_cosmetic_problems(buffer, conf, filepath):
File "/usr/lib/python3/dist-packages/yamllint/linter.py", line 140,
in get_cosmetic_problems
for problem in rule.check(rule_conf,
File "/usr/lib/python3/dist-packages/yamllint/rules/indentation.py",
line 580, in check
for problem in _check(conf, token, prev, next, nextnext, context):
File "/usr/lib/python3/dist-packages/yamllint/rules/indentation.py",
line 346, in _check
'wrong indentation: expected %d but found %d' %
TypeError: %d format: a number is required, not NoneType
I guess the right thing to do would be to output something like:
l.yaml
5:5 errorsyntax error: expected , but found '}'
(syntax)
(At least this is what happens if I force expected to be a number in
/usr/lib/python3/dist-packages/yamllint/rules/indentation.py", line 346)
Best regards
Uwe
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (700, 'testing-debug'), (700, 'stable-security'), (700,
'stable-debug'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500,
'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500,
'oldoldstable'), (500, 'oldstable'), (499, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64
Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages yamllint depends on:
ii python33.9.7-1
ii python3-pathspec 0.9.0-1
ii python3-pkg-resources 59.6.0-1.2
ii python3-yaml 5.4.1-1+b1
yamllint recommends no packages.
yamllint suggests no packages.
-- no debconf information
Bug#1003320: reprepro: zstd support
Hello,
[adding Dimitri to Cc who uploaded -1.3, sorry for forgetting this in
the initial report]
On 1/8/22 10:45, Uwe Kleine-König wrote:
reprepro in experimental (5.3.0-1.3) contains support for zstd
compressed packages. If I understand correctly this is needed for
tracking packages from Ubuntu. Their dpkg supports zstd since Bionic
(18.04.x)[1] and they consider backporting it to even xenial
(16.04.x)[2]. IIUC Ubuntu uses zstd by default since 21.04 ("Hirsute").
Looking at bash, bash/hirsute still uses xz, but bash/impish uses zstd.
Ubuntu includes 5.3.0-1.3 and there are no relevant bug reports.
So I suggest to put the changes into unstable. I intend to upload
reprepro 5.3.0-1.4 in a week from now which only differes from -1.3 by
the version and the target release. Tell me when you object.
/me meant s/when/if/ of course.
Anyhow, I noticed that -1.3 changed Vcs-Git in d/control which I
consider at least unusual. The history contained there and the tags
don't match completely what was actually uploaded. (But maybe this is
just me not liking and understanding git-dpm?)
I tend to undo this change, yielding the following debdiff for -1.4:
diff -Nru reprepro-5.3.0/debian/changelog reprepro-5.3.0/debian/changelog
--- reprepro-5.3.0/debian/changelog 2021-06-21 11:16:53.0 +0200
+++ reprepro-5.3.0/debian/changelog 2022-01-08 16:10:13.0 +0100
@@ -1,3 +1,11 @@
+reprepro (5.3.0-1.4) unstable; urgency=medium
+
+ * Non-maintainer upload to unstable (Closes: #1003320)
+ * Revert Vcs-Git and Vcs-Browser changes in 5.3.0-1.3 so it points to the
+maintainer's repository again.
+
+ -- Uwe Kleine-König Sat, 08 Jan 2022 16:10:13 +0100
+
reprepro (5.3.0-1.3) experimental; urgency=medium
* Non-maintainer upload.
diff -Nru reprepro-5.3.0/debian/control reprepro-5.3.0/debian/control
--- reprepro-5.3.0/debian/control 2021-06-21 11:11:30.0 +0200
+++ reprepro-5.3.0/debian/control 2022-01-08 16:10:13.0 +0100
@@ -4,8 +4,8 @@
Maintainer: Bernhard R. Link
Build-Depends: debhelper (>= 10), libgpgme-dev, libdb-dev, libz-dev,
libbz2-dev, liblzma-dev, libarchive-dev
Standards-Version: 4.3.0
-Vcs-Browser: https://salsa.debian.org/debian/reprepro
-Vcs-Git: https://salsa.debian.org/debian/reprepro.git -b debian
+Vcs-Browser: https://salsa.debian.org/brlink/reprepro
+Vcs-Git: https://salsa.debian.org/brlink/reprepro.git -b debian
Package: reprepro
Architecture: any
The git history I worked on is available at
https://salsa.debian.org/ukleinek/reprepro.git.
Best regards
Uwe
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1003320: reprepro: zstd support
Package: reprepro
Version: 5.3.0-1.2
Severity: normal
Hello,
reprepro in experimental (5.3.0-1.3) contains support for zstd
compressed packages. If I understand correctly this is needed for
tracking packages from Ubuntu. Their dpkg supports zstd since Bionic
(18.04.x)[1] and they consider backporting it to even xenial
(16.04.x)[2]. IIUC Ubuntu uses zstd by default since 21.04 ("Hirsute").
Looking at bash, bash/hirsute still uses xz, but bash/impish uses zstd.
Ubuntu includes 5.3.0-1.3 and there are no relevant bug reports.
So I suggest to put the changes into unstable. I intend to upload
reprepro 5.3.0-1.4 in a week from now which only differes from -1.3 by
the version and the target release. Tell me when you object.
Best regards
Uwe
[1] https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1923845
[2] https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1764220
Bug#1002219: [PATCH] t/eml.t: ignore newer Email::MIME behavior
Hello Eric,
On 12/30/21 20:17, Eric Wong wrote:
Uwe Kleine-König wrote:
Hello,
adding the Debian Perl Group to Cc, maybe they can help here.
(for context look at https://bugs.debian.org/1002219)
On 12/30/21 10:12, Uwe Kleine-König wrote:
I got a bug report against the public-inbox 1.6.1 package about a
failing test, see below for the whole output. I didn't have time yet to
look into it, so this is just a heads up to make you aware. If someone
has a hint what to do, this would be greatly appreciated. Maybe just
updating to 1.7 will help?
Best regards
Uwe
On 12/21/21 17:34, Lucas Nussbaum wrote:
# Failed test 'filename decoded'
# at t/eml.t line 407.
# got: '=?utf-8?q?vtpm-makefile.patch?='
# expected: 'vtpm-makefile.patch'
# Looks like you failed 1 test of 146.
t/eml.t ..
I can reproduce this problem with 1.6.1 checked out. I played a bit around
(suffering from my weak perl foo) and found that when I downgrade
libemail-mime-perl from 1.952-1 (i.e. Debian unstable's version) to 1.949-1
(i.e. Debian stable's version), this works.
The reproducer is:
$ perl -e 'use Email::MIME; print Email::MIME->new("Content-Type:
text/x-patch; name=\"=?utf-8?q?vtpm-fakefile.patch?=\"\nContent-Disposition:
attachment; filename=\"=?utf-8?q?vtpm-makefile.patch?=\"\n\n")->filename;'
which emits "vtpm-makefile.patch" with 1.949-1 (as public-inbox expects),.
but =?utf-8?q?vtpm-makefile.patch?= with 1.952-1.
So the key question is: Is the test correct and his is a regression in
libemail-mime-perl, or is the test wrong and we need to fix the test (and
PublicInbox::Eml)?
I thought I sent a fix to this; but I nuked the root FS on one of
my workstations on accident :< Still recovering...
Oh, good luck in restoring your precious data.
Thanks for your patch. I just uploaded public-inbox with this change to
fix the bug.
I still wonder if this is a regression in Email::MIME, or just a wrong
expectation. In the first case I'd open a bug against libemail-mime-perl.
Bisecting in https://github.com/rjbs/Email-MIME.git yields
https://github.com/rjbs/Email-MIME/commit/8a7cffd2b1091ff1a750d541a85e1813a6747b72
as breaking commit. So this looks like an intended change.
Best regards
Uwe
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1002219: public-inbox: FTBFS: dh_auto_test: error: make -j4 test TEST_VERBOSE=1 returned exit code 2
Hello,
adding the Debian Perl Group to Cc, maybe they can help here.
(for context look at https://bugs.debian.org/1002219)
On 12/30/21 10:12, Uwe Kleine-König wrote:
I got a bug report against the public-inbox 1.6.1 package about a
failing test, see below for the whole output. I didn't have time yet to
look into it, so this is just a heads up to make you aware. If someone
has a hint what to do, this would be greatly appreciated. Maybe just
updating to 1.7 will help?
Best regards
Uwe
On 12/21/21 17:34, Lucas Nussbaum wrote:
# Failed test 'filename decoded'
# at t/eml.t line 407.
# got: '=?utf-8?q?vtpm-makefile.patch?='
# expected: 'vtpm-makefile.patch'
# Looks like you failed 1 test of 146.
t/eml.t ..
I can reproduce this problem with 1.6.1 checked out. I played a bit
around (suffering from my weak perl foo) and found that when I downgrade
libemail-mime-perl from 1.952-1 (i.e. Debian unstable's version) to
1.949-1 (i.e. Debian stable's version), this works.
The reproducer is:
$ perl -e 'use Email::MIME; print Email::MIME->new("Content-Type:
text/x-patch;
name=\"=?utf-8?q?vtpm-fakefile.patch?=\"\nContent-Disposition:
attachment; filename=\"=?utf-8?q?vtpm-makefile.patch?=\"\n\n")->filename;'
which emits "vtpm-makefile.patch" with 1.949-1 (as public-inbox
expects), but =?utf-8?q?vtpm-makefile.patch?= with 1.952-1.
So the key question is: Is the test correct and his is a regression in
libemail-mime-perl, or is the test wrong and we need to fix the test
(and PublicInbox::Eml)?
Best regards
Uwe
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1001155: Fails to update when service is masked
Package: pcscd
Version: 1.9.5-1
Followup-For: Bug #1001155
Hello,
I just encountered the same problem. Digging into it (and before having
found this bug in the BTS) I saw the postinst script of pcscd restarts
the daemon twice. Once explicitly in debian/pcscd.postinst:
case "$1" in
configure|reconfigure)
# restart pcscd (PCSC daemon)
invoke-rc.d pcscd restart
;;
and again later added by dh_installinit/13.5.2:
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -z "${DPKG_ROOT:-}" ] && [ -x "/etc/init.d/pcscd" ]; then
update-rc.d pcscd defaults >/dev/null
invoke-rc.d --skip-systemd-native pcscd restart || exit
1
fi
fi
Even if you consider it a bug to mask pcscd.socket but not pcscd.service
(I disagree BTW), I still ask you to remove the explicit call to
invoke-rc.d pcscd restart, as the snippet added by dh_installinit should
serve the same purpose and this doesn't fail with pcscd.socket masked.
The latter invocation of invoke-rc.d is also better as it honors policy
9.3.3 "Maintainer scripts for packages including init scripts must use
update-rc.d [...]." So keeping the status quo might even justify a
serious severity for this bug.
(Note: There is one relevant difference, where I'm unsure if the snippet
added by dh_installinit is better: The explicit call also triggers for
$1 == reconfigure.)
Best regards
Uwe
Bug#947179: linux-image-5.3.0-3-amd64: Please provide CoreBoot (Google) firmware drivers
Hello Tobias, On Sun, Dec 22, 2019 at 04:45:12PM +0100, Tobias Gruetzmacher wrote: > Package: src:linux > Version: 5.3.15-1 > Severity: wishlist > > it would be nice if the Debian kernel would provide drivers to interact > with CoreBoot. As far as I can see, those are "hidden" behind > CONFIG_GOOGLE_FIRMWARE ... > > These seem to be all available as modules, so it won't hurt to switch > them on, right? (If I understand drivers/firmware/google/Makefile > correctly) > > For reference: > > CONFIG_GOOGLE_FIRMWARE=y > CONFIG_GOOGLE_SMI=m > CONFIG_GOOGLE_COREBOOT_TABLE=m > CONFIG_GOOGLE_MEMCONSOLE=m > CONFIG_GOOGLE_MEMCONSOLE_X86_LEGACY=m > CONFIG_GOOGLE_FRAMEBUFFER_COREBOOT=m > CONFIG_GOOGLE_MEMCONSOLE_COREBOOT=m > CONFIG_GOOGLE_VPD=m The helptext for GOOGLE_FIRMWARE reads: These firmware drivers are used by Google's servers. They are only useful if you are working directly on one of their proprietary servers. If in doubt, say "N". Is this text wrong, or are you working on Google's servers? In case you're not on Google's servers: Did you verify these settings are beneficial on your machine? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#999562: b4: Fails to attest without additional dependency installed
Package: b4 Version: 0.8.0-1 Severity: normal Hello, uwe@taurus:~/gsrc/linux$ b4 attest 0001-net-dsa-vsc73xxx-Make-vsc73xx_remove-return-void.patch ERROR: b4 now uses patatt for patch attestation. See: https://git.kernel.org/pub/scm/utils/patatt/patatt.git/about/ patatt doesn't seem to be packaged for Debian (at least apt search patatt doesn't yield any results.) Version 0.6.2 (i.e. the version in bullseye) is not affected. Best regards Uwe
Bug#900958: ITP: barebox-host-tools -- useful development tools from the barebox source tree
Hello, I somehow missed your reply, sorry, just found it by chance now. On Tue, Mar 30, 2021 at 12:55:58AM +0530, deepak varma wrote: > Are you looking for any further assistance with this ITP? I am willing to > assist if required. My plan is to first convert barebox to use SPDX to simplify (and only do once) the copyright stuff. If you want to help here, that would be great. I can share my scripting if you want. As you might have noticed it's not top-priority on my side, but occationally I send a conversion patch, the last one is https://git.pengutronix.de/cgit/barebox/commit/?id=e88ac96a532fbe056bf45cfa0fa1ebf28c193c41 Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#996447: /usr/bin/csharp: System.Net.WebClient fails to verify letsencrypt SSL chains that include the expired "DST Root CA X3" certificate
Package: mono-csharp-shell
Version: 6.8.0.105+dfsg-3.2
Severity: normal
Hello,
csharp -e 'new System.Net.WebClient ().DownloadString
("https://letsencrypt.org/;)'
currently fails with a TrustFailure. The certificate that (currently) is
served there looks as follows:
Certificate chain
0 s:CN = lencr.org
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
(taken from
openssl s_client -connect letsencrypt.org:https
). For a similar setup webserver connecting using the above commandline
succeeds when the "DST Root CA X3" certificate is taken out of the
provided chain.
I guess the ssl verifying component in mono has the same problem as
openssl < 1.1.0, i.e. the expired "DST Root CA X3" certificate makes the
verification fail even though the "ISRG Root X1" is trusted.
This breaks keepass2 when it's setup to have the password-db on a
https-secured webdav store.
Similar bug reports can be found on the net, e.g.:
https://sourceforge.net/p/keepass/discussion/329221/thread/21747e1096/
(I don't really know about mono and so probably picked the wrong Package
to report this problem against, please reassign accordingly.)
Best regards
Uwe
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (700, 'stable-security'), (700, 'stable-debug'), (700,
'oldstable-updates'), (700, 'stable'), (700, 'oldstable'), (600, 'unstable'),
(500, 'unstable-debug'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (499,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mono-csharp-shell depends on:
ii libc6 2.31-13
ii libmono-corlib4.5-cil 6.8.0.105+dfsg-3.2
ii libmono-csharp4.0c-cil 6.8.0.105+dfsg-3.2
ii libmono-management4.0-cil 6.8.0.105+dfsg-3.2
ii libmono-system4.0-cil 6.8.0.105+dfsg-3.2
ii mono-runtime 6.8.0.105+dfsg-3.2
mono-csharp-shell recommends no packages.
mono-csharp-shell suggests no packages.
-- no debconf information
Bug#995222: python3-django-mailman3: TypeError at /accounts/fedora/login/
Package: python3-django-mailman3 Version: 1.3.5-2 Severity: normal Hello, in the file /usr/lib/python3/dist-packages/django_mailman3/lib/auth/fedora/views.py in the post function of class LoginView the function allauth.socialaccount.providers.openid.views._openid_consumer is called with a single argument. However looking at /usr/lib/python3/dist-packages/allauth/socialaccount/providers/openid/views.py (provided by python3-django-allauth 0.44.0+ds-1) this function has three mandatory arguments. The result is that if someone (in my case search machine agents several times a day :-\) clicks on the fedora button on /accounts/login this results in an internal server error and a mail report to the admin address. Best regards Uwe -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-django-mailman3 depends on: ii python33.9.2-3 ii python3-django 2:2.2.24-1 ii python3-django-allauth 0.44.0+ds-1 ii python3-django-compressor 2.4-2 ii python3-django-gravatar2 1.4.4-2 ii python3-mailmanclient 3.3.2-1 ii python3-tz 2021.1-1 python3-django-mailman3 recommends no packages. python3-django-mailman3 suggests no packages. -- no debconf information
Bug#993860: public-inbox-imapd: missing dependency libparse-recdescent-perl
Hello Nicolas, hello Eric, On 9/9/21 9:43 AM, Eric Wong wrote: Nicolas Schier wrote: Installing libparse-recdescent-perl was enough on my system to solve the issue. Perhaps you might want to add it as dependency? Indeed, I never used imapd up to now and so didn't notice this missing. Uwe: Fwiw, perhaps making more things optional via Suggests:/Recommends: and possibly splitting into several packages (e.g. public-inbox-core, public-inbox-www, public-inbox-httpd, public-inbox-imapd). I think for a package like public-inbox splitting doesn't make much sense. We're talking about a dependency that adds 424 kB. When I split public-inbox into several packages the overhead on the systems that have public-inbox installed and the Debian archives probably outweights the gain. That's why I think that even Recommends isn't sensible, so I added a Depends. In any case, I try to keep the INSTALL doc up-to-date and make most dependencies optional so users can avoid downloading and installing stuff they won't use: https://public-inbox.org/meta/?q=dfn:INSTALL=t For building from source I fully agree that having dependencies only optional is good. Best regards Uwe OpenPGP_signature Description: OpenPGP digital signature
Bug#971590: rt-tests: bump to a new upstream release
Hellp Punit, On 9/14/21 4:36 AM, Punit Agrawal wrote: Uwe Kleine-König writes: On 9/7/21 4:35 AM, Punit Agrawal wrote: I was looking to update the rt-tests package in Debian as it is lagging behind upstream. Before digging into the task, I wanted to check if you're planning to make any changes or had any patches that haven't been pushed. Pointers to any particular issues to watch out for would also be appreciated. There is nothing pending on my side and if you want to adopt rt-tests that is fine for me. ISTR that Anders Roxell showed some interest in maintaining rt-tests, too, in the past, but I cannot find the corresponding conversation. Thanks. For now I have added myself as an uploader. I am happy to work with Anders (or anybody else interested in the rt-tests package) when / if they reach out. Feel free to drop me from Uploaders. Thanks for taking over maintainace. Best regards Uwe OpenPGP_signature Description: OpenPGP digital signature
Bug#994066: flash-kernel: kernel size check doesn't take appended device tree into account
Hello, On 9/10/21 11:07 PM, Uwe Kleine-König wrote: when the active machine entry has an "Mtd-Kernel" field, flash-kernel checks if the kernel fits into the specified mtd partition. However if the machine entry also has "DTB-Append: yes" the image written to said partition is a combination of kernel and dtb, and so the check must include the dtb's size, too. This is actually wrong, the misleading bit is, that the kernel partition's size is checked twice. The first time with the plain kernel's size (which might be a too weak check) and then later with the actual size which also includes U-Boot header and initrd size (in the case of a multi image). See commit abdc93372ef965a992850af8eed9381ccad83f76. So I suggest the following patch instead: diff --git a/functions b/functions index 260be2ba2b3d..9824f6534111 100644 --- a/functions +++ b/functions @@ -855,7 +855,10 @@ if [ -n "$mtd_kernel" ]; then check_char_dev "$kmtd" kmtdsize=$(mtdsize "$mtd_kernel") kreqsize=$kfilesize - check_mtd_size "$mtd_kernel" $kreqsize $kmtdsize kernel + + # The actual check is done later to take into account things added the + # kernel image (e.g. U-Boot image header, initrd (for multi images) + # and/or an appended dtb fi if [ -n "$mtd_initrd" ]; then imtd=$(mtdchar "$mtd_initrd") OpenPGP_signature Description: OpenPGP digital signature
Bug#994066: flash-kernel: kernel size check doesn't take appended device tree into account
Package: flash-kernel Version: 3.104 Severity: normal Hello, when the active machine entry has an "Mtd-Kernel" field, flash-kernel checks if the kernel fits into the specified mtd partition. However if the machine entry also has "DTB-Append: yes" the image written to said partition is a combination of kernel and dtb, and so the check must include the dtb's size, too. Here is an untested patch: diff --git a/functions b/functions index 260be2ba2b3d..d5fd0f714300 100644 --- a/functions +++ b/functions @@ -842,6 +842,12 @@ if [ -n "$dtb_append_from" ]; then fi fi +if [ "$dtb_append" = "yes" ]; then + dtb=$(find_dtb_file) + dfilesize=$(stat -c '%s' "$dtb") + kfilesize=$(($kfilesize + $dfilesize)) +fi + if [ -n "$mtd_kernel" ] || [ -n "$mtd_initrd" ]; then if [ ! -e "$PROC_MTD" ]; then error "$PROC_MTD doesn't exist" Best regards Uwe
Bug#994065: flash-kernel: Overwriting an entry doesn't support to remove a field
Package: flash-kernel Version: 3.104 Severity: normal Hello, for the Netgear ReadyNAS 104 there is an entry in the shipped db that looks as follows: Machine: NETGEAR ReadyNAS 104 DTB-Id: armada-370-netgear-rn104.dtb DTB-Append: yes Mtd-Kernel: uImage Mtd-Initrd: minirootfs U-Boot-Kernel-Address: 0x0400 U-Boot-Initrd-Address: 0x0500 Required-Packages: u-boot-tools Bootloader-Sets-Incorrect-Root: yes As the minirootfs partition is too small to hold a bullseye initramfs I want to increase the uImage partition, remove the minirootfs partition and use in /etc/flash-kernel/db: Machine: NETGEAR ReadyNAS 104 DTB-Id: armada-370-netgear-rn104.dtb DTB-Append: yes U-Boot-Multi-Address: 0x200 Mtd-Kernel: uImage Required-Packages: u-boot-tools Bootloader-Sets-Incorrect-Root: yes However this doesn't do what I intend because flash-kernel merges the two entries which results in the following config: Machine: NETGEAR ReadyNAS 104 DTB-Id: armada-370-netgear-rn104.dtb DTB-Append: yes U-Boot-Multi-Address: 0x200 Mtd-Kernel: uImage Required-Packages: u-boot-tools Bootloader-Sets-Incorrect-Root: yes Mtd-Initrd: minirootfs U-Boot-Kernel-Address: 0x0400 U-Boot-Initrd-Address: 0x0500 which is broken and makes flash-kernel stumble. As for other use-cases (i.e. just overwriting a single field) the merge mechanism is quite useful, my thought is to write something like the following to /etc/flash-kernel/db: Machine: NETGEAR ReadyNAS 104 DTB-Id: armada-370-netgear-rn104.dtb DTB-Append: yes U-Boot-Multi-Address: 0x200 Mtd-Kernel: uImage Required-Packages: u-boot-tools Bootloader-Sets-Incorrect-Root: yes # machine-entry-complete and make get_machine_field() return 1 if it sees the machine-entry-complete entry in state "fields". The ugly detail here however is that the comment becomes magic which I don't like much. (Sidenote: I could write "Machine: dummy" instead of the above comment. Apart from emitting an error message flash-kernel's behaviour becomes right :-) Any better ideas? Best regards Uwe
Bug#971590: rt-tests: bump to a new upstream release
Hello, On 9/7/21 4:35 AM, Punit Agrawal wrote: I was looking to update the rt-tests package in Debian as it is lagging behind upstream. Before digging into the task, I wanted to check if you're planning to make any changes or had any patches that haven't been pushed. Pointers to any particular issues to watch out for would also be appreciated. There is nothing pending on my side and if you want to adopt rt-tests that is fine for me. ISTR that Anders Roxell showed some interest in maintaining rt-tests, too, in the past, but I cannot find the corresponding conversation. Upstream used to be quite responsive to patches and I don't assume this has changed. Being in the #linux-rt irc channel (on OFTC) might be beneficial to contact them. Best regards Uwe OpenPGP_signature Description: OpenPGP digital signature
Bug#619442: mtd-utils: please include in armel installer
Hello, On Thu, Sep 24, 2020 at 07:45:04PM +0200, Bastian Germann wrote: > On Wed, 26 Nov 2003 18:56:57 -0500 Jonathan Lane > wrote: > > I'm running Debian Squeeze on a Marvell Sheevaplug, and I'd really like to > > install Debian directly to NAND memory. The mtd-utils package contains all > > the tools needed to do that that aren't already in the installer, and the > > existing method of putting a Debian install on the internal NAND is a pain > > in the rear. I'm in no real hurry to get this fixed right now, but it > > would be nice for future releases like Wheezy. > > Would you like the package to have a udeb version like the one that is > referenced at https://wiki.debian.org/DebianInstaller/MTD#MTD_utils ? > > Is there still interest in this? I have interest. I'm working to unbrick my NAS and having the mtd-utils available in the installer would simplify this. Thanks Uwe signature.asc Description: PGP signature
Bug#992251: Select `CONFIG_X86_PLATFORM_DRIVERS_DELL` for Dell devices (regression)
Control: tag 992251 + pending Hallo, On Mon, Aug 16, 2021 at 01:40:05PM +0200, Paul Menzel wrote: > Package: linux-image-5.13.0-trunk-amd64 > Version: 5.13.9-1~exp2 > Severity: normal > > > Dear Debian folks, > > > Linux commit f1e1ea5167 (platform/x86: Move all dell drivers to their own > subdirectory), present since v5.12-rc1, refactored Dell device related code, > introducing the new Kconfig option `X86_PLATFORM_DRIVERS_DELL` is not set > > $ diff -u /boot/config-5.10.0-8-amd64 /boot/config-5.13.0-trunk-amd64 | > grep DELL > -CONFIG_DELL_SMBIOS=m > -CONFIG_DELL_SMBIOS_WMI=y > -CONFIG_DELL_SMBIOS_SMM=y > -CONFIG_DELL_LAPTOP=m > -CONFIG_DELL_RBTN=m > -CONFIG_DELL_RBU=m > -CONFIG_DELL_SMO8800=m > -CONFIG_DELL_WMI=m > -CONFIG_DELL_WMI_DESCRIPTOR=m > -CONFIG_DELL_WMI_AIO=m > -CONFIG_DELL_WMI_LED=m > +# CONFIG_X86_PLATFORM_DRIVERS_DELL is not set > > On the Dell Latitude E75250, not selecting this causes the function key for > microphone (un-)mute and Wifi (de-)activation to stop working [1]. > > It’d be great if the Dell platform drivers could be built again. Fixed in git, see https://deb.li/3UEgA Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#992258: www.debian.org: packages.debian.org still has stable=buster and doesn't know about bullseye-security
Package: www.debian.org Severity: normal Hello, looking at: https://packages.debian.org/search?keywords=thunderbird=names=stable=all this lists the thunderbird packages from buster, while bullseye is the current stable release. Probably related to that packages.d.o doesn't know about bullseye-security and bullseye-backports. Best regards Uwe
Bug#992186: mailman3-web: Quoting in postinst broken
Package: mailman3-web
Version: 0+20200530-2
Severity: normal
Hello,
mailman3-web's postinst contains:
if [ -n "$su_name" ] && [ -n "$su_mail" ] && [ -n "$su_password" ]; then
$su_cmd "$django_admin shell $django_admin_args --command \
\"from django.contrib.auth.models import User; \
User.objects.filter(username='$su_name').delete(); \
User.objects.create_superuser('$su_name', \
'$su_mail', '$su_password')\"" www-data
fi
This is not robust for su_password (or su_name or su_mail) containing "
or '. When in the debconf dialog such a password is provided, in the
simplest case the script terminates with
sh: 1: Syntax error: Unterminated quoted string
But worse things can happen, see https://xkcd.com/327/. :-)
Best regards
Uwe
-- System Information:
Debian Release: 11.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mailman3-web depends on:
ii dbconfig-sqlite3 2.0.19
ii debconf [debconf-2.0] 1.5.77
ii init-system-helpers1.60
ii lsb-base 11.1.0
ii python33.9.2-3
ii python3-django-hyperkitty 1.3.4-4
ii python3-django-postorius 1.3.4-2
ii python3-psycopg2 2.8.6-2
ii python3-whoosh 2.7.4+git6-g9134ad92-5
ii ucf3.0043
ii uwsgi-core 2.0.19.1-7.1
ii uwsgi-plugin-python3 2.0.19.1-7.1
Versions of packages mailman3-web recommends:
ii libapache2-mod-proxy-uwsgi 2.4.48-3.1
Versions of packages mailman3-web suggests:
ii postgresql 13+225
-- debconf information excluded
Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1
Hello, On Thu, Aug 05, 2021 at 05:26:09PM +, Diederik de Haas wrote: > At > https://salsa.debian.org/raspi-team/image-specs/-/issues/7#note_206349 > it was reported that CPU frequency scaling was enabled for armhf and > arm64, but not for armel. I (and others) have been able to confirm that. > > So I build my own kernel with the following patch: > +CONFIG_CLK_RASPBERRYPI=y Would CONFIG_CLK_RASPBERRYPI=m be enough? > +CONFIG_CPUFREQ_DT=m > +CONFIG_CPUFREQ_DT_PLATDEV=y > +CONFIG_ARM_RASPBERRYPI_CPUFREQ=m These look reasonable. > -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y > +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > -# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set > +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y > -CONFIG_CPU_FREQ_GOV_ONDEMAND=m > +CONFIG_CPU_FREQ_GOV_ONDEMAND=y Hmm, CONFIG_CPU_FREQ_GOV_ONDEMAND=m is already there, so you should be able to switch to that if you prefer it?! Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#991259: b4: fails with dns.exception.Timeout
Hello, On 7/18/21 10:38 PM, Uwe Kleine-König wrote: I wiresharked the DNS traffic and found out that my provider's DNS server doesn't reply "big" queries without edns: $ dig +noedns fm3._domainkey.messagingengine.com TXT ;; Truncated, retrying in TCP mode. ;; communications error to 192.168.80.1#53: end of file ; <<>> DiG 9.16.15-Debian <<>> +noedns fm3._domainkey.messagingengine.com TXT ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21882 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;fm3._domainkey.messagingengine.com. IN TXT ;; Query time: 7 msec ;; SERVER: fdb0:5279:7365:8000::1#53(fdb0:5279:7365:8000::1) ;; WHEN: Sun Jul 18 22:17:15 CEST 2021 ;; MSG SIZE rcvd: 52 If I query one of the public DNS servers (like 1.1.1.1 or 8.8.8.8), or if I use an edns query (i.e. drop +noedns) or if I query one of the ipv6 servers of my provider I get a proper answer. If I understood correctly using edns is the only way to properly get replies bigger than 512 bytes, so it doesn't seem unreasonable to use edns for TXT records?! quick followup: I learned in the meantime that my provider's server doesn't answer TCP requests at all and that this is a violation of a MUST in the relevant RFC[1]. Still it would be a nice improvement for b4 to use edns as it saves the roundtrip through TCP. I'll try to bug my provider now to repair its DNS server. Best regards Uwe [1] https://www.rfc-editor.org/rfc/rfc7766.html#section-5 OpenPGP_signature Description: OpenPGP digital signature
Bug#991259: b4: fails with dns.exception.Timeout
Package: b4
Version: 0.6.2-1
Severity: normal
Hello,
for me the following b4 command reproducibly fails:
$ b4 am yo82s5mc6ha8m...@google.com
Looking up https://lore.kernel.org/r/YO82s5MC6HA8mL2Q%40google.com
Grabbing thread from lore.kernel.org/linux-input
Analyzing 5 messages in the thread
---
Thread incomplete, attempting to backfill
Grabbing thread from lore.kernel.org/alsa-devel
Grabbing thread from lore.kernel.org/dmaengine
Grabbing thread from lore.kernel.org/kvm
Loaded 1 messages from https://lore.kernel.org/kvm/
Grabbing thread from lore.kernel.org/linux-acpi
Grabbing thread from lore.kernel.org/linux-arm-kernel
Server returned an error: 404
Grabbing thread from lore.kernel.org/linux-arm-msm
Grabbing thread from lore.kernel.org/linux-cxl
Grabbing thread from lore.kernel.org/linux-fpga
Grabbing thread from lore.kernel.org/linux-hyperv
Grabbing thread from lore.kernel.org/linux-i2c
Grabbing thread from lore.kernel.org/linux-i3c
Server returned an error: 404
Grabbing thread from lore.kernel.org/lkml
Loaded 4 messages from https://lore.kernel.org/lkml/
Successfully backfilled missing patches
---
Writing
./v4_20210713_u_kleine_koenig_bus_make_remove_callback_return_void.mbx
✔ [PATCH v4 1/5] PCI: endpoint: Make struct pci_epf_driver::remove
return void
✔ [PATCH v4 2/5] s390/cio: Make struct css_driver::remove return void
✔ [PATCH v4 3/5] s390/ccwgroup: Drop if with an always false condition
✔ [PATCH v4 4/5] s390/scm: Make struct scm_driver::remove return void
✔ [PATCH v4 5/5] bus: Make remove callback return void
+ Acked-by: Dmitry Torokhov (✓
DKIM/gmail.com)
+ Acked-by: Geert Uytterhoeven
+ Acked-by: Sudeep Holla
Traceback (most recent call last):
File "/usr/bin/b4", line 33, in
sys.exit(load_entry_point('b4==0.6.2', 'console_scripts', 'b4')())
File "/usr/lib/python3/dist-packages/b4/command.py", line 213, in cmd
cmdargs.func(cmdargs)
File "/usr/lib/python3/dist-packages/b4/command.py", line 40, in
cmd_am
b4.mbox.main(cmdargs)
File "/usr/lib/python3/dist-packages/b4/mbox.py", line 538, in main
mbox_to_am(threadfile, cmdargs)
File "/usr/lib/python3/dist-packages/b4/mbox.py", line 114, in
mbox_to_am
am_mbx = lser.save_am_mbox(mbx, noaddtrailers=cmdargs.noaddtrailers,
File "/usr/lib/python3/dist-packages/b4/__init__.py", line 565, in
save_am_mbox
msg = lmsg.get_am_message(add_trailers=add_trailers,
trailer_order=trailer_order, copyccs=copyccs)
File "/usr/lib/python3/dist-packages/b4/__init__.py", line 1400, in
get_am_message
self.fix_trailers(trailer_order=trailer_order, copyccs=copyccs)
File "/usr/lib/python3/dist-packages/b4/__init__.py", line 1361, in
fix_trailers
attsig = LoreAttestationSignatureDKIM(fmsg.msg) # noqa
File "/usr/lib/python3/dist-packages/b4/__init__.py", line 1707, in
__init__
res = dkim.verify(self.msg.as_bytes(), dnsfunc=dkim_get_txt)
File "/usr/lib/python3/dist-packages/dkim/__init__.py", line 1352, in
verify
return d.verify(dnsfunc=dnsfunc)
File "/usr/lib/python3/dist-packages/dkim/__init__.py", line 940, in
verify
return self.verify_sig(sig, include_headers, sigheaders[idx],
dnsfunc)
File "/usr/lib/python3/dist-packages/dkim/__init__.py", line 773, in
verify_sig
self.pk, self.keysize, self.ktag, self.seqtlsrpt =
load_pk_from_dns(name,
File "/usr/lib/python3/dist-packages/dkim/__init__.py", line 481, in
load_pk_from_dns
s = dnsfunc(name, timeout=timeout)
File "/usr/lib/python3/dist-packages/b4/__init__.py", line 2452, in
dkim_get_txt
a = _resolver.resolve(lookup, dns.rdatatype.TXT,
raise_on_no_answer=False, lifetime=timeout, search=True)
File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1043, in
resolve
timeout = self._compute_timeout(start, lifetime)
File "/usr/lib/python3/dist-packages/dns/resolver.py", line 950, in
_compute_timeout
raise Timeout(timeout=duration)
dns.exception.Timeout: The DNS operation timed out after
5.001782417297363 seconds
I wiresharked the DNS traffic and found out that my provider's DNS
server doesn't reply "big" queries without edns:
$ dig +noedns fm3._domainkey.messagingengine.com TXT
;; Truncated, retrying in TCP mode.
;; communications error to 192.168.80.1#53: end of file
; <<>> DiG 9.16.15-Debian <<>> +noedns
fm3._domainkey.messagingengine.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode:
Bug#990215: tmux: Missleading error message if socket path has wrong permissions
Control: tag -1 + fixed-upstream
Hello Romain,
On Thu, Jun 24, 2021 at 08:49:53PM +0200, Romain Francoise wrote:
> On Wed, Jun 23, 2021 at 8:57 AM Uwe Kleine-König wrote:
> > To improve this, the following patch helps: [...]
>
> Thanks for the bug report and the patch. Can you contribute this
> directly upstream? It's always a bit awkward for me to try and get
> someone else's patch merged...
I reworked the patch a bit and upstream committed something similar in
commit 32f2d9d089ce ("Improve error reporting when the tmux /tmp
directory cannot be created or used, GitHub issue 2765 from Uwe
Kleine-Koenig.")
So I'm marking as fixed-upstream.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Bug#990215: tmux: Missleading error message if socket path has wrong permissions
Package: tmux
Version: 2.8-3
Severity: normal
Tags: upstream patch
Hello,
Starting with a running tmux session that is attachable as expected:
uwe@taurus:~$ chmod o+x /tmp/tmux-$(id -u)
uwe@taurus:~$ tmux a
error creating /tmp/tmux-1000 (Permission denied)
This error message is misleading, as the directory exists just fine.
unstable and experimental are also affected.
To improve this, the following patch helps:
diff --git a/tmux.c b/tmux.c
index 5b73079ee7b3..f11e5dc56136 100644
--- a/tmux.c
+++ b/tmux.c
@@ -134,12 +134,12 @@ make_label(const char *label, char **cause)
if (lstat(resolved, ) != 0)
goto fail;
if (!S_ISDIR(sb.st_mode)) {
- errno = ENOTDIR;
- goto fail;
+ xasprintf(cause, "%s is not a directory", resolved);
+ return NULL;
}
if (sb.st_uid != uid || (sb.st_mode & S_IRWXO) != 0) {
- errno = EACCES;
- goto fail;
+ xasprintf(cause, "unsafe permissions for %s", resolved);
+ return NULL;
}
xasprintf(, "%s/%s", resolved, label);
return (path);
Best regards
Uwe
Bug#987704: webext-foxyproxy: 100% cpu stalling
On Wed, Apr 28, 2021 at 09:00:47AM +0200, Uwe Kleine-König wrote:
> Package: webext-foxyproxy
> Version: 7.5.1+dfsg-1
> Severity: normal
>
> Hello,
>
> occationally (I didn't find the trigger yet) a subprocess of firefox
> occupies one complete cpu. There is no functional problem, all seems to
> work just fine.
>
> It was not clear to me what part of firefox is responsible for it, but
> now I think it is foxyproxy. I started a new profile and the problem
> didn't occur until I enabled foxyproxy. Today I looked in more detail
> into the process' status before closing firefox (which cures the
> problem):
>
> According to strace the process (with pid 16443) does:
>
> read(8, "\372", 1) = 1
> recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
> temporarily unavailable)
> recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
> temporarily unavailable)
> poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
> events=POLLIN}], 3, 0) = 0 (Timeout)
> write(9, "\372", 1) = 1
> recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
> temporarily unavailable)
> recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
> temporarily unavailable)
> poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
> events=POLLIN}], 3, 0) = 1 ([{fd=8, revents=POLLIN}])
>
> in a tight loop.
I checked now what that WebExtensions process does directly after
starting, there it looks like following:
09:26:10.657028 restart_syscall(<... resuming interrupted read ...>) = 1
09:26:11.155145 read(8, "\372", 1) = 1
09:26:11.155647 futex(0x7ff2ccf2aeb4, FUTEX_WAKE_PRIVATE, 1) = 1
09:26:11.156104 write(9, "\372", 1) = 1
09:26:11.156379 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
09:26:11.156848 poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 1 ([{fd=8, revents=POLLIN}])
09:26:11.157099 read(8, "\372", 1) = 1
09:26:11.157342 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
09:26:11.157457 poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 0 (Timeout)
09:26:11.157786 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
09:26:11.157940 poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 0 (Timeout)
09:26:11.158081 write(15, "\0", 1) = 1
09:26:11.158385 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
09:26:11.158535 poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 1 ([{fd=8, revents=POLLIN}])
09:26:11.158652 read(8, "\372", 1) = 1
09:26:11.158754 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
09:26:11.158852 poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 0 (Timeout)
09:26:11.158974 write(9, "\372", 1) = 1
09:26:11.159077 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
09:26:11.159174 poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 1 ([{fd=8, revents=POLLIN}])
09:26:11.159284 read(8, "\372", 1) = 1
09:26:11.159395 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
09:26:11.159496 poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 0 (Timeout)
09:26:11.159964 futex(0x7ff2ddd32404, FUTEX_WAKE_PRIVATE, 1) = 1
09:26:11.160060 futex(0x7ff2ddd323a8, FUTEX_WAKE_PRIVATE, 1) = 1
09:26:11.160201 write(15, "\0", 1) = 1
09:26:11.160340 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
09:26:11.160554 poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 0 (Timeout)
09:26:11.160786 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
09:26:11.160990 poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 0 (Timeout)
09:26:11.161118 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
09:26:11.161218 poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 0 (Timeout)
09:26:11.161320 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
09:26:11.161416 poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, -1) = 1 ([{fd=8, revents=POLLIN}])
09:26:15.812258 read(8, "\372", 1) = 1
09:26:15.812513 write(15, "\0", 1) = 1
09:26:15.812724 write(9, "\372", 1) = 1
09:26:15.813013 recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN
Bug#987704: webext-foxyproxy: 100% cpu stalling
Package: webext-foxyproxy
Version: 7.5.1+dfsg-1
Severity: normal
Hello,
occationally (I didn't find the trigger yet) a subprocess of firefox
occupies one complete cpu. There is no functional problem, all seems to
work just fine.
It was not clear to me what part of firefox is responsible for it, but
now I think it is foxyproxy. I started a new profile and the problem
didn't occur until I enabled foxyproxy. Today I looked in more detail
into the process' status before closing firefox (which cures the
problem):
According to strace the process (with pid 16443) does:
read(8, "\372", 1) = 1
recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 0 (Timeout)
write(9, "\372", 1) = 1
recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
poll([{fd=8, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18,
events=POLLIN}], 3, 0) = 1 ([{fd=8, revents=POLLIN}])
in a tight loop.
ls /proc/16443 contains:
lrwxrwxrwx 1 uwe uwe 0 Apr 28 08:25 cwd -> '/proc/16444/fdinfo (deleted)'
lrwxrwxrwx 1 uwe uwe 0 Apr 28 08:25 root -> '/proc/16444/fdinfo (deleted)'
and after I killed the process, normal web surfing is unaffected, and
foxyproxy doesn't work any more. (That is, the icon still appears in the
address bar and I can reconfigure foxyproxy, but when I access a site
that requires to pick a non-default proxy setting, firefox tries to
access it directly.)
I clicked a bit around in the developer console, looking for service
workers, but didn't find anything.
In the console there are a few messages:
Promise resolved after context unloaded
background.js:53
Object { mode: "patterns", proxySettings: (2) […] }
activeSettings in patterns mode background.js:176:13
background.js: loaded proxy settings from storage. background.js:105:11
Promise resolved after context unloaded
vapi-background.js:1456
The Components object is deprecated. It will soon be removed.
regex.js:12:20
I have no idea how to further debug that.
Best regards
Uwe
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (700, 'testing-debug'), (700, 'stable-updates'), (700,
'testing'), (700, 'stable'), (600, 'unstable'), (500, 'unstable-debug'), (500,
'stable-debug'), (500, 'oldstable'), (499, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64
Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages webext-foxyproxy depends on:
ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4
Versions of packages webext-foxyproxy recommends:
ii firefox 88.0-1
ii firefox-esr 78.10.0esr-1
webext-foxyproxy suggests no packages.
-- no debconf information
Bug#985862: linux: Please enable support for NXP/Freescale iMX8
Control: tag -1 + pending Hello Wookey, On Thu, Mar 25, 2021 at 05:13:02AM +, Wookey wrote: > Source: linux > Severity: normal > > The iMX8 SoC is used on various boards, widely available to debian > users and well supported by free software, but the platform is not > enabled in debian kernels, which is a rather major omission. I don't > know why not (I guess no-one filed this bug?). > > These are all avilable today and should at least mostly work with > mainline: > Nitrogen 8M > https://boundarydevices.com/product/nitrogen8m/ > Solidrun > Cubox M https://shop.solid-run.com/product/SRMP8QDWB1D04GE008X00CE/ > Hummingboard Pulse > https://shop.solid-run.com/product-category/embedded-computers/nxp-family/hummingboard-m/ > Purism > Librem 5 Phone https://en.wikipedia.org/wiki/Librem_5 > Compulab > SBC-iMX8X > https://www.compulab.com/products/sbcs/sbc-imx8x-nxp-i-mx-8x-single-board-computer/ > (supported since 5.4.24) > Toradex > Apalis iMX8 CoM > https://www.toradex.com/computer-on-modules/apalis-arm-family/nxp-imx-8 > > I believe that all that is needed is adding > CONFIG_ARCH_MXC=y in debian/config/arm64/config > Which is set by default upstream. I enabled a few more settings in our sid branch. See https://deb.li/3fUTV . > (There may be other drivers that should enabled too for some of these > platforms?) > > I just built the kernel with the above config change and it builds > fine on arm64, and installs and boots on softiron. I don't have an > iMX8 here to test on, but we can find some, I'm sure. I have an i.MX8 here, but didn't do any tests (yet). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Hello, On Wed, Mar 24, 2021 at 09:59:59AM +0100, Christoph Biedl wrote: > Felix Lechner wrote... > > > By the way, the suggestion behind this bug may not be implemented > > anytime soon. It would cause Lintian's output to change over time > > (same Lintian version on same package). Such tags are hard to test in > > Lintian's test suite. > > That argument seems fairly weird to me: Abandon or deny features because > they are difficult to test. By the way, to test behaviour over time, > faketime(1) serves me good enough. But that's your design decision. Just to make this suggestion more obvious as I got (and needed) this hint: A sensible date to fake (or compare to) would probably be the changelog date. Then the output doesn't vary over time and we also don't get bad positives for old packages. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#982423: reprepro: diff for NMU version 5.3.0-1.2
Control: tags 982423 + pending Hey Bernhard, I've prepared an NMU for reprepro (versioned as 5.3.0-1.2) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Regards from Freiburg Uwe diff -Nru reprepro-5.3.0/debian/changelog reprepro-5.3.0/debian/changelog --- reprepro-5.3.0/debian/changelog 2020-01-17 03:03:27.0 +0100 +++ reprepro-5.3.0/debian/changelog 2021-02-18 10:25:24.0 +0100 @@ -1,3 +1,10 @@ +reprepro (5.3.0-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Flush stdout and stderr before execv of an end hook (Closes: #982423) + + -- Uwe Kleine-König Thu, 18 Feb 2021 10:25:24 +0100 + reprepro (5.3.0-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru reprepro-5.3.0/debian/patches/flush-streams-before-exec-hook.patch reprepro-5.3.0/debian/patches/flush-streams-before-exec-hook.patch --- reprepro-5.3.0/debian/patches/flush-streams-before-exec-hook.patch 1970-01-01 01:00:00.0 +0100 +++ reprepro-5.3.0/debian/patches/flush-streams-before-exec-hook.patch 2021-02-18 10:25:24.0 +0100 @@ -0,0 +1,18 @@ +From: Hilko Bengen +Date: Wed, 10 Feb 2021 01:47:23 +0100 +Subject: Flush stdout, stderr before calling endhook +Bug-Debian: https://bugs.debian.org/982423 + +Flush stdout and stderr, otherwise output might be discarded. + +--- a/main.c b/main.c +@@ -4906,6 +4906,8 @@ + if (snprintf(exitcode, 4, "%u", ((unsigned int)status)&255U) > 3) + memcpy(exitcode, "255", 4); + sethookenvironment(causingfile, NULL, NULL, exitcode); ++ fflush(stdout); ++ fflush(stderr); + argv[0] = endhook, + (void)execv(endhook, argv); + fprintf(stderr, "Error executing '%s': %s\n", endhook, diff -Nru reprepro-5.3.0/debian/patches/series reprepro-5.3.0/debian/patches/series --- reprepro-5.3.0/debian/patches/series 2020-01-17 02:57:30.0 +0100 +++ reprepro-5.3.0/debian/patches/series 2021-02-18 10:25:24.0 +0100 @@ -1 +1,2 @@ bump-buffer-size +flush-streams-before-exec-hook.patch signature.asc Description: PGP signature
Bug#982423: reprepro: Does not write to pipe if --endhook is set
Control: forcemerge -1 928133 On Wed, Feb 17, 2021 at 12:55:45PM +0100, Hilko Bengen wrote: > control: merge -1 928133 I repeated that with a bit of force as the severities of the two don't match. > * Uwe Kleine-König: > > > This seems to be the same issue as https://bugs.debian.org/928133 > > Yes, indeed. > > > @brlink: Do you consider fixing this problem for bullseye? Would you > > welcome an NMU? > > If you do so, be sure to also add code to flush stderr, though. :-) Yeah, I noticed this flaw in my patch. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#982423: reprepro: Does not write to pipe if --endhook is set
Hello, On Wed, Feb 10, 2021 at 01:51:31AM +0100, Hilko Bengen wrote: > Package: reprepro > Version: 5.3.0-1.1 > Severity: important > Tags: patch > > Dear Maintainer, > > when used with --endhook, reprepro fails to output anything if standard > output is a pipe. Here's a minimal reproducer: > > , > | $ mkdir -p r/conf > | $ cat > r/conf/distributions < | Codename: sid > | Architectures: amd64 source > | Components: main > | EOF > | $ reprepro -b r includedsc sid hello_2.10-2.dsc > | Exporting indices... > | $ reprepro -b r list sid > | sid|main|source: hello 2.10-2 > | $ reprepro -b r list sid | cat > | sid|main|source: hello 2.10-2 > | $ reprepro -b r --endhook /bin/true list sid | cat > | $ > ` > > Apparently stdio buffers are not flushed before exec()ing the endhook > program. The attached patch fixes this. This seems to be the same issue as https://bugs.debian.org/928133 @brlink: Do you consider fixing this problem for bullseye? Would you welcome an NMU? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#976192: bsdmainutils: diff for NMU version 12.1.7+nmu2
Control: tags 976192 + pending
Hello Michael,
I've prepared an NMU for bsdmainutils (versioned as 12.1.7+nmu2) and
I'm about to upload it to DELAYED/7. Please feel free to tell me if I
should delay it longer.
Best regards
Uwe
diff -Nru bsdmainutils-12.1.7+nmu1/debian/changelog bsdmainutils-12.1.7+nmu2/debian/changelog
--- bsdmainutils-12.1.7+nmu1/debian/changelog 2021-02-08 10:04:48.0 +0100
+++ bsdmainutils-12.1.7+nmu2/debian/changelog 2021-02-15 11:31:35.0 +0100
@@ -1,3 +1,11 @@
+bsdmainutils (12.1.7+nmu2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ISO week calculation (Closes: #976192), thanks to Kate for the
+initial patch.
+
+ -- Uwe Kleine-König Mon, 15 Feb 2021 11:31:35 +0100
+
bsdmainutils (12.1.7+nmu1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru bsdmainutils-12.1.7+nmu1/debian/patches/ncal_fdow.diff bsdmainutils-12.1.7+nmu2/debian/patches/ncal_fdow.diff
--- bsdmainutils-12.1.7+nmu1/debian/patches/ncal_fdow.diff 2020-08-04 13:49:06.0 +0200
+++ bsdmainutils-12.1.7+nmu2/debian/patches/ncal_fdow.diff 2021-02-15 11:30:47.0 +0100
@@ -68,7 +68,7 @@
static int nswitchb; /* switch date for backward compatibility */
static int highlightdate;
+int weekstart = -1; /* day the week starts on (Sun [0] - Sat [6]) */
-+int days_first_week = 0; /* minimal length of the first week in year */
++int days_first_week = -1; /* minimal length of the first week in year */
static char *center(char *s, char *t, int w);
static wchar_t *wcenter(wchar_t *s, wchar_t *t, int w);
@@ -139,7 +139,7 @@
+#ifdef __GLIBC__
+ days_first_week = *nl_langinfo(_NL_TIME_WEEK_1STWEEK);
+#else
-+ days_first_week = 3;
++ days_first_week = 4;
+#endif
+
if (flag_month != NULL) {
signature.asc
Description: PGP signature
Bug#976192: bsdmainutils: diff for NMU version 12.1.7+nmu1
Hello Michael
I'd really like to see this fixed for bullseye. I prepared a merge
request on Salsa:
https://salsa.debian.org/meskes/bsdmainutils/-/merge_requests/6
It would be great if you could merge and upload.
I can also create an NMU if you don't find the time and agree. Then I'd
apply the attached patch and upload. Please advise.
Best regards
Uwe
diff -Nru bsdmainutils-12.1.7/debian/changelog bsdmainutils-12.1.7+nmu1/debian/changelog
--- bsdmainutils-12.1.7/debian/changelog 2020-08-04 13:49:06.0 +0200
+++ bsdmainutils-12.1.7+nmu1/debian/changelog 2021-02-09 09:36:12.0 +0100
@@ -1,3 +1,11 @@
+bsdmainutils (12.1.7+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ISO week calculation (Closes: #976192), thanks to Kate for the initial
+patch.
+
+ -- Uwe Kleine-König Tue, 09 Feb 2021 09:36:12 +0100
+
bsdmainutils (12.1.7) unstable; urgency=medium
* Fix broken locale for Russian calendars. (Closes: #930736, #945252)
diff -Nru bsdmainutils-12.1.7/debian/patches/ncal_fdow.diff bsdmainutils-12.1.7+nmu1/debian/patches/ncal_fdow.diff
--- bsdmainutils-12.1.7/debian/patches/ncal_fdow.diff 2020-08-04 13:49:06.0 +0200
+++ bsdmainutils-12.1.7+nmu1/debian/patches/ncal_fdow.diff 2021-02-09 09:36:12.0 +0100
@@ -68,7 +68,7 @@
static int nswitchb; /* switch date for backward compatibility */
static int highlightdate;
+int weekstart = -1; /* day the week starts on (Sun [0] - Sat [6]) */
-+int days_first_week = 0; /* minimal length of the first week in year */
++int days_first_week = -1; /* minimal length of the first week in year */
static char *center(char *s, char *t, int w);
static wchar_t *wcenter(wchar_t *s, wchar_t *t, int w);
@@ -139,7 +139,7 @@
+#ifdef __GLIBC__
+ days_first_week = *nl_langinfo(_NL_TIME_WEEK_1STWEEK);
+#else
-+ days_first_week = 3;
++ days_first_week = 4;
+#endif
+
if (flag_month != NULL) {
signature.asc
Description: PGP signature
Bug#981033: segfault in dtc -I fs
Package: device-tree-compiler Version: 1.4.7-3 Severity: important Tags: upstream, fixed-upstream Control: fixed -1 1.5.0-1 Hello, $ dtc -I fs -O dts /sys/firmware/devicetree/base/ : Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): /soc/bootrom: node has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): /soc/devbus-cs3: node has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): /soc/devbus-cs1: node has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): /soc/internal-regs: node has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): /soc/devbus-bootcs: node has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): /soc/sa-sram: node has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): /soc/devbus-cs2: node has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): /soc/devbus-cs0: node has a reg or ranges property, but no unit name : Warning (unique_unit_address): /soc/internal-regs/timer@20300: duplicate unit-address (also used in node /soc/internal-regs/watchdog@20300) : Warning (clocks_property): /soc/devbus-cs3:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/devbus-cs1:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/mvsdio@d4000:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/crypto@9:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/timer@20300:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/i2c@11100:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/corediv-clock@18740:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/mdio@72004:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/gpio@18140:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/watchdog@20300:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/usb@5:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/gpio@18100:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/ethernet@74000:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/i2c@11000:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/i2c@11000/g762@3e:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/serial@12100:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/nand-controller@d:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/ethernet@7:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/sata@a:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/sata@a:clocks: cell 2 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/clock-gating-control@18220:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/audio-controller@3:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/serial@12000:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/internal-regs/usb@51000:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/devbus-bootcs:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/spi@10680:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/pcie@8200/pcie@2,0:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/pcie@8200/pcie@1,0:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/sa-sram:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/devbus-cs2:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/spi@10600:clocks: cell 0 is not a phandle reference : Warning (clocks_property): /soc/devbus-cs0:clocks: cell 0 is not a phandle reference : Warning (interrupts_extended_property): /pmu:interrupts-extended: cell 0 is not a phandle reference : Warning (msi_parent_property): /soc/pcie@8200:msi-parent: cell 0
Bug#979868: /usr/share/man/man1/ssh.1.gz: ssh(1) doesn't document -D supporting named Unix sockets
Package: openssh-client Version: 1:8.4p1-3 Severity: minor File: /usr/share/man/man1/ssh.1.gz Tags: upstream patch Hello, while I experimented with ssh I noticed that -D supports using Unix sockets but this is undocumented in the manpage. I have no experience about bug/patch submitting upstream, so I'm just reporting here with a patch. Feel free to forward accordingly. Best regards Uwe >8 From: Uwe Kleine-König Date: Tue, 12 Jan 2021 09:13:28 +0100 Subject: [PATCH] ssh(1): Document -D supporting Unix sockets The option -D supports (similar to -L) to use a named Unix socket instead of binding to a port. Add this feature to the manpage. --- ssh.1 | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/ssh.1 b/ssh.1 index ad48fc8c816a..f67ee14d12f1 100644 --- a/ssh.1 +++ b/ssh.1 @@ -46,7 +46,7 @@ .Op Fl B Ar bind_interface .Op Fl b Ar bind_address .Op Fl c Ar cipher_spec -.Op Fl D Oo Ar bind_address : Oc Ns Ar port +.Op Fl D Ar socketspec .Op Fl E Ar log_file .Op Fl e Ar escape_char .Op Fl F Ar configfile @@ -173,14 +173,21 @@ for more information. .Ar port .Sm on .Xc +.It Fl D Xo +.Sm off +.Ar local_socket +.Sm on +.Xc Specifies a local .Dq dynamic application-level port forwarding. This works by allocating a socket to listen to .Ar port on the local side, optionally bound to the specified -.Ar bind_address . -Whenever a connection is made to this port, the +.Ar bind_address +or the specified Unix socket +.Ar local_socket . +Whenever a connection is made to this socket, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. -- 2.29.2 -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (700, 'testing-debug'), (700, 'stable-updates'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable'), (499, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-client depends on: ii adduser 3.118 ii dpkg 1.20.5 ii libc6 2.31-9 ii libedit2 3.1-20191231-2+b1 ii libfido2-11.5.0-2 ii libgssapi-krb5-2 1.18.3-4 ii libselinux1 3.1-2+b2 ii libssl1.1 1.1.1i-1 ii passwd1:4.8.1-1 ii zlib1g1:1.2.11.dfsg-2 Versions of packages openssh-client recommends: ii xauth 1:1.0.10-1 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere pn ssh-askpass -- no debconf information
Bug#979108: memtool: 64 bit memory reads may be split on 32 bit systems
Control: found -1 2016.10.0-1
Control: fixed -1 2018.03.0-1
On Tue, Jan 05, 2021 at 09:42:35PM +0100, Uwe Kleine-König wrote:
> On 1/2/21 8:34 PM, Gergely Peli wrote:
> > Package: memtool
> > Severity: normal
> > Tags: upstream patch
> >
> > Hello,
> >
> > I tried memtool on a 32 bit ARM system, and the supposedly 64 bit reads
> > with the "-q" option are done by 2 separate 32 bit "ldr" instructions.
> > Adding a volatile qualifier to the pointers accessing the memory could
> > convince gcc to generate a single "ldrd" instruction instead, which uses
> > a 64 bit memory transfer. See below a proposed patch. Adding volatile to all
> > 4 cases may be an overkill, but can't hurt. Cheers,
> >
> > Gergely Peli
> >
> >
> >
> > --- memtool-2016.10.0.orig/memtool.c
> > +++ memtool-2016.10.0/memtool.c
> > @@ -152,24 +152,24 @@ static int memory_display(const void *ad
> > for (i = 0; i < linebytes; i += width) {
> > if (width == 8) {
> > uint64_t res;
> > - res = (*uqp++ = *((uint64_t *)addr));
> > + res = (*uqp++ = *((volatile uint64_t
> > *)addr));
>
> In this code location it doesn't matter if two ldrs instead of a single ldrd
> is used. This is only the code printing the data from the buffer that holds
> the read data. If memtools behaves wrong the problem is likely in mmap_read.
In a private followup conversation it became obvious that there is
indeed a culprit but only in oldstable with version 2016.10.0-1 where
memory_display operates directly on the mmap'd memory.
With changes introduced in 2018.03.0 the problem is gone. (It's not
entirely clear why though, maybe there is also some luck involved
because the compiler behaviour changed and we might need some volatiles
in mmap_read (and mmap_write) for correctness). Anyhow, I checked
memtool 2018.03.0 on armhf and there a 64 bit read (vldr.64, not ldrd)
is used. So I marked 2018.03.0-1 as fixed.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Bug#979108: memtool: 64 bit memory reads may be split on 32 bit systems
Hello Gergely,
On 1/2/21 8:34 PM, Gergely Peli wrote:
Package: memtool
Severity: normal
Tags: upstream patch
Hello,
I tried memtool on a 32 bit ARM system, and the supposedly 64 bit reads
with the "-q" option are done by 2 separate 32 bit "ldr" instructions.
Adding a volatile qualifier to the pointers accessing the memory could
convince gcc to generate a single "ldrd" instruction instead, which uses
a 64 bit memory transfer. See below a proposed patch. Adding volatile to all
4 cases may be an overkill, but can't hurt. Cheers,
Gergely Peli
--- memtool-2016.10.0.orig/memtool.c
+++ memtool-2016.10.0/memtool.c
@@ -152,24 +152,24 @@ static int memory_display(const void *ad
for (i = 0; i < linebytes; i += width) {
if (width == 8) {
uint64_t res;
- res = (*uqp++ = *((uint64_t *)addr));
+ res = (*uqp++ = *((volatile uint64_t *)addr));
In this code location it doesn't matter if two ldrs instead of a single
ldrd is used. This is only the code printing the data from the buffer
that holds the read data. If memtools behaves wrong the problem is
likely in mmap_read.
This makes me wonder how you found the bug and how you tested that your
patch indeed fixes it.
Best regards
Uwe
OpenPGP_signature
Description: OpenPGP digital signature
Bug#975998: licensecheck: Fails with a Perl problem
Hello Nico, On 11/28/20 7:09 PM, Niko Tyni wrote: On Fri, Nov 27, 2020 at 11:25:25PM +0100, Uwe Kleine-König wrote: Package: licensecheck Version: 3.0.47-1 Severity: normal this might not be licensecheck's fault but maybe is related to the recent perl transition. But given I don't know much about Perl, I'm reporting against licensecheck. For all invokations of licensecheck I encounter: uwe@taurus:~$ licensecheck Base class package "Pod::Parser" is empty. (Perhaps you need to 'use' the module which defines that package first, or make that module available in @INC (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.0 /usr/local/share/perl/5.32.0 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl). at /usr/share/perl5/Pod/Constants.pm line 7. BEGIN failed--compilation aborted at /usr/share/perl5/Pod/Constants.pm line 7. Compilation failed in require at /usr/bin/licensecheck line 14. BEGIN failed--compilation aborted at /usr/bin/licensecheck line 14. This is on a machine that runs a mix of testing and unstable, but I can reproduce this problem on a sid chroot. Hi, thanks for the report. This doesn't seem to occur for me in a clean sid chroot. Is yours an older one that has been upgraded? Do you happen to have an old perl-modules-5.24 package lying around in both? It's indeed an upgraded sid chroot. I didn't check the chroot, but on my host I have perl-modules-5.24 5.24.1-7 installed. Is libpod-parser-perl installed? No, libpod-parser-perl isn't installed, but it is indeed provided by perl-modules-5.24. I'm guessing this might be similar to #972322 and we need to do something about it on the src:perl side. Installing libpod-parser-perl and removing perl-modules-5.24 fixed the problem. Thanks Uwe
Bug#975998: licensecheck: Fails with a Perl problem
Package: licensecheck Version: 3.0.47-1 Severity: normal Hello, this might not be licensecheck's fault but maybe is related to the recent perl transition. But given I don't know much about Perl, I'm reporting against licensecheck. For all invokations of licensecheck I encounter: uwe@taurus:~$ licensecheck Base class package "Pod::Parser" is empty. (Perhaps you need to 'use' the module which defines that package first, or make that module available in @INC (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.0 /usr/local/share/perl/5.32.0 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl). at /usr/share/perl5/Pod/Constants.pm line 7. BEGIN failed--compilation aborted at /usr/share/perl5/Pod/Constants.pm line 7. Compilation failed in require at /usr/bin/licensecheck line 14. BEGIN failed--compilation aborted at /usr/bin/licensecheck line 14. This is on a machine that runs a mix of testing and unstable, but I can reproduce this problem on a sid chroot. Best regards Uwe -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (700, 'stable-updates'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable'), (499, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages licensecheck depends on: ii libarray-intspan-perl 2.004-1 ii libgetopt-long-descriptive-perl0.105-1 ii liblist-someutils-perl 0.58-1 ii liblog-any-adapter-screen-perl 0.140-1 ii liblog-any-perl1.708-1 ii libmoo-perl2.004003-1 ii libmoox-struct-perl0.020-1 ii libnamespace-clean-perl0.27-1 ii libpath-iterator-rule-perl 1.014-1 ii libpath-tiny-perl 0.114-1 ii libpod-constants-perl 0.19-2 ii libre-engine-re2-perl 0.13-5+b4 ii libregexp-pattern-license-perl 3.4.0-1 ii libregexp-pattern-perl 0.2.14-1 ii libscalar-list-utils-perl 1:1.55-1+b1 ii libsort-key-perl 1.33-2+b3 ii libstrictures-perl 2.06-1 ii libstring-copyright-perl 0.003006-1 ii libstring-escape-perl 2010.002-2 ii libtry-tiny-perl 0.30-1 ii perl 5.32.0-5 ii perl-base [libscalar-list-utils-perl] 5.32.0-5 licensecheck recommends no packages. Versions of packages licensecheck suggests: ii bash-completion 1:2.11-2 -- no debconf information
Bug#973819: /usr/bin/pipewire-media-session: coredump after system upgrade to bullseye
Hi Simon, On 11/8/20 5:33 PM, Simon McVittie wrote: Control: tags -1 + moreinfo On Thu, 05 Nov 2020 at 15:27:11 +0100, Uwe Kleine-König wrote: pipewire-media-session segfaulted after I upgraded my system to bullseye. Does it do this repeatably, or only once? New upstream release 0.3.15 (now in testing) is meant to fix some regressions, so it might fix this? I upgraded to this version now. But also before the crash only happened once (during the first login after upgrading my machine to bullseye). The coredump is quite big (as is the output of gdb's bt command on it) If this is reproducible, please could you send or upload the gdb bt output? The core dump itself is only useful if using snapshot.debian.org or similar to force all -dbgsym packages to versions that match yours. I installed the debug symbol packages now, but I'm not motivated to pick the right debug symbol packages using snapshot.d.o. Of course this doesn't help for the coredump I reported here, but if it will happen again, you get a trace with the full information. Sorry, I didn't look in detail and so didn't notice that the coredumpctl output didn't include the full information. Best regards Uwe
Bug#973937: certbot wrongly reports live certs on purge
Package: certbot
Version: 1.6.0-1
Severity: normal
Hello,
the postrm script of certbot has the following code that is run on
purge:
LIVE=0
for cert in /etc/letsencrypt/live/*/cert.pem; do
if [ -e "$cert" ]; then
openssl x509 -in ${cert} -noout -checkend 0 -noout >/dev/null
2>&1
LIVE=$(( ${LIVE} + $? ))
fi
done
if [ $LIVE -eq 0 ]; then
# We have live certs. Prompt for deletion.
... only remove dir with a prompt
else
# No live certs. It's safe to purge
remove_letsencrypt_dir
fi
The logic implmented here is bogus. openssl returns 0 for certs that
are still valid. So removing the letsencrypt directory is only
interactive if *all* found certs are still valid. This includes the
special case that no cert is found at all.
The following should do a better job (untested though):
removeinteractive=false
for cert in /etc/letsencrypt/live/*/cert.pem; do
# is -noout really needed twice here?
if test -e "$cert" && openssl x509 -in ${cert} -noout -checkend 0
-noout >/dev/null 2>&1; then
removeinteractive=true
break
fi
done
if "$removeinteractive"; then
# We have live certs. Prompt for deletion.
... only remove dir with a prompt
else
# No live certs. It's safe to purge
remove_letsencrypt_dir
fi
Best regards
Uwe
Bug#973819: /usr/bin/pipewire-media-session: coredump after system upgrade to bullseye
Package: pipewire-bin Version: 0.3.14-1 Severity: normal File: /usr/bin/pipewire-media-session Hello, pipewire-media-session segfaulted after I upgraded my system to bullseye. uwe@taurus:~$ coredumpctl dump --output /tmp/pipewire.coredump PID: 1909 (pipewire-media-) UID: 1000 (uwe) GID: 1000 (uwe) Signal: 11 (SEGV) Timestamp: Thu 2020-11-05 15:11:46 CET (11min ago) Command Line: /usr/bin/pipewire-media-session -d bluez5 Executable: /usr/bin/pipewire-media-session Control Group: /user.slice/user-1000.slice/user@1000.service/pipewire.service Unit: user@1000.service User Unit: pipewire.service Slice: user-1000.slice Owner UID: 1000 (uwe) Boot ID: 58bbd25936ad458fab350dfec501cbfa Machine ID: 3b73e6754cbf43ba86a0758bcb8a0295 Hostname: taurus Storage: /var/lib/systemd/coredump/core.pipewire-media-.1000.58bbd25936ad458fab350dfec501cbfa.1909.160458550600.zst Message: Process 1909 (pipewire-media-) of user 1000 dumped core. Stack trace of thread 1909: #0 0x7ff0fda8d175 n/a (libspa-audioconvert.so + 0x4b175) #1 0x7ff0fda6e171 n/a (libspa-audioconvert.so + 0x2c171) #2 0x7ff10ac231b4 n/a (libpipewire-module-client-node.so + 0xe1b4) #3 0x7ff10bea9cae n/a (libpipewire-0.3.so.0 + 0x4ecae) #4 0x7ff0fda574ad n/a (libspa-audioconvert.so + 0x154ad) #5 0x7ff0fda63614 n/a (libspa-audioconvert.so + 0x21614) #6 0x7ff0fda84675 n/a (libspa-audioconvert.so + 0x42675) #7 0x7ff0fda84de7 n/a (libspa-audioconvert.so + 0x42de7) #8 0x7ff0fda6a3e6 n/a (libspa-audioconvert.so + 0x283e6) #9 0x7ff0fda6b751 n/a (libspa-audioconvert.so + 0x29751) #10 0x7ff0fda59552 n/a (libspa-audioconvert.so + 0x17552) #11 0x7ff10ac244d0 n/a (libpipewire-module-client-node.so + 0xf4d0) #12 0x7ff10ac2d8cd n/a (libpipewire-module-client-node.so + 0x188cd) #13 0x7ff10ac6b157 n/a (libpipewire-module-protocol-native.so + 0x11157) #14 0x7ff10ac6b720 n/a (libpipewire-module-protocol-native.so + 0x11720) #15 0x7ff10bf19cab n/a (libspa-support.so + 0x4cab) #16 0x560ef09c92fb n/a (pipewire-media-session + 0x432fb) #17 0x560ef09c9739 n/a (pipewire-media-session + 0x43739) #18 0x560ef09dad23 n/a (pipewire-media-session + 0x54d23) #19 0x560ef09dbee5 n/a (pipewire-media-session + 0x55ee5) #20 0x560ef09c5c1b n/a (pipewire-media-session + 0x3fc1b) #21 0x7ff10ac6e2b4 n/a (libpipewire-module-protocol-native.so + 0x142b4) #22 0x7ff10ac6b157 n/a (libpipewire-module-protocol-native.so + 0x11157) #23 0x7ff10ac6b720 n/a (libpipewire-module-protocol-native.so + 0x11720) #24 0x7ff10bf19cab n/a (libspa-support.so + 0x4cab) #25 0x560ef09c92fb n/a (pipewire-media-session + 0x432fb) #26 0x560ef09c9739 n/a (pipewire-media-session + 0x43739) #27 0x560ef09dad23 n/a (pipewire-media-session + 0x54d23) #28 0x560ef09dbee5 n/a (pipewire-media-session + 0x55ee5) #29 0x560ef09c5c1b n/a (pipewire-media-session + 0x3fc1b) #30 0x7ff10ac6e2b4 n/a (libpipewire-module-protocol-native.so + 0x142b4) #31 0x7ff10ac6b157 n/a (libpipewire-module-protocol-native.so + 0x11157) #32 0x7ff10ac6b720 n/a (libpipewire-module-protocol-native.so + 0x11720) #33 0x7ff10bf19cab n/a (libspa-support.so + 0x4cab) #34 0x560ef09c92fb n/a (pipewire-media-session + 0x432fb) #35 0x560ef09c9739 n/a (pipewire-media-session + 0x43739) #36 0x560ef09dad23 n/a (pipewire-media-session + 0x54d23) #37 0x560ef09dbee5 n/a (pipewire-media-session + 0x55ee5) #38 0x560ef09c5c1b n/a (pipewire-media-session + 0x3fc1b) #39 0x7ff10ac6e2b4 n/a (libpipewire-module-protocol-native.so + 0x142b4) #40 0x7ff10ac6b157 n/a (libpipewire-module-protocol-native.so + 0x11157) #41 0x7ff10ac6b720 n/a (libpipewire-module-protocol-native.so + 0x11720) #42 0x7ff10bf19cab n/a (libspa-support.so + 0x4cab) #43 0x560ef09c92fb n/a (pipewire-media-session + 0x432fb) #44 0x560ef09c9739 n/a (pipewire-media-session + 0x43739) #45 0x560ef09dad23 n/a (pipewire-media-session + 0x54d23) #46 0x560ef09dbee5 n/a (pipewire-media-session + 0x55ee5) #47 0x560ef09c5c1b n/a
Bug#972123: Please enable CONFIG_VIDEO_SUNXI_CEDRUS for Allwinner/sunxi
Control: tag -1 + pending Hello, On Mon, Oct 12, 2020 at 03:06:50PM -0700, Damon Tarry wrote: > Please enable CONFIG_VIDEO_SUNXI_CEDRUS to enable video decoding > hardware on Allwinner/sunxi devices. This includes both arm64 and > armhf (armmp) kernels. I enabled this in both variants, see https://deb.li/ub2g . I don't know the plans to upload 5.9 to sid, but eventually it will land there. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#970853: /usr/share/doc/mount/changelog.gz: useless link in upstream changelog
Package: mount Version: 2.33.1-0.1 Severity: minor File: /usr/share/doc/mount/changelog.gz Hello, /usr/share/doc/mount/changelog.gz consists mostly of a link to the git web interface. In the case of the 2.33.1 upstream release this isn't helpful though and the link provides an empty log. Probably upstream failed to tag the release or push the tag to this repository?! For unstable/testing having v2.36 the link looks fine. Best regards Uwe
Bug#970834: python3-notmuch: Segfault in pwnm-sync
Package: python3-notmuch
Version: 0.28.4-1
Severity: normal
Hello,
I'm using pwnm-sync from https://github.com/stewartsmith/pwnm-sync/ (from
commit fa4f19d2487291da6ee85d62969b4640ee99).
Just now it terminated as follows:
Processed 2500 linux-pwm patches...
Error ('Connection aborted.', RemoteDisconnected('Remote end closed
connection without response'))
Aborted (core dumped)
This was the first coredump ever, I use the script quite regularily.
The backtrace looks as follows:
#0 0x7eff69ed4db1 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7eff69ebe537 in __GI_abort () at abort.c:79
#2 0x7eff695b449e in talloc_abort (reason=0x7eff695be070 "Bad
talloc magic value - unknown value") at ../../talloc.c:505
#3 0x7eff695b4497 in talloc_abort_unknown_value () at
../../talloc.c:534
#4 0x7eff695b4497 in talloc_chunk_from_ptr (ptr=0x21a1ff0) at
../../talloc.c:534
#5 0x7eff695b4497 in _talloc_free (ptr=0x21a1ff0,
location=) at ../../talloc.c:1767
#6 0x7eff69805ccd in ffi_call_unix64 () at ../src/x86/unix64.S:101
#7 0x7eff6980525a in ffi_call_int
(cif=0x7ffdb95c5640, fn=0x7eff697e83e0 ,
rvalue=, avalue=, closure=)
at ../src/x86/ffi64.c:669
#8 0x7eff6984d54a in _call_function_pointer
(argcount=1, resmem=0x7ffdb95c55a0, restype=,
atypes=0x7ffdb95c5580, avalues=0x7ffdb95c5590, pProc=0x7eff697e83e0
, flags=) at
./Modules/_ctypes/callproc.c:871
#9 0x7eff6984d54a in _ctypes_callproc
(pProc=0x7eff697e83e0 , argtuple=, flags=, argtypes=, restype=None,
checker=0x0)
at ./Modules/_ctypes/callproc.c:1214
#10 0x7eff6984ce0c in PyCFuncPtr_call (self=,
inargs=, kwds=0x0) at ./Modules/_ctypes/_ctypes.c:4201
#11 0x00510243 in _PyObject_MakeTpCall
(callable=<_FuncPtr(__name__='notmuch_query_destroy') at remote
0x7eff68ccf340>, args=, nargs=,
keywords=)
at ../Include/internal/pycore_pyerrors.h:13
#12 0x0050a847 in _PyObject_Vectorcall
(kwnames=0x0, nargsf=, args=0x7eff672e7ec0,
callable=<_FuncPtr(__name__='notmuch_query_destroy') at remote 0x7eff68ccf340>)
at ../Include/cpython/abstract.h:125
#13 0x0050a847 in _PyObject_Vectorcall
(kwnames=0x0, nargsf=, args=0x7eff672e7ec0,
callable=<_FuncPtr(__name__='notmuch_query_destroy') at remote 0x7eff68ccf340>)
at ../Include/cpython/abstract.h:115
#14 0x0050a847 in call_function (kwnames=0x0, oparg=, pp_stack=, tstate=0x1c74060) at ../Python/ceval.c:4963
#15 0x0050a847 in _PyEval_EvalFrameDefault (f=,
throwflag=) at ../Python/ceval.c:3469
#16 0x0051aa70 in PyEval_EvalFrameEx
(throwflag=0, f=Frame 0x7eff672e7d40, for file
/usr/lib/python3/dist-packages/notmuch/query.py, line 237, in __del__
(self=,
mode=1) at remote 0x7eff67da8850>, _query=, sort=None) at remote 0x7eff67db0610>)) at ../Python/ceval.c:741
#17 0x0051aa70 in function_code_fastcall (globals=, nargs=1, args=, co=) at
../Objects/call.c:283
#18 0x0051aa70 in _PyFunction_Vectorcall (func=,
stack=, nargsf=, kwnames=)
at ../Objects/call.c:410
#19 0x005628bd in _PyObject_Vectorcall (kwnames=0x0, nargsf=1,
args=0x7ffdb95c5918, callable=)
at ../Include/cpython/abstract.h:147
#20 0x005628bd in _PyObject_FastCall (nargs=1,
args=0x7ffdb95c5918, func=) at
../Include/cpython/abstract.h:147
#21 0x005628bd in call_unbound_noarg (unbound=,
func=, self=)
at ../Objects/typeobject.c:1465
#22 0x00603fb7 in slot_tp_finalize
(self=, mode=1) at remote 0x7eff67da8850>, _query=, sort=None) at remote 0x7eff67db0610>) at
../Objects/typeobject.c:6835
#23 0x004f5789 in finalize_garbage (collectable=0x7ffdb95c59d0)
at ../Modules/gcmodule.c:883
#24 0x004f5789 in collect.constprop.0 (generation=2,
n_collected=0x7ffdb95c5aa0, n_uncollectable=0x7ffdb95c5aa8, nofail=0,
state=)
at ../Modules/gcmodule.c:1112
#25 0x005ca15a in collect_with_callback.constprop.0
(generation=generation@entry=2, state=) at
../Modules/gcmodule.c:1240
#26 0x005edb28 in PyGC_Collect () at ../Modules/gcmodule.c:1833
#27 0x005ec616 in Py_FinalizeEx () at
../Python/pylifecycle.c:1223
#28 0x005fb138 in Py_Exit (sts=1) at
../Python/pylifecycle.c:2295
#29 0x005f1f2b in handle_system_exit () at
../Python/pythonrun.c:658
#30 0x005f1e72 in _PyErr_PrintEx (set_sys_last_vars=1,
tstate=0x1c74060) at ../Python/pythonrun.c:763
#31 0x005f1e72 in PyErr_PrintEx (set_sys_last_vars=1) at
../Python/pythonrun.c:763
#32 0x005efdde
Bug#970442: libopenmpi-dev/sid and openmpi-bin/stable ship the same file
Package: libopenmpi-dev Version: 4.0.5-3 Severity: serious Justification: Policy 7.4 During an apt run on a machine that runs a mix of stable and testing/unstable I hit: dpkg: error processing archive /tmp/apt-dpkg-install-HP9Wwp/08-libopenmpi-dev_4.0.5-3_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/oshmem_info.1.gz', which is also in package openmpi-bin 3.1.3-11 This was also already noticed by piuparts: https://piuparts.debian.org/stable2sid/fail/libopenmpi-dev_4.0.5-3.log which can be consulted for a complete apt log. Best regards Uwe
Bug#900958: ITP: barebox-host-tools -- useful development tools from the barebox source tree
Control: retitle 900958 ITP bareobx -- a bootloader and its host tools Control: owner 900958 ! Hello, On Thu, Nov 29, 2018 at 11:14:36AM +0100, Roland Hieber wrote: > For the record, the current problem is assembling debian/copyright > automatically according to DEP-5. The file headers and copyright holders > are not always recognizable by licensecheck, but upstream is discussing > about using SPDX in the future, so I'll wait if that helps. I'm working on this (again) and intend to package barebox not only to provide a tools package but also some bootloader images. Roland told me that he currently doesn't find the time to maintain barebox, so I'm taking over this ITP. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#970106: lintian-info.1.gz is a dangling symlink
Hello Felix, thanks for looking into my bug (even before I reported it :-) On 9/11/20 9:46 PM, Felix Lechner wrote: > On Fri, Sep 11, 2020 at 12:15 PM Uwe Kleine-König wrote: >> >> man: warning: /usr/share/man/man1/lintian-info.1.gz is a dangling symlink > > Thanks for reporting this. It was fixed earlier this morning: > > https://salsa.debian.org/lintian/lintian/-/commit/0cb2170036d65a28afd669ea894b319709a12e6f > > Closing this bug. I'm a bit surprised. In my bubble bugs are closed once the fix is in an apt installable package. Setting the pending flag seems appropriate to me instead (and I'm a bit annoyed about myself to not have set it with my report). Best regards Uwe
Bug#970106: lintian-info.1.gz is a dangling symlink
Package: lintian Version: 2.94.0 Severity: normal Hello, $ man lintian-info man: warning: /usr/share/man/man1/lintian-info.1.gz is a dangling symlink No manual entry for lintian-info See 'man 7 undocumented' for help when manual pages are not available. I see this is already fixed in git[1], so just report this bug for others who hit this problem to locate it quicker. Best regards Uwe [1] https://salsa.debian.org/lintian/lintian/-/commit/0cb2170036d65a28afd669ea894b319709a12e6f -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (800, 'stable-updates'), (800, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable'), (499, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35-2 ii bzip2 1.0.6-9.2~deb10u1 ii diffstat1.62-1 ii dpkg1.19.7 ii dpkg-dev1.19.7 ii file1:5.35-4+deb10u1 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b3 ii libarchive-zip-perl 1.64-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b5 ii libclone-perl 0.45-1 ii libconfig-tiny-perl 2.23-1 ii libcpanel-json-xs-perl 4.19-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1 ii libdevel-size-perl 0.83-1+b1 ii libdpkg-perl1.19.7 ii libemail-address-xs-perl1.04-1+b2 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1 ii libhtml-html5-entities-perl 0.004-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004000-1 ii liblist-compare-perl0.53-1 ii liblist-moreutils-perl 0.416-1+b5 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.003004-2 ii libmoox-aliases-perl0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.108-1 ii libperlio-gzip-perl 0.19-1+b6 ii libproc-processtable-perl 0.59-2 ii libsereal-decoder-perl 4.017+ds-1 ii libsereal-encoder-perl 4.017+ds-1 ii libtext-glob-perl 0.10-1 ii libtext-levenshteinxs-perl 0.03-4+b7 ii libtext-markdown-discount-perl 0.12-1 ii libtext-xslate-perl 3.5.8-1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b2 ii libtimedate-perl2.3300-1 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.004004-1 ii libunicode-utf8-perl0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl 2.0134+dfsg-2 ii libyaml-libyaml-perl0.82+repack-1 ii lzip1.21-8 ii lzop1.03-4+b1 ii man-db 2.8.5-2 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.30.3-4 ii t1utils 1.41-3 ii unzip 6.0-23+deb10u1 ii xz-utils5.2.4-1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.35-2 ii libtext-template-perl 1.55-1 -- no debconf information
