Bug#992465: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system

[Michael Biebl]

Hi Nils, hi Peter

Am 20.08.21 um 07:54 schrieb Niels Thykier:


As people have concluded already, the change was intended and functional
although lintian was not updated to match.  Accordingly, I will close
this bug against debhelper.


I think we should start doing the same for udev files in 
/lib/udev/rules.d (i.e. move rules files vi dh_installudev). I will file 
bugs against debhelper and lintian so we can coordinate that.



@Michael: Re: lintian, then there is already a bug now with a patch
https://bugs.debian.org/992465


Thanks for the hint.

I guess after some point, I'd like to see lintian switched to actually 
flag packages that still install files in /lib/systemd/system, i.e. warn 
about them, so we can track the progress of the conversion to 
/usr/lib/systemd/system
We currently have well over 1100 packages installing over 2200 service 
files in /lib, so it's probably too early to do that. Maybe in a couple 
of months.


Regards,
Michael






OpenPGP_signature
Description: OpenPGP digital signature

Bug#991104: antlr: reproducible-builds: Example Makefiles embed build paths and binary paths

[Vagrant Cascadian]

On 2021-07-14, Vagrant Cascadian wrote:
> The attached patch modifies debian/rules to remove the exmaple
> Makefiles.

Unfortunately, I only tested this with arch:all+arch:any builds, not
arch:any builds without arch:all builds, and so the arch:any builds on
buildd.debian.org are failing...

It needs some special-casing to only run when the specified examples
directory is actually present.


> diff --git a/debian/rules b/debian/rules
> index 77396e35..c1e9921c 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -46,6 +46,8 @@ override_dh_installdocs:
>  override_dh_installexamples:
>   dh_installexamples
>   find debian/antlr-doc/usr/share/doc/antlr/examples -type f -print | 
> xargs -r chmod 0644
> + # Remove example Makefiles containing build paths and binary paths
> + find debian/antlr-doc/usr/share/doc/antlr/examples -name Makefile 
> -print -delete
>   rm -rf debian/antlr-doc/usr/share/doc/antlr/examples/csharp
>  
>  override_dh_auto_clean:
> -- 
> 2.32.0

Probably prefixing with something like:

  test ! -d debian/antlr-doc/usr/share/doc/antlr/examples || find ... -print 
-delete

(using "test -d ... && find ..." will error out when the directory isn't
there, e.g. arch:any builds)

This way the arch:any builds will just skip this step...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#992557: ITP: r-cran-gstat -- GNU R spatial and spatio-temporal geostatistical modelling

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-gstat -- GNU R spatial and spatio-temporal geostatistical 
modelling
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-gstat
  Version : 2.0
  Upstream Author : Edzer Pebesma,
* URL : https://cran.r-project.org/package=gstat
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R spatial and spatio-temporal geostatistical modelling
 This GNU R package provides spatio-temporal geostatistical modelling,
 prediction and Simulation Variogram modelling; simple, ordinary and
 universal point or block (co)kriging; spatio-temporal kriging;
 sequential Gaussian or indicator (co)simulation; variogram and variogram
 map plotting utility functions; supports sf and stars.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gstat

Bug#992330: bullseye-pu: package nova/22.2.2-1+deb11u1 (CVE-2021-3654)

[Thomas Goirand]

On 8/19/21 9:26 PM, Salvatore Bonaccorso wrote:
> Hi Thomas,
> 
> [not an authoritative answer, but a suggestion below]
> 
> 
> If this is an import of a new upstream version on top of the current
> packaging (plus some adjustment) then please actually use
> 2:22.2.2-0+deb11u1 which sorts before (an immaginary present)
> 2:22.2.2-1 at some point in unstable.
> 
> Alternatively 2:22.2.2-1~deb11u1.
> 
> Regards,
> Salvatore

Hi Salvatore,

Thanks for your suggestion. However, in the official repository
available at http://bullseye-victoria.debian.net, I have:

22.2.2-1~bpo11+1.dsc

Therefore, I prefer to have the version that I'm proposing, so it is
higher than the version from the unofficial backport, which I can delete
when it reaches official Bullseye.

Yes, I know, it's unofficial, so it "shouldn't count", though as you
see, it is taking way too long to get things updated in Debian as we go
through the normal administrative workflow. Also, I do expect OpenStack
users to use these unofficial backport repositories. So I have to find
ways to cover for production use. Please bare with this.

Cheers,

Thomas Goirand (zigo)

Bug#992500: locales: obsolete /etc/locale.alias settings after drop of non-UTF8 locales

[Aurelien Jarno]

On 2021-08-19 14:22, Vincent Lefevre wrote:
> Package: locales
> Version: 2.31-16
> Severity: normal
> 
> The /etc/locale.alias contains aliases to dropped locales, such as
> 
> french  fr_FR.ISO-8859-1

At this stage those locales haven't been dropped from the locales
package, they can't be chosen anymore in debconf, but they are still
supported if they were configured, or they can still be configured
manually by editing /etc/locales.gen. However, they have indeed been
dropped from the locales-all package.

> Such lines should be removed, or maybe better, replaced to use
> the UTF-8 locales (such as fr_FR.utf8).

It's probably better to just remove that file, as it has been marked as
obsolete for more than 13 years. It's probably something to coordinate
with upstream.

Regards,
Aurelien

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

Bug#992063: bullseye-pu: package fetchmail/6.4.16-4+deb11u1

[GCS]

Hi RMs,

On Tue, Aug 10, 2021 at 4:21 PM László Böszörményi  wrote:
> Asking for a fetchmail package update, fixing a regression in its last
> security fix. This is a one liner, moving down an 'endif'.
 Another issue has emerged, a regression since Buster. With certain
configurations, fetchmail crashes immediately.

[ Reason ]
Some options don't always have value. But code tried to strdup() that
- a non-existent value.

[ Impact ]
With such configurations, users can't use fetchmail anymore. Upstream
fix corrects the behaviour.

[ Tests ]
Local tests mostly. But the fix also went to Sid and it works for all users.

[ Risks ]
None.

[ 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 bullseye
  [x] the issue is verified as fixed in unstable

Thanks for considering,
Laszlo/GCS
diff -Nru fetchmail-6.4.16/debian/changelog fetchmail-6.4.16/debian/changelog
--- fetchmail-6.4.16/debian/changelog	2021-07-29 00:18:56.0 +0200
+++ fetchmail-6.4.16/debian/changelog	2021-08-09 20:06:48.0 +0200
@@ -1,3 +1,11 @@
+fetchmail (6.4.16-4+deb11u1) bullseye; urgency=medium
+
+  * Backport upstream regression fix for 6.4.20's security (CVE-2021-36386)
+fix.
+  * Fix envelope segmentation fault (closes: #992400).
+
+ -- Laszlo Boszormenyi (GCS)   Mon, 09 Aug 2021 20:06:48 +0200
+
 fetchmail (6.4.16-4) unstable; urgency=high
 
   * Backport upstream security fix for CVE-2021-36386: denial of service or
diff -Nru fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch
--- fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch	1970-01-01 01:00:00.0 +0100
+++ fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch	2021-08-09 20:06:48.0 +0200
@@ -0,0 +1,76 @@
+From d3db2da1d13bd2419370ad96defb92eecb17064c Mon Sep 17 00:00:00 2001
+From: Matthias Andree 
+Date: Mon, 9 Aug 2021 17:42:29 +0200
+Subject: [PATCH] Fix --logfile and message truncation issue.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Regression in 6.4.20's security fix (Git commit c546c829).
+
+We doubly incremented partial_message_size_used on modern systems
+(stdard.h/vsnprintf), once in report_vbuild() and then again in
+report_build(), so the 2nd and subsequent report_build() fragments
+landed too late in the buffer.  This will not cause overruns due to the
+reallocation prior to the vsnprintf/sprintf, but it write starts behind
+the '\0' byte, instead of right over it, so the string also gets
+truncated to the first fragment written with report_vbuild().
+
+Fix by moving the increment back into the #else...#endif part that does
+not use report_vbuild().
+
+Reported by: Jürgen Edner, Erik Christiansen
+---
+ NEWS | 18 ++
+ report.c |  3 ++-
+ 2 files changed, 20 insertions(+), 1 deletion(-)
+
+diff --git a/NEWS b/NEWS
+index 0cd3f968..b98f15d2 100644
+--- a/NEWS
 b/NEWS
+@@ -64,6 +64,24 @@ removed from a 6.5.0 or newer release.)
+   for end-of-life OpenSSL versions may be removed even from patchlevel releases.
+ 
+ 
++fetchmail-6.4.21 (released 2021-08-09, 30042 LoC):
++
++# REGRESSION FIX:
++* The new security fix in 6.4.20 for CVE-2021-36386 caused truncation of
++  messages logged to buffered outputs, predominantly --logfile.
++
++  This also caused lines in the logfile to run into one another because
++  the fragment containing the '\n' line-end character was usually lost.
++
++  Reason is that on all modern systems (with  header and vsnprintf()
++  interface), the length of log message fragments was added up twice, so
++  that these ended too deep into a freshly allocated buffer, after the '\0'
++  byte.  Unbuffered outputs flushed the fragments right away, which masked the
++  bug.
++
++  Reported by: Jürgen Edner, Erik Christiansen.
++
++
+ fetchmail-6.4.20 (not yet released):
+ 
+ # SECURITY FIX:
+diff --git a/report.c b/report.c
+index aea6b3ea..2db7d0a9 100644
+--- a/report.c
 b/report.c
+@@ -286,10 +286,11 @@ report_build (FILE *errfp, message, va_alist)
+ n = snprintf (partial_message + partial_message_size_used,
+ 		partial_message_size - partial_message_size_used,
+ 		message, a1, a2, a3, a4, a5, a6, a7, a8);
+-#endif
+ 
+ if (n > 0) partial_message_size_used += n;
+ 
++#endif
++
+ if (unbuffered && partial_message_size_used != 0)
+ {
+ 	partial_message_size_used = 0;
+-- 
+GitLab
+
diff -Nru fetchmail-6.4.16/debian/patches/13_fix_envelope_segfault.patch fetchmail-6.4.16/debian/patches/13_fix_envelope_segfault.patch
--- fetchmail-6.4.16/debian/patches/13_fix_envelope_segfault.patch	1970-01-01 01:00:00

Bug#992558: traps: apache2: general protection fault in libapr-1.so.0.7.0

[curious_debian]

Package: apache2
Version: 2.4.48-3.1+deb11u1
Severity: normal

Dear Maintainer,

Just noticed apache2 crash in dmesg.

[62643.929073] traps: apache2[821205] general protection fault ip:7f80b42c9556
sp:7ffeb6193880 error:0 in libapr-1.so.0.7.0[7f80b42b3000+22000]

I have freshly installed apache2, nothing is running on it, literally just a
"webpage under maintenance" index. But with TLS configured via letsencrypt.
Also system is freshly upgraded from buster, however, entire apache2 has been
nuked and reinstalled from the scratch, so it should be very clean, apart from
TLS config which I put back as it was before upgrade.

This is my 000-default.conf file (minus comments which I deleted)


RewriteEngine on
#RewriteCond %{SERVER_NAME} =ttbit.mine.bz
#RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI}
[END,QSA,R=permanent]
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R]



SSLStaplingCache shmcb:/var/run/apache2/stapling_cache(128000)

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

ServerName mywebsitename
Include /etc/letsencrypt/options-ssl-apache.conf
Header always set Strict-Transport-Security "max-age=63072000;
includeSubdomains; preload"
SSLCertificateFile /etc/letsencrypt/live/mywebsitename/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mywebsitename/privkey.pem
SSLUseStapling on




-- Package-specific info:

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

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

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.48-3.1+deb11u1
ii  apache2-data 2.4.48-3.1+deb11u1
ii  apache2-utils2.4.48-3.1+deb11u1
ii  dpkg 1.20.9
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  mime-support 3.66
ii  perl 5.32.1-4+deb11u1
ii  procps   2:3.3.17-5

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.0+nmu1

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  firefox-esr [www-browser]78.13.0esr-1~deb11u1
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-6
ii  libaprutil1  1.6.1-5
ii  libaprutil1-dbd-sqlite3  1.6.1-5
ii  libaprutil1-ldap 1.6.1-5
ii  libbrotli1   1.0.9-2+b2
ii  libc62.31-13
ii  libcrypt11:4.4.18-4
ii  libcurl4 7.74.0-1.3+b1
ii  libjansson4  2.13.1-1.1
ii  libldap-2.4-22.4.57+dfsg-3
ii  liblua5.3-0  5.3.3-1.1+b1
ii  libnghttp2-141.43.0-1
ii  libpcre3 2:8.39-13
ii  libssl1.11.1.1k-1
ii  libxml2  2.9.10+dfsg-6.7
ii  perl 5.32.1-4+deb11u1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  firefox-esr [www-browser]78.13.0esr-1~deb11u1
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2 is related to:
ii  apache2  2.4.48-3.1+deb11u1
ii  apache2-bin  2.4.48-3.1+deb11u1

-- Configuration Files:
/etc/apache2/sites-available/000-default.conf changed [not included]

-- no debconf information

Bug#992559: fixups for update-shells

[Helmut Grohne]

Source: debianutils
Version: 5.2-2
Tags: patch

Hi Clint,

we've identified a number of smaller issues post merging the
update-shells stuff. This is a cumulative update of known issues.

Guillem Jover asked that update-shells.8 includes a FILES section.

Guillem Jover said that we should also sync containing directories.

Johannes Schauer found that for some reason /etc/shells was not reliably
created prior to running update-shells. We have no clue how this could
happen given that the postinst script always creates /etc/shells before
running update-shells, but it makes
https://salsa.debian.org/helmutg/dpkg-root-demo fail. We propose dealing
with this case and copying the template if needed.

The attached patch addresses all of the above.

Helmut
--- debianutils-5.2.orig/update-shells
+++ debianutils-5.2/update-shells
@@ -63,10 +63,15 @@ done
 
 PKG_DIR="$ROOT/usr/share/debianutils/shells.d"
 STATE_FILE="$ROOT/var/lib/shells.state"
-ETC_FILE="$ROOT/etc/shells"
-NEW_ETC_FILE="$ETC_FILE.tmp"
+TARGET_ETC_FILE="$ROOT/etc/shells"
+SOURCE_ETC_FILE="$TARGET_ETC_FILE"
+NEW_ETC_FILE="$TARGET_ETC_FILE.tmp"
 NEW_STATE_FILE="$STATE_FILE.tmp"
 
+if ! test -e "$SOURCE_ETC_FILE"; then
+   SOURCE_ETC_FILE="$ROOT/usr/share/debianutils/shells"
+fi
+
 PKG_SHELLS='#'
 LC_COLLATE=C.UTF-8  # glob in reproducible order
 for f in "$PKG_DIR/"*; do
@@ -106,7 +111,7 @@ while IFS= read -r line; do
else
log "removing shell $shell"
fi
-done < "$ETC_FILE"
+done < "$SOURCE_ETC_FILE"
 
 : > "$NEW_STATE_FILE"
 saved_IFS=$IFS
@@ -133,12 +138,14 @@ if [ "$NOACT" = 0 ]; then
else
chmod 0644 "$NEW_STATE_FILE"
fi
-   chmod --reference="$ETC_FILE" "$NEW_ETC_FILE"
-   chown --reference="$ETC_FILE" "$NEW_ETC_FILE"
+   chmod --reference="$SOURCE_ETC_FILE" "$NEW_ETC_FILE"
+   chown --reference="$SOURCE_ETC_FILE" "$NEW_ETC_FILE"
sync --data "$NEW_ETC_FILE" "$NEW_STATE_FILE"
-   mv "$NEW_ETC_FILE" "$ETC_FILE"
-   sync "$ETC_FILE"
+   mv "$NEW_ETC_FILE" "$TARGET_ETC_FILE"
+   sync "$TARGET_ETC_FILE"
+   sync "$(dirname "$TARGET_ETC_FILE")"
mv "$NEW_STATE_FILE" "$STATE_FILE"
sync "$STATE_FILE"
+   sync "$(dirname "$STATE_FILE")"
trap "" EXIT
 fi
--- debianutils-5.2.orig/update-shells.8
+++ debianutils-5.2/update-shells.8
@@ -27,5 +27,9 @@ Operate on a chroot at
 .TP
 .B \-\-verbose
 Print the shells that are being added or removed.
+.SH FILES
+.I /etc/shells
+.I /var/lib/shells.state
+.I /usr/share/debianutils/shells.d
 .SH SEE ALSO
 .BR shells (5)

Bug#992346: elpa-org: install script from elpa-org package failed

[Damien Couroussé]

Hi David,

On 19/08/2021 20:31, David Bremner wrote:

I did another test in a schroot.  Here, the error was triggered by the
upgrade of the package 'emacs' from 1:26.1+1-3.2+deb10u2 to
1:27.1+1-3.1, with the package 'elpa-org' already installed.

I believe the issue is related to this package and not to the package
emacs, since the error only appears if the package 'elpa-org' is
installed, or going to be installed.

Are you doing an upgrade to bullseye / stable? Because that version of
emacs is not in oldstable, which is (roughly) what your bug report said.

Yes, the error appeared the first time when upgrading emacs to version 27.


There was some possibly related discussion about running emacs 27 in
buster on the backports list, you could check there.


The error appeared in two situations:

1. emacs 27 (currently in stable/bullseye) is already installed. Install 
elpa-org (from stable as well, i.e. version 9.1.14+dfsg-3). Produces the 
error as reported.
2. elpa-org is installed with emacs in old-stable.  Upgrade emacs to the 
version in stable / bullseye.  The package elpa-org is upgraded as well, 
producing the same error.  Produces the error as reported.


The issue did not occur with previous versions of elpa-org.



I found one discussion probably related to this bug report -- 
https://lists.debian.org/debian-backports/2021/02/msg00016.html
IIUC, the issue may be due to the fact that emacs-27 is now packaged 
with org-mode, which I didn't know.


I am not sure if this is the culprit, but it looks like emacs-27 and 
elpa-org provide possibly conflicting package files:


┌
│ $ dpkg -l elpa-org
│ iF  elpa-org   9.1.14+dfsg-3 all  Keep notes, maintain 
ToDo lists, and do project planning

│
│ $ dpkg -l emacs-common
│ ii  emacs-common   1:27.1+1-3.1 all  GNU Emacs editor's 
shared, architecture independent infras

│
│ $ dpkg -S /usr/share/emacs/27.1/lisp/org/ox-org.elc
│ emacs-common: /usr/share/emacs/27.1/lisp/org/ox-org.elc
│
│ $ dpkg -S /usr/share/emacs/site-lisp/elpa-src/org-9.1.14/ox-org.el
│ elpa-org: /usr/share/emacs/site-lisp/elpa-src/org-9.1.14/ox-org.el
└




best,
Damien

Bug#992500: locales: obsolete /etc/locale.alias settings after drop of non-UTF8 locales

[Vincent Lefevre]

On 2021-08-20 09:52:59 +0200, Aurelien Jarno wrote:
> On 2021-08-19 14:22, Vincent Lefevre wrote:
> > The /etc/locale.alias contains aliases to dropped locales, such as
> > 
> > french  fr_FR.ISO-8859-1
> 
> At this stage those locales haven't been dropped from the locales
> package, they can't be chosen anymore in debconf, but they are still
> supported if they were configured, or they can still be configured
> manually by editing /etc/locales.gen. However, they have indeed been
> dropped from the locales-all package.

I don't understand what you mean. The locales-all package is
documented as containing *all* supported locales.

And with it, "french" is no longer supported:

zira:~> LC_ALL=french perl /dev/null
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = "french",
LC_TIME = "en_DK.utf8",
LC_CTYPE = "C.UTF-8",
LC_CHARMAP = "UTF-8",
LC_COLLATE = "POSIX",
LANG = "POSIX"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("POSIX").

(no warning with glibc 2.31-13 packages).

> > Such lines should be removed, or maybe better, replaced to use
> > the UTF-8 locales (such as fr_FR.utf8).
> 
> It's probably better to just remove that file, as it has been marked as
> obsolete for more than 13 years. It's probably something to coordinate
> with upstream.

Agreed.

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

Bug#992531: osmcoastline: FTBFS with GDAL 3.3.1

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/osmcode/osmcoastline/issues/40

On 8/19/21 9:18 PM, Bas Couwenberg wrote:
> Your package FTBFS with GDAL 3.3.1:
> 
>  10/20 Test #12: test-invalid-self-intersection-on-open-ring 
> ..***Failed0.26 sec
>  + /build/osmcoastline-2.3.0/obj-x86_64-linux-gnu/src/nodegrid2opl
>  + cat
>  + /build/osmcoastline-2.3.0/obj-x86_64-linux-gnu/src/osmcoastline --verbose 
> --overwrite 
> --output-database=/build/osmcoastline-2.3.0/obj-x86_64-linux-gnu/test/invalid-self-intersection-on-open-ring.db
>  
> /build/osmcoastline-2.3.0/obj-x86_64-linux-gnu/test/invalid-self-intersection-on-open-ring.opl
>  + RC=2
>  + set -e
>  + test 2 -eq 2
>  + grep Self-intersection at or near point 
> /build/osmcoastline-2.3.0/obj-x86_64-linux-gnu/test/invalid-self-intersection-on-open-ring.log
>  Warning 1: Self-intersection at or near point 1.0901 
> 1.9749
>  + grep ^There were 2 warnings.$ 
> /build/osmcoastline-2.3.0/obj-x86_64-linux-gnu/test/invalid-self-intersection-on-open-ring.log

This test also fails with GDAL 3.2.2 in unstable, it seems to be caused
by the recent update of GEOS to 3.9.1.

The issue has been forwarded upstream.

Kind Regards,

Bas

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

Bug#992560: mariadb-client-core-10.5: erases mysql client command history

[Jan Ingvoldstad]

Package: mariadb-client-core-10.5
Version: 1:10.5.11-1
Severity: important

Dear Maintainer,

After upgrading from Debian buster to bullseye, and running the mysql command 
line client for the first time, the command line history is wiped, leaving a 
.mysql_history devoid of entries.

This is rather inconvenient, particularly in multi-user environments, where 
multiple .mysql_history files must be recovered from backups.

The bug seems to be related to the regression from GNU readline to BSD EditLine 
as the linked command line/history manager library. This regression is not 
apparent in upstream, at least as they package mariadb-client-core-10.5 for 
buster (versions up to and including: 1:10.5.12+maria~buster).

As far as I can tell, there are two apparent fixes, one apparently technically 
(if not policy-wise) easy, the other rather labor intensive.

Easy fix: revert the regression from readline to EditLine, so that the client 
library uses readline, as upstream does.

More labor intensive fix:

1) Prompt the user upon first use of the command for how to handle the 
situation.

