Bug#1081749: Secure boot disabling dialogue is missing information

[chrysn]

Package: shim-signed
Version: 1.44+15.8-1
Severity: minor

When updating kernel modules on secure boot that don't work with it, apt
shows this message that AIU comes from shim-signed:

> Your system has UEFI Secure Boot enabled
>
> UEFI Secure Boot is not compatible with the use of third-party
> drivers. To ensure that this change is being made [...]

The user needs to take a decision whether to disable secureboot or to
leave it on, but to make an *informed* decision, the user will need to
know which those third-party drivers are. In my case, I think it was the
v4l loopback, so I stuck with secureboot, but apt dialogues should
preferably not invite guessing.

I have no clue how that information is available at this point, but it
would have helped me to see something like:

> The third-party drivers that will be unavailable if secureboot statys
> active are:
>
> - virtualbox-dkms
> - v4l-loopback

thanks for your consideration, and for maintaining this
Christian

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

Kernel: Linux 6.6.8-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages shim-signed depends on:
ii  grub-efi-amd64-bin 2.12-2~deb13u1
ii  grub2-common   2.12-2~deb13u1
ii  shim-helpers-amd64-signed  1+15.8+1
ii  shim-signed-common 1.44+15.8-1

shim-signed recommends no packages.

shim-signed suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1072016: [PATCH] debian/patches: Refresh trivial cases

[chrysn]

Source: pypy3
Version: 7.3.16+dfsg-2
Followup-For: Bug #1072016

I got stuck trying to refresh the debian/ensurepip-wheels patch, but
could refresh some earlier patches. Most were applied automatically
anyway and just needed to be acknowledged (all do look fine), a few
needed trivial manual work -- still, a few steps less in porting:

---
 debian/patches/stdlib/locale-module|  4 +---
 debian/patches/stdlib/rlcompleter-invalidterminal  |  8 +++-
 debian/patches/tests/skip-test_multiprocessing |  4 +---
 debian/patches/tests/test_fsync-eatmydata  |  4 +---
 debian/patches/tests/test_readline-invalidterminal | 14 ++
 5 files changed, 12 insertions(+), 22 deletions(-)

diff --git a/debian/patches/stdlib/locale-module 
b/debian/patches/stdlib/locale-module
index 0c8772f2..f788b60d 100644
--- a/debian/patches/stdlib/locale-module
+++ b/debian/patches/stdlib/locale-module
@@ -12,11 +12,9 @@ Last-Update: 2011-12-19
  lib-python/3/locale.py | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
-diff --git a/lib-python/3/locale.py b/lib-python/3/locale.py
-index 1a4e9f6..dfcfba5 100644
 --- a/lib-python/3/locale.py
 +++ b/lib-python/3/locale.py
-@@ -1409,8 +1409,8 @@ locale_alias = {
+@@ -1415,8 +1415,8 @@
  'ug_cn':'ug_CN.UTF-8',
  'uk':   'uk_UA.KOI8-U',
  'uk_ua':'uk_UA.KOI8-U',
diff --git a/debian/patches/stdlib/rlcompleter-invalidterminal 
b/debian/patches/stdlib/rlcompleter-invalidterminal
index 3b7fed76..755ee294 100644
--- a/debian/patches/stdlib/rlcompleter-invalidterminal
+++ b/debian/patches/stdlib/rlcompleter-invalidterminal
@@ -10,19 +10,17 @@ Forwarded: https://github.com/pypy/pypy/issues/3308
  lib-python/3/rlcompleter.py | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)
 
-diff --git a/lib-python/3/rlcompleter.py b/lib-python/3/rlcompleter.py
-index 923f5c0..5a440c1 100644
 --- a/lib-python/3/rlcompleter.py
 +++ b/lib-python/3/rlcompleter.py
-@@ -32,6 +32,7 @@ Notes:
- import atexit
+@@ -33,6 +33,7 @@
  import builtins
+ import inspect
  import __main__
 +from pyrepl.unix_console import InvalidTerminal
  
  __all__ = ["Completer"]
  
-@@ -76,11 +77,13 @@ class Completer:
+@@ -77,11 +78,13 @@
  if not text.strip():
  if state == 0:
  if _readline_available:
diff --git a/debian/patches/tests/skip-test_multiprocessing 
b/debian/patches/tests/skip-test_multiprocessing
index c3804900..5947de3b 100644
--- a/debian/patches/tests/skip-test_multiprocessing
+++ b/debian/patches/tests/skip-test_multiprocessing
@@ -10,8 +10,6 @@ Last-Updated: 2015-02-11
  lib-python/3/test/_test_multiprocessing.py | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
-diff --git a/lib-python/3/test/_test_multiprocessing.py 
b/lib-python/3/test/_test_multiprocessing.py
-index c00f21c..21c0c09 100644
 --- a/lib-python/3/test/_test_multiprocessing.py
 +++ b/lib-python/3/test/_test_multiprocessing.py
 @@ -1,8 +1,10 @@
@@ -25,4 +23,4 @@ index c00f21c..21c0c09 100644
 +'Disabled for now')
  import unittest.mock
  import queue as pyqueue
- import time
+ import textwrap
diff --git a/debian/patches/tests/test_fsync-eatmydata 
b/debian/patches/tests/test_fsync-eatmydata
index 0b354c2e..c44489ba 100644
--- a/debian/patches/tests/test_fsync-eatmydata
+++ b/debian/patches/tests/test_fsync-eatmydata
@@ -8,11 +8,9 @@ Last-Update: 2012-02-06
  lib-python/3/test/test_os.py | 2 ++
  1 file changed, 2 insertions(+)
 
-diff --git a/lib-python/3/test/test_os.py b/lib-python/3/test/test_os.py
-index 3146d1a..fde22b5 100644
 --- a/lib-python/3/test/test_os.py
 +++ b/lib-python/3/test/test_os.py
-@@ -1972,6 +1972,8 @@ class TestInvalidFD(unittest.TestCase):
+@@ -2114,6 +2114,8 @@
  except OSError as e:
  self.assertEqual(e.errno, errno.EBADF)
  else:
diff --git a/debian/patches/tests/test_readline-invalidterminal 
b/debian/patches/tests/test_readline-invalidterminal
index c4190716..35c15b98 100644
--- a/debian/patches/tests/test_readline-invalidterminal
+++ b/debian/patches/tests/test_readline-invalidterminal
@@ -11,19 +11,17 @@ Forwarded: https://github.com/pypy/pypy/issues/3308
  lib-python/3/test/test_readline.py | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)
 
-diff --git a/lib-python/3/test/test_readline.py 
b/lib-python/3/test/test_readline.py
-index f711ba8..c8e4815 100644
 --- a/lib-python/3/test/test_readline.py
 +++ b/lib-python/3/test/test_readline.py
-@@ -10,6 +10,7 @@ import subprocess
+@@ -10,6 +10,7 @@
  import sys
  import tempfile
  import unittest
 +from pyrepl.unix_console import InvalidTerminal
- from test.support import import_module, unlink, temp_dir, TESTFN, verbose
- from test.support.script_helper import assert_python_ok
- 
-@@ -45,7 +46,10 @@ class TestHistoryManipulation (unittest.TestCase):
+ from test.support import verbose
+ from test.s

Bug#1072016: Build Python 3.10 version

[chrysn]

Source: pypy3
Version: 7.3.16+dfsg-2
Severity: wishlist

The current pypy3 package builds a pypy3.9. This excludes recent Python
packages that require Python 3.10 or newer (for comparison, 3.9 was in
bullseye, and bookworm has 3.11). It is also a bit confusing to users
who might look at the PyPy version provided (7.3.16+dfsg-2), see the
PyPy announcements ("PyPy 7.3.16 includes 3.10"), and get rejection from
tools not treating the pypy as a 3.10.

Please consider updating the pypy packages to include Python 3.10.

I've tried doing the update by stupidly replacing 3.9 with 3.10 in the
debian/ directory, but apparently that also changes the upstream
sources, and I have not yet managed to convince `gbp import-orig
--uscan` to "switch over".


Thanks for maintaining PyPy in Debian
chrysn

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

Kernel: Linux 6.6.8-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#989844: [Pkg-rust-maintainers] Bug#989844: Cross-compilation support (please package more libstd-rust-dev-*)

[chrysn]

> but without std, the topic of this bug.

I don't think that no-std targtets are off topic for this bug. Rust's
terminologiy is a bit weird in that "std" sometimes means the "std"
crate (which is the thing that does POSIX-style operations), but also
sometimes means std+alloc+core (for example in -Zbuild-std=core, which
replaces any shipped core with one freshly built -- something one might
use instead of having those packaged, except that it will stay a nightly
feature for the forseeable future).

Thus, it can be argued that even the built libraries would be
appropriately named as libstd-rust-dev-thumbv7em-none-eabihf etc -- and
even if not (going for libcore-rust-dev-thumbv7em-none-eabihf), the
implementation similarities to other platforms without host tools
probably warrant lumping them together.


signature.asc
Description: PGP signature

Bug#1032952: apt-add-repository silently ignores deb822 .sources files

[chrysn]

Package: software-properties-common
Version: 0.99.30-4
Severity: normal
File: /usr/bin/apt-add-repository

On systems whose sources are stored in deb822 format, apt-add-repository
commands that act on existing sources (such as `apt-add-repository
--component contrib`) fail silently: They don't update the entries, but
don't report an error either.

I didn't go though a full fresh install to show its reproducibility, but
it can be shown easily using Docker images:

$ podman run --rm -it --network=host docker.io/debian:sid
# apt-get update && apt-get -y install --no-install-recommends 
software-properties-common
# cp -a /etc/apt/sources.list.d/ /tmp/
# apt-add-repository  --component contrib
[Enter]
# echo $?
0
# diff -r /tmp/sources.list.d/ /etc/apt/sources.list.d/
[no differences]

This is probably not trivial to fix given that software-properties deals
in more than just this single tool. As a stop-gap measure against silent
failure, operations on all repositories could start to fail once any
`*.sources` file is present.

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

Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages software-properties-common depends on:
ii  ca-certificates  20211016
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-packagekitglib-1.01.2.6-3
ii  packagekit   1.2.6-3
ii  python-apt-common2.5.3
ii  python3  3.11.2-1
ii  python3-dbus 1.3.2-4+b1
ii  python3-gi   3.42.2-3+b1
ii  python3-software-properties  0.99.30-4

software-properties-common recommends no packages.

software-properties-common suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#1022129: Default to not include resume (hibernation / suspend to disk) is unexpected

[chrysn]

Package: dracut
Version: 056-3
Severity: minor

dracut by default appears not to include the resume module; I had to
enable it manually using the configuration from the Arch wiki[1].

https://bugs.debian.org/708253 indicates that a `resume=` parameter
would have been necessary with dracut; this appears not to be necessary
any more, and was not sufficient in my tests either.

I suggest that resume be enabled by default, or at least there be a note
something inside the shipped documentation (eg. README.Debian) that it
needs manual enabling.

[1]: https://wiki.archlinux.org/title/Dracut#Hibernation

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

Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dracut depends on:
ii  dracut-core  056-3

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#1012870: defaults should include dbus-daemon

[chrysn]

Package: earlyoom
Version: 1.7-1
Followup-For: Bug #1012870

> I have never seen dbus-daemon use more memory than firefox.
> Is there an unfixed memory leak in the Debian version of dbus-deamon?

None that I'm aware of -- but I've just had a similar situation (this
time with killing the systemd user process, which cascades into systemd
going on to a killing spree on the rest of the system), and maybe the
current log can shed some light here (see below). There, I've been
running earlyoom with `-EARLYOOM_ARGS="-r 3600 --avoid
'(^|/)(dbus-daemon)$' --prefer 'contentproc'`.

My I don't have logs of which process has used which amount of memory,
but my guess is that something outside earlyoom's reach has been growing
faster than the small game which earlyoom reached, and so it kept
killing process after process until it found systemd.

Does that help clear up things?

BR
chrysn

PS. When asking for additional information on the bts, consider
group-replying or replying to 1012870-submit...@bugs.debian.org, for
otherwise the mail will only reach users subscribed to the issue or
package, which does not include the original submitter by default.


Sep 16 08:31:30 hephaistos earlyoom[1694]: mem avail:  4073 of 15899 MiB 
(25.62%), swap free:9 of 16279 MiB ( 0.06%)
[... nothing earlyoom or memory related ... ]
Sep 16 08:56:08 hephaistos earlyoom[1694]: mem avail:  1554 of 15899 MiB ( 
9.78%), swap free:  401 of 16279 MiB ( 2.47%)
Sep 16 08:56:08 hephaistos earlyoom[1694]: low memory! at or below SIGTERM 
limits: mem 10.00%, swap 10.00%
Sep 16 08:56:08 hephaistos earlyoom[1694]: sending SIGTERM to process 
3874485 uid 1000 "goa-daemon": badness 800, VmRSS 8 MiB
Sep 16 08:56:08 hephaistos earlyoom[1694]: process exited after 0.1 seconds
Sep 16 08:56:08 hephaistos earlyoom[1694]: mem avail:  1568 of 15899 MiB ( 
9.87%), swap free:  407 of 16279 MiB ( 2.50%)
Sep 16 08:56:08 hephaistos earlyoom[1694]: low memory! at or below SIGTERM 
limits: mem 10.00%, swap 10.00%
Sep 16 08:56:08 hephaistos earlyoom[1694]: sending SIGTERM to process 
3892597 uid 1000 "gvfsd-metadata": badness 800, VmRSS 7 MiB
Sep 16 08:56:09 hephaistos earlyoom[1694]: process exited after 0.1 seconds
Sep 16 08:56:09 hephaistos earlyoom[1694]: mem avail:  1569 of 15899 MiB ( 
9.87%), swap free:  410 of 16279 MiB ( 2.52%)
Sep 16 08:56:09 hephaistos earlyoom[1694]: low memory! at or below SIGTERM 
limits: mem 10.00%, swap 10.00%
Sep 16 08:56:09 hephaistos earlyoom[1694]: sending SIGTERM to process 
3874498 uid 1000 "goa-identity-se": badness 800, VmRSS 7 MiB
Sep 16 08:56:09 hephaistos earlyoom[1694]: process exited after 0.1 seconds
Sep 16 08:56:09 hephaistos earlyoom[1694]: mem avail:  1559 of 15899 MiB ( 
9.81%), swap free:  412 of 16279 MiB ( 2.53%)
Sep 16 08:56:09 hephaistos earlyoom[1694]: low memory! at or below SIGTERM 
limits: mem 10.00%, swap 10.00%
Sep 16 08:56:09 hephaistos earlyoom[1694]: sending SIGTERM to process 
3873747 uid 1000 "dconf-service": badness 800, VmRSS 5 MiB
Sep 16 08:56:09 hephaistos earlyoom[1694]: process exited after 0.1 seconds
Sep 16 08:56:09 hephaistos earlyoom[1694]: mem avail:  1556 of 15899 MiB ( 
9.79%), swap free:  412 of 16279 MiB ( 2.53%)
Sep 16 08:56:09 hephaistos earlyoom[1694]: low memory! at or below SIGTERM 
limits: mem 10.00%, swap 10.00%
Sep 16 08:56:09 hephaistos earlyoom[1694]: memory situation has recovered 
while selecting victim
Sep 16 08:56:29 hephaistos earlyoom[1694]: mem avail:  1586 of 15899 MiB ( 
9.98%), swap free:  412 of 16279 MiB ( 2.53%)
Sep 16 08:56:29 hephaistos earlyoom[1694]: low memory! at or below SIGTERM 
limits: mem 10.00%, swap 10.00%
Sep 16 08:56:29 hephaistos earlyoom[1694]: sending SIGTERM to process 
3874500 uid 1000 "gvfs-afc-volume": badness 800, VmRSS 5 MiB
Sep 16 08:56:29 hephaistos systemd[2015]: gvfs-afc-volume-monitor.service: 
Consumed 3.200s CPU time.
Sep 16 08:56:29 hephaistos earlyoom[1694]: process exited after 0.1 seconds
Sep 16 08:56:29 hephaistos earlyoom[1694]: mem avail:  1495 of 15899 MiB ( 
9.41%), swap free:  392 of 16279 MiB ( 2.41%)
Sep 16 08:56:29 hephaistos earlyoom[1694]: low memory! at or below SIGTERM 
limits: mem 10.00%, swap 10.00%
Sep 16 08:56:29 hephaistos earlyoom[1694]: sending SIGTERM to process 
3874468 uid 1000 "gvfs-udisks2-vo": badness 800, VmRSS 5 MiB
Sep 16 08:56:29 hephaistos earlyoom[1694]: process exited after 0.1 seconds
Sep 16 08:56:29 hephaistos earlyoom[1694]: mem avail:  1527 of 15899 MiB ( 
9.60%), swap free:  371 of 16279 MiB ( 2.28%)
Sep 16 08:56:29 hephaistos earlyoom[1694]: low memory! at or below SIGTERM 
limits: mem 10.00%, swap 10.00%
Sep 16 08:56:29 hephaistos earlyoom[1694]: sending SIGTERM to process 
3892622 uid 1000 "gnome-keyring-d": badness 800, VmRSS 5

Bug#1016500: README.Debian documents KillUserProcesses but not Linger

[chrysn]

On Tue, Aug 02, 2022 at 08:30:48AM +0200, Michael Biebl wrote:
> We only document KillUserProcesses=yes in README.Debian as we deviate from
> the upstream defaults here.

The text does both: It documents the deviation and warns users of
possibly unexpected behavior.

> 
> > > The default Linger value for users is set to "no", and may need to be
> > > altered with `loginctl enable-linger ${USER}` to keep screen and tmux
> > > useful.
> 
> This reads like there would be a "Linger=yes/no" value in logind.conf, which
> is misleading.

Wording should be improved then; I didn't manage to find out where these
things are actually stored -- but let's look at whether a change is
indicated first:

> It is also incorrect, as you don't need to enable lingering if you want tmux
> to survive a log out (which was the reason for setting KillUserProcesses=no
> in Debian). Then again, I don't understand what you mean by "keep useful"?

