Bug#995147: StatVFS test is flaky

[Alois Micard]

Source: golang-github-pkg-sftp
Severity: important
Tags: upstream
X-Debbugs-Cc: creekor...@debian.org
Control: forwarded ! https://github.com/pkg/sftp/issues/463

The test StatVFS is a flaky one and therefore may
fails our autopkgtests from time  to time.


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

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

Bug#995133: python3-gpumodules: Error parsing amdfeaturemask

[Andrius Merkys]

Control: fixed 995133 3.6.0
Control: tags 995133 + fixed-upstream pending

Hi,

On 2021-09-27 00:04, Gregor Riepl wrote:
> gpu-pac currently fails on my system because of a hex string parsing issue in
> python3-gpumodules:
> 
> Traceback (most recent call last):
>   File "/usr/bin/gpu-pac", line 1323, in 
> main()
>   File "/usr/bin/gpu-pac", line 1274, in main
> gpu_list.set_gpu_list()
>   File "/usr/lib/python3/dist-packages/GPUmodules/GPUmodule.py", line 1666, in
> set_gpu_list
> self.amd_featuremask = env.GUT_CONST.read_amdfeaturemask()
>   File "/usr/lib/python3/dist-packages/GPUmodules/env.py", line 205, in
> read_amdfeaturemask
> self.amdfeaturemask = int(fm_file.readline())
> ValueError: invalid literal for int() with base 10: '0xbfff\n'
> 
> This issue is fixed in gpu-utils 3.6.0. Please push an upgrade.

I have pushed 3.6.0 some time ago, it is in NEW queue now.

Thanks,
Andrius

Bug#994873: libdrm-dev: mssing dependency on valgrind

[Andre Heider]

I did some more digging and it looks like valgrind can just be disabled:
https://salsa.debian.org/xorg-team/lib/libdrm/-/blob/debian-unstable/meson.build#L256

And AFAICT it's only used for debugging purposes ("ioctl annotations"), 
on intel and freedreno:

$ git grep HAVE_VALGRIND
freedreno/freedreno_priv.h:#if HAVE_VALGRIND
intel/intel_bufmgr_gem.c:#if HAVE_VALGRIND
intel/intel_bufmgr_gem.c:#if HAVE_VALGRIND
intel/intel_bufmgr_gem.c:#if HAVE_VALGRIND

For comparison:

arch disables it:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=libdrm-git#n43

suse too (if I read that "%if 0%{?with_valgrind_support:1}" correctly):
https://build.opensuse.org/package/view_file/openSUSE:Factory/libdrm/libdrm.spec?expand=1

fedora enables it on supported arch (but has a valgrind-devel package)
https://src.fedoraproject.org/rpms/libdrm/blob/rawhide/f/libdrm.spec

I propose to:
- disable valgrind for now
- reenable it once there's a multiarch compatible valgrind-devel package
  See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731228

Bug#995146: Acknowledgement (ssh -M (ControlMaster) triggers "tinysshd: W19qgD40: BUG: (protocol error){channel.c:57}")

[Trent W. Buck]

I can reproduce this using the version in salsa also:

bash5$ ssh -F/dev/null -oUserKnownHostsFile=/dev/null 
-oStrictHostKeyChecking=no root@localhost -p2022 dpkg-query -W base-files 
tinysshd linux-image-cloud-amd64
Warning: Permanently added '[localhost]:2022' (ED25519) to the list of 
known hosts.
base-files  11.1
linux-image-cloud-amd64 5.10.46-5
tinysshd20210601-1


bash5$ screen ssh -F/dev/null -oUserKnownHostsFile=/dev/null 
-oStrictHostKeyChecking=no root@localhost -p2022 -oControlMaster=auto 
-oControlPath=~/.ssh/master-%C -oControlPersist=3600
bash5$ screen ssh -F/dev/null -oUserKnownHostsFile=/dev/null 
-oStrictHostKeyChecking=no root@localhost -p2022 -oControlMaster=auto 
-oControlPath=~/.ssh/master-%C -oControlPersist=3600


bash5$ ssh -F/dev/null -oUserKnownHostsFile=/dev/null 
-oStrictHostKeyChecking=no root@localhost -p2022 systemctl --state=failed
Warning: Permanently added '[localhost]:2022' (ED25519) to the list of 
known hosts.
  UNIT   LOAD   ACTIVE SUB
DESCRIPTION
● tinysshd@1-10.0.2.15:22-10.0.2.2:38228.service loaded failed failed Tiny 
SSH server (10.0.2.2:38228)

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB= The low-level unit activation state, values depend on unit type.
1 loaded units listed.


bash5$ ssh -F/dev/null -oUserKnownHostsFile=/dev/null 
-oStrictHostKeyChecking=no root@localhost -p2022 systemctl status 
tinysshd@1-10.0.2.15:22-10.0.2.2:38228.service
Warning: Permanently added '[localhost]:2022' (ED25519) to the list of 
known hosts.
● tinysshd@1-10.0.2.15:22-10.0.2.2:38228.service - Tiny SSH server 
(10.0.2.2:38228)
 Loaded: loaded (/lib/systemd/system/tinysshd@.service; disabled; 
vendor preset: enabled)
 Active: failed (Result: exit-code) since Mon 2021-09-27 14:56:27 AEST; 
18s ago
TriggeredBy: ● tinysshd.socket
   Docs: man:tinysshd
Process: 414 ExecStartPre=/usr/sbin/tinysshd-makekey -q 
/etc/tinyssh/sshkeydir (code=exited, status=111)
Process: 415 ExecStart=/usr/sbin/tinysshd ${TINYSSHDOPTS} -- 
/etc/tinyssh/sshkeydir (code=exited, status=111)
   Main PID: 415 (code=exited, status=111)
CPU: 193ms

Sep 27 14:56:26 main.lan systemd[1]: Starting Tiny SSH server 
(10.0.2.2:38228)...
Sep 27 14:56:26 main.lan systemd[1]: Started Tiny SSH server 
(10.0.2.2:38228).
Sep 27 14:56:26 main.lan tinysshd[415]: tinysshd: 9ZEQRTtP: info: 
connection from 10.0.2.2:38228 {main_tinysshd.c:106}
Sep 27 14:56:26 main.lan tinysshd[415]: tinysshd: 9ZEQRTtP: info: auth: 
root: ssh-ed25519 
C3NzaC1lZDI1NTE5IIapAZ0E0353DaY6xBnasvu/DOvdWdKQ6RQURwq4l6Wu accepted 
{packet_auth.c:155}
Sep 27 14:56:27 main.lan tinysshd[415]: tinysshd: 9ZEQRTtP: BUG:  (protocol 
error){channel.c:57}
Sep 27 14:56:27 main.lan systemd[1]: 
tinysshd@1-10.0.2.15:22-10.0.2.2:38228.service: Main process exited, 
code=exited, status=111/n/a
Sep 27 14:56:27 main.lan systemd[1]: 
tinysshd@1-10.0.2.15:22-10.0.2.2:38228.service: Failed with result 'exit-code'.
Sep 27 14:56:27 main.lan systemd[1]: 
tinysshd@1-10.0.2.15:22-10.0.2.2:38228.service: Unit process 418 (bash) remains 
running after unit stopped.

Bug#995146: ssh -M (ControlMaster) triggers "tinysshd: W19qgD40: BUG: (protocol error){channel.c:57}"

[Trent W. Buck]

Package: tinysshd
Version: 20190101-1
Severity: normal

This has annoyed me for a while, but I only just today realized it was an 
actual bug and not simply a missing feature.
I had to use "screen" to run two SSH clients at once.  I tried using "ssh -f" 
and could not reproduce the problem.
I am using "-F /dev/null" to disable my ~/.ssh/config.

I have ControlMaster enabled by default on all my SSH connections with
this at the bottom of my .ssh/config:

Host *
  ControlMaster auto
  ControlPath ~/.ssh/master-%C
  ControlPersist 3600

If you do this (like me), a quick workaround that avoids this bug is to simply 
do
"ssh -M tinyssh-host" instead of
"ssh tinyssh-host".
This effectively disables ControlMaster for that one connection.


This issue is not discussed in upstream's issue tracker:
https://github.com/janmojzis/tinyssh/issues

I have not yet tested a newer upstream version (currently available in
salsa, but not in sid or experimental yet).



Here is a transcript of me reproducing the problem.  I am connecting
to a basic Debian 11 Live VM running in qemu, with its port 22
forwarded to localhost 2022.

bash5$ ssh -F/dev/null -oUserKnownHostsFile=/dev/null 
-oStrictHostKeyChecking=no root@localhost -p2022 systemctl status 
system-tinysshd.slice
Warning: Permanently added '[localhost]:2022' (ED25519) to the list of 
known hosts.
● system-tinysshd.slice
 Loaded: loaded
 Active: active since Mon 2021-09-27 14:40:45 AEST; 198ms ago
  Tasks: 2
 Memory: 3.8M
CPU: 178ms
 CGroup: /system.slice/system-tinysshd.slice
 └─tinysshd@0-10.0.2.15:22-10.0.2.2:38146.service
   ├─405 /usr/sbin/tinysshd -v -- /etc/tinyssh/sshkeydir
   └─408 systemctl status system-tinysshd.slice

Sep 27 14:40:45 main.lan systemd[1]: Created slice system-tinysshd.slice.
Sep 27 14:40:46 main.lan tinysshd[405]: tinysshd: BIFzIJ9B: info: 
connection from 10.0.2.2:38146 {main_tinysshd.c:106}
Sep 27 14:40:46 main.lan tinysshd[405]: tinysshd: BIFzIJ9B: info: auth: 
root: ssh-ed25519 
C3NzaC1lZDI1NTE5IIapAZ0E0353DaY6xBnasvu/DOvdWdKQ6RQURwq4l6Wu accepted 
{packet_auth.c:155}

# Run two ssh clients at once, sharing a control master.
# When the second one starts, tinysshd crashes, so the first one hangs up.
bash5$ screen ssh -F/dev/null -oUserKnownHostsFile=/dev/null 
-oStrictHostKeyChecking=no root@localhost -p2022 -oControlMaster=auto 
-oControlPath=~/.ssh/master-%C -oControlPersist=3600
bash5$ screen ssh -F/dev/null -oUserKnownHostsFile=/dev/null 
-oStrictHostKeyChecking=no root@localhost -p2022 -oControlMaster=auto 
-oControlPath=~/.ssh/master-%C -oControlPersist=3600


# Examining the system after the problem happened.
bash5$ ssh -F/dev/null -oUserKnownHostsFile=/dev/null 
-oStrictHostKeyChecking=no root@localhost -p2022 systemctl status 
system-tinysshd.slice
Warning: Permanently added '[localhost]:2022' (ED25519) to the list of 
known hosts.
● system-tinysshd.slice
 Loaded: loaded
 Active: active since Mon 2021-09-27 14:40:45 AEST; 14s ago
  Tasks: 4
 Memory: 6.9M
CPU: 429ms
 CGroup: /system.slice/system-tinysshd.slice
 ├─tinysshd@2-10.0.2.15:22-10.0.2.2:38154.service
 │ ├─423 /usr/sbin/tinysshd -v -- /etc/tinyssh/sshkeydir
 │ └─426 -bash
 └─tinysshd@3-10.0.2.15:22-10.0.2.2:38158.service
   ├─433 /usr/sbin/tinysshd -v -- /etc/tinyssh/sshkeydir
   └─436 systemctl status system-tinysshd.slice

Sep 27 14:40:46 main.lan tinysshd[405]: tinysshd: BIFzIJ9B: info: 
connection from 10.0.2.2:38146 {main_tinysshd.c:106}
Sep 27 14:40:46 main.lan tinysshd[405]: tinysshd: BIFzIJ9B: info: auth: 
root: ssh-ed25519 
C3NzaC1lZDI1NTE5IIapAZ0E0353DaY6xBnasvu/DOvdWdKQ6RQURwq4l6Wu accepted 
{packet_auth.c:155}
Sep 27 14:40:46 main.lan tinysshd[405]: tinysshd: BIFzIJ9B: info: finished 
{main_tinysshd.c:287}
Sep 27 14:40:55 main.lan tinysshd[412]: tinysshd: W19qgD40: info: 
connection from 10.0.2.2:38150 {main_tinysshd.c:106}
Sep 27 14:40:55 main.lan tinysshd[412]: tinysshd: W19qgD40: info: auth: 
root: ssh-ed25519 
C3NzaC1lZDI1NTE5IIapAZ0E0353DaY6xBnasvu/DOvdWdKQ6RQURwq4l6Wu accepted 
{packet_auth.c:155}
Sep 27 14:40:57 main.lan tinysshd[412]: tinysshd: W19qgD40: BUG:  (protocol 
error){channel.c:57}
Sep 27 14:40:57 main.lan tinysshd[423]: tinysshd: j6vr2uNR: info: 
connection from 10.0.2.2:38154 {main_tinysshd.c:106}
Sep 27 14:40:57 main.lan tinysshd[423]: tinysshd: j6vr2uNR: info: auth: 
root: ssh-ed25519 
C3NzaC1lZDI1NTE5IIapAZ0E0353DaY6xBnasvu/DOvdWdKQ6RQURwq4l6Wu accepted 
{packet_auth.c:155}
Sep 27 14:40:59 main.lan tinysshd[433]: tinysshd: CGtApdsN: info: 
connection from 10.0.2.2:38158 {main_tinysshd.c:106}
Sep 27 14:40:59 main.lan tinysshd[433]: tinysshd: CGtApdsN: 

Bug#879872: inadyn 2.8.1-1 pending for review

[Benda Xu]

Tags: patch

A merge request has been created for review,

  https://salsa.debian.org/debian/inadyn/-/merge_requests/1

with which we will release 2.8.1-1 into sid.

Cheers,
Benda

Bug#993755: libcrypt.so.1: cannot open shared object file when upgrading from Stretch to Sid