2) Provide conversion for the command line history from readline format to the 
current EditLine format, whatever that may be.

3) Automatically back up the command line history when the user chooses to 
start with a fresh history file.

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

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

Versions of packages mariadb-client-core-10.5 depends on:
ii  libc6   2.31-13
ii  libedit23.1-20191231-2+b1
ii  libmariadb3 1:10.5.11-1
ii  libncurses6 6.2+20201114-2
ii  libssl1.1   1.1.1k-1
ii  libstdc++6  10.2.1-6
ii  libtinfo6   6.2+20201114-2
ii  mariadb-common  1:10.5.11-1
ii  zlib1g  1:1.2.11.dfsg-2

mariadb-client-core-10.5 recommends no packages.

mariadb-client-core-10.5 suggests no packages.

-- no debconf information

Bug#992561: linux-headers-amd64 dependency to linux-headers-5.10.0-0.bpo.8-amd64 is broken in buster-backports

[Markus Rexhepi-Lindberg]

Package: linux-headers-amd64
Version: 4.19+105+deb10u12
Severity: important
Tags: a11y

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I wanted to install the linux-headers-amd64 package from buster-backports.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I ran the following command to install the linux-headers-amd64 package from 
buster-backports.

sudo apt -t buster-backports install linux-headers-amd64

   * What was the outcome of this action?

The package was not able to install. Here is the output of the command.

$ sudo apt install -t buster-backports linux-image-amd64 linux-headers-amd64
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 linux-headers-amd64 : Depends: linux-headers-5.10.0-0.bpo.8-amd64 (= 
5.10.46-2~bpo10+1) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

   * What outcome did you expect instead?

I expected that the linux-headers-amd64 package would install from 
buster-backports without any issues.

   * Suspected cause.

I suspect that the linux-headers-amd64 package from buster-backports is not 
install able because. The linux-headers-amd64_5.10.46-2~bpo10+1 depends on 
linux-headers-5.10.0-0.bpo.8-amd64_5.10.46-2~bpo10+1 but only 
linux-headers-5.10.0-0.bpo.8-amd64_5.10.46-4~bpo10+1 is available and thus a 
mismatch emerge and the installation fails.

*** End of the template - remove these template lines ***


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

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

Versions of packages linux-headers-amd64 depends on:
ii  linux-headers-4.19.0-17-amd64  4.19.194-3

linux-headers-amd64 recommends no packages.

linux-headers-amd64 suggests no packages.

-- no debconf information

Bug#992516: Upstream issue

[Vincent Smeets]

I have created an upstream issue at
https://github.com/karelzak/util-linux/issues/1416 and a pull request as
https://github.com/karelzak/util-linux/pull/1417

Regards,
Vincent

Bug#992526: fiona: FTBFS with GDAL 3.3.1

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/Toblerity/Fiona/issues/1031

On 8/19/21 9:05 PM, Bas Couwenberg wrote:
> Your package FTBFS with GDAL 3.3.1:
> 
>  === short test summary info 
> 
>  FAILED tests/test_datetime.py::test_datefield[GPSTrackMaker-datetime] - 
> fiona...
>  FAILED tests/test_datetime.py::test_datefield_null[GPSTrackMaker-datetime] - 
> ...
>  FAILED 
> tests/test_drvsupport.py::test_no_append_driver_cannot_append[GPSTrackMaker]
>  FAILED tests/test_drvsupport.py::test_no_append_driver_cannot_append[PCIDSK]
>  === 4 failed, 847 passed, 6 skipped, 2 xfailed, 21 xpassed in 13.20s 
> ===

Three of the test failures can be fixed by enabling a deprecated driver,
the remaining one can be skipped.

Kind Regards,

Bas

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

Bug#992563: transition: gdal

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html
Control: block -1 by 992527 992528

For the Debian GIS team I'd like to transition to GDAL 3.3.1.

Most reverse dependencies rebuilt successfully with GDAL 3.3.1 from
experimental as summarized below.

libgdal-grass doesn't need a binNMU as the 3.3.1 version will be
uploaded to unstable instead.


Transition: gdal

 libgdal28 (3.2.2+dfsg-2) -> libgdal29 (3.3.1+dfsg-1~exp1)