It appears it does need to be enabled. At least that was the
recommendation in [1016475]. The original [946645], while confirming
that this happens, did not manage to find where precisely it is coming
from, but enabling lingering was a working fix.

I lack the big picture of all the interworking components around logind,
but the observation confirmed both in these issues and also outside of
Debian[1] ("To fix, do *all* of the following steps") is that at least
in some circumstances (such as when following the steps outlined in the
two referenced issues), just having KillUserProcesses=no is
insufficient.

BR
c

[1]: 
https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions
[946645]: https://bugs.debian.org/946645
[1016475]://bugs.debian.org/1016475

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#1016500: README.Debian documents KillUserProcesses but not Linger

[chrysn]

Package: systemd
Version: 251.3-1
Severity: normal
File: /usr/share/doc/systemd/README.Debian.gz

The README.Debian file duefully documents the surprising[1] effects that
happen when using tmux or similar under in a logind session. However, it
only covers the KillUserProcesses part of things (a mechanism that
Debian thankfully disables by default), and not the linger part, which
has a similar (if not the same) effect and is set to kill by default.

Suggested new text, based on the current one:

> KillUserProcesses and linger behavior in Debian
> ===
> 
> If KillUserProcesses=yes is configured in logind.conf(5), the session scope
> will be terminated when the user logs out of that session.
>
> Likewise, processes launched by users configured as Linger=no (see
> loginctl(1)) are terminated.
> 
> See logind.conf(5):
> 
> | Note that setting KillUserProcesses=yes will break tools like screen(1) and
> | tmux(1), unless they are moved out of the session scope.
> 
> The default for KillUserProcesses in /etc/systemd/logind.conf is set
> to "yes" in upstream systemd, though Debian defaults to "no" (see #825394).
>
> The default Linger value for users is set to "no", and may need to be
> altered with `loginctl enable-linger ${USER}` to keep screen and tmux
> useful.

[1]: https://bugs.debian.org/1016475


-- Package-specific info:

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

Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser3.123
ii  libacl12.3.1-1
ii  libaudit1  1:3.0.7-1+b1
ii  libblkid1  2.38-6
ii  libc6  2.33-8
ii  libcap21:2.44-1
ii  libcryptsetup122:2.5.0-1
ii  libfdisk1  2.38-6
ii  libgcrypt201.10.1-2
ii  libkmod2   30+20220630-3
ii  liblz4-1   1.9.3-2
ii  liblzma5   5.2.5-2.1
ii  libmount1  2.38-6
ii  libseccomp22.5.4-1+b1
ii  libselinux13.4-1+b1
ii  libssl33.0.5-1
ii  libsystemd-shared  251.3-1
ii  libsystemd0251.3-1
ii  libzstd1   1.5.2+dfsg-1
ii  mount  2.38-6

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]  1.14.0-2
ii  ntpsec [time-daemon]1.2.1+dfsg1-7+b1

Versions of packages systemd suggests:
ii  libfido2-11.11.0-1+b1
ii  libtss2-esys-3.0.2-0  3.2.0-1+b1
ii  libtss2-mu0   3.2.0-1+b1
ii  libtss2-rc0   3.2.0-1+b1
ii  policykit-1   0.105-33
pn  systemd-boot  
ii  systemd-container 251.3-1
pn  systemd-homed 
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.0-2
pn  dracut 
ii  initramfs-tools0.142
pn  libnss-systemd 
ii  libpam-systemd 251.3-1
ii  udev   251.3-1

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#1016475: tmux sessions do not persist through logout

[chrysn]

Package: tmux
Version: 3.3a-1
Severity: normal

Under some starting conditions (eg. "starting from an xterm in Gnome"),
the tmux server gets killed when the user logs off (or, more
practically, gets logged off by the X server crashing). This damages one
of tmux's strong points: keeping whatever is launched in it running no
matter how unstable the terminal connection is.

Steps to reproduce:

* In a fresh sid installation, start Gnome under X11 (Wayland not
  tested).
* Alt+F2, xterm
* tmux
* Ensure you recognize the screen again later on
* Log out
* Log in back again, open xterm again
* tmux attach: "no sessions" -- the session was killed

Note that this is sentitive to the precise way tmux is being launched;
for example, if gnome-terminal were used, things would behave as normal.
That indicates that there is something processes can do to protect
themselves from getting killed (possibly with cgroups involved).

I've originally reported this against systemd as
https://bugs.debian.org/946645 assuming it's an error in
`KillUserProcesses=no` (whose default has caused similar grief), but
maintainers there insist it's not about that. The issue and discussion
around it may have valuable material, also w/rt other things I've
tested.

Please enable tmux to persist in the rough desktop environment. If you
think that it's not tmux's fault but tmux sessions should still persist,
please reassign to where you think this should be fixed.


Thanks
chrysn

PS. The issue appears to also exist in 3.4, which I've tested for
unrelated reasons.

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

Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tmux depends on:
ii  libc62.33-8
ii  libevent-core-2.1-7  2.1.12-stable-5+b1
ii  libtinfo66.3+20220423-2
ii  libutempter0 1.2.1-2

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#1012870: defaults should include dbus-daemon

[chrysn]

Package: earlyoom
Version: 1.7-1
Severity: wishlist

The default settings, even when applying the suggestions, can easily
cause everything in a desktop session to be killed indirectly: I've
repeatedly seen dbus-daemon falling victim to earlyoom, which does
succeed in freeing a lot of memory, but has the side effect of taking
firefox, xfce4-terminal and a bunch of other processes down with it.

I suggest that dbus-daemon be included in the --avoid list offered in
/etc/default/earlyoom, and possibly even be enabled by default.

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages earlyoom depends on:
ii  init-system-helpers  1.62
ii  libc62.33-7
ii  lsb-base 11.1.0

earlyoom recommends no packages.

earlyoom suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#983410: i2p: new upstream

[chrysn]

retitle 983410 i2p: new upstream 1.8.0
thx

By now there have been several new releases, skipping from 0.9.50 to 15
and then following up to 1.8. There are several privacy 
(eg. DoH reseeding), performance (eg. X25519) and compatibility (eg.
IPv6 uPnP) improvements, as well as countless bug fixes.

Please consider updating the packaged version.

Thanks for maintaining the i2p package!
chrysn


signature.asc
Description: PGP signature

Bug#998462: Plugin fails to load

[chrysn]

Package: gedit-latex-plugin
Version: 3.20.0-2
Severity: important

When using this in sid or bookworm, when the plugin is enabled and a
.tex file opened, nothing happens and this shows up on stderr: 

Traceback (most recent call last):
  File "/usr/lib/gedit/plugins/latex/tabdecorator.py", line 87, in _on_load
self._adjust_editor()
  File "/usr/lib/gedit/plugins/latex/tabdecorator.py", line 107, in 
_adjust_editor
location = self._text_buffer.get_location()
AttributeError: 'Document' object has no attribute 'get_location'
Traceback (most recent call last):
  File "/usr/lib/gedit/plugins/latex/tabdecorator.py", line 95, in _on_save
if not self._adjust_editor():
  File "/usr/lib/gedit/plugins/latex/tabdecorator.py", line 107, in 
_adjust_editor
location = self._text_buffer.get_location()
AttributeError: 'Document' object has no attribute 'get_location'

Could there be an undeclared mismatch between the LaTeX plugin version
and gedit? (Gedit underwent something that looked like a major version
change since the plugin was last updated, maybe an API changed).

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gedit-latex-plugin depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  gedit40.1-2
ii  libglib2.0-bin   2.70.0-3
ii  python3  3.9.7-1
ii  python3-dbus 1.2.18-3
ii  python3-gi   3.42.0-1+b1
ii  rubber   1.6.0-2

Versions of packages gedit-latex-plugin recommends:
ii  texlive  2021.20210921-1

gedit-latex-plugin suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#995824: New version available (1.5.6)

[chrysn]

Source: ruby-kramdown-rfc2629
Severity: wishlist
File: /usr/bin/kramdown-rfc2629

The latest available version (1.5.6) is necessary for many recent
drafts, please consider updating the packages.

(I can't pinpoint the exact changes of what breaks where, as there is
some interdependency with xml2rfc too, but it's probably a smooth
upgrade).

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

Kernel: Linux 5.13.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#994459: libjs-jquery removed symlinked files

[chrysn]

Package: q2templates
Version: 2020.11.1+dfsg-1
Severity: normal

Running qiime like this produces an error:

