Bug#1071757: SyntaxWarning: invalid escape sequence with Python 3.12

[Kevin Locke]

Package: python3-azext-devops
Version: 1.0.1-1
Severity: normal
Tags: upstream
Forwarded: https://github.com/Azure/azure-devops-cli-extension/pull/1414

Dear Maintainer,

Installing python3-azext-devops 1.0.1-1 produces the following output:

Setting up python3-azext-devops (1.0.1-1) ...
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_0/feed/models.py:101: 
SyntaxWarning: invalid escape sequence '\,'
  """FeedCore.
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_0/feed/models.py:209: 
SyntaxWarning: invalid escape sequence '\,'
  """FeedUpdate.
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_0/feed/models.py:985: 
SyntaxWarning: invalid escape sequence '\,'
  """Feed.
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_1/feed/models.py:101: 
SyntaxWarning: invalid escape sequence '\,'
  """
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_1/feed/models.py:220: 
SyntaxWarning: invalid escape sequence '\,'
  """
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_1/feed/models.py:1049:
 SyntaxWarning: invalid escape sequence '\,'
  """
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v6_0/feed/models.py:101: 
SyntaxWarning: invalid escape sequence '\,'
  """
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v6_0/feed/models.py:224: 
SyntaxWarning: invalid escape sequence '\,'
  """
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v6_0/feed/models.py:1080:
 SyntaxWarning: invalid escape sequence '\,'
  """

I believe this is due to changes in Python 3.12 as a result of
https://github.com/python/cpython/issues/98401.

I have opened a pull request to fix the issue upstream:
https://github.com/Azure/azure-devops-cli-extension/pull/1414

Thanks,
Kevin


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.9.0 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-azext-devops depends on:
ii  python33.11.8-1
ii  python3-azure-cli  2.50.0-2
ii  python3-distro 1.9.0-1
ii  python3-keyring25.2.1-1

python3-azext-devops recommends no packages.

python3-azext-devops suggests no packages.

-- no debconf information

Bug#1064543: python3-launchpadlib: Failed to start launchpadlib-cache-clean.service

[Kevin Locke]

Package: python3-launchpadlib
Version: 1.11.0-4
Severity: normal

Dear Maintainer,

After upgrading to 1.11.0-4, I have observed the following errors in
my system log:

2024-02-23T15:03:42-07:00 systemd[1538]: launchpadlib-cache-clean.service: 
Failed with result 'exit-code'.
2024-02-23T15:03:42-07:00 systemd[1538]: Failed to start 
launchpadlib-cache-clean.service - Clean up old files in the Launchpadlib cache.

After examining /usr/lib/systemd/user/launchpadlib-cache-clean.service
I suspect that this is because ~/.launchpadlib does not exist for my
user.  It would be nice if the unit only ran when required.  Perhaps

ConditionPathExists=%h/.launchpadlib/api.launchpad.net/cache

could be added to the [Unit] section of launchpadlib-cache-clean.service?

Thanks for considering,
Kevin


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'oldstable-security'), (500, 'unstable'), 
(500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.0-rc5 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-launchpadlib depends on:
ii  init-system-helpers 1.66
ii  python3 3.11.6-1
ii  python3-httplib20.20.4-3
ii  python3-lazr.restfulclient  0.14.6-1
ii  python3-lazr.uri1.0.6-3

python3-launchpadlib recommends no packages.

Versions of packages python3-launchpadlib suggests:
ii  python3-keyring24.3.0-1
ii  python3-pkg-resources  68.1.2-2
pn  python3-testresources  

-- no debconf information

Bug#1036049: cryptsetup-initramfs: support for compressed modules

[Kevin Locke]

Package: cryptsetup-initramfs
Version: 2:2.6.1-4~deb12u1
Severity: wishlist
Tags: patch

Dear Maintainer,

When Linux is configured with CONFIG_MODULE_COMPRESS_{GZIP,XZ,ZSTD},
modules are compressed and stored with a .ko.{gz,xz,zst} extension.
This causes the cryptroot hook script not to add the modules to the
initramfs, which can cause boot failures.  Although compression is not
currently enabled in any Debian kernel configuration that I'm aware
of, it would be nice if cryptsetup-initramfs could support this
configuration for downstream distributions and users with custom
kernels.

I've attached a patch to add support, as done by initramfs-tools:
https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/8c806b446fab5f5807651a5c7869141837592ecd
Note that the situation has changed a bit since that commit and kmod
now supports zstd (Bug 990092) in addition to xz (Bug 772628).

Thanks for considering,
Kevin

-- Package-specific info:

-- System Information:
Debian Release: 12.0
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'stable'), (101, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-rc1+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptsetup-initramfs depends on:
ii  busybox 1:1.35.0-4+b3
ii  cryptsetup  2:2.6.1-4~deb12u1
ii  debconf [debconf-2.0]   1.5.82
ii  initramfs-tools [linux-initramfs-tool]  0.142

Versions of packages cryptsetup-initramfs recommends:
ii  console-setup  1.220
ii  kbd2.5.1-1+b1

cryptsetup-initramfs suggests no packages.

-- debconf information excluded
>From e52a22ea1ccc9bc66f80d1e3d2eb9ed5e92e4022 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Kevin Locke 
Date: Sat, 13 May 2023 22:37:01 -0600
Subject: [PATCH] initramfs: cryptroot support compressed modules

When Linux is configured with CONFIG_MODULE_COMPRESS_{GZIP,XZ,ZSTD},
modules are compressed and stored with a .ko.{gz,xz,zst} extension. This
causes the cryptroot hook script not to add the modules to the
initramfs, which can cause boot failures.

Match module files with additional extensions, as in
https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/8c806b446fab5f5807651a5c7869141837592ecd
for initramfs-tools.  Note that kmod now supports zstd (Bug 990092) in
addition to xz (Bug 772628).

Signed-off-by: Kevin Locke 
---
 debian/initramfs/hooks/cryptroot | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/initramfs/hooks/cryptroot b/debian/initramfs/hooks/cryptroot
index 35577865..7b438593 100644
--- a/debian/initramfs/hooks/cryptroot
+++ b/debian/initramfs/hooks/cryptroot
@@ -266,8 +266,8 @@ populate_CRYPTO_MODULES() {
 add_modules() {
 local glob="$1" found=n
 shift
-for mod in $(find -H "$@" -name "$glob.ko" -type f -printf '%f\n'); do
-manual_add_modules "${mod%.ko}"
+for mod in $(find -H "$@" -name "$glob.ko*" -type f -printf '%f\n'); do
+manual_add_modules "${mod%.ko*}"
 found=y
 done
 [ "$found" = y ] && return 0 || return 1
-- 
2.39.2

Bug#1033532: aptitude: forgets upgrade action(s) to experimental after becoming root

[Kevin Locke]

Package: aptitude
Version: 0.8.13-5
Severity: normal

Dear Maintainer,

When running aptitude 0.8.13-5 as a non-root user, if an installed
package is marked for upgrade to a version from experimental, aptitude
forgets about the action after becoming root.  To reproduce, starting
from a fresh installation of Debian testing, as root:

echo 'deb https://deb.debian.org/debian experimental main' 
>/etc/apt/sources.list.d/debian-experimental.list
apt update
apt install aptitude

Then as a non-root user:

1. Run aptitude.
2. Mark an installed package for upgrade to the version from experimental.
   (e.g. upgrade mawk 1.3.4.20200120-3.1 to 1.3.4.20230203-1~exp1)
3. Press g to start an install run.
4. Become root when prompted.

Observe that after becoming root, the package upgrade is no longer
pending and the following message appears:

> No packages are scheduled to be installed, removed or upgraded.

Instead, the upgrade action should still be pending so it can be
completed as root.

Thanks,
Kevin

Note: This issue appears similar to https://bugs.debian.org/398956
where purge actions are forgotten after becoming root.


-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 12.1.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.3
  libsigc++ version: 2.10.8
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.4.20221231
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7fff085eb000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7fbf327df000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fbf327a5000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fbf32773000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fbf32e2f000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7fbf32681000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fbf32522000)
libboost_iostreams.so.1.74.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 (0x7fbf3250a000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fbf3220)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fbf32e28000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fbf31e0)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fbf32121000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fbf324ea000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fbf31c1f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fbf324cb000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fbf324b8000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fbf32489000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7fbf32463000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7fbf32065000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fbf32436000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7fbf31b5)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fbf31a09000)
libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7fbf3205)
/lib64/ld-linux-x86-64.so.2 (0x7fbf32e3a000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fbf32046000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7fbf3203a000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7fbf319e1000)

-- System Information:
Debian Release: 12.0
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
'unstable'), (101, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-rc3-dirty (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-5
ii  libapt-pkg6.0 2.6.0
ii  libboost-iostreams1.74.0  1.74.0+ds1-20
ii  libc6 2.36-8
ii  libcwidget4   0.5.18-6
ii  libgcc-s1 12.2.0-14
ii  libncursesw6  6.4-2
ii  libsigc++-2.0-0v5 2.12.0-1
ii  libsqlite3-0  3.40.1-2
ii  libstdc++612.2.0-14
ii  libtinfo6 6.4-2
ii  libxapian30   1.4.22-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.21.21
ii  sensible-utils  0.0.17+nmu1

Versions of packages 

Bug#1024981: chromium: .remove-on-upgrade [...]/duckduckgo.json: Not found in archive

[Kevin Locke]

Package: chromium
Version: 107.0.5304.121-1~deb11u1
Severity: minor

Dear Maintainer,

When the chromium package is upgraded by unattended-upgrades on
Bullseye it produces the following error:

tar: .remove-on-upgrade /etc/chromium/policies/recommended/duckduckgo.json: Not 
found in archive
tar: Exiting with failure status due to previous errors

To reproduce the error on a fresh Bullseye install run (as root):

apt install -y unattended-upgrades chromium=104.0.5112.79-1~deb11u1 
chromium-common=104.0.5112.79-1~deb11u1
unattended-upgrades

Although chromium and chromium-common are upgraded from
104.0.5112.79-1~deb11u1 to 107.0.5304.121-1~deb11u1, the error message
is concerning (and annoying).  It would be nice if it could be fixed
or avoided.

Note: /etc/chromium/policies/recommended/duckduckgo.json does not
exist in either version of the package, as far as I can tell.

Thanks for considering,
Kevin

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-19-amd64 (SMP w/1 CPU thread)
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 chromium depends on:
ii  chromium-common107.0.5304.121-1~deb11u1
ii  libasound2 1.2.4-1.1
ii  libatk-bridge2.0-0 2.38.0-1
ii  libatk1.0-02.36.0-2
ii  libatomic1 10.2.1-6
ii  libatspi2.0-0  2.38.0-4
ii  libbrotli1 1.0.9-2+b2
ii  libc6  2.31-13+deb11u5
ii  libcairo2  1.16.0-5
ii  libcups2   2.3.3op2-3+deb11u2
ii  libdbus-1-31.12.24-0+deb11u1
ii  libdouble-conversion3  3.1.5-6.1
ii  libdrm22.4.104-1
ii  libevent-2.1-7 2.1.12-stable-1
ii  libexpat1  2.2.10-2+deb11u5
ii  libflac8   1.3.3-2+deb11u1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1+deb11u1
ii  libgbm120.3.5-1
ii  libgcc-s1  10.2.1-6
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libjpeg62-turbo1:2.0.6-4
ii  libjsoncpp24   1.9.4-4
ii  liblcms2-2 2.12~rc1-2
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.29-1
ii  libnss32:3.61-1+deb11u2
ii  libopenjp2-7   2.4.0-3
ii  libopus0   1.3.1-0.1
ii  libpango-1.0-0 1.46.2-3
ii  libpng16-161.6.37-3
ii  libpulse0  14.2-2
ii  libre2-9   20210201+dfsg-1
ii  libsnappy1v5   1.1.8-1
ii  libstdc++6 10.2.1-6
ii  libwebp6   0.6.1-2.1
ii  libwebpdemux2  0.6.1-2.1
ii  libwebpmux30.6.1-2.1
ii  libwoff1   1.0.2-1+b1
ii  libx11-6   2:1.7.2-1
ii  libxcb11.14-3
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.5-2
ii  libxext6   2:1.3.3-1.1
ii  libxfixes3 1:5.0.3-2
ii  libxkbcommon0  1.0.3-2
ii  libxml22.9.10+dfsg-6.7+deb11u3
ii  libxnvctrl0470.141.03-1~deb11u1
ii  libxrandr2 2:1.5.1-1
ii  libxslt1.1 1.1.34-4+deb11u1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backen  1.8.0-1
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

Versions of packages chromium recommends:
ii  chromium-sandbox  

Bug#1017988: bluez: systemd: ConfigurationDirectory 'bluetooth' already exists but the mode is different

[Kevin Locke]

Package: bluez
Version: 5.65-1
Severity: minor

Dear Maintainer,

With bluez 5.65-1 and systemd 251.3-1, the following message is logged
on boot:

systemd[1234]: ConfigurationDirectory 'bluetooth' already exists but the mode 
is different. (File system: 755 ConfigurationDirectoryMode: 555)

My understanding is that this occurs because bluez creates the
/etc/bluetooth directory with mode 0755, yet
/lib/systemd/system/bluetooth.service contains

[Service]
ConfigurationDirectory=bluetooth
ConfigurationDirectoryMode=0555

Creating /etc/bluetooth with mode 0555 or setting
ConfigurationDirectoryMode to 0755 should resolve the warning.

Thanks,
Kevin


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'stable-debug'), (500, 'unstable'), (101, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-rc2 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bluez depends on:
ii  dbus [default-dbus-system-bus]  1.14.0-2
ii  init-system-helpers 1.64
ii  kmod30+20220630-3
ii  libasound2  1.2.7.2-1
ii  libc6   2.34-4
ii  libdbus-1-3 1.14.0-2
ii  libdw1  0.187-1
ii  libglib2.0-02.72.3-1+b1
ii  libreadline88.1.2-1.2
ii  libudev1251.3-1
ii  lsb-base11.2
ii  udev251.3-1

bluez recommends no packages.

Versions of packages bluez suggests:
pn  pulseaudio-module-bluetooth  

-- no debconf information

Bug#977792: closed by Debian FTP Masters

[Kevin Locke]

found 977792 16.15.1+dfsg-1
found 977792 18.3.0+dfsg-1
thanks

On Sun, 2022-05-29 at 19:25 +0200, Jérémy Lal wrote:
> Le dim. 29 mai 2022 à 19:18, Kevin Locke  a écrit :
>> It may also be worth considering adding nodejs.links with content:
>> /usr/share/bash-completion/completions/node
>>  /usr/share/bash-completion/completions/nodejs
>> So that users will get completion for `node ` in addition to
>> `nodejs `.
> 
> Well, exactly !
> And thank you !
> The next update will fix this.

Thanks again for working on this issue and for such quick fixes!  I
must apologize for giving you bad advice.  The line I recommended for
nodejs.links was backward, which causes debhelper to overwrite the
bash-completion script named nodejs with a broken symlink pointing to
a nonexistent file named node.  My intent was to create a link named
node pointing to the bash-completion script named nodejs.  To do this,
the line in debian/nodejs.links should actually be:

/usr/share/bash-completion/completions/nodejs 
/usr/share/bash-completion/completions/node

My apologies,
Kevin

Bug#1013181: freerdp2-wayland: ERRCONNECT_TLS_CONNECT_FAILED with libssl3 and Server 2008 R2

[Kevin Locke]

Package: freerdp2-wayland
Version: 2.7.0+dfsg1-1+b1
Severity: normal

Dear Maintainer,

Attempting to connect to a computer running Remote Desktop Services on
Windows Server 2008 R2 (with default settings as far as I am aware)
using FreeRDP 2.7.0+dfsg1-1+b1 with default options fails with:

$ wlfreerdp /v:192.168.0.2
[08:00:38:003] [283611:283611] [ERROR][com.freerdp.core] - 
transport_connect_tls:freerdp_set_last_error_ex ERRCONNECT_TLS_CONNECT_FAILED 
[0x00020008]
[08:00:38:005] [283611:283611] [ERROR][com.freerdp.client.wayland] - Failed to 
connect

Using FreeRDP 2.7.0+dfsg1-1 (or 2.6.1+dfsg1-3+b1) works as expected.

This appears to be the same issue as Debian Bug 912206.  However, it
is now necessary to use seclevel 0 (by adding
/tls-ciphers:DEFAULT@SECLEVEL=0 or /tls-seclevel:0) rather than 1.

Since Server 2008 R2 is no longer generally supported, I wouldn't
recommend decreasing the default seclevel (unless there are other
supported RDP server versions which require it) but it would be nice
if the error message gave users some suggestions for likely causes of
ERRCONNECT_TLS_CONNECT_FAILED and how to address them.

Thanks,
Kevin


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'stable-debug'), (500, 'unstable'), (101, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-rc2 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages freerdp2-wayland depends on:
ii  libc6 2.33-7
ii  libfreerdp-client2-2  2.7.0+dfsg1-1+b1
ii  libfreerdp2-2 2.7.0+dfsg1-1+b1
ii  libuwac0-02.7.0+dfsg1-1+b1
ii  libwinpr2-2   2.7.0+dfsg1-1+b1

freerdp2-wayland recommends no packages.

freerdp2-wayland suggests no packages.

-- no debconf information

Bug#977792: closed by Debian FTP Masters

[Kevin Locke]

found 977792 16.15.0+dfsg-1
thanks

On Fri, 2022-05-27 at 14:54 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the nodejs package:
> 
> #977792: nodejs: install bash-completion script
> 
> It has been closed by Debian FTP Masters  
> (reply to Jérémy Lal ).

Thanks for working on this issue!  Unfortunately, it does not appear
to be fixed in 16.15.0+dfsg-1, as the
/usr/share/bash-completion/completions directory is empty in this
version:

$ dget nodejs=16.15.0+dfsg-1
$ dpkg -c nodejs_16.15.0+dfsg-1_amd64.deb | grep bash-completion
drwxr-xr-x root/root 0 2022-05-27 07:48 ./usr/share/bash-completion/
drwxr-xr-x root/root 0 2022-05-27 07:48 
./usr/share/bash-completion/completions/

The buildd log for amd64[1] includes:

/bin/sh: 1: ./node: not found

in debian/rules override_dh_auto_build-arch on line 1443.  Which
appears be the source of the problem.  Apparently the error is not
fatal because it occurs in a variable substitution?  Was that
intentional?  Perhaps it could be fixed and made fatal with:

--- a/debian/rules
+++ b/debian/rules
@@ -257,7 +257,7 @@ endif
 
 override_dh_auto_build-arch: deps_build
dh_auto_build
-   $(shell ./node --completion-bash > ./debian/nodejs.bash-completion)
+   ./out/Release/node --completion-bash > ./debian/nodejs.bash-completion
 
 override_dh_auto_build-indep: deps_links
mkdir -p $(DEBIAN_DOC_DEPS)


It may also be worth considering adding nodejs.links with content:
/usr/share/bash-completion/completions/node 
/usr/share/bash-completion/completions/nodejs
So that users will get completion for `node ` in addition to
`nodejs `.

Thanks again,
Kevin

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=nodejs=amd64=16.15.0%2Bdfsg-1=1653680475=0

Bug#1011399: pipewire: create pipewire group with rlimits for rtprio/priority/memlock

[Kevin Locke]

Package: pipewire
Version: 0.3.51-1
Severity: wishlist

Dear Maintainer,

During the investigation of a scheduler priority issue in WirePlumber,
Niklāvs Koļesņikovs lamented Debian's use of RTKit for setting
scheduling priority[1], rather than a group with increased rlimits as
recommended in the Pipewire wiki.[2]  Niklāvs noted some of the
benefits:[3]

1. RTKit does not support Flatpak, whereas RLIMITs do work inside user
   namespaces.
2. RTKit usually does not go above priority 19 (though it should be
   noted that there's some level of disagreement in the pro audio
   community on what the appropriate priority for audio daemons [and
   applications] should be).
3. RTKit is known to sometimes think that its canary thread is
   starving when the system exits S3 sleep state, this will cause
   RTKit to revoke realtime from all clients until at least the
   particular client restarts (possibly also RTKit restart but I'm
   not immediately sure if it's that bad). The exact mechanism is
   unknown but speculated to happen if the canary thread or the
   watchdog ends up frozen at particular point making it perceive a
   huge realtime scheduling delay.
4. RTKit is actually abandoned with no upstream being interested or
   active in fixing bugs such as the previously described canary
   starvation issue. Worst of all the same will likely be true if a
   security issue is discovered.

Additionally:

5. It would allow raising the memlock rlimit, not handled by RTKit.
6. It would allow creating the WirePlumber GLib thread pool threads
   at a nice level matching the main thread and avoiding the
   "Failed to set scheduler settings: Operation not permitted"
   currently printed by wireplumber on startup.[4]

Perhaps it would make sense for the pipewire package to create a
pipewire group, configure the suggested rlimit values in a
/etc/security/limits.d/ file, and document use of the group in
README.Debian?

Thanks for considering,
Kevin

[1]: 
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/255#note_1393924
[2]: 
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance-tuning#rlimits
[3]: 
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/255#note_1394696
[4]: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/255

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'stable-debug'), (500, 'unstable'), (101, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-rc7 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pipewire depends on:
ii  init-system-helpers  1.62
ii  libpipewire-0.3-modules  0.3.51-1
ii  pipewire-bin 0.3.51-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1010041: ident: awk: syntax error in regular expression $^

[Kevin Locke]

Package: joystick
Version: 1:1.7.1-1
Severity: normal
Tags: patch

Dear Maintainer,

When original-awk is configured as /usr/bin/awk, jscal-store produces
the following errors:

/usr/bin/awk: syntax error in regular expression $^ at 
 source line number 41 source file /usr/share/joystick/ident
 context is
 >>> /$^/ <<<  {
No product name or vendor available, calibration will be stored for the
given device name () only!
/usr/bin/awk: syntax error in regular expression $^ at 
 source line number 69 source file /usr/share/joystick/filter
 context is
if ($0 ~ >>>  /$^/ <<< ) {

This can be fixed by changing /$^/ to /^$/ on line 41 of ident and 69
of filter, as in the attached patch.

Thanks,
Kevin

Note: I think this might be a bug in original-awk (although it also
present in BSD awk), so I've opened
 as well.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'stable-debug'), (500, 'unstable'), (101, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-rc3 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages joystick depends on:
ii  libc6  2.33-7
ii  libsdl2-2.0-0  2.0.20+dfsg-2

Versions of packages joystick recommends:
ii  evtest   1:1.34-1
pn  inputattach  

joystick suggests no packages.


0001-avoid-syntax-error-with-original-awk.patch
Description: inode/empty

Bug#1004083: plocate: stops with misleading error on pruned filesystem

[Kevin Locke]

On Sun, 2022-01-30 at 21:16 +0100, Steinar H. Gunderson wrote:
> On Sun, Jan 30, 2022 at 07:25:55PM +0100, Steinar H. Gunderson wrote:
>> Yes, I wonder if this is the best fix for this specific issue.
>> If there's an error, there's no performance issue, since the alternative
>> is total failure; we can check /proc/mounts before deciding to crash out
>> or nt.
> 
> I've pushed a change for this to upstream git; are you in a position to try
> it out?

Sure thing.  After re-creating the broken CIFS mount on /mnt, I ran:

updatedb -o /tmp/plocate.db
locate -d /tmp/plocate.db debian_version

I can confirm that with 5aea022 updatedb prints

/mnt: Host is down

then exits with code 1 (and does not create /tmp/plocate.db).  With
e734063 updatedb exits with code 0 and no error is printed.  locate
prints /etc/debian_version as expected.

Those both seem like great improvements to me.  Thank you for the
quick response and fixes!

Cheers,
Kevin

Bug#1004083: plocate: stops with misleading error on pruned filesystem

[Kevin Locke]

Thanks for the thoughtful response!

On Sun, 2022-01-30 at 18:47 +0100, Steinar H. Gunderson wrote:
> On Thu, Jan 20, 2022 at 08:05:14AM -0700, Kevin Locke wrote:
>> 2. The error occurred on a CIFS filesystem, which is excluded by
>>PRUNEFS in /etc/updatedb.conf.  Presumably it should be skipped
>>rather than causing an error.
> 
> The problem is that updatedb doesn't really know for sure it entered a new
> filesystem until it's stat-ed the directory. [...]
> 
>> 3. updatedb immediately aborts, rather than updating the database for
>>the rest of the filesystem.  In this case, since the failing mount
>>was at the root, the entire tree is skipped.
> 
> I don't honestly think this is a bug. If updatedb goes wrong for whatever
> reason, it's not good to just silently discard parts of the database.
> If nothing else, the next rescan could become very expensive.

I think the behavior is understandable in both of the above cases,
although it's unfortunate that a flakey mount on an excluded
filesystem at an otherwise always empty directory causes updatedb to
fail entirely.  I'm not sure if it might be worth the effort to check
/proc/mounts or statfs(2) on stat(2) failure (for certain error
codes?), or to consider whether the directory is currently empty in
the database, or to skip it without discarding previous entries, or
something else.  I'll defer to your judgement.

It's not a common or major issue for me.  Feel free to close or treat
as low-priority.  I thought it was worth raising the issue for
consideration, but don't have strong feelings about it.

Cheers,
Kevin

Bug#1004083: plocate: stops with misleading error on pruned filesystem

[Kevin Locke]

Package: plocate
Version: 1.1.14-1
Severity: normal

Dear Maintainer,

On a machine with a CIFS mount on /mnt, plocate-updatedb.service
failed and updatedb.plocate printed:

/: Host is down

Running updatedb.plocate -v printed:

//initrd.img.old
//vmlinuz.old
//mnt
//root
//vmlinuz
//sys
//bin
//run
//etc
//libx32
//lib32
//var
//initrd.img
//usr
//lib
//tmp
//proc
//srv
//home
//dev
//lost+found
//lib64
//media
//sbin
//opt
//boot
/: Host is down

It turns out this the failure was due to a network issue which
prevented contacting the host for the CIFS mount on /mnt.  However,
this presents several issues that might be worth addressing:

1. The error message contains the parent directory, rather than the
   directory which could not be read, which makes the error harder to
   diagnose.
2. The error occurred on a CIFS filesystem, which is excluded by
   PRUNEFS in /etc/updatedb.conf.  Presumably it should be skipped
   rather than causing an error.
3. updatedb immediately aborts, rather than updating the database for
   the rest of the filesystem.  In this case, since the failing mount
   was at the root, the entire tree is skipped.

Let me know if you'd like me to report any of these issues separately.

Thanks for considering,
Kevin


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 
'unstable'), (101, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plocate depends on:
ii  libc6   2.33-2
ii  libgcc-s1   11.2.0-13
ii  libstdc++6  11.2.0-13
ii  liburing2   2.1-2
ii  libzstd11.4.8+dfsg-3

plocate recommends no packages.

Versions of packages plocate suggests:
ii  powermgmt-base  1.36
ii  systemd-sysv250.2-3

-- no debconf information

Bug#1001589: libgsl25: Can't be upgraded to 2.7+dfsg-2

[Kevin Locke]

Hi All,

I'm also having difficulty updating my system because libgsl25 2.7+dfsg-2
and libgsl27 2.7.1+dfsg-3 can not be coinstalled due to requiring
different versions of libgslcblas0.  (See #960515)

I wanted to clarify that sagemath is not the only affected package.
In sid on amd64 the following packages depend on libgsl25:

  bist
  librivet11v5
  libmath-gsl-perl
  enfuse
  enblend

None of these appear to have open bugs for dropping libgsl25 (although
#993323 is related).  Do I understand correctly that bugs should be
filed for these because libgsl25 will never be coinstallable with
libgsl27?  It also appears that libgsl25 is not in testing.  Is that
permanent?

Thanks,
Kevin

Bug#1001472: uscan: "Use of uninitialized value" with searchmode=plain and filenamemangle

[Kevin Locke]

Package: devscripts
Version: 2.21.6
Severity: normal

Dear Maintainer,

Running uscan on a watch file which contains searchmode=plain and any
filenamemangle option causes a "Use of uninitialized value" warning:

curl -o chromium.watch 
https://salsa.debian.org/chromium-team/chromium/-/raw/debian/93.0.4577.82-1/debian/watch
uscan --report --package chromium --upstream-version 93.0.4577.82 --watchfile 
chromium.watch >/dev/null
Use of uninitialized value in concatenation (.) or string at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 204.

I'm able to reproduce the issue with version 2.18.5 where
searchmode was introduced, so I do not believe it is a regression.
The warning does not cause any misbehavior as far as I am aware.

Thanks,
Kevin


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 
'unstable'), (101, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-rc4+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages devscripts depends on:
ii  dpkg-dev  1.20.9
ii  fakeroot  1.25.3-1.1
ii  file  1:5.41-2
ii  gnupg 2.2.27-2
ii  gnupg22.2.27-2
ii  gpgv  2.2.27-2
ii  libc6 2.32-5
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.12-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.005004-3
ii  libwww-perl   6.59-1
ii  patchutils0.4.2-1
ii  perl  5.32.1-6
ii  python3   3.9.7-1
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.3.13
ii  curl7.79.1-2
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2021.09.25
ii  dput1.1.0
ii  equivs  2.3.1
ii  libdistro-info-perl 1.1
ii  libdpkg-perl1.20.9
ii  libencode-locale-perl   1.05-1.1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.26-1
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.31-1
ii  liburi-perl 5.10-1
ii  licensecheck3.2.14-2
ii  lintian 2.111.0
ii  man-db  2.9.4-2
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.3.0+b1
ii  python3-debian  0.1.42
ii  python3-magic   2:0.4.24-2
ii  python3-requests2.25.1+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.27-2
ii  strace  5.10-1
ii  unzip   6.0-26
ii  wget1.21.2-2+b1
ii  xz-utils5.2.5-2

Versions of packages devscripts suggests:
pn  adequate  
pn  at
ii  autopkgtest   5.19
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-2
ii  build-essential   12.9
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 13.5.2
pn  diffoscope
pn  disorderfs
pn  dose-extra
pn  duck  
pn  elpa-devscripts   
pn  faketime  
ii  gnuplot   5.4.1+dfsg1-1
ii  gnuplot-qt [gnuplot]  5.4.1+dfsg1-1
pn  how-can-i-help
ii  libauthen-sasl-perl   2.1600-1.1
pn  libdbd-pg-perl
ii  libfile-desktopentry-perl 0.22-2
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3300-2
ii  libyaml-syck-perl 1.34-1+b1
ii  mmdebstrap0.8.1-1
pn  mozilla-devscripts
ii  mutt  2.1.3-1
ii  openssh-client [ssh-client]   1:8.7p1-2
pn  piuparts

Bug#992215: rsync: please consider re-adding --copy-devices patch

[Kevin Locke]

Hi Samuel,

On Sun, 2021-09-12 at 17:52 +0100, Samuel Henrique wrote:
> Thanks for the detailed bugreport,
> 
> I agree with it and have just uploaded the fix to unstable. I'm gonna
> try to get this into bullseye before the 11.1 release, and
> bullseye-backports shall get the fix after it reaches testing.

That's great!  Thanks for all of your work to re-add the patch and
to apply it to bullseye.  I really appreciate it!

Thanks again,
Kevin

Bug#993524: calibre: pypy3compile "Failed to byte-compile ..." from postinst

[Kevin Locke]

Package: calibre
Version: 5.26.0+dfsg-2
Severity: normal

Dear Maintainer,

Installing calibre 5.26.0+dfsg-2 on a system with pypy3 7.3.5+dfsg-2
installed produced the following message:

Setting up calibre (5.26.0+dfsg-2) ...
Failed to byte-compile /usr/lib/calibre/calibre/utils/formatter.py:   File 
"/usr/lib/calibre/calibre/utils/formatter.py", line 928
if v := self.expr(expr):
  ^
SyntaxError: invalid syntax

It appears that /var/lib/dpkg/info/calibre.postinst contains 2 calls
to py3compile and pypy3compile for /usr/lib/calibre, first with
-V 3.7-, then with -V 3.9:

-8<--[calibre.postinst from line 28]--
if which py3compile >/dev/null 2>&1; then
py3compile -p calibre /usr/lib/calibre -V 3.7-
fi
if which pypy3compile >/dev/null 2>&1; then
pypy3compile -p calibre /usr/lib/calibre -V 3.7- || true
fi


# Automatically added by dh_python3
if which py3compile >/dev/null 2>&1; then
py3compile -p calibre /usr/lib/calibre -V 3.9
fi
if which pypy3compile >/dev/null 2>&1; then
pypy3compile -p calibre /usr/lib/calibre -V 3.9 || true
fi

if which py3compile >/dev/null 2>&1; then
py3compile -p calibre /usr/share/calibre -V 3.9
fi
if which pypy3compile >/dev/null 2>&1; then
pypy3compile -p calibre /usr/share/calibre -V 3.9 || true
fi
-8<--[calibre.postinst]---

On my system, `pypy3compile -p calibre /usr/lib/calibre -V 3.7-`
produces the error.

It appears that removing the calls to py3compile and pypy3compile from
debian/calibre.postinst in favor of the ones added by dh_python3 would
avoid the issue.

Thanks,
Kevin


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 
'unstable'), (101, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-rc7 (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages calibre depends on:
ii  calibre-bin  5.26.0+dfsg-2
ii  dpkg 1.20.9
ii  fonts-liberation22.1.4-2
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  libjpeg-turbo-progs  1:2.0.6-4
ii  libjxr-tools 1.1-6+b1
ii  optipng  0.7.7-1+b1
ii  poppler-utils20.09.0-3.1
ii  python3  3.9.2-3
ii  python3-apsw 3.34.0-r1-1
ii  python3-bs4  4.9.3-1
ii  python3-chardet  4.0.0-1
ii  python3-chm  0.8.6-2+b3
ii  python3-css-parser   1.0.6-1
ii  python3-cssselect1.1.0+ds-1
ii  python3-cssutils 1.0.2-3
ii  python3-dateutil 2.8.1-6
ii  python3-feedparser   5.2.1-3
ii  python3-html2text2020.1.16-1
ii  python3-html5-parser 0.4.9-3+b3
ii  python3-html5lib 1.1-3
ii  python3-jeepney  0.6.0-1
ii  python3-lxml 4.6.3+dfsg-0.1
ii  python3-markdown 3.3.4-1
ii  python3-mechanize1:0.4.5-2
ii  python3-msgpack  1.0.2-2
ii  python3-netifaces0.10.9-0.2+b3
ii  python3-pil  8.1.2+dfsg-0.3
ii  python3-pkg-resources52.0.0-4
ii  python3-py7zr0.11.3+dfsg-1
ii  python3-pygments 2.7.1+dfsg-2.1
ii  python3-pyparsing2.4.7-1
ii  python3-pyqt55.15.2+dfsg-3
ii  python3-pyqt5.qtsvg  5.15.2+dfsg-3
ii  python3-pyqt5.qtwebengine5.15.2-2
ii  python3-pyqt5.sip12.8.1-1+b2
ii  python3-regex0.1.20201113-1
ii  python3-routes   2.5.1-1
ii  python3-speechd  0.10.2-2
ii  python3-zeroconf 0.26.1-1
ii  python3.93.9.2-1
ii  xdg-utils1.1.3-4.1

Versions of packages calibre recommends:
ii  python3-dnspython  2.0.0-1
pn  python3-ipython
ii  udisks22.9.3-1

Versions of packages calibre suggests:
ii  python3-openssl   20.0.1-1
pn  python3-unrardll  

-- no debconf information

Bug#992306: radicale: use "radicale" instead of "env" as syslog identifier

[Kevin Locke]

Package: radicale
Version: 3.0.6-3
Severity: minor

Dear Maintainer,

When radicale is started by systemd, log messages have the syslog
identifier "env".  For example:

Aug 16 03:17:02 servername env[10730]: [2021-08-16 03:17:02 +] 
[10730/Thread-4] [WARNING] Client provided invalid sync token 
'http://radicale.org/ns/sync/4d313dba5726344f8f8299259cfc1875': Malformed 
token: 'http://radicale.org/ns/sync/4d313dba5726344f8f8299259cfc1875'

Which makes finding the source of the messages difficult.  This can be
avoided by changing `ExecStart=/usr/bin/env python3 -m radicale` to
`ExecStart=/usr/bin/radicale` or by adding `SyslogIdentifier=radicale`
to the `[Service]` section of radicale.service.

Thanks for considering,
Kevin


-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'unstable'), (101, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-rc6 (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#992215: rsync: please consider re-adding --copy-devices patch

[Kevin Locke]

Package: rsync
Version: 3.2.0-1
Severity: normal
Control: found -1 3.2.3-4

Dear Maintainer,

In [af31473f] for rsync 3.2.0-1, copy-devices.diff was dropped with
the note that "--copy-devices is now --write-devices".  Unfortunately,
that is only partially true.  Although --write-devices allows writing
to device files, it does not allow copying from devices files as
--copy-devices did.  For example, I could create sparse device images
using:

rsync -S --copy-devices /dev/sdX1 /tmp/sdX1.raw

Replacing --copy-devices with --write-devices produces:

skipping non-regular file "sdX1"

Note that [copy-devices.diff] is still maintained in rsync-patches and
was updated to be compatible with --write-devices in [c9d55ab].

Thanks for considering,
Kevin

[af31473f]: 
https://salsa.debian.org/debian/rsync/-/commit/921ddfb35c2641843cc4f671560d9056ea6b5a05
[c9d55ab]: 
https://git.samba.org/?p=rsync-patches.git;a=commitdiff;h=c9d55ab688df0067fd37d5199650615c6d675074#patch11
[copy-devices.diff]: 
https://git.samba.org/?p=rsync-patches.git;a=blob;f=copy-devices.diff


-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
'oldoldstable'), (500, 'unstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-rc5 (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rsync depends on:
ii  init-system-helpers  1.60
ii  libacl1  2.2.53-10
ii  libc62.31-13
ii  liblz4-1 1.9.3-2
ii  libpopt0 1.18-2
ii  libssl1.11.1.1k-1
ii  libxxhash0   0.8.0-2
ii  libzstd1 1.4.8+dfsg-2.1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:8.4p1-5
ii  openssh-server  1:8.4p1-5
ii  python3 3.9.2-3

-- no debconf information

Bug#991380: graphicsmagick: Assertion failed using -label with PDF

[Kevin Locke]

Package: graphicsmagick
Version: 1.4+really1.3.36+hg16481-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

If the -label option is given when writing a PDF, the following
assertion failure occurs:

$ gm convert -label MyLabel xc:#ff labeled.pdf
gm: magick/memory.c:678: _MagickReallocateResourceLimitedMemory: Assertion 
`memory_resource.signature == MagickSignature' failed.
gm convert: abort due to signal 6 (SIGABRT) "Abort"...

I reported the issue upstream in [#646] and it was fixed in
[22aaff86b4aa].  I'm reporting it here, as suggested by upstream, so
that you are aware, and in case you'd like to carry the patch
(attached) until a new upstream version is released.

Thanks,
Kevin

[#646]: https://sourceforge.net/p/graphicsmagick/bugs/646/
[22aaff86b4aa]: 
https://sourceforge.net/p/graphicsmagick/code/ci/22aaff86b4aa34c10b3fbfb104adaaeef8653a36/


-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'oldstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-rc2 (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages graphicsmagick depends on:
ii  libc62.31-12
ii  libgraphicsmagick-q16-3  1.4+really1.3.36+hg16481-1

graphicsmagick recommends no packages.

Versions of packages graphicsmagick suggests:
pn  graphicsmagick-dbg  

-- no debconf information
Subject: WritePDFImage(): Use appropriate memory deallocator for memory 
returned by StringToList().
Origin: 
https://sourceforge.net/p/graphicsmagick/code/ci/22aaff86b4aa34c10b3fbfb104adaaeef8653a36/
Bug: https://sourceforge.net/p/graphicsmagick/bugs/646/
From: Bob Friesenhahn 
Applied-Upstream: commit:22aaff86b4aa34c10b3fbfb104adaaeef8653a36

# HG changeset patch
# User Bob Friesenhahn 
# Date 1626915582 18000
#  Wed Jul 21 19:59:42 2021 -0500
# Node ID 22aaff86b4aa34c10b3fbfb104adaaeef8653a36
# Parent  acf305f9ef3e85e6273d62e72d81cce03440eb3d
WritePDFImage(): Use appropriate memory deallocator for memory returned by 
StringToList().

diff --git a/ChangeLog b/ChangeLog
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,10 +1,14 @@
 2021-07-21  Bob Friesenhahn  
 
+* coders/pdf.c (WritePDFImage): Use appropriate memory deallocator
+for memory returned by StringToList().  Fixes SourceForge issue
+646 "Assertion failed using -label with PDF".
+
 * coders/webp.c (ReadWEBPImage): Add full error checking when
 retrieving embedded profiles.
 
 * magick/profile.c (SetImageProfile): Do not try to store a
 zero-sized profile.
 
 * coders/webp.c (ReadWEBPImage): Enforce that embedded profiles
 provided by libWebP are not zero-sized. This problem was brought
diff --git a/coders/pdf.c b/coders/pdf.c
--- a/coders/pdf.c
+++ b/coders/pdf.c
@@ -1041,19 +1041,19 @@ static unsigned int WritePDFImage(const 
image_info->pointsize);
   (void) WriteBlobString(image,buffer);
   FormatString(buffer,"%ld %g Td\n",geometry.x,(double) geometry.y+
(double) geometry.height+i*(double) 
image_info->pointsize+12);
   (void) WriteBlobString(image,buffer);
   FormatString(buffer,"(%.1024s) Tj\n",labels[i]);
   (void) WriteBlobString(image,buffer);
   (void) WriteBlobString(image,"ET\n");
-  MagickFreeResourceLimitedMemory(labels[i]);
+  MagickFreeMemory(labels[i]);
 }
-  MagickFreeResourceLimitedMemory(labels);
+  MagickFreeMemory(labels);
 }
   FormatString(buffer,"%g 0 0 %g %ld %ld cm\n",x_scale,y_scale,geometry.x,
geometry.y);
   (void) WriteBlobString(image,buffer);
   FormatString(buffer,"/Im%lu Do\n",image->scene);
   (void) WriteBlobString(image,buffer);
   (void) WriteBlobString(image,"Q\n");
   offset=TellBlob(image)-offset;
diff --git a/www/Changelog.html b/www/Changelog.html
--- a/www/Changelog.html
+++ b/www/Changelog.html
@@ -32,16 +32,19 @@
   Reference
 
 
 
 
 
 2021-07-21  Bob Friesenhahn  mailto:bfriesensimpledallastxus;>bfriesensimpledallastxus
 
+* coders/pdf.c (WritePDFImage): Use appropriate memory deallocator
+for memory returned by StringToList().  Fixes SourceForge issue
+646 Assertion failed using -label with PDF.
 * coders/webp.c (ReadWEBPImage): Add full error checking when
 retrieving embedded profiles.
 * magick/profile.c (SetImageProfile): Do not try to store a
 zero-sized profile.
 * coders/webp.c (ReadWEBPImage): Enforce that embedded profiles
 provided by libWebP are not zero-sized. This problem was 

Bug#991289: /etc/ImageMagick-6/policy.xml: invalid XML due to broken comment

[Kevin Locke]

Package: imagemagick-6-common
Version: 8:6.9.11.60+dfsg-1.3
Severity: normal
File: /etc/ImageMagick-6/policy.xml

Dear Maintainer,

Line 77 of /etc/ImageMagick-6/policy.xml (for name="shared-secret")
has a comment start marker ()
causing the start marker on the next line to occur within a comment,
which is not valid XML[^1]:

> For compatibility, the string "--" (double-hyphen) MUST NOT occur within 
> comments.

As demonstrated by `xmllint /etc/ImageMagick-6/policy.xml`:

/etc/ImageMagick-6/policy.xml:77: parser error : Double hyphen within 
comment: 
^

It does not cause any issues with the ImageMagick tools that I am
aware of, but it complicates use/checking by other tools which parse
the XML more strictly (e.g. XMLStarlet).

The issue is caused by 0007-Improve-policy-in-order-to-be-safer.patch
(d9e5818685) which removed the end marker on line 77.

Thanks,
Kevin

[^1]: https://www.w3.org/TR/REC-xml/#sec-comments


-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
compare:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
convert:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
composite:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
conjure:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
display:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
identify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
import:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
mogrify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
montage:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
stream:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org

-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'oldstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-rc1 (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#991288: imagemagick: update Repository in debian/upstream/metadata

[Kevin Locke]

Source: imagemagick
Version: 8:6.9.11.60+dfsg-1.3
Severity: minor
Tags: patch

Dear Maintainer,

The [Repository in debian/upstream/metadata] responds with 404 Not
Found.  The [Install from Source] page on the ImageMagick website
states:

> The authoritative source code repository is https://github.com/ImageMagick.

It would be nice to update debian/upstream/metadata with the current
repository URL (https://github.com/ImageMagick/ImageMagick6 for IM6,
https://github.com/ImageMagick/ImageMagick for IM7).  I've attached a
patch which does so with the IM6 repository for the current package
version.

Thanks,
Kevin
>From 966afb82d32e892161ec605d3504164c617a9e27 Mon Sep 17 00:00:00 2001
Message-Id: 
<966afb82d32e892161ec605d3504164c617a9e27.1626728544.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Mon, 19 Jul 2021 14:52:41 -0600
Subject: [PATCH] upstream/metadata: update Repository

The [Repository in debian/upstream/metadata] responds with 404 Not
Found.  The [Install from Source] page on the ImageMagick website
states:

> The authoritative source code repository is https://github.com/ImageMagick.

Update Repository in debian/upstream/metadata to point to the git
repository for [ImageMagick 6 on GitHub].

Add Repository-Browse with the browseable URL as well.

[ImageMagick 6 on GitHub]: https://github.com/ImageMagick/ImageMagick6
[Install from Source]: https://imagemagick.org/script/install-source.php
[Repository in debian/upstream/metadata]: 
https://subversion.imagemagick.org/subversion/ImageMagick/trunk

Signed-off-by: Kevin Locke 
---
 debian/upstream/metadata | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/upstream/metadata b/debian/upstream/metadata
index 71f831bf3f..e40ebdf713 100644
--- a/debian/upstream/metadata
+++ b/debian/upstream/metadata
@@ -5,5 +5,6 @@ Bug-Submit: 
http://www.imagemagick.org/discourse-server/viewforum.php?f=3
 Contact: http://www.imagemagick.org/discourse-server/
 FAQ: http://www.imagemagick.org/Usage/
 Homepage: http://www.imagemagick.org/
-Repository: https://subversion.imagemagick.org/subversion/ImageMagick/trunk
+Repository: https://github.com/ImageMagick/ImageMagick6.git
+Repository-Browse: https://github.com/ImageMagick/ImageMagick6
 Security-Contact: Post private message to on the Bug-Submit forum. Add a 
public remainder on the bug forum asking to check private message.
\ No newline at end of file
-- 
2.30.2

Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Kevin Locke]

Hi Carsten,

On Sat, 2021-06-19 at 09:00 +0200, Carsten Schoenert wrote:
> To prevent quite a lot of work on all involved parties with not that
> much gain in the end I'd suggest to go back to my option B that was to
> (re)build Thunderbird with it's internal shipped NSS version.

Sure, that works for me.  If the other stakeholders (security and
release teams?) are ok with that plan, I'll close Bug #990059.
I think Bug #990058 should remain open until fixed in either case.

> I've done such a rebuild of 78.11.0 together with the internal NSS
> library and so far I don't see any TLS/SSL related issue as before.
> 
> The packages and the debian folder can be found here
> 
> https://people.debian.org/~tijuca/thunderbird-bullseye/

I gave it a try and it works well on my system with either libnss3
2:3.61-1 or 2:3.67-1 installed.  (It doesn't appear to use libnss3, as
you said, but I can't uninstall it due to other rdepends on my system).

Thanks again,
Kevin

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Kevin Locke]

Hi Sebastian,

On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote:
> Thanks for this detailed analysis. That actually means that the symbol
> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
> version requirement for all symbols that works with SSLChannelInfo. From
> your description, at least the version for SSL_GetChannelInfo would need
> to be bumped. If thunderbird would then be built against a libnss3
> version with a fixed symbol files, it would pick up tight enought
> dependencies.
> 
> So ideally the bug against thunderbird would be reassigned to libnss3
> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
> thunderbird to pick up the correct depedencies.

Good point.  Fixing the libnss3 symbol file sounds like the right fix to
me.  As far as I can tell SSL_GetChannelInfo is the only symbol which
takes SSLChannelInfo.  I've opened https://bugs.debian.org/990058 with
the proposed fix.

> But since that version of libnss3 is not in bullseye, the rebuild would
> not be abile to migrate. Ideally libnss3 would be reverted to the
> version in bullseye to avoid this issue. Otherwise I can schedule
> binNMUs of thunderbird in tpu, but that means that we would need to do
> that for any thunderbird upload that we want in bullseye until the
> release. That is suboptimal - it's more work with less testing.

That may be tricky.  firefox 88.0.1-1 in unstable depends on
libnss3 (>= 2:3.63~).  If the maintainers are willing to upload an NSS
version between 2:3.63 and 2:3.65, I believe that would solve the issue
without breaking firefox.  (2:3.63-1 is the only suitable version
in debian/changelog.)  I've opened https://bugs.debian.org/990059 to
discuss.

Thanks,
Kevin

P.S. My apologies for not following your suggestion to reassign #989839
to libnss3.  I thought we might need separate issues for better
granularity over the different parts of the issue.  I hope it doesn't
end up causing more confusion or hassle.

Bug#990059: libnss3: Please consider reverting to version in bullseye

[Kevin Locke]

Package: libnss3
Version: 2:3.67-1
Severity: normal
X-Debbugs-Cc: Sebastian Ramacher , Carsten Schoenert 


Dear Maintainer,

Thunderbird 1:78.11.0-1 in bullseye is unable to establish some (all?)
TLS connections, as discussed in Bug #989839 and on debian-release.[1]
To fix the issue, thunderbird needs to be rebuilt against a version of
libnss3-dev compatible with the version of libnss3 in bullseye.
Sebastian Ramacher suggested that libnss3 could be reverted to the
version in bullseye to facilitate this and avoid the need for all
subsequent thunderbird uploads to go through t-p-u until the release.[2]

I'm opening this issue to propose the idea to you.  Thoughts?

Thanks for considering,
Kevin

[1]: https://lists.debian.org/debian-release/2021/06/msg00570.html
[2]: https://lists.debian.org/debian-release/2021/06/msg00597.html

-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'oldstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-rc6 (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 libnss3 depends on:
ii  libc6 2.31-12
ii  libnspr4  2:4.29-1
ii  libsqlite3-0  3.34.1-3

libnss3 recommends no packages.

libnss3 suggests no packages.

-- no debconf information

Bug#990058: libnss3: increase symbol version for SSL_GetChannelInfo when SSLChannelInfo size changes

[Kevin Locke]

Package: libnss3
Version: 2:3.67-1
Severity: serious
Tags: patch
Justification: Policy 8.6.3.3
X-Debbugs-Cc: Sebastian Ramacher , Carsten Schoenert 


Dear Maintainer,

Thunderbird 1:78.11.0-1 in testing is unable to establish some (all?)
TLS connections when run with libnss3 2:3.61-1, because it was built
with libnss3-dev 2:3.66-1.  The issue occurs because the size of
SSLChannelInfo increased between NSS 3.61 and 3.66 (due to the addition
of PRBool isFIPS).  SSL_GetChannelInfo takes both a pointer to and size
of SSLChannelInfo as arguments.  If the size is greater than the size it
expects, it returns SECFailure, causing the connection to fail.  See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989839#48 for details.

The issue is being discussed on debian-release, where Sebastian Ramacher
pointed out that the libnss3 symbol file should bump the minimum version
requirement for all symbols that works with SSLChannelInfo.[1]  I agree.
As far as I can tell, SSL_GetChannelInfo is the only such symbol.  I
believe it should be bumped to 2:3.66 for package 2:3.67 and bumped in
future versions whenever the size of SSLChannelInfo changes.  I've
attached a patch to do so.

Thanks for considering,
Kevin

[1]: https://lists.debian.org/debian-release/2021/06/msg00597.html

-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'oldstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-rc6 (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 libnss3 depends on:
ii  libc6 2.31-12
ii  libnspr4  2:4.29-1
ii  libsqlite3-0  3.34.1-3

libnss3 recommends no packages.

libnss3 suggests no packages.

-- no debconf information
>From eaffc616b99dd2be285ade5df072cfa1e30924fe Mon Sep 17 00:00:00 2001
Message-Id: 

From: Kevin Locke 
Date: Fri, 18 Jun 2021 14:41:27 -0600
Subject: [PATCH] libnss3.symbols: bump SSL_GetChannelInfo to 2:3.66

PRBool isFIPS was added to SSLChannelInfo in NSS 3.66, causing its size
to increase.  Since SSL_GetChannelInfo is called with
sizeof(SSLChannelInfo) and returns SECFailure when called with a larger
size than it expects, it creates a version incompatibility where
programs compiled with NSS >= 3.66 do not function correction when
loaded with NSS < 3.66, as in #989839 for thunderbird.

To avoid breakage, bump the version of SSL_GetChannelInfo, as suggested
by Sebastian Ramacher in
https://lists.debian.org/debian-release/2021/06/msg00597.html

Signed-off-by: Kevin Locke 
---
 debian/libnss3.symbols | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/libnss3.symbols b/debian/libnss3.symbols
index 5213379c..2bb7294a 100644
--- a/debian/libnss3.symbols
+++ b/debian/libnss3.symbols
@@ -154,5 +154,5 @@ libssl3.so libnss3 #MINVER#
  (symver)NSS_3.4 2:3.13.4-2~
  (symver)NSS_3.7.4 2:3.13.4-2~
  SSL_GetCipherSuiteInfo@NSS_3.4 2:3.44.0
- SSL_GetChannelInfo@NSS_3.4 2:3.34
+ SSL_GetChannelInfo@NSS_3.4 2:3.66
  SSL_GetPreliminaryChannelInfo@NSS_3.21 2:3.44.0
-- 
2.30.2

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Kevin Locke]

On 2021-06-17 22:32:46 +0200, Sebastian Ramacher wrote:
> On 2021-06-17 19:54:51, Carsten Schoenert wrote:
>> Unfortunately rather also quickly I got some bug reports about
>> Thunderbird isn't correctly working in testing/bullseye, but has before
>> in version 1:78.10.0-1.
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989839
>> 
>> [...]
>> 
>> But how to proceed right now?
>> 
>> I see two possible options.
>> 
>> 1. Unblock nss 2:3.67-1
>>But I've no idea if Mike has his reasons for not requesting an
>>unblock. But I also can't think of any.
>> 
>> 2. Rebuild the thunderbird package and use the internal shipped nss
>>source which is at 3.51.1.
>>I expect this will get needed any way for bullseye once the next ESR
>>circle is starting as and usually MZLA will use then the most recent
>>available nss version within the shipped source.
>> 
>> What for opinions the RT is seeing?
> 
> Please correct me if I get anything wrong: thunderbird requires nss3 >=
> 3.51.1 (which it includes). It was built against 3.67 and fails to run
> with 3.66. Would it work correctly if built against nss3 3.66 (which would
> also satisfy the version requirement)?
> 
> If not, is nss3 in bullseye broken? Of yes, did 3.67 break its ABI? Or
> is it simply a matter of an incorrectly produce dependency which is not
> high enough?

Forgive me for butting in to the conversation, but I think I can provide
some useful information:  I believe the issue is that the size of
SSLChannelInfo increases between some NSS versions (NSS 3.54 added
pskType, NSS 3.60 added echAccepted, NSS 3.66 added isFIPS).
SSL_GetChannelInfo takes both a pointer to and size of SSLChannelInfo as
arguments.  If the size is greater than the size it expects, it returns
SECFailure.  This means SSL_GetChannelInfo fails when the caller was
compiled with a more recent version of libnss3 than the version it is
loaded with and the size of SSLChannelInfo changed between the versions.
SSL_GetChannelInfo succeeds when the caller was compiled with any lower
version than the version it is loaded with.  This causes issues when
thunderbird 1:78.11.0-1 (built with libnss3-dev 2:3.66-1) is run with
libnss3 2:3.61-1 currently in testing.

I don't think libnss3 2:3.61-1 is broken.  I think thunderbird needs to
be compiled against libnss3-dev <= 3.65 to run with 3.61, or it needs to
be run with libnss3 >= 3.66.

To avoid issues going forward, I would suggest that thunderbird needs a
tighter versioned dependency on libnss3.  It may make sense for
thunderbird to depend on libnss3 >= the version of libnss3-dev it was
compiled against.  (Which is a bit conservative, since the size of
SSLChannelInfo doesn't change in every version, but would require less
work than tracking version compatibility.)  Just an idea.  I'd defer to
Carsten's judgement on how best to handle it.

Cheers,
Kevin

[SSL_GetChannelInfo]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/nss/lib/ssl/sslinfo.c#l13

Bug#989839: Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

[Kevin Locke]

On Wed, 2021-06-16 at 11:55 -0600, Kevin Locke wrote:
> Setting a breakpoint on SSL_GetChannelInfo revealed that it is called by
> PreliminaryHandshakeDone with len = 128 by 78.10.0 and len = 136 by
> 78.11.0, which causes `len > sizeof inf` to fail and return SECFailure
> (because `sizeof inf` is 128).
> 
> It appears that SSLChannelInfo added pskType in NSS 3.54, echAccepted
> in NSS 3.60, and isFIPS in NSS 3.66.  Perhaps there is a version
> mismatch?

After a bit more testing, I realized thunderbird 1:78.10.2-1 was built
with libnss3-dev 2:3.63-1 and thunderbird 1:78.11.0-1 was built with
libnss3-dev 2:3.66-1.  I am only able to reproduce the issue with
libnss3 2:3.61-1, not libnss3 2:3.67-1 from unstable.

Cheers,
Kevin

https://buildd.debian.org/status/fetch.php?pkg=thunderbird=amd64=1%3A78.11.0-1=1622744401=0
https://buildd.debian.org/status/fetch.php?pkg=thunderbird=amd64=1%3A78.10.2-1=1621535757=0

Bug#989839: Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

[Kevin Locke]

Comparing the log.moz_log from running thunderbird with MOZ_LOG=nsHttp:3
and MOZ_LOG_FILE=log in the environment shows
Http2Session::ConfirmTLSProfile gets version=304 from
ssl->GetSSLVersionUsed() in 78.10.0 and version=
(nsISSLSocketControl::SSL_VERSION_UNKNOWN) in 78.11.0, which causes
Http2Session::ConfirmTLSProfile "FAILED due to lack of TLS1.2" and
INADEQUATE_SECURITY[1]:

I/nsHttp Http2Session::ConfirmTLSProfile 0x7f78dbdb7000 version=
I/nsHttp Http2Session::ConfirmTLSProfile 0x7f78dbdb7000 FAILED due to lack 
of TLS1.2
I/nsHttp Http2Session::SessionError 0x7f78dbdb7000 reason=0xc 
mPeerGoAwayReason=0x1f
I/nsHttp Http2Session::ReadSegments 0x7f78dbdb7000 returning 
INADEQUATE_SECURITY 804b0052

Setting a breakpoint on SSL_GetChannelInfo revealed that it is called by
PreliminaryHandshakeDone with len = 128 by 78.10.0 and len = 136 by
78.11.0, which causes `len > sizeof inf` to fail and return SECFailure
(because `sizeof inf` is 128).

It appears that SSLChannelInfo added pskType in NSS 3.54, echAccepted
in NSS 3.60, and isFIPS in NSS 3.66.  Perhaps there is a version
mismatch?

Best,
Kevin

[ConfirmTLSProfile]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/netwerk/protocol/http/Http2Session.cpp#l4194
[PreliminaryHandshakeDone]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/manager/ssl/nsNSSCallbacks.cpp#l700
[SSL_GetChannelInfo]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/nss/lib/ssl/sslinfo.c#l13
[SSLChannelInfo FF78]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/nss/lib/ssl/sslt.h#l293
[SSLChannelInfo tip]: 
https://hg.mozilla.org/mozilla-central/file/tip/security/nss/lib/ssl/sslt.h#l299

Bug#942799: Stretch: Wrong startup under gdb

[Kevin Locke]

On Wed, 2021-06-16 at 09:22 -0600, Kevin Locke wrote:
> I've attached a patch which changes the quoting to fix the issue with
> the hope that you may find it more acceptable than Christophe's patch.

Please ignore the previous patch.  It was sent with insufficient testing
and did not handle the quoting in ${TB_GDB_DEFAULT_OPTS} in the way it
appears to be intended.

I've attached v2 of the patch which quotes ${TB_ARGS[@]} using
`printf ' %q'` then uses eval to perform word splitting on the combined
command string.  In my testing it handled spaces and special characters
in ${TB_GDB_DEFAULT_OPTS} and arguments following -g in the way that I
would expect.  See what you think.

Cheers,
Kevin
>From 50bcc2bb310a25fe2a1e6e39528c385c4c98569d Mon Sep 17 00:00:00 2001
Message-Id: <50bcc2bb310a25fe2a1e6e39528c385c4c98569d.1623858686.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Wed, 16 Jun 2021 09:08:10 -0600
Subject: [PATCH v2] Fix quoting for -g in thunderbird-wrapper.sh

Running `thunderbird -g` produces the following error:

INFO  -> Starting Thunderbird with GDB ...
INFO  -> LANG= /usr/bin/gdb -ex "handle SIG38 nostop" -ex "handle SIGPIPE nostop" -ex "run" /usr/lib/thunderbird/thunderbird
/usr/bin/thunderbird: line 254: /usr/bin/gdb -ex "handle SIG38 nostop" -ex "handle SIGPIPE nostop" -ex "run" /usr/lib/thunderbird/thunderbird : No such file or directory

This occurs because exec is passed a single argument, which it
interprets as a file name that does not exist.  Instead, use the
following steps:

1. Build a command string which combines ${TB_GDB_DEFAULT_OPTS} and
   ${TB_ARGS[@]} (using `printf ' %q'`).
2. Print the command string with output_info.
3. Run it using `eval` (for word splitting) and `exec` (to replace the
   shell process with gdb, as before).

Signed-off-by: Kevin Locke 
---

Changes since v1:
 - Use eval to handle quoting in ${TB_GDB_DEFAULT_OPTS}, since word
   splitting does not consider quotes in variables.

 debian/thunderbird-wrapper.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/thunderbird-wrapper.sh b/debian/thunderbird-wrapper.sh
index 7546724f136..b76f522654e 100755
--- a/debian/thunderbird-wrapper.sh
+++ b/debian/thunderbird-wrapper.sh
@@ -250,8 +250,9 @@ else
 if [ -f /usr/bin/gdb ]; then
 if dpkg-query -W -f='${Version}' thunderbird-dbgsym &>/dev/null ; then
 output_info "Starting Thunderbird with GDB ..."
-output_info "LANG= /usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex \"run\" ${MOZ_LIBDIR}/${MOZ_APP_NAME} ${TB_ARGS[@]}"
-LANG='' exec "/usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex \"run\" ${MOZ_LIBDIR}/${MOZ_APP_NAME} ${TB_ARGS[@]}"
+TB_ARGS_LINE="/usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex run ${MOZ_LIBDIR}/${MOZ_APP_NAME}$(printf ' %q' "${TB_ARGS[@]}")"
+output_info "LANG= $TB_ARGS_LINE"
+LANG='' eval "exec $TB_ARGS_LINE"
 else
 output_info "No package 'thunderbird-dbgsym' installed! Please install first and restart."
 output_info "More information how to adjust your sources.list to being able installing"
-- 
2.30.2

Bug#942799: Stretch: Wrong startup under gdb

[Kevin Locke]

On Mon, 2019-10-21 at 19:53 +0200, Carsten Schoenert wrote:
> Am 21.10.19 um 19:40 schrieb Christophe DELAHAYE:
>> I tried to run Thunderbird under GDB to characterize a crash, but the
>> command line built by the start script is wrong.
> 
> could you give please an example what is going wrong.
> This part of the script was tested several times so before I will apply
> any patch I need to understand what is causing issues.

I am able to reproduce the issue with thunderbird 1:78.11.0-1 by running
`thunderbird -g` which prints:

INFO  -> Starting Thunderbird with GDB ...
INFO  -> LANG= /usr/bin/gdb -ex "handle SIG38 nostop" -ex "handle SIGPIPE 
nostop" -ex "run" /usr/lib/thunderbird/thunderbird 
/usr/bin/thunderbird: line 254: /usr/bin/gdb -ex "handle SIG38 nostop" -ex 
"handle SIGPIPE nostop" -ex "run" /usr/lib/thunderbird/thunderbird : No such 
file or directory

Then exits with code 127.  The issue occurs because exec is passed a
single argument on line 254, which bash interprets as a path that does
not exist.

I've attached a patch which changes the quoting to fix the issue with
the hope that you may find it more acceptable than Christophe's patch.

Thanks for considering,
Kevin
>From 119b82022ef8887aea70b0104922a38ce9e020cb Mon Sep 17 00:00:00 2001
Message-Id: <119b82022ef8887aea70b0104922a38ce9e020cb.1623856383.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Wed, 16 Jun 2021 09:08:10 -0600
Subject: [PATCH] Fix quoting for -g in thunderbird-wrapper.sh

Running `thunderbird -g` produces the following error:

INFO  -> Starting Thunderbird with GDB ...
INFO  -> LANG= /usr/bin/gdb -ex "handle SIG38 nostop" -ex "handle SIGPIPE nostop" -ex "run" /usr/lib/thunderbird/thunderbird
/usr/bin/thunderbird: line 254: /usr/bin/gdb -ex "handle SIG38 nostop" -ex "handle SIGPIPE nostop" -ex "run" /usr/lib/thunderbird/thunderbird : No such file or directory

This occurs because exec is passed a single argument, which it
interprets as a file name that does not exist.  Remove the surrounding
quotes so that each argument is passed separately.

Signed-off-by: Kevin Locke 
---
 debian/thunderbird-wrapper.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/thunderbird-wrapper.sh b/debian/thunderbird-wrapper.sh
index 7546724f136..2e088812b72 100755
--- a/debian/thunderbird-wrapper.sh
+++ b/debian/thunderbird-wrapper.sh
@@ -251,7 +251,7 @@ else
 if dpkg-query -W -f='${Version}' thunderbird-dbgsym &>/dev/null ; then
 output_info "Starting Thunderbird with GDB ..."
 output_info "LANG= /usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex \"run\" ${MOZ_LIBDIR}/${MOZ_APP_NAME} ${TB_ARGS[@]}"
-LANG='' exec "/usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex \"run\" ${MOZ_LIBDIR}/${MOZ_APP_NAME} ${TB_ARGS[@]}"
+LANG='' exec /usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex run "${MOZ_LIBDIR}/${MOZ_APP_NAME}" "${TB_ARGS[@]}"
 else
 output_info "No package 'thunderbird-dbgsym' installed! Please install first and restart."
 output_info "More information how to adjust your sources.list to being able installing"
-- 
2.30.2

Bug#989839: thunderbird: Gmail imap authentication error

[Kevin Locke]

On Mon, 2021-06-14 at 17:40 +0200, Benjamin Bänziger wrote:
> Package: thunderbird
> Version: 1:78.11.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> Since todays update, thunderbird doesn't connect with gmail imap server
> anymore;
> "Authenticcation failure while connecting to server imap.gmail.com"
> 
> Also creating a new account for gmail doesn't work:
> "Thunderbird failed to find the settings for your email account"

I encountered the same error after upgrading from 1:78.10.0-1 to
1:78.11.0-1 for every account using IMAP with TLS.  It also manifests as
"Failed to connect to server ${SERVER}" with network.trr.mode=3.  I
believe something is wrong with TLS in 1:78.11.0-1.  An easy way to
reproduce (optionally in a new profile with no accounts configured):

1. Click "Add-ons" from the menu.
2. Click the "Find More Addons" button at the bottom of the
   "Recommendations" tab.
3. Observe https://addons.thunderbird.net/en-US/thunderbird/ is opened
   in a new tab with Error code: NS_ERROR_NET_INADEQUATE_SECURITY.

These steps correctly show the Thunderbird Add-ons page with thunderbird
78.10.2-1 and below.  The "Authentication failure" messages also do not
occur for me after downgrading thunderbird to 78.10.2-1.

Thanks,
Kevin

Bug#987070: reportbug: Support GNU BTS at debbugs.gnu.org

[Kevin Locke]

Package: reportbug
Version: 7.10.3
Severity: wishlist

Dear Maintainers,

It would be great if reportbug could be used to query and report bugs to
the debbugs-based GNU BTS at https://debbugs.gnu.org, presumably via
`-B gnu` or similar.

Thanks for considering,
Kevin

P.S. I started working on a patch to add support until I realized that
python3-debianbts only supports bugs.debian.org (Bug #949867), which may
make adding support difficult.

Bug#984959: trace-cmd: bash-completion script installed to wrong location

[Kevin Locke]

Hi Sudip,

On Thu, 2021-04-08 at 10:01 +0100, Sudip Mukherjee wrote:
> On Wed, Mar 10, 2021 at 04:55:40PM -0700, Kevin Locke wrote:
>> trace-cmd installs a bash-completion script to
>> /usr/share/bash-completion/completions/trace-cmd/trace-cmd.bash
>> Unfortunately, it will not be used because bash-completion dynamically
>> loads completion scripts from
>> /usr/share/bash-completion/completions/$cmd, so completions for
>> trace-cmd must be installed as
>> /usr/share/bash-completion/completions/trace-cmd.
> 
> Thanks for the report. Not sure how I missed this in my initial test. :(
> But I think the rename is not required as bash-completion loads "$cmd"
> or "$cmd.bash" or "_$cmd". And, so based on my testing only installing
> /usr/share/bash-completion/completions/trace-cmd.bash does make it work.
> 
> Can you please confirm from your setup before I upload the new version +
> this fix..

Sure thing.  I can confirm that installing the completion script as
/usr/share/bash-completion/completions/trace-cmd.bash works on my
system.  You are right that "$cmd", "$cmd.bash" or "_$cmd" should work.
I think the leading underscore is generally used for fallback by
bash-completion, as in commit 4d8e1520, but I'm not aware of any
convention around use of the .bash extension.  Installing as
/usr/share/bash-completion/completions/trace-cmd.bash sounds good to me.

Thanks for working on it!
Kevin

[4d8e1520]: 
https://github.com/scop/bash-completion/commit/4d8e152039311e2bebf3d3ecb875e570b3171865

Bug#985151: dh_bash-completion: treats nitrokey-app file list as script

[Kevin Locke]

Hi Gabriel,

On Sun, 2021-03-28 at 12:12 -0300, Gabriel F. T. Gomes wrote:
> On Mon, 15 Mar 2021 07:07:36 -0600 Kevin Locke  wrote:
>> I've attached an updated version
>> which matches & and | in addition to ; as command separators.  We may
>> also want to consider modifying the compgen expression in the same way.
> 
> I added this patch (with a changelog entry) to the repository at:
> 
> https://salsa.debian.org/debian/bash-completion/-/commits/master

Looks great, thanks!

> Then I tested it against as much packages as possible:
> 
>   # Download packages that have some completion file (get the list from 
> apt-file)
>   apt-file search "/usr/share/bash-completion/completions" | cut -d ':' -f 1 
> | sort -u | tr '\n' ' ' | xargs apt-get source -y
>   
>   # Unpack all
>   for file in *.deb; do dpkg-deb --extract $file extract/; done
> 
>   # Run each package.bash-completion file against a simplified version
>   # of the perl script [1] (with and without this change)
>   for i in `find -name *.bash-completion`; do echo $i; perl 
> /var/tmp/build-root/test-me/root/perl-pre.pl < $i; done > _result.pre
>   for i in `find -name *.bash-completion`; do echo $i; perl 
> /var/tmp/build-root/test-me/root/perl-pos.pl < $i; done > _result.pos
> 
>   # Compare the results
>   diff -u1 _result.{pre,pos}
>./nitrokey-app-1.4.2/debian/nitrokey-app.bash-completion
>   -Yes
>   +No
> 
> 
> So, the change seems to affect nitrokey-app only, which is fine...
> 
> Nevertheless, I haven't released this to unstable, because of the
> freeze... I'm worried that this change could undesired side-effects
> (such as making other packages loose their completions) at this point
> of the release cycle, even though the test is telling me it won't.
> 
> Let me know your thoughts (about this and/or about the tests I ran).
> 
> 
> I'll submit it to experimental, then, once the freeze is lifted, to
> unstable.

That sounds like a good plan to me.  Even with the extra testing (which
I appreciate!) I don't think fixing a single, likely long-standing,
issue with nitrokey-app is worth the risk of inadvertently breaking
other packages during a freeze.

Thanks again,
Kevin

Bug#985542: golang-1.16-go: Please document how to use the go version from this package

[Kevin Locke]

Package: golang-1.16-go
Version: 1.16-1
Severity: normal

Dear Maintainer,

My apologies if this is a silly question, but how do you use the go
version provided by this package?  I checked the following:

- This package does not provide an executable named go1.16 or similar,
  as it is shown in the golang docs[1] and as done by similar packages
  (clang, gcc, perl, python, etc.).
- This package does not provide an alternative for /usr/bin/go using the
  Debian Alternatives System.  There are third-party tutorials that
  describe how to do so[2] but I assume this is unsupported.
- Setting GOROOT=/usr/lib/go-1.16 does not appear to work:
  
  $ GOROOT=/usr/lib/go-1.16 go version
  go version go1.15.9 linux/amd64

Are users expected to set PATH=/usr/lib/go-1.16/bin/:$PATH in addition
to GOROOT=/usr/lib/go-1.16 in order to use go 1.16?  Is this mentioned
in the docs?  I didn't see any mention of version management in:

- man go
- man go-version
- /usr/share/doc/golang*/{NEWS,README}*
- /usr/share/doc/golang*/html/*.html
- https://wiki.debian.org/golang
- https://go-team.pages.debian.net/

Any guidance and additions to the docs (if I haven't missed something
obvious) would be appreciated.

Thanks,
Kevin

[1]: https://golang.org/doc/manage-install#installing-multiple
[2]: https://iamemhn.link/rom/multiple-golang-debian-way/


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
'unstable'), (101, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.12.0-rc3 (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 golang-1.16-go depends on:
ii  golang-1.16-src  1.16-1
ii  libc62.31-9

Versions of packages golang-1.16-go recommends:
ii  g++   4:10.2.1-1
ii  gcc   4:10.2.1-1
ii  libc6-dev 2.31-9
ii  pkgconf [pkg-config]  1.7.4~git20210206+dcf529b-3

Versions of packages golang-1.16-go suggests:
ii  brz [bzr]3.1.0-8
ii  ca-certificates  20210119
ii  git  1:2.30.2-1
ii  mercurial5.6.1-2
ii  subversion   1.14.1-3

-- no debconf information

Bug#985151: dh_bash-completion: treats nitrokey-app file list as script

[Kevin Locke]

Hi Gabriel,

On Mon, 2021-03-15 at 09:52 -0300, Gabriel F. T. Gomes wrote:
> On Sat, 13 Mar 2021, Kevin Locke wrote:
>> I've attached a patch to fix the issue by requiring complete to follow a
>> line break or semicolon.  It obviously does not address the root of the
>> problem of reliably differentiating a list of paths from a Bash script.
>> (Which is not really possible, since a list of paths is a valid bash
>> script.)  But it may be a sufficient quick fix until/unless #785271 is
>> addressed.
> 
> I'm not sure we will ever be able to correctly detect everything...
> Anyhow, your patch looks not only sufficient, but correct on its own.
> I'll check if it works correctly with the scripts currently installed
> under my /usr/share/bash-completion.
> 
> Also, the detection algorithm has been kindly written by sergiodj (CC),
> so I'll give him some time to weigh in, then I'll apply your fix. 

Thanks for reviewing the patch!  While looking at it again this morning,
I noticed a potential issue: The patched version wouldn't match the last
line of

_have mycommand && _mycommand() {
  ...
} && complete ...

Which appears to be a common idiom for only defining the function and
completion if the command is in $PATH.  I've attached an updated version
which matches & and | in addition to ; as command separators.  We may
also want to consider modifying the compgen expression in the same way.

Thanks again,
Kevin
>From 1b21115318d9620ac7770f1051a536c8a8f3139f Mon Sep 17 00:00:00 2001
Message-Id: <1b21115318d9620ac7770f1051a536c8a8f3139f.1615813233.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Sat, 13 Mar 2021 10:18:37 -0700
Subject: [PATCH v2] dh_bash-completion: Tighten is_filelist matching

The regular expressions in is_filelist which matches "well-known idioms
on bash scripts" currently matches the path to the bash-completion
script in the nitrokey-app package:

'data/bash-autocomplete/nitrokey-app' =~ /\s*complete.*-[A-Za-z].*/

Avoid this by ensuring the is only matched when following a line break
or character which can be used to chain shell commands.

Signed-off-by: Kevin Locke 
---
 debian/extra/debhelper/dh_bash-completion | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Changes in v2:
* Match & and | in addition to ; as command separators.
  This is important for `... && complete`, which is a common idiom.

diff --git a/debian/extra/debhelper/dh_bash-completion b/debian/extra/debhelper/dh_bash-completion
index d1d9bf2e..7999151c 100755
--- a/debian/extra/debhelper/dh_bash-completion
+++ b/debian/extra/debhelper/dh_bash-completion
@@ -75,7 +75,7 @@ sub is_filelist {
 		#
 		# - If we see an "if...then" construction in the file.  We
 		#   take into account multi-line statements.
-		if (/\s*complete.*-[A-Za-z].*/
+		if (/(^|[|&;])\s*complete.*-[A-Za-z].*/
 			|| /\$\(.*\)/
 			|| /\s*compgen.*-[A-Za-z].*/
 			|| /\s*if.*;.*then/s) {
-- 
2.30.2

Bug#985157: gromacs-data: broken bash-completion scripts for gmx

[Kevin Locke]

Package: gromacs-data
Version: 2020.6-1
Severity: normal

Dear Maintainer,

Sourcing /usr/share/bash-completion/completions/gmx produces the
following errors:

bash: /usr/share/bash-completion/completions/gmx: line 1: syntax error near 
unexpected token `('
bash: /usr/share/bash-completion/completions/gmx: line 1: `complete -o 
nospace -F _gmx_compl gmxcomplete -o nospace -F _gmx_compl 
gmx_d_gmx_anaeig_compl() {'
bash: /usr/share/bash-completion/completions/gmx: line 1: syntax error near 
unexpected token `('
bash: /usr/share/bash-completion/completions/gmx: line 1: `complete -o 
nospace -F _gmx_compl gmxcomplete -o nospace -F _gmx_compl 
gmx_d_gmx_anaeig_compl() {

This occurs because /usr/share/bash-completion/completions/gmx starts
with:

complete -o nospace -F _gmx_compl gmxcomplete -o nospace -F _gmx_compl 
gmx_d_gmx_anaeig_compl() {

Which is not valid bash syntax.  This occurs because
/usr/bin/gmx-completion-gmx.bash produced by the gromacs installer does
not have a trailing newline, which causes it to be combined with the
first line of /usr/bin/gmx-completion.bash by

cat $(CURDIR)/debian/gromacs/usr/bin/gmx*.bash > \

$(CURDIR)/debian/gromacs-data/usr/share/bash-completion/completions/gmx

in debian/rules to produce the combined first line which causes the
syntax error.

Cheers,
Kevin

Bug#985151: dh_bash-completion: treats nitrokey-app file list as script

[Kevin Locke]

Package: bash-completion
Version: 1:2.11-2
Severity: normal
Tags: patch
X-Debbugs-Cc: j.naum...@fu-berlin.de

Dear Maintainer,

The regular expressions in is_filelist which matches "well-known idioms
on bash scripts" currently matches the path to the bash-completion
script in the nitrokey-app package[1]:

'data/bash-autocomplete/nitrokey-app' =~ /\s*complete.*-[A-Za-z].*/

This causes debian/nitrokey-app.bash-completion to be installed as
/usr/share/bash-completion/completions/nitrokey-app, which is not
useful.

I've attached a patch to fix the issue by requiring complete to follow a
line break or semicolon.  It obviously does not address the root of the
problem of reliably differentiating a list of paths from a Bash script.
(Which is not really possible, since a list of paths is a valid bash
script.)  But it may be a sufficient quick fix until/unless #785271 is
addressed.

Thanks for considering,
Kevin

[1]: 
https://salsa.debian.org/janluca-guest/nitrokey-app-debian/-/blob/master/debian/nitrokey-app.bash-completion


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
'unstable'), (101, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.11.0 (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

-- no debconf information
>From 77b328932fa429e2f3a6ac5e86707d88eb939856 Mon Sep 17 00:00:00 2001
Message-Id: 
<77b328932fa429e2f3a6ac5e86707d88eb939856.1615656992.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Sat, 13 Mar 2021 10:18:37 -0700
Subject: [PATCH] dh_bash-completion: Tighten is_filelist matching

The regular expressions in is_filelist which matches "well-known idioms
on bash scripts" currently matches the path to the bash-completion
script in the nitrokey-app package:

'data/bash-autocomplete/nitrokey-app' =~ /\s*complete.*-[A-Za-z].*/

Avoid this by ensuring the is only matched when following a line break
or semicolon.

Signed-off-by: Kevin Locke 
---
 debian/extra/debhelper/dh_bash-completion | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/extra/debhelper/dh_bash-completion 
b/debian/extra/debhelper/dh_bash-completion
index d1d9bf2e..d292ea87 100755
--- a/debian/extra/debhelper/dh_bash-completion
+++ b/debian/extra/debhelper/dh_bash-completion
@@ -75,7 +75,7 @@ sub is_filelist {
#
# - If we see an "if...then" construction in the file.  We
#   take into account multi-line statements.
-   if (/\s*complete.*-[A-Za-z].*/
+   if (/(^|;)\s*complete.*-[A-Za-z].*/
|| /\$\(.*\)/
|| /\s*compgen.*-[A-Za-z].*/
|| /\s*if.*;.*then/s) {
-- 
2.30.1

Bug#985140: gobgpd: bash-completion script attempts to source missing file

[Kevin Locke]

Package: gobgpd
Version: 2.18.0-1+b2
Severity: normal

Dear Maintainer,

gobgp installs a bash-completion script at
/usr/share/bash-completion/completions/gobgp which starts with:

. `dirname $BASH_SOURCE`/gobgp-static-completion.bash
. `dirname $BASH_SOURCE`/gobgp-dynamic-completion.bash

Since these files do not exist, it causes the script not to function.
Presumably these should be changed to:

. `dirname $BASH_SOURCE`/gobgp-static
. `dirname $BASH_SOURCE`/gobgp-dynamic

To match the files installed by in the gobgp package.

Thanks,
Kevin

Bug#985029: git-phab: non-functional bash-completion script

[Kevin Locke]

On Thu, 2021-03-11 at 23:46 +0100, Andrej Shadura wrote:
> On Thu, 11 Mar 2021, at 22:53, Kevin Locke wrote:
>> I've attached a patch with a functional bash-completion script based on
>> the output of register-python-argcomplete3.  See patch for specific
>> details.
> 
> Thanks a lot!

My pleasure.  Thank you for the lightning-fast fix and upload!

Cheers,
Kevin

Bug#985029: git-phab: non-functional bash-completion script

[Kevin Locke]

Package: git-phab
Version: 2.9.0~git20170531+6877964-1
Severity: normal
Tags: patch

Dear Maintainer,

The bash-completion script which git-phab installs has a syntax error
(missing } to end the function) and calls a function which is not
defined (_python_argcomplete_global).  The errors were hidden due to
bash-completion redirecting stdout/stderr when loading completion
scripts, which is being changed in an upcoming version.  See
https://github.com/scop/bash-completion/issues/506

I've attached a patch with a functional bash-completion script based on
the output of register-python-argcomplete3.  See patch for specific
details.

Thanks,
Kevin
>From 5d3f5f2a52dcae25509384bc4c1fe708f4b5fb90 Mon Sep 17 00:00:00 2001
Message-Id: 
<5d3f5f2a52dcae25509384bc4c1fe708f4b5fb90.1615499214.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Thu, 11 Mar 2021 13:55:19 -0700
Subject: [PATCH] fix bash-completion script

The previous bash-completion script was non-functional.  Replace it with
a functional bash-completion script generated using:

register-python-argcomplete3 git-phab | sed '
s/_python_argcomplete/_git_phab/
s/"$1"/git-phab/
s/COMP_LINE="$COMP_LINE"/COMP_LINE="${COMP_LINE\/git phab\/git-phab}"/'

The first replacement renames the completion function to _git_phab,
which is required by the bash-completion script for git to complete `git
phab`.

The second replacement invokes git-phab to perform the completion,
rather than the first function argument, since the git bash-completion
script does not pass any arguments to the completion function.

The third replaces 'git phab' with 'git-phab' in $COMP_LINE so that
argcomplete can recognize the script name when parsing $COMP_LINE.

Note: It would be possible to Build-Depend on python3-argcomplete and
generate this script during build.  (See diffoscope for an example.)
However, making the above changes would be fragile, since the output of
register-python-argcomplete3 may change arbitrarily, so this patch uses
the edited script.

Signed-off-by: Kevin Locke 
---
 debian/bash_completion.d/git-phab | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/debian/bash_completion.d/git-phab 
b/debian/bash_completion.d/git-phab
index 6603f72..e9a3ea5 100644
--- a/debian/bash_completion.d/git-phab
+++ b/debian/bash_completion.d/git-phab
@@ -1,7 +1,22 @@
-function _git_phab()
-{
-  COMP_WORDS=(git-phab ${COMP_WORDS[@]:2})
-  COMP_CWORD=$((COMP_CWORD - 1))
-  COMP_LINE=${COMP_LINE/git phab/git-phab}
-  _python_argcomplete_global git-phab
 
+_git_phab() {
+local IFS=$'\013'
+local SUPPRESS_SPACE=0
+if compopt +o nospace 2> /dev/null; then
+SUPPRESS_SPACE=1
+fi
+COMPREPLY=( $(IFS="$IFS" \
+  COMP_LINE="${COMP_LINE/git phab/git-phab}" \
+  COMP_POINT="$COMP_POINT" \
+  COMP_TYPE="$COMP_TYPE" \
+  _ARGCOMPLETE_COMP_WORDBREAKS="$COMP_WORDBREAKS" \
+  _ARGCOMPLETE=1 \
+  _ARGCOMPLETE_SUPPRESS_SPACE=$SUPPRESS_SPACE \
+  git-phab 8>&1 9>&2 1>/dev/null 2>/dev/null) )
+if [[ $? != 0 ]]; then
+unset COMPREPLY
+elif [[ $SUPPRESS_SPACE == 1 ]] && [[ "$COMPREPLY" =~ [=/:]$ ]]; then
+compopt -o nospace
+fi
+}
+complete -o nospace -o default -F _git_phab "git-phab"
-- 
2.30.1

Bug#984981: arcanist: non-functional bash-completion script

[Kevin Locke]

On Thu, 2021-03-11 at 07:31 -0700, Kevin Locke wrote:
> arcanist installs a bash-completion script at
> /usr/share/bash-completion/completions/arcanist.bash-completion
> which will not be loaded by bash-completion [...]

I just realized that arcanist previously installed a functional
completion script as /etc/bash_completion.d/arcanist.bash-completion.
(Which was loaded because all scripts in /etc/bash_completion.d are
eagerly loaded.)  It looks like that script was replaced with the
non-functional one in
https://github.com/phacility/arcanist/commit/acf060768340ba057e1acd5e8950dea41dc2b19e
Installing the previous version as 
/usr/share/bash-completion/completions/arcanist might work well.

Thanks for considering,
Kevin

Bug#984981: arcanist: non-functional bash-completion script

[Kevin Locke]

Package: arcanist
Version: 0~git20200925-1
Severity: normal

Dear Maintainer,

arcanist installs a bash-completion script at
/usr/share/bash-completion/completions/arcanist.bash-completion
which will not be loaded by bash-completion, which only tries:
/usr/share/bash-completion/completions/arcanist
/usr/share/bash-completion/completions/_arcanist
/usr/share/bash-completion/completions/arcanist.bash

Even if it were loaded, I suspect it would not function correctly
because `arc shell-complete --generate` will be unable to create
$GENERATED_RULES_FILE (/usr/share/bash-completion/rules/bash-rules.sh)
when run as a non-root user.  Running it as a user causes:

 GENERATE  Generating shell completion rules...
[2021-03-11 14:25:46] EXCEPTION: (FilesystemException) Requested path 
'/usr/share/arcanist/support/shell/rules' is not writable. at 
[/src/filesystem/Filesystem.php:1251]
arcanist()
  #0 Filesystem::assertWritable called at 
[/src/filesystem/Filesystem.php:73]
  #1 Filesystem::assertWritableFile called at 
[/src/filesystem/Filesystem.php:89]
  #2 Filesystem::writeFile called at 
[/src/toolset/workflow/ArcanistShellCompleteWorkflow.php:436]
  #3 ArcanistShellCompleteWorkflow::runGenerate called at 
[/src/toolset/workflow/ArcanistShellCompleteWorkflow.php:148]
  #4 ArcanistShellCompleteWorkflow::runWorkflow called at 
[/src/workflow/ArcanistWorkflow.php:227]
  #5 ArcanistWorkflow::executeWorkflow called at 
[/src/toolset/ArcanistPhutilWorkflow.php:21]
  #6 ArcanistPhutilWorkflow::execute called at 
[/src/parser/argument/PhutilArgumentParser.php:492]
  #7 PhutilArgumentParser::parseWorkflowsFull called at 
[/src/runtime/ArcanistRuntime.php:171]
  #8 ArcanistRuntime::executeCore called at 
[/src/runtime/ArcanistRuntime.php:37]
  #9 ArcanistRuntime::execute called at 
[/support/init/init-arcanist.php:6]
  #10 require_once(string) called at [/bin/arc:10]

If at all possible, I'd suggest running `arc shell-complete --generate`
during build and shipping
/usr/share/arcanist/support/shell/rules/bash-rules.sh in the package
with a symlink from /usr/share/bash-completion/completions/arcanist.

Thanks,
Kevin

Bug#984979: aptly: Installs invalid bash-completion script

[Kevin Locke]

Package: aptly
Version: 1.4.0+ds1-3
Severity: normal
Tags: patch

Dear Maintainer,

Because the file named in debian/aptly.bash-completion does not exist,
dh_bash-completion installs debian/aptly.bash-completion as
/usr/share/bash-completion/completions/aptly, which is not a valid shell
script.  Instead, debian/aptly.bash-completion should install
completion.d/aptly as /usr/share/bash-completion/completions/aptly.

Patch attached.

Thanks,
Kevin
>From 6ab5c95da42860bdf2f341d1eef5c7d550589b5c Mon Sep 17 00:00:00 2001
Message-Id: 
<6ab5c95da42860bdf2f341d1eef5c7d550589b5c.1615471580.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Thu, 11 Mar 2021 07:01:57 -0700
Subject: [PATCH] Fix bash-completion script installation

Because the file named in debian/aptly.bash-completion does not exist,
dh_bash-completion installs debian/aptly.bash-completion as
/usr/share/bash-completion/completions/aptly, which is invalid.  Fix it
to install completion.d/aptly instead.

Signed-off-by: Kevin Locke 
---
 debian/aptly.bash-completion | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/aptly.bash-completion b/debian/aptly.bash-completion
index 2e8627e4..af08cb0b 100644
--- a/debian/aptly.bash-completion
+++ b/debian/aptly.bash-completion
@@ -1 +1 @@
-bash_completion.d/aptly
+completion.d/aptly
-- 
2.30.1

Bug#984959: trace-cmd: bash-completion script installed to wrong location

[Kevin Locke]

Package: trace-cmd
Version: 2.9.1-1
Severity: normal
Tags: patch

Dear Maintainer,

trace-cmd installs a bash-completion script to
/usr/share/bash-completion/completions/trace-cmd/trace-cmd.bash
Unfortunately, it will not be used because bash-completion dynamically
loads completion scripts from
/usr/share/bash-completion/completions/$cmd, so completions for
trace-cmd must be installed as
/usr/share/bash-completion/completions/trace-cmd.

I've attached a patch to fix the issue.

Thanks for considering,
Kevin
>From ac5a9a6cef51186da0b498c87534baeec5020640 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Kevin Locke 
Date: Wed, 10 Mar 2021 16:53:26 -0700
Subject: [PATCH] install bash-completion script to correct location

bash-completion scripts for $cmd must be installed as
/usr/share/bash-completion/completions/$cmd to be dynamically loaded.
The script was installed as
/usr/share/bash-completion/completions/trace-cmd/trace-cmd.bash
because dh_install naively installs the named file to the named
directory.  Use dh-exec to rename the file during install, as suggested
in dh_install(1), so that it is installed as
/usr/share/bash-completion/completions/trace-cmd.

Signed-off-by: Kevin Locke 
---
 debian/control   | 2 +-
 debian/trace-cmd.install | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index df9661f..69e7614 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: devel
 Priority: optional
 Homepage: http://kernelshark.org/
 Maintainer: Sudip Mukherjee 
-Build-Depends: debhelper-compat (= 13), cmake, libjson-c-dev, freeglut3-dev, 
libxmu-dev, libegl-dev [mipsel], libxi-dev, qtbase5-dev, asciidoc, docbook-xsl, 
xsltproc, policykit-1, libcunit1-dev
+Build-Depends: debhelper-compat (= 13), dh-exec, cmake, libjson-c-dev, 
freeglut3-dev, libxmu-dev, libegl-dev [mipsel], libxi-dev, qtbase5-dev, 
asciidoc, docbook-xsl, xsltproc, policykit-1, libcunit1-dev
 Standards-Version: 4.5.0
 Rules-Requires-Root: no
 Vcs-Browser: https://github.com/sudipm-mukherjee/trace-cmd.git
diff --git a/debian/trace-cmd.install b/debian/trace-cmd.install
index df98a91..eff9aa4 100644
--- a/debian/trace-cmd.install
+++ b/debian/trace-cmd.install
@@ -1,3 +1,4 @@
+#!/usr/bin/dh-exec
 usr/bin/trace-cmd
 usr/lib/trace-cmd/plugins/*
-usr/etc/bash_completion.d/trace-cmd.bash 
/usr/share/bash-completion/completions/trace-cmd
+usr/etc/bash_completion.d/trace-cmd.bash => 
/usr/share/bash-completion/completions/trace-cmd
-- 
2.30.1

Bug#984957: libgadap-dev: bash-completion script installed to wrong location

[Kevin Locke]

Package: libgadap-dev
Version: 2.0-12
Severity: normal
Tags: patch

Dear Maintainer,

libgadap-dev installs a bash-completion script to
/usr/share/bash-completion/completions/bash_completion.d/gadap-config
Unfortunately, it will not be used because bash-completion dynamically
loads completion scripts from
/usr/share/bash-completion/completions/$cmd, so completions for
gadap-config must be installed as
/usr/share/bash-completion/completions/gadap-config.

I've attached a patch to fix the issue.

Thanks for considering,
Kevin
>From cf0bbab541a086081cf1c5422f1a5be75d9bdf21 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Kevin Locke 
Date: Wed, 10 Mar 2021 16:45:11 -0700
Subject: [PATCH] install bash-completion script to correct location

bash-completion scripts for $cmd must be installed as
/usr/share/bash-completion/completions/$cmd to be dynamically loaded.
The script was installed as
/usr/share/bash-completion/completions/bash_completion.d/gadap-config
due to installing the whole bash_completion.d directory.
Fix by adding a glob to install files in that directory into
/usr/share/bash-completion/completions/.

Signed-off-by: Kevin Locke 
---
 debian/libgadap-dev.install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/libgadap-dev.install b/debian/libgadap-dev.install
index edb076b..3830d54 100644
--- a/debian/libgadap-dev.install
+++ b/debian/libgadap-dev.install
@@ -1 +1 @@
-debian/bash_completion.d   /usr/share/bash-completion/completions
+debian/bash_completion.d/* /usr/share/bash-completion/completions
-- 
2.30.1

Bug#984955: crystal-lang: bash-completion file installed to wrong location

[Kevin Locke]

Package: crystal-lang
Version: 0.34.0+dfsg-1
Severity: normal
Tags: patch

Dear Maintainer,

The crystal-lang package currently installs a bash-completion script to
/usr/share/bash-completion/completions/crystal-lang/completion.bash
Unfortunately, it will not be used because bash-completion dynamically
loads completion scripts from
/usr/share/bash-completion/completions/$cmd, so completions for crystal
must be installed as /usr/share/bash-completion/completions/crystal.

I assume zsh has the same issue and
/usr/share/zsh/vendor-completions/_crystal-lang/completion.zsh must be
/usr/share/zsh/vendor-completions/_crystal.

The attached patch should fix both.

Thanks for considering,
Kevin
From 271285e4b9130f2ca17d8f702b3cc6ef2caff01f Mon Sep 17 00:00:00 2001
Message-Id: 
<271285e4b9130f2ca17d8f702b3cc6ef2caff01f.1615418709.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Wed, 10 Mar 2021 16:23:11 -0700
Subject: [PATCH] install shell completions to correct locations

bash-completion loads completion scripts dynamically from
/usr/share/bash-completion/completions/$cmd, so completions for the
crystal command must be installed as
/usr/share/bash-completion/completions/crystal, rather than
/usr/share/bash-completion/completions/crystal-lang/completion.bash
as they currently are.

I assume the same is true for ZSH.

Signed-off-by: Kevin Locke 
---
 debian/control  | 1 +
 debian/crystal-lang.install | 6 --
 2 files changed, 5 insertions(+), 2 deletions(-)
 mode change 100644 => 100755 debian/crystal-lang.install

diff --git a/debian/control b/debian/control
index 43e09b1..445f090 100644
--- a/debian/control
+++ b/debian/control
@@ -3,6 +3,7 @@ Section: devel
 Priority: optional
 Maintainer: David Suárez 
 Build-Depends: debhelper-compat (= 12),
+   dh-exec,
git,
libbsd-dev,
libedit-dev,
diff --git a/debian/crystal-lang.install b/debian/crystal-lang.install
old mode 100644
new mode 100755
index 7dcc686..a47dfa9
--- a/debian/crystal-lang.install
+++ b/debian/crystal-lang.install
@@ -1,7 +1,9 @@
+#!/usr/bin/dh-exec
+
 .build/crystal /usr/bin
 
 # TODO: multiarch for /usr/lib/crystal/lib/{ext/libcrystal.a, 
llvm/ext/llvm_ext.a}
 src/* /usr/lib/crystal/lib
 
-etc/completion.bash /usr/share/bash-completion/completions/crystal-lang
-etc/completion.zsh /usr/share/zsh/vendor-completions/_crystal-lang
+etc/completion.bash => /usr/share/bash-completion/completions/crystal
+etc/completion.zsh => /usr/share/zsh/vendor-completions/_crystal
-- 
2.30.1

Bug#803329: pulseaudio: Bash completion files provided by wrong package

[Kevin Locke]

tags 803329 +patch
thanks

On Mon, 2021-03-08 at 09:56 -0300, Felipe Sateler wrote:
> I would accept a patch moving the completion files to the pulseaudio-utils
> package.

Great!  Patch attached.

Cheers,
Kevin
>From a6e3fc1f1e0057c7f10df61c830619b54a456a92 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Kevin Locke 
Date: Mon, 8 Mar 2021 06:16:29 -0700
Subject: [PATCH] Move shell completion scripts to pulseaudio-utils

The shell completion scripts support commands from both the pulseaudio
package and pulseaudio-utils package, which may be installed without
pulseaudio (e.g. for use with PipeWire configured for PulseAudio
compatibility).  Ship the completions in pulseaudio-utils to cover this
case.  Note that the completion for the pulseaudio command will be
available if the pulseaudio package is installed, since it depends on
pulseaudio-utils.

Also move the Lintian override for script-not-executable and add one for
bash-completion-with-hashbang.  I'm in favor of fixing these, rather
than overriding them, but not sufficiently to pursue it right now.

Fixes: #803329

Signed-off-by: Kevin Locke 
---
 debian/pulseaudio-utils.install   | 2 ++
 debian/pulseaudio-utils.lintian-overrides | 2 ++
 debian/pulseaudio.install | 2 --
 debian/pulseaudio.lintian-overrides   | 1 -
 4 files changed, 4 insertions(+), 3 deletions(-)
 create mode 100644 debian/pulseaudio-utils.lintian-overrides

diff --git a/debian/pulseaudio-utils.install b/debian/pulseaudio-utils.install
index bda341aeb..6f31a3036 100644
--- a/debian/pulseaudio-utils.install
+++ b/debian/pulseaudio-utils.install
@@ -9,6 +9,7 @@ usr/bin/padsp
 usr/bin/pax11publish
 usr/bin/pasuspender
 usr/bin/pa-info
+usr/share/bash-completion/completions/*
 usr/share/man/man1/pacat.1
 usr/share/man/man1/pacmd.1
 usr/share/man/man1/pactl.1
@@ -19,3 +20,4 @@ usr/share/man/man1/parec.1
 usr/share/man/man1/parecord.1
 usr/share/man/man1/pasuspender.1
 usr/share/man/man1/pax11publish.1
+usr/share/zsh
diff --git a/debian/pulseaudio-utils.lintian-overrides b/debian/pulseaudio-utils.lintian-overrides
new file mode 100644
index 0..0b3e03c3f
--- /dev/null
+++ b/debian/pulseaudio-utils.lintian-overrides
@@ -0,0 +1,2 @@
+pulseaudio-utils: bash-completion-with-hashbang usr/share/bash-completion/completions/pulseaudio
+pulseaudio-utils: script-not-executable usr/share/bash-completion/completions/pulseaudio
diff --git a/debian/pulseaudio.install b/debian/pulseaudio.install
index 25046237b..c0e99572a 100755
--- a/debian/pulseaudio.install
+++ b/debian/pulseaudio.install
@@ -80,7 +80,6 @@ usr/lib/pulse-*/modules/module-x11*.so
 usr/lib/pulse-*/modules/module-allow-passthrough.so
 [linux-any] usr/lib/pulse-*/modules/module-systemd-login.so
 [linux-any] usr/lib/systemd/user/pulseaudio.*
-usr/share/bash-completion/completions/*
 usr/share/locale
 usr/share/man/man1/pulseaudio.1
 usr/share/man/man5/default.pa.5
@@ -91,4 +90,3 @@ usr/share/man/man1/start-pulseaudio-x11.1
 [linux-any] usr/share/pulseaudio/alsa-mixer
 [linux-any] usr/share/alsa
 usr/share/apport
-usr/share/zsh
diff --git a/debian/pulseaudio.lintian-overrides b/debian/pulseaudio.lintian-overrides
index 6d67fe20c..6a438ed94 100644
--- a/debian/pulseaudio.lintian-overrides
+++ b/debian/pulseaudio.lintian-overrides
@@ -1,4 +1,3 @@
 # These are not meant to be executed
 pulseaudio: script-not-executable etc/pulse/*.pa
-pulseaudio: script-not-executable usr/share/bash-completion/completions/pulseaudio
 pulseaudio: description-starts-with-package-name
-- 
2.30.1

Bug#803329: pulseaudio: Bash completion files provided by wrong package

[Kevin Locke]

On Fri, 2015-10-30 at 08:55 +0100, Francois Gouget wrote:
> On Wed, 28 Oct 2015, Felipe Sateler wrote:
>> What problem does this cause? Or what benefits does it cause to use
>> the correct package? I don't really want to complicate the packaging.
> 
> Anyway, here's another reason: it's possible to install pulseaudio-utils 
> without installing pulseaudio.

I just ran into this issue as you described.  I have pulseaudio-utils
installed, but not pulseaudio (because I am using PipeWire as a
PulseAudio substitute[1]).

I sympathize with your desire to avoid complicating the packaging.
Splitting the completion file looks non-trivial.  Might I suggest
shipping a copy of the completion file in the pulseaudio package as
/usr/share/bash-completion/completions/pulseaudio and a copy in the
pulseaudio-utils package as /usr/share/bash-completion/completions/pacmd
with symlinks for the other commands provided by that package?  This way
a completion for each command is shipped in the same package.  The 15kB
of duplicated data seems reasonable, if not ideal, to avoid divergence
from upstream, or the packaging work of creating a -common package just
for completions.

Thanks for considering,
Kevin

[1]: 
https://wiki.debian.org/PipeWire#Using_as_a_substitute_for_PulseAudio.2FJACK.2FALSA

Bug#984429: pipewire: could not set nice-level without rtkit

[Kevin Locke]

Package: pipewire
Version: 0.3.19-4
Severity: normal

Dear Maintainer,

With pipewire 0.3.19-4, if the rtkit package is not installed,
`systemctl --user status pipewire.service` includes:

pipewire[1455]: could not set nice-level to -11: No such file or directory
pipewire[1455]: could not make thread realtime: No such file or directory
pipewire-media-session[1473]: could not set nice-level to -11: No such file or 
directory
pipewire-media-session[1473]: could not make thread realtime: No such file or 
directory

After installing rtkit these messages disappear.  Presumably this also
avoids potential issues (glitches, etc.) under load, although I did not
observe any.

Perhaps it would make sense to add rtkit to Recommends for pipewire, as
done by pulseaudio?

Thanks for considering,
Kevin


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'stable-debug'), (500, 'unstable'), (101, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.11.0 (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 pipewire depends on:
ii  init-system-helpers  1.60
ii  libpipewire-0.3-modules  0.3.19-4
ii  pipewire-bin 0.3.19-4

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#954850: php-fpm.conf: Shouldn't pass URLs for missing files to PHP-FPM

[Kevin Locke]

On Sat, 2021-02-20 at 10:49 +0100, Ondřej Surý wrote:
> Hi Kevin,
> 
> I tried to add this patch to the PHP-FPM package, but it breaks existing
> installations[1] and I had to revert the change.
> 
> Since this won't ever get merged, so I am just closing the issue.
> 
> 1. https://github.com/oerdnj/deb.sury.org/issues/1545

Hi Ondrej,

Thanks for the update.  My apologies for the regression.  Running Apache
and PHP-FPM as different users with different hosted file visibility is
an interesting case that I hadn't considered.  Not including the patch
by default and closing the issue makes sense to me.

Thanks again,
Kevin

Bug#977923: closed by Debian FTP Masters

[Kevin Locke]

On Wed, 2020-12-23 at 01:06 +, Debian Bug Tracking System wrote:
> Source: lxc
> Source-Version: 1:4.0.5-1
> Done: Antonio Terceiro 

Crazy-fast update and fix.  Many thanks!

Cheers,
Kevin

Bug#977923: lxc: start fails on Linux 5.10: Failed to copy "/proc/self/mountinfo"

[Kevin Locke]

On Tue, 2020-12-22 at 20:42 -0300, Antonio Terceiro wrote:
> Control: tag -1 + confirmed fixed-upstream
> Control: forwarded -1 https://github.com/lxc/lxc/issues/3580

Good find!  Not sure how I missed it.  Rebuilding with
https://github.com/lxc/lxc/commit/a39fc34bd6842ad1adc6144391071d8b1078667e.patch
added to debian/patches works for me.

Thanks!
Kevin

Bug#977927: DistributionNotFound: 'hyperframe>=6.0' due to missing dependencies

[Kevin Locke]

Package: mitmproxy
Version: 5.3.0-1
Severity: important

Dear Maintainer,

In a fresh container with Debian testing, running mitmproxy with any
arguments produces the following output:

Traceback (most recent call last):
  File "/usr/bin/mitmproxy", line 33, in 
sys.exit(load_entry_point('mitmproxy==5.3.0', 'console_scripts', 
'mitmproxy')())
  File "/usr/bin/mitmproxy", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 790, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/mitmproxy/tools/main.py", line 22, in 

from ._main import *  # noqa
  File "/usr/lib/python3/dist-packages/mitmproxy/tools/_main.py", line 14, in 

from mitmproxy import exceptions, master
  File "/usr/lib/python3/dist-packages/mitmproxy/master.py", line 7, in 
from mitmproxy import addonmanager
  File "/usr/lib/python3/dist-packages/mitmproxy/addonmanager.py", line 8, in 

from mitmproxy import eventsequence
  File "/usr/lib/python3/dist-packages/mitmproxy/eventsequence.py", line 4, in 

from mitmproxy import flow
  File "/usr/lib/python3/dist-packages/mitmproxy/flow.py", line 5, in 
from mitmproxy import connections
  File "/usr/lib/python3/dist-packages/mitmproxy/connections.py", line 9, in 

from mitmproxy.net import tcp
  File "/usr/lib/python3/dist-packages/mitmproxy/net/tcp.py", line 12, in 

from mitmproxy.net import tls
  File "/usr/lib/python3/dist-packages/mitmproxy/net/tls.py", line 17, in 

from mitmproxy.contrib.kaitaistruct import tls_client_hello
  File 
"/usr/lib/python3/dist-packages/mitmproxy/contrib/kaitaistruct/tls_client_hello.py",
 line 7, in 
from pkg_resources import parse_version
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3239, 
in 
def _initialize_master_working_set():
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3222, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3251, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 567, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 884, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 770, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'hyperframe>=6.0' distribution was not 
found and is required by mitmproxy

The mitmproxy package appears to be missing the following dependencies:
python3-hyperframe (>= 6.0)
python3-h2 (>= 4.0)

After installing these packages, mitmproxy appears to work correctly.

Thanks,
Kevin

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'unstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-4-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 mitmproxy depends on:
ii  dpkg  1.20.5
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-4
ii  python3   3.9.0-4
ii  python3-asgiref   3.3.1-1
ii  python3-blinker   1.4+dfsg1-0.3
ii  python3-brotli1.0.9-2+b2
ii  python3-certifi   2020.6.20-1
ii  python3-click 7.1.2-1
ii  python3-cryptography  3.2.1-1
ii  python3-flask 1.1.2-2
ii  python3-h11   0.11.0-1
ii  python3-kaitaistruct  0.8-3
ii  python3-ldap3 2.8.1-1
ii  python3-msgpack   1.0.0-6+b1
ii  python3-openssl   19.1.0-2
ii  python3-passlib   1.7.2-2
ii  python3-pkg-resources 50.3.0-1
ii  python3-protobuf  3.12.3-2+b2
ii  python3-publicsuffix2 2.20191221-2
ii  python3-pyasn10.4.8-1
ii  python3-pyparsing 2.4.7-1
ii  python3-pyperclip 1.8.0-1
ii  python3-ruamel.yaml   0.16.12-2
ii  python3-sortedcontainers  2.1.0-2
ii  python3-tornado   6.1.0-1+b1
ii  python3-urwid 2.1.2-1
ii  python3-wsproto   0.15.0-3

mitmproxy recommends no packages.

mitmproxy suggests no packages.

Bug#977923: lxc: start fails on Linux 5.10: Failed to copy "/proc/self/mountinfo"

[Kevin Locke]

On Tue, 2020-12-22 at 16:04 -0700, Kevin Locke wrote:
> Package: lxc
> Version: 1:4.0.4-6

For reference, I'm also able to reproduce the issue with 4.0.5, built
from source.

Cheers,
Kevin

Bug#977923: lxc: start fails on Linux 5.10: Failed to copy "/proc/self/mountinfo"

[Kevin Locke]

Package: lxc
Version: 1:4.0.4-6
Severity: normal

Dear Maintainer,

A freshly created container with Debian testing runs fine on Linux 5.9
(from linux-image-5.9.0-4-amd64 5.9.11-1), but fails to start on Linux
5.10 (from linux-image-5.10.0-trunk-amd64 5.10.1-1~exp1).  To reproduce:

lxc-create -n testing-amd64 -t debian -- --release testing
lxc-start -n testing-amd64 --logfile debug.log --logpriority TRACE

Works fine on 5.9, prints the following on 5.10:

lxc-start: testing-amd64: lxccontainer.c: wait_on_daemonized_start: 849 
Received container state "ABORTING" instead of "RUNNING"
lxc-start: testing-amd64: tools/lxc_start.c: main: 308 The container failed to 
start
lxc-start: testing-amd64: tools/lxc_start.c: main: 311 To get more details, run 
the container in foreground mode
lxc-start: testing-amd64: tools/lxc_start.c: main: 313 Additional information 
can be obtained by setting the --logfile and --logpriority options

The first error in debug.log is:

lxc-start testing-amd64 2020125630.248 ERRORconf - 
conf.c:turn_into_dependent_mounts:2965 - Invalid argument - Failed to copy 
"/proc/self/mountinfo"

debug.log attached.

Let me know if there's anything else I can do to help, or if I should
report the issue upstream.

Thanks,
Kevin

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'unstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-trunk-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 lxc depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.31-5
ii  libcap21:2.44-1
ii  libgcc-s1  10.2.1-1
ii  liblxc11:4.0.4-6
ii  libseccomp22.5.0-3+b1
ii  libselinux13.1-2+b2
ii  lsb-base   11.1.0

Versions of packages lxc recommends:
ii  apparmor 2.13.5-1+b2
ii  bridge-utils 1.6-3
ii  debootstrap  1.0.123
ii  dirmngr  2.2.20-1
ii  dnsmasq-base [dnsmasq-base]  2.82-1
ii  gnupg2.2.20-1
ii  iproute2 5.9.0-1
ii  iptables 1.8.6-1
ii  libpam-cgfs  1:4.0.4-6
ii  lxc-templates3.0.4-4
ii  lxcfs4.0.5-1
ii  nftables 0.9.7-1
ii  openssl  1.1.1h-1
ii  rsync3.2.3-2
ii  uidmap   1:4.8.1-1

Versions of packages lxc suggests:
ii  btrfs-progs  5.9-1+b1
pn  lvm2 
ii  python3-lxc  1:3.0.4-1+b4

-- Configuration Files:
/etc/lxc/default.conf [Errno 13] Permission denied: '/etc/lxc/default.conf'

-- debconf information:
* lxc/auto_update_config: true
  lxc/auto: true
  lxc/title:
  lxc/shutdown: /usr/bin/lxc-halt
* lxc/directory: /var/lib/lxc
lxc-start testing-amd64 2020125629.681 TRACEcommands - 
commands.c:lxc_cmd:289 - Connection refused - Command "get_init_pid" failed to 
connect command socket
lxc-start testing-amd64 2020125629.681 TRACEcommands - 
commands.c:lxc_cmd:289 - Connection refused - Command "get_state" failed to 
connect command socket
lxc-start testing-amd64 2020125629.681 TRACEstart - 
start.c:lxc_init_handler:692 - Created anonymous pair {4,5} of unix sockets
lxc-start testing-amd64 2020125629.681 TRACEcommands - 
commands.c:lxc_cmd_init:1670 - Created abstract unix socket 
"/var/lib/lxc/testing-amd64/command"
lxc-start testing-amd64 2020125629.681 TRACEstart - 
start.c:lxc_init_handler:708 - Unix domain socket 6 for command server is ready
lxc-start testing-amd64 2020125629.682 INFO lxccontainer - 
lxccontainer.c:do_lxcapi_start:969 - Set process title to [lxc monitor] 
/var/lib/lxc testing-amd64
lxc-start testing-amd64 2020125629.682 DEBUGlxccontainer - 
lxccontainer.c:wait_on_daemonized_start:830 - First child 2735 exited
lxc-start testing-amd64 2020125629.682 TRACEstart - 
start.c:lxc_start:2113 - Doing lxc_start
lxc-start testing-amd64 2020125629.682 INFO lsm - lsm/lsm.c:lsm_init:30 
- LSM security driver AppArmor
lxc-start testing-amd64 2020125629.682 TRACEstart - 
start.c:lxc_init:732 - Initialized LSM
lxc-start testing-amd64 2020125629.682 TRACEstart - 
start.c:lxc_serve_state_clients:438 - Set container state to STARTING
lxc-start testing-amd64 2020125629.682 TRACEstart - 
start.c:lxc_serve_state_clients:441 - No state clients registered
lxc-start testing-amd64 2020125629.682 TRACEstart - 
start.c:lxc_init:738 - Set container state to "STARTING"
lxc-start testing-amd64 2020125629.682 TRACEstart - 
start.c:lxc_init:794 - Set 

Bug#977792: nodejs: install bash-completion script

[Kevin Locke]

Package: nodejs
Version: 12.19.0~dfsg-1
Severity: wishlist

Dear Maintainer,

Node.js supports generating a programmable tab-completion script for
Bash by running `node --completion-bash`.[1]  It would be nice if the
nodejs package installed the script so that it would be used by Bash
whenever the bash-completion package is installed.  This could be done
by:

1. Generating debian/nodejs.bash-completion containing either:
  a. The output of `node --completion-bash` run during build.
  b. `eval "$(nodejs --completion-bash)"` to run node when loaded.
2. Installing debian/nodejs.bash-completion to 
   /usr/share/bash-completion/completions/node and 
   /usr/share/bash-completion/completions/nodejs, preferably using
   dh_bash-completion from the bash-completion package (which already in
   Build-Depends, although not currently used).

Thanks for considering,
Kevin

[1]: https://github.com/nodejs/node/pull/20713


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'unstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0 (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 nodejs depends on:
ii  libc6  2.31-5
ii  libnode72  12.19.0~dfsg-1

Versions of packages nodejs recommends:
ii  ca-certificates  20200601
ii  nodejs-doc   12.19.0~dfsg-1

Versions of packages nodejs suggests:
pn  npm  

-- no debconf information

Bug#975980: /usr/share/man/man1/firejail.1.gz: Incorrect path to syscalls.txt in firejail(1)

[Kevin Locke]

Package: firejail
Version: 0.9.64-1
Severity: minor
File: /usr/share/man/man1/firejail.1.gz

Dear Maintainer,

The --seccomp section of the firejail(1) manual page includes:

More information about groups can be found in
/usr/share/doc/firejail/syscalls.txt

Which does not exist in version 0.9.64-1.  Perhaps it is referring to
/usr/share/doc/firejail/templates/syscalls.txt.gz?

Presumably the location in the man page is correct (although missing the
.gz extension) since it is not a profile template like the other files
in templates directory.

Minor detail in either case.

Thanks,
Kevin

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'unstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail depends on:
ii  libapparmor1  2.13.5-1+b1
ii  libc6 2.31-4
ii  libselinux1   3.1-2+b1

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64-1
ii  iproute2   5.9.0-1
ii  iptables   1.8.6-1
ii  xauth  1:1.0.10-1
ii  xdg-dbus-proxy 0.1.2-1
ii  xserver-xephyr 2:1.20.8-2
ii  xvfb   2:1.20.8-2

firejail suggests no packages.

-- no debconf information

Bug#972713: libnss3: Handshake failed (-12251) with Pidgin since 2:3.58-1

[Kevin Locke]

forwarded 972713 https://bugzilla.mozilla.org/1672703
thanks

On Thu, 2020-10-22 at 16:41 -0600, Kevin Locke wrote:
> Downgrading to 2:3.56-1 resolves the issue.  I have opened
> https://bugzilla.mozilla.org/1672855 to investigate the issue with NSS
> upstream.

Somehow I had missed that https://bugzilla.mozilla.org/1672703 was
already open to track this issue.  A fix is in development on that
issue.

Cheers,
Kevin

Bug#972713: libnss3: Handshake failed (-12251) with Pidgin since 2:3.58-1

[Kevin Locke]

Package: libnss3
Version: 2:3.58-1
Severity: important
Tags: upstream
Forwarded: https://bugzilla.mozilla.org/1672855
X-Debbugs-Cc: ste.calleg...@tiscali.it

Dear Maintainer,

After installing libnss3 2:3.58-1, pidgin is unable to connect to (any?)
services using TLS.  The issue occurs on all services I tested,
including: IRC (chat.freenode.net), XMPP (talk.google.com), Discord
(gateway.discord), and AIM (slogin.oscar.aol.com). Relevant output from
pidgin --debug:

nss: Handshake failed  (-12251)
connection: Connection error on 0x55f37b4e6880 (reason: 5 description: SSL 
Handshake Failed)
account: Disconnecting account m...@example.com (0x55f37a78c4b0)
connection: Disconnecting connection 0x55f37b4e6880
connection: Destroying connection 0x55f37b4e6880

Downgrading to 2:3.56-1 resolves the issue.  I have opened
https://bugzilla.mozilla.org/1672855 to investigate the issue with NSS
upstream.

Cheers,
Kevin

Note: Although the "Handshake failed" is similar to
https://bugs.debian.org/790610, I think this is a different issue caused
by a specific commit rather than the weak FFDHE group causing the issue
in that bug.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'unstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0 (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 libnss3 depends on:
ii  libc6 2.31-4
ii  libnspr4  2:4.28-1
ii  libsqlite3-0  3.33.0-1

libnss3 recommends no packages.

libnss3 suggests no packages.

-- no debconf information

Bug#972577: spampd: support systemd service reloading via SIGHUP

[Kevin Locke]

Package: spampd
Version: 2.53-1
Severity: wishlist
Tags: patch

Dear Maintainer,

Attempting to `systemctl reload spampd.service` results in the error:

Failed to reload spampd.service: Job type reload is not applicable for unit 
spampd.service.

For a service to be reloaded, it must define ExecReload=, which
spampd.service does not currently do.  Since SpamPD supports reloading
via SIGHUP (see [mpaperno/spampd#20]), adding:

ExecReload=kill -HUP $MAINPID

(matching the example from systemd.service(5)) to the [Service] section
of spampd.service should be sufficient.  I've attached a patch for
reference.

Thanks for considering,
Kevin
>From 897e2d06b47c8d6975ecd75161defc086527412a Mon Sep 17 00:00:00 2001
Message-Id: 
<897e2d06b47c8d6975ecd75161defc086527412a.1603208436.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Tue, 20 Oct 2020 09:31:42 -0600
Subject: [PATCH] spampd.service: Support reload via ExecReload=

Attempting to `systemctl reload spampd.service` results in the error:

Failed to reload spampd.service: Job type reload is not applicable for unit 
spampd.service.

For a service to be reloaded, it must define ExecReload=.  Since SpamPD
supports reloading via SIGHUP (see [mpaperno/spampd#20]), define it to
do so.  Note: This matches the example in systemd.service(5) verbatim.

[mpaperno/spampd#20]: https://github.com/mpaperno/spampd/pull/20

Signed-off-by: Kevin Locke 
---
 debian/spampd.service | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/spampd.service b/debian/spampd.service
index 31293ff..0822a33 100644
--- a/debian/spampd.service
+++ b/debian/spampd.service
@@ -6,6 +6,7 @@ After=network.target local-fs.service
 EnvironmentFile=-/var/run/spampd/spampd.arguments
 ExecStartPre=/usr/share/spampd/process_arguments.sh
 ExecStart=/usr/sbin/spampd --setsid $SPAMPD_ARGS
+ExecReload=kill -HUP $MAINPID
 Restart=on-failure
 PIDFile=/var/run/spampd/spampd.pid
 
-- 
2.28.0

Bug#962654: pip fails to install cryptography on pypy3

[Kevin Locke]

On Thu, 2020-06-11 at 12:55 +0200, chrysn wrote:
> Package: python3-pip
> Version: 20.1.1-2
> Severity: normal
> 
> In pypy3 venvs, installing the cryptography package fails. As replacing
> pip with the upstream pip makes things work, and because the whole
> situation looks similar to #955414 / #954256 (where I found the
> workaround), there is reason to assume this is relating to Debian
> customizations in pip.

I just ran into this issue as well and agree with the similarities to
the bugs you mentioned.  On my system it appears to be unrelated to the
cryptography package and can be reproduced using the same steps as in
#954256:

pypy3 -m venv /tmp/venv/
source /tmp/venv/bin/activate
mkdir /tmp/pypa
cd /tmp/pypa
echo "from setuptools import setup; setup()" > setup.py
touch pyproject.toml
pip install --isolated -e .

Which fails with:

Obtaining file:///tmp/pypa
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'error'
  ERROR: Command errored out with exit status 1:
   command: /tmp/venv/bin/pypy3-c 
/usr/share/python-wheels/pep517-0.8.2-py2.py3-none-any.whl/pep517/_in_process.py
 get_requires_for_build_wheel /tmp/tmpu8qlrd77
   cwd: /tmp/pypa
  Complete output (1 lines):
  /tmp/venv/bin/pypy3-c: can't find '__main__' module in 
'/usr/share/python-wheels/pep517-0.8.2-py2.py3-none-any.whl/pep517/_in_process.py'
  
ERROR: Command errored out with exit status 1: /tmp/venv/bin/pypy3-c 
/usr/share/python-wheels/pep517-0.8.2-py2.py3-none-any.whl/pep517/_in_process.py
 get_requires_for_build_wheel /tmp/tmpu8qlrd77 Check the logs for full command 
output.

As you noted, and as in #954256, running `pip install --force pip` in
the venv avoids the error.

Thanks,
Kevin

Bug#972233: zipgrep: Avoid test errors when no members present

[Kevin Locke]

Package: unzip
Version: 6.0-25
Severity: normal
Tags: patch

Dear Maintainer,

If zipgrep is given one or more member names, none of which are present
in the archive, it produces errors such as the following:

caution: filename not matched:  membername
/usr/bin/zipgrep: 97: test: -eq: unexpected operator
/usr/bin/zipgrep: 100: test: Illegal number:

Which can be reproduced by running:

zip motd.zip /etc/motd
zipgrep pattern motd.zip membername

This occurs because the sts variable is only set inside the loop over
member names present in the archive.  This can be avoided by
initializing sts to 0 before the loop, as done by the attached patch.

Thanks for considering,
Kevin

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'unstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0 (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 unzip depends on:
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-3

unzip recommends no packages.

Versions of packages unzip suggests:
ii  zip  3.0-11+b1

-- no debconf information
>From 0fc0fef8153e70f5cf956922512d8e2acbc626ea Mon Sep 17 00:00:00 2001
Message-Id: 
<0fc0fef8153e70f5cf956922512d8e2acbc626ea.1602716158.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Wed, 14 Oct 2020 16:46:23 -0600
Subject: [PATCH] zipgrep: Avoid test errors when no members present

If zipgrep is given one or more member names, none of which are present
in the archive, it produces errors such as the following:

caution: filename not matched:  membername
/usr/bin/zipgrep: 97: test: -eq: unexpected operator
/usr/bin/zipgrep: 100: test: Illegal number:

Which can be reproduced by running:

zip motd.zip /etc/motd
zipgrep pattern motd.zip membername

This occurs because the sts variable is only set inside the loop over
member names present in the archive.  Avoid it by initializing sts to 0.

Signed-off-by: Kevin Locke 
---
 unix/zipgrep | 1 +
 1 file changed, 1 insertion(+)

diff --git a/unix/zipgrep b/unix/zipgrep
index 69cd6ba..b9d2316 100755
--- a/unix/zipgrep
+++ b/unix/zipgrep
@@ -44,6 +44,7 @@ if test -n "$opt"; then
   opt="-$opt"
 fi
 
+sts=0
 status_grep_global=1
 IFS='
 '
-- 
2.28.0

Bug#970393: RFP: shfmt -- Shell script formatter

[Kevin Locke]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org

* Package name: shfmt
  Version : 3.1.2
  Upstream Author : Daniel Martí 
* URL : https://github.com/mvdan/sh
* License : BSD-3
  Programming Lang: Go
  Description : Shell script formatter

shfmt is a code formatter for POSIX shell scripts, including support for
Bash and mksh extensions.

shfmt would be a good candidate for packaging due to its popularity (>3k
stars on GitHub) and being actively maintained for more than 4 years.
Debian currently includes code formatters for many languages (e.g.
astyle, bcpp, clang-tidy, indent, uncrustify), but none for shell
scripts.  shfmt is the only such code formatter I am aware of (other
than an unmaintained awk script[1]).

Thanks for considering,
Kevin

[1]: http://www.bolthole.com/AWK.html

Bug#969986: [Pkg-javascript-devel] Bug#969986: Bug#969986: npm: Error: Cannot find module 'semver'

[Kevin Locke]

reassign 969986 nodejs
merge 969986 932659
thanks

On Wed, 2020-09-09 at 21:11 +0200, Jonas Smedegaard wrote:
> Quoting Kevin Locke (2020-09-09 20:32:01)
>> Did you try installing to a chroot:
>> 
>> debootstrap testing npm-chroot && chroot npm-chroot sh -c 'apt install -y 
>> npm && npm --version'
> 
> I tried above command just now (inside another chroot), and it failed:
>
> [...]
> Error: Cannot find module 'semver'
> [...]
> 
> Installing npm into a clean pbuilder chroot (either sid or bullseye) and 
> running "npm --version" does not fail, however.

Good catch.  I am seeing the same behavior.  It looks to me like a
difference in the node module search path, not specific to npm.

If I run `node -e 'console.log(require.resolve.paths("semver"))'` in the
chroot, I get (note the missing /usr prefix):

[
  '/node_modules',
  '/root/.node_modules',
  '/root/.node_libraries',
  '/lib/x86_64-linux-gnu/nodejs',
  '/share/nodejs',
  '/lib/nodejs'
]

In pbuilder I get:

[
  '/node_modules',
  '/root/.node_modules',
  '/root/.node_libraries',
  '/usr/lib/x86_64-linux-gnu/nodejs',
  '/usr/share/nodejs',
  '/usr/lib/nodejs'
]

I think the problem is that process.execPath is "node" in the chroot and
"/usr/bin/node" in pbuilder and that this is used to build the module
search path.  The problem occurs when /proc is not mounted.

It appears this was already reported in #932659.  Sorry for not noticing
that earlier.

Thanks,
Kevin


signature.asc
Description: PGP signature

Bug#969986: [Pkg-javascript-devel] Bug#969986: npm: Error: Cannot find module 'semver'

[Kevin Locke]

On Wed, 2020-09-09 at 20:20 +0200, Xavier wrote:
> Control: tags -1 + moreinfo
> 
> Le 09/09/2020 à 19:54, Kevin Locke a écrit :
>> Package: npm
>> Version: 6.14.8+ds-1
>> Severity: important
>> 
>> Dear Maintainer,
>> 
>> When I run `npm --version` (or any subcommand), it prints:
>> 
>> internal/modules/cjs/loader.js:968
>>   throw err;
>>   ^
>> 
>> Error: Cannot find module 'semver'
>> Require stack:
>> - /usr/share/npm/lib/utils/unsupported.js
>> - /usr/share/npm/bin/npm-cli.js
>> at Function.Module._resolveFilename 
>> (internal/modules/cjs/loader.js:965:15)
>> at Function.Module._load (internal/modules/cjs/loader.js:841:27)
>> at Module.require (internal/modules/cjs/loader.js:1025:19)
>> at require (internal/modules/cjs/helpers.js:72:18)
>> at Object. (/usr/share/npm/lib/utils/unsupported.js:2:14)
>> at Module._compile (internal/modules/cjs/loader.js:1137:30)
>> at Object.Module._extensions..js (internal/modules/cjs/loader.js:1157:10)
>> at Module.load (internal/modules/cjs/loader.js:985:32)
>> at Function.Module._load (internal/modules/cjs/loader.js:878:14)
>> at Module.require (internal/modules/cjs/loader.js:1025:19) {
>>   code: 'MODULE_NOT_FOUND',
>>   requireStack: [
>> '/usr/share/npm/lib/utils/unsupported.js',
>> '/usr/share/npm/bin/npm-cli.js'
>>   ]
>> }
>> 
>> I am able to reproduce the error in a fresh chroot with:
>> 
>> debootstrap testing npm-chroot
>> chroot npm-chroot sh -c 'apt install -y npm && npm --version'
>> 
>> Any ideas?
> 
> Hi,
> 
> I'm unable to reproduce this bug when adding this autopkgtest
> (node-semver is a dependency of npm):
> 
> Test-Command: npm --version
> Depends: @
> Restrictions: superficial
> Features: test-name=npm-version
> 
> 
> Result is:
> autopkgtest [20:16:49]: test npm-version: npm --version
> autopkgtest [20:16:49]: test npm-version: [---
> 6.14.8
> autopkgtest [20:16:49]: test npm-version: ---]
> autopkgtest [20:16:49]: test npm-version:  - - - - - - - - - - results
> npm-version  PASS (superficial)

I'm sorry, but I'm not familiar enough with autopkgtest to confirm.
I'll start reading about autopkgtest to see if I can confirm or come up
with a repro.

Did you try installing to a chroot:

debootstrap testing npm-chroot && chroot npm-chroot sh -c 'apt install -y npm 
&& npm --version'

Thanks,
Kevin

Bug#969986: npm: Error: Cannot find module 'semver'

[Kevin Locke]

Package: npm
Version: 6.14.8+ds-1
Severity: important

Dear Maintainer,

When I run `npm --version` (or any subcommand), it prints:

internal/modules/cjs/loader.js:968
  throw err;
  ^

Error: Cannot find module 'semver'
Require stack:
- /usr/share/npm/lib/utils/unsupported.js
- /usr/share/npm/bin/npm-cli.js
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:965:15)
at Function.Module._load (internal/modules/cjs/loader.js:841:27)
at Module.require (internal/modules/cjs/loader.js:1025:19)
at require (internal/modules/cjs/helpers.js:72:18)
at Object. (/usr/share/npm/lib/utils/unsupported.js:2:14)
at Module._compile (internal/modules/cjs/loader.js:1137:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1157:10)
at Module.load (internal/modules/cjs/loader.js:985:32)
at Function.Module._load (internal/modules/cjs/loader.js:878:14)
at Module.require (internal/modules/cjs/loader.js:1025:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
'/usr/share/npm/lib/utils/unsupported.js',
'/usr/share/npm/bin/npm-cli.js'
  ]
}

I am able to reproduce the error in a fresh chroot with:

debootstrap testing npm-chroot
chroot npm-chroot sh -c 'apt install -y npm && npm --version'

Any ideas?

Thanks,
Kevin


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'unstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.7 (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 npm depends on:
ii  ca-certificates 20200601
ii  node-abbrev 1.1.1-2
ii  node-ajv6.12.4-1
ii  node-ansi   0.3.1-1
ii  node-ansi-regex 5.0.0-1
ii  node-ansi-styles4.2.1-1
ii  node-ansistyles 0.1.3-2
ii  node-aproba 2.0.0-1
ii  node-archy  1.0.0-3
ii  node-are-we-there-yet   1.1.5-1
ii  node-asap   2.0.6-2
ii  node-asn1   0.2.3-2
ii  node-assert-plus1.0.0-2
ii  node-asynckit   0.4.0-3
ii  node-aws-sign2  0.7.1-2
ii  node-aws4   1.10.1-1
ii  node-balanced-match 1.0.0-1
ii  node-bcrypt-pbkdf   1.0.2-1
ii  node-bl 4.0.3-1
ii  node-bluebird   3.7.2+dfsg1-1
ii  node-boxen  4.2.0-3
ii  node-brace-expansion1.1.11-1
ii  node-builtin-modules3.1.0-1
ii  node-builtins   1.0.3-2
ii  node-cacache11.3.3-2
ii  node-call-limit 1.1.1-1
ii  node-camelcase  5.3.1-1
ii  node-caseless   0.12.1-1
ii  node-chalk  2.4.2-1
ii  node-chownr 1.1.3-3
ii  node-ci-info2.0.0-1
ii  node-cli-boxes  2.2.0-3
ii  node-cliui  4.1.0-2
ii  node-clone  2.1.2-2
ii  node-co 4.6.0-3
ii  node-color-convert  1.9.3-1
ii  node-color-name 1.1.4-1
ii  node-colors 1.4.0-1
ii  node-columnify  1.5.4-3
ii  node-combined-stream1.0.8-1
ii  node-concat-map 0.0.1-2
ii  node-concat-stream  2.0.0-1
ii  node-config-chain   1.1.12-1
ii  node-configstore5.0.1-1
ii  node-console-control-strings1.1.0-2
ii  node-copy-concurrently  1.0.5-5
ii  node-core-util-is   1.0.2-2
ii  node-crypto-random-string   3.2.0-1
ii  node-cyclist1.0.1-3
ii  node-dashdash   1.14.1-3
ii  node-debbundle-es-to-primitive  1.2.1+~cs8.3.13-1
ii  node-debug  4.1.1+~cs4.1.5-1
ii  node-decamelize 4.0.0-1
ii  node-deep-extend0.6.0-1
ii  node-defaults   1.0.3-2
ii  node-define-properties  1.1.3-1
ii  node-delayed-stream 1.0.0-4
ii  node-delegates  1.0.0-2
ii  node-detect-indent  6.0.0-1
ii  node-detect-newline 3.1.0-1
ii  node-dot-prop   5.2.0-1
ii  node-duplexer3  0.1.4-5
ii  node-duplexify  4.1.1-1
ii  node-ecc-jsbn   0.2.0-2
ii  node-editor 1.0.0-2
ii  node-encoding   0.1.12-3
ii  node-end-of-stream  1.4.4-1
ii  node-err-code   2.0.0+dfsg-1
ii  node-errno  0.1.7-2
ii  node-es6-promise4.2.8-7
ii  node-escape-string-regexp   

Bug#969897: wireless-regdb: Document differences between debian and upstream regulatory.db

[Kevin Locke]

Package: wireless-regdb
Version: 2020.04.29-2
Severity: wishlist

Dear Maintainer,

I recently encountered the error

cfg80211: loaded regulatory.db is malformed or signature is missing/invalid

when booting kernel 5.8.7 without Debian patches.  Based on
/usr/share/doc/wireless-regdb/README.Debian I understand that this is
expected and I need to switch the regulatory.db alternative.  This all
works well, thanks.

However, I don't understand the implications of this change.  How does
the Debian version differ from the upstream version, if at all?  They
appear to be binary identical on my system, and that this is enforced by
the build scripts.  Is the difference only the signing keys?  Presumably
there is good reason for this divergence.  Would it be possible to
document the differences and motivation in README.Debian and/or
regulatory.db(5) to help users like myself understand?

Thanks,
Kevin


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'unstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.7 (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

wireless-regdb depends on no packages.

wireless-regdb recommends no packages.

Versions of packages wireless-regdb suggests:
ii  crda  4.14+git20191112.9856751-1

-- no debconf information

Bug#969755: nvidia-legacy-390xx-kernel-source: fails to build with module-assistant and NV_EXCLUDE_KERNEL_MODULES=nvidia-uvm

[Kevin Locke]

Package: nvidia-legacy-390xx-kernel-source
Version: 390.138-2
Severity: normal

Dear Maintainer,

I attempted to build nvidia-legacy-390xx-kernel-source against kernel
5.8.7 using module-assistant with NV_EXCLUDE_KERNEL_MODULES=nvidia-uvm
set in the environment, as suggested for dkms in the changelog.  It
failed with the following error:

$ NV_EXCLUDE_KERNEL_MODULES=nvidia-uvm m-a a-i -t -l 5.8.7 
nvidia-legacy-390xx-kernel-source
[... omit many lines of output ...]
make[1]: Leaving directory 
'/usr/src/modass/usr_src/modules/nvidia-legacy-390xx-kernel'
mv nvidia.ko nvidia-legacy-390xx.ko
mv nvidia-modeset.ko nvidia-legacy-390xx-modeset.ko
mv nvidia-drm.ko nvidia-legacy-390xx-drm.ko
mv nvidia-uvm.ko nvidia-legacy-390xx-uvm.ko
mv: cannot stat 'nvidia-uvm.ko': No such file or directory
make: *** [debian/rules:51: build-stamp] Error 1
BUILD FAILED!

It appears that nvidia-uvm.ko was not built (as intended) but
debian/rules fails when it does not exist.  Is there a way to build
against 5.8 with module-assistant, or is dkms required?

Thanks,
Kevin

Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not parse device path: Invalid argument"

[Kevin Locke]

On Mon, 2020-07-27 at 18:24 +0200, Michel Le Bihan wrote:
> Le lundi 27 juillet 2020 à 15:28 +, Limonciello, Mario a écrit :
>>> On Sun, 2020-07-26 at 14:58, Michel Le Bihan wrote:
>>> What's preventing the upstream fix from being applied to this
>>> package?
>> 
>> I personally can't reproduce the failure on my system's firmware.
>> Can you apply the fix locally and confirm it actually helps?
> 
> I applied the fix and built the package. It didn't help. I also built
> latest master and I still have this issue.

FWIW, I'm also experiencing the issue that efibootmgr -v produces the
error "Could not parse device path: Invalid argument" with libefiboot1
37-2.1, but not 37-2.  Building libefiboot1 with fdb8034 and 4e04afc
added to debian/patches does solve the issue for me.

https://github.com/rhboot/efivar/commit/fdb803402fb32fa6d020bac57a40c7efe4aabb7d.patch
https://github.com/rhboot/efivar/commit/4e04afc2df9bbc26e5ab524b53a6f4f1e61d7c9e.patch

Best,
Kevin

P.S. I had to build using GCC 9 due to
https://github.com/rhboot/efivar/issues/156

Bug#963805: efibootmgr: Could not parse device path: Invalid argumen

[Kevin Locke]

On Sat, 2020-06-27 at 20:13 +0200, Mikhail Morfikov wrote:
> it looks like that efibootmgr works well, but when the "-v" flag is used, I 
> get
> the following output:
> 
> # efibootmgr -v
> BootCurrent: 001A
> Timeout: 0 seconds
> BootOrder:
> 001A,001B,0019,0018,0001,0002,0003,0007,0008,0009,000A,000D,000B,000C,000E,000F,0010,0011,0012
> Boot  SetupCould not parse device path: Invalid argument

I am experiencing the same issue.  FYI, it is caused by a bug in
libefiboot1 37-2.1, which can be worked around by downgrading to 37-2
until a fix is released.  See https://bugs.debian.org/963475 and
https://github.com/rhboot/efibootmgr/issues/133#issuecomment-632578892

Best,
Kevin

Bug#953530: samba-common-bin: post-install fails with "lock directory /run/samba does not exist"

[Kevin Locke]

On Tue, 2020-03-10 at 08:40 +0100, Gian Piero Carrubba wrote:
> Package: samba-common-bin
> Version: 2:4.11.5+dfsg-1+b1
> Severity: normal
> 
> While upgrading samba-common-bin from 2:4.11.5+dfsg-1 to 2:4.11.5+dfsg-1+b1:
> 
> ---
> Performing actions...
> Setting up samba-common-bin (2:4.11.5+dfsg-1+b1) ...
> Checking smb.conf with testparm
> Load smb config files from /etc/samba/smb.conf
> Loaded services file OK.
> ERROR: lock directory /run/samba does not exist
> 
> ERROR: pid directory /run/samba does not exist
> 
> Server role: ROLE_STANDALONE
> 
> dpkg: error processing package samba-common-bin (--configure):
>  installed samba-common-bin package post-installation script subprocess 
> returned error exit status 1
> Errors were encountered while processing:
>  samba-common-bin
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> ---

I just ran into the same issue with a fresh install of
2:4.11.5+dfsg-1+b1.  For reference, packaging/systemd/README contains
the following warning:

> If you're a packager don't forget to run the systemd-tmpfiles binary
> in the script after samba has been installed. This makes sure the
> directory exists and you can start samba directly after the installation.
> 
> /usr/bin/systemd-tmpfiles --create /etc/tmpfiles.d/samba.conf

Presumably that should be changed to

/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/samba.conf

for the current Debian packaging.

Cheers,
Kevin

packaging/systemd/README: 
https://git.samba.org/samba.git/?p=samba.git;a=blob;f=packaging/systemd/README

Bug#962354: pristine-tar: pristine-xz failed to reproduce build of ../libvirt_6.4.0.orig.tar.xz

[Kevin Locke]

On Mon, 2020-06-15 at 09:52 -0300, Antonio Terceiro wrote:
> On Sat, Jun 06, 2020 at 05:11:58PM +0200, Andrea Bolognani wrote:
>> Package: pristine-tar
>> Version: 1.47
>> Severity: normal
> [...]
>> Downgrading pristine-tar to 1.46 from buster makes it possible to run
>> gbp import-orig successfully, at which point both 1.46 and 1.47 are
>> able to regenerate the tarball from the git branch.
> [...]
> 
> I bisected this and the commit that introduced this bug was
> 4ff745f2d3e905d88718b5e57bc6b4baf479f55b ("pristine-xz: Detect pixz
> compression").
> 
> Kevin, can you please take a look?

Sure thing.  Thanks Antonio.

Unfortunately, the issue was introduced by me in
https://salsa.debian.org/debian/pristine-tar/-/merge_requests/3
I've created a PR to fix it:
https://salsa.debian.org/debian/pristine-tar/-/merge_requests/5

Sorry for the hassle,
Kevin


signature.asc
Description: PGP signature

Bug#962293: RFP: virt-v2v -- Convert a guest from a foreign hypervisor to run on KVM

[Kevin Locke]

Package: wnpp
Severity: wishlist

* Package name: virt-v2v
  Version : 1.42.0
  Upstream Author : Richard W.M. Jones, Red Hat Inc.
* URL : http://libguestfs.org/
* License : GPL-2+
  Programming Lang: OCaml
  Description : Convert a guest from a foreign hypervisor to run on KVM

Virt-v2v converts a single guest from a foreign hypervisor to run on
KVM.  It can read Linux and Windows guests running on VMware, Xen,
Hyper-V and some other hypervisors, and convert them to KVM managed by
libvirt, OpenStack, oVirt, Red Hat Virtualisation (RHV) or several other
targets. It can modify the guest to make it bootable on KVM and install
virtio drivers so it will run quickly.

It was developed as part of libguestfs from 1.28 up to 1.41.7, and has
since been split into its own repository.[1][2][3]  It was shipped in
buster and it would be great to see it return to sid.

I whipped up a package for my own use.[4]  It is functional, but I'm
still following up on a few issues with upstream.  Deficiencies I'm
aware of are noted in debian/TODO.md.  Let me know if there's anything
else I can do to help.

Thanks,
Kevin

[1]: https://www.redhat.com/archives/libguestfs/2019-July/msg00102.html
[2]: https://www.redhat.com/archives/libguestfs/2019-October/msg00085.html
[3]: https://www.redhat.com/archives/libguestfs/2020-March/msg00053.html
[4]: https://salsa.debian.org/kevinoid/virt-v2v

Bug#956458: nvidia-legacy-390xx-kernel-source: Fails to build with Linux 5.6

[Kevin Locke]

Package: nvidia-legacy-390xx-kernel-source
Version: 390.132-3
Severity: normal
Tags: patch

Dear Maintainer,

Thanks for including a patch to fix building on Linux 5.5 (#951091) in
390.132-3!  Unfortunately, it fails to build on Linux 5.6.  There is a
patch in the same RPM Fusion bug used for 5.5[1] which is also included
in the rpm.[2]  As before, I would be willing to backport the changes
from 440.64 if that would be preferable.

Thanks again,
Kevin

[1]: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5536#c14
[2]: 
https://pkgs.rpmfusion.org/cgit/nonfree/nvidia-390xx-kmod.git/commit/?id=8f604b93a857c33f334669eeca8eea3eb5fc3563

Bug#955485: composer: Backport GitHub access_token fix before API removal

[Kevin Locke]

Since I forgot to include it in the original email, the GitHub
announcement with the deprecation timeline for access_token is at:

https://developer.github.com/changes/2020-02-10-deprecating-auth-through-query-param/

Best,
Kevin

Bug#955485: composer: Backport GitHub access_token fix before API removal

[Kevin Locke]

Package: composer
Version: 1.8.4-1
Severity: normal
Tags: patch

Dear Maintainer,

Until version 1.10.0 (commit 4b6c25d4b), Composer used the access_token
query parameter to authenticate with GitHub.  GitHub has announced[1]
that access_token is deprecated with brownouts on September 30 and
October 28, followed by removal on November 13, 2020.  They are
currently sending monthly email notifications to access_token users.

Since this is within the LTS timeline for both Stretch and Buster, and
the patch to fix the issue (attached) is quite small, would you consider
applying the fix to versions in those releases?

Thanks,
Kevin


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.5 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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
>From 4b6c25d4bc33d49097320e29e6e5705b12e9d6ef Mon Sep 17 00:00:00 2001
Message-Id: 
<4b6c25d4bc33d49097320e29e6e5705b12e9d6ef.1585743806.git.ke...@kevinlocke.name>
From: Jordi Boggiano 
Date: Tue, 14 Jan 2020 15:35:52 +0100
Subject: [PATCH] Use Authorization header instead of deprecated access_token
 query param, fixes #8454

---
 src/Composer/Util/RemoteFilesystem.php | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/Composer/Util/RemoteFilesystem.php 
b/src/Composer/Util/RemoteFilesystem.php
index 6d343f7a1..4885b7530 100644
--- a/src/Composer/Util/RemoteFilesystem.php
+++ b/src/Composer/Util/RemoteFilesystem.php
@@ -278,7 +278,7 @@ protected function get($originUrl, $fileUrl, 
$additionalOptions = array(), $file
 if (isset($options['github-token'])) {
 // only add the access_token if it is actually a github URL (in 
case we were redirected to S3)
 if (preg_match('{^https?://([a-z0-9-]+\.)*github\.com/}', 
$fileUrl)) {
-$fileUrl .= (false === strpos($fileUrl, '?') ? '?' : '&') . 
'access_token='.$options['github-token'];
+$options['http']['header'][] = 'Authorization: token 
'.$options['github-token'];
 }
 unset($options['github-token']);
 }
-- 
2.25.1

Bug#948206: mitmproxy incompatible with python3-wsproto=0.15.0-2

[Kevin Locke]

On Sun, 2020-01-05 at 11:27 +0100, Adrian Vollmer wrote:
> After upgrading python3-wsproto to version 0.15.0-2, mitmproxy fails
> immediately with this error message:
> 
> ImportError: cannot import name 'WSConnection' from 'wsproto.connection'
> (/usr/lib/python3/dist-packages/wsproto/connection.py)

I just encountered the same issue.  For reference, this specific error
was fixed in 106948d99[1] which is included in 5.0.0.  Apparently
setup.py was not updated to wsproto 0.15 due to mypy type checking
errors[2] (which I'm unable to reproduce on e01f044c).  Using wsproto
0.15 with 5.0.1 has been working well for me.

Best,
Kevin

[1]: https://github.com/mitmproxy/mitmproxy/commit/106948d99
[2]: https://github.com/mitmproxy/mitmproxy/pull/3651

Bug#952894: cups: Bad Request for FQDN without explicit ServerAlias

[Kevin Locke]

On Mon, 2020-03-02 at 08:48 +0100, Didier 'OdyX' Raboud wrote:
> Le dimanche, 1 mars 2020, 16.43:56 h CET Kevin Locke a écrit :
>> Accessing CUPS via https://hostname:631 works while
>> https://hostname.example.com:631 fails with 400 Bad Request if
>> cupsd.conf does not contain either "HostNameLookups on" or
>> "ServerAlias printserver.example.com".  This is a divergence from
>> upstream, where the FQDN returned by gethostname(2) is automatically
>> added as a ServerAlias.

One additional caveat: CUPS accepts FQDN with .local TLD as a special
case, with or without the patch.

>> It appears to be an untended side-effect of
>> 0026-Do-not-use-host-names-for-broadcasting-print-queues-.patch for
>> LP#449586.  Perhaps we could consider a different way to disable name
>> broadcasting without removing the ServerAlias for the FQDN which is used
>> for HTTP host checking?
> 
> Have you tried building and testing without this patch?

I hadn't, but did just now.  I can confirm CUPS now responds 200 OK to
requests with FQDN Host.  However, I'm not familiar with mDNS and
don't have cups-browsed installed, so I can't confirm whether the
patch would cause the FQDN to be broadcast and what effects that might
have, as in LP#449586.

> After 4+ years, it seems realistic to try without this patch again but: a) 
> only if we're sure it helps, b) only after 2.3.1-11 is migrated to testing.

I don't feel qualified to weigh the trade-off between requiring
explicit ServerAlias for valid FQDN and causing mDNS issues due to
invalid FQDN.  At least the current behavior was relatively easy to
debug.  Feel free to hold off until someone with mDNS experience, or
with a stronger rationale for either side weighs in.

Thanks,
Kevin

Bug#952894: cups: Bad Request for FQDN without explicit ServerAlias

[Kevin Locke]

Package: cups
Version: 2.3.1-7
Severity: normal

Dear Maintainer,

Accessing CUPS via https://hostname:631 works while
https://hostname.example.com:631 fails with 400 Bad Request if
cupsd.conf does not contain either "HostNameLookups on" or
"ServerAlias printserver.example.com".  This is a divergence from
upstream, where the FQDN returned by gethostname(2) is automatically
added as a ServerAlias.

It appears to be an untended side-effect of
0026-Do-not-use-host-names-for-broadcasting-print-queues-.patch for
LP#449586.  Perhaps we could consider a different way to disable name
broadcasting without removing the ServerAlias for the FQDN which is used
for HTTP host checking?

Thanks,
Kevin

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.5 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups depends on:
ii  cups-client2.3.1-7
ii  cups-common2.3.1-7
ii  cups-core-drivers  2.3.1-7
ii  cups-daemon2.3.1-7
ii  cups-filters   1.27.1-1
ii  cups-ppdc  2.3.1-7
ii  cups-server-common 2.3.1-7
ii  debconf [debconf-2.0]  1.5.73
ii  ghostscript9.50~dfsg-5
ii  libavahi-client3   0.7-5
ii  libavahi-common3   0.7-5
ii  libc6  2.29-10
ii  libcups2   2.3.1-7
ii  libgcc-s1  10-20200222-1
ii  libstdc++6 10-20200222-1
ii  libusb-1.0-0   2:1.0.23-2
ii  poppler-utils  0.71.0-6
ii  procps 2:3.3.15-2+b1

Versions of packages cups recommends:
pn  avahi-daemon  
pn  colord

Versions of packages cups suggests:
pn  cups-bsd   
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20191126-1
ii  smbclient  2:4.11.5+dfsg-1
ii  udev   244.3-1

-- debconf information excluded

Bug#952767: systemd: enable systemd-pstore.service by default

[Kevin Locke]

Package: systemd
Version: 244.3-1
Severity: normal

Dear Maintainer,

This morning my ThinkPad T430 failed to boot with the message:

Error: The non-volatile variable storage is about full
Press F1 to enter Setup.

The cause was the same as #891434: the kernel had dumped dmesg in pstore
after an oops, which created dump-type0-* efivars, which had accumulated
sufficiently to cause UEFI pre-boot to require user action.  (Luckily my
machine still boots, unlike in #891434.)

It appears that systemd-pstore.service should move these files to
/var/lib/systemd/pstore/ but the service is disabled.  `systemctl status
systemd-pstore.service` shows:

Loaded: loaded (/lib/systemd/system/systemd-pstore.service; disabled; 
vendor preset: enabled)"

I confirmed the same state occurs in a fresh testing install in a VM and
was not inadvertently disabled by me or a previous update.

Is there a reason systemd-pstore.service is disabled by default?  Could
we consider enabling it to avoid causing UEFI boot issues?

Thanks,
Kevin


-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.5 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-5
ii  libapparmor1 2.13.3-7
ii  libaudit11:2.8.5-2+b1
ii  libblkid12.34-0.1
ii  libc62.29-10
ii  libcap2  1:2.32-1
ii  libcryptsetup12  2:2.2.2-3
ii  libgcrypt20  1.8.5-3
ii  libgnutls30  3.6.12-2
ii  libgpg-error01.37-1
ii  libidn2-02.2.0-2
ii  libip4tc21.8.4-3
ii  libkmod2 27-1
ii  liblz4-1 1.9.2-2
ii  liblzma5 5.2.4-1+b1
ii  libmount12.34-0.1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.2-2
ii  libselinux1  3.0-1+b1
ii  libsystemd0  244.3-1
ii  mount2.34-0.1
ii  util-linux   2.34-0.1

Versions of packages systemd recommends:
ii  dbus  1.12.16-2

Versions of packages systemd suggests:
ii  policykit-10.105-26
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.136
ii  libnss-systemd   244.3-1
ii  libpam-systemd   244.3-1
ii  udev 244.3-1

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]
/etc/systemd/system.conf changed [not included]

-- no debconf information

Bug#951084: module-assistant: unpack sub-command not documented in module-assistant(8)

[Kevin Locke]

Package: module-assistant
Version: 0.11.10
Severity: minor
Tags: patch

Dear Maintainer,


Although the `unpack` sub-command is documented in the `--help` output,
it is not currently documented in the module-assistant(8) manual page,
which makes it harder to find for users consulting the man page.  I've
attached a patch which documents it.

Cheers,
Kevin


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.6 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages module-assistant depends on:
ii  bzip2  1.0.8-2
ii  libtext-wrapi18n-perl  0.06-9
ii  perl   5.30.0-9
ii  xz-utils   5.2.4-1+b1

Versions of packages module-assistant recommends:
ii  liblocale-gettext-perl  1.07-4

Versions of packages module-assistant suggests:
ii  build-essential  12.8
ii  whiptail 0.52.21-4

-- no debconf information
>From 677eb8a7e0ebbc03b880ef6b49f898afde9a3700 Mon Sep 17 00:00:00 2001
Message-Id: 
<677eb8a7e0ebbc03b880ef6b49f898afde9a3700.1581375953.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Mon, 10 Feb 2020 15:56:55 -0700
Subject: [PATCH] document unpack in module-assistant(8)

Although the `unpack` sub-command is documented in the `--help` output,
it is not currently documented in the module-assistant(8) manual page.
This commit adds some basic documentation similar to the other
sub-commands.

Signed-off-by: Kevin Locke 
---
 module-assistant.8.sgml | 8 
 1 file changed, 8 insertions(+)

diff --git a/module-assistant.8.sgml b/module-assistant.8.sgml
index 74205bf..d739c8e 100644
--- a/module-assistant.8.sgml
+++ b/module-assistant.8.sgml
@@ -44,6 +44,7 @@
list-installed
auto-unpacked
get
+   unpack
build
install
clean
@@ -189,6 +190,13 @@
  source, downloading source packages when needed.
  
 
+ unpack
+ 
+ 
+
  build
  
  

Bug#945534: virtualbox-source: Module FTBFS on Linux 5.4 due to set_pages_x

[Kevin Locke]

close 945534 6.0.14-dfsg-4
thanks

Thanks for releasing 6.0.14-dfsg-4 with the patch for 5.4.  Works
great for me.

Best,
Kevin

Bug#931656: libtorrent20: sends private IP address to trackers

[Kevin Locke]

On Mon, 08 Jul 2019 16:01:47 -0600 Kevin Locke  wrote:
> The issue is fixed by a 2-line patch to libtorrent that has been merged,
> but not released: https://github.com/rakshasa/libtorrent/pull/176

Quick update:  This patch is included in 0.13.8.

Cheers,
Kevin

Bug#945534: virtualbox-source: Module FTBFS on Linux 5.4 due to set_pages_x

[Kevin Locke]

Package: virtualbox-source
Version: 6.0.14-dfsg-2
Severity: normal
Tags: patch

Dear Maintainer,

The virtualbox module fails to build against Linux 5.4 with errors such
as the following:

-8<

In file included from 
/usr/src/modass/usr_src/modules/virtualbox/vboxdrv/r0drv/linux/alloc-r0drv-linux.c:31:
/usr/src/modass/usr_src/modules/virtualbox/vboxdrv/r0drv/linux/alloc-r0drv-linux.c:
 In function ‘VBoxHost_RTMemContAlloc’:
/usr/src/modass/usr_src/modules/virtualbox/vboxdrv/r0drv/linux/the-linux-kernel.h:340:47:
 error: implicit declaration of function ‘set_pages_x’; did you mean 
‘set_pages_rw’? [-Werror=implicit-function-declaration]
  340 | # define MY_SET_PAGES_EXEC(pPages, cPages)set_pages_x(pPages, 
cPages)
  |   ^~~
/usr/src/modass/usr_src/modules/virtualbox/vboxdrv/r0drv/linux/alloc-r0drv-linux.c:447:13:
 note: in expansion of macro ‘MY_SET_PAGES_EXEC’
  447 | MY_SET_PAGES_EXEC([iPage], 1);
  | ^

-8<

In addition to the currently included patch from r81649, the patches
from r81586 and r81587 must also be included for the module to build
with 5.4 on my system:

https://www.virtualbox.org/changeset/81586/vbox?format=diff
https://www.virtualbox.org/changeset/81587/vbox?format=diff

Thanks,
Kevin


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virtualbox-source depends on:
ii  build-essential   12.8
ii  bzip2 1.0.8-2
ii  debhelper [debhelper-compat]  12.7.1
ii  kbuild1:0.1.9998svn3296+dfsg-1
ii  module-assistant  0.11.10

Versions of packages virtualbox-source recommends:
ii  virtualbox  6.0.14-dfsg-2

virtualbox-source suggests no packages.

-- no debconf information

Bug#908088: xfce4-panel: systray icon background corrupt after upgrade to GTK 3.24 if display compositing disabled

[Kevin Locke]

On Sun, 2018-09-09 at 11:10 +1200, Ben Caradoc-Davies wrote:
> On 08/09/2018 16:52, Michael Biebl wrote:
>> This was indeed tested with compositing enabled.
>> So a GTK 3.24 / compositing related problem?
> 
> It is starting to look like it is. Is this the right package for this bug or
> should I reassign it to another package? gtk+3.0, perhaps? The bug is not
> limited to just nm-applet.

I just encountered this issue as well.  It is being tracked by XFCE at
https://bugzilla.xfce.org/show_bug.cgi?id=14577  It may be a
regression of https://gitlab.gnome.org/GNOME/gtk/issues/1280 that
occurred in GTK sometime between 3.22.30 and 3.24.8.

Cheers,
Kevin

Bug#708976: close 708976

[Kevin Locke]

On Tue, 2019-07-09 at 18:10 +0200, Nicolas Boulenguez wrote:
> This bug is probably fixed, and the original reporter seems unreachable.

My apologies, I must have missed your previous message.

I can confirm that on my system a program linked against libffado
run as a normal user prints:

Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns

That seems reasonable to me.  I agree with closing the issue.

Thanks!
Kevin

Bug#928634: nvidia-legacy-390xx-kernel-source: Fails to build with kernel 5.1

[Kevin Locke]

Here is an additional patch with backports from 430.14 to build with
kernel 5.2.  Again tested by me on amd64 but not arm or i386.

Cheers,
Kevin
Author: Kevin Locke 
Description: backport changes from 430.14 for kernel 5.2

Note: addition of set_page_dirty backported due to fc1d8e7cca2d

--- a/nvidia-uvm/uvm8_tools.c
+++ b/nvidia-uvm/uvm8_tools.c
@@ -204,18 +204,21 @@
 return event_tracker != NULL && !event_tracker->is_queue;
 }
 
-static void put_user_pages(struct page **pages, NvU64 page_count)
+static void uvm_put_user_pages_dirty(struct page **pages, NvU64 page_count)
 {
 NvU64 i;
-for (i = 0; i < page_count; i++)
+
+for (i = 0; i < page_count; i++) {
+set_page_dirty(pages[i]);
 put_page(pages[i]);
+}
 }
 
 static void unmap_user_pages(struct page **pages, void *addr, NvU64 size)
 {
 size = DIV_ROUND_UP(size, PAGE_SIZE);
 vunmap((NvU8 *)addr);
-put_user_pages(pages, size);
+uvm_put_user_pages_dirty(pages, size);
 uvm_kvfree(pages);
 }
 
@@ -279,7 +282,7 @@
 uvm_kvfree(vmas);
 
 if (ret > 0)
-put_user_pages(*pages, ret);
+uvm_put_user_pages_dirty(*pages, ret);
 else if (ret < 0)
 status = errno_to_nv_status(ret);
 

Bug#931656: libtorrent20: sends private IP address to trackers

[Kevin Locke]

Package: libtorrent20
Version: 0.13.7-1
Severity: normal
Tags: patch

Dear Maintainer,

I just upgraded to buster and found that rtorrent now sends my private
IP address to trackers unless manually configured (to send a bogus
address or the public address, via scripting if dynamic).  For details,
see .

Leaking the private IP can be a security and privacy issue which is not
obvious to users, unless trackers report a warning or error (most do
not).

The issue is fixed by a 2-line patch to libtorrent that has been merged,
but not released: https://github.com/rakshasa/libtorrent/pull/176

Is there any chance you would consider applying this patch, ideally in
both sid and stable?

Thanks,
Kevin


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.11 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtorrent20 depends on:
ii  libc6  2.28-10
ii  libcppunit-1.14-0  1.14.0-3
ii  libgcc11:8.3.0-6
ii  libssl1.1  1.1.1c-1
ii  libstdc++6 8.3.0-6
ii  zlib1g 1:1.2.11.dfsg-1

libtorrent20 recommends no packages.

libtorrent20 suggests no packages.

-- no debconf information

Bug#931583: unbound: start timeout if chroot configured

[Kevin Locke]

Package: unbound
Version: 1.9.0-2
Severity: normal

Dear Maintainer,

After upgrading from stretch (1.6.0-3+deb9u2) to buster (1.9.0-2)
unbound failed to start with log messages such as the following:

Jul 07 17:18:37 buster systemd[1]: Starting Unbound DNS server...
Jul 07 17:18:37 buster package-helper[12157]: /var/lib/unbound/root.key has 
content
Jul 07 17:18:37 buster package-helper[12157]: success: the anchor is ok
Jul 07 17:18:37 buster unbound[12161]: [12161:0] notice: init module 0: subnet
Jul 07 17:18:37 buster unbound[12161]: [12161:0] notice: init module 1: 
validator
Jul 07 17:18:37 buster unbound[12161]: [12161:0] notice: init module 2: iterator
Jul 07 17:18:37 buster unbound[12161]: [12161:0] info: start of service 
(unbound 1.9.0).
Jul 07 17:20:07 buster systemd[1]: unbound.service: Start operation timed out. 
Terminating.
Jul 07 17:20:07 buster unbound[12161]: [12161:0] info: service stopped (unbound 
1.9.0).
Jul 07 17:20:07 buster unbound[12161]: [12161:0] info: server stats for thread 
0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip 
ratelimiting
Jul 07 17:20:07 buster unbound[12161]: [12161:0] info: server stats for thread 
0: requestlist max 0 avg 0 exceeded 0 jostled 0
Jul 07 17:20:07 buster systemd[1]: unbound.service: Failed with result 
'timeout'.

I eventually determined that this is the result of having chroot
configured, as discussed in #921538.  To save others the time I spent
debugging this issue, I propose unbound log an error (and ideally fail
quickly) if chroot is configured in a way that won't work, rather than
causing start to quietly timeout.  I would be willing to provide a patch
if there is an agreeable way to achieve this (or to make the chroot
configuration work with systemd).

I would recommend unbound log an error for sd_notify() < 0 (which does
not occur if $NOTIFY_SOCKET is not defined).  If that is not acceptable,
perhaps `/usr/lib/unbound/package-helper chroot_setup` could fail and
log an error if $CHROOT_DIR/$NOTIFY_SOCKET is not a socket.  (This would
require passing $NOTIFY_SOCKET explicitly, since it is not available in
ExecStartPre.)

How would you like to proceed?

Thanks for considering,
Kevin

P.S.  I fixed the timeout by adding a unbound.service override with:

[Service]
BindPaths=/run/systemd/notify:/var/lib/unbound/run/systemd/notify

If there isn't a plan to make chroot work automatically (which is
difficult since BindPath can't be set using systemctl set-property)
I could add instructions to README.Debian as part of the patch.

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
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 unbound depends on:
ii  adduser 3.118
ii  dns-root-data   2019031302
ii  libc6   2.28-10
ii  libevent-2.1-6  2.1.8-stable-4
ii  libfstrm0   0.4.0-1
ii  libprotobuf-c1  1.3.1-1+b1
ii  libpython3.73.7.3-2
ii  libssl1.1   1.1.1c-1
ii  libsystemd0 241-5
ii  lsb-base10.2019051400
ii  openssl 1.1.1c-1
ii  unbound-anchor  1.9.0-2

unbound recommends no packages.

Versions of packages unbound suggests:
ii  apparmor  2.13.2-10

-- Configuration Files:
/etc/unbound/unbound.conf changed [not included]

-- no debconf information

Bug#930530: pcscd: Runs with possibly unnecessary privileges

[Kevin Locke]

Package: pcscd
Version: 1.8.24-1
Severity: normal

Dear Maintainer,

pcscd currently runs as root.  This is a security risk (as pointed out
in the SECURITY file shipped with pcscd).  It was previously fixed in
Bug #606142 and regressed back to root when systemd support was added
(setgid was removed in 798d03c).

Is there a reason that pcscd needs to run as root, rather than a normal
user with access to the necessary device files?  If so, could the
rationale be documented in the SECURITY file?  If not, what would be
required to run as a non-root user and would you accept patches that
make the necessary changes?

Thanks,
Kevin


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.2 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pcscd depends on:
ii  libc6   2.28-10
ii  libccid [pcsc-ifd-handler]  1.4.30-1
ii  libpcsclite11.8.24-1
ii  libsystemd0 241-5
ii  libudev1241-5
ii  lsb-base10.2019051400

pcscd recommends no packages.

Versions of packages pcscd suggests:
ii  systemd  241-5

-- no debconf information

Bug#929055: virtualbox-source: Build failed due to dh_clean -k with dh compat 12

[Kevin Locke]

Package: virtualbox-source
Version: 6.0.8-dfsg-2
Severity: normal

Dear Maintainer,

Attempting to build version 6.0.8-dfsg-2 with `m-a build` ends with the
following messages:

dh_testroot
dh_clean -k
dh_clean: The -k option is not supported in compat 12; use dh_prep instead
dh_clean: This feature was removed in compat 12.
make[1]: *** [debian/rules:59: binary-modules] Error 2
make[1]: Leaving directory '/usr/src/modass/usr_src/modules/virtualbox'
make: *** [/usr/share/modass/include/common-rules.make:56: kdist_build] Error 2
BUILD FAILED!

Downgrading virtualbox-source to 6.0.8-dfsg-1 fixes the issue.

Best,
Kevin

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.2 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages virtualbox-source depends on:
ii  build-essential   12.6
ii  bzip2 1.0.6-9
pn  debhelper-compat  
ii  kbuild1:0.1.9998svn3293+dfsg-2
ii  module-assistant  0.11.10

Versions of packages virtualbox-source recommends:
ii  virtualbox  6.0.8-dfsg-2

virtualbox-source suggests no packages.

-- no debconf information

Bug#928634: nvidia-legacy-390xx-kernel-source: Fails to build with kernel 5.1

[Kevin Locke]

-mesa  1.0.0
ii  glx-diversions1.0.0
ii  update-glx1.0.0

Versions of packages glx-alternative-nvidia suggests:
pn  nvidia-driver  

Versions of packages xserver-xorg-video-intel depends on:
ii  libc6  2.28-10
ii  libdrm-intel1  2.4.97-1
ii  libdrm22.4.97-1
ii  libpciaccess0  0.14-1
ii  libpixman-1-0  0.36.0-1
ii  libudev1   241-3
ii  libx11-6   2:1.6.7-1
ii  libx11-xcb12:1.6.7-1
ii  libxcb-dri2-0  1.13.1-2
ii  libxcb-dri3-0  1.13.1-2
ii  libxcb-sync1   1.13.1-2
ii  libxcb-util0   0.3.8-3+b2
ii  libxcb11.13.1-2
ii  libxcursor11:1.1.15-2
ii  libxdamage11:1.1.4-3+b3
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxinerama1   2:1.1.4-2
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  libxshmfence1  1.3-1
ii  libxss11:1.2.3-1
ii  libxtst6   2:1.2.3-1
ii  libxv1 2:1.0.11-1
ii  libxvmc1   2:1.0.10-1
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.3-1

Versions of packages nvidia-legacy-390xx-kernel-source is related to:
pn  bumblebee
pn  bumblebee-nvidia 
pn  ccache   
pn  libcuda1 
pn  libdrm-nouveau1  
pn  libdrm-nouveau1a 
ii  libdrm-nouveau2  2.4.97-1
ii  libegl1  1.1.0-1
ii  libgl1   1.1.0-1
ii  libgl1-nvidia-legacy-390xx-glvnd-glx [libgl1-nvidia-glx-any] 390.116-1
ii  libgles1 1.1.0-1
ii  libgles2 1.1.0-1
ii  libglvnd01.1.0-1
ii  libglx0  1.1.0-1
ii  libnvidia-legacy-390xx-cuda1 [libcuda1-any]  390.116-1
pn  libopencl0   
ii  libvulkan1   1.1.97-2
pn  linux-headers
ii  make 4.2.1-1.2
pn  nvidia-glx-legacy-390xx  
ii  nvidia-kernel-common 20151021+9
ii  nvidia-legacy-390xx-driver [nvidia-glx-any]  390.116-1
pn  nvidia-legacy-390xx-kernel-dkms  
ii  nvidia-legacy-390xx-kernel-source390.116-1
ii  nvidia-legacy-390xx-kernel-support [nvidia-kernel-support-any]   390.116-1
ii  nvidia-legacy-390xx-opencl-icd [opencl-icd]  390.116-1
ii  nvidia-legacy-390xx-vulkan-icd [vulkan-icd]  390.116-1
ii  nvidia-modprobe  418.56-1
pn  nvidia-settings  
ii  nvidia-support   20151021+9
pn  nvidia-xconfig   
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-2
ii  xserver-xorg 1:7.7+19
ii  xserver-xorg-core2:1.20.3-1
ii  xserver-xorg-legacy  2:1.20.3-1
ii  xserver-xorg-video-nouveau   1:1.0.16-1
ii  xserver-xorg-video-nvidia-legacy-390xx [xserver-xorg-video-nvid  390.116-1

-- no debconf information
Author: Kevin Locke 
Description: backport changes from 418.74 for kernel 5.1.patch

--- a/common/inc/nv-linux.h
+++ b/common/inc/nv-linux.h
@@ -1082,6 +1082,10 @@
 
 #define NV_PAGE_MASK(NvU64)(long)PAGE_MASK
 
+#ifndef NV_VMF_INSERT_PFN_PRESENT
+typedef int vm_fault_t;
+#endif
+
 extern void *nvidia_stack_t_cache;
 
 // Changed in 2.6.23 via commit 20c2df83d25c6a95affe6157a4c9cac4cf5ffaac
--- a/common/inc/nv-list-helpers.h
+++ b/common/inc/nv-list-helpers.h
@@ -91,10 +91,12 @@
 list_entry((pos

Bug#923561: parted: Incorrect optimal alignment for USB device

[Kevin Locke]

On Tue, 2019-03-05 at 16:27 -0500, Phillip Susi wrote:
> On 3/5/2019 10:58 AM, Kevin Locke wrote:
>> Sounds great.  How do you propose that the kernel determine the
>> optimal alignment?
> 
> md does it using the stripe size.  Not sure if anything other the md or
> dm would make sense to populate the value.  Well, I guess hardware raid
> drivers.

Sounds reasonable to me.  Feel free to propose it to the kernel
maintainers.

>> the disk on which I am running parted is not a RAID array, I don't
>> think the documentation above says that it is anything more than
>> "preferred unit for sustained I/O".
> 
> Yes, the first part says that, but then it goes on to say that normal
> disks generally leave it zero, and raid disks set it to the stripe width.

Documentation/ABI/testing/sysfs-block does not say "normal disks
generally leave it 0", it says "If no optimal I/O size is reported
this file contains 0."  SCSI disks report an optimal I/O size via VPD.

I still think the documentation here is correct.  If you disagree,
feel free to report it to the kernel maintainers.

>>> Wait, how can optimal_io_size NOT be a multiple of the block size?
>> 
>> For my disk, the logical block size is 512 bytes, the physical block
>> size is 4,096, opt_xfer_blocks is 65,535, so optimal_io_size is
>> 65,535*512=33,553,920 which is not a multiple of 4,096.  I considered
>> advocating that the kernel check this, but decided against it.
> 
> Oh, that is weird.  I guess such a sanity check would fix the issue for
> your USB stick, but what about others?

Are there cases where the optimal partition alignment is not a
multiple of the physical sector size?  If so, lets consider whether
they can be worked into the sanity checking logic.  If not, are there
other risks that you foresee which are not shared by util-linux and
cryptsetup, which have been using such a sanity check for years?

Also, if "your USB stick" was intended to suggest that this is not a
common problem, I would disagree.  I suspect it occurs on most/all
Seagate UAS drives (which share some other known problems[1]).

>> SCSI devices can report any value (measured in logical blocks) for VPD
>> Optimal Transfer Length.  It is not restricted to multiples of the
>> physical block size.  For my disk, it is not, which is the cause of
>> the current issue.
> 
> So for 512e disks basically, the optimal transfer length can be not a
> multiple of physical block size and foolish drives try to specify the
> maximum possible value in logical 512 byte sectors, and that ends up
> being 1 logical sector too small to align to 4k.  For 512n 4kn disks,
> the optimal size can never not be a multiple of the sector size, so the
> sanity check would pass and still give you a massive alignment you don't
> want.

I agree that is a potential issue.  Sanity checking the size of
optimal_io_size would make sense.  At the moment, I'm less concerned
about wasted space than misalignment, so I don't have an opinion on
how to handle that case.

Kevin


[1]: https://github.com/torvalds/linux/commit/7fee72d5e8f1

Bug#923561: parted: Incorrect optimal alignment for USB device

[Kevin Locke]

On Tue, 2019-03-05 at 08:49 -0500, Phillip Susi wrote:
> On 3/4/2019 5:29 PM, Kevin Locke wrote:
> > On 17 June 2015 at 01:08, Martin K. Petersen  
> > wrote:
>>> There's only so much we can do about devices that report garbage.
>>>
>>> Also, the kernel only reports things. It is up to Karel to decide
>>> whether to sanity check the values before he uses them.
>> 
>> If we are going to bring it up again, I'd like to have a specific
>> recommendation or request.  More discussion below:
> 
> It sounds like it wasn't intended to have anything to do with alignment,
> but since MD used it that way, parted interpreted it that way.  If
> optimal_io_size is just that, then maybe a new variable needs to be
> created to expose optimal alignment?

Sounds great.  How do you propose that the kernel determine the
optimal alignment?

>> Could you point me to the kernel documentation that mentions how the
>> md driver uses optimal_io_size?
> 
> Documentation/ABI/testing/sysfs-block:
> 
> Storage devices may report an optimal I/O size, which is
> the device's preferred unit for sustained I/O.  This is
> rarely reported for disk drives.  For RAID arrays it is
> usually the stripe width or the internal track size.

I disagree that what you quoted says that that the md driver uses
optimal_io_size for anything, much less unconditionally.  Also, since
the disk on which I am running parted is not a RAID array, I don't
think the documentation above says that it is anything more than
"preferred unit for sustained I/O".

>> My current reading is that optimal_io_size has the same definition as
>> SCSI VPD Optimal Transfer Length.  It has a loosely defined meaning,
>> but its value for any particular use is contingent on sanity checking.
> 
> I'm not sure how you can sanity check it.  Either it has meaning
> relevant to alignment or it doesn't.  It sounds like it wasn't supposed
> to even though md used it that way.

I suggest sanity checking it in the same way that cryptsetup and
util-linux now do, by checking that it is a multiple of the physical
sector size or minimum_io_size.

>> Do you have a particular proposal for how to improve the kernel
>> documentation or how optimal_io_size behaves?  I worked up a patch
>> which only uses logical_to_bytes(sdp, sdkp->opt_xfer_blocks) for
>> io_opt if it is a multiple of sdkp->physical_block_size, but I am not
>> convinced enough that it is universally applicable to advocate for it.
>> Any alternative suggestions?
> 
> Wait, how can optimal_io_size NOT be a multiple of the block size?

For my disk, the logical block size is 512 bytes, the physical block
size is 4,096, opt_xfer_blocks is 65,535, so optimal_io_size is
65,535*512=33,553,920 which is not a multiple of 4,096.  I considered
advocating that the kernel check this, but decided against it.

SCSI devices can report any value (measured in logical blocks) for VPD
Optimal Transfer Length.  It is not restricted to multiples of the
physical block size.  For my disk, it is not, which is the cause of
the current issue.

Kevin

Bug#923561: parted: Incorrect optimal alignment for USB device

[Kevin Locke]

After a bit more research, I found that this issue has been mentioned
on linux-usb[1] and that Martin K. Petersen weighed in on the issue in
a util-linux-ng thread[2]:

On 17 June 2015 at 01:08, Martin K. Petersen  wrote:
> There's only so much we can do about devices that report garbage.
> 
> Also, the kernel only reports things. It is up to Karel to decide
> whether to sanity check the values before he uses them.

If we are going to bring it up again, I'd like to have a specific
recommendation or request.  More discussion below:

On Mon, 2019-03-04 at 13:42 -0500, Phillip Susi wrote:
> On 3/4/2019 11:50 AM, Kevin Locke wrote:
>> optimal_io_size is defined in the kernel ABI[1] as "the preferred
>> request size for workloads where sustained throughput is desired".  In
>> this case, I think it comes from scsi_disk.opt_xfer_blocks[2] which
>> comes from the VPD block limits page[3] which my disk reports as 65535
>> blocks (according to sg_vpd).
> 
> Yes, I was looking over the definition earlier in the kernel
> documentation, and it seems to me that part of the definition indicates
> it is simply an optimal size to transfer in, and has nothing to do with
> alignment.  But parted treats it as having to do with alignment, because
> the same kernel documentation mentions that is what the md driver uses
> the field for.

Could you point me to the kernel documentation that mentions how the
md driver uses optimal_io_size?

>> However, whether or not this is changed in the kernel, I would argue
>> it should be handled in parted.  Both to support previous+current
>> kernels and because I think the optimal_io_size ABI definition allows
>> optimal_io_size which is not a multiple of minimum_io_size for
>> transports where that truly is the case.
> 
> Unfortunately, that means parted needs to simply ignore the value of
> optimal io size as totally meaningless garbage, and I don't much like
> the thought of that.  If parted has always been wrong and the intended
> meaning of the kernel parameter has never had anything to do with
> alignment, then yes, parted needs to ignore it because it read meaning
> into it that was never intended.  But if it is supposed to have
> something to do with optimal alignment, then md is right and usb is
> wrong, and usb needs to be fixed.

My current reading is that optimal_io_size has the same definition as
SCSI VPD Optimal Transfer Length.  It has a loosely defined meaning,
but its value for any particular use is contingent on sanity checking.

Do you have a particular proposal for how to improve the kernel
documentation or how optimal_io_size behaves?  I worked up a patch
which only uses logical_to_bytes(sdp, sdkp->opt_xfer_blocks) for
io_opt if it is a multiple of sdkp->physical_block_size, but I am not
convinced enough that it is universally applicable to advocate for it.
Any alternative suggestions?

Thanks,
Kevin

[1]: https://www.spinics.net/lists/linux-usb/msg125988.html
[2]: https://www.spinics.net/lists/util-linux-ng/msg11702.html

Bug#923561: parted: Incorrect optimal alignment for USB device

[Kevin Locke]

On Mon, 2019-03-04 at 10:01 -0500, Phillip Susi wrote:
> Interesting.  It sounds like USB and MD are using optimal_io_size in
> fundamentally incompatible ways.  The question then is: is USB doing the
> wrong thing ( and should be fixed ), or is the very definition of
> optimal_io_size fundamentally broken?

optimal_io_size is defined in the kernel ABI[1] as "the preferred
request size for workloads where sustained throughput is desired".  In
this case, I think it comes from scsi_disk.opt_xfer_blocks[2] which
comes from the VPD block limits page[3] which my disk reports as 65535
blocks (according to sg_vpd).

The definition seems reasonable, but it would not surprise me if 65535
were bogus.  I am not familiar enough with USB+UAS to know if this
might be an optimal size for the protocols involved.  I can raise the
issue on linux-scsi/linux-usb.

However, whether or not this is changed in the kernel, I would argue
it should be handled in parted.  Both to support previous+current
kernels and because I think the optimal_io_size ABI definition allows
optimal_io_size which is not a multiple of minimum_io_size for
transports where that truly is the case.

Best,
Kevin

P.S.  libfdisk from util-linux has also applied the same fix as
cryptsetup of ignoring optimal_io_size if it is not a multiple of
minimum_io_size.[4]

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-block?h=v5.0#n134
[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/sd.c?h=v5.0#n3137
[3]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/sd.c?h=v5.0#n2886
[4]: https://github.com/karelzak/util-linux/commit/acb7651f8

Bug#923561: parted: Incorrect optimal alignment for USB device

[Kevin Locke]

Package: parted
Version: 3.2-24
Severity: normal

Dear Maintainer,

Running `parted /dev/sdb mkpart primary 0% 100%` on an 8TB Seagate
"Backup Plus Hub" USB3 drive results in a partition which starts at
65535s (33553920B), which is not a multiple of the physical block size
(4096B).  It also causes parted `parted /dev/sdb mkpart primary 1MiB 100%`
to print "Warning: The resulting partition is not properly aligned for
best performance."

If this partition is used by device-mapper, the kernel will print:

device-mapper: table: 254:2: adding target device sdb1 caused an alignment 
inconsistency: physical_block_size=4096, logical_block_size=512, 
alignment_offset=0, start=33553920

The drive has the following topology (lsblk -t /dev/sdb):

NAME ALIGNMENT MIN-IO   OPT-IO PHY-SEC LOG-SEC ROTA SCHED   RQ-SIZE  RA 
WSAME
sdb  0   4096 335539204096 5121 mq-deadline  60 128   
32M

Presumably the error occurs because parted is using the optimal_io_size
for alignment.  Since optimal_io_size is based on USB constraints rather
than disk constraints, it does not seem suitable for partition layout.

I would suggest ignoring optimal_io_size if it is not a multiple of
minimum_io_size, as done by cryptsetup[1].  Alternatively, 33553920
could be ignored specifically, since it seems common for USB disks.

This issue has been discussed elsewhere:
https://www.saout.de/pipermail/dm-crypt/2016-January/004934.html
https://bugzilla.redhat.com/show_bug.cgi?id=1513820
https://unix.stackexchange.com/q/340484
https://linux-blog.anracom.com/2018/12/03/linux-ssd-partition-alignment-problems-with-external-usb-to-sata-controllers-i/

Thanks for considering,
Kevin

[1]: https://gitlab.com/cryptsetup/cryptsetup/commit/b80278c0

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.20.10 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages parted depends on:
ii  libc6 2.28-7
ii  libparted23.2-24
ii  libreadline7  7.0-5
ii  libtinfo6 6.1+20181013-2

parted recommends no packages.

Versions of packages parted suggests:
pn  parted-doc  

-- no debconf information