The status of the most recent rebuilds is as follows.

 fiona   (1.8.20-2)   OK
 gazebo  (11.1.0+dfsg-6)  OK
 gmt (6.2.0+dfsg-1)   OK
 libcitygml  (2.0.9-3)OK
 libosmium   (2.17.0-1)   OK
 mapcache(1.10.0-2)   OK
 mapnik  (3.1.0+ds-1) OK
 mapproxy(1.13.2-1)   OK
 mapserver   (7.6.4-1)OK
 merkaartor  (0.19.0~rc1+ds-1)OK
 mysql-workbench (8.0.26+dfsg-1)  OK
 ncl (6.6.2-7)OK
 node-srs(1.2.0+~2.6.2-1) FTBFS (#992527)
 octave-mapping  (1.4.1-1)FTBFS (#992528)
 openorienteering-mapper (0.9.4-2)OK
 openscenegraph  (3.6.5+dfsg1-7)  OK
 pdal(2.2.0+ds-1) OK
 pgsql-ogr-fdw   (1.1.1-1)OK
 pktools (2.6.7.6+ds-3)   OK
 postgis (3.1.3+dfsg-1)   OK
 python-django   (2:2.2.24-1) OK
 qmapshack   (1.16.0-1)   OK
 r-cran-rgdal(1.5-21+dfsg-1)  OK
 r-cran-sf   (0.9-7+dfsg-5)   OK
 rasterio(1.2.6-1)OK
 saga(7.3.0+dfsg-5)   OK
 vtk6(6.3.0+dfsg2-8.1)OK
 vtk7(7.1.1+dfsg2-10) OK
 vtk9(9.0.1+dfsg1-8)  OK

 cloudcompare(2.10.3-4)   OK
 grass   (7.8.5-2)OK
 opencv  (4.5.1+dfsg-5)   OK
 osmcoastline(2.3.0-2)OK
 paraview(5.9.0-2)OK
 sumo(1.8.0+dfsg2-5)  OK

 libgdal-grass   (3.2.2-1 / 3.3.1-1~exp1) FTBFS / OK
 otb (7.2.0+dfsg-1)   OK
 qgis(3.16.10+dfsg-1) OK


Kind Regards,

Bas

Bug#992564: FTBFS: "rpc/rpc.h" not found (removed from glibc 2.32)

[Simon Chopin]

Source: caml-crush
Severity: serious
Tags: upstream ftbfs

Dear Maintainer,

The package fails to build from source in clean environments as it
relies on "rpc/rpc.h" being present, while those headers have been
removed in glibc 2.32, considered obsolete. The solution is to use tirpc
instead.

There is a PR upstream to adapt the build system to use tirpc :

https://github.com/caml-pkcs11/caml-crush/pull/47

-- System Information:
Debian Release: 11.0
  APT prefers impish
  APT policy: (500, 'impish'), (50, 'impish-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#785487: supertuxkart: Crash when loading 'Solo' or 'History' screens

[Fabio Pedretti]

Hi Fabien,
are you still able to reproduce this issue?

Bug#992565: ITP: r-cran-datawizard -- GNU R easy data wrangling

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-datawizard -- GNU R easy data wrangling
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-datawizard
  Version : 0.2.0
  Upstream Author : Dominique Makowski (,
* URL : https://cran.r-project.org/package=datawizard
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R easy data wrangling
 A lightweight GNU R package to easily manipulate, clean,
 transform, and prepare your data for analysis. It also forms
 the data wrangling backend for the packages in the 'easystats'
 ecosystem.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-datawizard

Bug#908196: linux-image-4.9.0-8-armmp: Please set CONFIG_LEDS_PCA963X=m

[Vincent Blut]

Hi Reco,

Le 2021-08-20 11:16, Reco a écrit :
>   Hi, Vincent.
> 
> On Tue, Aug 17, 2021 at 04:41:20PM +0200, Vincent Blut wrote:
> > Package: src:linux
> > Followup-For: Bug #908196
> 
> > Is it still worthwhile to enable this option?
> 
> IMO yes. I have the thing sitting on my desk now, it runs Debian, and it
> serves its function.

Good to know.

> > So if this router does not run on Linux 5.13+, it's probably not worth
> > to enable this option.
> 
> I've just upgraded the device to bullseye, and installed
> linux-image-5.13.0-trunk from the experimental on it.
> I confirm that:
> 
> - the device boots successfully with that kernel.
> - both LAN and WAN ports work.
> - USB ports work too.
> 
> The kernel from the experimental just misses the usual:
> 
> - pca963x for WAN/WIFI leds
> - wifi.
> 
> Wifi requires out of tree module anyway, and its outside of the scope of
> this bug report.

OK! I'll send a merge request to the kernel team later today then.
> 
> Sincerely yours, Reco

Have a good day,
Vincent


signature.asc
Description: PGP signature

Bug#983412: libc-bin: please add support for DPKG_ROOT to the postinst

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Johannes 'josch' Schauer (2021-02-23 20:30:41)
> this is a followup on
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910685

we can now verify that with this patch it is possible to create a Debian chroot
that is bit-by-bit identical to one created the normal way:

https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs

Currently, half the time in our CI job is spent building glibc. It would be
great if this patch can be applied, so that we do not have to build a patched
glibc anymore.

I opened a merge request here:

https://salsa.debian.org/glibc-team/glibc/-/merge_requests/4

And attached the git-format-patch.

Thanks!

cheers, josch>From 64e9212385a7cf75a206481e539ca1779a075b5e Mon Sep 17 00:00:00 2001
From: Johannes Schauer Marin Rodrigues 
Date: Fri, 20 Aug 2021 11:37:16 +0200
Subject: [PATCH] More support for DPKG_ROOT (closes: #983412)

 - this partially reverts 9e77b114 because debconf is patched to support
   DPKG_ROOT
---
 debian/changelog  | 4 
 debian/debhelper.in/libc-bin.postinst | 6 +++---
 debian/debhelper.in/libc.postinst | 2 +-
 debian/debhelper.in/libc.preinst  | 6 +++---
 4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index f9175ced..e6b256d9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,11 @@
 glibc (2.31-17) UNRELEASED; urgency=medium
 
+  [ Samuel Thibault ]
   * debian/testsuite-xfail-debian.mk: Update tests.
 
+  [ Johannes Schauer Marin Rodrigues ]
+  * additional bits to support DPKG_ROOT (closes: #983412)
+
  -- Samuel Thibault   Wed, 18 Aug 2021 23:04:08 +0200
 
 glibc (2.31-16) unstable; urgency=medium
diff --git a/debian/debhelper.in/libc-bin.postinst b/debian/debhelper.in/libc-bin.postinst
index 802a3ad0..7fc320c5 100644
--- a/debian/debhelper.in/libc-bin.postinst
+++ b/debian/debhelper.in/libc-bin.postinst
@@ -40,15 +40,15 @@ update_to_current_default() {
 }
 
 if [ "$1" = "configure" ] && [ "$2" = "" ] ; then
-  install_from_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf
+  install_from_default "$DPKG_ROOT/usr/share/libc-bin/nsswitch.conf" "$DPKG_ROOT/etc/nsswitch.conf"
 fi
 
 if [ "$1" = "configure" ] && [ "$2" != "" ]; then
-  update_to_current_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf
+  update_to_current_default "$DPKG_ROOT/usr/share/libc-bin/nsswitch.conf" "$DPKG_ROOT/etc/nsswitch.conf"
 fi
 
 if [ "$1" = "triggered" ] || [ "$1" = "configure" ]; then
-  ldconfig || ldconfig --verbose
+  ldconfig -r "$DPKG_ROOT/" || ldconfig --verbose -r "$DPKG_ROOT/"
   exit 0
 fi
 
diff --git a/debian/debhelper.in/libc.postinst b/debian/debhelper.in/libc.postinst
index 687ebc4c..d58771ed 100644
--- a/debian/debhelper.in/libc.postinst
+++ b/debian/debhelper.in/libc.postinst
@@ -20,7 +20,7 @@ then
 __NOHWCAP__
 fi
 
-if [ "$type" = configure -a -z "$DPKG_ROOT" ]
+if [ "$type" = configure ]
 then
 # Load debconf module if available
 if [ -f /usr/share/debconf/confmodule ] ; then
diff --git a/debian/debhelper.in/libc.preinst b/debian/debhelper.in/libc.preinst
index 9a857c9c..75519bca 100644
--- a/debian/debhelper.in/libc.preinst
+++ b/debian/debhelper.in/libc.preinst
@@ -12,7 +12,7 @@ kernel_compare_versions () {
 test $verA -$2 $verB
 }
 
-if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
+if [ "$type" != abort-upgrade ]
 then
 # Load debconf module if available and usable
 if [ -f /usr/share/debconf/confmodule ]; then
@@ -159,7 +159,7 @@ then
 fi
 fi
 
-if [ "$type" = upgrade -a -z "$DPKG_ROOT" ]
+if [ "$type" = upgrade ]
 then
 if [ -n "$preversion" ] && [ -x "$(command -v ischroot)" ] && ! ischroot; then
 	# NSS authentication trouble guard
@@ -247,7 +247,7 @@ then
 
 # This will keep us from using hwcap libs (optimized) during an
 # upgrade.
-touch /etc/ld.so.nohwcap
+touch "$DPKG_ROOT/etc/ld.so.nohwcap"
 fi
 
 #DEBHELPER#
-- 
2.30.2



signature.asc
Description: signature

Bug#992498: Should util-linux take over hardlink?

[Julian Andres Klode]

On Thu, Aug 19, 2021 at 01:36:45PM +0200, Chris Hofstaedtler wrote:
> Source: hardlink,util-linux
> Severity: wishlist
> 
> Hello Julian,
> 
> I'm filing this bug as a conversation starter. It appears you have
> submitted hardlink to util-linux upstream. That made me wonder if
> util-linux in Debian should start building and installing the
> hardlink program, effectively taking it over from the hardlink
> package?
> 
> I have not checked if there are differences between the util-linux
> version and the current version in hardlink.
> 
> What were/are your intentions/thoughts on this?

Yes, that's why it was submitted. util-linux should provide/conflicts/
replaces hardlink, and hardlink should be RMed.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Bug#973153: caml-crush: FTBFS: ocamlopt: OCaml has been configured with -force-safe-string: -unsafe-string is not available.

[Simon Chopin]

Source: caml-crush
Followup-For: Bug #973153

There's a PR upstream to deal with this:

https://github.com/caml-pkcs11/caml-crush/pull/46

-- System Information:
Debian Release: 11.0
  APT prefers impish
  APT policy: (500, 'impish'), (50, 'impish-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#992566: reportbug: should support a timeout option in reportbug.conf / .reportbugrc

[Vincent Lefevre]

Package: reportbug
Version: 7.10.3
Severity: wishlist

reportbug has a --timeout=SECONDS option, but there is no
corresponding option for the .reportbugrc file: a line

timeout 20

gives the following messages:

Unrecognized token: timeout
Unrecognized token: 20

Once done, it should also be described in the reportbug.conf(5)
man page.

-- Package-specific info:
** Environment settings:
EDITOR="/home/vinc17/bin/eclient"
PAGER="less -Lis"
VISUAL="/home/vinc17/bin/eclient"
EMAIL="vinc...@vinc17.net"
INTERFACE="text"

** /home/vinc17/.reportbugrc:
reportbug_version "2.10"
mode advanced
ui text
realname "Vincent Lefevre"
email "vinc...@vinc17.net"
mua mutt
cc
timeout 20

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

Kernel: Linux 5.10.0-8-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 reportbug depends on:
ii  apt2.3.8
ii  python33.9.2-3
ii  python3-reportbug  7.10.3
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
ii  debsums 3.0.2
ii  dlocate 1.07+nmu1
ii  emacs-bin-common1:27.1+1-3.1
ii  file1:5.39-3+local1
ii  gnupg   2.2.27-2
ii  postfix [mail-transport-agent]  3.5.6-1+b1
ii  python3-urwid   2.1.2-1
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.3.8
ii  file   1:5.39-3+local1
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-debian 0.1.39
ii  python3-debianbts  3.2.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug 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#992361: [Python-modules-team] Bug#992361: O: python-slip

[Michael Biebl]

Am 19.08.21 um 22:29 schrieb Emmanuel Arias:

Hi everybody,

The last upstream release is from 2017, upstream appears to be not that
active [2].


But have a commit two months ago.
I'll be happy to take python-slip. But I will like to know if it is 
"convenient" to do it.


So, first I would like to understand how important is a package for 
Debian. I run

`apt rdepends python3-slip` and then `apt rdepends python3-slip-dbus`
(I guess the correct way) and as Michael mentioned this python-slip will 
not be used

by any other package until today.


I used dak:


$ dak rm -Rn python-slip
Will remove the following packages from unstable:

python-slip |0.6.5-3 | source
python3-slip |0.6.5-3 | all
python3-slip-dbus |0.6.5-3 | all

Maintainer: Debian QA Group 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
selinux-dbus: policycoreutils-dbus
selinux-python: policycoreutils-gui

Dependency problem found.



As bigon mentioned earlier though, selinux-{dbus, python} will drop this 
dependency in a few months. At that point, there will be no remaining 
rdeps of python-slip.


Also I look in the popcon, but I don't know how to interpret it, I mean, 
for example,

how many downloads are a "good number".

So, what is your recommendation? Take python-slip and other package mark 
as orphan?

or it's a good idea to leave it for newcomers?


I have no opinion on whether it is useful to keep python-slip or not.

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992568: glibc: inconsistency in NEWS.Debian.gz file for locales and locales-all

[Vincent Lefevre]

Source: glibc
Version: 2.31-16
Severity: minor

The NEWS.Debian.gz file for locales and locales-all packages contain:

Please note that iconv still supports conversion to and from non UTF-8
charsets. For instance reading a file using an ISO-8859-15 charset can be
done with: iconv --from-code=ISO-8859-1 foobar.txt

There is a mismatch between ISO-8859-15 and ISO-8859-1.

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

Kernel: Linux 5.10.0-8-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

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

Bug#992567: ayatana-indicator-sound: Upgrading (full-upgrade) from Buster to Bullseye broke sound handling

[Dávur Eyðunsson Sørensen]

Package: ayatana-indicator-sound
Version: 0.8.2-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: dav...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I did a full upgrade, Buster>Bullseye on the night of the release on my Dell
Latitude E5270.
Afterwards both Bluetooth and the sound applet were gone from the topbar and
the sound keys (F1,F2,F3) no longer controlled the sound.

Doing a Web search for 'debian sound applet gone', I found recommendation for
install or re-install package 'indicator-sound' but that returned 'package is
not available but will be replaced by ayatana-indicator-sound'.

Installing ayatana-indicator-sound also installed a few other items:
apg ayatana-indicator-common ayatana-indicator-sound cheese-common
gir1.2-malcontent-0 gnome-control-center gnome-control-center-data
  libasound2-plugins libcanberra-pulse libcheese-gtk25 libcheese8 libflatpak0
liblomiri-url-dispatcher0 libmalcontent-ui-0-0
  libnss-myhostname libostree-1-1 libpulsedsp malcontent malcontent-gui
pulseaudio pulseaudio-module-bluetooth pulseaudio-utils realmd rtkit



*** End of the template - remove these template lines ***


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.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 ayatana-indicator-sound depends on:
ii  ayatana-indicator-common 0.8.4-1
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  init-system-helpers  1.60
ii  libaccountsservice0  0.6.55-3
ii  libc62.31-13
ii  libgee-0.8-2 0.20.4-1
ii  libglib2.0-0 2.66.8-1
ii  libglib2.0-bin   2.66.8-1
ii  liblomiri-url-dispatcher00.1.0-4
ii  libnotify4   0.7.9-3
ii  libpulse-mainloop-glib0  14.2-2
ii  libpulse014.2-2
ii  pulseaudio   14.2-2

Versions of packages ayatana-indicator-sound recommends:
ii  accountsservice   0.6.55-3
ii  gnome-control-center  1:3.38.4-1

Versions of packages ayatana-indicator-sound suggests:
pn  ayatana-greeter-session-broadcast  

Bug#992569: missing-debian-watch-file-standard files for watch files without content

[Jelmer Vernooij]

Package: lintian
Version: 2.104.0
Severity: minor


The missing-debian-watch-file-standard tag triggers for a lot of debian/watch
files that have no contents, or only contain comments.

For example, this is the case for the "aladin" package, where the comments are:

# The latest version of upstream can be found at
#  http://aladin.u-strasbg.fr/java/nph-aladin.pl?frame=downloading .
# Since upstream does not provide a versioning scheme, however,
#  (source archives are generally named "AladinSrc.jar") the watch
#  file syntax will not have any effect.
#
# A tools to download + version the upstream Jarball can be found at:
#  https://github.com/sladen/vo/blob/master/aladin-meta/fetch-aladin-source.py

https://lintian.debian.org/tags/missing-debian-watch-file-standard

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 lintian depends on:
ii  binutils2.37-4
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.26-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.430-2
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012002-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.08-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.22-3
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.1-5
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#992533: steam: Does not work on 32-bit (i386) systems

[Simon McVittie]

Control: retitle -1 steam: Does not work on 32-bit (i386) systems
Control: tags -1 + upstream wontfix

On Thu, 19 Aug 2021 at 21:27:30 +0200, Nicolas Patrois wrote:
> I can launch Steam (use and see the window) but I can’t open the navigator
> inside it.

Steam requires a 64-bit operating system and a 64-bit CPU. It is installable
on 32-bit (i386) Debian for historical reasons, but Valve do not support
32-bit installations any more.

Very old versions did work on purely 32-bit systems, but Steam
auto-updates, so it is not possible to run an old version. This is
outside Debian's control.

For newer versions, we need to keep steam as an i386 package for now,
so that it can pull in i386 dependencies on an amd64 system.

I want to do some restructuring of the Steam package that would make it
correctly not be installable on pure i386 systems, and make it install
64-bit dependencies more reliably, but that's going to require some
work behind the scenes (we have to dot every i and cross every t in
terms of licensing before going through the NEW queue to add additional
binary packages).

smcv

Bug#689997: Not only myspell-hu

[Philipp Marek]

Not only myspell-hu errors out here:


	Building PostgreSQL dictionaries from installed myspell/hunspell 
packages...

ERROR: no ecoding defined in /usr/share/hunspell/ar.aff, ignoring
  bg_bg
...
  hu_hu
iconv: ungültige Eingabe-Sequenz an der Stelle 131
ERROR: Conversion of /usr/share/hunspell/hu_HU.aff failed
  id_id
  is_is
  it_it
ERROR: no ecoding defined in /usr/share/hunspell/kk_KZ.aff, ignoring
  kmr_latn

Bug#992570: nmu: rebuild on buildd for testing migration

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu eln_1.4.0-1 . amd64 . unstable . -m "rebuild on buildd"
nmu jpegqs_1.20210408-1 . amd64 . unstable . -m "rebuild on buildd"
nmu python-pyo_1.0.4-1 . amd64 . unstable . -m "rebuild on buildd"
nmu sptag_0.0~git20210514.20d55e1+ds-1 . amd64 . unstable . -m "rebuild on 
buildd"
nmu virt-v2v_1.44.0-1 . amd64 . unstable . -m "rebuild on buildd"
nmu qemu-web-desktop_21.08.10-1 . amd64 . unstable . -m "rebuild on buildd"
nmu kexec-tools_1:2.0.22-2 . amd64 . unstable . -m "rebuild on buildd"
nmu fuse-posixovl_1.3-1 . amd64 . unstable . -m "rebuild on buildd"
nmu recordmydesktop_0.4.0-1 . amd64 . unstable . -m "rebuild on buildd"
nmu foremost_1.5.7-10 . amd64 . unstable . -m "rebuild on buildd"

Bug#992572: variables no longer exported to hooks (LIVE_IMAGE_NAME, LB_ARCHITECTURE, etc)

[Nicholas Brown]

Package: live-build
Version: 1:20210407

This MR:
https://salsa.debian.org/live-team/live-build/-/merge_requests/173//diffs
removed the export of the following variables:

LIVE_CONFIGURATION_VERSION
LIVE_IMAGE_NAME (no renamed to LB_IMAGE_NAME)
LB_ARCHITECTURE
LIVE_IMAGE_TYPE

These are useful from hooks.
(example:
https://github.com/danos/build-iso/blob/master/config/hooks/live/00-manifest.binary
)

It would great if live-build could continue to export these so they are
available to hooks.

Bug#992571: Debian 11 install success on Xiaomi notebook

[肖盛文]

Package: installation-reports
Severity: wishlist
Tags: d-i
X-Debbugs-Cc: atzli...@sina.com

Boot method: USB
Image version: debian-11.0.0-amd64-netinst.iso


Machine: https://linux-hardware.org/?probe=485caf5846


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

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



-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210731"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-3 (2021-07-28) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:190c] 
(rev 08)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD 
Graphics 515 [8086:191e] (rev 07)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon 
E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 
08)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP 
USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: 00:15.1 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-LP 
SATA Controller [AHCI mode] [8086:9d03] (rev 21)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #9 [8086:9d18] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation LPC/eSPI Controller 
[8086:9d46] (rev 21)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise 
Point-LP PMC [8086:9d21] (rev 21)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD 
Audio [8086:9d70] (rev 21)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel, snd_soc_skl
lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus 
[8086:9d23] (rev 21)
lspci -knn: Subsystem: Xiaomi Device [1d72:1501]
lspci -knn: 01:00.0 Network controller [0280]: Intel Corporation Wireless 8260 
[8086:24f3] (rev 3a)
lspci -knn: Subsystem: Intel Corporation Device [8086:9010]
lspci -knn: Kernel modules: iwlwifi
usb-list: 
usb-list: Bus 01 Device 01: xHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 5.10.0-8-amd64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 01 Device 02: DT 101 G2 [0951:1642]
usb-list:Level 01 Parent 01 Port 01  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: Kingston
usb-list:Interface 00: Class 08(mstor) Subclass 06 Protocol 50 Driver 
usb-storage
usb-list: 
usb-list: Bus 01 Device 03: DT 101 G2 [8087:0a2b]
usb-list:Level 01 Parent 01 Port 02  Class e0(wlcon) Subclass 01 Protocol 01
usb-list:Interface 00: Class e0(wlcon) Subclass 01 Protocol 01 Driver 
usb-list:Interface 01: Class e0(wlcon) Subclass 01 Protocol 01 Driver 
usb-list: 
usb-list: Bus 01 Device 04: XiaoMi USB 2.0 Webcam [04f2:b59a]
usb-list:Level 01 Parent 01 Port 06  Class ef(misc ) Subclass 02 Protocol 01
usb-list

Bug#990191: xml-core: leftovers on package purge

[Tommi Höynälänmaa]

Hello


On Tue, 22 Jun 2021 14:18:53 +0200 Christoph Anton Mitterer 
 wrote:


> Package: xml-core
> Version: 0.18+nmu1
> Severity: normal
>
>
>
> Hi.
>
> It seems the package purge has some issues:
> Purging configuration files for xml-core (0.18+nmu1) ...
> dpkg: warning: while removing xml-core, directory '/etc/xml' not 
empty so not removed

>
>

...

I get the following error message:

---

Removing xml-core (0.18+nmu1) ...
Purging configuration files for xml-core (0.18+nmu1) ...
dpkg: warning: while removing xml-core, directory '/etc/sgml' not empty 
so not removed


---

Are you sure it is /etc/xml in your error message?

 - Tommi Höynälänmaa




OpenPGP_0xBB861FDE40460F83.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#989355: transition: tinyxml2

[Chow Loong Jin]

On Fri, Aug 20, 2021 at 12:23:46AM +0200, Sebastian Ramacher wrote:
> On 2021-06-08 02:06:08 +0800, Chow Loong Jin wrote:
> > On Sat, Jun 05, 2021 at 05:39:04PM +0800, Chow Loong Jin wrote:
> > > On Wed, Jun 02, 2021 at 12:27:06PM +0200, Sebastian Ramacher wrote:
> > > > On 2021-06-02 02:45:56, Chow Loong Jin wrote:
> > > > > Package: release.debian.org
> > > > > Severity: normal
> > > > > User: release.debian@packages.debian.org
> > > > > Usertags: transition
> > > > > 
> > > > > There's been an ABI break without an upstream soname bump in
> > > > > libtinyxml2-8, between upstream versions 8.0.0 and 8.1.0, see [1] and
> > > > > [2]. To remedy this, I have uploaded version 8.1.0+dfsg-2 to
> > > > > experimental with the library package renamed from libtinyxml2-8 to
> > > > > libtinyxml2-8a. It is waiting in the NEW queue now.
> > > > 
> > > > Please revert tinyxml2 in unstable to the state of 8.0.0+dfsg-2 to
> > > > avoid uploads of reverse dependencies that are targetted for bullseye to
> > > > be built against the broken version.
> > > 
> > > Done -- uploaded 8.0.0+dfsg-2 as 8.1.0+really8.0.0+dfsg-1 to unstable
> > > 
> > > Also reuploaded 8.1.0+dfsg-2 as 8.1.0+really8.1.0+dfsg-1 to experimental
> > > to keep the relative order of the versions.
> > 
> > The upstream developer has uploaded a 9.0.0 release with the desired
> > soname bump to libtinyxml2.so.9, which I have packaged and uploaded into
> > experimental as 9.0.0+dfsg-1.
> 
> Please go ahead

Thanks. Uploaded 9.0.0+dfsg-1 to unstable.

-- Loong Jin


signature.asc
Description: PGP signature

Bug#981515: kcoreaddons: please replace fam with gamin

[Chris Hofstaedtler]

Hi Pino,

given we are now in the bookworm cycle - do you think kcoreaddons
could remove fam (or replace it with gamin if really needed)?

Do you want a wider audience informed of the change, or would the
change in kcoreaddons be self-contained enough?

Thanks,
Chris

Bug#992574: mailcap: should no longer use "which" in mailcap.postinst

[Vincent Lefevre]

Package: mailcap
Version: 3.69
Severity: normal

I got the following warning:

Processing triggers for mailcap (3.69) ...
/usr/bin/which: this version of 'which' is deprecated and should not be used.

Indeed, "which" is used twice in mailcap.postinst.

Use "command -v" instead.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 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 mailcap depends on:
ii  media-types  4.0.0
ii  perl 5.32.1-5

Versions of packages mailcap recommends:
ii  bzip2 1.0.8-4
ii  file  1:5.39-3
ii  xz-utils  5.2.5-2

mailcap 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#992575: libtorrent-rasterbar10: import fails on Raspberry Pi 3b

[Eetu Karppinen]

Package: libtorrent-rasterbar10
Version: 1.2.9-0.3
Severity: important
X-Debbugs-Cc: eetu.karppi...@aalto.fi

Hey,

trying to import libtorrent on Raspberry Pi 3b in python results in the 
following error:

$ python3 -c 'import libtorrent'
Traceback (most recent call last):
  File "", line 1, in 
ImportError: /usr/lib/arm-linux-gnueabihf/libtorrent-rasterbar.so.10: undefined 
symbol: __atomic_fetch_add_8

Installed libtorrent packages:

$ dpkg --list | grep libtorrent
ii  libtorrent-rasterbar101.2.9-0.3
armhfC++ bittorrent library by Rasterbar Software
ii  python3-libtorrent1.2.9-0.3
armhfPython bindings for libtorrent-rasterbar (Python 3)

This might be related? https://github.com/arvidn/libtorrent/issues/5117

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Architecture: armv7l

Kernel: Linux 5.10.52-v7+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libtorrent-rasterbar10 depends on:
ii  libc6   2.31-13+rpi1
ii  libgcc-s1   10.2.1-6+rpi1
ii  libssl1.1   1.1.1k-1
ii  libstdc++6  10.2.1-6+rpi1

libtorrent-rasterbar10 recommends no packages.

Versions of packages libtorrent-rasterbar10 suggests:
pn  libtorrent-rasterbar-dbg  

-- no debconf information

Bug#986713: gpsd: please stop build-depending on makedev

[Chris Hofstaedtler]

Hi Bernd,

* Chris Hofstaedtler  [210820 11:47]:
> your package build-depends on makedev, which itself is long
> obsolete. Please consider replacing makedev.

I know that this was tried in gpsd 3.5-5, and apparently caused an
issue on mips. However, mips itself is long gone, and the mipsel
build log for 3.5-5 doesn't show a problem.

Would you consider trying removing makedev from Build-Depends once
again?

Thanks,
Chris

Bug#969240: playonlinux: please switch away from netcat

[Chris Hofstaedtler]

Control: severity -1 serious

* Chris Hofstaedtler  [210820 11:49]:
> playonlinux Depends on netcat. This is a transitional package on
> netcat-openbsd, and the transitional package should go away sooner
> than later, preferably in bullseye.

The transitional "netcat" package is now gone in bookworm.
Your package is therefore now uninstallable.

Chris

Bug#989734: mailgraph does not start on boot

[Jörg Frings-Fürst]

Hello,

Debian 10 uses systemd as init system.

Mailgraph is disabled after installation. You must first enable
mailgraph with:

  systemctl enable mailgraph

After that the daemon starts after boot.

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#992576: mfgtools FTBFS on armel/mipsel/m68k/powerpc/sh4: must link with libatomic

[Adrian Bunk]

Source: mfgtools
Version: 1.4.139-1
Severity: serious
Tags: ftbfs patch

https://buildd.debian.org/status/package.php?p=mfgtools&suite=sid

...
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -pthread -O2 -Wl,-z,relro -Wl,-z,now 
CMakeFiles/uuu.dir/uuu.cpp.o CMakeFiles/uuu.dir/buildincmd.cpp.o 
CMakeFiles/uuu.dir/autocomplete.cpp.o -o uuu   -L/<>/uuu/libuuu  
../libuuu/libuuc_s.a /usr/lib/arm-linux-gnueabi/libssl.so 
/usr/lib/arm-linux-gnueabi/libcrypto.so -lusb-1.0 -lzip -lz -ldl -lbz2 
/usr/bin/ld: ../libuuu/libuuc_s.a(usbhotplug.cpp.o): in function 
`std::atomic > 
>::load(std::memory_order) const':
/usr/include/c++/10/atomic:258: undefined reference to `__atomic_load_8'
/usr/bin/ld: /usr/include/c++/10/atomic:258: undefined reference to 
`__atomic_load_8'
/usr/bin/ld: /usr/include/c++/10/atomic:258: undefined reference to 
`__atomic_load_8'
/usr/bin/ld: ../libuuu/libuuc_s.a(usbhotplug.cpp.o): in function 
`std::atomic > 
>::load(std::memory_order) const':
/usr/include/c++/10/atomic:258: undefined reference to `__atomic_load_8'
/usr/bin/ld: /usr/include/c++/10/atomic:258: undefined reference to 
`__atomic_load_8'
/usr/bin/ld: ../libuuu/libuuc_s.a(usbhotplug.cpp.o): in function 
`std::atomic > 
>::store(std::chrono::duration >, 
std::memory_order)':
/usr/include/c++/10/atomic:247: undefined reference to `__atomic_store_8'
/usr/bin/ld: ../libuuu/libuuc_s.a(usbhotplug.cpp.o): in function 
`std::atomic > 
>::store(std::chrono::duration >, 
std::memory_order)':
/usr/include/c++/10/atomic:247: undefined reference to `__atomic_store_8'
/usr/bin/ld: ../libuuu/libuuc_s.a(usbhotplug.cpp.o): in function 
`std::atomic > 
>::store(std::chrono::duration >, 
std::memory_order)':
/usr/include/c++/10/atomic:247: undefined reference to `__atomic_store_8'
collect2: error: ld returned 1 exit status
make[3]: *** [uuu/CMakeFiles/uuu.dir/build.make:184: uuu/uuu] Error 1


Fix/Workaround:

--- debian/rules.old2021-08-20 12:01:24.425914897 +
+++ debian/rules2021-08-20 12:01:59.806444576 +
@@ -3,6 +3,11 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all 
reproducible=+fixfilepath,+fixdebugpath
 include /usr/share/dpkg/pkg-info.mk
 
+ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mipsel powerpc sh4))
+  export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
-Wl,--as-needed
+endif
+
+
 %:
dh $@
 

Bug#992577: RFS: mailgraph/1.14-18 -- RRDtool frontend for Mail statistics

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mailgraph":

   Package name: mailgraph
   Version : 1.14-18
   Upstream Author : David Schweikert 
   URL : https://mailgraph.schweikert.ch
   License : GPL-2
   Vcs : https://jff.email/cgit/mailgraph.git
   Section : admin

It builds those binary packages:

  mailgraph - RRDtool frontend for Mail statistics

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/m/mailgraph/mailgraph_1.14-18.dsc

or from 

 git https://jff.email/cgit/mailgraph.git/?h=release/debian/1.14-18

Changes since the last upload:

 mailgraph (1.14-18) unstable; urgency=medium
 .
   * Migrate to debhelper-compat 13:
 - Remove debian/compat.
 - debian/control:
   + Bump minimum debhelper-compat version to = 13.
   * Declare compliance with Debian Policy 4.6.0.0 (No changes needed).
   * debian/control:
 - Add ${misc:Pre-Depends}.
 - Add Rules-Requires-Root: no.
   * Rename NEWS.Debian to NEWS (thanks to lintian).
   * Fix the owner and the group of the directory /var/lib/mailgraph/
 (Closes: #927017). Thanks to Michael Krieger .
   * debian/copyright:
 - Add year 2021 to myself.


CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#981522: varmon - ship with bullseye?

[Chris Hofstaedtler]

Control: severity -1 serious

Hi Christoph,

* Christoph Franzen  [210820 12:09]:
> > Note that the dac960 has been removed from Linux 4.20-rc1. myrb/myrs
> > are given as replacements, but someone should check varmon works
> > with those drivers.
>  
> I WILL test the new driver, when I've enough spare time – it probably
> involves to set up a fresh installation rather than starting from the
> old "Lenny era" test drive I've stored with my spare card. The other
> machine has a more recent version, but I think is still too old to
> simply install a 4.x kernel and try loading that module.

> If you think it takes too long, please send me a reminder.

In the meantime I have checked the new driver sources, and found
that the new drivers do not register the special "misc" device
varmon relies on.

I would find it highly unlikely that varmon can work at all with any
4.x or 5.x kernel.

Therefore I'm marking this bug as serious, as I believe varmon is of
zero use in bookworm and forward.

Thanks,
Chris

Bug#992578: login: please add support for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Package: login
Version: 1:4.8.1-1
Severity: normal
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support
Control: block -1 by 989712

Hi,

We're working on a way to install packages into a chroot without
actually using the chroot system call. A consequence of doing so is that
maintainer scripts are run outside the chroot and are supposed to still
operate on the chroot whose location is communicated via the DPKG_ROOT
environment variable.

We have created a salsaci job which patches 13 source packages,
including src:shadow and shows that a chroot-tarball created that way is
bit-by-bit identical to a chroot-tarball created the normal way:

https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs

The necessary changes to src:shadow can be found in bug #989712 as well
as in the patch at the end of this mail.

Thanks!

cheers, josch

--- a/debian/login.postinst
+++ b/debian/login.postinst
@@ -4,23 +4,23 @@
 
 if [ "$1" = "configure" ]; then
# Install faillog during initial installs only
-   if [ "$2" = "" ] && [ ! -f /var/log/faillog ] ; then
-   touch /var/log/faillog
-   chown root:root /var/log/faillog
-   chmod 644 /var/log/faillog
+   if [ "$2" = "" ] && [ ! -f "$DPKG_ROOT/var/log/faillog" ] ; then
+   touch "$DPKG_ROOT/var/log/faillog"
+   chown 0:0 "$DPKG_ROOT/var/log/faillog"
+   chmod 644 "$DPKG_ROOT/var/log/faillog"
fi

# Create subuid/subgid if missing
-   if [ ! -e /etc/subuid ]; then
-   touch /etc/subuid
-   chown root:root /etc/subuid
-   chmod 644 /etc/subuid
+   if [ ! -e "$DPKG_ROOT/etc/subuid" ]; then
+   touch "$DPKG_ROOT/etc/subuid"
+   chown 0:0 "$DPKG_ROOT/etc/subuid"
+   chmod 644 "$DPKG_ROOT/etc/subuid"
fi

-   if [ ! -e /etc/subgid ]; then
-   touch /etc/subgid
-   chown root:root /etc/subgid
-   chmod 644 /etc/subgid
+   if [ ! -e "$DPKG_ROOT/etc/subgid" ]; then
+   touch "$DPKG_ROOT/etc/subgid"
+   chown 0:0 "$DPKG_ROOT/etc/subgid"
+   chmod 644 "$DPKG_ROOT/etc/subgid"
fi
 fi
 

Bug#981515: kcoreaddons: please replace fam with gamin

[Pino Toscano]

block 981515 by 510368
thanks

Hi,

In data venerdì 20 agosto 2021 13:32:08 CEST, Chris Hofstaedtler ha scritto:
> given we are now in the bookworm cycle - do you think kcoreaddons
> could remove fam (or replace it with gamin if really needed)?

As I wrote a couple of times in this bug already: #510368 must be fixed
first. It seems like I forgot to set this dependency, so I'm adding it
now.

Also, considering that there is a huge queue of RM bugs on the
FTP-masters side that have been attended so far a couple of times in
this year (sigh), rushing this won't make any change, since the RM will
be ignored for some time anyway.
Also #2: considering that we are not even a week since the lift of the
freeze and everybody and their dogs have already uploaded things of
every sort of unstable, please give (me) some time for what is really
not a priority.

Thanks,
-- 
Pino Toscano

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

Bug#992579: omnidb-server: mariadb is not supported

[Ximin Luo]

Package: omnidb-server
Version: 3.0.3b+ds-2
Severity: important

Dear Maintainer,

Despite advertising MariaDB support in the package description, this package 
does
not actually support it:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 
34, in inner
response = get_response(request)
  File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 115, 
in _get_response
response = self.process_exception_by_middleware(e, request)
  File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 113, 
in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python3/dist-packages/OmniDB_app/views/memory_objects.py", 
line 46, in wrap
return function(request, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/OmniDB_app/views/connections.py", line 
276, in test_connection
database = OmniDatabase.Generic.InstantiateDatabase(
  File 
"/usr/lib/python3/dist-packages/OmniDB_app/include/OmniDatabase/__init__.py", 
line 57, in InstantiateDatabase
return MariaDB(p_server, p_port, p_service, p_user, p_password, p_conn_id, 
p_alias, p_conn_string, p_parse_conn_string)
  File 
"/usr/lib/python3/dist-packages/OmniDB_app/include/OmniDatabase/MariaDB.py", 
line 100, in __init__
self.v_connection = Spartacus.Database.MariaDB(self.v_active_server, 
self.v_active_port, self.v_active_service, self.v_active_user, self.v_password, 
p_conn_string)
  File 
"/usr/lib/python3/dist-packages/OmniDB_app/include/Spartacus/Database.py", line 
2306, in __init__
raise Spartacus.Database.Exception("MariaDB is not supported. Please 
install it with 'pip install Spartacus[mariadb]'.")
OmniDB_app.include.Spartacus.Database.Exception: MariaDB is not supported. 
Please install it with 'pip install Spartacus[mariadb]'.

X

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

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

Versions of packages omnidb-server depends on:
ii  adduser3.118
ii  omnidb-common  3.0.3b+ds-2

omnidb-server recommends no packages.

omnidb-server suggests no packages.

-- no debconf information

Bug#992284: Please add full dmesg log

[Heiner Kallweit]

RTL8111 is a chip family, relevant is the exact chip version.  Please attach a 
full dmesg log with the r8169 driver.
Would be good if you can test with the latest mainline kernels: 5.13.12, 
5.14-rc6

Bug#992580: labplot FTFBS with nocheck build profile

[Helmut Grohne]

Source: labplot
Version: 2.8.2-1
Tags: ftbfs patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

labplot fails to build from source when built with the nocheck build
profile, because it attempts to link -lspectre, but libspectre-dev is
annotated  and thus missing. Please consider applying the
attached patch to drop the erroneous annotation.

Helmut
diff --minimal -Nru labplot-2.8.2/debian/changelog 
labplot-2.8.2/debian/changelog
--- labplot-2.8.2/debian/changelog  2021-08-16 08:45:08.0 +0200
+++ labplot-2.8.2/debian/changelog  2021-08-20 14:32:33.0 +0200
@@ -1,3 +1,10 @@
+labplot (2.8.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with nocheck build profile. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 20 Aug 2021 14:32:33 +0200
+
 labplot (2.8.2-1) unstable; urgency=medium
 
   * New upstream release:
diff --minimal -Nru labplot-2.8.2/debian/control labplot-2.8.2/debian/control
--- labplot-2.8.2/debian/control2021-08-16 07:50:46.0 +0200
+++ labplot-2.8.2/debian/control2021-08-20 14:28:10.0 +0200
@@ -33,7 +33,7 @@
  bison,
  libcantor-dev,
  libpoppler-qt5-dev (>= 19.12~),
- libspectre-dev ,
+ libspectre-dev,
  libcfitsio-dev,
  libgsl-dev,
  libnetcdf-dev,

Bug#908196: linux-image-4.9.0-8-armmp: Please set CONFIG_LEDS_PCA963X=m

[Reco]

Hi, Vincent.

On Tue, Aug 17, 2021 at 04:41:20PM +0200, Vincent Blut wrote:
> Package: src:linux
> Followup-For: Bug #908196

> Is it still worthwhile to enable this option?

IMO yes. I have the thing sitting on my desk now, it runs Debian, and it
serves its function.


> So if this router does not run on Linux 5.13+, it's probably not worth
> to enable this option.

I've just upgraded the device to bullseye, and installed
linux-image-5.13.0-trunk from the experimental on it.
I confirm that:

- the device boots successfully with that kernel.
- both LAN and WAN ports work.
- USB ports work too.

The kernel from the experimental just misses the usual:

- pca963x for WAN/WIFI leds
- wifi.

Wifi requires out of tree module anyway, and its outside of the scope of
this bug report.

Sincerely yours, Reco

Bug#989712: Bug#992578: login: please add support for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

For your convenience, I created a salsa MR that fixes #989712 as well as
#992578:

https://salsa.debian.org/debian/shadow/-/merge_requests/15

With this patch, a chroot created with DPKG_ROOT will be bit-by-bit identical
to one created normally, see
https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs

signature.asc
Description: signature

Bug#992554: service seems to start regularly but it doesn't work

[Ivan Sergio Borgonovo]

I had the same problem, downgrading made it works...

Later on I did a safe-upgrade that probably brought in some related 
library and now it is working.


[UPGRADE] e2fsprogs:amd64 1.46.2-2 -> 1.46.4-1
[UPGRADE] libcom-err2:amd64 1.46.2-2 -> 1.46.4-1
[UPGRADE] libext2fs2:amd64 1.46.2-2 -> 1.46.4-1
[UPGRADE] libgpg-error0:amd64 1.38-2 -> 1.42-2
[UPGRADE] libss2:amd64 1.46.2-2 -> 1.46.4-1
[UPGRADE] logsave:amd64 1.46.2-2 -> 1.46.4-1
[UPGRADE] node-ansi-escapes:amd64 5.0.0-1 -> 5.0.0+really.4.3.1-1
[UPGRADE] tor:amd64 0.4.5.9-1 -> 0.4.5.10-1
[UPGRADE] tor-geoipdb:amd64 0.4.5.9-1 -> 0.4.5.10-1


Probably newer libgpg-error.so.0

--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#992502: initramfs-tools: upgrade buster/bullseye fails; wrong path in /usr/share/initramfs-tools/hooks/growroot for udevadm

[Salvatore Bonaccorso]

Control: reassign -1 cloud-initramfs-growroot 0.18.debian8

On Thu, Aug 19, 2021 at 02:24:36PM +0200, Josef Dean Butler wrote:
> Package: initramfs-tools
> Version: 0.140
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> During the upgrade from buster to bullseye dpkg failed to init the RAM fs. 
> dpkg --configure -a always led to the same output:
> Selecting previously unselected package linux-image-5.10.0-8-amd64.
> (Reading database ... 51840 files and directories currently installed.)
> Preparing to unpack .../linux-image-5.10.0-8-amd64_5.10.46-4_amd64.deb ...
> Unpacking linux-image-5.10.0-8-amd64 (5.10.46-4) ...
> Selecting previously unselected package linux-image-amd64.
> Preparing to unpack .../linux-image-amd64_5.10.46-4_amd64.deb ...
> Unpacking linux-image-amd64 (5.10.46-4) ...
> Setting up linux-image-5.10.0-8-amd64 (5.10.46-4) ...
> I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.10.0-8-amd64
> I: /initrd.img.old is now a symlink to boot/initrd.img-5.10.0-8-amd64
> I: /vmlinuz is now a symlink to boot/vmlinuz-5.10.0-8-amd64
> I: /initrd.img is now a symlink to boot/initrd.img-5.10.0-8-amd64
> /etc/kernel/postinst.d/initramfs-tools:
> update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64
> E: /usr/share/initramfs-tools/hooks/growroot failed with return 1.
> update-initramfs: failed for /boot/initrd.img-5.10.0-8-amd64 with 1.
> run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
> dpkg: error processing package linux-image-5.10.0-8-amd64 (--configure):
>  installed linux-image-5.10.0-8-amd64 package post-installation script 
> subprocess returned error exit status 1
> dpkg: dependency problems prevent configuration of linux-image-amd64:
>  linux-image-amd64 depends on linux-image-5.10.0-8-amd64 (= 5.10.46-4); 
> however:
>   Package linux-image-5.10.0-8-amd64 is not configured yet.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Since the kernel panicked during reboot I had to boot an emergency 
> environment. I mounted my drives and chrooted into them. I checked, if enough 
> space was available on the SSD. I tried to re-install initramfs-tools and the 
> kernel. None helped. A friend discovered that the path for udevadm was wrong 
> in /usr/share/initramfs-tools/hooks/growroot
> . We changed it from /sbin/udevadm to /bin/udevadm and then dpkg --configure 
> -a worked wirhout errors and the new kernel was installed. A reboot brought 
> back the system to live.
> 
>* What was the outcome of this action?
> Changing the path for udevadm solved the issue completely. dpkg --configure 
> -a worked again and I could boot just fine.

The hook is shipped by the cloud-initramfs-growroot package, so
reassigning there.

Regards,
Salvatore

Bug#992004: [PATCH 0/2] UCSI race condition resulting in wrong port state

[Salvatore Bonaccorso]

Hi Greg,

On Fri, Nov 06, 2020 at 11:47:25AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Oct 28, 2020 at 10:10:43AM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Oct 09, 2020 at 04:40:45PM +0200, Benjamin Berg wrote:
> > > From: Benjamin Berg 
> > > 
> > > Hi all,
> > > 
> > > so, I kept running in an issue where the UCSI port information was saying
> > > that power was being delivered (online: 1), while no cable was attached.
> > > 
> > > The core of the problem is that there are scenarios where UCSI change
> > > notifications are lost. This happens because querying the changes that
> > > happened is done using the GET_CONNECTOR_STATUS command while clearing the
> > > bitfield happens from the separate ACK command. Any change in between will
> > > be lost.
> > > 
> > > Note that the problem may be almost invisible in the UI as e.g. GNOME will
> > > still show the battery as discharging. But some policies like automatic
> > > suspend may be applied incorrectly.
> > > 
> > > Cc: Hans de Goede 
> > > Cc: Heikki Krogerus 
> > > 
> > > Benjamin Berg (2):
> > >   usb: typec: ucsi: acpi: Always decode connector change information
> > >   usb: typec: ucsi: Work around PPM losing change information
> > 
> > Do these need to be backported to stable kernel releases?  If so, how
> > far back?
> 
> Due to the lack of response, I guess they don't need to go to any stable
> kernel, so will queue them up for 5.11-rc1.

At least one user in Debian (https://bugs.debian.org/992004) would be
happy to have those backported as well to the 5.10.y series (which we
will pick up).

So if Benjamin ack's this, this would be great to have in 5.10.y.

Regards,
Salvatore

Bug#989734: mailgraph does not start on boot

[Vincent Lefevre]

Control: reopen 989734

Hi,

On 2021-08-20 14:02:16 +0200, Jörg Frings-Fürst wrote:
> Debian 10 uses systemd as init system.
> 
> Mailgraph is disabled after installation. You must first enable
> mailgraph with:
> 
>   systemctl enable mailgraph
> 
> After that the daemon starts after boot.

Yes, but this is silly. I don't want to do that each time mailgraph
is upgraded. FYI, mailgraph was started on boot in Debian 9, and
this was no longer the case after the upgrade to Debian 10, though
systemd was already used in Debian 9 (the mailgraph version has not
changed since then).

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

Bug#992480: debianutils: Translated man pages for which(1) not handled by alternatives

[Clint Adams]

On Thu, Aug 19, 2021 at 01:23:45AM -0400, Boyuan Yang wrote:
> Thanks for managing /usr/bin/which under alternatives system. However, the
> translated man pages for which command (such as
> /usr/share/man/pl/man1/which.1.gz) are not handled by alternatives system.
> This won't cause issues in near future, but we have a possibility for file
> collision after different which(1) implementations are packaged.
> 
> Currently I don't have a good solution for it. Maybe we can think more?

If I understand the update-alternatives documentation correctly, it
won't cause a problem to add the slave links for those translations
even if your package doesn't provide them.  Do you read it differently,
or were you concerned about something else?

Bug#992523: cpio breaks perl autopkgtest on armhf and i386: realloc(): invalid next size

[Niko Tyni]

Control: reassign -1 cpio 2.13+dfsg-6

On Thu, Aug 19, 2021 at 08:40:19PM +0200, Paul Gevers wrote:
> Source: cpio, perl
> Control: found -1 cpio/2.13+dfsg-6
> Control: found -1 perl/5.32.1-5
> Severity: serious
> Tags: sid bookworm
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of cpio the autopkgtest of perl fails in testing
> when that autopkgtest is run with the binary packages of cpio from
> unstable. It passes when run with only packages from testing.

> autopkgtest [09:23:59]: test verify-configure: [---
> realloc(): invalid next size
> Aborted
> make: debian/rules: No such file or directory
> make: *** No rule to make target 'debian/rules'.  Stop.
> autopkgtest [09:24:00]: test verify-configure: ---]

That test just runs cpio in pass-through mode:

  #!/bin/sh
  mkdir $AUTOPKGTEST_TMP/source
  find . -print0 | cpio -p0d $AUTOPKGTEST_TMP/source
  cd $AUTOPKGTEST_TMP/source
  make -f debian/rules verify-configure-stamp

Can't see how perl could be at fault for cpio crashing so reassigning.
-- 
Niko

Bug#992581: vdirsyncer: Bug in systemd unit file results in continuous restarts when encountering problems in the run

[Detlev Zundel]

Package: vdirsyncer
Version: 0.16.8-2
Severity: normal

Hi,

I have acticated the provided systemd config to run vdirsyncer as a user
systemd timer:

dzu@krikkit:~$ systemctl --user cat vdirsyncer.timer
# /usr/lib/systemd/user/vdirsyncer.timer
[Unit]
Description=Synchronize vdirs

[Timer]
OnBootSec=5m
OnUnitActiveSec=15m
AccuracySec=5m

[Install]
WantedBy=timers.target
dzu@krikkit:~$

This uses the vdirsyncer.service file in
/usr/lib/systemd/user/vdirsyncer.service provided by the package without any
overrides.

The setup ran fine until the Nextcloud server it syncs against went into
maintenance mode.  Vsync then reports 503 errors that the server cannot be
reached.  In the systemd logs I then see that the process exits with
status=1/FAILURE and is immediately restarted. This log excerpt shows the good
case of running every 20 minutes and then the immediate restarts upon the
problem:

Aug 10 15:15:10 krikkit systemd[3173042]: vdirsyncer.service: Consumed 2.244s
CPU time.
Aug 10 15:35:09 krikkit systemd[3173042]: vdirsyncer.service: Succeeded.
Aug 10 15:35:09 krikkit systemd[3173042]: vdirsyncer.service: Consumed 2.163s
CPU time.
Aug 10 15:55:10 krikkit systemd[3173042]: vdirsyncer.service: Succeeded.
Aug 10 15:55:10 krikkit systemd[3173042]: vdirsyncer.service: Consumed 2.469s
CPU time.
Aug 10 16:15:07 krikkit systemd[3173042]: vdirsyncer.service: Main process
exited, code=exited, status=1/FAILURE
Aug 10 16:15:07 krikkit systemd[3173042]: vdirsyncer.service: Failed with
result 'exit-code'.
Aug 10 16:15:07 krikkit systemd[3173042]: vdirsyncer.service: Consumed 1.744s
CPU time.
Aug 10 16:15:07 krikkit systemd[3173042]: vdirsyncer.service: Scheduled restart
job, restart counter is at 1.
Aug 10 16:15:07 krikkit systemd[3173042]: vdirsyncer.service: Consumed 1.744s
CPU time.
Aug 10 16:15:09 krikkit systemd[3173042]: vdirsyncer.service: Main process
exited, code=exited, status=1/FAILURE
Aug 10 16:15:09 krikkit systemd[3173042]: vdirsyncer.service: Failed with
result 'exit-code'.
Aug 10 16:15:09 krikkit systemd[3173042]: vdirsyncer.service: Consumed 1.674s
CPU time.
Aug 10 16:15:09 krikkit systemd[3173042]: vdirsyncer.service: Scheduled restart
job, restart counter is at 2.
Aug 10 16:15:09 krikkit systemd[3173042]: vdirsyncer.service: Consumed 1.674s
CPU time.
Aug 10 16:15:11 krikkit systemd[3173042]: vdirsyncer.service: Main process
exited, code=exited, status=1/FAILURE
Aug 10 16:15:11 krikkit systemd[3173042]: vdirsyncer.service: Failed with
result 'exit-code'.
Aug 10 16:15:11 krikkit systemd[3173042]: vdirsyncer.service: Consumed 1.550s
CPU time.
Aug 10 16:15:11 krikkit systemd[3173042]: vdirsyncer.service: Scheduled restart
job, restart counter is at 3.
Aug 10 16:15:11 krikkit systemd[3173042]: vdirsyncer.service: Consumed 1.550s
CPU time.
Aug 10 16:15:13 krikkit systemd[3173042]: vdirsyncer.service: Main process
exited, code=exited, status=1/FAILURE
Aug 10 16:15:13 krikkit systemd[3173042]: vdirsyncer.service: Failed with
result 'exit-code'.
Aug 10 16:15:13 krikkit systemd[3173042]: vdirsyncer.service: Consumed 1.473s
CPU time.
Aug 10 16:15:13 krikkit systemd[3173042]: vdirsyncer.service: Scheduled restart
job, restart counter is at 4.
Aug 10 16:15:13 krikkit systemd[3173042]: vdirsyncer.service: Consumed 1.473s
CPU time.


I believe that the "Restart=on-failure" in the unit file is responsible for
that behavior.  I actually do not understand the intention of this statement
for vdirsyncer at all.

In the case I showed above, the reruns were "harmless" because the target host
was not reachable but I also encountered a situation where vdirsyncer exited
after syncing all the sources like this:

Aug 10 22:34:09 krikkit vdirsyncer[2202152]: Syncing dzu_contacts/z-app-
generated--contactsinteraction--recent
Aug 10 22:34:10 krikkit vdirsyncer[2202152]: error: dzu_contacts/z-app-
generated--contactsinteraction--recent: Storage "dzu_contacts_remote/z-app-
generated--contactsinteraction--recent" was completely emptied. If you want to
delete ALL entries on BOTH sides, then use>
Aug 10 22:34:13 krikkit vdirsyncer[2202152]: error: 1 out of 14 tasks failed.
Aug 10 22:34:13 krikkit systemd[3173042]: vdirsyncer.service: Main process
exited, code=exited, status=1/FAILURE
Aug 10 22:34:13 krikkit systemd[3173042]: vdirsyncer.service: Failed with
result 'exit-code'.
Aug 10 22:34:13 krikkit systemd[3173042]: vdirsyncer.service: Consumed 2.244s
CPU time.
Aug 10 22:34:13 krikkit systemd[3173042]: vdirsyncer.service: Scheduled restart
job, restart counter is at 2.
Aug 10 22:34:13 krikkit systemd[3173042]: Stopped Synchronize calendars and
contacts.
Aug 10 22:34:13 krikkit systemd[3173042]: vdirsyncer.service: Consumed 2.244s
CPU time.
Aug 10 22:34:13 krikkit systemd[3173042]: Started Synchronize calendars and
contacts.


In this case vdirsyncer was running continuously and produced a lot of network
traffic.  I was actually only finding this problem because my network provider
sent me a traffic warning as vdirsyncer produced ~4GB of

Bug#989734: mailgraph does not start on boot

[Jörg Frings-Fürst]

Hi,

Am Freitag, dem 20.08.2021 um 14:59 +0200 schrieb Vincent Lefevre:
> Control: reopen 989734
> 
> Hi,
> 
> On 2021-08-20 14:02:16 +0200, Jörg Frings-Fürst wrote:
> > Debian 10 uses systemd as init system.
> > 
> > Mailgraph is disabled after installation. You must first enable
> > mailgraph with:
> > 
> >   systemctl enable mailgraph
> > 
> > After that the daemon starts after boot.
> 
> Yes, but this is silly. I don't want to do that each time mailgraph
> is upgraded. FYI, mailgraph was started on boot in Debian 9, and
> this was no longer the case after the upgrade to Debian 10, though
> systemd was already used in Debian 9 (the mailgraph version has not
> changed since then).
> 

The "systemctl enable mailgraph" must only run one time after
installation. Then the mailgraph daemon starts every time after boot.



-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#992335: shim-helpers-amd64-signed: grub install: error: failed to register the EFI boot entry, no space left on device

[Steve McIntyre]

Control: reassign -1 grub-efi-amd64

Hi wim,

On Tue, Aug 17, 2021 at 03:22:49PM +0200, wim wrote:
>Package: shim-helpers-amd64-signed
>Version: 1+15.4+5~deb10u1
>Severity: normal
>
>Hello,
>
>This is the setup:

OK, this is a problem being reported by grub-install, called by
shim-helpers-amd64-signed as it's installed. Reassigning to one of the
grub packages.

># df -h
>BestandssysteemGrootte Gebruikt Besch Geb% 
>Aangekoppeld op
>udev   32G0   32G   0% /dev
>tmpfs 6,3G  13M  6,3G   1% /run
>/dev/mapper/root_ssd-lv_root_ssd_crypt1,9T 1,6T  152G  92% /
>tmpfs  32G  92K   32G   1% /dev/shm
>tmpfs 5,0M 4,0K  5,0M   1% /run/lock
>tmpfs  32G0   32G   0% 
>/sys/fs/cgroup
>/dev/loop0165M 165M 0 100% 
>/snap/gnome-3-28-1804/161
>/dev/loop1100M 100M 0 100% 
>/snap/core/11316
>/dev/nvme1n1p1504M 368M  112M  77% /boot
>/dev/loop2 72M  72M 0 100% 
>/snap/carnet/15
>/dev/nvme0n1p1511M  49M  463M  10% /boot/efi
>/dev/loop4159M 159M 0 100% 
>/snap/codium/166
>/dev/loop3163M 163M 0 100% 
>/snap/gnome-3-28-1804/145
>/dev/loop6 56M  56M 0 100% 
>/snap/core18/2128
>/dev/loop5 56M  56M 0 100% 
>/snap/core18/2074
>/dev/loop8100M 100M 0 100% 
>/snap/core/11420
>/dev/loop7 66M  66M 0 100% 
>/snap/gtk-common-themes/1515
>/dev/loop9151M 151M 0 100% 
>/snap/codium/162
>/dev/loop10   128K 128K 0 100% 
>/snap/hello-world/29
>/dev/loop1165M  65M 0 100% 
>/snap/gtk-common-themes/1514
>/dev/loop1242G  42G 0 100% 
>/home/wim/ucll/zolder_gt
>/dev/loop1372M  72M 0 100% 
>/snap/carnet/16
>/dev/sdb1 3,6T 3,2T  307G  92% 
>/mnt/terra_1_5_story
>/dev/mapper/data_1T   856G 254G  558G  32% /data_1T
>tmpfs 6,3G  64K  6,3G   1% 
>/run/user/1000
>/dev/mmcblk0p13,7G  64K  3,7G   1% 
>/media/wim/MICROSD
>/dev/sr0   88M  88M 0 100% 
>/media/wim/20190318_164558
>
>So /boot/efi and /boot have free space

Nod. The problem is that your system is failing to create/update an
EFI boot variable in its NVRAM. The most common issue that causes this
is system log reports in /sys/fs/pstore/ . Could you check and see if
there are any files there please?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

Bug#992582: docker.io: Little problem in the dockerd-rootless-setuptool.sh script prevents successful rootless setup

[Igor Torrente]

Package: docker.io
Version: 20.10.5+dfsg1-1+b5
Severity: important
Tags: patch upstream

Dear maintainers,

I found a little issue in the dockerd-rootless-setuptool.sh installation script.
The fix (or workaround) will be sent in this email.

AFAIK this script is based on the official docker script. But the original 
script assumes
that the docker binary will be in the same folder as the dockerd-rootless.sh.
And this is not the case in the Debian package.

Here is my patch to solve this problem

--- /usr/share/docker.io/contrib/dockerd-rootless-setuptool.sh  2021-08-20 
10:08:53.200580743 -0300
+++ /usr/share/docker.io/contrib/dockerd-rootless-setuptool.sh  2021-08-20 
10:15:46.489616241 -0300
@@ -55,12 +55,13 @@
exit 1
fi
 
-   # set BIN
-   if ! BIN="$(command -v "$DOCKERD_ROOTLESS_SH" 2> /dev/null)"; then
+   # set BIN and ROOTLESS_BIN
+   if ! ROOTLESS_BIN="$(command -v "$DOCKERD_ROOTLESS_SH" 2> /dev/null)"; 
then
ERROR "$DOCKERD_ROOTLESS_SH needs to be present under \$PATH"
exit 1
fi
-   BIN=$(dirname "$BIN")
+   ROOTLESS_BIN=$(dirname "$ROOTLESS_BIN")
+   BIN="/usr/bin/"
 
# set SYSTEMD
if systemctl --user show-environment > /dev/null 2>&1; then
@@ -294,7 +295,7 @@
 
[Service]
Environment=PATH=$BIN:/sbin:/usr/sbin:$PATH
-   ExecStart=$BIN/dockerd-rootless.sh 
$DOCKERD_ROOTLESS_SH_FLAGS
+   ExecStart=$ROOTLESS_BIN/dockerd-rootless.sh 
$DOCKERD_ROOTLESS_SH_FLAGS
ExecReload=/bin/kill -s HUP \$MAINPID
TimeoutSec=0
RestartSec=2

I also had a problem with kernel modules, so I had to add them manually. I'm 
not sure how useful 
they would be in other types of installation, but Maybe worth add them to the 
installation script.

--- /dev/null   2021-08-20 08:47:56.012087970 -0300
+++ /etc/modprobe.d/overlay.conf2021-08-19 19:35:17.535171578 -0300
@@ -0,0 +1,2 @@
+# Debian-specific kernel patch, introduced in Debian 10 to the overlay2 
storage driver
+options overlay permit_mounts_in_userns=1

---  /etc/modules-load.d/modules.con2021-08-20 10:25:11.522661268 -0300
+++ /etc/modules-load.d/modules.conf2021-08-19 19:41:25.866695920 -0300
@@ -2,3 +2,4 @@
 #
 # This file contains the names of kernel modules that should be loaded
 # at boot time, one per line. Lines beginning with "#" are ignored.
+br_netfilter


Thanks for your attention,

Igor M. A. Torrente


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

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

Versions of packages docker.io depends on:
ii  adduser  3.118
ii  containerd   1.4.5~ds1-2
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-13
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libsystemd0  247.3-6
ii  lsb-base 11.1.0
ii  runc 1.0.0~rc93+ds1-5+b2
ii  tini 0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 2.13.6-10
ii  ca-certificates  20210119
ii  cgroupfs-mount   1.4
ii  git  1:2.30.2-1
ii  needrestart  3.5-4
ii  xz-utils 5.2.5-2

Versions of packages docker.io suggests:
pn  aufs-tools 
pn  btrfs-progs
pn  debootstrap
pn  docker-doc 
ii  e2fsprogs  1.46.2-2
pn  rinse  
ii  rootlesskit0.14.2-1+b3
ii  xfsprogs   5.10.0-4
pn  zfs-fuse | zfsutils-linux  

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/share/docker.io/contrib/dockerd-rootless-setuptool.sh (from docker.io 
package)

Bug#992335: shim-helpers-amd64-signed: grub install: error: failed to register the EFI boot entry, no space left on device

[Wim Bertels]

Steve McIntyre schreef op vr 20-08-2021 om 14:29 [+0100]:
> Control: reassign -1 grub-efi-amd64
> 
> Hi wim,
> 
> On Tue, Aug 17, 2021 at 03:22:49PM +0200, wim wrote:
> > Package: shim-helpers-amd64-signed
> > Version: 1+15.4+5~deb10u1
> > Severity: normal
> > 
> > Hello,
> > 
> > This is the setup:
> 
> OK, this is a problem being reported by grub-install, called by
> shim-helpers-amd64-signed as it's installed. Reassigning to one of
> the
> grub packages.
> 
> > # df -h
> > BestandssysteemGrootte Gebruikt Besch Geb%
> > Aangekoppeld op
> > udev   32G0   32G   0%
> > /dev
> > ..
> > /dev/mmcblk0p13,7G  64K  3,7G   1%
> > /media/wim/MICROSD
> > /dev/sr0   88M  88M 0 100%
> > /media/wim/20190318_164558
> > 
> > So /boot/efi and /boot have free space
> 
> Nod. The problem is that your system is failing to create/update an
> EFI boot variable in its NVRAM. The most common issue that causes
> this
> is system log reports in /sys/fs/pstore/ . Could you check and see if
> there are any files there please?

Yes, there are many files, all from 'nov 7 2019' which could be the
installation date.

# ls /sys/fs/pstore/ -altr
totaal 0
-r--r--r-- 1 root root 1799 nov  7  2019 dmesg-efi-157315250037001
-r--r--r-- 1 root root 1799 nov  7  2019 dmesg-efi-157315250036001
-r--r--r-- 1 root root 1800 nov  7  2019 dmesg-efi-157315250035002
-r--r--r-- 1 root root 1799 nov  7  2019 dmesg-efi-157315250035001
-r--r--r-- 1 root root 1800 nov  7  2019 dmesg-efi-157315250034002

An example of the content, most of them about nouveau:

# cat  /sys/fs/pstore/dmesg-efi-157332678916001 
Oops#1 Part16
<4>[  105.363372]  ? __switch_to+0x7a/0x3e0
<4>[  105.363373]  ? __switch_to_asm+0x34/0x70
<4>[  105.363374]  pm_runtime_work+0x82/0x90
<4>[  105.363375]  process_one_work+0x1a7/0x3b0
<4>[  105.363375]  worker_thread+0x30/0x390
<4>[  105.363376]  ? create_worker+0x1a0/0x1a0
<4>[  105.363377]  kthread+0x112/0x130
<4>[  105.363378]  ? __kthread_parkme+0x70/0x70
<4>[  105.363378]  ret_from_fork+0x1f/0x40
<4>[  105.363379] ---[ end trace b62441a5f9a44a7c ]---
<2>[  105.364066] nouveau :01:00.0: tmr: stalled at 
<4>[  105.364067] [ cut here ]
<4>[  105.364067] nouveau :01:00.0: timeout
<4>[  105.364096] WARNING: CPU: 5 PID: 557 at 
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmtu102.c:47 
tu102_vmm_flush+0x128/0x140 [nouveau]
<4>[  105.364097] Modules linked in: nls_utf8 isofs fuse ctr ccm rfcomm cmac 
snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core 
snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress arc4 iwlmvm 
intel_rapl mac80211 bnep iwlwifi btusb btrtl btbcm btintel bluetooth cfg80211 
drbg ansi_cprng ecdh_generic hp_wmi ecc sparse_keymap snd_hda_codec_hdmi 
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_codec_realtek 
kvm nls_ascii nls_cp437 snd_hda_codec_generic vfat irqbypass efi_pstore fat 
ledtrig_audio intel_cstate snd_usb_audio uvcvideo snd_hda_intel cdc_ether 
videobuf2_vmalloc usbnet videobuf2_memops snd_hda_codec intel_uncore 
videobuf2_v4l2 videobuf2_common snd_usbmidi_lib r8152 snd_rawmidi snd_hda_core 
snd_seq_device mii intel_rapl_perf efivars videodev snd_hwdep joydev 
rtsx_pci_ms iTCO_wdt snd_pcm mei_me iTCO_vendor_support serio_raw 
intel_wmi_thunderbolt pcspkr watchdog wmi_bmof pcc_cpufreq tpm_crb memstick sg 
usblp media snd_timer rfkill mei

The ones that are not:

# cat $(grep -L nouv * )
Oops#1 Part2
<4>[  200.823189] RDX: 0029 RSI: 00b4 RDI: 
c03e
<4>[  200.823190] RBP: aa238675bd98 R08:  R09: 

<4>[  200.823191] R10:  R11:  R12: 

<4>[  200.823192] R13: 7fff R14: 9530e3ea83c0 R15: 

<4>[  200.823193]  ? common_interrupt+0xa/0xf
<4>[  200.823195]  ? __bpf_prog_run32+0x39/0x60
<4>[  200.823196]  ? __seccomp_filter+0x6a/0x680
<4>[  200.823198]  ? __seccomp_filter+0x7a/0x680
<4>[  200.823199]  ? devkmsg_read+0x73/0x2c0
<4>[  200.823200]  ? devkmsg_read+0x165/0x2c0
<4>[  200.823202]  ? syscall_trace_enter+0x192/0x2b0
<4>[  200.823204]  ? do_syscall_64+0x104/0x130
<4>[  200.823205]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
<4>[  200.823206] Modules linked in: snd_soc_skl snd_soc_skl_ipc 
snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_acpi_intel_match 
snd_soc_acpi snd_soc_core snd_compress arc4 intel_rapl iwlmvm mac80211 btusb 
snd_hda_codec_hdmi btrtl btbcm btintel bluetooth uvcvideo x86_pkg_temp_thermal 
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 iwlwifi snd_hda_codec_realtek 
videobuf2_common intel_powerclamp videodev coretemp snd_hda_codec_generic 
kvm_intel ledtrig_audio cfg80211 snd_hda_intel snd_hda_codec snd_hda_core 
snd_hwdep snd_pcm rtsx_pci_ms memstick media kvm snd_timer 
processor_thermal_device intel_s

Bug#992335: shim-helpers-amd64-signed: grub install: error: failed to register the EFI boot entry, no space left on device

[Steve McIntyre]

On Fri, Aug 20, 2021 at 03:40:48PM +0200, Wim Bertels wrote:
>Steve McIntyre schreef op vr 20-08-2021 om 14:29 [+0100]:
>> 
>> Nod. The problem is that your system is failing to create/update an
>> EFI boot variable in its NVRAM. The most common issue that causes
>> this
>> is system log reports in /sys/fs/pstore/ . Could you check and see if
>> there are any files there please?
>
>Yes, there are many files, all from 'nov 7 2019' which could be the
>installation date.
>
># ls /sys/fs/pstore/ -altr
>totaal 0
>-r--r--r-- 1 root root 1799 nov  7  2019 dmesg-efi-157315250037001
>-r--r--r-- 1 root root 1799 nov  7  2019 dmesg-efi-157315250036001
>-r--r--r-- 1 root root 1800 nov  7  2019 dmesg-efi-157315250035002
>-r--r--r-- 1 root root 1799 nov  7  2019 dmesg-efi-157315250035001
>-r--r--r-- 1 root root 1800 nov  7  2019 dmesg-efi-157315250034002
>
>An example of the content, most of them about nouveau:

OK, that's junk that you can simply delete. If you do that, things
should clear up for you. Depending on the firmware of your computer
(and its handling of EFI variables), you *might* need to reboot for
the space to free up completely. In that case, I'd recomment that you
have an installer USB (or similar) handy just in case things don't
boot.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Arguing that you don't care about the right to privacy because you have
 nothing to hide is no different than saying you don't care about free
 speech because you have nothing to say."
   -- Edward Snowden

Bug#989734: mailgraph does not start on boot

[Vincent Lefevre]

On 2021-08-20 15:28:45 +0200, Jörg Frings-Fürst wrote:
> Am Freitag, dem 20.08.2021 um 14:59 +0200 schrieb Vincent Lefevre:
> > Yes, but this is silly. I don't want to do that each time mailgraph
> > is upgraded. FYI, mailgraph was started on boot in Debian 9, and
> > this was no longer the case after the upgrade to Debian 10, though
> > systemd was already used in Debian 9 (the mailgraph version has not
> > changed since then).
> 
> The "systemctl enable mailgraph" must only run one time after
> installation. Then the mailgraph daemon starts every time after boot.

Then how can you explain that the upgrade from Debian 9 to
Debian 10 broke that?

I recall that mailgraph was *already* enabled before the upgrade
to Debian 10.

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

Bug#988172: libgss3: please add Breaks+Replaces: libgss0

[Simon Josefsson]

Hi, and thanks for the report, and I'm sorry I failed to fix this
before bullseye.  I believe the proper fix is to build with --with-po-
suffix so that the po files are called gss3.po in libgss-dev, instead
of gss.po which caused the conflict you noticed.  The --with-po-suffix
parameter was mistakenly dropped in 1.0.3-5 which also explains why
this happened now rather many years ago.

I'm fixing this for unstable/testing with a new upload.  I'm thinking
whether we also want to fix this in bullseye?  Maybe a propsed-update
upload?  I have never done an upload like that, so I don't know what
the requirements and restrictions are for fixes to a stable release. 
It does seem to make sense though, since it helps to fix multi-release
upgrade paths.

My upload now doesn't resolve why libgss0 is installed after a long-
time upgrade cycle like yours.  I'm not sure that is incorrect: having
libgss0 installed (even when libgss3 is installed) is fine and
shouldn't cause problems.  Are packages required to make sure old
obsolete packages are removed?  If so, is a Replaces: libgss0 on
libgss3 sufficient?  What do you think?

/Simon

Bug#992583: 'chown' example program returns success but file ownership not changed

[Dominique Brazziel]

Package: manpages-devVersion: 5.10-1Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
   * What led up to the situation?Compiling and running the example program   * 
What exactly did you do (or not do) that was effective (or     ineffective)?Ran 
the program passing valid UID as argument
   * What was the outcome of this action?The file owner was not changed to the 
user specified
   * What outcome did you expect instead?File owner changed to specified 
argument.
*** End of the template - remove these template lines ***

-- System Information:Debian Release: 11.0  APT prefers testing  APT policy: 
(990, 'testing'), (500, 'stable-security'), (500, 'unstable')Architecture: 
amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)Kernel taint flags: 
TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not setShell: /bin/sh linked to /bin/dashInit: 
systemd (via /run/systemd/system)LSM: AppArmor: enabled
Versions of packages manpages-dev depends on:ii  manpages  5.10-1
manpages-dev recommends no packages.
Versions of packages manpages-dev suggests:ii  man-db [man-browser]  2.9.4-2
-- no debconf information

Bug#992584: URL for upstream project should be updated

[Camaleón]

Package: connman
Version: 1.36-22
Severity: minor

Hello,

It seems the original Intel's forge no longer works¹ (it displays a 
404 error), thus URL of the project should be updated to a working one² 
on Debian's package frontend (external resources homepage)³.

¹https://01.org/connman
²https://git.kernel.org/pub/scm/network/connman/connman.git/
³https://packages.debian.org/sid/connman

Greetings,
-- 
Camaleón 

Bug#992538: libpam0g: Syntax error in postinst, breaking package install

[Sam Hartman]

Paul> The VCS repository for this package unfortunately is at
Paul> 1.4.0-1, while 1.4.0-9 is shipped with Bullseye. Could you
Paul> please update the repository in question?

The current commits are at https://salsa.debian.org/hartmans/pam
and a merge request asking for these to be merged into the official
packaging repo is at
https://salsa.debian.org/vorlon/pam/-/merge_requests/5


I don'th need a merge request to fix this.
My apologies that neither I nor my code reviewer caught the issue.

I'll prepare an update to Debian 11 and to unstable.

Bug#992335: shim-helpers-amd64-signed: grub install: error: failed to register the EFI boot entry, no space left on device

[Wim Bertels]

Steve McIntyre schreef op vr 20-08-2021 om 14:50 [+0100]:
> On Fri, Aug 20, 2021 at 03:40:48PM +0200, Wim Bertels wrote:
> > Steve McIntyre schreef op vr 20-08-2021 om 14:29 [+0100]:
> > > Nod. The problem is that your system is failing to create/update
> > > an
> > > EFI boot variable in its NVRAM. The most common issue that causes
> > > this
> > > is system log reports in /sys/fs/pstore/ . Could you check and
> > > see if
> > > there are any files there please?
> > 
> > Yes, there are many files, all from 'nov 7 2019' which could be the
> > installation date.
> > 
> > # ls /sys/fs/pstore/ -altr
> > totaal 0
> > -r--r--r-- 1 root root 1799 nov  7  2019 dmesg-efi-157315250037001
> > -r--r--r-- 1 root root 1799 nov  7  2019 dmesg-efi-157315250036001
> > -r--r--r-- 1 root root 1800 nov  7  2019 dmesg-efi-157315250035002
> > -r--r--r-- 1 root root 1799 nov  7  2019 dmesg-efi-157315250035001
> > -r--r--r-- 1 root root 1800 nov  7  2019 dmesg-efi-157315250034002
> > 
> > An example of the content, most of them about nouveau:
> 
> OK, that's junk that you can simply delete. If you do that, things
> should clear up for you. Depending on the firmware of your computer
> (and its handling of EFI variables), you *might* need to reboot for
> the space to free up completely. In that case, I'd recomment that you
> have an installer USB (or similar) handy just in case things don't
> 
> boot.
> 

ok, emptied it(, without rebooting)

/sys/fs/pstore# rm dmesg-efi-1573*

That seemed to do trick, --configure gives no errors, just reporting
this, in case the system doesn't reboot (password for eufi change was
asked)

# dpkg --configure shim-helpers-amd64-signed
Instellen van shim-helpers-amd64-signed (1+15.4+5~deb10u1) ...
Installeren voor x86_64-efi-platform.
Installatie is afgerond. Er werden geen fouten gerapporteerd.
# dpkg --configure shim-signed
Instellen van shim-signed:amd64 (1.36~1+deb10u2+15.4-5~deb10u1) ...
Installeren voor x86_64-efi-platform.
Installatie is afgerond. Er werden geen fouten gerapporteerd.

hth,
Wim

Bug#992585: pluto crashes during connection setup (IKEv2, x509)

[Phil Nightowl]

Package: libreswan
Version: 3.27-6+deb10u1

Pluto crashes reproducibly when negotiating tunnel type connection on 
the responder side.

I am not a developer, so when requesting further debugging, please send 
also brief instructions on how to obtain the necessary information. I 
will be happy to help, at least to the extent I am capable of.

In the pluto log, the following appears immediately before pluto crashes:

Aug 20 12:30:05 responder pluto[23155]: | emitting length of IKEv2 Certificate 
Payload: 2386
Aug 20 12:30:05 responder pluto[23155]: | CHILD SA proposals received
Aug 20 12:30:05 responder pluto[23155]: | going to assemble AUTH payload
Aug 20 12:30:05 responder pluto[23155]: | next payload type: setting 'IKEv2 
Certificate Payload'.'next payload type' to IKEv2 Authentication Payload 
(39:ISAKMP_NEXT_v2AUTH)
Aug 20 12:30:05 responder pluto[23155]: | *emit IKEv2 Authentication 
Payload:
Aug 20 12:30:05 responder pluto[23155]: |next payload type: 
ISAKMP_NEXT_v2SA (0x21)
Aug 20 12:30:05 responder pluto[23155]: |flags: none (0x0)
Aug 20 12:30:05 responder pluto[23155]: |auth method: IKEv2_AUTH_RSA (0x1)
Aug 20 12:30:05 responder pluto[23155]: | next payload type: saving payload 
location 'IKEv2 Authentication Payload'.'next payload type'
Aug 20 12:30:05 responder pluto[23155]: | started looking for secret for C=CC, 
O=Mynet, CN=responder.mynet->C=CC, O=Mynet, CN=initiator.mynet of kind PKK_RSA
Aug 20 12:30:05 responder pluto[23155]: | searching for certificate 
PKK_RSA:AwEAAcC9U vs PKK_RSA:AwEAAcC9U
Aug 20 12:30:07 responder pluto[23155]: | emitting 1024 raw bytes of rsa 
signature into IKEv2 Authentication Payload
Aug 20 12:30:07 responder pluto[23155]: | rsa signature   *  *  *  *   *  *  *  
*   *  *  *  *   *  *  *  *
Aug 20 12:30:07 responder pluto[23155]: | rsa signature  . . .

...

Aug 20 12:30:07 responder systemd[1]: ipsec.service: Main process exited, 
code=killed, status=11/SEGV
Aug 20 12:30:07 responder pluto[23155]: | rsa signature   *  *  *  *   *  *  *  
*   *  *  *  *   *  *  *  *

...

Aug 20 12:30:07 responder pluto[23155]: | rsa signature   *  *  *  *   *  *  *  
*   *  *  *  *   *  *  *  *
Aug 20 12:30:07 responder pluto[23155]: | emitting length of IKEv2 
Authentication Payload: 1032
Aug 20 12:30:07 responder pluto[23155]: | TS: parse initiator traffic selectors
Aug 20 12:30:07 responder pluto[23155]: | ***parse IKEv2 Traffic Selector:
Aug 20 12:30:07 responder pluto[23155]: |TS type: IKEv2_TS_IPV4_ADDR_RANGE 
(0x7)
Aug 20 12:30:07 responder pluto[23155]: |IP Protocol ID: 0 (0x0)
Aug 20 12:30:07 responder pluto[23155]: |length: 16 (0x10)
Aug 20 12:30:07 responder pluto[23155]: |start port: 0 (0x0)
Aug 20 12:30:07 responder pluto[23155]: |end port: 65535 (0x)
Aug 20 12:30:07 responder pluto[23155]: | parsing 4 raw bytes of IKEv2 Traffic 
Selector into ipv4 ts low
Aug 20 12:30:07 responder pluto[23155]: | ipv4 ts low  0a 00 00 00
Aug 20 12:30:07 responder pluto[23155]: | parsing 4 raw bytes of IKEv2 Traffic 
Selector into ipv4 ts high
Aug 20 12:30:07 responder pluto[23155]: | ipv4 ts high  0a 00 00 ff
Aug 20 12:30:07 responder pluto[23155]: | TS: parse responder traffic selectors
Aug 20 12:30:07 responder pluto[23155]: | ***parse IKEv2 Traffic Selector:
Aug 20 12:30:07 responder pluto[23155]: |TS type: IKEv2_TS_IPV4_ADDR_RANGE 
(0x7)
Aug 20 12:30:07 responder pluto[23155]: |IP Protocol ID: 0 (0x0)
Aug 20 12:30:07 responder pluto[23155]: |length: 16 (0x10)
Aug 20 12:30:07 responder pluto[23155]: |start port: 0 (0x0)
Aug 20 12:30:07 responder pluto[23155]: |end port: 65535 (0x)
Aug 20 12:30:07 responder pluto[23155]: | parsing 4 raw bytes of IKEv2 Traffic 
Selector into ipv4 ts low
Aug 20 12:30:07 responder pluto[23155]: | ipv4 ts low  b9 63 b1 ad
Aug 20 12:30:07 responder pluto[23155]: | parsing 4 raw bytes of IKEv2 Traffic 
Selector into ipv4 ts high
Aug 20 12:30:07 responder pluto[23155]: | ipv4 ts high  b9 63 b1 ad
Aug 20 12:30:07 responder pluto[23155]: |   ikev2_evaluate_connection_fit 
evaluating our conn="office" I=ini.tia.tor.pub/32:0/0 R=res.pon.der.0/24:0/0  
to their:
Aug 20 12:30:07 responder pluto[23155]: | 
tsi[0]=ini.tia.tor.0-ini.tia.tor.255 proto=0 portrange 0-65535, 
tsr[0]=res.pon.der.pub-res.pon.der.pub proto=0 portrange 0-65535
Aug 20 12:30:07 responder pluto[23155]: | prefix fitness rejected c office 
c->name
Aug 20 12:30:07 responder pluto[23155]: | find_host_pair: comparing 
res.pon.der.priv:500 to 0.0.0.0:500
Aug 20 12:30:07 responder pluto[23155]: | find_host_pair: comparing 
res.pon.der.priv:500 to ini.tia.tor.pub:500
Aug 20 12:30:07 responder pluto[23155]: |   checking hostpair res.pon.der.0/24 
-> ini.tia.tor.pub/32 is found
Aug 20 12:30:07 responder pluto[23155]: |match_id a=C=CC, O=Mynet, 
CN=initiator.mynet
Aug 20 12:30:07 responder pluto[23155]: | b=C=CC, O=Mynet, 
CN=initiator.mynet
Aug 20 12:30:07 responder pluto[23155]: |results  matched
Aug 20 12:30:07 resp

Bug#992554: not really a libgpg-error0 problem

[Ivan Sergio Borgonovo]

Even if after upgrade of libgpg-error0 newer version of tor seemed to 
work... after a reboot it stopped working again.


Downgrading to 0.4.5.9-1, this time even without downgrading 
libgpg-error0, makes it work again.


--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#992586: rails: CVE-2021-22942: Possible Open Redirect in Host Authorization Middleware

[Salvatore Bonaccorso]

Source: rails
Version: 2:6.0.3.7+dfsg-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rails.

CVE-2021-22942[0]:
| Possible Open Redirect in Host Authorization Middleware

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-22942
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22942
[1] https://www.openwall.com/lists/oss-security/2021/08/20/1

Regards,
Salvatore

Bug#991972: More information

[Tomas Pospisek]

So I'm not sure what to do about this ticket.

The current situation is:

* we have backports.org - which does *not* belong to Debian
* when accessing it, some variations of the URL get forwarded to
  https://backports.debian.org/ and some break in various way

My opinion on this is: let's let the backports.org URL die or be broken 
like it is. If people notice then let them manually switch the URL they 
use to https://backports.debian.org/.


*t

On Sun, 15 Aug 2021, Xan Charbonnet wrote:


Sorry, I should have checked this on more than one browser before reporting.

For some reason my ancient Firefox profile, when I browse to "backports.org", 
redirects to https://www.backports.org/.  Perhaps this was a cached permanent 
redirect, or something to do with HSTS.


On a naive profile (with seemingly any browser), browsing to "backports.org" 
fails, because backports.org has no A record.  Not terribly friendly but not 
a problem.  It sounds like your browser has some memory that points 
backports.org to backports.debian.org.  A naive browser has no way to return 
anything for https://backports.org/ or http://backports.org/.


www.backports.org does have a CNAME record: it points to 
backports.debian.org, which seems to have the same IP address as debian.org. 
Browsing to http://www.backports.org/ is successful: the Debian webserver 
redirects the request to https://backports.debian.org/, and when accessed via 
that name, the Debian webserver correctly serves the backports page.


However, when you browse to https://www.backports.org/ (note the secure 
protocol), that's when it breaks.  The Debian webserver defaults to serving 
the Debian homepage, complete with the TLS certificate for debian.org.  This 
causes a nasty security error in the browser, and if bypassed, results in the 
Debian homepage loading at https://www.backports.org/ rather than the 
Backports page.


The only remaining mystery is why my Firefox profile is handling 
"backports.org" the way it is.  I'm trying to figure out how to diagnose 
that, but it doesn't seem like there's much visibility to that kind of thing. 
It could be something that affects everybody who visited backports.org during 
a particular timeframe.


--
To unsubscribe, send mail to 991972-unsubscr...@bugs.debian.org.

Bug#992486: docker.io: cgroup v2 defaults break rootless container start & build

[Shengjing Zhu]

On Fri, Aug 20, 2021 at 12:40 PM Forest  wrote:
>
> On Fri, 20 Aug 2021 12:09:34 +0800, Shengjing Zhu wrote:
>
> >This one looks almost same:
> >
> >https://github.com/opencontainers/runc/issues/3124
>
> Hm... The conditions in that issue are different (my /proc is not mounted
> with a hidepid option) but yes, the docker error message looks similar.
>
> >Could you try command like:
> >
> >  busctl --user --no-pager status
>
> $ busctl --user --no-pager status
> Failed to connect to bus: No such file or directory
>
> When I run it again with strace, I see this system call failing:
>
> connect(3, {sa_family=AF_UNIX, sun_path="/run/user/[UID]/bus"}, 21) = -1
> ENOENT (No such file or directory)
>
> The /run/user/[UID]/ directory does exist, both for the current user and
> other users, but they do not contain a file named "bus".  Perhaps because
> this is a headless server with no desktop sessions at all?
>
> >Also as it's likely upstream issue, could you try Docker Inc's rootless 
> >binaries?
>
> I'm afraid I cannot. The policy for this machine is only to run binaries
> from debian or built locally.
>
> However, if runc assumes the presence of /run/user/$uid/bus, that does seem
> likely to be a problem, does it not?

Yes. The default mode, which is using systemd to setup cgroup, requires dbus.
So you need to install dbus-user-session, which will provide /run/user/$uid/bus.

Or you can use cgroupfs mode, which is mentioned in your first mail,
as a workaround.

-- 
Shengjing Zhu

Bug#992573: libgpg-error relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5'

[Simon McVittie]

Control: severity -1 grave

On Fri, 20 Aug 2021 at 13:41:17 +0200, Simon Josefsson wrote:
> /usr/bin/ld: 
> /usr/lib/x86_64-linux-gnu/libgpg-error.a(libgpg_error_la-estream.o): warning: 
> relocation against `stdin@@GLIBC_2.2.5' in read-only section `.text'
> /usr/bin/ld: 
> /usr/lib/x86_64-linux-gnu/libgpg-error.a(libgpg_error_la-init.o): relocation 
> R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when 
> making a shared object; recompile with -fPIC

I can reproduce a similar failure when trying to build ostree.

In testing:

$ ls -l /usr/lib/x86_64-linux-gnu/libgpg-error.so
lrwxrwxrwx 1 root root 39 Jul  1  2020 
/usr/lib/x86_64-linux-gnu/libgpg-error.so -> 
/lib/x86_64-linux-gnu/libgpg-error.so.0

In unstable, it's a broken link on non-merged-/usr systems (which includes
all official buildd chroots):

$ ls -l /usr/lib/x86_64-linux-gnu/libgpg-error.so
lrwxrwxrwx 1 root root 22 Aug 20 01:47 
/usr/lib/x86_64-linux-gnu/libgpg-error.so -> libgpg-error.so.0.32.0

This appears to have been caused by trying to fix the Lintian breakout-link
warning, which is an endless source of false-positives[1][2], in commit
7c408ba0[3].

For now, please revert that commit. I can NMU with a revert if necessary?

Thanks,
smcv

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968525
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971707
[3] 
https://salsa.debian.org/debian/libgpg-error/-/commit/7c408ba0968c14492b6f087c57c6d44af4878de6

Bug#930281: Fixed?

[Kartik Mistry]

Hi,

Just wanted to check if this bug[1] is fixed in the latest version of
recoll? If yes, we can close it.

Thanks!

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

-- 
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com

Bug#992582: docker.io: Little problem in the dockerd-rootless-setuptool.sh script prevents successful rootless setup

[Shengjing Zhu]

On Fri, Aug 20, 2021 at 9:39 PM Igor Torrente  wrote:
>
> Package: docker.io
> Version: 20.10.5+dfsg1-1+b5
> Severity: important
> Tags: patch upstream
>
> Dear maintainers,
>
> I found a little issue in the dockerd-rootless-setuptool.sh installation 
> script.
> The fix (or workaround) will be sent in this email.
>
> AFAIK this script is based on the official docker script. But the original 
> script assumes
> that the docker binary will be in the same folder as the dockerd-rootless.sh.
> And this is not the case in the Debian package.
>
> Here is my patch to solve this problem
>
> --- /usr/share/docker.io/contrib/dockerd-rootless-setuptool.sh  2021-08-20 
> 10:08:53.200580743 -0300
> +++ /usr/share/docker.io/contrib/dockerd-rootless-setuptool.sh  2021-08-20 
> 10:15:46.489616241 -0300
> @@ -55,12 +55,13 @@
> exit 1
> fi
>
> -   # set BIN
> -   if ! BIN="$(command -v "$DOCKERD_ROOTLESS_SH" 2> /dev/null)"; then
> +   # set BIN and ROOTLESS_BIN
> +   if ! ROOTLESS_BIN="$(command -v "$DOCKERD_ROOTLESS_SH" 2> 
> /dev/null)"; then
> ERROR "$DOCKERD_ROOTLESS_SH needs to be present under \$PATH"
> exit 1
> fi
> -   BIN=$(dirname "$BIN")
> +   ROOTLESS_BIN=$(dirname "$ROOTLESS_BIN")
> +   BIN="/usr/bin/"
>
> # set SYSTEMD
> if systemctl --user show-environment > /dev/null 2>&1; then
> @@ -294,7 +295,7 @@
>
> [Service]
> Environment=PATH=$BIN:/sbin:/usr/sbin:$PATH
> -   ExecStart=$BIN/dockerd-rootless.sh 
> $DOCKERD_ROOTLESS_SH_FLAGS
> +   ExecStart=$ROOTLESS_BIN/dockerd-rootless.sh 
> $DOCKERD_ROOTLESS_SH_FLAGS
> ExecReload=/bin/kill -s HUP \$MAINPID
> TimeoutSec=0
> RestartSec=2
>
> I also had a problem with kernel modules, so I had to add them manually. I'm 
> not sure how useful
> they would be in other types of installation, but Maybe worth add them to the 
> installation script.
>

I know by default dockerd-rootless-setuptool.sh refuses to run and
wants the user to add /usr/share/docker.io/contrib/ to PATH.
However this script is just copied from upstream without change.

I'm not sure we shall patch it. But a simple workaround is run it like:

  PATH=/usr/share/docker.io/contrib/:$PATH dockerd-rootless-setuptool.sh

> --- /dev/null   2021-08-20 08:47:56.012087970 -0300
> +++ /etc/modprobe.d/overlay.conf2021-08-19 19:35:17.535171578 -0300
> @@ -0,0 +1,2 @@
> +# Debian-specific kernel patch, introduced in Debian 10 to the overlay2 
> storage driver
> +options overlay permit_mounts_in_userns=1
>

This is actually broken, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969223
You'd better to install fuse-overlayfs and use that.

> ---  /etc/modules-load.d/modules.con2021-08-20 10:25:11.522661268 -0300
> +++ /etc/modules-load.d/modules.conf2021-08-19 19:41:25.866695920 -0300
> @@ -2,3 +2,4 @@
>  #
>  # This file contains the names of kernel modules that should be loaded
>  # at boot time, one per line. Lines beginning with "#" are ignored.
> +br_netfilter
>

-- 
Shengjing Zhu

Bug#992066: libvkd3d-headers: Package doesn't contain header files

[Francois Gouget]

I can confirm this. None of the 1.2-5 vkd3d packages contain the 
headers: particularly not libvkd3d-headers and not libvkd3d-dev.

The workaround is to go back to vkd3d 1.2-3 (if you can find the 
corresponding packages that is).


-- 
Francois Gouget   http://fgouget.free.fr/
 The greatest programming project of all took six days; on the seventh day the
  programmer rested. We've been trying to debug the *&^%$#@ thing ever since.
  Moral: design before you implement.

Bug#992121: linux-image-5.10.0-8-amd64: kernel oops and subsequent hard crash in bluetooth bt_sock_poll, regression, upstream patch

[Salvatore Bonaccorso]

Hi Tim,

On Wed, Aug 18, 2021 at 10:54:47PM +1000, Tim Connors wrote:
> On Thu, 12 Aug 2021, Salvatore Bonaccorso wrote:
> 
> > > https://www.spinics.net/lists/linux-bluetooth/msg88356.html
> > >
> > > points to a patch that has supposedly already been applied to
> > > bluetooth-next, but is definitely not in linux-source-5.10 5.10.46-4
> > > (testing).
> > >
> > > Current code still reads:
> > >
> > > /* cleanup runtime environment */
> > > remove_wait_queue(sk_sleep(session->intr_sock->sk), &intr_wait);
> > > remove_wait_queue(sk_sleep(session->intr_sock->sk), &ctrl_wait);
> > > wake_up_interruptible(&session->report_queue);
> > > hidp_del_timer(session);
> > >
> > > Second remove_wait_queue should be: ctrl_sock->sk
> >
> > Would it be possible that you check if the upstream commit
> > https://git.kernel.org/linus/cca342d98bef68151a80b024f7bf5f388d1fbdea
> > fixes the issue?
> >
> > It was not yet queued for the 5.10.y series, but if yes, this should
> > go to stable@ so that we then can pick it up for either cherry-picking
> > for the next bullseye upload (or a rebase to the latest 5.10.y in a
> > point release).
> 
> I've been running it for a few days now, and it seems good to me!

Thanks! I asked if this can be included in  future 5.10.y stable
update so that we can pick it up:

https://lore.kernel.org/stable/yr+9p8na4pmxi...@eldamar.lan/T/#u

Regards,
Salvatore

Bug#992589: No UI translation (Spanish)

[Camaleón]

Package: connman-gtk
Version: 1.1.1
Severity: minor

Hello,

When running the program, I get an unlocalized (English) UI, despite my 
system locale is set to Spanish (es_ES).

Greetings,

-- 
Camaleón

Bug#992590: jsoup: CVE-2021-37714

[Salvatore Bonaccorso]

Source: jsoup
Version: 1.10.2-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for jsoup.

CVE-2021-37714[0]:
| jsoup is a Java library for working with HTML. Those using jsoup
| versions prior to 1.14.2 to parse untrusted HTML or XML may be
| vulnerable to DOS attacks. If the parser is run on user supplied
| input, an attacker may supply content that causes the parser to get
| stuck (loop indefinitely until cancelled), to complete more slowly
| than usual, or to throw an unexpected exception. This effect may
| support a denial of service attack. The issue is patched in version
| 1.14.2. There are a few available workarounds. Users may rate limit
| input parsing, limit the size of inputs based on system resources,
| and/or implement thread watchdogs to cap and timeout parse runtimes.


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-37714
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37714
[1] https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#992582: docker.io: Little problem in the dockerd-rootless-setuptool.sh script prevents successful rootless setup

[Igor Matheus Andrade Torrente]

On 8/20/21 12:01 PM, Shengjing Zhu wrote:

On Fri, Aug 20, 2021 at 9:39 PM Igor Torrente  wrote:


Package: docker.io
Version: 20.10.5+dfsg1-1+b5
Severity: important
Tags: patch upstream

Dear maintainers,

I found a little issue in the dockerd-rootless-setuptool.sh installation script.
The fix (or workaround) will be sent in this email.

AFAIK this script is based on the official docker script. But the original 
script assumes
that the docker binary will be in the same folder as the dockerd-rootless.sh.
And this is not the case in the Debian package.

Here is my patch to solve this problem

--- /usr/share/docker.io/contrib/dockerd-rootless-setuptool.sh  2021-08-20 
10:08:53.200580743 -0300
+++ /usr/share/docker.io/contrib/dockerd-rootless-setuptool.sh  2021-08-20 
10:15:46.489616241 -0300
@@ -55,12 +55,13 @@
 exit 1
 fi

-   # set BIN
-   if ! BIN="$(command -v "$DOCKERD_ROOTLESS_SH" 2> /dev/null)"; then
+   # set BIN and ROOTLESS_BIN
+   if ! ROOTLESS_BIN="$(command -v "$DOCKERD_ROOTLESS_SH" 2> /dev/null)"; 
then
 ERROR "$DOCKERD_ROOTLESS_SH needs to be present under \$PATH"
 exit 1
 fi
-   BIN=$(dirname "$BIN")
+   ROOTLESS_BIN=$(dirname "$ROOTLESS_BIN")
+   BIN="/usr/bin/"

 # set SYSTEMD
 if systemctl --user show-environment > /dev/null 2>&1; then
@@ -294,7 +295,7 @@

 [Service]
 Environment=PATH=$BIN:/sbin:/usr/sbin:$PATH
-   ExecStart=$BIN/dockerd-rootless.sh 
$DOCKERD_ROOTLESS_SH_FLAGS
+   ExecStart=$ROOTLESS_BIN/dockerd-rootless.sh 
$DOCKERD_ROOTLESS_SH_FLAGS
 ExecReload=/bin/kill -s HUP \$MAINPID
 TimeoutSec=0
 RestartSec=2

I also had a problem with kernel modules, so I had to add them manually. I'm 
not sure how useful
they would be in other types of installation, but Maybe worth add them to the 
installation script.



I know by default dockerd-rootless-setuptool.sh refuses to run and
wants the user to add /usr/share/docker.io/contrib/ to PATH.
However this script is just copied from upstream without change.

I'm not sure we shall patch it. But a simple workaround is run it like:

   PATH=/usr/share/docker.io/contrib/:$PATH dockerd-rootless-setuptool.sh



I know that we should always avoid an out-of-three/downstream patch. But 
for me, at least, I had to apply the change and the PATH workaround.


Because of this line(~336):
DOCKER_HOST="unix://$XDG_RUNTIME_DIR/docker.sock" $BIN/docker version


And now I noticed that this patch above could be simplified...


--- /dev/null   2021-08-20 08:47:56.012087970 -0300
+++ /etc/modprobe.d/overlay.conf2021-08-19 19:35:17.535171578 -0300
@@ -0,0 +1,2 @@
+# Debian-specific kernel patch, introduced in Debian 10 to the overlay2 
storage driver
+options overlay permit_mounts_in_userns=1



This is actually broken, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969223
You'd better to install fuse-overlayfs and use that.


As I far as I understood, this shouldnt be a problem in the way that I 
use docker. But thanks for the tip.





---  /etc/modules-load.d/modules.con2021-08-20 10:25:11.522661268 -0300
+++ /etc/modules-load.d/modules.conf2021-08-19 19:41:25.866695920 -0300
@@ -2,3 +2,4 @@
  #
  # This file contains the names of kernel modules that should be loaded
  # at boot time, one per line. Lines beginning with "#" are ignored.
+br_netfilter

Bug#990122: base-passwd: please support DPKG_ROOT in preinst and postinst

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Johannes Schauer Marin Rodrigues (2021-06-21 13:28:05)
> Please consider applying the attached patch (post bullseye). We tested the
> patch using the scripts at https://salsa.debian.org/helmutg/dpkg-root-demo
> and can show that a chroot created that way is bit-by-bit identical to one
> that was created normally.

for your convenience, I created a MR on salsa that implements the fix to this
bug:

https://salsa.debian.org/debian/base-passwd/-/merge_requests/9

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#992573: libgpg-error relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5'

[Simon Josefsson]

Package: libgpg-error
Version: 1.42-2

Hi!  I got a build error referencing libgpg-error, and when I rebuilt
the same package in testing, without the latest libgpg-error, it worked.
This might be triggered by some other problem, and I'll debug things
further, but I thought I'd report it in case others are noticing this or
the error message makes sense to you.

https://salsa.debian.org/auth-team/shishi/-/jobs/1835930

/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libgpg-error.a(libgpg_error_la-estream.o): warning: 
relocation against `stdin@@GLIBC_2.2.5' in read-only section `.text'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libgpg-error.a(libgpg_error_la-init.o): 
relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used 
when making a shared object; recompile with -fPIC

/Simon


signature.asc
Description: PGP signature

Bug#983427: libpam-runtime: please add support for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Sam Hartman (2021-06-22 20:48:43)
> So, the feature seems achievable for a significant important use case
> and so I think we should take the patch.

for your convenience, I created a MR on salsa with the proposed changes:

https://salsa.debian.org/vorlon/pam/-/merge_requests/6

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#822236: Hello my love

[jane ferguson121]

 Hello my love, how are you my name is Jane Ferguson and i read through
your profile today and i became interested in you, i am a woman and i
will like to have a long lasting relationship with you and as soon as
i hear from you i will send to you my pictures for me and you to
proceed to know each other more better in future. thank and do have a
nice day.please contact me on this email janeferguson...@yahoo.com
Miss Jane

Bug#992554: not really a libgpg-error0 problem

[Peter Palfrader]

On Fri, 20 Aug 2021, Ivan Sergio Borgonovo wrote:

> Even if after upgrade of libgpg-error0 newer version of tor seemed to
> work... after a reboot it stopped working again.
> 
> Downgrading to 0.4.5.9-1, this time even without downgrading libgpg-error0,
> makes it work again.

The binary produced by the buildds has the systemd files in
/usr/lib/systemd while my own builds have them in /lib/systemd as
expected.  Hm.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#992591: icu-devtools: pkgdata command is broken

[Scott Talbert]

Package: icu-devtools
Version: 63.1-6+deb10u1
Severity: important

Dear Maintainer,

In Buster, the pkgdata command is broken due to the removal of
icu-config:

$ pkgdata -p test -m static -q packagelist.txt
sh: 1: icu-config: not found
sh: 1: icu-config: not found
pkgdata: icu-config: No icu-config found. (fix PATH or use -O option)
 required parameter is missing: -O is required for static and shared builds.
Run 'pkgdata --help' for help.

Upstream has updated pkgdata to work with pkg-config:
https://github.com/unicode-org/icu/commit/5aae52d3ef316b3fd3c43b3f974a8032d279e6fc

It would be greatly appreciated if this patch could be backported to
buster.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#992469: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system

[Peter Palfrader]

On Thu, 19 Aug 2021, Luca Boccassi wrote:

> > Installing those files in /usr/lib/systemd/system is fine.
> 
> 
> 
> This is indeed the right thing to do moving forward, so updating
> Lintian would be the best outcome. Thanks!

It seems that generators in /usr/lib/systemd are being ignored.  This
causes #992554 in tor.

The tor amd64 package build on the buildds has the systemd files in
/usr/lib/systemd, and this results in a broken package.

Moving /usr/lib/systemd/system-generators/tor-generator tor
/lib/systemd/system-generators "fixes" the issue.

Probably debhelper should not move generators to /usr until systemd also
checks that tree for generators.  Or I'm missing something else.

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#979067: pinta: please package pinta 1.7

[Dimitrij Mijoski]

Package: pinta
Followup-For: Bug #979067
X-Debbugs-Cc: la...@debian.org

I am pinging the last uploader, whom may be interested in updating to this new
version. The email for the maintaineer is probably dead (alioth.debian.org is
retired), that is why I am manually pinging.

Bug#992362: release-notes: Out of step wuth apt maintainers

[Brian Potkin]

On Wed 18 Aug 2021 at 20:42:16 +0100, Brian Potkin wrote:

> On Wed 18 Aug 2021 at 10:19:06 +0300, Andrei POPESCU wrote:
> 
> > On Ma, 17 aug 21, 20:20:40, Brian Potkin wrote:
> > > Package: release-notes
> > > Severity: normal
> > > 
> > > 
> > > Please see
> > > 
> > >   https://lists.debian.org/debian-doc/2021/08/msg00077.html
> > > 
> > > Then look at
> > > 
> > >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758316
> > > 
> > > How abut a bit of consistency?
> > 
> > As I understand it the APT maintainers are just saying it doesn't bring 
> > much (if any) security or privacy benefit, they don't explicitly 
> > recommend against it.
> 
> They closed the report. That is sufficient reason to take notice of
> their stance.
>  
> > For the Release Notes itself there is however a real benefit in avoiding 
> > all future bug reports asking to use https:// everywhere ;)
> 
> A reasonable acceptable argument in this context.

For future readers of this report, the bascic issue has been thoroughly
discussed in the thread beginning at

  https://lists.debian.org/debian-devel/2021/08/msg00269.html

Cheers,

Brian.

Bug#992545: Netinst 10.9: Cating /etc/shadow reveals a user that is not visible by other means

[Marc Haber]

severity #992545 normal
tags #992545 security
reassign #992545 cdimage.debian.org
thanks

(Tagging this as a potential security issue, lowering severity probably
too far, reassigning to cdimage.debian.org as this looks like a possible
issue with the official CD images)

That being said, Debian 10.9 has become Debian oldstable last weekend,
and we released a point release in the mean time, so normal people are
unlikely to to install from a Debian 10.9 image since we now have Debian
11.0 and Debian 10.10.

On Fri, Aug 20, 2021 at 01:07:52AM +0200, Molly Millions wrote:
> Something fishy is going on with the
> 
> debian-10.9.0-amd64-netinst.iso
> MD5: 73e74eef3d998d522f92295016d92fdc
> SHA256: 8660593d10de0ce7577c9de4dab886ff540bc9843659c8879d8eea0ab224c109

I can confirm that the CD image that can be downloaded from
https://cdimage.debian.org/mirror/cdimage/archive/10.9.0/amd64/iso-cd/debian-10.9.0-amd64-netinst.iso
actually has those checksums.

> I used this image to install a base system with VMWare player. After the
> installation is done I login with root on the console and cat'ing the
> /etc/shadow file shows a randomly generated user (AWkoc7HZ90) in the shadow
> file that is *not visible* by using nano. If I ssh into the box as root the
> shadow file doesn't reveal the user. Check the attached picture.

I have installed from this image into a KVM VM (graphical installer,
giving default answers to most questions) and I can confirm that
/etc/shadow is just fine both from the running system and from the file
system mounted into a rescue system booted from an read-only ISO.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#990428: Working configuration for Debian 11 Bulseye

[Arunas]

https://serverfault.com/a/1075192/267378

Best regards,
Arunas

Bug#992432: RFS: frobby (NEW binary package)

[Torrance, Douglas]

On Wed 18 Aug 2021 03:35:19 PM EDT, Doug Torrance  
wrote:
> Due to [1], frobby needs a soname version bump and hence a NEW binary package
> (libfrobby0 -> libfrobby1).  As a DM, I'm not able to upload packages to the
> NEW queue.  Would anyone be able to review/sponsor?
>
> https://salsa.debian.org/science-team/frobby
>
> Thanks!
> Doug
>
> [1] https://bugs.debian.org/992432

FYI, I just uploaded a band-aid fix to sid to take care of this RC bug for the
time being so we don't have to wait for the NEW queue, but I'm still looking
for a sponsor for the long-term fix, which I've pushed to git.

Thanks!
Doug

Bug#601640: xpaint: New upstream release

[Dimitrij Mijoski]

Package: xpaint
Followup-For: Bug #601640

This project has some new activity and the latest upstream version is 3.1.4.
https://sourceforge.net/projects/sf-xpaint/files/sf-xpaint/xpaint-3.1.4/

Bug#992554: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system

[Simon McVittie]

Control: retitle 992554 debhelper: moves systemd system generators to a 
location not searched by systemd
Control: reassign 992554 debhelper 13.4
Control: affects 992554 + tor ostree

On Fri, 20 Aug 2021 at 16:20:04 +, Peter Palfrader wrote:
> It seems that generators in /usr/lib/systemd are being ignored.  This
> causes #992554 in tor.
> 
> The tor amd64 package build on the buildds has the systemd files in
> /usr/lib/systemd, and this results in a broken package.
> 
> Moving /usr/lib/systemd/system-generators/tor-generator tor
> /lib/systemd/system-generators "fixes" the issue.
> 
> Probably debhelper should not move generators to /usr until systemd also
> checks that tree for generators.  Or I'm missing something else.

I think debhelper should *not* be moving anything from /lib/systemd/
to /usr/lib/systemd/, except for /lib/systemd/system/, which we have
confirmed is OK. Other directories like /lib/systemd/system-generators
are not necessarily going to be searched on non-merged-/usr systems;
before moving any particular class of systemd-related files, debhelper
developers should confirm with the systemd maintainers that systemd
is already looking in both locations, and since which version (so that
appropriate ${misc:Depends} can be added if required).

On merged-/usr systems (with aliasing symlinks like /lib -> usr/lib,
as created by usrmerge and debootstrap --merged-usr), this is of course
a non-issue, but we do not all have merged-/usr systems yet.

I think this is a nice illustration of the things that can go wrong on
non-merged-/usr systems, when we move individual categories of files
from the rootfs into /usr, in order to achieve the same result as
merged-/usr (but with more effort and more complexity).

smcv

Bug#964524: hollywood: diff for NMU version 1.21-1.1

[Chris Hofstaedtler]

Package: hollywood
Version: 1.21-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for hollywood (versioned as 1.21-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru hollywood-1.21/debian/changelog hollywood-1.21/debian/changelog
--- hollywood-1.21/debian/changelog 2020-03-10 13:23:13.0 +
+++ hollywood-1.21/debian/changelog 2021-08-20 11:55:12.0 +
@@ -1,3 +1,11 @@
+hollywood (1.21-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Depend on bsdextrautils for hexdump. (Closes: #964524, #963226)
+  * Update locate recommendation. (Closes: #989519)
+
+ -- Chris Hofstaedtler   Fri, 20 Aug 2021 11:55:12 +
+
 hollywood (1.21-1) unstable; urgency=medium

   [ Sergio Schvezov ]
diff -Nru hollywood-1.21/debian/control hollywood-1.21/debian/control
--- hollywood-1.21/debian/control   2019-11-29 20:57:42.0 +
+++ hollywood-1.21/debian/control   2021-08-20 11:55:12.0 +
@@ -16,12 +16,12 @@
  apg,
  atop,
  bmon,
- bsdmainutils,
+ bsdextrautils,
  ccze,
  cmatrix,
  htop,
  jp2a,
- mlocate,
+ plocate | mlocate | locate,
  moreutils,
  openssh-client,
  speedometer,

Bug#992592: lightdm fails to start after update to bullseye (missing '/var/lib/lightdm/data')

[Pavel Sanda]

Package: lightdm
Version: 1.26.0-7
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: sa...@lyx.org

Dear Maintainer,

updating debian to bullseye killed access to my desktop environment.
It was actually stretch->buster and then (after appropriate reboots etc.)
buster->bullseye, so not sure which of two steps broke it.

lightdm used to be default DM and was not working anymore after the update.
Checking logs with
lightdm --test-mode --debug
showed critical line about missing /var/lib/lightdm/data like in bugs
#947319 and #931335.

apt-get purge lightdm
apt-get install lightdm

fixed the situation (purge was clearly doing bunch of stuff in /etc/
which should be probably part of distro-update procedures(?).


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

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

Versions of packages lightdm depends on:
ii  adduser3.118
ii  dbus   1.12.20-2
ii  debconf [debconf-2.0]  1.5.77
ii  libaudit1  1:3.0-2
ii  libc6  2.31-13
ii  libgcrypt201.8.7-6
ii  libglib2.0-0   2.66.8-1
ii  libpam-systemd [logind]247.3-6
ii  libpam0g   1.4.0-9
ii  libxcb11.14-3
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.8-2
ii  lsb-base   11.1.0

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+22

Versions of packages lightdm suggests:
ii  accountsservice  0.6.55-3
ii  upower   0.99.11-2
pn  xserver-xephyr   

-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm

Bug#992593: RM: pdns-recursor [armel armhf i386 mipsel] -- ROM; 32bit time_t archs unsupported

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

upstream has removed support for architectures with 32bit time_t values.

Please remove pdns-recursor from armel armhf i386 mipsel.

Thanks,
Chris

Bug#992486: docker.io: cgroup v2 defaults break rootless container start & build

[Forest]

On Fri, 20 Aug 2021 22:48:18 +0800, Shengjing Zhu wrote:

>Yes. The default mode, which is using systemd to setup cgroup, requires dbus.
>So you need to install dbus-user-session, which will provide 
>/run/user/$uid/bus.
>
>Or you can use cgroupfs mode, which is mentioned in your first mail,
>as a workaround.

In that case, shouldn't Debian's docker.io package document this requirement
for rootless containers? And shouldn't the runc package have Suggests:
dbus-user-session?