[Marco d'Itri]

On Sep 27, Otto Kekäläinen  wrote:

> Seems this libcrypt1 change not only affects upgrades from Stretch,
> but in some cases even upgrades from Buster:
Buster to Bookworm still means skipping a release.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#993755: libcrypt.so.1: cannot open shared object file when upgrading from Stretch to Sid

[Otto Kekäläinen]

Hello!

Seems this libcrypt1 change not only affects upgrades from Stretch,
but in some cases even upgrades from Buster:
- https://salsa.debian.org/mariadb-team/galera-4/-/jobs/2008098
- https://salsa.debian.org/mariadb-team/galera-4/-/jobs/2008103

I wonder if there is some workaround? Could we somehow force the new
librcypt1 to install before libc upgrades?

Bug#992563: transition: gdal

[Sebastiaan Couwenberg]

On 9/23/21 11:40 AM, Sebastian Ramacher wrote:
> On 2021-09-23 11:34:21, Sebastiaan Couwenberg wrote:
>> On 9/18/21 9:57 AM, Sebastian Ramacher wrote:
>>> On 2021-09-18 07:01:38 +0200, Sebastiaan Couwenberg wrote:
 On 9/12/21 7:54 PM, Sebastiaan Couwenberg wrote:

 Quite a few packages on mipsel may need a binNMU for the recent glibc
 changes, it allowed libgdal-grass to migrate, but there a still quite a
 few packages with remaining issues:

  https://linuxminded.nl/debian/gis-transitions/testing/html/gdal.html
>>>
>>> There are a over 200 packages and a bunch of binNMUs that are blocked by
>>> glibc. I'm slowly wading through that list.
>>
>> glibc migrated to testing, this allowed a few packages that are part of
>> the gdal & pdal transitions to migrate but there are still outstanding
>> issues.
>>
>> In the britney update_output.txt you see these packages as reasons why
>> the old gdal & pdal library cannot be removed, but you don't see
>> attempts to migrate those packages.
>>
>> r-cran-rgdal and r-cran-sf are blocked by r-base.
> 
> They have been binNMUed in testing-proposed-updates and should migrate
> to testing in the next run.
> 
>>
>> What is preventing vtk7 and paraview from migrating?
> 
>>From https://release.debian.org/britney/update_excuses.html: both the
> paraview and vtk7 binNMUs are blocked by openmpi.

postgis, paraview, and vtk7 migrated to testing as well.

That just leaves opencv on mipsel which update_excuses suggests is
blocked by vtk9, and qgis on mips* which is waiting for FTP master to
act on #994053.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#995134: dkms modules fail to build on 5.14.0, error: ‘TIF_IA32’ undeclared

[Benjamin Kaduk]

severity 995134 serious
tags 995134 upstream fixed-upstream pending
thanks

On Sun, Sep 26, 2021 at 05:07:44PM -0400, Ryan Kavanagh wrote:
> Package: openafs-modules-dkms
> Version: 1.8.6-5
> Severity: grave
> Justification: Renders package unusable
> 
> The openafs dkms modules fail to build on 5.14.0. I've attached
> /var/lib/dkms/openafs/1.8.6/build/make.log.

Thanks for the report.  Upstream OpenAFS 1.8.8 includes support for linux
kernels through 5.14, but since the upstream release came out during freeze
I didn't package it at the time.
Given the extra reminder, I'm happy to package it now.

Thanks,

Ben


signature.asc
Description: PGP signature

Bug#452721: #452721 moreinfo?

[Elliott Mitchell]

I'm surprised #452721 is tagged moreinfo since it seems simple, but that
may depend on installation capability.

Note, I am not the original reporter, so I might actually be observing
something distinct.  I doubt this, but I cannot be certain.


Issue is this, a hypervisor machine could have tens or even hundreds of
VMs.  There could be ordering dependencies during startup and shutdown.

Notably there are core services, such as LDAP, DHCP, fileserver and DNS.
Often these need to be up before anything else and they may need to come
up in a particular order.  Most often the LDAP server (which can be a
distinct VM) needs to be up first.  Meanwhile for downtimes, a fileserver
(which can also be a VM) needs to go down last.

During a full downtime when all VMs were fully shut down, this effect
can be achieved by including numbers in the filename.  Say
/etc/xen/auto/0_ldap.cfg, /etc/xen/auto/1_fileserver.cfg,
/etc/xen/auto/9_everything_else.cfg.

If the hypervisor is rebooted and VMs are saved to /var/lib/xen/save;
they will be paused in identifier order, but saved by domain name.  When
scanning /var/lib/xen/save, `xendomains` goes by filename which means VMs
are restored in a distinct (and often problematic) order.


A minimal solution would be for `xendomains` to save VMs in
/var/lib/xen/save - and then use `sort -n` during restore.

A better approach would be to have a LSB style header specifying
dependencies to flag VMs which should be saved or shutdown late, and VMs
which should be saved or shutdown early.

A ridiculous overkill solution might be to turn the /etc/xen/*.cfg files
into full init scripts.  This could be done by having a script which
understood domain configuration files well enough to identify the
name/UUID and then start/stop the domain as specified by $1.  Use that
script as the interpreter (#! line), then it could find the configuration
via $0.  Then normal init script handling tools could take care of
ordering.

(geeze, that really does actually seem kind of like a semi-workable
solution despite seeming rather crazy at first)


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#995145: cyrus-sasl2: reproducible builds: timestamps in man pages

[Vagrant Cascadian]

Source: cyrus-sasl2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Timestamps are embedded in man pages generated by sphinx:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/cyrus-sasl2.html

  /usr/share/man/man3/sasl.3.gz

  .TH·"SASL"·"3"·"August·23,·2022"·"2.1.27"·"Cyrus·SASL"
  vs.
  .TH·"SASL"·"3"·"July·22,·2021"·"2.1.27"·"Cyrus·SASL"

The attached patch fixes this by passing a specific date during the
build, using SOURCE_DATE_EPOCH defined from debian/changelog.

With this patch applied cyrus-sasl2 should become reproducible on
tests.reproducible-builds.org.


Thanks for maintaining cyrus-sasl2!


live well,
  vagrant
From 2591a38f60f182898679f2a6f5f7f17e72009fc6 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 27 Sep 2021 01:27:09 +
Subject: [PATCH 2/2] Makefile.am: Set date in man pages.

The build date is embedded in the man pages by default. Pass arguments
to sphinx to use the date defined in SOURCE_DATE_EPOCH.

https://reproducible-builds.org/docs/source-date-epoch/
---
 Makefile.am | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index 25694a8..c2a86fc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -180,6 +180,12 @@ GENERATED_RSTS =
 
 SPHINX_OPTS = -d $(SPHINX_CACHE) -n -q
 
+# Pass date defined in SOURCE_DATE_EPOCH for reproducible builds:
+# https://reproducible-builds.org/docs/source-date-epoch/
+SOURCE_DATE_EPOCH ?= $(shell date -d "$$(dpkg-parsechangelog -S Date)" +%s)
+BUILD_DATE=$(shell LC_ALL=C date -u --iso-8601 -d "@$(SOURCE_DATE_EPOCH)")
+SPHINX_OPTS += -D today=$(BUILD_DATE)
+
 ## detect when source directory is not build directory (i.e. VPATH
 ## build), and clone the docsrc tree into the build directory, so
 ## that we have a single "source directory" for sphinx-build to use.
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#995144: bullseye-pu: package jailkit/2.21-4+deb11u1

[Joao Eriberto Mota Filho]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
This update is not for a regression. There are two bugs discovered recently.
With these bugs, jailkit will work partially. The bugs are #992420 and #992422.

[ Impact ]
Jailkit is a set of tools to help us to create jails for shells or services,
e.g. ssh.

If this request is not approved, the jailkit won't be able to create jails that
need to use files in /dev. Also, some checks for libraries will fail.

[ Tests ]
Some tests were made by me and users, creating new jails. Is not possible to
make automated tests because jailkit don't trust in $AUTOPKGTEST_TMP
environment since it uses permission 755, instead of 700.

[ Risks ]
The changes are trivial and they were reviewed by the upstream. I can't see
risks.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
There are two trivial patches, changing few lines in two files. The first patch
will change a division with floating point to an integer division to select the
right device. The second patch will fix a mistake, adding an option to a line.

[ Other info ]
No more info. Thanks.
diff -Nru jailkit-2.21/debian/changelog jailkit-2.21/debian/changelog
--- jailkit-2.21/debian/changelog   2021-07-16 11:31:18.0 -0300
+++ jailkit-2.21/debian/changelog   2021-09-26 22:24:08.0 -0300
@@ -1,3 +1,17 @@
+jailkit (2.21-4+deb11u1) bullseye; urgency=medium
+
+  * debian/patches/:
+  - 050_fix-incorrect-device.patch: created to fix the incorrect calc of
+device major number. Without this patch, jailkit won't be able to
+create jails that needs a device from /dev. Thanks to Jesse Norell
+. (Closes: #992422)
+  - 060_fix-typo-jk_init.patch: created to fix a typo in /usr/sbin/jk_init.
+Without this patch, jailkit won't be able to check the presence of
+some libraries. Thanks to Peter Viskup .
+(Closes: #992420)
+
+ -- Joao Eriberto Mota Filho   Sun, 26 Sep 2021 22:24:08 
-0300
+
 jailkit (2.21-4) unstable; urgency=medium
 
   * debian/control: bumped Standards-Version to 4.5.1.
diff -Nru jailkit-2.21/debian/patches/050_fix-incorrect-device.patch 
jailkit-2.21/debian/patches/050_fix-incorrect-device.patch
--- jailkit-2.21/debian/patches/050_fix-incorrect-device.patch  1969-12-31 
21:00:00.0 -0300
+++ jailkit-2.21/debian/patches/050_fix-incorrect-device.patch  2021-09-26 
22:19:07.0 -0300
@@ -0,0 +1,33 @@
+Description: fix the incorrect calc of device major number
+Author: Jesse Norell 
+Bug: https://savannah.nongnu.org/bugs/?61130
+Bug-Debian: https://bugs.debian.org/992422
+Forwarded: 
https://lists.nongnu.org/archive/html/jailkit-dev/2021-08/msg4.html
+Last-Update: 2021-09-08
+Index: jailkit/py/jk_lib.py
+===
+--- jailkit.orig/py/jk_lib.py
 jailkit/py/jk_lib.py
+@@ -578,18 +578,18 @@ def copy_device(chroot, path, be_verbose
+   sb = os.stat(path)
+   try:
+   if (sys.platform[:5] == 'linux'):
+-  major = sb.st_rdev / 256 #major = st_rdev divided by 
256 (8bit reserved for the minor number)
++  major = sb.st_rdev // 256 #major = st_rdev divided by 
256 (8bit reserved for the minor number)
+   minor = sb.st_rdev % 256 #minor = remainder of st_rdev 
divided by 256
+   elif (sys.platform == 'sunos5'):
+   if (sys.maxint == 2147483647):
+-  major = sb.st_rdev / 262144 #major = st_rdev 
divided by 256 (18 bits reserved for the minor number)
++  major = sb.st_rdev // 262144 #major = st_rdev 
divided by 256 (18 bits reserved for the minor number)
+   minor = sb.st_rdev % 262144 #minor = remainder 
of st_rdev divided by 256
+   else:
+   #64 bit solaris has 32 bit minor/32bit major
+-  major = sb.st_rdev / 2147483647
++  major = sb.st_rdev // 2147483647
+   minor =  sb.st_rdev % 2147483647
+   else:
+-  major = sb.st_rdev / 256 #major = st_rdev divided by 256
++  major = sb.st_rdev // 256 #major = st_rdev divided by 
256
+   minor = sb.st_rdev % 256 #minor = remainder of st_rdev 
divided by 256
+   if (stat.S_ISCHR(sb.st_mode)): 
+   mode = 'c'
diff -Nru jailkit-2.21/debian/patches/060_fix-typo-jk_init.patch 
jailkit-2.21/debian/patches/060_fix-typo-jk_init.patch
--- jailkit-2.21/debian/patches/060_fix-typo-jk_init.patch  1969-12-31 
21:00:00.0 -0300
+++ 

Bug#995123: cyrus-sasl2 FTBFS: sphinx: AttributeError: 'CyrusManualPageBuilder' object has no attribute 'settings'

[Vagrant Cascadian]

Control: tags 995123 +patch

On 2021-09-26, Dmitry Shachnev wrote:
> On Sun, Sep 26, 2021 at 07:37:13PM +0200, Helmut Grohne wrote:
>> cyrus-sasl2 fails to build from source in unstable on amd64. A build
>> ends as follows:
...
>> It built fine yesterday and today sphinx got uploaded to unstable. That
>> seems like a very plausible reason, right? I've put Dmitry in the loop.
>
> Yes, it is caused by a change in Sphinx.
>
> CyrusManualPageTranslator inherits from Sphinx' ManualPageTranslator and
> calls the super-class constructor as follows:
>
>   BaseTranslator.__init__(self, builder, *args, **kwds)
>
> However, starting with Sphinx 2.0 it should be called with document as the
> first argument and builder as the second one [1]. The old way of calling it
> raised a warning for some time and was completely removed in Sphinx 4.0.

I tested the attached patch which seems to fix this.

Next... fixing the outstanding reproducible builds issues...

live well,
  vagrant
From 7570e73df1dbf6eea0f1ef07ff76bc2cd01eae6e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 27 Sep 2021 01:21:20 +
Subject: [PATCH 1/3] Fix build with sphinx 4+ (Closes: #995123).

The positional arguments changed order in newer sphinx versions.
---
 docsrc/exts/sphinxlocal/writers/manpage.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docsrc/exts/sphinxlocal/writers/manpage.py b/docsrc/exts/sphinxlocal/writers/manpage.py
index e8e9c3a..c33ba61 100644
--- a/docsrc/exts/sphinxlocal/writers/manpage.py
+++ b/docsrc/exts/sphinxlocal/writers/manpage.py
@@ -34,7 +34,7 @@ class CyrusManualPageWriter(ManualPageWriter):
 self.builder = builder
 
 def translate(self):
-visitor = CyrusManualPageTranslator(self.builder, self.document)
+visitor = CyrusManualPageTranslator(self.document, self.builder)
 self.visitor = visitor
 self.document.walkabout(visitor)
 self.output = visitor.astext()
@@ -45,8 +45,8 @@ class CyrusManualPageTranslator(BaseTranslator):
 Custom translator.
 """
 
-def __init__(self, builder, *args, **kwds):
-BaseTranslator.__init__(self, builder, *args, **kwds)
+def __init__(self, document, builder, *args, **kwds):
+BaseTranslator.__init__(self, document, builder, *args, **kwds)
 self.builder = builder
 
 self.in_productionlist = 0
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

[Christoph Anton Mitterer]

Seems to be doable with a simply oneliner:

--- a/lib/cryptsetup/functions  2021-09-27 03:30:31.928052985 +0200
+++ b/lib/cryptsetup/functions  2021-09-27 03:30:28.387976358 +0200
@@ -278,6 +278,7 @@
 local keyscriptarg="$1" CRYPTTAB_TRIED="$2" keyscript;
 export CRYPTTAB_NAME CRYPTTAB_SOURCE CRYPTTAB_OPTIONS
 export CRYPTTAB_TRIED
+export _CRYPTTAB_NAME _CRYPTTAB_SOURCE _CRYPTTAB_KEY _CRYPTTAB_OPTIONS
 
 if [ -n "${CRYPTTAB_OPTION_keyscript+x}" ] && \
 [ "$CRYPTTAB_OPTION_keyscript" != "/lib/cryptsetup/askpass" ]; then


But I'm not sure how you'd want to handle _CRYPTTAB_KEY. It seems to be
there at this point, but CRYPTTAB_KEY is set below in the conditional
from $keyscriptarg .

Cheers,
Chris.

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Hi Hannah!

Reply follows inline.

Hi Alexandre!

I'm CCing you to ask if you'd appreciate help packaging deps for
Syncthing 1.18.2, because the working copy of Syncthing Tray that Hannah
prepared has an embedded copy of this version's libsyncthing that should
be unbundled.

Hannah Rittich  writes:

> Hey Nicholas,
>
> nice to hear that you are still interested.
>

Yes, definitely!  Long ago Alexandre Viau (Syncthing maintainer in
Debian) convinced me of the usefulness of Syncthing, and a more friendly
and convenient UI for our KDE Plasma users is *long overdue*.  Oh, and
Alexandre was my first Debian contact.  By the way, is this your first
Debian contribution?  If so, welcome! :-)

> I have read this BTS entry, as well as the related GitHub issue [1].
> Indeed, libc++utilities and libqtutilities are quite generic names. I
> think, there are three ways to deal with this.
>
> 1.  Rename the libraries. Build a package for each one.
> 2.  Build a syncthingtray package that includes the libraries and
> installs them to `/usr/lib/$ARCH/syncthingtray`. This would make use
> of the multiple tarball support.
> 3.  Acceptance. Keep the names as they are. Build a package for each
> one.
>
> The three approaches have pros and cons.
>
> 1.  + More specific package name.
> - More work: requires changing the build process and changes to
>   upstream might be necessary.
> - Increases long term maintenance cost, since higher complexity
>   increases the chance of errors.
> - Can break on updates, if upstream does not want to include the
>   changes.
>
> 2.  + A hypothetical name collision is avoided.
> o Probably less work than 1.
> - Additional work: requires a more complicated build process.
> - Increases long term maintenance cost, since higher complexity
>   increases the chance of errors.
> - Libraries cannot be used by other packages. (The author has other
>   applications that might be of interest. They use the same
>   libraries.)
>
> 3.  + Much simpler than 1. and 2.
> + Debian package is very close to the upstream package.
> + Low maintenance cost and more stable build process.
> - A hypothetical name collision can occur.
>
> I, would suggest option 3. A name collision, at this point, is just
> hypothetical, while the drawbacks of the other options are real.
>
> I have checked the package database and there is currently no name
> collision with these package names, and the Debian Policy
> Manual just requires a name to be unique in Debian [2], which they are.
>
> Furthermore, the chance of a name collision is rather small. Yes,
> libc++utilities is a rather generic name. However, for the same reason
> you are concerned about the name, most people will not consider to use
> such a generic name for a project; it is actually a bold move to choose
> such a name. In case a more important package needs this name, however,
> the packages can still be renamed. Hence, I do not see a reason to
> significantly increase the effort of packaging when there is no concrete
> reason to do so at the moment. There is the saying "done is better than
> perfect."
>
> If you insist, one could add a section to the README.Debian file that
> the package will be renamed in case the name is needed by a more
> important package.
>

So option #1 is patching the library, and not using a different package
name at the dpkg level.  I wonder about namespacing the dependencies'
names at the dpkg level, without patching the library?  Eg:
src:marchus-cpp-utilities (which generates
bin:marchus-libc++utilities5).  What do you think?  I think this would
be less confusing to users/devs, and I feel like it's likely that there
will be a cpp-utilities from glibc or LLVM somewhere in the future.
What I mean by "confusing" is I really don't think that it's appropriate
for a helper library to grab such an authoritative name, except in
Flatpaks, and such containerised packages, of course! ;-)  If #3 ever
becomes a real issue, I hope that our popcon stats will help convince
upstream to DTRT.

> In any case, I have taken the liberty to create an MVP (minimum viable
> packaging) for Syncthing Tray and the required libraries [3], which can
> be improved upon.
>
> What are your thoughts?
>

Wow!  Yes, I will definitely sponsor your work :-)  How do you feel
about comaintaining these packages in the "debian" group (used to be
called collab-maint)?

Syncthing for Debian tends to lag behind upstream, and we'll need to
ignore or remove the embedded copy of libsyncthing in Syncthing Tray.
In terms of long-term maintenance it looks like Syncthing Tray updates
will need to block for Syncthing (and its new deps) uploads.  I forget
if I uploaded the packages or not, but at some point I worked on
packaging new Golang deps for Syncthing, and it wasn't as difficult as I
had expected.  I'll wait for Alexandre's ACK before asking you if you're
also interested in Golang packaging ;-)

Hannah, thank you 

Bug#993824: transition: libqalculate

[Norbert Preining]

Hi Phil,

I pushed a commit with initial changes for libqalculate20-data dummy
package. Please take a look.

Thanks

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1

[Diederik de Haas]

Hi,

On vrijdag 6 augustus 2021 16:07:18 CEST Diederik de Haas wrote:
> On vrijdag 6 augustus 2021 15:14:26 CEST Uwe Kleine-König wrote:
> > On Thu, Aug 05, 2021 at 05:26:09PM +, Diederik de Haas wrote:
> > > https://salsa.debian.org/raspi-team/image-specs/-/issues/7#note_206349
> > > 
> > > So I build my own kernel with the following patch:
> > > +CONFIG_CLK_RASPBERRYPI=y
> > 
> > Would CONFIG_CLK_RASPBERRYPI=m be enough?
> 
> Maybe. I haven't tried that. I 'copied' what was done for arm64 and armhf in
> https://salsa.debian.org/kernel-team/linux/-/commit/7dc3d9453272836a9571c30
> b9776a85a5e41c657
> https://salsa.debian.org/kernel-team/linux/-/commit/c4ab143979cc30c395251a4
> 8ba6b5b8969973b70
> 
> If I grep on CLK on configs on my amd64 machine and various RPi's,
> then they all have '=y' on them, so it appears to be the standard/norm.

I just found out that on my Rock64 arm64 kernel the value is '=y'
$ grep CONFIG_CLK_RASPBERRYPI /boot/config-5.14.0-trunk-arm64 
CONFIG_CLK_RASPBERRYPI=y

And on top of that, this kernel config change is targeted at 
debian/config/armel/config.rpi which is a config file solely for the RPi 0/0w/1.
I understand/agree with the principle to enable things as modules as much as 
possible, but I don't think it's important in this specific case.
 
> > > -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> > > +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> > > -# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
> > > +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> > > -CONFIG_CPU_FREQ_GOV_ONDEMAND=m
> > > +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> > 
> > Hmm, CONFIG_CPU_FREQ_GOV_ONDEMAND=m is already there, so you should be
> > able to switch to that if you prefer it?!

True, but I think 'performance' is a bad default scheduler in general as 
AFAICT it runs the CPU at full speed all the time.
In the case or RPi's I think it's especially bad as due to their low power 
consumption they're often on 24/7, while being idle most of the time.
With 'ondemand' it runs at lowest speed normally, but only scales up when 
needed, which I think is what most people want and expect.
So changing the default to 'ondemand' seems the right choice and the default 
governor must be builtin.

https://salsa.debian.org/kernel-team/linux/-/merge_requests/381 is my MR to fix 
this bug and enable these changes in config.rpi.
(I'll soon update that MR and retarget it to master)

In that MR I've also made 'conservative' governor builtin.
While strictly not needed, this change is also restricted to config.rpi and 
it's the best governor for solar/battery powered devices, which is (afaik) a 
common use case for RPi 0/0w/1.
I'm _assuming_ that many users of RPi's are not tech-savvy and don't know that 
you can 'modprobe' additional governors if you want to use them.
In fact I only learned that recently. Previously I thought I couldn't use them 
because they didn't show up in the *available* governors. When a governor is 
loaded (or builtin), it does show up as an available governor.

Cheers,
   Diederik



signature.asc
Description: This is a digitally signed message part.

Bug#939186: irt: Bug #939186 and 4.11/4.14

[Elliott Mitchell]

found 939186 4.14.2+25-gb6a8c4f72d-2
found 939186 4.14.3-1
tags 939186 upstream
quit

Upon a bit more experimentation, seems my minimal example had become too
minimal.  Bring in the less minimal example and things explode again.

Finally setup an appropriate downtime window and it reproduced.  After
some fighting to get Xen's console operational, detail on the panic was
recorded.

My wild guess from the output is some combination of enabling "nestedhvm"
and this being an AMD processor machine.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

[Christoph Anton Mitterer]

Hey again.

Next to stabilising "_CRYPTTAB_*", could you also export it to the
keyscripts?

I can see it in the initramfs hook, when using crypttab_foreach_entry,
but it's not there in the keyscript.

Thus I cannot implement my own unescaping.


Cheers,
Chris.

Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module

[Forest]

Control: tags -1 - moreinfo

>Could you try with the current kernel in unstable?
>We are at 5.14.6-2, which had some rk3399 related changes. 

Did any of those changes arrive after 5.14.0-1?  If so, I suppose I would
have to wait for a newer debian kernel to appear before I could test it.

With 5.14.0-1 (the version in unstable), the results are worse:

Dropbear no longer works.  Error message:
/scripts/init-premount/dropbear: .: line 333: can't open '/run/net-*.conf': No 
such file or directory

Using a serial console for LUKS unlock and then running rmmod dwmac_rk / 
modprobe dwmac_rk no longer brings up eth0.

The dmesg output has changed a bit:
$ egrep 'mac|eth0' dmesg.linux-image-5.14.0-1-arm64 
[5.708873] rk_gmac-dwmac fe30.ethernet: IRQ eth_wake_irq not found
[5.709470] rk_gmac-dwmac fe30.ethernet: IRQ eth_lpi not found
[5.710965] rk_gmac-dwmac fe30.ethernet: PTP uses main clock
[5.712133] rk_gmac-dwmac fe30.ethernet: clock input or output? (input).
[5.713263] rk_gmac-dwmac fe30.ethernet: TX delay(0x28).
[5.714418] rk_gmac-dwmac fe30.ethernet: RX delay(0x11).
[5.716512] rk_gmac-dwmac fe30.ethernet: integrated PHY? (no).
[5.717492] rk_gmac-dwmac fe30.ethernet: cannot get clock clk_mac_speed
[5.719275] rk_gmac-dwmac fe30.ethernet: clock input from PHY
[5.724825] rk_gmac-dwmac fe30.ethernet: init for RGMII
[5.725658] rk_gmac-dwmac fe30.ethernet: User ID: 0x10, Synopsys ID: 0x35
[5.726328] rk_gmac-dwmac fe30.ethernet: DWMAC1000
[5.726802] rk_gmac-dwmac fe30.ethernet: DMA HW capability register 
supported
[5.727511] rk_gmac-dwmac fe30.ethernet: RX Checksum Offload Engine 
supported
[5.728183] rk_gmac-dwmac fe30.ethernet: COE Type 2
[5.728652] rk_gmac-dwmac fe30.ethernet: TX Checksum insertion supported
[5.729275] rk_gmac-dwmac fe30.ethernet: Wake-Up On Lan supported
[5.731134] rk_gmac-dwmac fe30.ethernet: Normal descriptors
[5.731674] rk_gmac-dwmac fe30.ethernet: Ring mode enabled
[5.732192] rk_gmac-dwmac fe30.ethernet: Enable RX Mitigation via HW 
Watchdog Timer
[5.851291] libphy: stmmac: probed
[5.851612] RTL8211F Gigabit Ethernet stmmac-0:00: attached PHY driver 
(mii_bus:phy_addr=stmmac-0:00, irq=POLL)
[5.852504] RTL8211F Gigabit Ethernet stmmac-0:01: attached PHY driver 
(mii_bus:phy_addr=stmmac-0:01, irq=POLL)
[6.639085] rk_gmac-dwmac fe30.ethernet eth0: PHY [stmmac-0:00] driver 
[RTL8211F Gigabit Ethernet] (irq=POLL)
[6.641458] rk_gmac-dwmac fe30.ethernet eth0: Register 
MEM_TYPE_PAGE_POOL RxQ-0
[6.653320] rk_gmac-dwmac fe30.ethernet eth0: No Safety Features support 
found
[6.653364] rk_gmac-dwmac fe30.ethernet eth0: PTP not supported by HW
[6.654183] rk_gmac-dwmac fe30.ethernet eth0: configuring for phy/rgmii 
link mode
[9.760371] rk_gmac-dwmac fe30.ethernet eth0: Link is Up - 1Gbps/Full - 
flow control rx/tx
[9.760429] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  199.685064] rk_gmac-dwmac fe30.ethernet eth0: Link is Down
[  207.195113] rk_gmac-dwmac fe30.ethernet eth0: PHY [stmmac-0:00] driver 
[RTL8211F Gigabit Ethernet] (irq=POLL)
[  207.197673] rk_gmac-dwmac fe30.ethernet eth0: Register 
MEM_TYPE_PAGE_POOL RxQ-0
[  207.206976] rk_gmac-dwmac fe30.ethernet eth0: No Safety Features support 
found
[  207.207681] rk_gmac-dwmac fe30.ethernet eth0: PTP not supported by HW
[  207.208307] rk_gmac-dwmac fe30.ethernet eth0: configuring for phy/rgmii 
link mode
[  210.304576] rk_gmac-dwmac fe30.ethernet eth0: Link is Up - 1Gbps/Full - 
flow control rx/tx
[  210.305423] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Bug#995143: xdmf: reproducible builds: Embeds buildpath, kernel and uname path

[Vagrant Cascadian]

Source: xdmf
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath usrmerge kernel
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path, kernel version and path to the uname binary are
embedded in /usr/lib/x86_64-linux-gnu/cmake/Xdmf/XdmfConfig.cmake,
which cause reproducibility issues.

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/xdmf.html

  set(XDMF_CMAKE_BINARY_DIR 
"/build/1st/xdmf-3.0+git20190531/debian/build-mpi-python3.9")
  vs.
  set(XDMF_CMAKE_BINARY_DIR 
"/build/2/xdmf-3.0+git20190531/2nd/debian/build-mpi-python3.9")

The attached patch fixes this by sanitizing these values in the
XdmfConfig.cmake file.

It is unclear if XdmfConfig.cmake actually needs to be included in the
package; a better course of action might be to remove the file entirely.


With this patch applied(or removing XdmfConfig.cmake from the package),
xdmf should become reproducible on tests.reproducible-builds.org.


Thanks for maintaining xdmf!


live well,
  vagrant
From 143591a985b25b0baf340537af7a00d51ac9fde1 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 27 Sep 2021 00:04:08 +
Subject: [PATCH] debian/rules: Sanitize XdmfConfig.cmake to fix
 reproducibility issues.

The build path, kernel version and path to the uname binary are
embedded in /usr/lib/x86_64-linux-gnu/cmake/Xdmf/XdmfConfig.cmake,
which cause reproducibility issues.

https://tests.reproducible-builds.org/debian/issues/captures_build_path_issue.html
https://tests.reproducible-builds.org/debian/issues/captures_kernel_version_via_CMAKE_SYSTEM_issue.html
https://tests.reproducible-builds.org/debian/issues/paths_vary_due_to_usrmerge_issue.html
---
 debian/rules | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/debian/rules b/debian/rules
index 321ae850..c95f8b43 100755
--- a/debian/rules
+++ b/debian/rules
@@ -91,6 +91,12 @@ override_dh_auto_install:
 		cp debian/build-serial-$$p/lib/__*.so   $(PY3DEST)/usr/lib/$$p/dist-packages/xdmf/NoMpi ; \
 		cp debian/build-mpi-$$p/lib/__*.so   $(PY3DEST)/usr/lib/$$p/dist-packages/xdmf ; \
 		done
+	# Remove build path and kernel version, and adjust path to
+	# uname to make build reproducible
+	sed -i -e "s,$(CURDIR),BUILDDIR,g" \
+		-e "s,/usr/bin/uname,/bin/uname,g" \
+		-e "s,$(shell uname -r),,g" \
+		debian/tmp/usr/lib/x86_64-linux-gnu/cmake/Xdmf/XdmfConfig.cmake
 
 override_dh_auto_fixperms:
 	dh_auto_fixperms
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#995142: RFP: Srain

[Wellington Almeida]

Package: wnpp
Version: N/A
Severity: wishlist

URL: https://github.com/SrainApp/srain
URL: https://srain.im/
License: GNU General Public License Version 3

Description: IRC client

Modern IRC client written in GTK I would very much like to have it packaged
in the official debian repositories.





-- 
Wellington Almeida
Rio de Janeiro - Brasil

Bug#982091: Please include some yaml.nanorc

[Otto Kekäläinen]

Hello!

I tested this today, but unfortunately the yaml.nanorc seems to have
syntax errors:

```
Error in /usr/share/nano/yaml.nanorc on line 6: A syntax name must be quoted
Error in /usr/share/nano/yaml.nanorc on line 7: A 'header' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 9: Command "tabgives" not
allowed in included file
Error in /usr/share/nano/yaml.nanorc on line 10: A 'comment' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 13: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 14: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 15: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 18: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 19: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 20: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 21: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 24: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 27: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 28: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 31: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 32: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 35: A 'color' command
requires a preceding 'syntax' command
Error in /usr/share/nano/yaml.nanorc on line 38: A 'color' command
requires a preceding 'syntax' command
```

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Jesse Smith]

On 2021-09-26 8:55 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> I checked out the init.d directories provided by Thorsten. One of the
>> features of insserv allows it to test init scripts in an alternative
>> directory or chroot.
> This seems to be broken:
>
> tglase@tglase:~ $ insserv -p etc-stripped
> insserv: fopen(/etc/init.d/.depend.boot): Permission denied
>
> (Having extracted the tarball as regular user so there are no
> permission issues.)
>

I just realized what the problem is. On the version of insserv you are
using, the command should be "insserv -p etc-stripped/init.d -i
etc-stripped/init.d". The 1.21.0 version of insserv has a second flag
for where to send dependency information.

Jesse

Bug#995140: llvm-11-runtime: replace "which" by "command -v" in postinst script

[Vincent Lefevre]

Package: llvm-11-runtime
Version: 1:11.1.0-1
Severity: minor

When upgrading llvm-11-runtime:

Setting up llvm-11-runtime (1:11.1.0-1) ...
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.

Indeed, /var/lib/dpkg/info/llvm-11-runtime.postinst contains

if which update-binfmts >/dev/null; then
   ^

BTW, indentation is incorrect.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages llvm-11-runtime depends on:
ii  libc6   2.32-4
ii  libgcc-s1   11.2.0-8
ii  libllvm11   1:11.1.0-1
ii  libstdc++6  11.2.0-8
ii  libtinfo6   6.2+20210905-1
ii  libz3-4 4.8.12-1+b1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages llvm-11-runtime recommends:
ii  binfmt-support  2.2.1-1

llvm-11-runtime suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Jesse Smith]

On 2021-09-26 8:55 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> I checked out the init.d directories provided by Thorsten. One of the
>> features of insserv allows it to test init scripts in an alternative
>> directory or chroot.
> This seems to be broken:
>
> tglase@tglase:~ $ insserv -p etc-stripped
> insserv: fopen(/etc/init.d/.depend.boot): Permission denied
>
> (Having extracted the tarball as regular user so there are no
> permission issues.)

Hmm, that's interesting. What happens if you run "insserv -n -p
etc-stripped"? And then, if it suggests changing the symlinks from K02
to K01, doing that manually? eg "mv etc-stripped/rc0.d/K02avahi-daemon
etc-stripped/rc0.d/K01avahi-daemon" and then re-running insserv?

>> If others see the same behaviour I do, then I'm guessing there is
>> something else on the reporting system with the error which causes a
>> conflict. But if other people are seeing the "toggle" between K01 and
> Do you want strace(1)s or so?
>
Not yet, let's see what the above tests reveals first and go from there.

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Thorsten Glaser]

On Sun, 26 Sep 2021, Jesse Smith wrote:

> I checked out the init.d directories provided by Thorsten. One of the
> features of insserv allows it to test init scripts in an alternative
> directory or chroot.

This seems to be broken:

tglase@tglase:~ $ insserv -p etc-stripped
insserv: fopen(/etc/init.d/.depend.boot): Permission denied

(Having extracted the tarball as regular user so there are no
permission issues.)

> If others see the same behaviour I do, then I'm guessing there is
> something else on the reporting system with the error which causes a
> conflict. But if other people are seeing the "toggle" between K01 and

Do you want strace(1)s or so?

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Jesse Smith]

On 2021-09-26 3:25 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> behaviour. I've tried both the latest version of insserv (1.23.0) and
>> the version which shipped with Debian 10 (1.18.0). I did notice having
> This is Debian 11 so 1.21.0-1.1 (including Debian patches).
>
>> Thorsten, I wonder if you could give the latest version of insserv a try
> No, this is a remote machine where I prefer to not risk bootability.
>


I checked out the init.d directories provided by Thorsten. One of the
features of insserv allows it to test init scripts in an alternative
directory or chroot. I ran insserv versions 1.18.0, 1.21.0, and 1.23.0
against the init.d scripts provided in the "etc-stripped" directory
Thorsten uploaded.

In each case insserv detected that the avahi-daemon script should be
marked as K01 instead of K02. Which is good, that is consistent with
what I have on my system and it looks to be correct. Once this change
was made none of the three versions of insserv suggested switching
avahi-daemon back to K02. ie On my system insserv does not perform the
"toggle" action when given the uploaded init scripts.

Which means when any recent version of insserv is run against just the
init.d scripts provided it sets avahi-daemon to be K01 and leaves it
that way, future runs don't toggle the symlink back. At least that's
been my finding.

Can anyone else confirm that running "insserv -p etc-stripped/init.d" on
the uploaded scripts always sets avahi-daemon to K01, or do you get the
"toggle" behaviour in the bug report?

If others see the same behaviour I do, then I'm guessing there is
something else on the reporting system with the error which causes a
conflict. But if other people are seeing the "toggle" between K01 and
K02 on the provided scripts then I'm guessing things are just working
correctly for me due to an oversight or quirk of my system. Any feedback
on confirming or disputing my findings is appreciated.

- Jesse

Bug#995139: python-gevent build-depends on removed package

[peter green]

package: python-librtmp
version: 20.9.0-2
severity: serious
tags: bookworm, sid

python-librtmp build-depends on python3-cffi-backend-dbg, which has been 
dropped by the
python-cffi source package. It is still present in unstable as a cruft package
but is uninstallable due to version constraints. It is completely gone from 
testing.

Bug#995138: python-gevent build-depends on removed package

[peter green]

package: python-gevent
version: 20.9.0-2
severity: serious
tags: bookworm, sid

python-gevent build-depends on python3-cffi-backend-dbg, which has been dropped 
by the
python-cffi source package. It is still present in unstable as a cruft package
but is uninstallable due to version constraints. It is completely gone from 
testing.

Bug#995135: CryFS Conan build requirement

[Sebastian Messmer]

This may help: https://github.com/cryfs/cryfs#using-local-dependencies
It should, in theory, allow building by getting the dependencies from the 
local system instead of from Conan.


On September 26, 2021 2:39:10 PM David Steele  wrote:


Package: cryfs
severity: important
thanks


CryFS 0.11.0 is asking for conan to be present for the build. Conan is
not available in Debian, and provides a service that should not be
necessary in any case.

Resolve the CryFS build for 0.11.0-1.

Bug#995137: Can not get current location with gpsd

[Takeshi Soejima]

Package: marble-plugins
Version: 4:20.12.3-1

Dear Maintainer,

Marble with the plugin in bullseye can not get current location with
gpsd packaged in the same release (displaying "waiting for current
location information...").

  marble-qt (or marble) 4:20.12.3-1
  gpsd 3.22-4 (works fine with cgps and foxtrotgps)

I don't have such an experience with the package in buster (with gpsd in
buster or buster-backports).

Bug#995115: /usr/bin/ruby: symbol lookup error: /lib/x86_64-linux-gnu/libruby-2.7.so.2.7: undefined symbol: rb_st_numhash

[Francesco Poli]

Control: reassign -1 libruby2.7


On Sun, 26 Sep 2021 20:46:50 +0200 David Kalnischkies wrote:

[...]
> > 274 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
> > Need to get 0 B/745 MB of archives.
> > After this operation, 313 MB of additional disk space will be used.
> > Do you want to continue? [Y/n]
> > /usr/bin/ruby: symbol lookup error: 
> > /lib/x86_64-linux-gnu/libruby-2.7.so.2.7: undefined symbol: rb_st_numhash
> > E: Sub-process /usr/bin/apt-listbugs apt returned an error code (127)
> > E: Failure running script /usr/bin/apt-listbugs apt
> 
> The script exits unsuccessfully and as such the action is stopped.
> apt hence works as intended, it is "just" not intended that the scripts
> called do crash in such ways, but that is the bug of those scripts or
> their interpreters not of apt itself.

Hello xiscu,
I am the maintainer of apt-listbugs (thanks to David for reassigning
the bug report!).

As David explained, apt exits with errors, because apt-listbugs fails
to run.
But, from what I see, it seems that apt-listbugs fails to run, because
ruby (the interpreter for the programming language apt-listbugs is
written in) crashes with an undefined symbol error in its library
(libruby-2.7.so.27).

Hence, what you should do is understand why ruby crashes on your system.

Personally, I am unable to reproduce the crash: on my Debian testing
boxes, ruby (and apt-listbugs) works without any issues. I have also
tried on an up-to-date Debian unstable system, but it works there, as
well.

> 
> 
> > trying to deinstall apt-listbugs results on the same problem.

Trying to remove apt-listbugs using apt (or aptitude) will result in
another attempt to automatically run apt-listbugs (before it is
actually removed!), and hence, no luck!

But you can temporarily disable apt-listbugs, by editing file
'/etc/apt/apt.conf.d/10apt-listbugs' . Inside this file, you may
modify the following line:

  DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs apt";};

by prepending it with a comment symbol, so that it becomes:

  // DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs apt";};


That way, apt-listbugs will not run and you will (hopefully) be able to
use apt to fix your system.
Once your system is fixed, you should be able to run ruby programs
without any crash.
You may try to run apt-listbugs as your regular user:

  $ apt-listbugs -v
  0.1.35

When it works, without any crash, you may re-enable its automatic
invocation by apt (by reverting the above change to
'/etc/apt/apt.conf.d/10apt-listbugs').

I hope this is clear enough.

[...]
> Seems like a ruby upgrade broke it
[...]

It definitely seems that the problem is in ruby.
I am hence reassigning to libruby2.7 .

Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpdV31LcZE0m.pgp
Description: PGP signature

Bug#994454: golang-github-containers-common: should include debci test suite

[Reinhard Tartler]

Control: tag -1 help

Hi Bastien,

On Thu, Sep 16, 2021 at 4:36 AM Bastien Roucariès <
roucaries.bast...@gmail.com> wrote:

> Package: golang-github-containers-common
> Severity: important
>
> Dear Maintainer,
>
> This package is used in conjunction of podman to run container, and the
> secomp
> list could break due to kernel change on some arch or even lib change.
>
> It will be nice to exercice this package using podman to run a basic debian
> container running some classical package (systemd, at with a timer in 60s
> etc).
>
> It will allow to catch bug like #994451 using debci early and moreover run
> this
> test also at build time in order to catch regression during the rebuild
> phase
> of release on non debci arch.
>

I like that idea a lot. In this case, however, we would need to recompile
podman against the fixed containers/common. Shouldn't that debci test
therefore rather be in the src:libpod package?

Also, do you have experience how to write those tests? I'd be happy to
review/accept a patch doing so.

-- 
regards,
Reinhard

Bug#995136: RM: netbeans-cvsclient -- ROM; No longer used

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-j...@lists.debian.org

Hi,

Please remove the netbeans-cvsclient package, it was only used by maven-scm
but the dependency has been dropped in the 1.12.0-1 update. It's unlikely
this package will be useful again, so it's safe to remove it.

Thank you,

Emmanuel Bourg

Bug#995135: CryFS Conan build requirement

[David Steele]

Package: cryfs
severity: important
thanks


CryFS 0.11.0 is asking for conan to be present for the build. Conan is 
not available in Debian, and provides a service that should not be 
necessary in any case.


Resolve the CryFS build for 0.11.0-1.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#896460: Please package ipywidgets 7

[Drew Parsons]

Source: ipywidgets
Followup-For: Bug #896460

There are also 2nd order dependencies affected by this bug.

Docs for scipy 1.7 use pydata-sphinx-theme, which depends on jupyter-sphinx.

So the scipy upgrade is blocked.

Bug#953977: gridengine-drmaa1.0: Please install libdrmaa.so.1.0 into standard library dir

[Afif Elghraoui]

On 9/26/21 1:37 PM, Andreas Tille wrote:
> Hi Afif,
> 
> On Sun, Sep 26, 2021 at 01:20:34PM -0700, Afif Elghraoui wrote:
>>> My guess is that also other packages than python3-drmaa will profit from
>>> this.
>>
>> The thing is that gridengine is not the only implementation of drmaa,
>> though it seems to be the only one in current Debian releases. If we
>> wanted to do this right, I think we'd need to get a virtual package for
>> libdrmaa that gridengine and, for example, slurm could both provide.
> 
> would you volunteer to work on an accoring solution?
> 

I don't think so...at least not in the near term.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
https://afif.ghraoui.name

Bug#995129: Acknowledgement (upgrade of libc or something resulted in postfix/smtp[3114]: fatal: unknown service: smtp/tcp)

[Joey Hess]

root@kite:~>sh -x /usr/lib/postfix/configure-instance.sh
+ INSTANCE=
+ SYNC_CHROOT=y
+ test -r /etc/default/postfix
+ [ X = X ]
+ POSTCONF=postconf -o inet_interfaces=
+ + tr A-Z a-z
postconf -o inet_interfaces= -hx myorigin
+ MYORIGIN=kitenet.net
+ [ Xkitenet.net != Xkitenet.net ]
+ [ Xkitenet.net = Xubuntu.com ]
+ [ Xkitenet.net = Xdebian.org ]
+ postconf -o inet_interfaces= -hx config_directory
+ config_dir=/etc/postfix
+ postconf -o inet_interfaces=+ cut -d. -f1
 -hx mail_version
+ MAJOR_VER=3
+ [ 3 -ge 3 ]
+ CHROOT_TEST=[yY]
+ awk /^[0-9a-z]/ && ($5 ~ "[yY]") { print "y"; exit} /etc/postfix/master.cf
+ NEED_CHROOT=
+ [ -n  ]

This happens despite master.cf containing:

smtp  unix  -   -   -   -   -   smtp
relay unix  -   -   -   -   -   smtp

It seems that it only treats 'y' as being a chroot, but appears to not
match how postfix is parsing my file, which treats '-' as being a chroot
too. I'm basing this on changing that to a 'n' having fixed my problem.

So why is postfix parsing my master.cf that way? My file starts like this:

#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master" or
# on-line: http://www.postfix.org/master.5.html).
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==
# service type  private unpriv  chroot  wakeup  maxproc command + args
#   (yes)   (yes)   (yes)   (never) (100)
# ==
smtp  inet  n   -   n   -   -   smtpd
#smtp  inet  n   -   -   -   1   postscreen
#smtpd pass  -   -   -   -   -   smtpd
#dnsblog   unix  -   -   -   -   0   dnsblog
#tlsproxy  unix  -   -   -   -   0   tlsproxy

Could it be that something about this is making postfix parse it
with its old parser, that defaulted to enabling chroot for '-'?

Sep 26 16:32:41 kite postfix/master[24015]: /etc/postfix/master.cf: line 50: 
using backwards-compatible default setting chroot=y

Aha. My main.cf does not have a value for compatibility_level,
so it defaults to level 0, which behaves that way.

My postfix configs are quite old, addmittedly, but it seems
that if you're going to parse master.cf, it needs to be done fully
compatibly with how postfix parses it..

(I also noticed BTW, that /etc/init.d/postfix's running() check
always thinks postfix is running, even when it's not.
Somehow /usr/lib/postfix/sbin/master -t exits nonzero
even when no daemon is running. This would prevent updating
the chroot ever if that init script were actually used, but with
systemd it is not.)

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#995134: dkms modules fail to build on 5.14.0, error: ‘TIF_IA32’ undeclared

[Ryan Kavanagh]

Package: openafs-modules-dkms
Version: 1.8.6-5
Severity: grave
Justification: Renders package unusable

The openafs dkms modules fail to build on 5.14.0. I've attached
/var/lib/dkms/openafs/1.8.6/build/make.log.

-- System Information:
Debian Release: bookworm/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 5.14.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openafs-modules-dkms depends on:
ii  dkms   2.8.4-4
ii  libc6-dev  2.32-4
ii  perl   5.32.1-6

Versions of packages openafs-modules-dkms recommends:
ii  openafs-client  1.8.6-5

openafs-modules-dkms suggests no packages.

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A
DKMS make.log for openafs-1.8.6 for kernel 5.14.0-1-amd64 (x86_64)
Sun 26 Sep 17:00:15 EDT 2021
checking for gcc... gcc-10
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc-10 accepts -g... yes
checking for gcc-10 option to accept ISO C89... none needed
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to run the C preprocessor... gcc-10 -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for flex... no
checking for lex... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for libxslt... no
checking for saxon... no
checking for xalan-j... no
checking for xsltproc... xsltproc
checking for fop... no
checking for dblatex... no
checking for docbook2pdf... no
checking for kindlegen... no
checking for doxygen... no
checking for dot... dot
checking for library containing strerror... none required
checking for pid_t... yes
checking for size_t... yes
checking whether ln -s works... yes
checking for ranlib... ranlib
checking for bison... no
checking for byacc... no
checking if lex is flex... yes
checking whether byte order is known at compile time... yes
checking whether byte ordering is bigendian... no
checking whether printf understands the %z length modifier... yes
checking your OS... linux
checking for ranlib... (cached) ranlib
checking for as... as
checking for mv... mv
checking for rm... rm
checking for ld... ld
checking for cp... cp
checking for gencat... gencat
checking if gcc-10 accepts -march=pentium... no
checking if gcc-10 needs -fno-strength-reduce... yes
checking if gcc-10 needs -fno-strict-aliasing... yes
checking if gcc-10 supports -fno-common... yes
checking if gcc-10 supports -pipe... yes
checking if linux kbuild requires EXTRA_CFLAGS... no
checking if linux kernel module build works... yes
checking operation follow_link in inode_operations... no
checking operation put_link in inode_operations... no
checking operation rename in inode_operations... no
checking for linux/cred.h... yes
checking for linux/config.h... no
checking for linux/exportfs.h... yes
checking for linux/freezer.h... yes
checking for linux/key-type.h... yes
checking for linux/semaphore.h... yes
checking for linux/seq_file.h... yes
checking for linux/sched/signal.h... yes
checking for linux/uaccess.h... yes
checking for struct vfs_path... no
checking for kuid_t... yes
checking for struct proc_ops... yes
checking for time_t... no
checking for backing_dev_info in struct address_space... no
checking for write_begin in struct address_space_operations... yes
checking for name in struct backing_dev_info... no
checking for session_keyring in struct cred... yes
checking for ctl_name in struct ctl_table... no
checking for d_u.d_alias in struct dentry... yes
checking for d_automount in struct dentry_operations... yes
checking for gid in struct group_info... yes
checking for i_alloc_sem in struct inode... no
checking for i_blkbits in struct inode... yes
checking for i_blksize in struct inode... no
checking for i_mutex in struct inode... no
checking for i_security in struct inode... yes
checking for f_path in struct 

Bug#995133: python3-gpumodules: Error parsing amdfeaturemask

[Gregor Riepl]

Package: python3-gpumodules
Version: 3.5.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: onit...@gmail.com

Dear Maintainer,

gpu-pac currently fails on my system because of a hex string parsing issue in
python3-gpumodules:

Traceback (most recent call last):
  File "/usr/bin/gpu-pac", line 1323, in 
main()
  File "/usr/bin/gpu-pac", line 1274, in main
gpu_list.set_gpu_list()
  File "/usr/lib/python3/dist-packages/GPUmodules/GPUmodule.py", line 1666, in
set_gpu_list
self.amd_featuremask = env.GUT_CONST.read_amdfeaturemask()
  File "/usr/lib/python3/dist-packages/GPUmodules/env.py", line 205, in
read_amdfeaturemask
self.amdfeaturemask = int(fm_file.readline())
ValueError: invalid literal for int() with base 10: '0xbfff\n'

This issue is fixed in gpu-utils 3.6.0. Please push an upgrade.

In the meantime, there is a simple workaround:
In /usr/lib/python3/dist-packages/GPUmodules/env.py, line 205, add ", 0" so
int() will accept hex strings in addition to decimal.
The line should look like this:
self.amdfeaturemask = int(fm_file.readline(), 0)

Thank you very much.

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

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

Versions of packages python3-gpumodules depends on:
ii  lshw  02.18.85-0.7
ii  python3   3.9.2-3
ii  python3-cycler0.10.0-3
ii  python3-dateutil  2.8.1-6
ii  python3-kiwisolver1.3.1-1+b1
ii  python3-matplotlib3.3.4-1
ii  python3-numpy 1:1.19.5-1
ii  python3-pandas1.1.5+dfsg-2
ii  python3-pyparsing 2.4.7-1
ii  python3-ruamel.yaml   0.16.12-2
ii  python3-ruamel.yaml.clib  0.2.2-1+b2
ii  python3-six   1.16.0-2
ii  python3-tz2021.1-1

python3-gpumodules recommends no packages.

Versions of packages python3-gpumodules suggests:
ii  ricks-amdgpu-utils  3.5.0-1

Bug#995122: Clang and /usr/lib/cuda

[Raul Tambre]

Package: nvidia-cuda-toolkit
Version: 11.3.1-4
Severity: important

Dear maintainer,

Clang recently changed its CUDA version discovery to use cuda.h since 
version.txt is no more. See the LLVM commit 
.


It is read from /include/cuda.h.
/usr/lib/cuda is used as a special case by Clang on Debian/Ubuntu and also by 
CMake 
.


On my installations /usr/lib/cuda/include is an empty directory. The CUDA 
version detection fails, Clang falls back to the latest version it knows (11.4) 
and ptxas fails to assemble due to PTX assembly being for a newer version.


Could we symlink /usr/lib/cuda/include to /usr/include?

A solution before Clang 14 makes it into the repository seems desirable.
Ideally this would also be backported as a fix so users wishing to use a newer 
self-built Clang on older versions could do so.


Discussion in the TensorFlow issues linked in bug #985798 indicate that they 
are/were moving towards assuming a similar layout as Clang (/usr/lib/cuda). It 
seems likely the breakage would also extend to that and be fixed by the proposed 
symlink.


Also see:
* CMake bug 
* LLVM commit discussion 

Bug#953977: gridengine-drmaa1.0: Please install libdrmaa.so.1.0 into standard library dir

[Andreas Tille]

Hi Afif,

On Sun, Sep 26, 2021 at 01:20:34PM -0700, Afif Elghraoui wrote:
> > My guess is that also other packages than python3-drmaa will profit from
> > this.
> 
> The thing is that gridengine is not the only implementation of drmaa,
> though it seems to be the only one in current Debian releases. If we
> wanted to do this right, I think we'd need to get a virtual package for
> libdrmaa that gridengine and, for example, slurm could both provide.

would you volunteer to work on an accoring solution?

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Bug#953977: gridengine-drmaa1.0: Please install libdrmaa.so.1.0 into standard library dir

[Afif Elghraoui]

On 3/15/20 2:44 AM, Andreas Tille wrote:
> as you can read in bug #953832 I need a patch[1] for python-drmaa to find
> libdrmaa.so.1.0.  As Sergio pointed out in his comment[2] this is due an
> unusual location of the library.  It would be great if you would consider
> installing it rather to
> 
> /usr/lib/${DEB_HOST_MULTIARCH}/
> 
> instead of
> 
> /usr/lib/gridengine-drmaa/lib/
> 
> My guess is that also other packages than python3-drmaa will profit from
> this.

The thing is that gridengine is not the only implementation of drmaa,
though it seems to be the only one in current Debian releases. If we
wanted to do this right, I think we'd need to get a virtual package for
libdrmaa that gridengine and, for example, slurm could both provide.

thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
https://afif.ghraoui.name

Bug#993922: amtk: abandoned upstream

[Jeremy Bicha]

On Wed, Sep 8, 2021 at 4:42 AM Simon McVittie  wrote:
> There seems to be a fork at https://github.com/gedit-org/amtk (along with
> a fork of gedit) but it specifically does not accept contributions either.
> This seems like something that Debian should not be relying on.

The amtk situation (and other projects managed by that developer) is strange.

He changed the github version from "contributions not accepted" to
"contributing - will open soon"
https://github.com/gedit-org/amtk/commit/72b37d96d8
https://gedit-org.github.io/dev.html

Thanks,
Jeremy

Bug#995111: closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#995111: fixed in librandomx 1.1.8-3)

[Age Bosma]

Hi,

Thank you for the swift response.
Unfortunately both the new 1.1.8-3 as well as 1.1.9-1 still suffer the same 
issue.

-
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/librandomx0/DEBIAN/symbols doesn't match 
completely debian/librandomx0.symbols
--- debian/librandomx0.symbols (librandomx0_1.1.8-3_amd64)
+++ dpkg-gensymbolsgIIzSc   2021-09-26 16:16:57.240027567 +
@@ -608,7 +608,7 @@
  
(optional=privatelib)_ZN7randomx20AssemblyGeneratorX869h_IMULH_RERNS_11InstructionEi@Base
 1.1.7
  
(optional=privatelib)_ZN7randomx20AssemblyGeneratorX869h_ISWAP_RERNS_11InstructionEi@Base
 1.1.7
  (optional=privatelib)_ZN7randomx22SuperscalarInstruction4NullE@Base 1.1.7
- 
_ZN7randomx22SuperscalarInstruction6createEPKNS_26SuperscalarInstructionInfoERNS_15Blake2GeneratorE@Base
 1.1.8
+#MISSING: 1.1.8-3# 
_ZN7randomx22SuperscalarInstruction6createEPKNS_26SuperscalarInstructionInfoERNS_15Blake2GeneratorE@Base
 1.1.8
  (optional=privatelib)_ZN7randomx26SuperscalarInstructionInfo3NOPE@Base 1.1.7
  (optional=privatelib)_ZN7randomx26SuperscalarInstructionInfo6IMUL_RE@Base 
1.1.7
  (optional=privatelib)_ZN7randomx26SuperscalarInstructionInfo6IROR_CE@Base 
1.1.7
@@ -749,8 +749,9 @@
  (optional=privatelib)_ZNK7randomx11Instruction9h_IMULH_RERSo@Base 1.1.7
  (optional=privatelib)_ZNK7randomx11Instruction9h_ISWAP_RERSo@Base 1.1.7
  (optional=privatelib)_ZNKSt5ctypeIcE8do_widenEc@Base 1.1.7
- (optional=privatelib|arch=i386 
mipsel)_ZNSt6vectorIN7randomx7MacroOpESaIS1_EE12emplace_backIJS1_EEEvDpOT_@Base 
1.1.7
+ 
(optional=privatelib)_ZNSt6vectorIN7randomx7MacroOpESaIS1_EE12emplace_backIJS1_EEEvDpOT_@Base
 1.1.7
  
(optional=privatelib)_ZNSt6vectorIN7randomx7MacroOpESaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 1.1.7
+ _ZNSt6vectorIiSaIiEE12emplace_backIJiEEEvDpOT_@Base 1.1.8-3
  
(optional=privatelib|arch=amd64)_ZNSt6vectorIiSaIiEE17_M_realloc_insertIJRKiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_@Base
 1.1.7
  
(optional=privatelib)_ZNSt6vectorIiSaIiEE17_M_realloc_insertIJiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_@Base
 1.1.7
  (optional=privatelib|arch=!armel !armhf !hppa !i386 !mipsel 
!powerpc)_ZNSt6vectorImSaImEE17_M_realloc_insertIJRKmEEEvN9__gnu_cxx17__normal_iteratorIPmS1_EEDpOT_@Base
 1.1.7
dh_makeshlibs: error: failing due to earlier errors
make: *** [debian/rules:43: binary] Error 1
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
-

-
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/librandomx0/DEBIAN/symbols doesn't match 
completely debian/librandomx0.symbols
--- debian/librandomx0.symbols (librandomx0_1.1.9-1_amd64)
+++ dpkg-gensymbolscnxo1b   2021-09-26 16:14:56.093354659 +
@@ -608,7 +608,7 @@
  
(optional=privatelib)_ZN7randomx20AssemblyGeneratorX869h_IMULH_RERNS_11InstructionEi@Base
 1.1.7
  
(optional=privatelib)_ZN7randomx20AssemblyGeneratorX869h_ISWAP_RERNS_11InstructionEi@Base
 1.1.7
  (optional=privatelib)_ZN7randomx22SuperscalarInstruction4NullE@Base 1.1.7
- 
_ZN7randomx22SuperscalarInstruction6createEPKNS_26SuperscalarInstructionInfoERNS_15Blake2GeneratorE@Base
 1.1.8
+#MISSING: 1.1.9-1# 
_ZN7randomx22SuperscalarInstruction6createEPKNS_26SuperscalarInstructionInfoERNS_15Blake2GeneratorE@Base
 1.1.8
  (optional=privatelib)_ZN7randomx26SuperscalarInstructionInfo3NOPE@Base 1.1.7
  (optional=privatelib)_ZN7randomx26SuperscalarInstructionInfo6IMUL_RE@Base 
1.1.7
  (optional=privatelib)_ZN7randomx26SuperscalarInstructionInfo6IROR_CE@Base 
1.1.7
@@ -749,8 +749,9 @@
  (optional=privatelib)_ZNK7randomx11Instruction9h_IMULH_RERSo@Base 1.1.7
  (optional=privatelib)_ZNK7randomx11Instruction9h_ISWAP_RERSo@Base 1.1.7
  (optional=privatelib)_ZNKSt5ctypeIcE8do_widenEc@Base 1.1.7
- (optional=privatelib|arch=i386 
mipsel)_ZNSt6vectorIN7randomx7MacroOpESaIS1_EE12emplace_backIJS1_EEEvDpOT_@Base 
1.1.7
+ 
(optional=privatelib)_ZNSt6vectorIN7randomx7MacroOpESaIS1_EE12emplace_backIJS1_EEEvDpOT_@Base
 1.1.7
  
(optional=privatelib)_ZNSt6vectorIN7randomx7MacroOpESaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 1.1.7
+ _ZNSt6vectorIiSaIiEE12emplace_backIJiEEEvDpOT_@Base 1.1.9-1
  
(optional=privatelib|arch=amd64)_ZNSt6vectorIiSaIiEE17_M_realloc_insertIJRKiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_@Base
 1.1.7
  
(optional=privatelib)_ZNSt6vectorIiSaIiEE17_M_realloc_insertIJiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_@Base
 1.1.7
  (optional=privatelib|arch=!armel !armhf !hppa !i386 !mipsel 
!powerpc)_ZNSt6vectorImSaImEE17_M_realloc_insertIJRKmEEEvN9__gnu_cxx17__normal_iteratorIPmS1_EEDpOT_@Base
 1.1.7
@@ -943,7 +944,7 @@
  

Bug#994179: Upstream mess

[積丹尼 Dan Jacobson]

OK I meant serious: "makes the package unsuitable for release."
Because it is now spitting out error messages on every use.

Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1

[Aurelien Jarno]

Hi,

On 2021-09-26 20:46, Adam D. Barratt wrote:
> On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote:
> [...]
> > In the meantime another issue that would need to be fixed in sid
> > > > came
> > as
> > bug#994042. 
> > 
> > This time the issue is in the preinst. To summarize, in the case
> > debconf is not usable to prompt the user about the upgrade, the
> > preinst switches to text prompt. However as the debconf module has
> > been loaded got control of the tty, which prevent any input from the
> > user. For skilled users it still possible to kill the upgrade from
> > another, but other users will probably try other actions that might
> > have damaging effects (like rebooting the system).
> > 
> > The fix is to get the debconf configuration without using the debconf
> > module, as suggested by Colin Watson.
> > 
> 
> Thanks. That looks OK to me, particularly with Colin's review.

Thanks for the review. I guess that now it just needs a kibi-ack.
 
> Is there an ETA for getting the fix into unstable?

Upgrades from buster to bookworm are not supported, so it means upgrade
to bookworm starts from bullseye, which has a fixed debconf (the issue
has been fixed in version 1.5.76). Therefore the fix in unstable has
been done in glibc 2.32-3 by just dropping all the workaround:

https://salsa.debian.org/glibc-team/glibc/-/commit/66359576b1aa793ae6c79618b188738287cf8789

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#995131: nut: reproducible builds: udev rules vary depending readdir order

[Vagrant Cascadian]

Control: forwarded 995131 https://github.com/networkupstools/nut/pull/528
Control: tags 995131 fixed-upstream

Already reported and fixed upstream:

  
https://github.com/networkupstools/nut/commit/d693c427c526af1a933fa9aa95165c483fe08114

The patch is basically the same.

No new upstream release has been made in the years since... there does
seem to be some recent activity in git.


live well,
  vagrant

On 2021-09-26, Vagrant Cascadian wrote:
> The comments for various udev rules list different drivers for some
> devices.
>
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/nut.html
>
>   /lib/udev/rules.d/62-nut-usbups.rules
>
>   Krauler·UP-M500VA··-·blazer_usb
>   vs.
>   Krauler·UP-M500VA··-·nutdrv_qx
>
> The udev rules are generated from tools/nut-usbinfo.pl reading the files
> in ../drivers/, using perl's File::Find, which does not reliably return
> the same file ordering. In some cases, multiple drivers claim support
> for a given device, and which driver gets embedded into the udev
> comments depends on the order in which the directory contents were
> returned.
>
> The attached patch fixes this by sorting the directory output.
>
> With this patch applied, nut should become reproducible on
> tests.reproducible-builds.org.
>
> Our test infrastructure seems to only reliably catch this issue on i386
> and armhf (e.g. 32-bit architectures).
>
>
> Thanks for maintaining nut!
>
>
> live well,
>   vagrant
> From c18bf3799a6b8dafcfe42c1a0e595ae54b7d3f82 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Sun, 26 Sep 2021 19:21:00 +
> Subject: [PATCH] nut-usbinfo.pl: Sort the directory scan results.
>
> The order of the files processed depends on readdir order. As some
> devices are supported by multiple drivers, which one gets embedded in
> the output (e.g. udev rules) depends on the order of the processed
> files.
>
> https://reproducible-builds.org/docs/stable-inputs/
> ---
>  tools/nut-usbinfo.pl | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/nut-usbinfo.pl b/tools/nut-usbinfo.pl
> index 2c0dd05..56dd331 100755
> --- a/tools/nut-usbinfo.pl
> +++ b/tools/nut-usbinfo.pl
> @@ -76,7 +76,9 @@ my %vendorName;
>  
>  # MAIN #
>  
> -find(\_usbdevs,$scanPath);
> +find({wanted => \_usbdevs,
> +  preprocess => sub { sort(@_)}}
> + ,$scanPath);
>  _usb_files;
>  
>  # SUB METHOD #
> -- 
> 2.33.0


signature.asc
Description: PGP signature

Bug#995132: libhtml-treebuilder-libxml-perl: autopkgtest regression between 5 September 2021 and 25 September 2021

[Paul Gevers]

Source: libhtml-treebuilder-libxml-perl
Version: 0.26-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-CC: debian...@lists.debian.org

Dear maintainer(s),

Your package has an autopkgtest, great! However, somewhere between last
month and today it started to fail [1]. Unfortunately our migration
setup didn't catch this because it's either caused by something external
to the archive, or the package that caused it is in not a direct (build)
dependency of your packages. Can you fix the situation?

Paul

[1] https://ci.debian.net/packages/libh/libhtml-treebuilder-libxml-perl/

https://ci.debian.net/data/autopkgtest/testing/amd64/libh/libhtml-treebuilder-libxml-perl/15530611/log.gz

not ok 7 - 2 atts on same element # TODO I don't know, this order is
required for xpath spec, or not??
#   Failed (TODO) test '2 atts on same element'
#   at t/HTML-TreeBuilder-XPath.t line 39.
#  got: 'foomyspan'
# expected: 'myspanfoo'
not ok 8 - 2 atts on same element # TODO I don't know, this order is
required for xpath spec, or not??
#   Failed (TODO) test '2 atts on same element'
#   at t/HTML-TreeBuilder-XPath.t line 40.
#  got: 'foomyspan'
# expected: 'myspanfoo'
not ok 9 - 2 atts on same element (unsorted) # TODO I don't know, this
order is required for xpath spec, or not??
#   Failed (TODO) test '2 atts on same element (unsorted)'
#   at t/HTML-TreeBuilder-XPath.t line 41.
#  got: 'foomyspan'
# expected: 'myspanfoo'



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995131: nut: reproducible builds: udev rules vary depending readdir order

[Vagrant Cascadian]

Source: nut
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The comments for various udev rules list different drivers for some
devices.

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/nut.html

  /lib/udev/rules.d/62-nut-usbups.rules

  Krauler·UP-M500VA··-·blazer_usb
  vs.
  Krauler·UP-M500VA··-·nutdrv_qx

The udev rules are generated from tools/nut-usbinfo.pl reading the files
in ../drivers/, using perl's File::Find, which does not reliably return
the same file ordering. In some cases, multiple drivers claim support
for a given device, and which driver gets embedded into the udev
comments depends on the order in which the directory contents were
returned.

The attached patch fixes this by sorting the directory output.

With this patch applied, nut should become reproducible on
tests.reproducible-builds.org.

Our test infrastructure seems to only reliably catch this issue on i386
and armhf (e.g. 32-bit architectures).


Thanks for maintaining nut!


live well,
  vagrant
From c18bf3799a6b8dafcfe42c1a0e595ae54b7d3f82 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 26 Sep 2021 19:21:00 +
Subject: [PATCH] nut-usbinfo.pl: Sort the directory scan results.

The order of the files processed depends on readdir order. As some
devices are supported by multiple drivers, which one gets embedded in
the output (e.g. udev rules) depends on the order of the processed
files.

https://reproducible-builds.org/docs/stable-inputs/
---
 tools/nut-usbinfo.pl | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/nut-usbinfo.pl b/tools/nut-usbinfo.pl
index 2c0dd05..56dd331 100755
--- a/tools/nut-usbinfo.pl
+++ b/tools/nut-usbinfo.pl
@@ -76,7 +76,9 @@ my %vendorName;
 
 # MAIN #
 
-find(\_usbdevs,$scanPath);
+find({wanted => \_usbdevs,
+  preprocess => sub { sort(@_)}}
+ ,$scanPath);
 _usb_files;
 
 # SUB METHOD #
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#995128: dbus-user-session: Non-functional dbus-user-session installation

[Simon McVittie]

Control: tags -1 + moreinfo

On Sun, 26 Sep 2021 at 12:01:51 -0700, Francois Marier wrote:
> I installed dbus-user-session but it doesn't look functional:
...
> I'm not too sure if I should be manually starting it from my desktop
> environment (i3 + gnome-settings-daemon)

What's meant to happen is:

* your display manager runs the /etc/pam.d/common-session stack, which
  includes "session optional pam_systemd.so" from the libpam-systemd package

* pam_systemd tells systemd (pid 1) to start user@1000.service, which is
  systemd --user, launching default.target by default

* default.target includes dbus.socket because
  /usr/lib/systemd/user/sockets.target.wants/dbus.socket says so

* dbus.socket listens on $XDG_RUNTIME_DIR/bus

* the first time something connects to that socket, it starts dbus.service,
  which is dbus-daemon --session --address=systemd: (plus some other options)

Presumably something has gone wrong somewhere in that chain of events?

> $ ls -lh $XDG_RUNTIME_DIR/bus
> ls: cannot access '/run/user/1000/bus': No such file or directory
> 
> $ systemctl --user status dbus.service
> Failed to get properties: Process org.freedesktop.systemd1 exited with status 
> 1
> 
> $ systemctl --user status dbus.socket
> Failed to get properties: Process org.freedesktop.systemd1 exited with status 
> 1

If you can't tell what's wrong by comparing the chain of events I described
with what is actually happening on your system, here are some other things
that would be useful information:

Is there a "systemd --user" process running as your uid?

Is there a "dbus-daemon --session" process running as your uid?

Is anything D-Bus-related logged in the systemd Journal when you log in?

What does `systemd-cgls` say about these various services?

smcv

Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1

[Adam D. Barratt]

On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote:
[...]
> In the meantime another issue that would need to be fixed in sid
> > > came
> as
> bug#994042. 
> 
> This time the issue is in the preinst. To summarize, in the case
> debconf is not usable to prompt the user about the upgrade, the
> preinst switches to text prompt. However as the debconf module has
> been loaded got control of the tty, which prevent any input from the
> user. For skilled users it still possible to kill the upgrade from
> another, but other users will probably try other actions that might
> have damaging effects (like rebooting the system).
> 
> The fix is to get the debconf configuration without using the debconf
> module, as suggested by Colin Watson.
> 

Thanks. That looks OK to me, particularly with Colin's review.

Is there an ETA for getting the fix into unstable?

Regards,

Adam

Bug#995119: LXDE: switch network management from connman to network-manager?

[Holger Wansing]

Package: lxde
Severity: wishlist


Hi LXDE people,

looking at #988696 and #994875, I would like to ask, if you would be fine
with switching the main desktop network-management tool away from connman to
network-manager.

The main reasons are connman-gtk's lack of a system-tray icon (so users are not
easily aware of the existence of the tool) and some basically missing 
features [1].

It seems that network-manager is considered as the quasi-standard tool for
network management these days, so question is, if you have some strong ambitions
on using connman.
LXDE being a light-weighted desktop environment, I guess a main point will be
the disk-space and memory footprint, and currently this would be indeed an
issue, since the installation of network-manager on top of a current LXDE
installation uses 39 MB of additional disk space.

(However, it was already proposed by a network-manager maintainer, that the
used disk space could be reduced by 8,5 MB via the creation of a 
network-manager-l10n package or even more by the splitt-off of some plugin 
modules into separate packages [2].)



Technically such switch from connman to network-manager could be done just by
a swapping in a Recommends: line for the lxde package:

- connman-gtk | network-manager-gnome | wicd
+ network-manager-gnome | connman-gtk | wicd


What do you think?

Holger



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988696#106
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988696#96

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#993945: transition: evolution-data-server

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-evolution-data-server.html

On 2021-09-26 09:19:54 -0400, Jeremy Bicha wrote:
> https://release.debian.org/transitions/html/auto-evolution-data-server.html
> 
> This needs sourceful uploads of evolution-data-server, evolution, and
> evolution-ews. Then binNMUs for the rest.
> 
> The libgweather transition completed.
> 
> However, we probably want glib2.0 to migrate to testing first (now
> entangled with the libffi transition) since the rebuilds could easily
> end up with a dependency on the new glib.

Please feel free to go ahead after glib2.0 migrated.

Cheers

> 
> Thanks,
> Jeremy Bicha
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#988696: LXDE: Please include a user-friendly network management tool

[Holger Wansing]

Hi,

"Amy Kos"  wrote (Sun, 26 Sep 2021 13:03:03 +):
> Hi,
> 
> if you want to prefer network-manager, better do it in lxde metapackage
> instead of task-lxde-desktop which depends on the lxde metapackage.
> https://salsa.debian.org/lxde-team/lxde-metapackages/-/blob/debian/debian/control
> For instance change line 44 from
>  connman-gtk | network-manager-gnome | wicd, deluge | transmission-gtk,
> to
>  network-manager-gnome | connman-gtk | wicd, deluge | transmission-gtk,

Yes, I am about preparing a bugreport against lxde, to switch from connman
to network-manager, with exactly that patch proposal :-)

> If you want to keep connman it looks like there is a status icon option:
> https://github.com/jgke/connman-gtk
> > -Duse_status_icon=[true,false]
> > Enable or disable the status icon. Future GTK versions might remove the 
> > support for status icons, but as of 3.18 the support is still there, just 
> > deprecated.
> 
> By the way, there is a similar feature request for Lxqt too:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975524

Ok, I will follow up on that one too.


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#994540: transition: imagemagick

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/auto-imagemagick.html
Control: tags -1 moreinfo

On 2021-09-17 12:51:37 +, Bastien Roucariès wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Imagemagick changes some internal structures. Upstream bump so (safe), so ask
> for a rebuilt.

Do all reverse dependencies build fine with the new Imagemagick version?
If not, have bugs been filed?

Cheers

> 
> Ben file:
> 
> title = "imagemagick";
> is_affected = .depends ~
> "(?:libmagickcore-6.q[^-]+-6|libmagickwand-6.q[^-]+-6|libmagick++-6.q[^-]+-8)"
> | .depends ~
> "(?:libmagickcore-6.q[^-]+-7|libmagickwand-6.q[^-]+-7|libmagick++-6.q[^-]+-9)";
> is_good = .depends ~
> "(?:libmagickcore-6.q[^-]+-7|libmagickwand-6.q[^-]+-7|libmagick++-6.q[^-]+-9)";
> is_bad = .depends ~
> "(?:libmagickcore-6.q[^-]+-6|libmagickwand-6.q[^-]+-6|libmagick++-6.q[^-]+-8)";

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#995130: openssh: CVE-2021-41617

[Salvatore Bonaccorso]

Source: openssh
Version: 1:8.4p1-6
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:8.4p1-5
Control: found -1 1:7.9p1-10+deb10u2
Control: found -1 1:7.9p1-10

Hi,

The following vulnerability was published for openssh.

CVE-2021-41617[0]:
| sshd in OpenSSH 6.2 through 8.x before 8.8, when certain non-default
| configurations are used, allows privilege escalation because
| supplemental groups are not initialized as expected. Helper programs
| for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with
| privileges associated with group memberships of the sshd process, if
| the configuration specifies running the command as a different user.

IMHO it might be enough to address this via an upcoming point release
for both bullseye and buster.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-41617
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41617
[1] https://www.openwall.com/lists/oss-security/2021/09/26/1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#995129: upgrade of libc or something resulted in postfix/smtp[3114]: fatal: unknown service: smtp/tcp

[Joey Hess]

Package: postfix
Version: 3.5.6-1+b1
Severity: normal

This server is following testing, and has automatic upgrades enabled. On
Sep 22, all outgoing mail ceased flowing. 

I have been able to work around the problem by disabling chrooting for
smtp in master.cf.

/var/spool/postfix/etc/services seems ok, it was last modified in 2020
and has:

smtp25/tcp  mail

It does seem like it's out of date compared to /etc/services.

Looking at the logs, the error first occurred at 6:32.
At very close to the same time, there was this automatic upgrade:

2021-09-22 06:30:46 upgrade libc6:amd64 2.31-17 2.32-4

Other packages were upgraded too, but a libc upgrade folowed by a
nsswitch problem 2 minutes later seems probably related.

Looking at /var/spool/postfix/lib/x86_64-linux-gnu/ I 
notice it's kind of a mess:

-rw-r--r-- 1 root root  99K May  7  2020 libgcc_s.so.1
-rw-r--r-- 1 root root  31K Sep 21  2015 libnss_compat-2.19.so
-rw-r--r-- 1 root root  31K Feb 17  2016 libnss_compat-2.21.so
-rw-r--r-- 1 root root  31K Jun 26  2016 libnss_compat-2.22.so
-rw-r--r-- 1 root root  31K Aug 23  2016 libnss_compat-2.23.so
-rw-r--r-- 1 root root  31K Aug 26  2017 libnss_compat-2.24.so
-rw-r--r-- 1 root root  31K Dec 16  2017 libnss_compat-2.25.so
-rw-r--r-- 1 root root  31K Jan 26  2018 libnss_compat-2.26.so
-rw-r--r-- 1 root root  39K Oct 29  2018 libnss_compat-2.27.so
-rw-r--r-- 1 root root  39K May  1  2019 libnss_compat-2.28.so
-rw-r--r-- 1 root root  39K Feb  4  2020 libnss_compat-2.29.so
-rw-r--r-- 1 root root  39K Mar 25  2020 libnss_compat-2.30.so
lrwxrwxrwx 1 root root   21 Mar 25  2020 libnss_compat.so.2 -> 
libnss_compat-2.30.so
-rw-r--r-- 1 root root  23K Sep 21  2015 libnss_dns-2.19.so
-rw-r--r-- 1 root root  23K Feb 17  2016 libnss_dns-2.21.so
-rw-r--r-- 1 root root  23K Jun 26  2016 libnss_dns-2.22.so
-rw-r--r-- 1 root root  23K Aug 23  2016 libnss_dns-2.23.so
-rw-r--r-- 1 root root  23K Aug 26  2017 libnss_dns-2.24.so
-rw-r--r-- 1 root root  23K Dec 16  2017 libnss_dns-2.25.so
-rw-r--r-- 1 root root  23K Jan 26  2018 libnss_dns-2.26.so
-rw-r--r-- 1 root root  27K Oct 29  2018 libnss_dns-2.27.so
-rw-r--r-- 1 root root  27K May  1  2019 libnss_dns-2.28.so
-rw-r--r-- 1 root root  27K Feb  4  2020 libnss_dns-2.29.so
-rw-r--r-- 1 root root  27K Mar 25  2020 libnss_dns-2.30.so
lrwxrwxrwx 1 root root   18 Mar 25  2020 libnss_dns.so.2 -> libnss_dns-2.30.so
-rw-r--r-- 1 root root  47K Sep 21  2015 libnss_files-2.19.so
-rw-r--r-- 1 root root  47K Feb 17  2016 libnss_files-2.21.so
-rw-r--r-- 1 root root  47K Jun 26  2016 libnss_files-2.22.so
-rw-r--r-- 1 root root  47K Aug 23  2016 libnss_files-2.23.so
-rw-r--r-- 1 root root  47K Aug 26  2017 libnss_files-2.24.so
-rw-r--r-- 1 root root  47K Dec 16  2017 libnss_files-2.25.so
-rw-r--r-- 1 root root  47K Jan 26  2018 libnss_files-2.26.so
-rw-r--r-- 1 root root  55K Oct 29  2018 libnss_files-2.27.so
-rw-r--r-- 1 root root  55K May  1  2019 libnss_files-2.28.so
-rw-r--r-- 1 root root  51K Feb  4  2020 libnss_files-2.29.so
-rw-r--r-- 1 root root  51K Mar 25  2020 libnss_files-2.30.so
lrwxrwxrwx 1 root root   18 Mar 25  2020 libnss_files.so.2 -> 
libnss_files-2.30.so

Same for the ooutside the chroot.
of these libs in /lib/x86_64-linux-gnu/

lrwxrwxrwx 1 root root 20 Sep 19 14:46 /lib/x86_64-linux-gnu/libnss_files.so.2 
-> libnss_files-2.32.so

This makes me wonder a) why are the old ones not getting cleaned out
b) why are the new ones not copied in yet, and c) might there be 
libnss version skew with libc?

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.13+dfsg-7
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  e2fsprogs  1.46.4-1
ii  libc6  2.32-4
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libicu67   67.1-7
ii  libnsl21.3.0-2
ii  libsasl2-2 2.1.27+dfsg-2.1
ii  libssl1.1  1.1.1l-1
ii  lsb-base   11.1.0
ii  netbase6.3
ii  ssl-cert   1.1.0+nmu1

Versions of packages postfix recommends:
ii  ca-certificates  20210119
ii  python3  3.9.2-3

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]8.1.2-0.20180807cvs-2
ii  dovecot-core [dovecot-common]  1:2.3.16+dfsg1-3
ii  libsasl2-modules   2.1.27+dfsg-2.1
ii  mutt [mail-reader] 2.0.5-4.1
pn  postfix-cdb
pn  postfix-doc
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mysql  
ii  postfix-pcre

Bug#995116: Acknowledgement (pipewire: Soundcards not found on pipewire)

[Alexandre Lymberopoulos]

Dear all,

I've to apologize for submitting this bug, since I could "fix" it and
understand what really happened: after waking from hibernation/suspend
to ram the sound cards were "recognized again" appearing duplicated in
the pavucontrol Configuration tab, this probably caused confusion on the
sound system.

Thanks again.

Best, Alexandre

On Sep 26 2021, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 995116: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995116.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Utopia Maintenance Team 
> 
> If you wish to submit further information on this problem, please
> send it to 995...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 995116: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995116
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

-- 
===
Alexandre Lymberopoulos - lym...@gmail.com
===

Bug#993824: transition: libqalculate

[Sebastian Ramacher]

Hi Phil

On 2021-09-16 23:09:17 +0200, Sebastian Ramacher wrote:
> On 2021-09-10 09:49:05 +0200, Sebastian Ramacher wrote:
> > Control: tags -1 confirmed
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/auto-libqalculate.html
> > 
> > On 2021-09-06 23:49:01, Phil Morrell wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > 
> > > https://release.debian.org/transitions/html/auto-libqalculate.html
> > > 
> > > Please can we go ahead with the auto-libqalculate transition now? The
> > > new version is in experimental and has built on all release arches,
> > > including ports that gnuplot-nox is available for.
> > > 
> > > https://buildd.debian.org/status/package.php?p=libqalculate=experimental
> > > 
> > > It has 4 reverse dependencies which have all been test built with the
> > > new version and we have significant team overlap with them for future
> > > uploads.
> > 
> > Please go ahead
> 
> It seems that the move from libqalculate20-data to libqalculate-data is
> causing some issues. If one has task-kde-desktop installed, apt is
> unable to find an upgrade path and offers to remove task-kde-desktop
> instead. (This as reported and debugged on #debian-next)
> 
> I think a transitional and empty libqalculate20-data that depends on
> libqalculate-data and versioned Breaks+Replaces in libqalculate-data
> would help in this case. It would make libqalculate20 and libqalculate22
> coinstallable hopefolly helping apt to find a better solution than to
> remove task-kde-desktop.

Any chance an upload for that could happen soon?

Cheers

> 
> Cheers
> -- 
> Sebastian Ramacher



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#995018: jupyterlab-server 2.4.0-1 broken by jupyter-server 1.10.2-1

[Paul Gevers]

Hi Julien,

On 26-09-2021 20:28, Julien Puydt wrote:
> I just tried to rebuild jupyterlab-server in my unstable sbuild, and
> could check that it used the jupyter-server you complain about, and
> passes the tests.
> 
> I suspect the problem is that the latest version of python3-anyio
> doesn't migrate to testing (blocked by pytest).

Are you missing a *versioned* (test) dependency then? If all that's
needed is the newer version of python3-anyio to fix the autopkgtest

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994888: chromium: chrome://extensions/ broken

[Denis Krivosheev]

chrome://bookmarks/, chrome://downloads/, chrome://history/ are also broken.

Chromium 93.0.4577.82, Debian x86_64 bookworm.

Best regards,
Denis Krivosheev.

Bug#995128: dbus-user-session: Non-functional dbus-user-session installation

[Francois Marier]

Package: dbus-user-session
Version: 1.12.20-2
Severity: normal
X-Debbugs-Cc: s...@debian.org

I installed dbus-user-session but it doesn't look functional:

$ ls -lh $XDG_RUNTIME_DIR/bus
ls: cannot access '/run/user/1000/bus': No such file or directory

$ systemctl --user status dbus.service
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1

$ systemctl --user status dbus.socket
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1

I'm not too sure if I should be manually starting it from my desktop
environment (i3 + gnome-settings-daemon), but Simon McVittie suggested I
file a bug about this (see Bug #994961).

Francois

-- 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-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dbus-user-session depends on:
ii  dbus1.12.20-2
ii  libpam-systemd  247.9-2+b1
ii  systemd 247.9-2+b1

Versions of packages dbus-user-session recommends:
ii  systemd-sysv  247.9-2+b1

dbus-user-session suggests no packages.

-- no debconf information

-- 
https://fmarier.org/

Bug#995127: synaptic: 'New in repository' list not updated

[Roman Hornik]

Package: synaptic
Version: 0.90.2+b1
Severity: normal
X-Debbugs-Cc: roman.hor...@debian-linux.cz

Dear Maintainer,

The "New in Repository" list still contains the same items until the
/root/.synaptic/options file is manually deleted.


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

Kernel: Linux 5.13.0-trunk-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.17-2
ii  libapt-pkg6.02.3.9
ii  libc62.33-0experimental2
ii  libept1.6.0  1.2.1
ii  libgcc-s111.2.0-8
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.0-1+b1
ii  libgtk-3-0   3.24.30-3
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libstdc++6   11.2.0-8
ii  libvte-2.91-00.64.2-3
ii  libxapian30  1.4.18-3
ii  policykit-1  0.119-1

Versions of packages synaptic recommends:
pn  libgtk3-perl  
ii  xdg-utils 1.1.3-4.1

Versions of packages synaptic suggests:
ii  apt-xapian-index 0.52
ii  deborphan1.7.35
pn  dwww 
ii  menu 2.1.48
pn  software-properties-gtk  
pn  tasksel  

Bug#995123: cyrus-sasl2 FTBFS: sphinx: AttributeError: 'CyrusManualPageBuilder' object has no attribute 'settings'

[Dmitry Shachnev]

Hi Helmut and all!

On Sun, Sep 26, 2021 at 07:37:13PM +0200, Helmut Grohne wrote:
> I'm reporting this bug on behalf of Alexey Brodkin as the original
> reporter on irc.
>
> cyrus-sasl2 fails to build from source in unstable on amd64. A build
> ends as follows:
>
> [...skipping warnings which are not fatal...]
>
> | Exception occurred: File 
> "/usr/lib/python3/dist-packages/docutils/writers/manpage.py", line 171, in 
> __init__
> | self.settings = settings = document.settings
> | AttributeError: 'CyrusManualPageBuilder' object has no attribute 'settings'
> | The full traceback has been saved in /tmp/sphinx-err-3nha1qoj.log, if you 
> want to report the issue to the developers.
>
> [...]
>
> It built fine yesterday and today sphinx got uploaded to unstable. That
> seems like a very plausible reason, right? I've put Dmitry in the loop.

Yes, it is caused by a change in Sphinx.

CyrusManualPageTranslator inherits from Sphinx' ManualPageTranslator and
calls the super-class constructor as follows:

  BaseTranslator.__init__(self, builder, *args, **kwds)

However, starting with Sphinx 2.0 it should be called with document as the
first argument and builder as the second one [1]. The old way of calling it
raised a warning for some time and was completely removed in Sphinx 4.0.

The full traceback is:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 280, in 
build_main
app.build(args.force_all, filenames)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 337, in 
build
self.builder.build_update()
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 290, 
in build_update
self.build(['__all__'], to_build)
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 357, 
in build
self.write(docnames, list(updated_docnames), method)
  File 
"/cyrus-sasl2-2.1.27+dfsg/build-heimdal/docsrc/exts/sphinxlocal/builders/manpage.py",
 line 86, in write
docwriter.write(largetree, destination)
  File "/usr/lib/python3/dist-packages/docutils/writers/__init__.py", line 78, 
in write
self.translate()
  File 
"/cyrus-sasl2-2.1.27+dfsg/build-heimdal/docsrc/exts/sphinxlocal/writers/manpage.py",
 line 37, in translate
visitor = CyrusManualPageTranslator(self.builder, self.document)
  File 
"/cyrus-sasl2-2.1.27+dfsg/build-heimdal/docsrc/exts/sphinxlocal/writers/manpage.py",
 line 49, in __init__
BaseTranslator.__init__(self, builder, *args, **kwds)
  File "/usr/lib/python3/dist-packages/sphinx/writers/manpage.py", line 82, in 
__init__
super().__init__(document, builder)
  File "/usr/lib/python3/dist-packages/sphinx/util/docutils.py", line 460, in 
__init__
super().__init__(document)
  File "/usr/lib/python3/dist-packages/docutils/writers/manpage.py", line 171, 
in __init__
self.settings = settings = document.settings
AttributeError: 'CyrusManualPageBuilder' object has no attribute 'settings'

cyrus-sasl2's Sphinx extension passes builder in place of document, which
causes this error.

[1]: https://github.com/sphinx-doc/sphinx/pull/5828

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#995126: slade: See WADs thrice

[Nicolas Patrois]

Package: slade
Version: 3.1.12
Severity: normal

Dear Maintainer,

I see WADs thrice in the WAD folder.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

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

Versions of packages slade depends on:
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.32-4
ii  libcurl3-gnutls 7.74.0-1.3+b1
ii  libflac81.3.3-2
ii  libfluidsynth1  1.1.11-4
ii  libfreeimage3   3.18.0+ds2-6
ii  libftgl22.4.0-2.1
ii  libglu1-mesa9.0.1-1
ii  libgstreamer-plugins-base1.0-0  1.18.5-dmo1
ii  libgstreamer1.0-0   1.18.5-1
ii  libgtk-3-0  3.24.30-3
ii  libjavascriptcoregtk-4.0-18 2.34.0-1
ii  liblzma55.2.5-2
ii  libnotify4  0.7.9-3
ii  libogg0 1.3.4-0.1
ii  libopenal1  1:1.19.1-2
ii  libsm6  2:1.2.3-1
ii  libudev1247.9-3
ii  libvorbis0a 1.3.7-1
ii  libvorbisenc2   1.3.7-1
ii  libvorbisfile3  1.3.7-1
ii  libwebkit2gtk-4.0-372.34.0-1
ii  zlib1g  1:1.2.11.dfsg-2

slade recommends no packages.

slade suggests no packages.

Bug#995115: /usr/bin/ruby: symbol lookup error: /lib/x86_64-linux-gnu/libruby-2.7.so.2.7: undefined symbol: rb_st_numhash

[David Kalnischkies]

Control: reassign -1 apt-listbugs 0.1.35

On Sun, Sep 26, 2021 at 03:27:19PM +0200, xiscu wrote:
> Justification: renders package unusable

Which package is unusable?


> [...]
> 274 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/745 MB of archives.
> After this operation, 313 MB of additional disk space will be used.
> Do you want to continue? [Y/n]
> /usr/bin/ruby: symbol lookup error: /lib/x86_64-linux-gnu/libruby-2.7.so.2.7: 
> undefined symbol: rb_st_numhash
> E: Sub-process /usr/bin/apt-listbugs apt returned an error code (127)
> E: Failure running script /usr/bin/apt-listbugs apt

The script exits unsuccessfully and as such the action is stopped.
apt hence works as intended, it is "just" not intended that the scripts
called do crash in such ways, but that is the bug of those scripts or
their interpreters not of apt itself.


> trying to deinstall apt-listbugs results on the same problem.
> trying to upagrade apt (listbugs) first, results in:
> 
> bin# apt-get install -t sid apt

If you want to upgrade apt-listbugs first you will have to use that
package name, not apt, apt doesn't contain apt-listbugs.

That said, there is no new version of apt-listbugs at the moment, so
there is nothing to upgrade to. Seems like a ruby upgrade broke it, but
I don't know if it is intended breakage (= to be fixed in apt-listbugs)
or unintended (= somewhere in ruby) or something in between. That is for
someone to investigate who has an idea about ruby, hence reassigning
down the chain.

You may want to add which versions of ruby packages and apt-listbugs are
involved.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#994961: glib2.0: gnome-keyring unable to unlock login keyring on some systems since GLib 2.70.0-1

[Simon McVittie]

On Sun, 26 Sep 2021 at 10:57:53 -0700, Francois Marier wrote:
> $ ls -lh $XDG_RUNTIME_DIR/bus
> ls: cannot access '/run/user/1000/bus': No such file or directory

Looks like you have a non-functional installation of dbus-user-session
(which would put you in the same situation as people without that package
installed), but that should probably be a separate bug report against
dbus-user-session rather than being in-scope for this one.

smcv

Bug#995124: printer-driver-cups-pdf: error_log say 'E...[cups-driverd] Bad driver information file...' with indexbraille-*.defs files

[yg2709]

Package: printer-driver-cups-pdf
Version: 3.0.1-11
Severity: normal
X-Debbugs-Cc: yg2...@hotmail.com

Dear Maintainer,

After the last update (3.0.1-11), in /var/log/error_log appears:

E [26/Sep/2021:11:36:19 +0200] [cups-driverd] Bad driver information file 
\"/usr/share/cups/drv/indexbraille-filter.defs\"!
E [26/Sep/2021:11:36:19 +0200] [cups-driverd] Bad driver information file 
\"/usr/share/cups/drv/indexbraille-media.defs\"!

Why is bad? Since I don't know, I look at the following.

(1) All ".defs" files of cups are in /usr/share/cups/ppdc/, except those two:

/usr/share/cups/drv/indexbraille-filter.defs
/usr/share/cups/drv/indexbraille-media.defs

/usr/share/cups/ppdc/braille.defs
/usr/share/cups/ppdc/font.defs
/usr/share/cups/ppdc/imagemagick.defs
/usr/share/cups/ppdc/index.defs
/usr/share/cups/ppdc/liblouis1.defs
/usr/share/cups/ppdc/liblouis2.defs
/usr/share/cups/ppdc/liblouis3.defs
/usr/share/cups/ppdc/liblouis4.defs
/usr/share/cups/ppdc/liblouis.defs
/usr/share/cups/ppdc/media-braille.defs
/usr/share/cups/ppdc/media.defs
/usr/share/cups/ppdc/raster.defs

(2) All "#include" lines show the file between <>, except for 
/usr/share/cups/drv/indexbraille.drv which is between "".

/usr/share/cups/drv/brlaser.drv:#include 
/usr/share/cups/drv/brlaser.drv:#include 
. . .
/usr/share/cups/drv/indexbraille.drv:   #include "indexbraille-filter.defs"
/usr/share/cups/drv/indexbraille.drv:   #include "indexbraille-media.defs"
. . .
/usr/share/cups/drv/sample.drv:#include 
/usr/share/cups/drv/sample.drv:#include 
/usr/share/cups/drv/sample.drv:#include 

>From the above two points, I do the following to test:

(A) Move those .defs files from drv to ppdc with this command:

mv -v /usr/share/cups/drv/indexbraille*.defs /usr/share/cups/ppdc/
renamed '/usr/share/cups/drv/indexbraille-filter.defs' -> 
'/usr/share/cups/ppdc/indexbraille-filter.defs'
renamed '/usr/share/cups/drv/indexbraille-media.defs' -> 
'/usr/share/cups/ppdc/indexbraille-media.defs'

(B) Modify indexbraille.drv to change "" by <> with this command:

sed -i \
  -e '/#include/s/"//' \
  /usr/share/cups/drv/indexbraille.drv

grep include /usr/share/cups/drv/indexbraille.drv
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

After reset, no message on error_log. Seems to work!

Do you consider what I have done to be correct?

If this is the solution, perhaps this bug should be reassigned to package 
printer-driver-indexbraille, to which these two files belong:

$ sudo apt-file search indexbraille-filter.defs
printer-driver-indexbraille: /usr/share/cups/drv/indexbraille-filter.defs
$ sudo apt-file search indexbraille-media.defs
printer-driver-indexbraille: /usr/share/cups/drv/indexbraille-media.defs

Thanks in advance.


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

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

Versions of packages printer-driver-cups-pdf depends on:
ii  cups2.3.3op2-7
ii  cups-client 2.3.3op2-7
hi  ghostscript 9.53.3~dfsg-7+b1
ii  libc6   2.32-4
ii  libcups22.3.3op2-7
ii  libpaper-utils  1.1.28+b1

printer-driver-cups-pdf recommends no packages.

Versions of packages printer-driver-cups-pdf suggests:
ii  system-config-printer  1.5.14-1

-- Configuration Files:
/etc/cups/cups-pdf.conf changed:
Out ${HOME}/PDF
Label 2
Grp lpadmin
GSTmp /tmp
DecodeHexStrings 1


-- debconf-show failed

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Thorsten Glaser]

On Sun, 26 Sep 2021, Jesse Smith wrote:

> I've tried this again on my own machine and cannot reproduce the

Does the attached file help? It’s my /etc/{init.d,rc*}/ stripped to
just reproduce the files up to the end of the LSB headers.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!


etc-stripped.tgz
Description: application/gtar-compressed

Bug#995018: jupyterlab-server 2.4.0-1 broken by jupyter-server 1.10.2-1

[Julien Puydt]

Hi,

I just tried to rebuild jupyterlab-server in my unstable sbuild, and
could check that it used the jupyter-server you complain about, and
passes the tests.

I suspect the problem is that the latest version of python3-anyio
doesn't migrate to testing (blocked by pytest).

Cheers,

J.Puydt

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Jesse Smith]

On 2021-09-26 2:37 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> did last time. This time please run"
>>
>> # insserv -v -s
>>
>> This should set avahi-daemon to K01. Then run
> Erm, well, it doesn’t. Apparently, the presence of -s prevents this.

You're right, that's my mistake. I forgot the "-s" flag will show what
insserv plans to do, but not actually update the symlinks.


>> # insserv -v -s -n
>>
>> This should tell us whether insserv wants to toggle avahi-daemon back to
>> K02, but without actually making any changes. And hopefully it will give
>> a clue as to why this is happening.Thank you.
> Maybe the attached will still suffice as clue?
>

Based on the output you shared it does indeed look like that whenever
avahi-daemon is set to K02, insserv wants to switch it back to K01. But
then when insserv is run again, without the -s or -n flags indicating a
dry run, it tries to switch things back from K01 to K02. This is indeed
strange.

I've tried this again on my own machine and cannot reproduce the
behaviour. I've tried both the latest version of insserv (1.23.0) and
the version which shipped with Debian 10 (1.18.0). I did notice having
other dependency trouble when I tested with insserv 1.21.0 which I
believe is the version being used when the bug is triggered?

Thorsten, I wonder if you could give the latest version of insserv a try
(version 1.23.0) which can be downloaded here:
https://download.savannah.nongnu.org/releases/sysvinit/insserv-1.23.0.tar.xz

Perhaps this is related to a previous dependency issue we already fixed
in 1.21.0. Or, if you're still experiencing the problem with insserv
1.23.0 then we've got a bigger mystery.

- Jesse

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Thorsten Glaser]

On Sun, 26 Sep 2021, Jesse Smith wrote:

> behaviour. I've tried both the latest version of insserv (1.23.0) and
> the version which shipped with Debian 10 (1.18.0). I did notice having

This is Debian 11 so 1.21.0-1.1 (including Debian patches).

> Thorsten, I wonder if you could give the latest version of insserv a try

No, this is a remote machine where I prefer to not risk bootability.

Sorry,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#986709: rsnapshot is stable, not dead

[John Brooks]

On Fri, 28 May 2021 15:39:28 -0500 Michael Lustfield 
 wrote:

> On Fri, 28 May 2021 19:56:47 +0100
> David Cantrell  wrote:
>
> > [...]
> > So what, exactly, is unmaintained about it? Looks to me like it has
> > exactly the amount of maintenance that is required for mature software.
>
> I'm not going to strawman my justifications; it's not terribly 
relevant anyway.
> Absolutely anyone is free to disagree with me and continue 
maintenance of the

> package. If needed, I'll even sponsor the upload.
>
> https://mentors.debian.net/intro-maintainers (read 1-2, start at 3)
>

>

Michael,

I think it is important that you clarify or modify your stance given 
that upon further inspection by others here, there are no serious 
outstanding functional or security issues with the program. Even 
self-asserted justification (i.e. "I just don't want to maintain it 
anymore, so find someone else") is acceptable; that is your right as a 
volunteer. But it would have been prudent to either defend your initial 
assessment of the program as no longer suitable for inclusion, or 
acknowledge that you may have been incorrect. Otherwise the issue is 
just stuck in limbo.


Additionally, in response to this very bug, a new upstream release has 
now been issued. In light of this, do you plan to upload the new version 
and continue to fill the role of maintainer for the rsnapshot Debian 
package, or is another maintainer still needed going forward?


I don't seek to impose anything upon you, I just want to see that this 
doesn't fall through the cracks.


Thanks
John Brooks

Bug#994961: glib2.0: gnome-keyring unable to unlock login keyring on some systems since GLib 2.70.0-1

[Francois Marier]

On 2021-09-24 at 02:28:05, Simon McVittie (s...@debian.org) wrote:
> > I do have the dbus-user-session package installed.
> 
> I'm surprised by this. It's clearly still picking up XDG_RUNTIME_DIR
> from the environment, so I would have expected it to be able to connect
> to $XDG_RUNTIME_DIR/bus (arguably that's a bug, in that it should not be
> trusting the environment at all when run with capabilities, but it's
> necessary as long as gnome-keyring-daemon is setcap).
> 
> Do you have a socket at $XDG_RUNTIME_DIR/bus owned by your uid?

It doesn't look like it:

$ ls -lh $XDG_RUNTIME_DIR/bus
ls: cannot access '/run/user/1000/bus': No such file or directory

> What is the status of the session bus? (`systemctl --user status dbus.service`
> and `systemctl --user status dbus.socket`)

$ systemctl --user status dbus.service
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl --user status dbus.socket
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1

I'll give gnome-keyring 40.0-3 a go once it makes it to unstable.

Francois

-- 
https://fmarier.org/

Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye

[Chuck Zmudzinski]

Added tag upstream. Explanation is in discussion at
related bug #991967 here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#169

and here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#174

Briefly, since we are currently  shipping a fork of Xen-4.14
on our unstable, testing, and stable versions of the hypervisor
to better support arm devices but there is an annoying
bug also in x86 (amd64) in these versions, IMO we should

1) Notify upstream of the fork we are doing and
2) Notify our users, especially on the stable branch,
that our version of Xen is actually  a fork of Xen-4.14.

I know this can be discovered by reading the changelog,
but to find it one must go back to the unstable version
that was released back in December of 2020 to find
where the fork started. Not many people (including me)
would look there to try to find such a significant change
to the package, especially on stable where ordinarily only
vanilla security patches from upstream are in the changelog.
So, as a courtesy to our users, I think the visibility of
this change needs to be elevated to the status of at least
a README.Debian file, if not an actual notification
to the user by dpkg when installing. Of course
the changelog should also note explicitly that this is
a fork of Xen 4.14 in all the released versions that
have patches from Xen upstream 4.16. Perhaps there is
a way to also indicate this in the version name and number
of the packages, but I do not know if there are conventions
or policies to handle a version change that is really the start
of a fork. If so, we should follow them.

Bug#994594: ITP: time-decode -- timestamp decoder and converter

[Jan Gru]

Dear Samuel,
dear pkg-security-team,

Samuel Henrique  writes:
>
> I can sponsor for you, just let me know when the package is ready for a
> review (or if you need help with anything) :)
>
> Thank you
>

Thank you for your offer to sponsor `time-decode`, Samuel. I worked on
the package and want to ask for a review. The sources for the packaging
process can be found here:

https://salsa.debian.org/jgru/time-decode

`time-decode`' can be built successfully by running the commands listed
in [0]. Furthermore, I created three autopackage-tests, which check the
functionality of the resulting package. Those can be run with the
command listed in [1].

The package seems to be lintian-clean, except for some warnings about
NMU-version numbering and a not forwarded manpage.

I would be very glad, if you or another team member could conduct a
thourough review and provide some feedback, so that the package might
find its way in unstable's or testing's package sources eventually in
the future. If there are any issues, please let me know.

Thank you already in advance for your help on this!

Best regards
 Jan

--
[0] `git clone https://salsa.debian.org/jgru/time-decode.git; cd
time-decode; gbp buildpackage --git-debian-branch=debian/master
--git-ignore-new --git-upstream-tree="upstream";`

[1] Assuming your chroot's alias is UNRELEASED: `autopkgtest --debug --
schroot UNRELEASED`

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Thorsten Glaser]

On Sun, 26 Sep 2021, Jesse Smith wrote:

> did last time. This time please run"
> 
> # insserv -v -s
> 
> This should set avahi-daemon to K01. Then run

Erm, well, it doesn’t. Apparently, the presence of -s prevents this.

> # insserv -v -s -n
> 
> This should tell us whether insserv wants to toggle avahi-daemon back to
> K02, but without actually making any changes. And hopefully it will give
> a clue as to why this is happening.Thank you.

Maybe the attached will still suffice as clue?

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
Script started on 2021-09-26 19:34:28+02:00 [TERM="screen" TTY="/dev/pts/0" 
COLUMNS="113" LINES="34"]
tglase@tglase:~ $ sudo su -
[sudo] password for tglase: 
_,met$gg.    
   
 ,g$$$P.     
   
   ,g$$P""   """Y$$.".   
   
  ,$$P'  `$$$.   
   
',$$P   ,ggs. `$$b:  
   
`d$$' ,$P"'   .$$$   
,#.
 $$P  d$' ,$$P  ##:  :##
:###:   
 $$:  $$.   -,d$$'  ##'  `## 
`#'
 $$;  Y$b._   _,d$P'    __  ## __ ##  __  _ 
__  _   
 Y$$.`.`"YP"' ,:##  ,##.  ##.#. :### 
,##. ###.: 
 `$$b  "-.__ ,##' `###  ##:  :##  ###' `###  ##' #:  
 `## `###' `##:
  `Y$$b  ##`##  ####  ##'   `##  ##
___,##  ##:   `##
   `Y$$. ## ##  ###:  ## ##  ##  
.###  ##'##
 `$$b.   ## ##  ##'   ## ##  ##  ##' 
 `##  ## ##
   `Y$$b.##.   ,##  ####,##  ##  ##  
  ##  ## ##
 `"Y$b._ :#:._,###  ##:__,##  ##:__,##' ,##. 
##.__:##. ## ##
 `   `: ###  ##'  `##'   
`#"## ## ##

OS version: Debian GNU/Linux 11 (bullseye)
Linux Version 5.10.0-6-amd64, Compiled #1 SMP Debian 5.10.28-1 
(2021-04-09)
Four 3.06GHz Intel i7 Nehalem EP Processors, 24GB RAM, 25k 
Bogomips
Uptime 139 days 11 hours 49 minutes
tglase.lan.tarent.de

root@tglase:~ # cd /etc
root@tglase:/etc # git status
On branch master
nothing to commit, working tree clean
root@tglase:/etc # insserv -v -s
K:11:0 6:udev
K:09:0 6:cryptdisks
K:10:0 6:cryptdisks-early
K:01:0 1 6:openvpn
K:07:0 6:networking
K:06:0 6:umountnfs.sh
K:05:0 6:sendsigs
K:08:0 6:umountfs
K:04:0 1 6:inetutils-syslogd
K:01:0 1 6:kdm
K:12:0 6:umountroot
K:13:0 6:mdadm-waitidle
K:14:0:halt
K:14:6:reboot
K:01:0 1 6:boinc-client
K:02:0 6:early-rng-init-tools
K:05:0 6:hwclock.sh
K:01:0 6:urandom
K:01:0 1 6:edac
K:01:0 1 6:xrdp
K:01:0 1 6:schroot
K:01:0 6:brightness
K:01:0 1 6:irqbalance
K:02:0 1 6:postgresql
K:01:0 1 6:lvm2-lvmpolld
K:01:0 1 6:tarent-server
K:02:0 1 6:libvirtd
K:03:0 1 6:virtlogd
K:01:0 1 6:apache2
K:01:0 1 6:unscd
K:01:0 1 6:atd
K:01:0 1 6:cups-browsed
K:01:0 1 6:avahi-daemon
K:01:0 1 6:postfix
K:01:0 1 6:openntpd
K:01:0 1 6:mdadm
K:01:0 1 6:alsa-utils
K:01:0 1 2 3 4 5 6:apache-htcacheclean
K:01:0 1 6:libvirt-guests
K:01:0 1 6:uml-utilities
K:01:0 1 6:linuxlogo
K:01:0 1 6:openbsd-inetd
K:01:0 1 6:gpm
K:01:0 1 6:ntp
K:01:1:smartmontools
K:01:1:cups
K:01:1:acpi-support
K:01:0 1 6:stunnel4
K:01:0 1 6:rng-tools-debian
S:02:S:udev
S:10:S:cryptdisks
S:08:S:cryptdisks-early
S:03:2 3 4 5:openvpn
S:15:S:networking
S:16:S:mountnfs.sh
S:17:S:mountnfs-bootclean.sh
S:12:S:mountall.sh
S:13:S:mountall-bootclean.sh
S:02:2 3 4 5:inetutils-syslogd
S:06:2 3 4 5:kdm
S:07:S:checkroot.sh
S:09:S:lvm2
S:07:2 3 4 5:boinc-client
S:18:S:x11-common
S:05:2 3 4 5:dbus
S:14:S:early-rng-init-tools
S:06:S:hwclock.sh
S:14:S:urandom
S:02:2 3 4 5:edac
S:05:2 3 4 5:xrdp
S:05:2 3 4 5:schroot

Bug#995123: cyrus-sasl2 FTBFS: sphinx: AttributeError: 'CyrusManualPageBuilder' object has no attribute 'settings'

[Helmut Grohne]

Source: cyrus-sasl2
Version: 2.1.27+dfsg-2.1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Dmitry Shachnev 

I'm reporting this bug on behalf of Alexey Brodkin as the original
reporter on irc.

cyrus-sasl2 fails to build from source in unstable on amd64. A build
ends as follows:

| /usr/bin/sphinx-build -d docsrc/.doctrees -n -q -b cyrman ./docsrc ./man
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_auxprop_add_plugin.rst:22:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expected identifier in nested name. [error at 49]
|   int sasl_auxprop_add_plugin(const char *plugname,
|   -^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_auxprop_add_plugin.rst:22:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 35]
|   sasl_auxprop_plug_init_t *cplugfunc);
|   ---^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_canon_user_t.rst:23:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expected identifier in nested name. [error at 40]
|   int sasl_canon_user_t(sasl_conn_t *conn,
|   ^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_canon_user_t.rst:23:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 13]
|   void *context,
|   -^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_canon_user_t.rst:23:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 16]
|   const char *user,
|   ^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_canon_user_t.rst:23:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 13]
|   unsigned ulen,
|   -^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_canon_user_t.rst:23:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 14]
|   unsigned flags,
|   --^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_canon_user_t.rst:23:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 22]
|   const char *user_realm,
|   --^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_canon_user_t.rst:23:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 14]
|   char *out_user,
|   --^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_canon_user_t.rst:23:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 17]
|   unsigned out_umax,
|   -^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_canon_user_t.rst:23:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 18]
|   unsigned *out_ulen)
|   --^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_canonuser_add_plugin.rst:22:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expected identifier in nested name. [error at 51]
|   int sasl_canonuser_add_plugin(const char *plugname,
|   ---^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_canonuser_add_plugin.rst:22:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 37]
|   sasl_canonuser_plug_init_t *cplugfunc);
|   -^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_chalprompt_t.rst:24:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expected identifier in nested name. [error at 36]
|   int sasl_chalprompt_t(void *context,
|   ^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_chalprompt_t.rst:24:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 6]
|   int id,
|   --^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_chalprompt_t.rst:24:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 21]
|   const char *challenge,
|   -^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_chalprompt_t.rst:24:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in parameters. [error at 18]
|   const char *prompt,
|   --^
| 
/<>/build-heimdal/docsrc/sasl/reference/manpages/library/sasl_chalprompt_t.rst:24:
 WARNING: Error in declarator or parameters
| Invalid C declaration: Expecting "(" in 

Bug#986778: ITP: gcc-sh-elf -- GNU C compiler for embedded SuperH devices

[John Scott]

On Sun, 2021-09-26 at 18:55 +0200, John Paul Adrian Glaubitz wrote:
> I'm willing to sponsor this as I am Debian's primary maintainer of the sh4 
> port.
Thanks for your consideration! FYI, I just pushed a small fix for the
Binutils autopkgtest to both Git and mentors.debian.net. I would
appreciate any critique you have about the packaging. I'm on #debian-
ports (my nick is pert) if you'd prefer discussion there as well.


signature.asc
Description: This is a digitally signed message part

Bug#994971: OpenCL not working with latest Nvidia driver

[Klaus Ethgen]

Hi,

Am So den 26. Sep 2021 um 17:58 schrieb Andreas Beckmann:
> Thanks. You had modifications in nvidia-modprobe.conf, didn't try that
> before.

Ehem, I don't think so... Never touched that file by hand.

But I see, it was touched several times by an upgrade.

It started 2015-10-16 and was changed by updates 2015-10-22, 2016-07-30,
2016-09-30, 2018-03-10, 2021-08-03 and finally removed 2021-09-25.

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#988696: LXDE: Please include a user-friendly network management tool

[Amy Kos]

Hi,

if you want to prefer network-manager, better do it in lxde metapackage
instead of task-lxde-desktop which depends on the lxde metapackage.
https://salsa.debian.org/lxde-team/lxde-metapackages/-/blob/debian/debian/control
For instance change line 44 from
 connman-gtk | network-manager-gnome | wicd, deluge | transmission-gtk,
to
 network-manager-gnome | connman-gtk | wicd, deluge | transmission-gtk,

If you want to keep connman it looks like there is a status icon option:
https://github.com/jgke/connman-gtk
> -Duse_status_icon=[true,false]
> Enable or disable the status icon. Future GTK versions might remove the 
> support for status icons, but as of 3.18 the support is still there, just 
> deprecated.

By the way, there is a similar feature request for Lxqt too:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975524

And as for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994875 I'm afraid 
everything worked as expected:
> as far as I remember connman ignores /etc/network/interfaces by design.
> Lxde metapackage in buster recommends wicd which is not available in bullseye 
> due to the deprecation of python 2.
> Therefore lxde metapackage in bullseye recommends connman-gtk (connman).

Cheers,
Amy

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Jesse Smith]

On 2021-09-26 1:54 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> Something that might be useful here is seeing the output from "insserv
>> -v -s -n". This will show in what order insserv intends to assign each
>> service in each runlevel. No changes will be made to the system when
>> insserv is run with the "-n" flag.
> Attached.
>
>> It might also be useful to have the LSB header from the avahi-daemon
>> service file in /etc/init.d/
> root@tglase:/etc # head -15 /etc/init.d/avahi-daemon  
> #!/bin/sh
> ### BEGIN INIT INFO
> # Provides:  avahi avahi-daemon
> # Required-Start:$remote_fs dbus
> # Required-Stop: $remote_fs dbus
> # Should-Start:  $syslog
> # Should-Stop:   $syslog
> # Default-Start: 2 3 4 5
> # Default-Stop:  0 1 6
> # Short-Description: Avahi mDNS/DNS-SD Daemon
> # Description:   Zeroconf daemon for configuring your network 
> #automatically
> ### END INIT INFO
>
> PATH=/sbin:/bin:/usr/sbin:/usr/bin
>

Thanks, Thorseten, this is very helpful. So if I understand correctly if
you do the "apt upgrade" process now (or a regular insserv call)
avahi-daemon will get set to K01. Which looks right to me. But then if
you run insserv a second time it toggles back to K02?

Could you try this for me? Send me the same style of recored output you
did last time. This time please run"

# insserv -v -s

This should set avahi-daemon to K01. Then run

# insserv -v -s -n

This should tell us whether insserv wants to toggle avahi-daemon back to
K02, but without actually making any changes. And hopefully it will give
a clue as to why this is happening.Thank you.

- Jesse

Bug#994971: OpenCL not working with latest Nvidia driver

[Andreas Beckmann]

Control: severity -1 serious

On 26/09/2021 18.07, Klaus Ethgen wrote:

available somewhere in /var/log/apt/term.log*, it might give some hints what
happened.


Here it is.


Thanks. You had modifications in nvidia-modprobe.conf, didn't try that 
before. And dpkg messed it up. I could reproduce the disappearance of 
the file. Will try to reproduce with a conffile outside nvidia stuff...



By the way, make it sense to include all involved persons in reply?
Doesn't the bugtracker send notification too?


Only the maintainer gets notifications by default, everyone else has to 
subscribe manually. So let's keep the Cc:s.


Andreas

Bug#994873: libdrm-dev: mssing dependency on valgrind

[Andre Heider]

This is not multiarch compatible, libdrm-dev can't be coinstalled with 
libdrm-dev:i386 now.

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Thorsten Glaser]

Dixi quod…

> On Sun, 26 Sep 2021, Jesse Smith wrote:
> 
> > Something that might be useful here is seeing the output from "insserv
> > -v -s -n". This will show in what order insserv intends to assign each
> > service in each runlevel. No changes will be made to the system when
> > insserv is run with the "-n" flag.
> 
> Attached.

… erm, welp, now.

Mraw,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
Script started on 2021-09-26 18:53:00+02:00 [TERM="screen" TTY="/dev/pts/0" 
COLUMNS="113" LINES="34"]
root@tglase:/etc # insserv -v -s -n
insserv: Loading /etc/insserv.conf
insserv: Loading /etc/insserv.conf.d/postfix
insserv: Loading /etc/insserv.conf.d/kdm
insserv: Loading K01openvpn
insserv: Loading K10cryptdisks-early
insserv: Loading K13mdadm-waitidle
insserv: Loading K01boinc-client
insserv: Loading K02early-rng-init-tools
insserv: Loading K01edac
insserv: Loading K01xrdp
insserv: Loading K01schroot
insserv: Loading K05sendsigs
insserv: Loading K01brightness
insserv: Loading K01irqbalance
insserv: Loading K02postgresql
insserv: Loading K05hwclock.sh
insserv: Loading K01lvm2-lvmpolld
insserv: Loading K14halt
insserv: Loading K11udev
insserv: Loading K01tarent-server
insserv: Loading K02libvirtd
insserv: Loading K01apache2
insserv: Loading K01unscd
insserv: Loading K01atd
insserv: Loading K12umountroot
insserv: Loading K01urandom
insserv: Loading K01cups-browsed
insserv: Loading K02avahi-daemon
insserv: Loading K01postfix
insserv: Loading K01openntpd
insserv: Loading K08umountfs
insserv: Loading K01mdadm
insserv: Loading K01alsa-utils
insserv: Loading K01apache-htcacheclean
insserv: Loading K09cryptdisks
insserv: Loading K01libvirt-guests
insserv: Loading K01uml-utilities
insserv: Loading K06umountnfs.sh
insserv: Loading K01linuxlogo
insserv: Loading K04inetutils-syslogd
insserv: Loading K07networking
insserv: Loading K03virtlogd
insserv: Loading K01kdm
insserv: Loading K01openbsd-inetd
insserv: Loading K01gpm
insserv: Loading K01ntp
insserv: Loading K01openvpn
insserv: Loading K01smartmontools
insserv: Loading K01cups
insserv: Loading K01boinc-client
insserv: Loading K01edac
insserv: Loading K01xrdp
insserv: Loading K01schroot
insserv: Loading K01irqbalance
insserv: Loading K02postgresql
insserv: Loading K01acpi-support
insserv: Loading K01lvm2-lvmpolld
insserv: Loading K01tarent-server
insserv: Loading K02libvirtd
insserv: Loading K01apache2
insserv: Loading K01unscd
insserv: Loading S01killprocs
insserv: Loading K01atd
insserv: Loading K01cups-browsed
insserv: Loading K02avahi-daemon
insserv: Loading K01postfix
insserv: Loading K01openntpd
insserv: Loading K01mdadm
insserv: Loading K01alsa-utils
insserv: Loading K01apache-htcacheclean
insserv: Loading K01libvirt-guests
insserv: Loading K01uml-utilities
insserv: Loading S07bootlogs
insserv: Loading K01linuxlogo
insserv: Loading K04inetutils-syslogd
insserv: Loading S02single
insserv: Loading K03virtlogd
insserv: Loading K01kdm
insserv: Loading K01openbsd-inetd
insserv: Loading K01gpm
insserv: Loading K01ntp
insserv: Loading S05ntp
insserv: Loading S05openntpd
insserv: Loading S06avahi-daemon
insserv: Loading S02unscd
insserv: Loading S05dbus
insserv: Loading S02sudo
insserv: Loading S05xrdp
insserv: Loading S06kdm
insserv: Loading S05gpm
insserv: Loading S05mdadm
insserv: Loading S05anacron
insserv: Loading S08rc.local
insserv: Loading S02inetutils-syslogd
insserv: Loading S05schroot
insserv: Loading S05ssh
insserv: Loading S05virtlogd
insserv: Loading S05irqbalance
insserv: Loading S07libvirt-guests
insserv: Loading S02lvm2-lvmpolld
insserv: Loading S05smartmontools
insserv: Loading S05openbsd-inetd
insserv: Loading S07cups-browsed
insserv: Loading S03openvpn
insserv: Loading S02linuxlogo
insserv: Loading S05rsync
insserv: Loading S05postgresql
insserv: Loading S02sysfsutils
insserv: Loading S05rmnologin
insserv: Loading S02edac
insserv: Loading S05atd
insserv: Loading S04apache2
insserv: Loading K01apache-htcacheclean
insserv: Loading S02uml-utilities
insserv: Loading S08stop-bootlogd
insserv: Loading S02binfmt-support
insserv: Loading S06postfix
insserv: Loading S05cron
insserv: Loading S05acpi-support
insserv: Loading S06libvirtd
insserv: Loading S07bootlogs
insserv: Loading S05acpid
insserv: Loading S07cups
insserv: Loading S07boinc-client
insserv: Loading S01console-setup.sh
insserv: Loading S02tarent-server
insserv: Loading S05ntp
insserv: Loading S05openntpd
insserv: Loading 

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Thorsten Glaser]

On Sun, 26 Sep 2021, Jesse Smith wrote:

> Something that might be useful here is seeing the output from "insserv
> -v -s -n". This will show in what order insserv intends to assign each
> service in each runlevel. No changes will be made to the system when
> insserv is run with the "-n" flag.

Attached.

> It might also be useful to have the LSB header from the avahi-daemon
> service file in /etc/init.d/

root@tglase:/etc # head -15 /etc/init.d/avahi-daemon  
#!/bin/sh
### BEGIN INIT INFO
# Provides:  avahi avahi-daemon
# Required-Start:$remote_fs dbus
# Required-Stop: $remote_fs dbus
# Should-Start:  $syslog
# Should-Stop:   $syslog
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: Avahi mDNS/DNS-SD Daemon
# Description:   Zeroconf daemon for configuring your network 
#automatically
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin

,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#986778: ITP: gcc-sh-elf -- GNU C compiler for embedded SuperH devices

[John Paul Adrian Glaubitz]

Hi John!

> * Package name: gcc-sh-elf
>   Upstream Author : GNU Project
> * URL : https://gcc.gnu.org
> * License : GPL
>   Programming Lang: C, C++
>   Description : GNU C compiler for embedded SuperH devices
> 
> This native package will provide a build of gcc as a cross-compiler for
> bare-metal SuperH devices as well as a build of Newlib to serve as the
> ISO C standard library.

I'm willing to sponsor this as I am Debian's primary maintainer of the sh4 port.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#991967: Simply ACPI powerdown/reset issue?

[Chuck Zmudzinski]

On 9/26/2021 8:46 AM, Chuck Zmudzinski wrote:

On 9/25/2021 11:27 PM, Elliott Mitchell wrote:


Unfortunately I was too quick at installing the rebuilt 4.14.3-1 and I
missed trying the vanilla Debian 4.14.2+25-gb6a8c4f72d-2 with
Linux 4.19.181-1.  I believe this combination would have hung during
reboot.




In light of what I discovered while investigating the cause of
bug #994899, I would tend to think calling
Debian 4.14.2+25-gb6a8c4f72d-2 "vanilla" an interesting
choice of words. To me, vanilla connotes boring,
uninteresting. But that version of Debian Xen, and
also the current version in the stable distribution,
bullseye, are not boring or uninteresting as I have
studied these versions and concluded they actually
are now a fork of upstream Xen's 4.14 version, since
they contain patches from upstream Xen's 4.16 unstable
branch to better support the Raspberry Pi 4, as noted
in the changelogs of those versions.

So I am adding the tag upstream,


Actually, I will add the upstream tag to the bug I reported in
Xen, #994899, since we are talking about upstream Xen, not
upstream Linux.

Bug#991967: Simply ACPI powerdown/reset issue?

[Chuck Zmudzinski]

On 9/25/2021 11:27 PM, Elliott Mitchell wrote:


Unfortunately I was too quick at installing the rebuilt 4.14.3-1 and I
missed trying the vanilla Debian 4.14.2+25-gb6a8c4f72d-2 with
Linux 4.19.181-1.  I believe this combination would have hung during
reboot.




In light of what I discovered while investigating the cause of
bug #994899, I would tend to think calling
Debian 4.14.2+25-gb6a8c4f72d-2 "vanilla" an interesting
choice of words. To me, vanilla connotes boring,
uninteresting. But that version of Debian Xen, and
also the current version in the stable distribution,
bullseye, are not boring or uninteresting as I have
studied these versions and concluded they actually
are now a fork of upstream Xen's 4.14 version, since
they contain patches from upstream Xen's 4.16 unstable
branch to better support the Raspberry Pi 4, as noted
in the changelogs of those versions.

So I am adding the tag upstream, and I suggest that
the Debian Xen Team notify upstream Xen that we
are planning a fork of Xen to better support popular
arm devices and we are already shipping a testing
version of it in our current bullseye release. We could
tell upstream we are willing to stop this fork if they
could assist us with backporting the reworking of the
xen/arm/acpi and xen/x86/acpi code that is in upstream
Xen 4.16 unstable to xen 4.14. We can tell
them if they are interested in what we are doing, they
can take a look at the work we are doing on our
public development servers (salsa).

For our own users, especially in the stable version,
we should make a note of this fact in a README.Debian
file and place it in an appropriate place of the binary
packages. We should also note that there are encouraging
results with this version for improved support on arm,
but some tests indicate an annoying bug causing
problems shutting down Domain 0 appear to have
surfaced on x86 (amd64). For details, see bugs #991967
and #994899 on the Debian Bug Tracking System.

I think this is the BEST way to truly proceed in accordance
with the Debian Social Policy of courtesy and cooperation
with the free software projects that are available to the
public in our main repositories, and to properly inform
our users what we are doing in our current Xen packages
for unstable, testing, and stable.

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Jesse Smith]

On 2021-09-26 1:12 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Mark Hindley wrote:
>
>> Thorsten's original report[1] suggests it happens on every upgrade.
Not only every upgrade, but if I'm reading the report correctly it looks
like insserv is toggling between K01 and K02 with every time it is run,
even if no "apt upgrade" happens. Assuming I'm reading that report
correctly that means insserv is giving different output from the same
input every time.

I've tried this on my own machine with avahi-daemon installed and I'm
not seeing the same thing, in my case it always gets assigned to
K01avahi-daemon.

Something that might be useful here is seeing the output from "insserv
-v -s -n". This will show in what order insserv intends to assign each
service in each runlevel. No changes will be made to the system when
insserv is run with the "-n" flag.

It might also be useful to have the LSB header from the avahi-daemon
service file in /etc/init.d/

Jesse

Bug#982848: binutils-m68hc1x: Repackage as a native package

[John Paul Adrian Glaubitz]

Hello Vincent!

> It is suggested to use a native package structure to package binutils
> for a less common target.  The way this package should be packaged is
> described in https://wiki.debian.org/PackagingLessCommonBinutilsTargets
> 
> Please update the packaging to follow the above suggestions.

I'm the primary maintainer of Debian's m68k port and I would be happy
to sponsor the package for you.

Let me know if you're interested.

Please join the debian-68k mailing list and the #debian-ports IRC channel
on OFTC if you want to get in touch with the rest of us.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Thorsten Glaser]

On Sun, 26 Sep 2021, Mark Hindley wrote:

> Thorsten's original report[1] suggests it happens on every upgrade.

root@tglase:/etc # git status
On branch master
nothing to commit, working tree clean
root@tglase:/etc # insserv
root@tglase:/etc # git status
On branch master
Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
deleted:rc0.d/K02avahi-daemon
deleted:rc1.d/K02avahi-daemon
deleted:rc6.d/K02avahi-daemon

Untracked files:
  (use "git add ..." to include in what will be committed)
rc0.d/K01avahi-daemon
rc1.d/K01avahi-daemon
rc6.d/K01avahi-daemon

no changes added to commit (use "git add" and/or "git commit -a")
root@tglase:/etc # insserv
root@tglase:/etc # git status
On branch master
nothing to commit, working tree clean

So it happens on every insserv call.

||/ Name   Version  Architecture Description
+++-==---===>
ii  insserv1.21.0-1.1   amd64boot sequence organizer using LSB 
init.d script dependency informat>


(used to be x32 but I changed all sid systems to bullseye
to avoid UsrMove)

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#994971: OpenCL not working with latest Nvidia driver

[Klaus Ethgen]

Am So den 26. Sep 2021 um 16:56 schrieb Andreas Beckmann:
> On 26/09/2021 17.52, Klaus Ethgen wrote:
> > > I suspect that nvidia-modprobe.conf somehow got deleted. Check
> > >debsums -ac nvidia-kernel-support
> > 
> > Well, THAT gives a missing file.
> 
> Do you still have the transcript of the complete upgrade process? Should be
> available somewhere in /var/log/apt/term.log*, it might give some hints what
> happened.

Here it is.

By the way, make it sense to include all involved persons in reply?
Doesn't the bugtracker send notification too?

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


term.log.bz2
Description: Binary data


signature.asc
Description: PGP signature

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Mark Hindley]

Jesse,


On Sun, Sep 26, 2021 at 12:52:37PM -0300, Jesse Smith wrote:
> It's certainly possible insserv is renaming the shortcuts for
> avahi-daemon from K02 to K01. Though this raises a few questions, I believe:
> 
> 1. Why do you think avahi-daemon should be prefixed with K02 instead of
> K01? (Or does it switch back and force every time insserv is run?) On my
> system it is set as K01 and this looks to be correct.

I think Thorsten's point is that it is switched back and forth each time and
that change (presumably stat mtime or similar) is detected by etckeeper and
forces a commit.

> 2. Is there a service on the system that is getting
> added/removed/changed during the apt upgrade process that is affecting
> the order in which avahi-daemin is getting shutdown?
> 
> I'm suggesting it's likely insserv is making the change, I'm just not
> sure if it's a bug without knowing what else is changing on the system.

Thorsten's original report[1] suggests it happens on every upgrade.

Thanks for your help/

Mark

[1]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989284#5

Bug#995121: ITP: dioptas -- Python based GUI-Program for integration and exploration of 2D x-ray diffraction images

[Roland Mas]

Package: wnpp
Severity: wishlist
Owner: Roland Mas 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: dioptas
  Version : 0.5.2
  Upstream Author : Clemens Prescher 
* URL : https://github.com/Dioptas/Dioptas
* License : GPL-3
  Programming Lang: Python
  Description : Python based GUI-Program for integration and exploration of 
2D x-ray diffraction images

A GUI program for fast analysis of powder X-ray diffraction Images.
It provides the capability of calibrating, creating masks, having pattern
overlays and showing phase lines.

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Jesse Smith]

On 2021-09-26 7:10 a.m., Mark Hindley wrote:
> Jesse,
>
> On Mon, May 31, 2021 at 04:40:17AM +0200, Thorsten Glaser wrote:
>> Package: insserv
>> Version: 1.21.0-1.1
>> Severity: normal
>> X-Debbugs-Cc: t...@mirbsd.de
>>
>> I believe this is insserv; if not, feel free to reassign.
>>
>> With every update, I have etckeeper churn:
>>
>> [master 8a1a489] committing changes in /etc made by "apt-get --purge 
>> dist-upgrade"
>>  Author: mirabilos <…>
>>  4 files changed, 91 insertions(+), 9 deletions(-)
>>  rename rc0.d/{K02avahi-daemon => K01avahi-daemon} (100%)
>>  rename rc1.d/{K02avahi-daemon => K01avahi-daemon} (100%)
>>  rename rc6.d/{K02avahi-daemon => K01avahi-daemon} (100%)
>>
>> Basically, avahi-daemon toggles between K01 and K02 every time.
> I can't see where/how this is happening in insserv. Can you identify the 
> cause?
>

Hi Mark,

It's certainly possible insserv is renaming the shortcuts for
avahi-daemon from K02 to K01. Though this raises a few questions, I believe:

1. Why do you think avahi-daemon should be prefixed with K02 instead of
K01? (Or does it switch back and force every time insserv is run?) On my
system it is set as K01 and this looks to be correct.

2. Is there a service on the system that is getting
added/removed/changed during the apt upgrade process that is affecting
the order in which avahi-daemin is getting shutdown?

I'm suggesting it's likely insserv is making the change, I'm just not
sure if it's a bug without knowing what else is changing on the system.

Jesse

Bug#994971: OpenCL not working with latest Nvidia driver

[Andreas Beckmann]

On 26/09/2021 17.52, Klaus Ethgen wrote:

I suspect that nvidia-modprobe.conf somehow got deleted. Check
   debsums -ac nvidia-kernel-support


Well, THAT gives a missing file.


Do you still have the transcript of the complete upgrade process? Should 
be available somewhere in /var/log/apt/term.log*, it might give some 
hints what happened.


Andreas