| $ qiime demux summarize --i-data test.qza --o-visualization test.qzv
| /usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/__init__.py:36: 
UserWarning: h5py is running against HDF5 1.10.7 when it was built against 
1.10.6, this may cause problems
|   _warn(("h5py is running against HDF5 {0} when it was built against {1}, "
| /usr/lib/python3/dist-packages/skbio/util/_testing.py:15: FutureWarning: 
pandas.util.testing is deprecated. Use the functions in the public API at 
pandas.testing instead.
|   import pandas.util.testing as pdt
| Plugin error from demux:
|
|   
[('/usr/lib/python3/dist-packages/q2templates/templates/assets/js/jquery.min.js',
 '/tmp/qiime2-temp-worx3rub/q2templateassets/js/jquery.min.js', "[Errno 2] No 
such file or directory: 
'/usr/lib/python3/dist-packages/q2templates/templates/assets/js/jquery.min.js'")]

The critical part is the absence of
/usr/lib/python3/dist-packages/q2templates/templates/assets/js/jquery.min.js,
which is a broken symlink.

My `apt-file find` opined that libjs-jquery would have that file, but
since 3.5.1+dfsg+~3.5.5-4 these are not present any more.

As it's probably too late for node-jquery to Breaks: q2templates (or
should it still, for the next release?), the best fix to me seems to
bend the link over to the un-minified version; this is what fixed the
issue for me locally.


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

Kernel: Linux 5.13.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages q2templates depends on:
ii  libjs-bootstrap 3.4.1+dfsg-2
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  node-normalize.css  8.0.1-4
ii  python3 3.9.4-1
ii  python3-jinja2  2.11.3-1
ii  python3-pandas  1.1.5+dfsg-2
ii  python3-setuptools  52.0.0-4

q2templates recommends no packages.

q2templates suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#993582: `which` replacement is not usable for several years

[chrysn]

Package: debianutils
Version: 5.4-3
Severity: normal
File: /usr/bin/which

While the advertised replacement for `which` has been in shells for
ages, it is only in GNU Make 4.3 (released January 2020) that `command`
can be used, for otherwise Make is trying to be smart and fails in
surprising ways ([1] describes a RIOT incident caused by this).

Consequently, projects aiming for portability between Linux
distributions have no good alternative to `which` until Make < 4.3 has
been phased out of the major distributions. (For example, Ubuntu Feisty
ships an old Make).

In light of this, please reconsider the deprecation and removal
schedule.

[1]: https://github.com/RIOT-OS/RIOT/pull/16803#issuecomment-912458125

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

Kernel: Linux 5.13.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debianutils depends on:
ii  libc6  2.31-17

debianutils recommends no packages.

debianutils suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#993498: Checkinstall should use dpkg-shlibdeps

[chrysn]

Package: checkinstall
Version: 1.6.2+git20170426.d24a630-2
Severity: wishlist
Tags: upstream

When creating a deb on Debian using checkinstall (eg. to get a working
distributable version of software whose build dependencies are so
compilcated[1] it stands little chances in regular packaging), several
dependencies could be detected automatically using shlibdeps, as is done
eg. by debhelper dh_shlibdeps. When binaries are installed, that would
detect the necessary libc versions as well as any other shared libraries
the installed binaries depend on.

The correct dependency information would help both cleaning up the local
system (otherwise uninstalling the -dev packages might autoremove also
the libraries that are now depended on) and using it on a different
system (where now one has to read linker errors and add files on demand).

[1]: https://github.com/immunant/c2rust/issues/326


Minimal test case:

$ fakeroot checkinstall --pkgname test --default --install=no -- cp -a 
/usr/bin/ssh /bin
$ dpkg-deb --info test_20??-1_*.deb | grep Depends
(no results)

If shlibdeps were extracted, it should print at least something about
libc.

A minimal working example of how to arrive at the relevant shlibdeps is:

$ mkdir debian
$ touch debian/control
$ dpkg-shlibdeps /usr/bin/ssh
$ cat debian/substvars
shlibs:Depends=libc6 (>= 2.26), libgssapi-krb5-2 (>= 1.17), libselinux1 (>= 
3.1~), libssl1.1 (>= 1.1.0), zlib1g (>= 1:1.1.4)


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

Kernel: Linux 5.13.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages checkinstall depends on:
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  libc6   2.31-17
ii  sensible-utils  0.0.17

Versions of packages checkinstall recommends:
ii  make  4.3-4.1

Versions of packages checkinstall suggests:
ii  gettext  0.21-4

-- no debconf information


signature.asc
Description: PGP signature

Bug#790660: Closing this bug (BTS maintenance for src:linux bugs)

[chrysn]

> If you can reproduce it with
> 
> - the current version in unstable/testing
> - the latest kernel from backports
>
> please reopen the bug, see https://www.debian.org/Bugs/server-control
> for details.

Micha, can you? I don't have that hardware around any more.

BR
chrysn


signature.asc
Description: PGP signature

Bug#987815: MPTCP is not enabled

[chrysn]

Source: linux
Version: 5.10.28-1
Severity: wishlist


The current configuration does not enable the multipath TCP
functionality provided by the kernel through the MPTCP (and the
the-default MPTCP_IPV6) binary options.

These have been available since kernel version 5.6.

When enabled, user space applications can opt in to MPTCP behavior by
using the new IPPROTO_MPTCP; regular TCP connections are unaffected.

Applications using this are starting slowly (outside of the Apple
ecosystem where this has been in used for years to ensure smooth network
handovers), but having this available widely would make it easier for
application developers to verify MPTCP operation on systems where they
can't easily (or don't have the experience to) rebuild their kernel with
CONFIG_MPTCP=y.

Please consider enabling this feature.


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

Kernel: Linux 5.12.0-rc5 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#979542: gcc-riscv64-unknown-elf: Unable to use stdint.h

[chrysn]

Package: gcc-riscv64-unknown-elf
Version: 8.3.0.2019.08+dfsg-1
Followup-For: Bug #979542

I've also observed this when trying to use gcc-riscv64 with the RIOT
operating system, which (in contrast to Joel's initial report) sets a
lot of potentially-needed flags and gets tested with other versions of
the RISC-V GCC -- same result, the include_next fails.

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

Kernel: Linux 5.12.0-rc5 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-riscv64-unknown-elf depends on:
ii  binutils-riscv64-unknown-elf  2.32.2020.04+dfsg-2
ii  libc6 2.31-10
ii  libgcc-s1 [libgcc1]   10.2.1-6
ii  libgmp10  2:6.2.1+dfsg-1
ii  libmpc3   1.2.0-1
ii  libmpfr6  4.1.0-3
ii  libstdc++610.2.1-6
ii  zlib1g1:1.2.11.dfsg-2

gcc-riscv64-unknown-elf recommends no packages.

gcc-riscv64-unknown-elf suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#972508: RFP: julius -- a Roman themed city-building game compatible with Caesar III

[chrysn]

Package: wnpp
Severity: wishlist

* Package name: julius
  Version : 1.4.1
  Upstream Author : Bianca van Schaik
* URL : https://github.com/bvschaik/julius
* License : AGPL-3 with non-free (third-party) assets
  Programming Lang: C
  Description : a Roman themed city-building game compatible with Caesar III

julius is a city building game in which the player manages Roman cities
starting as a citizen managing building sites and water supply up to a
role as caesar managing a city like Massilia with all its different
classes of population, economy, entertainment and worship of the Gods.

The game is a gameplay and savegame compatible clone of the 1998 Sierra
game Caesar III. Playing it requires a copy of Caesar III.

---

This is *the* way to play Caesar III these days; gameplay is
indistinguishable (at least if it's been 20 years since you played the
original) while being usable on modern systems without the resolution or
platform limits of the past, and quality-wise in line with openttd or
openrct2 (although AFAICT it was developed from scratch and not from
decompiled binaries).

As the artwork is clearly nonfree and not even distributable in nonfree,
this is a case for contrib, and probably game-data-packager; innoextract
can already get the files. (If anyone ITPs or wants to do the g-d-p
work, I'm happy to sponsor a copy).

Building the game is rather straight-forward (cmake, SDL, libpng), I
figure the largest packaging effort will go into ensuring that /
checking whether savegames can go into a sane location in ~ when the
rest of the game files comes from whereever game-data-manager puts
things.

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#962654: pip fails to install cryptography on pypy3

[chrysn]

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.

As some things in the process spill out of the virtualenv (if you repeat
step env1 later as an env3, it will work -- something of the
cryptography installation spills to the outside), the steps to reproduce
are described using a cowbuilder:

$ sudo cowbuilder --create --distribution bullseye --basepath 
/var/cache/pbuilder/base-bullseye.cow
$ sudo cowbuilder --login --basepath /var/cache/pbuilder/base-bullseye.cow
# apt-get -y install build-essential python3-dev libssl-dev autoconf pypy3 
pypy3-dev python3-pip python3-virtualenv
# pip --version
pip 20.1.1 from /usr/lib/python3/dist-packages/pip (python 3.8)
# python3 -m virtualenv --python pypy3 /tmp/pypy3env1
# bash
# source /tmp/pypy3env1/bin/activate
(pypy3env1) # pip --version
pip 20.1.1 from /tmp/pypy3env1/site-packages/pip (python 3.6)
(pypy3env1) # pip install cryptography

> Collecting cryptography
>   Downloading cryptography-2.9.2.tar.gz (517 kB)
>  || 517 kB 1.7 MB/s 
>   Installing build dependencies ... done
>   Getting requirements to build wheel ... error
>   ERROR: Command errored out with exit status 1:
>command: /tmp/pypy3env1/bin/pypy3 
> /usr/share/python-wheels/pep517-0.8.2-py2.py3-none-any.whl/pep517/_in_process.py
>  get_requires_for_build_wheel /tmp/tmpe4kquiyd
>cwd: /tmp/pip-install-fv5voxu0/cryptography
>   Complete output (1 lines):
>   /tmp/pypy3env1/bin/pypy3: 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/pypy3env1/bin/pypy3 
> /usr/share/python-wheels/pep517-0.8.2-py2.py3-none-any.whl/pep517/_in_process.py
>  get_requires_for_build_wheel /tmp/tmpe4kquiyd Check the logs for full 
> command output.

(pypy3env1) # exit
# python3 -m virtualenv --python pypy3 /tmp/pypy3env2
# bash
# source /tmp/pypy3env2/bin/activate
(pypy3env2) # pypy3 -m pip install --force-reinstall pip
(pypy3env2) # pip --version
pip 20.1.1 from /tmp/pypy3env2/site-packages/pip (python 3.6)
(pypy3env2) # pip install cryptography

This succeeds and results in a working installation of cryptograph (as
well as -- as a note to anyone struggling with getting repeatable
results out of such a situation -- an artefact in ~/.local that causes
future runs to work even with the Debian pip).

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pip depends on:
ii  ca-certificates 20200601
ii  python-pip-whl  20.1.1-2
ii  python3 3.8.2-3
ii  python3-distutils   3.8.3-2
ii  python3-setuptools  46.1.3-1
ii  python3-wheel   0.34.2-1

Versions of packages python3-pip recommends:
ii  build-essential  12.8
ii  python3-dev  3.8.2-3

python3-pip suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#935814: PDF rendering bug in non-ASCII path is LyX-specific

[chrysn]

I've just stumbled over this after an upgrade to buster, and can provide
an additional datum that can also be used as a workaround:

While direct export to PDF via pdflatex is broken, the resulting TeX
file is fine. That means that you can export the LyX file to LaTeX
(pdflatex), and then from the command line invoke pdflatex on the file
to obtain a PDF.

(And to no surprise, it also affects german Umlauts).

Kind regards
chrysn


signature.asc
Description: PGP signature

Bug#959780: Insufficint dependency on readable-stream/writable

[chrysn]

Package: node-node-sass
Version: 4.13.1-3
Severity: normal
File: /usr/bin/node-sass

On my current sid system, a plain node-sass invocation results in:

guest@hephaistos:/tmp$ node-sass
internal/modules/cjs/loader.js:638
throw err;
^

Error: Cannot find module 'readable-stream/writable'
at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. 
(/usr/lib/x86_64-linux-gnu/nodejs/node-sass/node_modules/stdout-stream/index.js:2:16)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)

The node-readable-stream is installed as a depdendency (see below), but
still something internal seems not to find it.

A strace shows that node is looking for a file
/usr/lib/nodejs/readable-stream/writable.js that was present in
node-readable-stream 2.3.6-1 but is not in 3.4.0-2. (But I was not
successful in installing the stable package on the sid system as things
break in other places then.

I tried to track down the offending stdout-stream file to the upstream
sources, and found that the part that causes the dependency breakage
witht the newer readable-stream is not in the master source itself but
in stdout-stream that gets pulled in through debian/watch as a ...
dunno, shipped dependency?

From looking into what exists as latests versions, I don't quite see how
this can work for anyone (given that node-sass requires stdout-stream
^1.4.0 even in the latest version, and the latest stdout-sream is 1.4.1
which still uses readable-stream/writable which in term is absent from
the latest release. As a partial workaround, I've removed all std-stream
references from a local copy of the package (debian/gbp.conf,
package.json, bin/node-sass both the dependency and the single logging
use of stdout) -- just to end up with the same errors I got when I had
the older node-readable-stream installed, indicating that there might be
an unrelated different issue (then in node-read-pkg) waiting after this
is resolved.

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

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

Versions of packages node-node-sass depends on:
ii  libc6 2.30-4
ii  libgcc-s1 10-20200418-1
ii  libnode64 10.20.1~dfsg-1
ii  libstdc++610-20200418-1
ii  node-chalk2.4.2-1
ii  node-cross-spawn  5.1.0-2
ii  node-get-stdin6.0.0-1
ii  node-glob 7.1.6-1
ii  node-globule  1.3.0-1
ii  node-gyp  6.1.0-3
ii  node-lodash   4.17.15+dfsg-2
ii  node-meow 3.7.0-1
ii  node-mkdirp   0.5.1-2
ii  node-nan  2.14.0-1
ii  node-npmlog   4.1.2-2
ii  node-readable-stream  3.4.0-2
ii  node-request  2.88.1-4
ii  node-source-map   0.7.0++dfsg2+really.0.6.1-4
ii  node-yargs15.3.0-1
ii  nodejs10.20.1~dfsg-1

node-node-sass recommends no packages.

node-node-sass suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#930990: python*-bluez includes unusuable ble module

[chrysn]

What makes the situation trickier is that both the gattlib undeclaredly
depended on here and the alternative pygatt (see #939619) just wrap the
gatttool program, which is deprecated by the bluez project (not much
info out there, https://github.com/peplin/pygatt/issues/112 gives a good
summary).

While making gattlib available in Debian might solve the issue on the
short term, it might be worth looking for more current alternatives
instead; I don't clearly see one yet though.

Bug#953109: Recommend [check-valid-until=no] by default

[chrysn]

Package: snapshot.debian.org
Severity: minor
Tags: patch

With the last unsupporting version being oldoldstable,
[check-valid-until=no] should be in the sources.list line everyone[1]
copies over.

I've pushed a version with a suggested fix to
https://salsa.debian.org/chrysn-guest/snapshot/-/tree/default-check-valid-until
for easy merging, or attached as a patch if that better suites your
workflow.

[1] Well, I do. Just spent yet another run of changing / etckeeper
committing / apt update where I should really have known but mindlessly
copy-pasted anyway.

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

Kernel: Linux 5.6.0-rc2 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom
From 1264f8c9f59edb67bac0cd3d8dc237472b9e8b93 Mon Sep 17 00:00:00 2001
From: chrysn 
Date: Wed, 4 Mar 2020 17:47:30 +0100
Subject: [PATCH] Advertise [check-valid-until=no] by default

With all recent Debian versions supporting it, the recommendation can go
into what is most commonly copy-pasted, with just a note on older
versions.
---
 web/app/snapshot/templates/description.mako | 28 -
 1 file changed, 10 insertions(+), 18 deletions(-)

diff --git a/web/app/snapshot/templates/description.mako b/web/app/snapshot/templates/description.mako
index 294fb32..12513b0 100644
--- a/web/app/snapshot/templates/description.mako
+++ b/web/app/snapshot/templates/description.mako
@@ -54,10 +54,10 @@ If you want to add a specific date's archive to your apt sources.list
 
-deb https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
-deb-src https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
-deb https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
-deb-src https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
+deb [check-valid-until=no] https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
+deb-src [check-valid-until=no] https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
+deb [check-valid-until=no] https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
+deb-src [check-valid-until=no] https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
 
 
 To access snapshots using https, you need to install the ca-certificates
@@ -73,21 +73,13 @@ is no import at the exact time you specified you will get the latest
 available timestamp which is before the time you specified.
 
 
-To access snapshots of suites using Valid-Until that are older than a dozen days,
-it is necessary to ignore the Valid-Until header within Release files, in order
-to prevent apt from disregarding snapshot entries ("Release file expired").  Use
-aptitude -o Acquire::Check-Valid-Until=false update or
-apt-get -o Acquire::Check-Valid-Until=false update for this purpose.
-
-
-If you use at least apt version 1.1.exp9 (stretch and later), you can use this instead:
+The [check-valid-until=no] option is necessary to access suites
+older than a dozen days, as their Valid-Until header has expired.
+If you use apt versions before 1.1.exp9 (jessie and older), you have to elide
+the option and use aptitude -o Acquire::Check-Valid-Until=false
+update or apt-get -o Acquire::Check-Valid-Until=false
+update instead.
 
-
-deb [check-valid-until=no] https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
-deb-src [check-valid-until=no] https://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
-deb [check-valid-until=no] https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
-deb-src [check-valid-until=no] https://snapshot.debian.org/archive/debian-security/20091004T121501Z/ lenny/updates main
-
 
 
 If you want anything related to a specific package simply enter the
-- 
2.25.1



signature.asc
Description: PGP signature

Bug#946645: KillUserProcesses=no disregarded for some cgroups

[chrysn]

> Maybe we should first get to the bottom of your issue before jumping to
> conclusions and producing incorrect/incomplete documentation.

Happily so.

Right now I don't really know how to test this better (as in to get
usable data that'll get us on), let alone how to test this well (as in
without logging in and out of a virtual machine 2x5 times to get one or
two cases of observable behavior).

Any ideas on what more data I could pull out?

chrysn


signature.asc
Description: PGP signature

Bug#946645: KillUserProcesses=no disregarded for some cgroups

[chrysn]

On Mon, Feb 10, 2020 at 03:04:49PM +0100, Ansgar wrote:
> If I start an xterm via Alt-F2 in gnome, the xterm process runs in a
> cgroup like gnome-launched-xterm-489694.scope.  gnome-terminal or an
> xterm started in gnome-terminal run in the gnome-terminal-
> server.service cgroup.  I expect openbox doesn't do this and processes
> started by openbox run in the same cgroup as openbox itself.
> 
> `systemd-cgls` is useful to see how processes are organized into
> cgroups.
> 
> The gnome-launched-*.scope has KillMode=control-group, so all processes
> including background processes like tmux get killed when the unit gets
> stopped (systemd --user show -p KillMode gnome-launched-scope).

That does not explain the on-and-off behavior, but helps in
understanding why processes get killed in the first place.

Then, however, is KillUserProcesses completely obsolete? A user trying
to debug a situation like mine will currently wind up in the discussion
of #825394 and look into KillUserProcesses' documentation. Even if it's
not completely obsolete, a warning that desktop environment spawned
processes might also be subject to killing from their desktop
environment's KillMode would be helpful.

Kind regards
chrysn


signature.asc
Description: PGP signature

Bug#946645: KillUserProcesses=no disregarded for some cgroups

[chrysn]

On Mon, Feb 10, 2020 at 11:25:29AM +0100, Michael Biebl wrote:
> I assume your GNOME session is managed by systemd --user, i.e.
> gnome-session is modelled around systemd --user.
> 
> Might be that is gnome-session that triggers the cleanup of the
> session/processes.
> 
> You could try with a more minimal desktop session, like openbox, and
> start tmux in a xterm there and test if that survices a logout (it should)

In openbox, I could indeed not reproduce this behavior in the sid system
(Opening xterm via right-click / system / xterm, logging out via
right-click / ...) on a first attempt.

In the similarly simple i3wm (where I also saw it on my production
machine; in the sid VM I open the terminal using Win-D; logging out
using Win-Shift-E), the behavior happens on and off: I've seen it in 2
of 8 attempts (all with reboots inbetween).

Even on Gnome, when testing again after the first openbox failures, I
found the behavior to be on and off (seen in 2 out of 3 attempts), all
with no discernable patterns to it.

This is a bug in the bad area of happening often enough to not give up
on it, but erratically enough to place me at a loss on how to provide
better reproducibility to dig down :-/

Kind regards
chrsyn


signature.asc
Description: PGP signature

Bug#946645: KillUserProcesses=no disregarded for some cgroups

[chrysn]

found 946645 244.2-1
stop

On Sun, Jan 26, 2020 at 01:29:38AM +0100, Michael Biebl wrote:
> This works fine for me, so I can not reproduce the issue with the given
> information.
>
> Do you have libpam-systemd installed and enabled?

Yes, libpam-systemd is installed, and the line `session optional
pam_systemd.so` in /etc/pam.d/common-session was not modified (I'm using
a virtual machine that had Buster's installer run and upgraded to sid,
otherwise nothing in /etc was changed manually).

To reproduce on a current system, I've upgraded the the VM's systemd
from 243-8 to 244.2-1, and even the complete system to today's state.
The behavior is still as described in the original report. For sake of
completeness, it is (and has been) running gdm3.

Is there any particular VM implementation you tried the reproduction,
such that I can retry on that? (I don't really think it's the VM itself,
but it might make it easier to compare results.)

Kind regards
chrysn


signature.asc
Description: PGP signature

Bug#949131: New version 1.12 fixes heuristics bugs

[chrysn]

Source: modemmanager
Severity: normal

Hello modemmanager maintainers,

I've tested version 1.12.4 of modemmanager in the context of supporting
updated heuristics that won't snatch embedded developers' serial
terminals in some situations[164].

Steps I had to do to get 1.12 running:

* uscan in the new package
* Disable libQMI (--without-qmi; would need 1.24, so for a full
  modemmanager 1.12 libqmi will need updating as well)
* Rip out gensymbols (I just needed to verify that [164] can be solved
  in 1.12).

With that, I got a ModemManager that indeed did not display the
problem[164] of the 1.10 version any more. (I couldn't verify that it
all *works* as I don't have a modem, but it did probe the USB device I
built to mimick a modem during [164] verification).

Some bycatch from when I tried to find the QMI build error:

* --with-suspend-resume=systemd is now --with-systemd-suspend-resume=yes
  (the old config option went away in 1.8, and has now raised a
  warning).

Kind regards
chrysn


[164]: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/164

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

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

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#949129: vcs-git outdated

[chrysn]

Source: modemmanager
Severity: minor

Hello modemmangager maintainers,

it seems the Vcs-Git/-Web entries for ModemManager are outdated -- they
point o salsa.d.o/cyphermox-guest/modemmanager, but all that's there is
1.7.x when 1.10 has already seen maintainer uploads.

Please keep the git version current or point Vcs-Git to where the
current one is.

(Background: I was about to test 1.12 as it probably fixes a heuristics
bug[164], but it's hard to get tests started from dont-know-where).

Thanks
chrysn

[164]: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/164

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

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

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#949128: New version available (19.3.1)

[chrysn]

Package: python3-pip
Version: 18.1-5
Severity: normal

The new version 19.3.1 is available and would fix #947069 (as well as
any follow-up that'd raise the same problem about manylinux2014).

I've attempted to update the package quickly myself (just a `gbp
import-dsc --uscan` and patch cleanup), but found that `python3 -m
venv /tmp/testpath` does not work with that alone (it gives:

> The virtual environment was not created successfully because ensurepip is not
> available.  On Debian/Ubuntu systems, you need to install the python3-venv
> package using the following command.
>
> apt-get install python3-venv
>
> You may need to use sudo with that command.  After installing the python3-venv
> package, recreate your virtual environment.
>
> Failing command: ['/tmp/testpath/bin/python3', '-Im', 'ensurepip', 
> '--upgrade', '--default-pip']

so the update needs to be done by someone who understands what's going
on and not blindly follows the last error message of dpkg).

Still, I've had to refresh the patches to get into a working state.
The refershings (patches attached) will need review (and are commented
for that), but I still hope they save you a few minutes.

Bes regards
chrysn


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

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

Versions of packages python3-pip depends on:
ii  ca-certificates20190110
ii  python-pip-whl 19.3.1-1
ii  python33.7.5-3
ii  python3-distutils  3.8.0-1
ii  python3.8  3.8.1-2

Versions of packages python3-pip recommends:
ii  build-essential 12.8
ii  python3-dev 3.7.5-3
ii  python3-setuptools  44.0.0-1
ii  python3-wheel   0.33.6-2

python3-pip suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom
From 7ae3b61c128bf46a8855b40004528cd321103d14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20M=2E=20Ams=C3=BCss?= 
Date: Fri, 17 Jan 2020 08:53:44 +0100
Subject: [PATCH 1/4] Refresh hands-off-system-packages.patch

This refreshment is slightly incomplete as upstream added  note about
normalization requirements on the paths (which the patched version does
not assume); that will need to be reviewed by someone who knows the
original intentions or more context.
---
 debian/patches/hands-off-system-packages.patch | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/debian/patches/hands-off-system-packages.patch b/debian/patches/hands-off-system-packages.patch
index 564a266..ef28a6c 100644
--- a/debian/patches/hands-off-system-packages.patch
+++ b/debian/patches/hands-off-system-packages.patch
@@ -17,13 +17,11 @@ Last-Update: 2014-12-04
 Patch-Name: hands-off-system-packages.patch
 ---
 
-Index: python-pip/src/pip/_internal/utils/misc.py
-===
 python-pip.orig/src/pip/_internal/utils/misc.py
-+++ python-pip/src/pip/_internal/utils/misc.py
-@@ -289,22 +289,40 @@ def renames(old, new):
- 
+--- a/src/pip/_internal/utils/misc.py
 b/src/pip/_internal/utils/misc.py
+@@ -348,25 +348,42 @@
  def is_local(path):
+ # type: (str) -> bool
  """
 -Return True if path is within sys.prefix, if we're running in a virtualenv.
 +Return True if this is a path pip is allowed to modify.
@@ -39,11 +37,12 @@ Index: python-pip/src/pip/_internal/utils/misc.py
 +and the domain of the OS vendor. (In other words, everything _other
 +than_ sys.prefix is considered local.)
  
+ Caution: this function assumes the head of path has been normalized
+ with normalize_path.
  """
 -if not running_under_virtualenv():
 -return True
--return normalize_path(path).startswith(normalize_path(sys.prefix))
-+
+-return path.startswith(normalize_path(sys.prefix))
 +path = normalize_path(path)
 +prefix = normalize_path(sys.prefix)
 +
@@ -61,6 +60,7 @@ Index: python-pip/src/pip/_internal/utils/misc.py
  
  
  def dist_is_local(dist):
+ # type: (Distribution) -> bool
  """
 -Return True if given Distribution object is installed locally
 -(i.e. within current virtualenv).
-- 
2.25.0.rc2

From 982000b6803625f9796c91d380a5c54c23543e0e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20M=2E=20Ams=C3=BCss?= 
Date: Fri, 17 Jan 2020 09:09:22 +0100
Subject: [PATCH 2/4] Regular p

Bug#948951: libpam-gnome-keyring README suggests adding to other xDMs where already present

[chrysn]

Package: libpam-gnome-keyring
Version: 3.34.0-1
Severity: minor
File: /usr/share/doc/libpam-gnome-keyring/README.Debian

The README.Debian in for libpam-gnome-keyring states that GDM integrates
it into its PAM config, but it needs to be added manually for other DMs.

Currently, at least lightdm ships config for it, as do (according to
code search[1]) LXDM and SDDM.

Suggested text to replace the README body:

> The default PAM configurations for GDM, gnome-screensaver and several
> other display managers and screensavers already use pam_gnome_keyring.
> Password change is also implemented through the global PAM
> configuration.
> 
> If you want to start gnome_keyring from addiional display managers, you
> need to add the following lines to the corresponding /etc/pam.d/?dm
> file:

[1]: 
http://codesearch.debian.net/search?q=pam_gnome_keyring.so&literal=1&perpkg=1

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

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

Versions of packages libpam-gnome-keyring:amd64 depends on:
ii  libc6   2.29-8
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5
ii  libselinux1 3.0-1

Versions of packages libpam-gnome-keyring:amd64 recommends:
ii  gnome-keyring  3.34.0-1

libpam-gnome-keyring:amd64 suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#946645: KillUserProcesses=no disregarded for some cgroups

[chrysn]

Package: systemd
Version: 244-3
Severity: normal
File: /usr/share/man/man5/logind.conf.5.gz

The documentation about KillUserProcesses claims that processes will be
left alive after user logout when set to "no", and specifically mentions
tmux as one application.

This is only correct under some circumstances (apparently related to
cgroups, but I'm not familiar enough with them to give good details).
The observed issue is as follows:

* In a fresh sid installation, start Gnome under X11 (Wayland not
  tested).
* Alt+F2, xterm
* tmux
* Ensure you recognize the screen again later on
* Log out
* Log in back again, open xterm again
* tmux attach: "no sessions" -- the session was killed

In comparison, when `gnome-terminal` is used to start the tmux session,
it does survive the logout.

In drilling down to finding the difference at all (a process that seemed
very random to me in #945540, when I failed to take the terminal program
used into consideration), I noticed that the cgroups involved depended
on the terminal used: With xterm (or xfce4-terminal), the process seems
to be launched with cgroups pids, memory, name and "" in
/user.slice/user-$UID.slice/session-$SESSION.scope, whereas a surviving
tmux has its "", name and memory cgroups set to
/user.slice/user-$UID.slice/user@$UID.service/gnome-terminal-server.service
and the pids to /user.slice/user-$UID.slice/user@$UID.service.

It seems to me that processes under session-$SESSION.scope do get reaped
(whether deliberately killed by logind or somehow implicily by their
cgroups going away) at logout, and only those staretd from a program
that happens to switch cgroups survive.

Please change logind behavior to allow for all processes spawned in a
login session to survive, or if that is not possible, describe in the
KillUserProcesses which processes have a chance to survive.


For now, a usable workaround for me is to `systemd-run --user --scope
tmux` instead of tmux, but that's a workaround nobody should need to
use, especially as finding the need to do so usually involves having
lost one's tmux sessions over an X server crash before.

Thanks
chrysn


(Information down here relates to my production system where I've
reproduced the steps above with i3 instead of gnome).

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

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (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-6
ii  libcap2  1:2.27-1
ii  libcryptsetup12  2:2.2.2-1
ii  libgcrypt20  1.8.5-3
ii  libgnutls30  3.6.10-5
ii  libgpg-error01.36-7
ii  libidn2-02.2.0-2
ii  libip4tc21.8.4-1
ii  libkmod2 26-3
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  2.9-3+b1
ii  libsystemd0  244-3
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.135
ii  udev 244-3

-- no debconf information

Bug#850541: s/Python 2/Python 3/

[chrysn]

With its Python 3 port merged[1], whipper will not depend on Python 2
any more in the next release (probably 0.9). This should make packaging
a lot easier.

[1]: https://github.com/whipper-team/whipper/pull/411


signature.asc
Description: PGP signature

Bug#945540: tmux processes killed when Xorg exits uncleanly

[chrysn]

Package: systemd
Version: 243-6
Severity: normal

When Xorg is closed forcibly on my machine (I noticed when it probably
crashed, but for reproduction `sudo pkill -KILL`ed it), all the logged
in user's processes get killed, as observed in a running `tmux` session.

For comparison (and in accordance with the default
KillUserProcesses=no), if the X window manager (i3wm in my case) exits
cleanly, the tmux session is kept alive.

(When reproducing, make sure using `loginctl` / `loginctl session-status
$OLDER_SESSION_ID` that your current tmux session is not part of an
older logind session; that'd keep it from being terminated).

journalctl shows the following around an Xorg termination:

Nov 26 14:43:36 hephaistos sudo[1757962]: pam_unix(sudo:session): session 
opened for user root by chrysn(uid=0)
Nov 26 14:43:36 hephaistos sudo[1757962]: pam_unix(sudo:session): session 
closed for user root
Nov 26 14:43:36 hephaistos at-spi-bus-launcher[1998]: X connection to :0 broken 
(explicit kill or server shutdown).
Nov 26 14:43:36 hephaistos systemd[1]: session-2017.scope: Killing process 
1757746 (lightdm) with signal SIGTERM.
Nov 26 14:43:36 hephaistos systemd[1]: session-2017.scope: Killing process 
1757885 (tmux: server) with signal SIGTERM.
Nov 26 14:43:36 hephaistos systemd[1]: session-2017.scope: Killing process 
1757886 (zsh) with signal SIGTERM.
Nov 26 14:43:36 hephaistos systemd[1]: Stopping Session 2017 of user chrysn.
Nov 26 14:43:36 hephaistos systemd[1]: session-2017.scope: Succeeded.
Nov 26 14:43:36 hephaistos systemd[1]: Stopped Session 2017 of user chrysn.
Nov 26 14:43:36 hephaistos systemd-logind[1291]: Removed session 2017.

Setting a user to linger using `loginctl enable-linger` had no
observable effect on that behavior -- and anyway, `loginctl
show-session` displays `KillUserProcesses=no`.

The behavior was different on a fresh Buster installation with only tmux
installed additionally (both `sudo pkill -KILL wayland` and logging out
killed tmux, even though KillUserProcesses=no, but enable-linger
prevented killing in both cases). With linger disabled agani and "Gnome
on Xorg" as login session, the tmux session survived even a KILL Xorg,
as it did with the later installed and tried i3wm. That behavior did not
change after an upgrade to sid either (tested with i3 and KILL), so it
stands to assume that there is some property my system has gotten in the
upgrade path from an original sid installation in August 2018 that led
there. (I did no conscious change to the KillUserProcesses settings, and
etckeeper shows no change either since the original setup).

There's a lot of packages involved, so please let me know if you need
any data if only to assign it right, but the log lines of systemd
killing processes hopefully justify this initial assignment.

-- Package-specific info:

(Just in case it's relevant:)

$ systemd-delta
[MASKED] /etc/systemd/system/iodined.service → 
/lib/systemd/system/iodined.service
[EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
[EXTENDED]   /lib/systemd/system/systemd-resolved.service → 
/lib/systemd/system/systemd-resolved.service.d/resolvconf.conf
[EXTENDED]   /lib/systemd/system/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

4 overridden configuration files found.

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (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-6
ii  libaudit11:2.8.5-2
ii  libblkid12.34-0.1
ii  libc62.29-3
ii  libcap2  1:2.27-1
ii  libcryptsetup12  2:2.2.2-1
ii  libgcrypt20  1.8.5-3
ii  libgnutls30  3.6.10-4
ii  libgpg-error01.36-7
ii  libidn2-02.2.0-2
ii  libip4tc21.8.3-2
ii  libkmod2 26-3
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.32-5+b1
ii  libseccomp2  2.4.2-1
ii  libselinux1  2.9-3
ii  libsystemd0  243-6
ii  mount2.34-0.1
ii  util-linux   2.34-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-2
ii  libpam-systemd  243-6

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.135
ii  udev 243-6

-- no de

Bug#936132: arandr: new upstream release - python3 port

[chrysn]

> > Version 0.1.10
> > * Ported to Python 3 and PyGObject (by actionless)

Indeed; I just didn't get around to uploading a new version with it yet;
working on it now.

chrysn


signature.asc
Description: PGP signature

Bug#932741: merge conflict markers in man page

[chrysn]

Package: glances
Version: 3.1.0-1
Severity: minor

Calling `man glances` shows this:


  GLANCES(1)  Glances  GLANCES(1)

  <<< HEAD ===

  GLANCES(1)  Glances  GLANCES(1)

  >>> master

  NAME
 glances - An eye on your system

The bug was fixed upstream in [1] which appears to be the very commit on
which version 3.1.0 was tagged, so I don't quite understand how it got
into the Debian version 3.1.0-1 -- at any rate, this will be trivially
resolved with the next upstream version.

[1]: 
https://github.com/nicolargo/glances/commit/b668b0bf4c54d082538f938f52f3093543fdd693#diff-828e2a33d17aace28cc6eb30d4b12b67

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

Kernel: Linux 5.0.0-trunk-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages glances depends on:
ii  adduser3.118
ii  lsb-base   10.2019051400
ii  node-normalize.css 8.0.1-3
ii  python33.7.3-1
ii  python3-pkg-resources  41.0.1-1
ii  python3-psutil 5.5.1-1

Versions of packages glances recommends:
ii  hddtemp 0.3-beta15-53
ii  lm-sensors  1:3.5.0-3
ii  python3-bottle  0.12.15-2
ii  python3-docker  3.4.1-4
ii  python3-influxdb5.2.0-1
ii  python3-matplotlib  3.0.2-2
ii  python3-netifaces   0.10.4-1+b1
ii  python3-pysnmp4 4.4.6+repack1-1
ii  python3-pystache0.5.4-6

Versions of packages glances suggests:
pn  glances-doc  

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#928648: Sessions do not survive X restart under some conditions

[chrysn]

Package: tmux
Version: 2.9a-1
Severity: normal

In 2.9a-1 and 2.8-3, the following procedure resulted in tmux sessions
not surviving an X restart (which is my primary use case for tmux):

* Use a fresh user
* Log in to an i3 window manager session (when prompted, press enter)
* Win-d, enter xterm
* run tmux
* From a different console, restart lightdm
* Log in again and open a terminal again
* `tmux attach` finds "no sessions"

At the same time, using gnome-terminal instead of xterm results is in
survival of the tmux session, as it should always do.

Variations I've tried:

* XFCE as a window manager: same behavior (press Alt-F2 rather than
  Win-d)
* TWM shells (whatever terminal emulator their desktop menu spawns)
  behave like gnome-terminal (session survives)
* Logging out instead of restarting lightdm: tmux always survives
  (logout is Win-Shift-e on i3, or in the top-left menu in XFCE)
* entering Alt-Print-K (SysRQ SAK) instead of restarting lightdm: same
  behavior

For comparison, I've also tried whether a SAK on a terminal kills the
tmux session: It does (when with tmux launched on console 2 and attached
on console 3, a SAK on either console takes down the whole session); I
think it should not (cf. kernel Documentation/SAK.txt), but I'm not sure
how relevant this is to the above case of depending on the chosen
terminal emulator to survive an X lockup.

In case there is no obvious cause for this, is there any additional
testing I can provide?


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

Kernel: Linux 5.0.0-trunk-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tmux depends on:
ii  libc6   2.28-10
ii  libevent-2.1-6  2.1.8-stable-4
ii  libtinfo6   6.1+20181013-2
ii  libutempter01.1.6-3

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#924006: Recommend python3-watchdog to enable `-w` flag

[chrysn]

Package: darkslide
Version: 4.0.1-1
Severity: normal

When invoked with the `-w` (`--watch`) option to continuously update the
output on input file changes, darkslide builds once and then produces:

Error: The watchdog module must be installed to use the -w option   
  
As this is a regular (and useful) flag, please consider adding
python3-watchdog to Recommends.

Thanks
chrysn

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

Kernel: Linux 4.20.0-trunk-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages darkslide depends on:
ii  python3   3.7.2-1
ii  python3-docutils  0.14+dfsg-4
ii  python3-jinja22.10-1
ii  python3-markdown  3.0.1-3
ii  python3-pygments  2.3.1+dfsg-1
ii  python3-qrcode6.1-1
ii  python3-six   1.12.0-1

darkslide recommends no packages.

darkslide suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/darkslide/parser.py (from 
darkslide package)
(reporter note: This is for fixing #923977)

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#923977: Fails with python3-markdown >= 3

[chrysn]

Package: darkslide
Version: 4.0.1-1
Severity: important
Forwarded: https://github.com/ionelmc/python-darkslide/issues/10

There was a non-backwards compatible change in python3-markdown version
3 (allegedly; it happened on my system with the below dependencies
installed) that makes conversion from markdown fail like this:

$ darkslide slides.md
Adding   'slides.md' (markdown)
Error: markdown() takes 1 positional argument but 2 were given

This has already been reported upstream at
https://github.com/ionelmc/python-darkslide/issues/10, and can be fixed
by setting line 60 of parser.py to

return markdown.markdown(text, extension=self.md_extensions)

as suggested by the github reporter.

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

Kernel: Linux 4.20.0-trunk-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages darkslide depends on:
ii  python3   3.7.2-1
ii  python3-docutils  0.14+dfsg-4
ii  python3-jinja22.10-1
ii  python3-markdown  3.0.1-3
ii  python3-pygments  2.3.1+dfsg-1
ii  python3-qrcode6.1-1
ii  python3-six   1.12.0-1

darkslide recommends no packages.

darkslide suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/darkslide/parser.py (from 
darkslide package)

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#921751: python-rdflib-tools: CVE-2019-7653: Code injection from current working directory working directory

[chrysn]

> So it was somehow moved but definitely to a wrong location (that should
> be rather python-team/modules/rdflib).

yes, that was a mistake when moving the module and is now fixed.

> I used to be member of the DPMT group back on Alioth[2], can you add me on
> salsa? Then I can make the package ready for sponsor-upload-from-git
> once moved.

I've incorporated the changes from the move and an update to
standards-version, and set the changelog to indicate release readiness.
Would you sponsor the latest version (81346975) of [1] to close this
issue?

Thanks
Christian

[1]: https://salsa.debian.org/python-team/modules/rdflib


signature.asc
Description: PGP signature

Bug#921751: python-rdflib-tools: CVE-2019-7653: Code injection from current working directory working directory

[chrysn]

On Fri, Feb 15, 2019 at 09:11:11AM +0100, Andreas Tille wrote:
> On Thu, Feb 14, 2019 at 05:24:48PM +0100, chrysn wrote:
> > 
> > I can't directly push to the source right now (but have a PR pending at
> > [1]) and can't upload (as I don't have DMUA on that package).
> 
> Hmmm, I can not merge either.  What about moving that repository to
> Debian Python Modules team?

That's odd given you created the repo – but yes, I'm fine with it being
in DPMT as well, and will request it transferred (that'll only work via
the alioth admins).

I used to be member of the DPMT group back on Alioth[2], can you add me on
salsa? Then I can make the package ready for sponsor-upload-from-git
once moved.

Thanks
Christian

[2]: https://lists.debian.org/debian-python/2016/11/msg00048.html


signature.asc
Description: PGP signature

Bug#921751: python-rdflib-tools: CVE-2019-7653: Code injection from current working directory working directory

[chrysn]

On Sat, Feb 09, 2019 at 05:13:07AM +0100, Salvatore Bonaccorso wrote:
> For those following the bug, this likely does not affect the upstream
> project itself and is Debian specifc, as the Debian packaging AFAICS
> replaces the respective scripts/tools by wrappers invoking python -m
> as described by Gabriel (please correct me if I'm wrong).

I've updated the package's source to avoid the issue by using the
wrappers that setup.py/easy_install provides rather than making our own
in Debian.

I can't directly push to the source right now (but have a PR pending at
[1]) and can't upload (as I don't have DMUA on that package).

Andreas or Ondřej, could you do pull that in and do a team upload on
this? (I can prepare a full DM upload to be sponsered, but it's my
impression that team uploads are the easier way to go about this now).

Best regards
Christian

[1]: https://salsa.debian.org/debian/rdflib/merge_requests/1


signature.asc
Description: PGP signature

Bug#919872: new magic: HDT (RDF) files

[chrysn]

Package: file
Version: 1:5.35-2
Severity: wishlist

There exists a compact binary format for semantic web data following the
RDF (Resource Description Format) that is called HDT.

The format is described at [1], and example data is available at [2];
its media type is registered at [3].

A working rule set for those files I'd suggest is:

0 string $HDT HDT file (binary compressed indexed RDF triples)
!:mime application/vnd.hdt

I'm not sure whether `file` keeps track of common file extensions; if
it's relevant: such files typically have names ending with `.hdt`.

[1]: http://www.rdfhdt.org/hdt-internals/
[2]: http://gaia.infor.uva.es/hdt/swdf-2012-11-28.hdt.gz
[3]: https://www.iana.org/assignments/media-types/application/vnd.hdt


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

Kernel: Linux 4.20.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages file depends on:
ii  libc6  2.28-5
ii  libmagic1  1:5.35-2
ii  zlib1g 1:1.2.11.dfsg-1

file recommends no packages.

file suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#917262: virtualbox-source: Module FTBFS on Linux 4.20 undeclared ktime_get_real_ts

[chrysn]

Package: virtualbox-source
Version: 5.2.22-dfsg-2
Followup-For: Bug #917262

I just patched an (installed) version of virtualbox-source with the
mentioned changesets (picking files manually as the file paths don't
agree). They applied with small offsets. The patched source allowed a
reconfigure of the -dkms package to build working kernel modules.

Best regards
chrysn

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

Kernel: Linux 4.20.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (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.5
ii  bzip2 1.0.6-9
ii  debhelper 12
ii  kbuild1:0.1.9998svn3293+dfsg-2
ii  module-assistant  0.11.10

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

virtualbox-source suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#906093: installation-reports: Buster on HP ProBook 430 G5: Works in non-EFI mode, EFI needs console-setup(?)

[chrysn]

Package: installation-reports
Severity: normal

In order to install from netinstall, I had to disable secure boot. After
that, the netinst stick could be selected from the boot menu.

Both graphical and text installation left me with a black screen right
after GRUB; judging by the response to SysRq-B, Linux was running but
the graphics were broken. Switching over to legacy bootup (BIOS) got me
a working installer, which correctly detected that we're doing a UEFI
installation.

(I did try various arguments to GRUB and Linux -- `set
gfxpayload={1920x1080,keep}` and `nomodeset` as well as
`intel_pstate=no_hwp`, to no avail.)

The graphical installer had only partial mouse support: clicks were
detected, but mouse movement was not. The installed system has regular
mouse support (move, drag, soft buttons). For the actual installation, I
went with the text installer.

Installation itself was rather uneventful. The installer asked for
iwlwifi firmware, which I rejected. I chose full-disk LVM + encryption
setup on the SSD device, with some manual modification to reduce initial
file system size and use btrfs.

After the installation, I found that I can switch back to EFI boot mode.
The terminal still does not show anything at first, which includes the
disk encryption passphrase prompt, but when that is entered blindly, at
a later stage (I'd assume it's console-setup) the display does get
fixed, and both text console and X11 are available.

Everything I expect from the system to work seems to work (at least with
firmware-iwlwifi, firmware-misc-nonfree b/c of video firmware and
firmware-realtek for the ethernet adapter): WiFi, Bluetooth, Gigabit
Ethernet, suspend to RAM and to disk, FN keys, sound output and external
(HDMI, didn't test DP) video.

-- Package-specific info:

Boot method: USB
Image version: 
https://cdimage.debian.org/cdimage/buster_di_alpha3/amd64/iso-cd/debian-buster-DI-alpha3-amd64-netinst.iso
Date: 2018-08-12

Machine: HP ProBook 430 G5 (3KY90EA#ABD)

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]


-- 

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20180610"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux hephaistos 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5914] 
(rev 08)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8377]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:5917] (rev 07)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8377]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Skylake Processor Thermal Subsystem [8086:1903] (rev 08)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8377]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP 
USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8377]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8377]
lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8377]
lspci -knn: 00:15.1 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8377]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8377]
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-LP 
SATA Controller [AHCI mode] [8086:9d03] (rev 21)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8377]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #5 [8086:9d14] (rev f1)
lspci -kn

Bug#904741: lighttpd: create-mime.assign.pl skips mime types with capital letters

[chrysn]

Package: lighttpd
Version: 1.4.49-1.1
Severity: normal
Tags: patch

The create-mime.assign.pl script can only read mime types without
capital letters from /etc/mime.types, thus reporting files like .ts or
.m3u8 as application/octet-stream instead of video/MP2T and
application/x-mpegURL, respectively.

The attached patch fixes the issue by accepting capital letters in;
[^\s] would be an alternative depending on the precise definition of the
mime.types file.

Best regards, and thank you for maintaining this package
chrysn

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-0.bpo.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lighttpd depends on:
ii  libattr11:2.4.47-2+b2
ii  libbz2-1.0  1.0.6-8.1
ii  libc6   2.27-3
ii  libfam0 2.7.0-17.2+b1
ii  libldap-2.4-2   2.4.46+dfsg-5
ii  libmariadbclient18  1:10.1.29-6+b1
ii  libpcre32:8.39-9
ii  libssl1.1   1.1.0h-4
ii  lsb-base9.20170808
ii  mime-support3.61
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages lighttpd recommends:
ii  spawn-fcgi  1.6.4-2

Versions of packages lighttpd suggests:
pn  apache2-utils  
pn  lighttpd-doc   
ii  openssl1.1.0h-4
pn  php-cgi
pn  rrdtool

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

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/lighttpd/create-mime.assign.pl (from lighttpd 
package)

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom
--- a/create-mime.assign.pl  2018-07-27 14:00:49.0 +0200
+++ b/create-mime.assign.pl   2018-07-27 14:00:23.0 +0200
@@ -7,7 +7,7 @@
   chomp;
   s/\#.*//;
   next if /^\w*$/;
-  if(/^([a-z0-9\/+-.]+)\s+((?:[a-z0-9.+-]+[ ]?)+)$/) {
+  if(/^([a-zA-Z0-9\/+-.]+)\s+((?:[a-z0-9.+-]+[ ]?)+)$/) {
 foreach(split / /, $2) {
   # mime.types can have same extension for different
   # mime types


signature.asc
Description: PGP signature

Bug#882386: avahi-daemon segfaults with txt-record values ending in "="

[chrysn]

Package: avahi-daemon
Version: 0.7-4
Followup-For: Bug #882386

This bug can also occur easily when advertising a WebDAV server that
needs no user name / password on the LAN, or has an empty path because
everything on the server's authority is WebDAV.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages avahi-daemon depends on:
ii  adduser3.117
ii  bind9-host [host]  1:9.11.3+dfsg-2
it  dbus   1.12.8-3
ii  libavahi-common3   0.7-4
ii  libavahi-core7 0.7-4
ii  libc6  2.27-3
ii  libcap21:2.25-1.2
ii  libdaemon0 0.14-7
ii  libdbus-1-31.12.8-3
ii  libexpat1  2.2.5-3
ii  lsb-base   9.20170808

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.14.1-1

Versions of packages avahi-daemon suggests:
ii  avahi-autoipd  0.7-4

-- no debconf information


signature.asc
Description: PGP signature

Bug#851651: still in 1.13.1, test config

[chrysn]

> A patch is available at the upstream bug tracker at [1], it might be
> worth applying to the package.
> 
> [1]: https://github.com/arut/nginx-dav-ext-module/pull/17

The patch has been sitting there for quite a while (3 years), and there
was no upstream response; is that the right place to forward issues on
the component?

If it is and it is just poorly maintained, would you consider adding the
patch to Debian?

As it is now, the nginx DAV server is not really usable for general file
sharing with end-user provided file names, at least not with Gnome or
XFCE.

Thanks
chrysn


signature.asc
Description: PGP signature

Bug#856309: xfce4-panel: "Welcome" prompt is misguided; default to a useful config

[chrysn]

Package: xfce4-panel
Version: 4.13.3-1
Followup-For: Bug #856309
Forwarded: https://bugzilla.xfce.org/show_bug.cgi?id=14388

I just had a user run into this, necessitating a wipe of ~/ and a reboot
to get rid of the config daemon. I agree with Jonathan's recommendation
for the dialog to be removed and just the default to be used.

Also, the issue is still present on 4.12.2-1 and 4.13.3-1.

I've taken the liberty to forward this to the XFCE issue tracker.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-panel depends on:
ii  exo-utils0.12.0-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-3
ii  libcairo21.15.10-2
ii  libdbus-1-3  1.12.6-2
ii  libdbus-glib-1-2 0.110-2
ii  libexo-1-0   0.12.0-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-2
ii  libgarcon-1-00.6.1-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.0-5
ii  libgtk2.0-0  2.24.32-1
ii  libice6  2:1.0.9-2
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libpangoft2-1.0-01.42.0-1
ii  libsm6   2:1.2.2-1+b3
ii  libwnck222.30.7-5.1
ii  libx11-6 2:1.6.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfce4ui-1-0   4.13.3-1
ii  libxfce4util74.13.0-1
ii  libxfconf-0-24.12.1-1

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#897559: installation-reports: Stretch on HP ProBook 440 G5: Smooth installation, WiFi needs staging driver

[chrysn]

Package: installation-reports
Severity: normal

This is an installation report on an HP ProBook 440 G5, type number
3KX82ES#ABD.

It appears that the 3KX82ES number is what defines the hardware relevant
to this report; other ProBook 440 G5 appear to use different (Intel)
WiFi adapters.  (And don't be irritated if you don't find it on HP
support; HP's PartSurfer[1] does recognize it -- that appears to be a
common issue judging from support staff's reactions.)

The overall installation went very smooth.

The only exotic component in this machine is the WiFi/Bluetooth card,
which appears to be a Realtek 8822BE family device. (See
Comments/Problems below).

[1]: http://partsurfer.hp.com/Search.aspx?searchText=3KX82ES#ABD

-- Package-specific info:

Boot method: netinstall image via USB
Image version: 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.4.0-amd64-netinst.iso
Date: 2018-05-02

Machine: HP ProBook 440 G5 (3KX82ES#ABD)
Partitions: /dev/nvme0n1p[123]


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ] (no drive built in)
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

I chose to force a UEFI installation and use guided full-disk mode with
encrypted LVM, installed the XFCE desktop environment (probably makes no
difference). The system was in factory state before I started the
installation.

The "The installer is now overwriting ... with random data" message was
hard-cropped to the right ("This step m"), probably because
/dev/nvme0n1p3 appears to be an unusually long device name.

The touchpad was unavailable during graphical installation (but
available at the first boot).

Suspend-to-RAM and suspend-to-disk work out of the box.

The display brightness, "open display settings" and "on/off" buttons
work out of the box. The output volume buttons work as soon as the
PulseAudio widget is added to the XFCE panel; mute-mike is not captured
by that but shows correctly as XF86AudioMicMute in xev. The Suspend
button is recognized by xfce4-power-manager (just mapped to "Do nothing"
by default). The radio button kind of works, but follows its own logic
(enabling WiFi from network-manager goes unnoticed by it, so you might
have to press it twice to disable WiFi).

To get Bluetooth to run, I had to install the non-free firmware-realtek
package.

In order to get WiFi to run, I had to install the 4.15 kernel sources
from backports, unpack them, and (relative to the packaged amd64
.config) enable the R8822BE module. Additionally, I had to download [2]
to /lib/firmware/rtlwifi. With that, I can connect to my home WiFi. (Did
not test particulars band support or throughput, but it works and is
fast enough for the applications I run.)

[2]: 
https://github.com/wkennington/linux-firmware/raw/master/rtlwifi/rtl8822befw.bin

(The automatically gathered data below is from the stretch kernel, as I
started assembling this report as the installation progressed).

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170615+deb9u3"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux hera 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5904] 
(rev 02)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:837b]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:5916] (rev 02)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:837b]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Skylake Processor Thermal Subsystem [8086:1903] (rev 02)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:837b]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP 
USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:837b]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:837b]
lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
lspci -knn: Subsystem: Hewlett-Packard Co

Bug#866652: runit: Should depend on runit-(systemd|sysv) to be present

[chrysn]

Package: runit
Version: 2.1.2-9.2
Followup-For: Bug #866652

Hello Dmitry,

If this is implemented (which I think is a good idea), please implement
it in a way that users of runit as PID 1 can also satisfy the
dependency, eg. by making the dependency "runit-systemd | runit-any"
where runit-any is virtual and provided by runit-systemd, runit-sysv,
and users of runit-init can make it "Provides: runit-any" even if a
runit-init does not come back to Debian.

Thanks
chrysn


signature.asc
Description: PGP signature

Bug#825383: /usr/bin/hp-plugin: Re: /usr/share/hplip/doctor.py: hp-doctor will not accept sudo password and there is no root account

[chrysn]

Package: hplip
Version: 3.16.11+repack0-3
Followup-For: Bug #825383

The problem affects hp-plugin (and thus nowadays typical MFP setups) as well,
please consider changing the mechanism to something more generic or not
advertising the said programs in the application menu directly (but to be run
under whatever is a generic `gksudo` these days).

-- Package-specific info:

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

Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hplip depends on:
ii  adduser3.115
ii  coreutils  8.26-3
ii  cups   2.2.1-8
ii  hplip-data 3.16.11+repack0-3
ii  libc6  2.24-11+deb9u1
ii  libcups2   2.2.1-8
ii  libdbus-1-31.10.24-0+deb9u1
ii  libhpmud0  3.16.11+repack0-3
ii  libsane1.0.25-4.1
ii  libsane-hpaio  3.16.11+repack0-3
ii  libsnmp30  5.7.3+dfsg-1.7
ii  libusb-1.0-0   2:1.0.21-1
ii  lsb-base   9.20161125
ii  policykit-10.105-18
ii  printer-driver-hpcups  3.16.11+repack0-3
ii  python33.5.3-1
ii  python3-dbus   1.2.4-1+b1
ii  python3-gi 3.22.0-2
ii  python3-pexpect4.2.1-1
ii  python3-pil4.0.0-4
ii  python3-reportlab  3.3.0-2
ii  wget   1.18-5+deb9u1

Versions of packages hplip recommends:
ii  avahi-daemon  0.6.32-2
ii  printer-driver-postscript-hp  3.16.11+repack0-3
ii  sane-utils1.0.25-4.1

Versions of packages hplip suggests:
pn  hplip-doc  
ii  hplip-gui  3.16.11+repack0-3
ii  python3-notify20.3-3
ii  system-config-printer  1.5.7-3

-- no debconf information


signature.asc
Description: PGP signature

Bug#888243: Lack of /opt in base-files causes piuparts issues for in-house packages

[chrysn]

Package: base-files
Version: 10.1
Severity: normal

When a package gets installed and later uninstalled that places files in
/opt (or /etc/opt), that directory gets removed because it was only used
by that package and not owned by any. As a consequence, in-house
packages (which can reasonably install to /opt/) can not pass piuparts
as that complains about /opt and /etc/opt going away.

Now this could be fixed at several places (eg. dpkg could keep them
around, or piupats could mask them), but keeping such directories around
is typically done by base-files. The reason given in the FAQ for /opt
just being added in postinst is that it should be possible for an admin
to rmdir those -- a valid point, but causing inconvenience to packages
going there.

The fix I'd suggest is to have a base-files-fhs package recommended by
base-files but not required, which can be uninstalled if an admin wants
those files gone.


Thanks for your consideration
chrysn

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages base-files depends on:
ii  gawk [awk]  1:4.1.4+dfsg-1
ii  mawk [awk]  1.3.3-17+b3

base-files recommends no packages.

base-files suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#883986: openscad: FTBFS on mips/mipsel: virtual memory exhausted: Cannot allocate memory

[chrysn]

On Sun, Dec 10, 2017 at 03:52:04AM +0100, Andreas Beckmann wrote:
> Source: openscad
> openscad did run out of memory during the recent binNMU on mips/mipsel:
> 
> https://buildd.debian.org/status/package.php?p=openscad&suite=unstable

Thanks for the report. I'm waiting for porter box access on MIPS boxes
to resolve the issue.


signature.asc
Description: PGP signature

Bug#884766: new 2.0 version regresses on remote lines like `--port 587`

[chrysn]

Package: nullmailer
Version: 1:2.1-2
Severity: normal

The 1.13 series remotes accepted options like `--port 587`, while the
new 2.0 series requres `--port=587` as a style.

As these options are commonly stored in configuration, I think it would
be convenient to have those checked when upgrading on the stable path.

The NEWS files do not document the change. Admittedly, the syntax was
not advertised either (man page says `--port=587`), but my impression is
that accepting both is common enough that administrators can easily have
configured it that way.


Thanks
chrysn

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nullmailer depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  libc6  2.25-5
ii  libgnutls303.5.16-1
ii  libstdc++6 7.2.0-18
ii  lsb-base   9.20170808

Versions of packages nullmailer recommends:
ii  rsyslog [system-log-daemon]  8.31.0-2

nullmailer suggests no packages.

-- debconf information:
* nullmailer/relayhost:
  nullmailer/defaultdomain: amsuess.com
* shared/mailname: hephaistos.amsuess.com
* nullmailer/adminaddr: host-hephais...@christian.amsuess.com

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#878498: snakemake FTBFS with Python 3.6 as default

[chrysn]

On Mon, Dec 11, 2017 at 03:45:50PM +0100, Andreas Tille wrote:
> > Will let you know when I'm through with those and all is pushed to
> > alioth again.

The current master passes build in a cowbuilder that has access to
python3-ratelimiter, and lintian's only serious complaints are the
privacy violations (JavsScript and badges in the documentation and some
web application templates -- Snakemake has a web application?) that have
been there in the old release too and I don't have a plan on how to fix
them yet.

The new test suite system patch-outs are for

* r-cran-rmarkdown (filed as #884115, thanks Andreas for ITP-ing), and
* google-cloud-sdk (quoting the patch description: Whether this needs
  a Debian RFP or should be forwarded is undecided yet given I have no
  clue about what those Google Cloud SDK actually does).

IMO that package state is an enhancement over the last one in the
archive and can be considered for upload, if one is willing to accept
the abovementioned lintian warnings.

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#884115: RFP: r-cran-rmarkdown -- GNU R tool to convert R Markdown documents into a variety of formats

[chrysn]

Package: wnpp
Severity: wishlist

* Package name: r-cran-rmarkdown
  Version : 1.8
  Upstream Author : JJ Allaire, Yihui Xie et al
* URL : http://rmarkdown.rstudio.com,
https://cran.r-project.org/web/packages/rmarkdown/index.html
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R tool to convert R Markdown documents into a variety 
of formats

R Markdown is a framework for creating documents that mix R code with
markdown to produce visually pleasing, high quality and reproducible
reports. It supports various output formats, including HTML, PDF,
Microsoft Word and Beamer.

---

The package is a soft reverse build dependency of Snakemake (which is
currently patched to not execute the test in its test suite that depends
on rmarkdown), and a quick search shows that other R packages in the
archive could interact with it as well (eg. r-cran-fitbitscraper
suggests it).

There is already the r-cran-markdown package whose description
acknowledges rmarkdown as a "newer and enhanced version of this markdown
package".


signature.asc
Description: PGP signature

Bug#878498: snakemake FTBFS with Python 3.6 as default

[chrysn]

> The problem is that when trying to build this I get a lot of errors in
> the build time tests.  Is there any volunteer to have a look?

I've got them all down locally; it'll need some cleaning up (and
possibly upstreaming) of patches, and I have yet to run it in a pbuilder
to see which build dependencies popped up that are undeclared so far,
but I don't expect any showstoppers there.

Will let you know when I'm through with those and all is pushed to
alioth again.

Best regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#880661: RFP to ITP: python3-ratelimiter

[chrysn]

retitle 880661 ITP: python3-ratelimiter -- simple Python library for limiting 
the rate of operations
thanks

The snakemake workaround broke, and we'll need that anyway; starting to
package this in the style of DPMT policy with the intention of
maintaining it within the team.

Best regards
chrysn


signature.asc
Description: PGP signature

Bug#878498: snakemake FTBFS with Python 3.6 as default

[chrysn]

On Fri, Dec 08, 2017 at 09:18:42AM +0100, Andreas Tille wrote:
> The problem is that when trying to build this I get a lot of errors in
> the build time tests.  Is there any volunteer to have a look?

I've started with the tests more or less at random, and the second seems
to be promising to solve most of them:

* test_delete_output is IMO an upstream bug that only triggers when
  SHELL does not try to be POSIX compatible (why should it unless
  invoked as `sh`), eg. when SHELL=zsh.

  There are 3 more that fail even when run locally w/o any Debian
  modifications, so we might need to mask them or apply any of the
  workarounds. (Postponed that until the big ones are done).

* The noop-rate-limiter workaround I introduced earlier to be able to
  work on the other issues of the new version doesn't work right now.
  Before I spend any more time fixing a workaround, I'll go ahead and
  ITP python3-ratelimiter [880661] -- with that workaround in place, we
  shouldn't release an updated snakemake anyway.

If the delay introduced by ratelimiter (even with me getting packaging
done "immediately" and follow-up sponsorship from DPMT, this will need
to go through NEW.

Best regards
chrysn

[1]: 
https://bitbucket.org/snakemake/snakemake/issues/722/tests-fail-when-shell-is-zsh-and-not-bash
[880661]: https://bugs.debian.org/880661

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#878498: snakemake FTBFS with Python 3.6 as default

[chrysn]

On Sun, Dec 03, 2017 at 06:47:48PM +0100, Andreas Tille wrote:
> Ping?

sorry, I thought I had already done that: my latest WIP state is now
pushed; it includes a patch that disables rate limiting for sake of
being able to work on the main issue, but I haven't made any progress
there yet.


signature.asc
Description: PGP signature

Bug#880661: RFP: python3-ratelimiter -- simple Python library for limiting the rate of operations

[chrysn]

Package: wnpp
Severity: wishlist

* Package name: python3-ratelimiter
  Version : 1.2.0
  Upstream Author : Arnaud Porterie, Frazer McLean
* URL : https://github.com/RazerM/ratelimiter
* License : Apache-2.0
  Programming Lang: Python
  Description : simple Python library for limiting the rate of operations

This package provides the ratelimiter module, which ensures that an
operation will not be executed more than a given number of times on a
given period. This can prove useful when working with third parties APIs
which require for example a maximum of 10 requests per second.

---

The library is a dependency of newer versions of snakemake (introduced
at some point between 3.13 and 4.3).

I am not actively using the package (yet); if I actually start spending
time on snakemake, I will change this to an ITP.

The package probably lends itself to being maintained in the Python
Modules Team; if I package it, I'll do it within that team and CC it to
the bug.


chrsyn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#878498: snakemake FTBFS with Python 3.6 as default

[chrysn]

Package: src:snakemake
Followup-For: Bug #878498

The test also fails with the 3.13.3 version in the team repository.

I've had a short look at whether upgrading to 4.3.0 helps (minimal patch
refreshing and new build dependency on python3-configargparse as well as
the unpackaged ratelimiter module), but the same condition shows up
there as well.

I'll probably need to fix this, but as I'm new to snakemake: Will this
need keeping the 3 version around, or can I just go ahead and proceed
with 4.3.0?

Best regards
chrysn

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-rc7-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#880431: libxfce4ui-2-0 4.13.3-1 breaks xfce4-terminal

[chrysn]

Package: libxfce4ui-2-0
Version: 4.13.3-1
Severity: normal

While trying out the latest xfce4 experimental packages, I stumbled upon
a conflict that should probably be covered by a "Breaks" relation before
those versions hit unstable:

When libxfce4ui-2-0 version 4.13.3-1 is installed, running
xfce4-terminal and pressing F1 there returns in the following crash:

| (xfce4-terminal:26893): Gtk-ERROR **: failed to add UI: The resource at 
“/org/xfce/libxfce4ui/libxfce4ui-dialog-ui.ui” does not exist
| zsh: trace trap  xfce4-terminal --disable-server

Reverting libxfce4ui to 4.12.3-4 solves the issue, and F1 presents the
"Online Documentation" / "Do you want to read the Xfce Terminal manual
online" menu.

A (probably needless) word of warning: xfce4-terminal usually runs
single-process-per-user, so such a crash takes down all the terminal
windows; better test it on an instance started with the --disable-server
option.

Best regards
chrysn

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-rc5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#879697: RFS: opencsg/1.4.2-1 [RC]

[chrysn]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "opencsg"

 * Package name: opencsg
   Version : 1.4.2-1
   Upstream Author : Florian Kirsch (mail at opencsg dot org)
 * URL : http://opencsg.org/
 * License : GPL-2 with CGAL exception, and some ZLIB & similar
   Section : libs

The package provides the graphics library for the OpenSCAD programmatic
3D modelling tool. The library flips around the Z buffer so that CSG
(constructive solid geometry) compositions can be shown without
explicitly calculating their meshes.

It builds those binary packages:

libopencsg1
libopencsg-example - a small GLUT demo program whose practical
  importance in Debian is to answers the question of "is it a library or
  an OpenSCAD bug?"
libopencsg-dev
libopencsg1-dbg

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/opencsg

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opencsg/opencsg_1.4.2-1.dsc

For Sponsors who prefer to sponsor from git-buildpackage sources:

  git clone ssh://git.debian.org/git/collab-maint/opencsg.git

The package was built from 266c730b5c4b192be18d78bacc176961edfbe8f5.

Changes since the last upload:

  * New upstream version 1.4.2 (Closes: #861244)
  * Update copyright file
  * Drop old dependency names from squeeze or earlier
  * Modernize VCS-* and DEP URIs
  * Drop obsolete lintian override
  * Bump Standards-Version (no changes)

(up to here it has been sitting around for a while), and the RC bugfix:)

  * Make build dependency on rename explicit (Closes: #876676)

I'm aware that the Standards-Version is not the latest, but that would
better be fixed with other pending updates (eg. dbgsym migration), while
right now I'd like to get this through to resolve the FTBFS situation
with imminent testing removal.

Thanks for your consideration,
 chrysn


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-rc5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#878214: version limit of kramdown < 1.15~ in code not expressed in dependency

[chrysn]

Package: ruby-kramdown-rfc2629
Version: 1.2.6-1
Severity: important
File: /usr/bin/kramdown-rfc2629

Hello kramdown maintainers,

kramdown-rfc2629, with the below set of installed packages, err out like
this:

| $ kramdown-rfc2629
| /usr/lib/ruby/2.3.0/rubygems/dependency.rb:319:in `to_specs': Could not find 
'kramdown' (~> 1.14.0) - did find: [kramdown-1.15.0] (Gem::LoadError)
| Checked in 
'GEM_PATH=/home/chrysn/.gem/ruby/2.3.0:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all',
 execute `gem env` for more information
| from /usr/lib/ruby/2.3.0/rubygems/dependency.rb:328:in `to_spec'
| from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:65:in `gem'
| from /usr/lib/ruby/vendor_ruby/kramdown-rfc2629.rb:14:in `'
| from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in 
`require'
| from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in 
`rescue in require'
| from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:40:in 
`require'
| from /usr/bin/kramdown-rfc2629:3:in `'

If that were set, the package would become uninstallable right now, but
at least the package would stay usable because package managers would
refuse to upgrade kramdown in the presence of kramdown-rfc2629.

Thanks for maintaining the package
chrysn

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ruby-kramdown-rfc2629 depends on:
ii  ruby   1:2.3.3
ii  ruby-kramdown  1.15.0-1

ruby-kramdown-rfc2629 recommends no packages.

Versions of packages ruby-kramdown-rfc2629 suggests:
pn  xlm2rfc  

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#876178: "Browse Network" gives difficult error message, consider recommending gvfs-backends

[chrysn]

Package: thunar
Version: 1.6.12-1
Severity: wishlist

Hello Thunar maintainers,

please consider recommending gvfs-backends in from Thunar. AFAICT, in a
default xfce4 installation, Thunar displays the "Browse Network"
(network://) area in its sidebar, but lacks the backends to actually
open it (message 'Failed to open "/ on ".' / 'The specified location is
not supported').

If you deem gvfs-backends too heavyweight for an XFCE4 desktop (I
counted 9 new packages on a almost fresh install: libcdio-...,
libgdata..., libgoa..., libnfs8, liboauth0, psmisc), please let me know
and I'd rephrase this as a bug against gvfs-backends, "please provide a
gvfs-backends-light" or similar (at least SSHFS and WebDAV are IMO
reasonably to be expected from a network-enabled distribution).

Other alternatives I'd see is giving a more descriptive error message
with installation instructions (of whose difficulties to get it right
upstream and cross-distribution I'm aware, thus my initial suggestion),
or hiding the network area completely when not supported.

Thanks for maintaining Thunar
chrysn

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-2
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.26.0-2
ii  libc6   2.24-17
ii  libcairo2   1.15.8-0.1
ii  libdbus-1-3 1.11.16+really1.10.22-1
ii  libdbus-glib-1-20.108-2
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.36.5-4
ii  libglib2.0-02.54.0-1
ii  libgtk2.0-0 2.24.31-2
ii  libgudev-1.0-0  232-1
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-2
ii  libpango-1.0-0  1.40.12-1
ii  libsm6  2:1.2.2-1+b3
ii  libthunarx-2-0  1.6.12-1
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.8-1
ii  thunar-data 1.6.12-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.11.16+really1.10.22-1
ii  dbus-x11 [dbus-session-bus]   1.11.16+really1.10.22-1
ii  gvfs  1.30.4-1+b1
ii  libfontconfig12.12.3-0.2
ii  libfreetype6  2.8-0.2
ii  libpangocairo-1.0-0   1.40.12-1
ii  libpangoft2-1.0-0 1.40.12-1
ii  thunar-volman 0.8.1-2
ii  tumbler   0.1.32-1
ii  xdg-user-dirs 0.15-3
ii  xfce4-panel   4.12.1-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.3.1-4
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#810617: applying fix to stable

[chrysn]

On Tue, Sep 12, 2017 at 08:46:52PM +0200, chrysn wrote:
> unless [...], the next easiest solution would be packaging a 1.15
> version (fix is in everythin newer than 1.15.4).

After a closer look at cairo's versioning scheme, it has become clear
that packaging 1.15.8 is not directly an option, as odd numbers there
indicate snapshots rather than releases.

Nevertheless, I gave it a try (turned out that taking the snapshot as a
new orig tarball takes no more than the usual
merging/changelogging/patch-refreshing, plus a few new symbols), and
indeed the issue is fixed in "1.15.8-0.1".

Maintainers, if having something like that in experimental is appealing
to you, I can push branches upstream-experimental-snapshots and
experimental-snapshots and a tag upstream-experimental-snapshots/1.15.8
to collab-maint (or to another place or with other names depending on
how you manage those things).

Best regards
chrysn

-- 
You don't use science to show that you're right, you use science to become 
right.
  -- Randall Munroe


signature.asc
Description: PGP signature

Bug#810617: applying fix to stable

[chrysn]

The patch linked to in the report Dennis found[1] applies to stable with
some offsets, but fails to build; there is a new is_vector member on
targets which I didn't track down any further.

I've asked upstream about porting the patch back to the 1.14 series;
unless that turns out positive, the next easiest solution would be
packaging a 1.15 version (fix is in everythin newer than 1.15.4).

If there are any attempts around backporting this to 1.14, they should
probably also include [3], a fixup to [1].

Best regards
chrysn

[1]: 
https://cgit.freedesktop.org/cairo/commit/?id=190678f6444ad879847d603c3c9eaf8e9ab6887a
[2]: https://bugs.freedesktop.org/show_bug.cgi?id=94615#c5
[3]: 
https://cgit.freedesktop.org/cairo/commit/?id=d28b6d9b128675dfa9b3b6b793844144183aff64


signature.asc
Description: PGP signature

Bug#874456: New version 2.0.3 adds support for AEAD

[chrysn]

Source: python-cryptography
Severity: wishlist

Hello Tristan,

a new version 2.0.3 is available and adds a feature group (authenticated
encryption with additional data, AEAD) that is required for future
versions of the python3-aiocoap package (which I'm upstream of) that
will depend on python3-cryptography (>= 2) in its next release.

I've built python-cryptography-vectors and python-cryptography with the
uscan'd upstream tarballs, and all built well (though not tested in a
minimal environment yet), build tests passed, and the resulting package
is suitable for using the new feature (tested on Python 3.5 and Python
3.6). I did not have to change anything about the package short of the
version numbers in the changelog and the versioned build dependencies on
python-cryptography-vectors.

The only breaking change from the 2.0 announcement is dropped support for
Python 3.3 which should not be an issue in Debian anyway.

Please consider uploading a new version of the package.

Best regards
chrysn

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information


signature.asc
Description: PGP signature

Bug#874180: python3-tk: undefined symbol in _tkinter.cpython-35m-x86_64-linux-gnu.so

[chrysn]

Hi,

this seems to be related to the removal of fpecl extensions in python3.5
3.5.4-3 and python3.6 3.6.2-3: I rolled back my python3.6 to -2, and
tkinter could be importedl back at -3, the same issues occur.

I did not test the rollback with 3.5, but chances are that a versions
3.5.4-2 and earlier work as well.

Not changing the "found" version or assignment as I'm unsure how to best
represent that it affects both Python versions without duplicating the
bug, but at least the immediate cause and workarounds doumented here now.

Best regards
chrysn

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-tk depends on:
ii  blt   2.5.3+dfsg-3
ii  libc6 2.24-17
ii  libtcl8.6 8.6.7+dfsg-1
ii  libtk8.6  8.6.7-1
ii  libx11-6  2:1.6.4-3
ii  python3   3.5.3-3
ii  tk8.6-blt2.5  2.5.3+dfsg-3

python3-tk recommends no packages.

Versions of packages python3-tk suggests:
pn  python3-tk-dbg  
pn  tix 

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#873836: runscript suggestions

[chrysn]

Package: runit
Version: 2.1.2-10
Severity: minor

hi dmitry,

i just stumbled upon the runscript mechanism in the unreleased version
in git, and noticed two things:

* there is a typo ("unprivilleged" -> "unprivileged") that's probably
  easier to change now than when it's shipped, especially since it'd
  make its way into user files where it's hard to change later-on

* running nested runsvdirs, in my experience, needs special care that i
  did not see taken in the current script: when the outer service is
  taken down, the inner runsvdir process is sent the term signal. this
  makes it exit immediately, leaving the inner runsv instances running
  and hard to re-gain control of.

  if a `control/t` file is placed with `#!/bin/sh` / `exec sv -v h .`,
  then the runsvdir gets a SIGHUP first, terminates its child processes
  and then exits. i think this would be the less surprising behavior for
  such scripts.

best regards, and thanks for maintaining runit
(which i'm using from server init to user processes)
chrysn

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages runit depends on:
ii  libc6  2.24-17

runit recommends no packages.

runit suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#871808: [PATCH 1/2] u-a: Get altdir using DPKG_ROOT

[chrysn]

Previously, an update-alternatives run in a maintscript when installing
with `dpkg --root` would have worked on /etc/alternatives rather than
/install-dir/etc/alternatives.

This patch is not complete yet because an unmodified version of altdir
would actually be required for symlink targets. (Right now, this creates
a $DPKG_ROOT/usr/bin/awk -> $DPKG_ROOT/etc/alternatives/awk rather than
-> /etc/alternatives/awk; that still needs to be resolved.)

Closes: https://bugs.debian.org/871808
---
 utils/update-alternatives.c | 59 +
 1 file changed, 44 insertions(+), 15 deletions(-)

diff --git a/utils/update-alternatives.c b/utils/update-alternatives.c
index 9a9d10c62..8a3bff1dd 100644
--- a/utils/update-alternatives.c
+++ b/utils/update-alternatives.c
@@ -50,7 +50,8 @@
 
 #define PROGNAME "update-alternatives"
 
-static const char *altdir = SYSCONFDIR "/alternatives";
+static const char *altdir ;
+static const char *dpkg_root;
 static const char *admdir;
 
 static const char *prog_path = "update-alternatives";
@@ -378,6 +379,24 @@ admindir_init(void)
return xasprintf("%s/%s", basedir, "alternatives");
 }
 
+static const char *
+dpkg_root_init(void)
+{
+   const char *env_root;
+
+   env_root = getenv("DPKG_ROOT");
+   if (env_root != NULL)
+   return env_root;
+
+   return "";
+}
+
+static const char *
+altdir_init(void)
+{
+   return xasprintf("%s%s/%s", dpkg_root, SYSCONFDIR, "alternatives");
+}
+
 static FILE *fh_log = NULL;
 
 static void DPKG_ATTR_PRINTF(1)
@@ -1741,7 +1760,7 @@ static void
 alternative_prepare_install_single(struct alternative *a, const char *name,
const char *linkname, const char *file)
 {
-   char *fntmp, *fn;
+   char *fntmp, *linktmp, *fn;
 
/* Create link in /etc/alternatives. */
fntmp = xasprintf("%s/%s" ALT_TMP_EXT, altdir, name);
@@ -1751,14 +1770,16 @@ alternative_prepare_install_single(struct alternative 
*a, const char *name,
alternative_add_commit_op(a, OPCODE_MV, fntmp, fn);
free(fntmp);
 
-   if (alternative_path_needs_update(linkname, fn)) {
+   linktmp = xasprintf("%s%s", dpkg_root, linkname);
+   if (alternative_path_needs_update(linktmp, fn)) {
/* Create alternative link. */
-   fntmp = xasprintf("%s" ALT_TMP_EXT, linkname);
+   fntmp = xasprintf("%s" ALT_TMP_EXT, linktmp);
checked_rm(fntmp);
checked_symlink(fn, fntmp);
-   alternative_add_commit_op(a, OPCODE_MV, fntmp, linkname);
+   alternative_add_commit_op(a, OPCODE_MV, fntmp, linktmp);
free(fntmp);
}
+   free(linktmp);
free(fn);
 }
 
@@ -1778,7 +1799,7 @@ alternative_prepare_install(struct alternative *a, const 
char *choice)
 
/* Take care of slaves alternatives */
for (sl = a->slaves; sl; sl = sl->next) {
-   char *fn;
+   char *fn, *sltmp;
 
if (fileset_can_install_slave(fs, sl->name)) {
alternative_prepare_install_single(a, sl->name,
@@ -1795,11 +1816,12 @@ alternative_prepare_install(struct alternative *a, 
const char *choice)
 
/* Drop unused slave. */
fn = xasprintf("%s/%s", altdir, sl->name);
-   if (alternative_path_can_remove(sl->link))
-   alternative_add_commit_op(a, OPCODE_RM, sl->link, NULL);
+   sltmp = xasprintf("%s%s", dpkg_root, sl->link);
+   if (alternative_path_can_remove(sltmp))
+   alternative_add_commit_op(a, OPCODE_RM, sltmp, NULL);
else
warning(_("not removing %s since it's not a symlink"),
-   sl->link);
+   sltmp);
alternative_add_commit_op(a, OPCODE_RM, fn, NULL);
free(fn);
}
@@ -1810,17 +1832,22 @@ alternative_remove_files(struct alternative *a)
 {
struct slave_link *sl;
 
-   checked_rm_args("%s" ALT_TMP_EXT, a->master_link);
-   if (alternative_path_can_remove(a->master_link))
-   checked_rm(a->master_link);
+   const char *mltmp, *sltmp;
+
+   mltmp = xasprintf("%s%s", dpkg_root, a->master_link);
+
+   checked_rm_args("%s" ALT_TMP_EXT, mltmp);
+   if (alternative_path_can_remove(mltmp))
+   checked_rm(mltmp);
 
checked_rm_args("%s/%s" ALT_TMP_EXT, altdir, a->master_name);
checked_rm_args("%s/%s", altdir, a->master_name);
 
for (sl = a->slaves; sl; sl = sl->next) {
-   checked_rm_args("%s" ALT_TMP_EXT, sl->link);
-   if (alternative_path_can_remove(sl->link))
-   checked_rm(sl->link);
+   sltmp = xasprintf("%s%s", dpkg_root, sl->link);
+   checked_rm_args("%s" ALT_TMP_EXT, sltmp);
+   if (alternative_path_can_remo

Bug#871808: [PATCH 2/2] u-a: Fix link targets for DPKG_ROOT != ""

[chrysn]

---
 utils/update-alternatives.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/utils/update-alternatives.c b/utils/update-alternatives.c
index 8a3bff1dd..982d1b954 100644
--- a/utils/update-alternatives.c
+++ b/utils/update-alternatives.c
@@ -51,6 +51,7 @@
 #define PROGNAME "update-alternatives"
 
 static const char *altdir ;
+static const char *altdir_as_prefix;
 static const char *dpkg_root;
 static const char *admdir;
 
@@ -1760,22 +1761,23 @@ static void
 alternative_prepare_install_single(struct alternative *a, const char *name,
const char *linkname, const char *file)
 {
-   char *fntmp, *linktmp, *fn;
+   char *fntmp, *linktmp, *fn, *fnlink;
 
/* Create link in /etc/alternatives. */
fntmp = xasprintf("%s/%s" ALT_TMP_EXT, altdir, name);
fn = xasprintf("%s/%s", altdir, name);
+   fnlink = xasprintf("%s/%s", altdir_as_prefix, name);
checked_rm(fntmp);
checked_symlink(file, fntmp);
alternative_add_commit_op(a, OPCODE_MV, fntmp, fn);
free(fntmp);
 
linktmp = xasprintf("%s%s", dpkg_root, linkname);
-   if (alternative_path_needs_update(linktmp, fn)) {
+   if (alternative_path_needs_update(linktmp, fnlink)) {
/* Create alternative link. */
fntmp = xasprintf("%s" ALT_TMP_EXT, linktmp);
checked_rm(fntmp);
-   checked_symlink(fn, fntmp);
+   checked_symlink(fnlink, fntmp);
alternative_add_commit_op(a, OPCODE_MV, fntmp, linktmp);
free(fntmp);
}
@@ -1898,7 +1900,7 @@ alternative_has_broken_slave(struct slave_link *sl, 
struct fileset *fs)
sl_altlnk = areadlink(sl->link);
if (!sl_altlnk)
return true;
-   wanted = xasprintf("%s/%s", altdir, sl->name);
+   wanted = xasprintf("%s/%s", altdir_as_prefix, sl->name);
if (strcmp(sl_altlnk, wanted) != 0) {
free(wanted);
free(sl_altlnk);
@@ -1921,7 +1923,7 @@ alternative_has_broken_slave(struct slave_link *sl, 
struct fileset *fs)
/* Slave link must not exist. */
if (alternative_path_classify(sl->link) != ALT_PATH_MISSING)
return true;
-   sl_altlnk = xasprintf("%s/%s", altdir, sl->name);
+   sl_altlnk = xasprintf("%s/%s", altdir_as_prefix, sl->name);
if (alternative_path_classify(sl_altlnk) != ALT_PATH_MISSING) {
free(sl_altlnk);
return true;
@@ -1945,7 +1947,7 @@ alternative_needs_update(struct alternative *a)
altlnk = areadlink(a->master_link);
if (!altlnk)
return ALT_UPDATE_LINK_BROKEN;
-   wanted = xasprintf("%s/%s", altdir, a->master_name);
+   wanted = xasprintf("%s/%s", altdir_as_prefix, a->master_name);
if (strcmp(altlnk, wanted) != 0) {
free(wanted);
free(altlnk);
@@ -2593,6 +2595,7 @@ main(int argc, char **argv)
admdir = admindir_init();
dpkg_root = dpkg_root_init();
altdir = altdir_init();
+   altdir_as_prefix = altdir + strlen(dpkg_root);
 
if (setvbuf(stdout, NULL, _IONBF, 0))
syserr("setvbuf failed");
@@ -2717,6 +2720,9 @@ main(int argc, char **argv)
if (MISSING_ARGS(1))
badusage(_("--%s needs a  
argument"), "log");
altdir = argv[i + 1];
+   if (strlen(altdir) < strlen(dpkg_root) || 
memcmp(dpkg_root, altdir, strlen(dpkg_root)))
+   badusage(_("--%s needs to start with 
DPKG_ROOT"), "log");
+   altdir_as_prefix = altdir + strlen(dpkg_root);
i++;
} else if (strcmp("--admindir", argv[i]) == 0) {
if (MISSING_ARGS(1))
-- 
2.13.3


signature.asc
Description: PGP signature

Bug#871808: u-a should follow DPKG_ROOT

[chrysn]

Package: dpkg
Version: 1.19.0
Severity: wishlist
File: /usr/bin/update-alternatives
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support

The update-alternatives program, when run from a maintainer script with
DPKG_ROOT set, should respect that variable in order to facilitate
bootstrap installations[1].

There is a patch available at [2]/[3] in which OpenEmbedded implement
this (they call it "offline mode"); that patch doesn't apply anymore
though since the latest update-alternative changes, and AFAICT would
only work if the installation directory was the current working
directory (which AFAIK is not guaranteed by dpkg).

Given that update-alternatives already respects DPKG_ADMINDIR, it should
be sufficient to adapt altdir to prepend DPKG_ROOT; I'm just trying a
small patch to that.


Note that this is distinct from #77828 which was about using u-a for user
homes, while this just happens to mean that a user can also use u-a but
in an out-of-root Debian installation.

[1]: https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap?action=subscribe
[2]: https://lists.debian.org/debian-dpkg/2016/12/msg4.html
[3]: https://patchwork.openembedded.org/patch/134905/

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

Kernel: Linux 4.12.0 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-14
ii  liblzma5 5.2.2-1.3
ii  libselinux1  2.6-3+b2
ii  tar  1.29b-2
ii  zlib1g   1:1.2.8.dfsg-5

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.5~beta1
pn  debsig-verify  

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#871048: ui-gtk: duplicate list is not clear about steps forward

[chrysn]

Package: reportbug
Version: 7.1.7
Severity: minor
Tags: patch

The text user interface is pretty clear about what to do with the list
of already reported bugs

"Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]?"

with a sane default. The equivalent screen in the gtk user interface
does not contain any instruction on what to do if none match (which
would be pressing next).

I suggest that the "Double-click a bug to retrieve and submit more
information." should be ammended to ", or press 'Next' if none match.";
a patch is attached.

Thanks
chrysn

-- Package-specific info:
** Environment settings:
EDITOR="vim"
EMAIL="chr...@fsfe.org"
INTERFACE="text"

** /home/chrysn/.reportbugrc:
reportbug_version "4.4"
mode expert
ui text
realname "chrysn"

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

Kernel: Linux 4.12.0 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages reportbug depends on:
ii  apt1.5~beta1
ii  python33.5.3-3
ii  python3-reportbug  7.1.7

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail   
ii  debconf-utils1.5.63
ii  debsums  2.2.2
ii  dlocate  1.07+nmu1
pn  emacs24-bin-common | emacs25-bin-common  
ii  file 1:5.30-1
ii  gir1.2-gtk-3.0   3.22.17-1
ii  gir1.2-vte-2.91  0.46.2-1
ii  gnupg2.1.18-8
ii  nullmailer [mail-transport-agent]1:1.13-1.2
ii  python3-gi   3.22.0-2.1
ii  python3-gi-cairo 3.22.0-2.1
pn  python3-gtkspellcheck
pn  python3-urwid
ii  xdg-utils1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.5~beta1
ii  file   1:5.30-1
ii  python33.5.3-3
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.18.1-1

python3-reportbug suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom
diff --git a/reportbug/ui/gtk2_ui.py b/reportbug/ui/gtk2_ui.py
index fe97201..c80a2ab 100644
--- a/reportbug/ui/gtk2_ui.py
+++ b/reportbug/ui/gtk2_ui.py
@@ -1188,7 +1188,7 @@ class HandleBTSQueryPage(TreePage):
 
 def execute(self, buglist, sectitle):
 _assert_context(ui_context)
-GLib.idle_add(self.label.set_text, "%s. Double-click a bug to retrieve and submit more information." % sectitle)
+GLib.idle_add(self.label.set_text, "%s. Double-click a bug to retrieve and submit more information, or press 'Next' if none match." % sectitle)
 
 self.model = Gtk.TreeStore(*([str] * len(self.columns)))
 for category in buglist:


signature.asc
Description: PGP signature

Bug#871040: consider using submission rather than smtp

[chrysn]

Package: reportbug
Version: 7.1.7
Severity: wishlist

When reportbug is using SMTP, I think it should consider (or even
prefer) port 587 (submission) rather than 25 (SMTP).

User story behind this (which just happened): A novice user (whose
devices typically don't have any reliable SMTP setup) reporting their
first bug gets asked about mail sending prefernces, doesn't know a thing
about "MTA"s and sensibly picks the default option of not having any set
up, and is then asked for mail sending host and user name.

They look up their mail provider's data, but it being a modern provider
would need to use submission rather than SMTP, or otherwise

* the SMTP port is not open
* the mail cold not be accepted
* there would not be SSL enabled on SMTP (that's what happened in my
  case)
* port 25 might be blocked by a middle box (which is unfortunate but
  widespread)
* spam filtering might trigger because the mail is sent via SMTP from a
  dynamic IP block that shows up in several block lists


Please consider at least falling back to trying submission when any of
the above happen, or just as a default.

If the Debian mail server skips the last item (eg. by disabling the
default spamassassin rules against the behavior), reportbug could
instead just as well submit mails directly to the MX of bugs.debian.org
in novice mode (but I suppose there are good reasons why this is not
done).

Best regards
chrysn

-- Package-specific info:
** Environment settings:
EDITOR="vim"
EMAIL="chr...@fsfe.org"
INTERFACE="text"

** /home/chrysn/.reportbugrc:
reportbug_version "4.4"
mode expert
ui text
realname "chrysn"

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

Kernel: Linux 4.12.0 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages reportbug depends on:
ii  apt1.5~beta1
ii  python33.5.3-3
ii  python3-reportbug  7.1.7

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail   
ii  debconf-utils1.5.63
ii  debsums  2.2.2
ii  dlocate  1.07+nmu1
pn  emacs24-bin-common | emacs25-bin-common  
ii  file 1:5.30-1
ii  gir1.2-gtk-3.0   3.22.17-1
ii  gir1.2-vte-2.91  0.46.2-1
ii  gnupg2.1.18-8
ii  nullmailer [mail-transport-agent]1:1.13-1.2
ii  python3-gi   3.22.0-2.1
ii  python3-gi-cairo 3.22.0-2.1
pn  python3-gtkspellcheck
pn  python3-urwid
ii  xdg-utils1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.5~beta1
ii  file   1:5.30-1
ii  python33.5.3-3
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.18.1-1

python3-reportbug suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#871039: spam: testing reportbug

[chrysn (as a tester)]

Package: spam
Severity: normal

Dear Maintainer,

test report, please ignore (testing smtp/submission).

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

Kernel: Linux 4.12.0 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#870750: reproducibly build packages where possible

[chrysn]

Package: dpkg-repack
Version: 1.43
Severity: wishlist
Tags: patch

Playing around with dpkg-repack I noticed that even in the case of
packages where there is no modification that'd make it impossible,
dpkg-repack never generates perfect replicas of the original packages.


With the attached patch, dpkg-repack inspects the installed package's
changelog file for a suitable timestamp for SOURCE_DATE_EPOCH and sets
it if appropriate. With --tag=none, this gives byte-perfect replicas of
the packages I've tested it against unless they had local / config /
post-inst modifications.

I'd envision that a --tag=auto feature go well with that (that adds a
version tag if the md5sums indicate that the package changed), but
that's not implemented in the current patch and I don't know if the
md5sums criterion would be sufficient (eg. to see whether file ownership
was changed in postinst).


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

Kernel: Linux 4.12.0 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dpkg-repack depends on:
ii  libdpkg-perl  1.18.24
ii  perl  5.26.0-5

dpkg-repack recommends no packages.

Versions of packages dpkg-repack suggests:
ii  fakeroot  1.21-3.1

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom
From 782b2e9c90fb6f9ab682bb91b179af46a72f605b Mon Sep 17 00:00:00 2001
From: chrysn 
Date: Fri, 4 Aug 2017 17:38:30 +0200
Subject: [PATCH] dpkg calls: Respond to error codes

Contributes-To: https://bugs.debian.org/870724
---
 dpkg-repack | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/dpkg-repack b/dpkg-repack
index 920f434..6f65499 100755
--- a/dpkg-repack
+++ b/dpkg-repack
@@ -131,9 +131,9 @@ sub Extract_Status {
 my $inst = Dpkg::Control->new(type => CTRL_FILE_STATUS);
 
 open my $fh, '-|', 'dpkg', "--root=$rootdir/", '-s', $pkgname
-or Die "Unable to locate $pkgname in the package list.";
+or Die "Failed to fork dpkg.";
 $inst->parse($fh, "dpkg status for $pkgname");
-close $fh;
+close $fh or Die "`dpkg -s` failed (status " . ($? >> 8) . ").";
 
 if ($inst->{Status} !~ m/^\S+\s+\S+\s+installed$/) {
 Die "Package $pkgname not fully installed: $inst->{Status}";
@@ -184,12 +184,12 @@ sub Install_DEBIAN {
 
 my @control_files;
 open my $q_fh, '-|', "dpkg-query --admindir=$rootdir/var/lib/dpkg --control-path $inst->{Package} 2>/dev/null"
-or Die "dpkg-query failed: $!";
+or Die "Failed to fork dpkg.";
 while (my $fn = <$q_fh>) {
 chomp $fn;
 push @control_files, $fn;
 }
-close $q_fh;
+close $q_fh or Die "`dpkg-query` failed (status " . ($? >> 8) . ").";
 
 foreach my $fn (@control_files) {
 my ($basename) = $fn =~ m/^.*\.(.*?)$/;
@@ -233,7 +233,11 @@ sub Install_Files {
 # it runs with English language output.
 my $lc_all = $ENV{LC_ALL};
 $ENV{LC_ALL} = 'C';
-my @filelist = split /\n/, qx{dpkg --root=$rootdir/ -L $inst->{Package}};
+my $filelist = qx{dpkg --root=$rootdir/ -L $inst->{Package}:$inst->{Architecture}};
+if ($? != 0) {
+Die "`dpkg -L` failed (status " . ($? >> 8) . ").";
+}
+my @filelist = split /\n/, $filelist;
 $ENV{LC_ALL} = $lc_all if defined $lc_all; # important to reset it.
 
 # Set up a hash for easy lookups.
-- 
2.13.2



signature.asc
Description: PGP signature

Bug#870724: can't repackage multiarch libraries

[chrysn]

On Fri, Aug 04, 2017 at 05:56:12PM +0200, chrysn wrote:
> In going through the code, I found several places where dpkg error codes
> were ignored (will send patch to this bug when I've worked out the last
> error code); [...]

I think that this patch would have made spotting the errors easier, and
make good future-proofing:

From 782b2e9c90fb6f9ab682bb91b179af46a72f605b Mon Sep 17 00:00:00 2001
From: chrysn 
Date: Fri, 4 Aug 2017 17:38:30 +0200
Subject: [PATCH] dpkg calls: Respond to error codes

Contributes-To: https://bugs.debian.org/870724
---
 dpkg-repack | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/dpkg-repack b/dpkg-repack
index 920f434..6f65499 100755
--- a/dpkg-repack
+++ b/dpkg-repack
@@ -131,9 +131,9 @@ sub Extract_Status {
 my $inst = Dpkg::Control->new(type => CTRL_FILE_STATUS);
 
 open my $fh, '-|', 'dpkg', "--root=$rootdir/", '-s', $pkgname
-or Die "Unable to locate $pkgname in the package list.";
+or Die "Failed to fork dpkg.";
 $inst->parse($fh, "dpkg status for $pkgname");
-close $fh;
+close $fh or Die "`dpkg -s` failed (status " . ($? >> 8) . ").";
 
 if ($inst->{Status} !~ m/^\S+\s+\S+\s+installed$/) {
 Die "Package $pkgname not fully installed: $inst->{Status}";
@@ -184,12 +184,12 @@ sub Install_DEBIAN {
 
 my @control_files;
 open my $q_fh, '-|', "dpkg-query --admindir=$rootdir/var/lib/dpkg 
--control-path $inst->{Package} 2>/dev/null"
-or Die "dpkg-query failed: $!";
+or Die "Failed to fork dpkg.";
 while (my $fn = <$q_fh>) {
 chomp $fn;
 push @control_files, $fn;
 }
-close $q_fh;
+close $q_fh or Die "`dpkg-query` failed (status " . ($? >> 8) . ").";
 
 foreach my $fn (@control_files) {
 my ($basename) = $fn =~ m/^.*\.(.*?)$/;
@@ -233,7 +233,11 @@ sub Install_Files {
 # it runs with English language output.
 my $lc_all = $ENV{LC_ALL};
 $ENV{LC_ALL} = 'C';
-my @filelist = split /\n/, qx{dpkg --root=$rootdir/ -L $inst->{Package}};
+my $filelist = qx{dpkg --root=$rootdir/ -L 
$inst->{Package}:$inst->{Architecture}};
+if ($? != 0) {
+Die "`dpkg -L` failed (status " . ($? >> 8) . ").";
+}
+my @filelist = split /\n/, $filelist;
 $ENV{LC_ALL} = $lc_all if defined $lc_all; # important to reset it.
 
 # Set up a hash for easy lookups.
-- 
2.13.2


signature.asc
Description: PGP signature

Bug#870724: can't repackage multiarch libraries

[chrysn]

On Fri, Aug 04, 2017 at 04:53:01PM +0200, Guillem Jover wrote:
> I've fixed this locally with an additional ":$inst->{Architecture}" to
> the dpkg -L call, but might switch back to using $pkgname as passed
> by the user for greated backwards compat with older dpkg versions.

In going through the code, I found several places where dpkg error codes
were ignored (will send patch to this bug when I've worked out the last
error code); if you already consider going back to pkgname, I won't look
for where inst->Architecture needs to be added exactly any more.

Thanks
chrysn

-- 
This may seem a bit weird, but that's okay, because it is weird.
  -- perldata(1) about perl variables


signature.asc
Description: PGP signature

Bug#870724: can't repackage multiarch libraries

[chrysn]

Package: dpkg-repack
Version: 1.43
Severity: normal

| dpkg-repack does not produce a proper .deb for packages that are
| multiply installed via multiarch, eg. libpng16-16:amd64. i tried various
| approaches:
| 
| $ dpkg-repack libpng16-16
| dpkg-query: error: --status needs a valid package name but 'libpng16-16' is 
not: ambiguous package name 'libpng16-16' with more than one installed instance
| 
| Use --help for help about querying packages.
| Use of uninitialized value in pattern match (m//) at /usr/bin/dpkg-repack 
line 138.
| Use of uninitialized value in concatenation (.) or string at 
/usr/bin/dpkg-repack line 139.
| dpkg-repack: Fatal Error: Package libpng16-16 not fully installed:

| $ dpkg-repack libpng16-16:amd64
| dpkg-query: error: --listfiles needs a valid package name but 'libpng16-16' 
is not: ambiguous package name 'libpng16-16' with more than one installed 
instance
| 
| Use --help for help about querying packages.
| dpkg-deb: building package 'libpng16-16' in 
'./libpng16-16_1.6.29-3_amd64.deb'.

| $ dpkg-repack libpng16-16 --arch amd64
| dpkg-query: error: --status needs a valid package name but 'libpng16-16' is 
not: ambiguous package name 'libpng16-16' with more than one installed instance
| 
| Use --help for help about querying packages.
| Use of uninitialized value in pattern match (m//) at /usr/bin/dpkg-repack 
line 138.
| Use of uninitialized value in concatenation (.) or string at 
/usr/bin/dpkg-repack line 139.
| dpkg-repack: Fatal Error: Package libpng16-16 not fully installed:

| $ dpkg-repack libpng16-16:amd64 --arch amd64
| dpkg-query: error: --listfiles needs a valid package name but 'libpng16-16' 
is not: ambiguous package name 'libpng16-16' with more than one installed 
instance
| 
| Use --help for help about querying packages.
| dpkg-deb: building package 'libpng16-16' in 
'./libpng16-16_1.6.29-3_amd64.deb'.

The :amd64 ones actually produce empty (control file only) .deb files.

For a quick fix, I needed to add some more :amd64 throughout
dpkg-repack, but I'll look into it more deeply to see whether I can
produce a proper patch.


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

Kernel: Linux 4.12.0 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dpkg-repack depends on:
ii  libdpkg-perl  1.18.24
ii  perl

dpkg-repack recommends no packages.

Versions of packages dpkg-repack suggests:
ii  fakeroot  1.21-3.1

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#851651: still in 1.13.1, test config

[chrysn]

found 851651 1.13.1-2
thanks

For testing of the behavior, I used

$ touch /tmp/"foo bar"
$ /usr/sbin/nginx -c /tmp/localwebdav.conf &
$ thunar dav://localhost:1234/

which shows a file "foo%20bar" in the list.

--- /tmp/localwebdav.conf:

pid /tmp/nginx_pid;
error_log /dev/stderr;

daemon off;
load_module modules/ngx_http_dav_ext_module.so;

events {
worker_connections 768;
# multi_accept on;
}

http {
access_log /dev/stdout;
server {
listen [::]:1234 ipv6only=off;
root /tmp;

dav_ext_methods PROPFIND OPTIONS;
}
}


signature.asc
Description: PGP signature

Bug#864071: [Pkg-utopia-maintainers] Bug#864071: SIGSEGV when connecting to bluetooth network

[chrysn]

Hello Michael,

On Sun, Jun 04, 2017 at 12:37:12AM +0200, Michael Biebl wrote:
> Probably https://bugzilla.gnome.org/show_bug.cgi?id=782545
> 
> Could you try the patch mentioned in the upstream bug tracker?

tried the patch, and it solves the issue.

Thanks for your quick reaction, and sorry for not having found the
upstream bug myself

chrysn


signature.asc
Description: PGP signature

Bug#864071: SIGSEGV when connecting to bluetooth network

[chrysn]

Package: network-manager
Version: 1.8.0-2
Severity: normal

When I connect to the Bluetooth connection to an Android cellphone I
paired via bluetooth using blueman, network-manager segfaults.
Backtrace:

(gdb) bt
#0  0x55609794 in nm_ip6_config_capture (platform=, 
ifindex=ifindex@entry=0,
capture_resolv_conf=capture_resolv_conf@entry=0, 
use_temporary=use_temporary@entry=NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN)
at src/nm-ip6-config.c:368
#1  0x55659101 in act_stage3_ip6_config_start (self=0x55c3bce0, 
out_config=,
out_failure_reason=) at src/devices/nm-device.c:7727
#2  0x55668f71 in nm_device_activate_stage3_ip6_start 
(self=self@entry=0x55c3bce0) at src/devices/nm-device.c:7845
#3  0x5566a2f0 in activate_stage3_ip_config_start (self=0x55c3bce0) 
at src/devices/nm-device.c:7922
#4  0x5564f1f2 in activation_source_handle_cb (self=0x55c3bce0, 
family=family@entry=2)
at src/devices/nm-device.c:4453
#5  0x5564f2de in activation_source_handle_cb4 (user_data=) at src/devices/nm-device.c:4390
#6  0x76b776aa in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x76b77a60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x76b77d82 in g_main_loop_run () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x55580de3 in main (argc=, argv=) at 
src/main.c:435
(gdb)

Based on the trace, I set IPv6 on that interface to "ignore"; the link
then works as expected.

Please let me know if and which other debug information you might need.

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

Kernel: Linux 4.11.0-rc2+ (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.18-1
ii  init-system-helpers1.48
ii  libaudit1  1:2.6.7-2
ii  libbluetooth3  5.43-2
ii  libc6  2.24-11
ii  libcurl3-gnutls7.52.1-5
ii  libglib2.0-0   2.50.3-2
ii  libgnutls303.5.8-5
ii  libjansson42.9-1
ii  libmm-glib01.6.4-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-1
ii  libnl-3-2003.2.27-2
ii  libnm0 1.8.0-2
ii  libpam-systemd 232-24
ii  libpolkit-agent-1-00.105-18
ii  libpolkit-gobject-1-0  0.105-18
ii  libpsl50.17.0-4
ii  libreadline7   7.0-3
ii  libselinux12.6-3+b1
ii  libsystemd0232-24
ii  libteamdctl0   1.26-1+b1
ii  libudev1   232-24
ii  libuuid1   2.29.2-1
ii  lsb-base   9.20161125
ii  policykit-10.105-18
ii  udev   232-24
ii  wpasupplicant  2:2.4-1

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base 2.77-1
ii  iptables 1.6.0+snapshot20161117-6
ii  iputils-arping   3:20161105-1
ii  isc-dhcp-client  4.3.5-3
ii  modemmanager 1.6.4-1
ii  ppp  2.4.7-1+4

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#861244: New version available fixing render issues

[chrysn]

Package: libopencsg1
Version: 1.4.0-1+b2
Severity: normal

A new version (1.4.2) is available and was reported to fix rendering
issues on Intel graphics cards (irc://freenode.org/#openscad 2017-04-23).

I'll prepare an updated package as soon as I find some time.


signature.asc
Description: PGP signature

Bug#858904: openscad: opengl / x11 strange "hanging" error (also found in other packages)

[chrysn]

Hi,

On Tue, Mar 28, 2017 at 01:56:21PM +0100, lkcl wrote:
> the issue appears to be that a race condition causes a frame to be
> dropped.  however once there is only one frame dropped, *all*
> subsequent frames stop from that point onwards.

that is a tricky one.

I've tried to reproduce the issue with octave-gui as described in
#848895 (even under full CPU load as "helped" with the chromium
version), but it did not trigger a lockup on my machine.

Are there any other known ways to trigger this (to find out which
machines are affected at all), or to trigger this in OpenSCAD?

Best regards
chrysn


signature.asc
Description: PGP signature

Bug#855322: README.Debian should mention necessity to add infect line to .vimrc

[chrysn]

Package: vim-pathogen
Version: 2.4-1
Severity: minor

While pathogen can be easily installed via package and `vim-addons
install`, that step is *not* sufficient to get a working setup, even
though a symlink is placed in ~/.vim/autoload/. The pathogen.vim does
explain that adding the ``execute pathogen#infect()`` line to one's
.vimrc is necessary, but that's not where I'd usually look.

Please consider either adding a line like this to README.Debian:

| After installation, add the line
| 
| execute pathogen#infect()
| 
| at the top of your .vimrc.

Alternatively, I think it would be OK if the addon installation actually
added an infect step to VIM's autoload; other plugins become active
after vim-addons install too.


Thanks for maintaining this package
chrysn

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

Kernel: Linux 4.10.0-rc5+ (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages vim-pathogen depends on:
ii  vim2:8.0.0197-2
ii  vim-addon-manager  0.5.6
ii  vim-gtk3 [vim] 2:8.0.0197-2

Versions of packages vim-pathogen recommends:
ii  vim-scripts  20130814

vim-pathogen suggests no packages.

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#851651: displayName is percent-encoded

[chrysn]

Package: libnginx-mod-http-dav-ext
Version: 1.10.2-3
Severity: normal
Tag: patch

When directories are shown using libnginx-mod-http-dav-ext that need
percent-encoding to have valid URLs, their `displayName`s are wrongly
percent-encoded. As a result, some WebDAV viewers (those that show the
displayName instead of the URL path component, like XFCE's Thunar or
Gnome's Nautilus) show percent-encoded items to the user in the
directory listing.

A patch is available at the upstream bug tracker at [1], it might be
worth applying to the package.

[1]: https://github.com/arut/nginx-dav-ext-module/pull/17

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

Kernel: Linux 4.10.0-rc3+ (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libnginx-mod-http-dav-ext depends on:
ii  libc6 2.24-8
ii  libexpat1 2.2.0-2
ii  nginx-common  1.10.2-3

libnginx-mod-http-dav-ext recommends no packages.

libnginx-mod-http-dav-ext suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#782054: mbsync: New version cannot open Maildir boxes

[chrysn]

I just checked whether the patch of
0f24ca31b5fafe5228d0e99f460f1c823121b296 could be trivially applied, but
it does not even apply with fuzz, and has "both modified" sections in
several places.

Oswald, do you think you could apply that patch to the 1.2 branch?

Thanks
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#844543: new version available

[chrysn]

Source: aiocoap
Followup-For: Bug #844543

hello tin, 

i've recently released 0.3; that's probably late for stretch, but still
worth a try!

best regards
chrysn


signature.asc
Description: PGP signature

Bug#841314: dh-python: generated dependencies should be constrained by Build-Depends versions

[chrysn]

Package: dh-python
Version: 2.20160818
Followup-For: Bug #841314

When this feature gets added, would it look at all build dependencies
(and not only those active in the current profile when doing a profiled
build)? In rdflib, I need to provide a "nocheck nodoc" profile to avoid
dependency loops, but even nocheck builds will have the Recommends to
some build-depended-on packages, and should take their version limit
from there.

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

Kernel: Linux 4.9.0-rc2 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dh-python depends on:
pn  python3:any  

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  libdpkg-perl  1.18.15

-- no debconf information


signature.asc
Description: PGP signature

Bug#845643: python{,3}-{html5lib,sparqlwrapper} should be i-deps of python{,3}-rdflib

[chrysn]

Both for sparqlwrapper and for rdflib, there are now fixed versions in
VCS ([1], [2]) that declare their dependencies not only inside Debian
but also in their egg-info.

The sparqlwrapper changes are already accepted upstream, rdflib changes
are pending there.

Andreas, could you sponsor these uploads again?

Thanks
chrysn

[1]: debcheckout sparql-wrapper-python
  latest head should be d9eea45ec77afd435e0b5d0560884caf47dc
[2]: git clone https://anonscm.debian.org/git/collab-maint/rdflib.git --
  latest head should be 81c32657796d03b24d6285fbd40886e4cfb4a81b


signature.asc
Description: PGP signature

Bug#847304: documentation mismatch on --recommends-section=sparql

[chrysn]

Package: dh-python
Version: 2.20160818
Severity: minor
File: /usr/bin/dh_python3

While dh_python[23] accept repeated --recommends-section=S arguments,
the dh_python3 man page describes an option with
--recommends-sections=SECTIONS (single plural argument instead of
repeated singular ones), and the dh_python2 man page does not show it at
all. The output of --help on the utilities is correct.

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

Kernel: Linux 4.9.0-rc2 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dh-python depends on:
pn  python3:any  

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  libdpkg-perl  1.18.15

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#845643: python{,3}-{html5lib,sparqlwrapper} should be i-deps of python{,3}-rdflib

[chrysn]

On Mon, Dec 05, 2016 at 06:04:38PM +0100, chrysn wrote:
> Anyhow, I failed to build the package even before it came to the unit
> tests due to the keepalive dependency.

Just a short update: that issue was also reported in #846871; I'll see
to that and then have a look at whether maybe the html5lib issues are up
the same alley.

Best regards
chrysn


signature.asc
Description: PGP signature

Bug#845643: python{,3}-{html5lib,sparqlwrapper} should be i-deps of python{,3}-rdflib

[chrysn]

Hello Ghis,

On Mon, Dec 05, 2016 at 02:14:56PM +, Ghislain Vaillant wrote:
> The build FTBFS due to a failed query on html5lib at test time. Since the
> prov module does not explicitly depend on the latter, it had to be missing
> transitively from rdflib.
>
> Upon inspection of the packaging repository, I noticed that html5lib is
> listed as recommends and that automatic dependency resolution via dh-python
> is explicitly disabled.

rdflib is usually well usable without the html5lib module, there *should*
be just the RDFa and microdata extraction affected; that does sound like
a legit case for 'Recommends' to me. The source code is explicitly
prepared to only fail on html5lib import errors if that functionality is
actually required. The presence of requirements.py?.txt seems to be only
due to the lack of Depends/Recommends distinction in the Python tools.

I had a look at the prov package and `uscan`ed the latest upstream
version into it. Were RDFa or microdata examples in the tests, I'd have
said that you should probably build-depend on html5lib (for the tests
depend on it), but the tests actually don't look like it. Anyhow, I
failed to build the package even before it came to the unit tests due to
the keepalive dependency. Could you publish your state of packaging for
me to reproduce the build issues you're having, or send a backtrace of
the failing tests?

Best regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#838849: rdflib upload (was: Re: Bug#843397: python-rdflib-jsonld: Requires python-rdflib 4.2.1) to work properly with schema.org contexts

[chrysn]

Hello Andreas,

(tl;dr: all fixed, please build and upload).

On Thu, Nov 17, 2016 at 04:45:51PM +0100, Andreas Tille wrote:
> While I have fixed the clean target in Git to make the build start at
> all [...]

Thanks for the fix. It does not solve the whole issue of the clean
target (that's an open TODO point in the package -- upstream seems to do
its 2to3 in clean), but it does ensure double-buildability again.


> [...] there is one remaining unit test error:
> 
> ...
> No SPARQL endpoint for SPARQLUpdateStore (tests skipped)
> Exception: RDFa parsing Error! __init__() got an unexpected keyword argument 
> 'encoding'
> 
> Any idea?

Now yes: there is a circular build dependency I did not catch, and an
already troublesome test case selected the old (installed) version,
which didn't show up in my cowbuilder tests as I needed local repos back
then to satisfy the sparqlwrapper build dependency.

A fix (disabling the offending tests) is in place until I've worked out
how this should run properly with upstream; it's still a circular
build-dep to be fixed, but as long as there are RC bugs open, I'd like
to get the basics done first and then do the shining.

The debian branch (5c368a6433a3d) contains a cowbuilder-building and
working version; please sponsor that as an upload.

> PS: If you need help to make the repository DPMT compliant I'd volunteer to
> take over this task if you want me to do so.

Thanks, but unless you plan to do more on the package where the lack of
DPMT configuration would be hindering to you, I'd like to use that
package to practice git-dpm and to practically implement DPMT policy;
I'd be happy to have the result of that reviewed, though, when bringing
the package into the team.

Best regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature