Bug#983213: ukui-control-center: Missing dependency on libglib2.0-bin

[Adrian Bunk]

Package: ukui-control-center
Version: 3.0.2-1
Severity: serious

https://piuparts.debian.org/sid/fail/ukui-control-center_3.0.2-1.log

...
  Setting up ukui-control-center (3.0.2-1) ...
  /var/lib/dpkg/info/ukui-control-center.postinst: 5: glib-compile-schemas: not 
found
  dpkg: error processing package ukui-control-center (--configure):
   installed ukui-control-center package post-installation script subprocess 
returned error exit status 127
...

Bug#983212: libgeotiff: FTBFS with PROJ 8.0.0

[Bas Couwenberg]

Source: libgeotiff
Version: 1.6.0-1
Severity: important
Tags: upstream ftbfs
User: debian-...@lists.debian.org
Usertag: proj-8.0

Dear Maintainer,

Your package FTBFS with PROJ 8.0.0:

 ../test/testlistgeo ../bin/listgeo
 
 Running ../test/testlistgeo using ../bin/listgeo:
 
 proj_create: unrecognized format / unknown name
 proj_create: unrecognized format / unknown name
 proj_create: unrecognized format / unknown name
 proj_create: unrecognized format / unknown name
 proj_create: unrecognized format / unknown name
 proj_create: unrecognized format / unknown name
 proj_create: unrecognized format / unknown name
 proj_create: unrecognized format / unknown name
 proj_create: unrecognized format / unknown name
 proj_create: unrecognized format / unknown name
 diff testlistgeo_out with testlistgeo_out.dist
 --- testlistgeo_out 2021-02-21 07:01:34.961336363 +
 +++ testlistgeo_out.dist.tmp2021-02-21 07:01:34.957336392 +
 @@ -1566,6 +1566,9 @@
 ProjFalseEastingGeoKey: 649328.00 m
 ProjFalseNorthingGeoKey: 665262.00 m
  GCS: 4258/ETRS89
 +Datum: 6258/European Terrestrial Reference System 1989
 +Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
 +Prime Meridian: 8901/Greenwich (0.00/  0d 0' 0.00"E)
  Projection Linear Units: 9001/metre (1.00m)
  
  Corner Coordinates:
 @@ -1616,6 +1619,9 @@
 ProjFalseEastingGeoKey: 649328.00 m
 ProjFalseNorthingGeoKey: 665262.00 m
  GCS: 4258/ETRS89
 +Datum: 6258/European Terrestrial Reference System 1989
 +Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
 +Prime Meridian: 8901/Greenwich (0.00/  0d 0' 0.00"E)
  Projection Linear Units: 9001/metre (1.00m)
  
  Corner Coordinates:
 @@ -1744,6 +1750,9 @@
 ProjFalseEastingGeoKey: 4321000.00 m
 ProjFalseNorthingGeoKey: 321.00 m
  GCS: 4258/ETRS89
 +Datum: 6258/European Terrestrial Reference System 1989
 +Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
 +Prime Meridian: 8901/Greenwich (0.00/  0d 0' 0.00"E)
  Projection Linear Units: 9001/metre (1.00m)
  
  Corner Coordinates:
 @@ -1790,6 +1799,9 @@
 ProjFalseEastingGeoKey: 4321000.00 m
 ProjFalseNorthingGeoKey: 321.00 m
  GCS: 4258/ETRS89
 +Datum: 6258/European Terrestrial Reference System 1989
 +Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
 +Prime Meridian: 8901/Greenwich (0.00/  0d 0' 0.00"E)
  Projection Linear Units: 9001/metre (1.00m)
  
  Corner Coordinates:
 
 PROBLEMS HAVE OCCURRED
 test file testlistgeo_out saved
 
 make[3]: *** [Makefile:540: check-local] Error 100

The full buildlog is attached.

Kind Regards,

Bas 
dpkg-checkbuilddeps: error: Unmet build dependencies: libproj-dev (>= 6.0.0)
W: Unmet build-dependency in source
dh clean
   debian/rules override_dh_clean
make[1]: Entering directory '/home/bas/tmp/debian/libgeotiff-1.6.0'
dh_clean libgeotiff.* xtiffio.h newgeo.tif
make[1]: Leaving directory '/home/bas/tmp/debian/libgeotiff-1.6.0'
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building libgeotiff using existing 
./libgeotiff_1.6.0.orig.tar.gz
dpkg-source: info: building libgeotiff in libgeotiff_1.6.0-2.debian.tar.xz
dpkg-source: info: building libgeotiff in libgeotiff_1.6.0-2.dsc
I: Generating source changes file for original dsc
dpkg-genchanges: info: not including original source code in upload
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.19606
I: forking: cp -al /var/cache/pbuilder/base-sid+rebuild.cow 
/var/cache/pbuilder/build/cow.19606
I: removed stale ilistfile /var/cache/pbuilder/build/cow.19606/.ilist
I: forking: chroot /var/cache/pbuilder/build/cow.19606 
cowdancer-ilistcreate /.ilist 'find . -xdev -path ./home -prune -o \( \( -type 
l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ''
I: Invoking pbuilder
I: forking: pbuilder build --debbuildopts  --debbuildopts  --buildplace 
/var/cache/pbuilder/build/cow.19606 --buildresult /var/cache/pbuilder/result/ 
--mirror http://ftp.nl.debian.org/debian/ --distribution sid --no-targz 
--internal-chrootexec 'chroot /var/cache/pbuilder/build/cow.19606 cow-shell' 
/home/bas/tmp/debian/libgeotiff_1.6.0-2.dsc
I: Running in no-targz mode
I: pbuilder: network access will be disabled during build
I: Current time: Sun Feb 21 07:58:54 CET 2021
I: pbuilder-time-stamp: 1613890734
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage 
for details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: 

Bug#983211: php-http-psr7-integration-tests: autopkgtest failure

[Adrian Bunk]

Source: php-http-psr7-integration-tests
Version: 1.1.1-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-http-psr7-integration-tests/10589995/log.gz

...
autopkgtest [21:38:30]: test command1: mkdir -p vendor && phpab -o 
vendor/autoload.php -t debian/autoload.tests.php.tpl tests && phpunit 
--testsuite Guzzle
autopkgtest [21:38:30]: test command1: [---
phpab %development% - Copyright (C) 2009 - 2021 by Arne Blankerts and 
Contributors

Scanning directory tests

Autoload file vendor/autoload.php generated.

PHPUnit 9.5.2 by Sebastian Bergmann and contributors.

Warning:   Your XML configuration validates against a deprecated schema.
Suggestion:Migrate your XML configuration using "--migrate-configuration"!

..S  63 / 137 ( 45%)
....E.E.E..E... 126 / 137 ( 91%)
... 137 / 137 (100%)

Time: 00:00.137, Memory: 8.00 MB

There were 4 errors:

1) Http\Psr7Test\Tests\Guzzle\StreamTest::testIsNotSeekable
fopen(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify 
failed

/usr/share/php/Http/Psr7Test/StreamIntegrationTest.php:152

2) Http\Psr7Test\Tests\Guzzle\StreamTest::testIsNotWritable
fopen(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify 
failed

/usr/share/php/Http/Psr7Test/StreamIntegrationTest.php:179

3) Http\Psr7Test\Tests\Guzzle\StreamTest::testIsNotReadable
fopen(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify 
failed

/usr/share/php/Http/Psr7Test/StreamIntegrationTest.php:206

4) Http\Psr7Test\Tests\Guzzle\StreamTest::testRewindNotSeekable
fopen(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify 
failed

/usr/share/php/Http/Psr7Test/StreamIntegrationTest.php:251

ERRORS!
Tests: 137, Assertions: 247, Errors: 4, Skipped: 5.
autopkgtest [21:38:30]: test command1: ---]
autopkgtest [21:38:30]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 2

Bug#983102: casync FTCBFS: python3-sphinx dependency not installable

[Martin Pitt]

Control: tag -1 pending

Hello Helmut,

Helmut Grohne [2021-02-19  7:29 +0100]:
> As such I propose simply annotating the dependency :native and doing so is
> sufficient to make casync cross buildable. Please consider applying the
> attached patch.

Thanks for fixing that! I applied your patch to git. I'll do some other
house-keeping now, and do an upload today.

Martin

Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0

[Sam Hartman]

> "Martin" == Martin Schurz  writes:

>> It looks like Steve had an explicit reason for disabling
>> pam_tally here and I don't want to go second guess that.  (Steve,
>> if I'm wrong, please chime in).  In particular, Steve kept
>> pam_cracklib, which also requires an extra option, but did not
>> keep pam_tally.

Martin> Oh, sorry there was some detail missing. The config option
Martin> --enable-tally was added in linux-pam from version 1.4.0 to
Martin> soft deprecate this module.  So when we re-enable it with
Martin> this option, it should build the pam_tally module like it
Martin> was the case up to 1.3.x.

I understood this.  But Steve, the Debian maintainer did not choose to
use that option even though he did choose to use a similar option that
was available for cracklib.

My assumption is that we'll use whatever strategy we come up with for
tally for cracklib next relesae.

Bug#979973: libpam-yubico: proposed patch to fix #979973

[Jochen Hein]

Package: libpam-yubico
Followup-For: Bug #979973

Dear Maintainer,

I've upgraded one of my systems where I use pam_yubico and hit the problem.
I'd like to see the issue fixed for bullseye since it might have
security implications or might render people to be unable to login.

Please consider the attached patch to debian packaging.

Do we need to talk to the release team and/or raise the bug severity?

<#part type="text/x-diff" 
filename="~/work/GNU/libpam-yubico-fix-debian-bug-979973.diff" 
disposition=inline>
<#/part>

Thanks for considering.
Jochen

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 libpam-yubico depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.31-9
ii  libldap-2.4-2  2.4.57+dfsg-2
ii  libpam-runtime 1.4.0-4
ii  libpam0g   1.4.0-4
ii  libykclient3   2.15-2+b1
ii  libykpers-1-1  1.20.0-3
ii  libyubikey01.13-6

libpam-yubico recommends no packages.

libpam-yubico suggests no packages.

-- debconf information:
  libpam-yubico/module_args: mode=client try_first_pass id=N key=K

Bug#979973: libpam-yubico: add missing patch

[Jochen Hein]

Package: libpam-yubico
Followup-For: Bug #979973

Dear Maintainer,

I missed adding the path. Here it is:

diff -ur yubico-pam-2.26.orig/debian/changelog yubico-pam-2.26/debian/changelog
--- yubico-pam-2.26.orig/debian/changelog   2021-02-21 05:40:48.0 
+0100
+++ yubico-pam-2.26/debian/changelog2021-02-21 06:01:59.0 +0100
@@ -1,3 +1,10 @@
+yubico-pam (2.26-1.2~jochen1+1) unstable; urgency=low
+
+  * Move pam_yubico.so from /lib/security to /lib/x86_64-linux-gnu/security
+(Closes: 979973)
+
+ -- Jochen Kellner   Sun, 21 Feb 2021 17:37:57 +0100
+
 yubico-pam (2.26-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -ur yubico-pam-2.26.orig/debian/rules yubico-pam-2.26/debian/rules
--- yubico-pam-2.26.orig/debian/rules   2021-02-21 05:40:48.0 +0100
+++ yubico-pam-2.26/debian/rules2021-02-21 05:58:17.0 +0100
@@ -7,14 +7,14 @@
 
 override_dh_auto_configure:
dh_auto_configure -- \
-   --with-pam-dir=$(DESTDIR)/lib/security \
+   --with-pam-dir=$(DESTDIR)/lib/x86_64-linux-gnu/security \
--includedir=/usr/include/libpam-yubico
 
 override_dh_install:
install -D -m 0644 debian/pam-auth-update \

debian/libpam-yubico/usr/share/libpam-yubico/pam-auth-update.template
chrpath -d debian/libpam-yubico/usr/bin/ykpamcfg
-   chrpath -d debian/libpam-yubico/lib/security/pam_yubico.so
-   rm debian/libpam-yubico/lib/security/pam_yubico.la
+   chrpath -d 
debian/libpam-yubico/lib/x86_64-linux-gnu/security/pam_yubico.so
+   rm debian/libpam-yubico/lib/x86_64-linux-gnu/security/pam_yubico.la
rm -rf debian/libpam-yubico/usr/include
dh_install --fail-missing

Bug#983209: lynx: differences in documentation when built in parallel

[Vagrant Cascadian]

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

The lynx documentation has many differences between two builds:

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

  /usr/share/doc/lynx-common/lynx_help/body.html.gz
  
In one of the builds, there has several occurrences of:

  Support·for·this·setting·was·disabled·at·compile-time. 


All of the documentation differences disappeared for me when disabling
parallelism in the build (and fixing the usrmerge issue reported in
another bug). The attached patch passes --no-parallel to dh in
debian/rules to accomplish this.

I do not know weather this is actually a more serious issue where
various features are actually disabled between the two builds or only a
documentation difference.


This does not resolve all reproducibility issues (e.g. when /bin/sh
points to bash), but should reduce some of the noise when comparing the
differences.


live well,
  vagrant
From 234708e2ab9e8117a059905ba69dd65226c0b1c2 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 21 Feb 2021 04:27:16 +
Subject: [PATCH 2/2] debian/rules: Disable parallel build.

This causes wildly different documentation to be generated, at the
very least, and possibly significant differences in the binary itself.
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 7e4ca22..ef46a5d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -62,4 +62,4 @@ override_dh_link:
 	dh_link
 
 %:
-	dh $@
+	dh $@ --no-parallel
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#983208: lynx: embeds path to various binaries that differ with usrmerge

[Vagrant Cascadian]

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

The paths to various binaries are embedded in /usr/bin/lynx, which
differs on a usrmerge vs. non-usrmerge system.

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

  /usr/bin/lynx

  "/bin/gzip"
  vs.
  "/usr/bin/gzip"


Patch attached which passes variables to configure to use the
non-usrmerge locations, as usrmerge installations typically have
compatibility symlinks, but not vice-versa.


This does not resolve all reproducibility issues (e.g. when /bin/sh
points to bash), but should reduce some of the noise when comparing the
differences.


live well,
  vagrant
From 65e7a04ed68d33c7adf0a278948f9a7138bb1a69 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 21 Feb 2021 02:29:36 +
Subject: [PATCH 1/2] debian/rules: Pass paths to various binaries.

Use the non-usrmerge locations for binaries, which works on both
usrmerge and non-usrmerge systems.

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

diff --git a/debian/rules b/debian/rules
index b0ca680..7e4ca22 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,6 +13,15 @@ else
 	CONFTLS := --with-ssl
 endif
 
+# Ensure the most compatible helper program paths to work on both
+# usrmerge and non-usrmerge systems.
+BINARY_PATHS += GZIP=/bin/gzip
+BINARY_PATHS += UNCOMPRESS=/bin/gunzip
+BINARY_PATHS += MV=/bin/mv
+BINARY_PATHS += ZCAT=/bin/zcat
+BINARY_PATHS += TAR=/bin/tar
+BINARY_PATHS += RM=/bin/rm
+
 override_dh_auto_configure:
 ifeq ($(SSL),gnu)
 	sed -i -e s/libssl-dev/libgnutls28-dev/g debian/control
@@ -36,6 +45,7 @@ endif
 --enable-read-eta --enable-scrollbar --enable-syslog \
 	--with-zlib --with-bzlib --without-included-gettext \
 	--with-screen=ncursesw --enable-justify-elts \
+	$(BINARY_PATHS) \
 	$(CONFTLS)
 
 override_dh_autoreconf:
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#983206: [libupnp13] Please update for CVE-2020-12695 & fixes

[Lyndon Brown]

On Sun, 21 Feb 2021 04:16:21 + Lyndon Brown 
wrote:
> I'm also having trouble getting DLNA working with minidlna on one
> system and vlc on another, with little idea so far why it's not
> working. Getting an updated libupnp13 with all the fixes they've made
> may help eliminate some possible causes.

Weird, having spent hours on this, I switched back to vlc after firing
off the email and the remote system was suddenly right there in vlc's
list... I can't explain that. I don't think I'd made any changes since
the last time I checked. Something I did earlier must have fixed it but
with some sort of delay to updating something. I think that the only
big difference to where I started from is no longer having minissdpd on
the server. Interestingly with it now fixed I refreshed the
x.x.x.x:8200 webpage in the browser and noticed the client type field
changed, from 'Unknown' to 'Generic UPnP 1.0'.

Hmm... Well that did not last. A little fiddling, and now it's gone
again and I'm not having any success at getting it back. The client has
also gone back to 'Unknown'. :/

Anyway, please update at least for the CVE, and fingers crossed it may
help with this also.

Bug#983207: geeqie: does not display images under sway/wayland

[Vagrant Cascadian]

Package: geeqie
Version: 1:1.6-6
Severity: important

After I switched from using i3 (X.org window manager) to sway (a wayland
compositor), when I try to view images in geeqie, it just shows a blank
white space where the image should be. Thumbnails in the sidebar view
work fine...


Thanks for maintaining geeqie, I've gotten a lot of use out of it over
the years!


live well,
  vagrant

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, 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 geeqie depends on:
ii  geeqie-common1:1.6-6
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libchamplain-0.12-0  0.12.20-1
ii  libchamplain-gtk-0.12-0  0.12.20-1
ii  libclutter-1.0-0 1.26.4+dfsg-2
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libcogl201.22.8-2
ii  libdjvulibre21   3.5.28-1
ii  libexiv2-27  0.27.3-3
ii  libffmpegthumbnailer4v5  2.1.1-0.2+b1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.7-1
ii  libgtk-3-0   3.24.24-1
ii  libheif1 1.11.0-1
ii  libjpeg62-turbo  1:2.0.5-2
ii  liblcms2-2   2.12~rc1-2
ii  liblirc-client0  0.10.1-6.2+b1
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libopenjp2-7 2.4.0-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpoppler-glib8 20.09.0-3.1
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.2.0-1
ii  libwebp6 0.6.1-2+b1
ii  sensible-utils   0.0.14

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.3.3op2-2
ii  exiftran 2.10-4
ii  exiv20.27.3-3
ii  imagemagick  8:6.9.11.60+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1
ii  librsvg2-common  2.50.3+dfsg-1
pn  ufraw-batch  
ii  zenity   3.32.0-6

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.10.22-2
ii  libjpeg-turbo-progs [libjpeg-progs]  1:2.0.5-2
pn  ufraw
pn  xpaint   

-- no debconf information


signature.asc
Description: PGP signature

Bug#983206: [libupnp13] Please update for CVE-2020-12695 & fixes

[Lyndon Brown]

Package: libupnp13
Version: 1:1.8.4-2
Severity: critical

According to the changelog upstream version 1.14.0 includes a security
fix for CVE-2020-12695 (currently not tracked for pupnp in the debian
security tracker).

Please update to 1.14.x. Thanks.

I'm also having trouble getting DLNA working with minidlna on one
system and vlc on another, with little idea so far why it's not
working. Getting an updated libupnp13 with all the fixes they've made
may help eliminate some possible causes.

Bug#983205: golang-github-go-ping-ping: Some tests require network access

[Logan Rosen]

Package: golang-github-go-ping-ping
Version: 0+git20201106.b6486c6-2
Severity: serious
Tags: patch
Justification: Policy 4.9
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

python-rfc6555 currently requires network access during build for some of its
tests, which causes the build to fail in Ubuntu [1] (and reproducible
builds [2]) and is a violation of Debian policy.

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/skip-tests-requiring-network-access.patch: Skip tests that require
network access since Ubuntu's buildds don't have it.

Thanks for considering the patch.

Logan

[1] 
https://launchpad.net/ubuntu/+source/golang-github-go-ping-ping/0+git20201106.b6486c6-2/+build/20988534
[2] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-go-ping-ping.html
diff -Nru 
golang-github-go-ping-ping-0+git20201106.b6486c6/debian/patches/series 
golang-github-go-ping-ping-0+git20201106.b6486c6/debian/patches/series
--- golang-github-go-ping-ping-0+git20201106.b6486c6/debian/patches/series  
1969-12-31 19:00:00.0 -0500
+++ golang-github-go-ping-ping-0+git20201106.b6486c6/debian/patches/series  
2021-02-20 23:04:52.0 -0500
@@ -0,0 +1 @@
+skip-tests-requiring-network-access.patch
diff -Nru 
golang-github-go-ping-ping-0+git20201106.b6486c6/debian/patches/skip-tests-requiring-network-access.patch
 
golang-github-go-ping-ping-0+git20201106.b6486c6/debian/patches/skip-tests-requiring-network-access.patch
--- 
golang-github-go-ping-ping-0+git20201106.b6486c6/debian/patches/skip-tests-requiring-network-access.patch
   1969-12-31 19:00:00.0 -0500
+++ 
golang-github-go-ping-ping-0+git20201106.b6486c6/debian/patches/skip-tests-requiring-network-access.patch
   2021-02-20 23:05:17.0 -0500
@@ -0,0 +1,18 @@
+--- a/ping_test.go
 b/ping_test.go
+@@ -227,6 +227,7 @@
+ }
+ 
+ func TestNewPingerValid(t *testing.T) {
++  t.Skip("Requires network access")
+   p := New("www.google.com")
+   err := p.Resolve()
+   AssertNoError(t, err)
+@@ -344,6 +345,7 @@
+ }
+ 
+ func TestSetIPAddr(t *testing.T) {
++  t.Skip("Requires network access")
+   googleaddr, err := net.ResolveIPAddr("ip", "www.google.com")
+   if err != nil {
+   t.Fatal("Can't resolve www.google.com, can't run tests")

Bug#983204: git-buildpackage: FTBFS in Ubuntu due to incorrect /etc/os-release check

[Logan Rosen]

Package: git-buildpackage
Version: 0.9.22
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

git-buildpackage FTBFS in Ubuntu because the dch tests have an incorrect
/etc/os-release check. It looks for the ID as "Ubuntu," while it's
populated as "ubuntu" (lowercase) in Ubuntu.

In Ubuntu, the attached patch was applied to achieve the following:

  * tests/11_test_dch_main.py: Fix OS release check for Ubuntu.

Thanks for considering the patch.

Logan
diff -Nru git-buildpackage-0.9.22/tests/11_test_dch_main.py 
git-buildpackage-0.9.22ubuntu1/tests/11_test_dch_main.py
--- git-buildpackage-0.9.22/tests/11_test_dch_main.py   2021-01-27 
04:45:11.0 -0500
+++ git-buildpackage-0.9.22ubuntu1/tests/11_test_dch_main.py2021-02-20 
22:30:30.0 -0500
@@ -18,7 +18,7 @@
 os_release = OsReleaseFile()
 
 # OS release codename and snapshot of version 0.9-2~1
-if os_release['ID'] == 'Ubuntu':
+if os_release['ID'] == 'ubuntu':
 os_codename = os_release['UBUNTU_CODENAME']
 snap_header_0_9 = 
r'^test-package\s\(0.9-1ubuntu1~1\.gbp([0-9a-f]{6})\)\sUNRELEASED;\surgency=%s' 
% default_urgency
 new_version_0_9 = '0.9-1ubuntu1'

Bug#920078: ITA: colortest -- utilities to test color capabilities of terminal

[Micheal Waltz]

retitle 920078 ITA: colortest -- utilities to test color capabilities of 
terminal

-- 
Micheal Waltz
https://keybase.io/ecliptik
GPG Fingerprint: 5F70 F2AC BD58 F580 DF15  3D1F 4FA2 70F5 CD36 71F9


signature.asc
Description: PGP signature

Bug#983203: [firewalld] error - invalid ipset sshguard4

[Lyndon Brown]

Package: firewalld
Version: 0.9.3-2
Severity: important

I'm experiencing problems on a Sid system with firewalld and sshguard - 
firewalld does
not seem happy with the sshguard config for some reason.

I set things up for sshguard a while ago and today happened to notice a problem 
when trying to
add a temporary firewall rule while playing around with DLNA which resulted in 
an error...

`firewall-cmd --add-port=1900/udp` gave:
Error: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0: Error: Could 
not process rule: No such file or directory


JSON blob:
{"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"rule": 
{"family": "inet", "table": "firewalld", "chain": "filter_IN_public_allow", 
"expr": [{"match": {"left": {"payload": {"protocol": "udp", "field": "dport"}}, 
"op": "==", "right": 1900}}, {"match": {"left": {"ct": {"key": "state"}}, "op": 
"in", "right": {"set": ["new", "untracked"]}}}, {"accept": null}]}}}]}

Checking `systemctl status firewalld` led to the discovery that firewalld did 
not seem
happy with the existing permanent sshguard config, which had been added with 
the following
commands (per sshguard setup instructions):
1. firewall-cmd --permanent --zone=public --add-rich-rule="rule source 
ipset=sshguard4 drop"
2. firewall-cmd --permanent --zone=public --add-rich-rule="rule source 
ipset=sshguard6 drop"

`firewall-cmd --info-ipset=sshguard4` gives:
Error: INVALID_IPSET: sshguard4

`firewall-cmd --state` gives:
failed

`systemctl status firewalld` gives:
● firewalld.service - firewalld - dynamic firewall daemon
 Loaded: loaded (/lib/systemd/system/firewalld.service; enabled; vendor 
preset: enabled)
 Active: active (running) since Sun 2021-02-21 00:44:38 GMT; 34min ago
   Docs: man:firewalld(1)
   Main PID: 1973 (firewalld)
  Tasks: 2 (limit: 4636)
 Memory: 25.1M
CPU: 1.328s
 CGroup: /system.slice/firewalld.service
 └─1973 /usr/bin/python3 /usr/sbin/firewalld --nofork --nopid

Feb 21 00:44:37 debian systemd[1]: Starting firewalld - dynamic firewall 
daemon...
Feb 21 00:44:38 debian systemd[1]: Started firewalld - dynamic firewall daemon.
Feb 21 00:44:38 debian firewalld[1973]: ERROR: INVALID_IPSET: sshguard4
Feb 21 00:44:38 debian firewalld[1973]: ERROR: 'python-nftables' failed: 
internal:0:0-0: Error: Could not process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory


JSON blob:
{"nftables": [{"metainfo": 
{"json_schema_version": 1}}, {"insert": {"rule": {"family": "inet", "table": 
"firewalld", "chain": "filter_INPUT_ZONES", "expr": [>
Feb 21 00:44:38 debian firewalld[1973]: ERROR: COMMAND_FAILED: 
'python-nftables' failed: internal:0:0-0: Error: Could not process rule: No 
such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: Could not 
process rule: No such file or directory

internal:0:0-0: Error: 

Bug#983202: time: reproducible builds: Embeds date in documentation

[Vagrant Cascadian]

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

The timezone affects the date embedded in the info page and html
documentation:

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

  /usr/share/doc/time/time.html

  updated·14·February·2021
  vs.
  updated·19·March·2022

The attached patch fixes this by removing the updated date from the
documentation files. The build date is not really when the content was
last updated, so is a bit misleading anyways.


Thanks for maintaining time!


live well,
  vagrant
From 2048be16fa0418c231bc953e2d4350b117672ce0 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 20 Feb 2021 22:28:30 +
Subject: [PATCH] doc/time.texi: Remove timestamp from documentation.

The date the package was built is misleading about when the
documentation was last updated.

https://reproducible-builds.org/docs/timestamps/
---
 doc/time.texi | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/doc/time.texi b/doc/time.texi
index dfc0aa4..c660a66 100644
--- a/doc/time.texi
+++ b/doc/time.texi
@@ -11,7 +11,6 @@
 This manual is for GNU @code{time} command for running programs
 and summarizing the system resources they use.
 version @value{VERSION}
-updated @value{UPDATED}
 
 Copyright @copyright{} 1991-2018 Free Software Foundation, Inc.
 
@@ -37,7 +36,6 @@ Texts.  A copy of the license is included in the section entitled
 @title Measuring Program Resource Use
 @subtitle The GNU @code{time} Command
 @subtitle version @value{VERSION}
-@subtitle updated @value{UPDATED}
 @author David MacKenzie
 @page
 @vskip 0pt plus 1filll
@@ -54,7 +52,7 @@ Texts.  A copy of the license is included in the section entitled
 
 This file documents the the GNU @code{time} command for running programs
 and summarizing the system resources they use.
-Version @value{VERSION}, updated @value{UPDATED}
+Version @value{VERSION}
 @end ifnottex
 
 
-- 
2.30.1



signature.asc
Description: PGP signature

Bug#983201:

[PICCORO McKAY Lenz]

Package: iperf
Version: 2.0.14a+dfsg1-1
Severity: important
Tags: upstream

iperf now has a new version (iperf) 2.1.0rc that has some improvements
and several fixed..

current debian version has two critical bugs that reports incorrect numbers

#965974 and #760590 makes the package acts like a toy cos cannot be
used in production environment (we are not under little router guys)

i package a new version at the vegnuli OBS deb repository if some one
want to take a look and improved for debian, it seems mantainers are
sleeping since a long time

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#965974: patch available but still happened!

[PICCORO McKAY Lenz]

this but has time.. there-s still happened today?

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#983200: debconf: debian-logo.png is the "Fat Tailed" version

[Philip Hands]

Package: debconf
Version: 1.5.71
Severity: minor

Hi,

I just noticed that the package 'cockpit' displays the version of the logo that
has a fat tail, and looking into what was going on there, I noticed that they
are grabbing the logo from /usr/share/pixmaps/debian-logo.png, which comes from
debconf, hence this bug report.

I've knocked up a replacement PNG, and created a merge request:

  https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/6

which includes a full description of what was done and why.

HTH

Cheers, Phil.

Bug#983199: save.c: include chset.h

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 8d491a71390bbb9ac913a6ae35fa1be91474fc76 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 21 Feb 2021 00:02:33 +
>Subject: [PATCH] save.c: include chset.h

  Error from the compiler:

save.c: In function 'init_save':
save.c:206:6: error: 'curchset' undeclared (first use in this function)
  206 |  curchset->cs_name, "2>&1 |", pager);
  |  ^~~~

Signed-off-by: Bjarni Ingi Gislason 
---
 save.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/save.c b/save.c
index 2b14d6b..cff45a3 100644
--- a/save.c
+++ b/save.c
@@ -22,6 +22,7 @@
 #include "save.h"
 #include "nn_term.h"
 #include "unshar.h"
+#include "chset.h"
 
 /* save.c */
 
-- 
2.30.0



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#983198: torbrowser-launcher: launcher does not detect torbrowser as installed on non-EN user session

[Marcelo Soares Mota]

Package: torbrowser-launcher
Version: 0.3.3-3
Severity: normal
Tags: patch
X-Debbugs-Cc: motasmarc...@gmail.com

Package: torbrowser-launcher
Version: 0.3.3-3
Severity: normal
Tags: patch

Dear Maintainer,

I believe i found an issue with the launcher (somehow related with #842021) 

It happens that though the launcher works it doesn't detect torbrowser
as installed. It causes two issues:
  - The 'Settings' window points status as Not Installed;
  - The 'Browser launcher' keeps running the routines to download and
verify the 'first installation'.

I realized that reload the settings after rebuilding paths makes the
launcher works as expected.

Plus, load_settings() is not checking changes at 'installed' directive
to rewrite the settings file ('settings.json').


Regards,

Marcelo S Mota
Description: fix failure in detect installed torbrowser
Author: Marcelo Soares Mota 
Last-Update: 2021-02-20

--- torbrowser-launcher-0.3.3.orig/torbrowser_launcher/common.py
+++ torbrowser-launcher-0.3.3/torbrowser_launcher/common.py
@@ -64,6 +64,7 @@ class Common(object):
 self.load_mirrors()
 self.load_settings()
 self.build_paths()
+self.load_settings()
 self.mkdir(self.paths["download_dir"])
 self.mkdir(self.paths["tbb"]["dir"])
 self.init_gnupg()
@@ -371,7 +372,10 @@ class Common(object):
 resave = False
 
 # detect installed
-settings["installed"] = os.path.isfile(self.paths["tbb"]["start"])
+installed = os.path.isfile(self.paths["tbb"]["start"])
+if settings["installed"] != installed:
+settings["installed"] = installed
+resave = True
 
 # make sure settings file is up-to-date
 for setting in default_settings:

Bug#983170: s3ql: High load causes "Transport endpoint is not connected"

[Graham Cobb]

Package: s3ql
Version: 3.7.0+dfsg-2
Followup-For: Bug #983170

The mount.log consists of minor variations on the following...

2021-02-20 13:21:46.208 238604:MainThread s3ql.mount.determine_threads: Using 
10 upload threads.
2021-02-20 13:21:46.210 238604:MainThread s3ql.mount.main: Autodetected 1048514 
file descriptors available for cache entries
2021-02-20 13:21:46.982 238604:MainThread s3ql.mount.get_metadata: Using cached 
metadata.
2021-02-20 13:21:47.001 238604:MainThread s3ql.mount.main_async: Setting cache 
size to 17754 MB
2021-02-20 13:21:47.004 238604:MainThread s3ql.block_cache.__init__: Loaded 0 
entries from cache
2021-02-20 13:21:47.040 238604:MainThread s3ql.mount.main_async: Mounting 
s3://eu-west-1/xxx/s3ql/yyy/ at /mnt/a...
2021-02-20 13:21:47.050 238624:MainThread 
s3ql.daemonize.detach_process_context: Daemonizing, new PID is 238625
2021-02-20 13:22:56.691 238625:MainThread s3ql.mount.unmount: Unmounting file 
system...
2021-02-20 13:23:01.703 238625:MainThread s3ql.block_cache.destroy: Could not 
complete object removals, no removal threads left alive
2021-02-20 13:23:01.710 238625:MainThread root.excepthook: Uncaught top-level 
exception:
Traceback (most recent call last):
  File "/usr/bin/mount.s3ql", line 33, in 
sys.exit(load_entry_point('s3ql==3.7.0', 'console_scripts', 'mount.s3ql')())
  File "/usr/lib/s3ql/s3ql/mount.py", line 131, in main
trio.run(main_async, options, stdout_log_handler)
  File "/usr/local/lib/python3.9/dist-packages/trio/_core/_run.py", line 1932, 
in run
raise runner.main_task_outcome.error
  File "/usr/lib/s3ql/s3ql/mount.py", line 274, in main_async
await pyfuse3.main()
  File "/usr/lib/python3/dist-packages/_pyfuse3.py", line 30, in wrapper
await fn(*args, **kwargs)
  File "src/pyfuse3.pyx", line 776, in main
  File "/usr/local/lib/python3.9/dist-packages/trio/_core/_run.py", line 815, 
in __aexit__
raise combined_error_from_nursery
trio.MultiError: NoWorkerThreads('no removal threads'), NoWorkerThreads('no 
removal threads'), NoWorkerThreads('no removal threads'), NoWorkerThreads('no 
removal threads'), NoWorkerThreads('no removal threads'), NoWorkerThreads('no 
removal threads'), NoWorkerThreads('no removal threads'), NoWorkerThreads('no 
removal threads'), NoWorkerThreads('no removal threads'), NoWorkerThreads('no 
removal threads'), NoWorkerThreads('no removal threads'), NoWorkerThreads('no 
removal threads')

Details of embedded exception 1:

  Traceback (most recent call last):
File "/usr/lib/s3ql/s3ql/block_cache.py", line 598, in _deref_block
  self.to_remove.put(obj_id, block=False)
File "/usr/lib/python3.9/queue.py", line 137, in put
  raise Full
  queue.Full

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/_pyfuse3.py", line 30, in wrapper
  await fn(*args, **kwargs)
File "src/internal.pxi", line 278, in _session_loop
File "/usr/lib/s3ql/s3ql/fs.py", line 1172, in forget
  await self.cache.remove(id_, 0, inode.size // self.max_obj_size + 1)
File "/usr/lib/s3ql/s3ql/block_cache.py", line 847, in remove
  await self._deref_block(block_id)
File "/usr/lib/s3ql/s3ql/block_cache.py", line 600, in _deref_block
  await trio.to_thread.run_sync(self._queue_removal, obj_id)
File "/usr/local/lib/python3.9/dist-packages/trio/_threads.py", line 207, 
in to_thread_run_sync
  return await trio.lowlevel.wait_task_rescheduled(abort)
File "/usr/local/lib/python3.9/dist-packages/trio/_core/_traps.py", line 
166, in wait_task_rescheduled
  return (await _async_yield(WaitTaskRescheduled(abort_func))).unwrap()
File "/usr/lib/python3/dist-packages/outcome/_sync.py", line 111, in unwrap
  raise captured_error
File "/usr/local/lib/python3.9/dist-packages/trio/_threads.py", line 157, 
in do_release_then_return_result
  return result.unwrap()
File "/usr/lib/python3/dist-packages/outcome/_sync.py", line 111, in unwrap
  raise captured_error
File "/usr/local/lib/python3.9/dist-packages/trio/_threads.py", line 170, 
in worker_fn
  ret = sync_fn(*args)
File "/usr/lib/s3ql/s3ql/block_cache.py", line 553, in _queue_removal
  raise NoWorkerThreads('no removal threads')
  s3ql.block_cache.NoWorkerThreads: no removal threads

Details of embedded exception 2:

...

embedded exception 2 is a copy of embedded exception 1, and there are another 
10 identical embedded exceptions.

The complete log is available at http://www.cobb.uk.net/s3ql-983170-mount.log.gz

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.utf8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via 

Bug#946118: synaptics touchpad does not work in debian installer graphical mode

[Holger Wansing]

Hi,

Samuel Thibault  wrote (Sat, 7 Dec 2019 22:54:09 +0100):
> Samuel Thibault, le mer. 04 déc. 2019 01:52:36 +0100, a ecrit:
> > Thinking of it... IIRC the touchpad is not working on my DELL XPS13
> > laptop in g-i.
> 
> Indeed, it doesn't work.

Now that the graphical installer uses libinput instead of evdev, maybe it's
worth it to try if it works for you now with latest builds?


Holger



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

Bug#983197: autopkgtest: another difference between qemu and lxc testbeds

[Ryutaroh Matsumoto]

Package: autopkgtest
Version: 5.16
Severity: important
Tags: bullseye sid

Dear Maintainer,

I report here another different behaviors of lxc and qemu testbeds.
The testbeds were made by debci setup -f -s sid -a amd64 -b ...
Tests of debootstrap pass on lxc, but some of them fail on qemu as


not ok 19 - unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/schroot-1.6.10-3 
chroot.d runuser -u nobody -- script -q -c cat /etc/debian_version /dev/null
not ok 20 - script(1) should work under (fake) schroot
#   Failed test 'unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/schroot-1.6.10-3 
chroot.d runuser -u nobody -- script -q -c cat /etc/debian_version /dev/null'
#   at /tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/debian-testing line 
30.
#   Failed test 'script(1) should work under (fake) schroot'
#   at /tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/debian-testing line 
69.
#  got: ''
# expected: 'bullseye/sid'
# Running: unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/schroot-proposed 
chroot.d runuser -u nobody -- script -q -c cat /etc/debian_version /dev/null
# fake-schroot: crw-rw-rw- 1 root tty 5, 2 Feb 20 23:09 chroot.d/dev/ptmx
# fake-schroot: crw-rw-rw- 1 root root 5, 2 Feb 20 23:11 chroot.d/dev/pts/ptmx
# fake-schroot: crw-rw-rw- 1 root root 5, 2 Feb 20 23:11 chroot.d/dev/ptmx
# fake-schroot: crw-rw-rw- 1 root root 5, 2 Feb 20 23:11 chroot.d/dev/pts/ptmx
not ok 25 - unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/schroot-1.6.10-3 
--sbuild chroot.d runuser -u nobody -- script -q -c cat /etc/debian_version 
/dev/null
not ok 26 - script(1) should work under (fake) schroot
script: failed to create pseudo-terminal: No such file or directory
#   Failed test 'unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/schroot-1.6.10-3 
--sbuild chroot.d runuser -u nobody -- script -q -c cat /etc/debian_version 
/dev/null'
#   at /tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/debian-testing line 
30.
#   Failed test 'script(1) should work under (fake) schroot'
#   at /tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/debian-testing line 
69.
#  got: ''
# expected: 'bullseye/sid'
# Running: unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/pbuilder-proposed 
chroot.d runuser -u nobody -- script -q -c cat /etc/debian_version /dev/null
# fake-pbuilder: crw-rw-rw- 1 root root 5, 2 Feb 20 23:11 chroot.d/dev/ptmx
# fake-pbuilder: crw-rw-rw- 1 root root 5, 2 Feb 20 23:11 chroot.d/dev/pts/ptmx
# Running: unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/pbuilder-0.228.4-1 
chroot.d runuser -u nobody -- script -q -c cat /etc/debian_version /dev/null
not ok 47 - unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/schroot-1.6.10-3 
/tmp/autopkgtest.PYPTQP/autopkgtest_tmp/from-nspawn.d runuser -u nobody -- 
script -q -c cat /etc/debian_version /dev/null
not ok 48 - script(1) should work under (fake) schroot
# fake-schroot: crw-rw-rw- 1 root tty 5, 2 Feb 20 23:09 
/tmp/autopkgtest.PYPTQP/autopkgtest_tmp/from-nspawn.d/dev/ptmx
# fake-schroot: crw-rw-rw- 1 root root 5, 2 Feb 20 23:12 
/tmp/autopkgtest.PYPTQP/autopkgtest_tmp/from-nspawn.d/dev/pts/ptmx
# fake-schroot: crw-rw-rw- 1 root root 5, 2 Feb 20 23:12 
/tmp/autopkgtest.PYPTQP/autopkgtest_tmp/from-nspawn.d/dev/ptmx
# fake-schroot: crw-rw-rw- 1 root root 5, 2 Feb 20 23:12 
/tmp/autopkgtest.PYPTQP/autopkgtest_tmp/from-nspawn.d/dev/pts/ptmx
# Running: unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/schroot-proposed 
--sbuild /tmp/autopkgtest.PYPTQP/autopkgtest_tmp/from-nspawn.d runuser -u 
nobody -- script -q -c cat /etc/debian_version /dev/null
not ok 53 - unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/schroot-1.6.10-3 
--sbuild /tmp/autopkgtest.PYPTQP/autopkgtest_tmp/from-nspawn.d runuser -u 
nobody -- script -q -c cat /etc/debian_version /dev/null # TODO schroot 
--sbuild doesn't work when /dev/ptmx is a symlink to /dev/pts/ptmx
#   Failed (TODO) test 'unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/schroot-1.6.10-3 
--sbuild /tmp/autopkgtest.PYPTQP/autopkgtest_tmp/from-nspawn.d runuser -u 
nobody -- script -q -c cat /etc/debian_version /dev/null'
#   at /tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/debian-testing line 
30.
not ok 54 - script(1) should work under (fake) schroot # TODO schroot --sbuild 
doesn't work when /dev/ptmx is a symlink to /dev/pts/ptmx
#   Failed (TODO) test 'script(1) should work under (fake) schroot'
#   at /tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/debian-testing line 
69.
#  got: ''
# expected: 'bullseye/sid'
# fake-pbuilder: crw-rw-rw- 1 root root 5, 2 Feb 20 23:12 
/tmp/autopkgtest.PYPTQP/autopkgtest_tmp/from-nspawn.d/dev/ptmx
# fake-pbuilder: crw-rw-rw- 1 root root 5, 2 Feb 20 23:12 
/tmp/autopkgtest.PYPTQP/autopkgtest_tmp/from-nspawn.d/dev/pts/ptmx

Full log of autopkgtests are 

Bug#980856: bridge-utils: ignores bridge_hw

[Santiago Garcia Mantinan]

> We wouldn't need hwaddress anymore with the new patch, right?

Nope, I have found another problem with the kind of setup that you have, on
this setups brctl addif fails because the interface needs to be configured
by hostapd, and as the code for setting the mac was conditionally tight to
the brctl it would not be executed. I have moved it before the brctl addif
so that it will be executed no matter what. This is on a patch attached to
this bug. That should hopefully solve the final problem with mac setting.

> iface br0 inet dhcp
> bridge_hw enp4s0MAC
> bridge_ports regex (en|wl).*
> post-up ifup /wl*
> iface br0 inet6 auto
> privext 2
> 
> iface enp3s0 inet manual
> iface enp4s0 inet manual

these two iface enp* lines shouldn't be needed at all, the regex on bridge
ports should catch them and bridge-utils should configure the ports.
Like I said before I'd add the bridge_ports to the inet6 definition as well,
the full patch to fix this two definitions will need that info for
everything to run ok.

If you can add the attached patch and test everything it would be great.

Regards...
-- 
Manty/BestiaTester -> http://manty.net
--- /lib/udev/bridge-network-interface~	2021-02-16 13:01:37.0 +0100
+++ /lib/udev/bridge-network-interface	2021-02-21 00:24:11.936523677 +0100
@@ -31,10 +31,10 @@
 if [ -d /sys/class/net/$port ]; then
 	ifup --allow auto $i
 	if [ -f /proc/sys/net/ipv6/conf/$port/disable_ipv6 ]; then echo 1 > /proc/sys/net/ipv6/conf/$port/disable_ipv6;fi
-	brctl addif $i $port && ip link set dev $port up &&
 	if [ "$(ifquery "$i"|sed -n -e's/^bridge[_-]hw: //p')" = "$port" ]; then
 		ip link set dev "$i" address "$(ip link show dev "$port" 2>/dev/null|sed -n "s|.*link/ether \([^ ]*\) brd.*|\1|p")"
 	fi
+	brctl addif $i $port && ip link set dev $port up
 fi
 break
 ;;

Bug#983196: RFP: exwm -- full-featured tiling X window manager for Emacs

[Martin]

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

* Package name: exwm
  Version : 0.24 (2020-05-24)
  Upstream Author : Chris Feng 
* URL : https://github.com/ch11ng/exwm
* License : GPL-3+
  Programming Lang: Emacs-Lisp
  Description : full-featured tiling X window manager for Emacs

EXWM (Emacs X Window Manager) is a full-featured tiling X window
manager for Emacs built on top of XELB. It features:
 - Fully keyboard-driven operations
 - Hybrid layout modes (tiling & stacking)
 - Dynamic workspace support
 - ICCCM/EWMH compliance
 - (Optional) RandR (multi-monitor) support
 - (Optional) Builtin system tray
 - (Optional) Builtin input method

Bug#982984: Mirror blocked due to repeated errors

[Sven Geuer]

Package: apt-cacher-ng
Version: 3.6-1
Followup-For: Bug #982984

same issue here since upgrade to apt-cacher-ng 3.6-1. Packages apparmor-
profiles or apparmor-profiles-extra are not installed.

Sven



-- Package-specific info:

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

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

Versions of packages apt-cacher-ng depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.74
ii  dpkg 1.20.7.1
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-9
ii  libevent-2.1-7   2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libgcc-s110.2.1-6
ii  liblzma5 5.2.5-1.0
ii  libssl1.11.1.1i-3
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-1
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20210119

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.8-5
pn  doc-base  
ii  libfuse2  2.9.9-3

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Keine Berechtigung: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
* apt-cacher-ng/cachedir: keep
* apt-cacher-ng/proxy: keep
* apt-cacher-ng/gentargetmode: Set up now and update later
* apt-cacher-ng/port: keep
* apt-cacher-ng/bindaddress: keep
* apt-cacher-ng/tunnelenable: true

Bug#982755:

[J. Smith]

The emacs-bin-common package does recommend mailutils.
That seems an appropriate level of dependency, given that many won't use Emacs 
for mail at all.

Bug#983195: save.c: define "DO_MIME" and "pager"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 3b6b67d3ad6628029c366f59f34f0576138260d8 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sat, 20 Feb 2021 22:40:56 +
>Subject: [PATCH] save.c: define "DO_MIME" and "pager"

Signed-off-by: Bjarni Ingi Gislason 
---
 save.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/save.c b/save.c
index b35211f..2b14d6b 100644
--- a/save.c
+++ b/save.c
@@ -93,6 +93,7 @@ int print_header_type = SHORT_HEADER;
 #defineDO_UNSHAR   0x2000  /* unshar article (or patch) */
 #defineDO_PATCH0x4000  /* patch article */
 #defineDO_DECODE   0x8000  /* uudecode article */
+#defineDO_MIME 0x1 /* make mime article readable */
 
 /* open modes for open_news_article for the various HEADER_HANDLINGs */
 
@@ -194,6 +195,7 @@ set_folder_type(char *name)
 char   *
 init_save(int command, char **mode_textp)
 {
+extern char*pager;
 char   *mode_text;
 static char last_input[FILENAME] = "";
 static char name_buf[512]; /* buffer for file name expansion */
-- 
2.30.0




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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#960111: lxde: recommends deprecated clipit

[Andriy Grytsenko]

I'm agree, ClipIt needs some alternative. Although from what I saw about
Diodon it integrates into GNOME desktop and as such it will bring start
of bunch of GNOME services (dconf, zeitgeist) which are not started by
the ClipIt of course. Not very good for a desktop environment which is
intended to be lightweight, thus I would not name Diodon as appropriate
tool for LXDE albeit viable one.

Another issue with Diodon is that it is too much minimalistic, it have
neither correct right-click support (it is understandable for GNOME
desktop which is now oriented on touchscreen so no right-click would be
ever supported), nor history management, nor permanent history items, nor
any history list configuration. So far Diodon vs ClipIt is a bycicle vs
Tesla. I'll try to find if some viable alternative could be added beside
clipit. Thank you for your notice.

What is strange about ClipIt is why it was considered as deprecated while
it is still developed (https://github.com/CristianHenzel/ClipIt) by the
upstream, current version is 1.4.5. May be said "deprecated" state was
inspired by some people behind Diodon to kill concurrency? May be it's
better to take over clipit maintenance and return it back into Debian?
I'll try to contact its maintainer for more information.

Bug#983194: imagemagick: broken canvas height autosizing for labels

[Tomáš Szaniszlo]

Package: imagemagick
Version: 8:6.9.11.60+dfsg-1
Severity: normal
X-Debbugs-Cc: tomaxu...@gmail.com

Dear maintainer,

it looks like that probably after an upgrade from 8:6.9.11.24+dfsg-1+b2 to
8:6.9.11.60+dfsg-1 this stopped working correctly:

$ convert -verbose label:text out.jpg
label:text=>text LABEL 20x1 20x1+0+0 16-bit sRGB 0.070u 0:00.082
label:text=>out.jpg LABEL 20x1 20x1+0+0 16-bit GrayscaleAlpha Gray 186B 
0.010u 0:00.000

The problem is that the image has 1px height, so canvas autosizing for labels
is broken for height. However, for width it seems to be ok.

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

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 imagemagick depends on:
ii  imagemagick-6.q16  8:6.9.11.60+dfsg-1

imagemagick recommends no packages.

imagemagick suggests no packages.

-- no debconf information

Bug#981612: epoptes-client: socat[1483] E Failed to set SNI host ""

[Vagrant Cascadian]

Control: found 981612 21.01-1
Control: notfound 981612 1.0.1-2

Marking as notfound for the version in buster, as buster does not have
the socat versions (1.7.4+) that triggers the issue.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#983193: variable.c: define "only_newsrc_groups"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 1b87c008419dbb3979356be4bb0a619cbc971bd2 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sat, 20 Feb 2021 21:48:11 +
>Subject: [PATCH] variable.c: define "only_newsrc_groups"

Signed-off-by: Bjarni Ingi Gislason 
---
 variable.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/variable.c b/variable.c
index d04b5e5..68cc1f0 100644
--- a/variable.c
+++ b/variable.c
@@ -117,7 +117,8 @@ extern int  /* boolean variables */
 keep_backup_folder, keep_rc_backup, keep_unsubscribed, 
keep_unsub_long,
 long_menu, macro_debug, mailer_pipe_input, mark_overlap,
 mark_overlap_shading, match_parts_equal, match_parts_begin,
-monitor_mode, new_read_prompt, novice, old_packname, 
prev_also_read,
+monitor_mode, new_read_prompt, novice, old_packname,
+only_newsrc_groups, prev_also_read,
 preview_mark_read, query_signature, quick_save, 
quick_unread_count,
 read_ret_next_page, repeat_group_query, report_cost_on_exit, 
retain_seen_status,
 save_report, scroll_clear_page, select_leave_next, 
select_on_sender,
-- 
2.30.0


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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#982984: Mirror blocked due to repeated errors

[Eduard Bloch]

Hallo,
* Michael Tokarev [Sun, Feb 21 2021, 12:16:06AM]:
> Getting these errors here too, restart of apt-cacher-ng
> does NOT help in my case (so I'm basically unable to use apt
> anymore, will have to drop usage of the cacher).
>
> The log contains this message for every access to the cache:
>
>  apt-cacher-ng[xxx]: [warn] Call to getaddrinfo_async with no evdns_base 
> configured.

I tried to reproduce it but couldn't so far. I admit that there is no
error handling for the failing creation of evdns_base, though. And I have a
strange feeling that it might be connected to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983006 .

Do you all have apparmor-profiles-extra installed?

Best regards,
Eduard.

Bug#982756:

[J. Smith]

Presumably this is https://bugs.debian.org/968955 , an issue in 
dictionaries-common that was fixed last August.

Bug#983110: buster-pu: package ipmitool/1.8.18-6 (CVE-2020-5208)

[Thomas Goirand]

On 2/19/21 8:38 PM, Salvatore Bonaccorso wrote:
> Thanks for preparing this update! For the buster update, please adjust
> the target distribution to 'buster'.
> 
> Regards,
> Salvatore

Sure. I just attached the debdiff that I prepared for buster-security,
without rebuilding. I'll rebuild accordingly when I get the go-head from
Adam or Julien.

Cheers,

Thomas Goirand (zigo)

Bug#983192: variable.c: define "keep_active_file"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 614f794778ddfdb9629a7540888592a215ac154f Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sat, 20 Feb 2021 21:34:37 +
>Subject: [PATCH] variable.c: define "keep_active_file"

Signed-off-by: Bjarni Ingi Gislason 
---
 variable.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/variable.c b/variable.c
index 3c50f79..d04b5e5 100644
--- a/variable.c
+++ b/variable.c
@@ -113,6 +113,7 @@ extern int  /* boolean variables */
 folder_format_check, folder_rewrite_trace, guard_double_slash,
 ignore_formfeed, ignore_xon_xoff, ignore_re, include_art_id,
 include_full_header, include_mark_blanks, inews_pipe_input,
+keep_active_file,
 keep_backup_folder, keep_rc_backup, keep_unsubscribed, 
keep_unsub_long,
 long_menu, macro_debug, mailer_pipe_input, mark_overlap,
 mark_overlap_shading, match_parts_equal, match_parts_begin,
-- 
2.30.0


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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#932093: Bug#944114: Missing directory spec in Remap secdeb rule

[Ryan Tandy]

On Sat, Feb 20, 2021 at 07:48:41PM +0100, Eduard Bloch wrote:

Ok, so I think the default configuration has been PITA for some people
for the last couple of years and I am sorry. I intend to modify the
default mapping as shown below, or see:

https://salsa.debian.org/blade/apt-cacher-ng/-/commit/3090d97ed9794a64f509917c77f0bb7ebccf1fbf

Is this something we can agree on? I am not so sure about using
deb.debian.org as default backend.


Looks good to me. Including both security.d.o and deb.d.o as backends 
seems reasonable. I don't have any idea about which would be better as 
default. AFAIK security.d.o is also some kind of CDN, or at least 
mirrored/aliased.


Thanks again for maintaining acng.
Ryan

Bug#982984: Mirror blocked due to repeated errors

[Michael Tokarev]

Getting these errors here too, restart of apt-cacher-ng
does NOT help in my case (so I'm basically unable to use apt
anymore, will have to drop usage of the cacher).

The log contains this message for every access to the cache:

 apt-cacher-ng[xxx]: [warn] Call to getaddrinfo_async with no evdns_base 
configured.

/mjt

Bug#983180: Wrong status report: all files shown as deleted

[Philipp Marek]

Package: git-gui
Version: 1:2.30.1+next.20210212-1
Severity: minor
X-Debbugs-Cc: phil...@marek.priv.at

"git gui" is sensitive to its starting conditions.

In a git checkout with some changes do the following steps:

- start to commit something: # git commit -a
- in your $EDITOR, decide to run git gui. For vim:   :!git gui &
- Now commit (or don't); just quit your editor.
- Press F5 in "git gui" to refresh the view.
  => all files are shown as deleted, and as new files as well.


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

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

Versions of packages git-gui depends on:
ii  git  1:2.30.1+next.20210212-1
ii  tk   8.6.11

Versions of packages git-gui recommends:
ii  gitk  1:2.30.1+next.20210212-1

Versions of packages git-gui suggests:
ii  aspell   0.60.8-2
pn  git-doc  
pn  meld 

-- no debconf information

Bug#983179: zfs-dkms: fails to build with backports kernel 5.10.0-0.bpo.3-amd64

[Christian Garbs]

Package: zfs-dkms
Version: 0.8.6-1~bpo10+1
Severity: important

Dear Maintainer,

   * What led up to the situation?

The kernel in stretch-backports was updated from 5.9.0-0.bpo.5-amd64
to 5.10.0-0.bpo.3-amd64.  After rebooting, I was dropped to the
initramfs rescue shell because my ZFS root file system could not be
mounted.

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

The last time this has happened, the zfs-dkms module build did not run
automaticalls and thus the zfs modules were missing from the initrd.
I have since fixed this by setting REMAKE_INITRD='yes' in
/etc/dkms/zfs.conf, but my first guess was that it has somehow gone
wrong again.

So I booted up the previous kernel (really grateful for that option)
and tried to do a manual install of zfs-dkms via

$ dkms install -k 5.10.0-0.bpo.3-amd64 zfs/0.8.6

   * What was the outcome of this action?

The compilation of the module failed, which explains why the ZFS
modules were not included in the initrd in the first place.

Compilation log shows this as the source of the error:

 - - - 8< - - -

  CC [M]  /var/lib/dkms/zfs/0.8.6/build/module/zfs/vdev_disk.o
/var/lib/dkms/zfs/0.8.6/build/module/zfs/vdev_disk.c: In function 
‘vdev_blkg_tryget’:
/var/lib/dkms/zfs/0.8.6/build/module/zfs/vdev_disk.c:506:37: error: ‘struct 
percpu_ref’ has no member named ‘count’
   rc = atomic_long_inc_not_zero(>count);
 ^~
make[6]: *** 
[/usr/src/linux-headers-5.10.0-0.bpo.3-common/scripts/Makefile.build:284: 
/var/lib/dkms/zfs/0.8.6/build/module/zfs/vdev_disk.o] Error 1

 - - - >8 - - -


   * What outcome did you expect instead?

I had expected zfs-dkms to build without failure, update my initrd and
be able to boot into the current stretch-backports kernel.

Due to some issues with Intel onboard graphics, I need to use the
newer backports kernel instead of the the original stretch kernel.



btw: Is there any way I can tell the kernel installer or the initramfs
creation to fail if the the ZFS module has not been compiled?



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

Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  dkms   2.6.1-4
ii  file   1:5.35-4+deb10u2
ii  libc6-dev [libc-dev]   2.28-10
ii  libpython3-stdlib  3.7.3-1
ii  lsb-release10.2019051400
ii  perl   5.28.1-6+deb10u1
ii  python3-distutils  3.7.3-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  4.19.171-2
ii  zfs-zed 0.8.6-1~bpo10+1
ii  zfsutils-linux  0.8.6-1~bpo10+1

Versions of packages zfs-dkms suggests:
pn  debhelper  

-- debconf information:
  zfs-dkms/stop-build-for-unknown-kernel: true
* zfs-dkms/note-incompatible-licenses:
  zfs-dkms/stop-build-for-32bit-kernel: true

Bug#983191: Add code to create a "mime_command" to display articles with a different encoding

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From fded6b930c7d30c01e5da75bb44e58c3432af06b Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sat, 20 Feb 2021 19:15:05 +
>Subject: [PATCH] Add code to create a "mime_command" to display articles with
> a different encoding

  The name of the variable "mime_command" is a command,
that changes the encoding of a article to that,
what the user uses,
so it can be read.

  It is set in the init file.

  The default name is "nnmime".

  "mime_command" was created in analogy to "patch_command".

save.c: add the code here

variable.c: add definitions of "mime_command" and "edit_mime_command"
here.

Signed-off-by: Bjarni Ingi Gislason 
---
 save.c | 25 +
 variable.c |  4 ++--
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/save.c b/save.c
index 35c0a52..b35211f 100644
--- a/save.c
+++ b/save.c
@@ -59,6 +59,9 @@ int edit_patch_command = 1;
 charunshar_command[FILENAME] = SHELL;
 int edit_unshar_command = 0;
 
+charmime_command[FILENAME] = "";
+int edit_mime_command = 1;
+
 extern char*temp_file;
 extern int  shell_restrictions;
 extern char delayed_msg[];
@@ -196,6 +199,11 @@ init_save(int command, char **mode_textp)
 static char name_buf[512]; /* buffer for file name expansion */
 char   *start, *last, *np;
 
+if (mime_command[0] == NUL) {
+   snprintf(mime_command, FILENAME, "%s %s %s %s", "nnmime -c",
+   curchset->cs_name, "2>&1 |", pager);
+}
+
 uniq_counter = 0;
 short_header_lines = save_header_lines;
 
@@ -313,6 +321,23 @@ init_save(int command, char **mode_textp)
unshar_cmd = patch_command;
goto unshar1;
 
+   case K_MIME:
+   save_mode = FULL_HEADER | IS_PIPE | DO_MIME;
+   mode_text = "Mime";
+   if (!shell_restrictions && edit_mime_command) {
+   prompt("\1Mime command:\1 ");
+   save_name = get_s(NONE, mime_command, NONE, NULL_FCT);
+   if (save_name == NULL || *save_name == NUL)
+   return NULL;
+   strcpy(mime_command, save_name);
+   }
+   if (!edit_mime_command)
+   save_name = mime_command;
+/* unshar_cmd = mime_command; */
+   clrdisp();
+   fl; /* May be irrelevant */
+   break;
+
case K_UNSHAR:
save_mode = NO_HEADER | SEPARATE_FILES | DO_UNSHAR;
mode_text = "Unshar";
diff --git a/variable.c b/variable.c
index 0709b95..3c50f79 100644
--- a/variable.c
+++ b/variable.c
@@ -91,7 +91,7 @@ extern char   /* string variables */
*folder_save_file, *header_lines, *folder_directory, 
included_mark[],
*inews_program, *initial_newsrc_path, *mail_alias_expander,
*mail_box, *mail_record, *mail_script, *mailer_program,
-attributes[], *newsrc_file, *news_record, *news_script,
+   attributes[], mime_command[], *newsrc_file, *news_record, 
*news_script,
*pager, patch_command[], printer[], *print_header_lines,
*response_dflt_answer, *save_counter_format, *save_header_lines,
*saved_header_escape, *shade_on_attr, *shade_off_attr, 
*spell_checker,
@@ -107,7 +107,7 @@ extern int  /* boolean variables */
 conf_junk_seen, consolidated_manual, consolidated_menu,
 counter_padding, decode_keep, delay_redraw, dflt_kill_select,
 do_kill_handling, dont_sort_articles, dont_sort_folders,
-dont_split_digests, echo_prefix_key, edit_patch_command,
+dont_split_digests, echo_prefix_key, edit_mime_command, 
edit_patch_command,
 edit_print_command, edit_unshar_command, empty_answer_check,
 enter_last_read_mode, flow_control, flush_typeahead, 
fmt_rptsubj,
 folder_format_check, folder_rewrite_trace, guard_double_slash,
-- 
2.30.0



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#982175: #982175 task-japanese-desktop: should explicitly prefer mozc over anthy

[Holger Wansing]

Adding debian-japanese@l.d.o to the loop


> Package: task-japanese-desktop
> Version: 3.63
> Tags: bullseye patch
> Priority: important
> 
> Dear Maintainer,
> 
> Most Japanese users prefer "mozc" over "anthy" among several Japanese
> input method engines.
> Because mozc is supported upstream in limited architectures (x86 and
> arm related only)
> anthy has been used as a fall-back.
> However, the recent bullseye debian installer does not configure the
> system as expected.
> 
> When the buster (or earlier) debian installer installs japanese-desktop task
> it configures (runs postinst maintainer scripts of) the uim-* input
> method packages in the following order:
> uim-anthy
> uim-mozc
> 
> buster dpkg.log:
> 2021-01-31 12:47:57 install uim-anthy:all <なし> 1:1.8.8-4+deb10u3
> 2021-01-31 12:47:57 status half-installed uim-anthy:all 1:1.8.8-4+deb10u3
> 2021-01-31 12:47:57 status unpacked uim-anthy:all 1:1.8.8-4+deb10u3
> (snip)
> 2021-01-31 12:51:44 install uim-mozc:amd64 <なし> 2.23.2815.102+dfsg-4
> 2021-01-31 12:51:44 status half-installed uim-mozc:amd64 2.23.2815.102+dfsg-4
> 2021-01-31 12:51:44 status unpacked uim-mozc:amd64 2.23.2815.102+dfsg-4
> (snip)
> 2021-01-31 12:53:58 configure uim-anthy:all 1:1.8.8-4+deb10u3 <なし>
> 2021-01-31 12:53:58 status unpacked uim-anthy:all 1:1.8.8-4+deb10u3
> 2021-01-31 12:53:58 status half-configured uim-anthy:all 1:1.8.8-4+deb10u3
> 2021-01-31 12:53:58 status installed uim-anthy:all 1:1.8.8-4+deb10u3
> (snip)
> 2021-01-31 12:54:04 configure uim-mozc:amd64 2.23.2815.102+dfsg-4 <なし>
> 2021-01-31 12:54:04 status unpacked uim-mozc:amd64 2.23.2815.102+dfsg-4
> 2021-01-31 12:54:04 status half-configured uim-mozc:amd64 2.23.2815.102+dfsg-4
> 2021-01-31 12:54:04 status installed uim-mozc:amd64 2.23.2815.102+dfsg-4
> 
> which makes uim input method framework configured in the desirable
> preference ordering,
> because the uim-* input method packages are structured as LIFO: last
> configured package is preferred first.
> 
> However, the recent bullseye debian installer (perhaps recent apt or
> dpkg algorithm) has been changed for some reason. It configures the
> uim-* input method packages in the following order:
> uim-mozc
> uim-anthy
> 
> bullseye dpkg.log:
> 2021-01-31 10:55:44 install uim-anthy:all  1:1.8.8-7
> 2021-01-31 10:55:44 status half-installed uim-anthy:all 1:1.8.8-7
> 2021-01-31 10:55:44 status unpacked uim-anthy:all 1:1.8.8-7
> (snip)
> 2021-01-31 10:58:47 install uim-mozc:amd64  2.26.4220.100+dfsg-2
> 2021-01-31 10:58:47 status half-installed uim-mozc:amd64 2.26.4220.100+dfsg-2
> 2021-01-31 10:58:47 status unpacked uim-mozc:amd64 2.26.4220.100+dfsg-2
> (snip)
> 2021-01-31 11:00:36 configure uim-mozc:amd64 2.26.4220.100+dfsg-2 
> 2021-01-31 11:00:36 status unpacked uim-mozc:amd64 2.26.4220.100+dfsg-2
> 2021-01-31 11:00:36 status half-configured uim-mozc:amd64 2.26.4220.100+dfsg-2
> 2021-01-31 11:00:36 status installed uim-mozc:amd64 2.26.4220.100+dfsg-2
> (snip)
> 2021-01-31 11:00:38 configure uim-anthy:all 1:1.8.8-7 
> 2021-01-31 11:00:38 status unpacked uim-anthy:all 1:1.8.8-7
> 2021-01-31 11:00:38 status half-configured uim-anthy:all 1:1.8.8-7
> 2021-01-31 11:00:38 status installed uim-anthy:all 1:1.8.8-7
> 
> Since depending on the dpkg configuration order is inherently fragile,
> it should be avoided.
> It should be better to adjust the dependency field in the task package.
> The attached patch should fix this problem.

What do Japanese people think about this?
Would you support prefering mozc over anthy?


Holger




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

Bug#940821: NFS Caching broken in 4.19.37

[Chuck Lever]

> On Feb 20, 2021, at 3:13 PM, Anton Ivanov  
> wrote:
> 
> On 20/02/2021 20:04, Salvatore Bonaccorso wrote:
>> Hi,
>> 
>> On Mon, Jul 08, 2019 at 07:19:54PM +0100, Anton Ivanov wrote:
>>> Hi list,
>>> 
>>> NFS caching appears broken in 4.19.37.
>>> 
>>> The more cores/threads the easier to reproduce. Tested with identical
>>> results on Ryzen 1600 and 1600X.
>>> 
>>> 1. Mount an openwrt build tree over NFS v4
>>> 2. Run make -j `cat /proc/cpuinfo | grep vendor | wc -l` ; make clean in a
>>> loop
>>> 3. Result after 3-4 iterations:
>>> 
>>> State on the client
>>> 
>>> ls -laF 
>>> /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
>>> 
>>> total 8
>>> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
>>> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
>>> 
>>> State as seen on the server (mounted via nfs from localhost):
>>> 
>>> ls -laF 
>>> /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
>>> total 12
>>> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
>>> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
>>> -rw-r--r-- 1 anivanov anivanov   32 Jul  8 11:40 ipcbuf.h
>>> 
>>> Actual state on the filesystem:
>>> 
>>> ls -laF 
>>> /exports/work/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
>>> total 12
>>> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
>>> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
>>> -rw-r--r-- 1 anivanov anivanov   32 Jul  8 11:40 ipcbuf.h
>>> 
>>> So the client has quite clearly lost the plot. Telling it to drop caches and
>>> re-reading the directory shows the file present.
>>> 
>>> It is possible to reproduce this using a linux kernel tree too, just takes
>>> much more iterations - 10+ at least.
>>> 
>>> Both client and server run 4.19.37 from Debian buster. This is filed as
>>> debian bug 931500. I originally thought it to be autofs related, but IMHO it
>>> is actually something fundamentally broken in nfs caching resulting in cache
>>> corruption.
>> According to the reporter downstream in Debian, at
>> https://bugs.debian.org/940821#26 thi seem still reproducible with
>> more recent kernels than the initial reported. Is there anything Anton
>> can provide to try to track down the issue?
>> 
>> Anton, can you reproduce with current stable series?
> 
> 100% reproducible with any kernel from 4.9 to 5.4, stable or backports. It 
> may exist in earlier versions, but I do not have a machine with anything 
> before 4.9 to test at present.

Confirming you are varying client-side kernels. Should the Linux
NFS client maintainers be Cc'd?


> From 1-2 make clean && make  cycles to one afternoon depending on the number 
> of machine cores. More cores/threads the faster it does it.
> 
> I tried playing with protocol minor versions, caching options, etc - it is 
> still reproducible for any nfs4 settings as long as there is client side 
> caching of metadata.
> 
> A.
> 
>> 
>> Regards,
>> Salvatore
>> 
> 
> -- 
> Anton R. Ivanov
> Cambridgegreys Limited. Registered in England. Company Number 10273661
> https://www.cambridgegreys.com/

--
Chuck Lever

Bug#983190: [Pkg-javascript-devel] Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler

[Jonas Smedegaard]

Quoting Sascha Steinbiss (2021-02-20 20:56:13)
> If you are wondering why there haven't been any updates lately, I am 
> sad to announce that current versions of datatables.js does not build 
> anymore with the old version of closure-compiler in Debian.

Looks like it does not really need to use closure-compiler, so I would 
suggest to instead use uglifyjs.

Patch attached.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private--- a/build/include.sh
+++ b/build/include.sh
@@ -124,14 +124,7 @@
 		cp $DIR/$FILE.js $TMPDIR/$FILE.js
 		perl -i -0pe "s/^\/\*! (.*)$/\/** \@license \$1/s" $TMPDIR/$FILE.js
 
-		rm -f $TMPDIR/closure_error.log || true
-		java -jar $CLOSURE --charset 'utf-8' --js $TMPDIR/$FILE.js > $TMPDIR/$FILE.min.js 2> $TMPDIR/closure_error.log
-
-		if [ -e $TMPDIR/closure_error.log ]; then
-			if [ -z "$LOG" -o "$LOG" = "on" ]; then
-cat $TMPDIR/closure_error.log
-			fi
-		fi
+		uglifyjs $TMPDIR/$FILE.js > $TMPDIR/$FILE.min.js
 
 		# And add the important comment back in
 		perl -i -0pe "s/^\/\*/\/*!/s" $TMPDIR/$FILE.min.js


signature.asc
Description: signature

Bug#940821: NFS Caching broken in 4.19.37

[Anton Ivanov]

On 20/02/2021 20:04, Salvatore Bonaccorso wrote:

Hi,

On Mon, Jul 08, 2019 at 07:19:54PM +0100, Anton Ivanov wrote:

Hi list,

NFS caching appears broken in 4.19.37.

The more cores/threads the easier to reproduce. Tested with identical
results on Ryzen 1600 and 1600X.

1. Mount an openwrt build tree over NFS v4
2. Run make -j `cat /proc/cpuinfo | grep vendor | wc -l` ; make clean in a
loop
3. Result after 3-4 iterations:

State on the client

ls -laF 
/var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm

total 8
drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../

State as seen on the server (mounted via nfs from localhost):

ls -laF 
/var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
total 12
drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
-rw-r--r-- 1 anivanov anivanov   32 Jul  8 11:40 ipcbuf.h

Actual state on the filesystem:

ls -laF 
/exports/work/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
total 12
drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
-rw-r--r-- 1 anivanov anivanov   32 Jul  8 11:40 ipcbuf.h

So the client has quite clearly lost the plot. Telling it to drop caches and
re-reading the directory shows the file present.

It is possible to reproduce this using a linux kernel tree too, just takes
much more iterations - 10+ at least.

Both client and server run 4.19.37 from Debian buster. This is filed as
debian bug 931500. I originally thought it to be autofs related, but IMHO it
is actually something fundamentally broken in nfs caching resulting in cache
corruption.

According to the reporter downstream in Debian, at
https://bugs.debian.org/940821#26 thi seem still reproducible with
more recent kernels than the initial reported. Is there anything Anton
can provide to try to track down the issue?

Anton, can you reproduce with current stable series?


100% reproducible with any kernel from 4.9 to 5.4, stable or backports. 
It may exist in earlier versions, but I do not have a machine with 
anything before 4.9 to test at present.


From 1-2 make clean && make  cycles to one afternoon depending on the 
number of machine cores. More cores/threads the faster it does it.


I tried playing with protocol minor versions, caching options, etc - it 
is still reproducible for any nfs4 settings as long as there is client 
side caching of metadata.


A.



Regards,
Salvatore



--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

Bug#983116: im-config: does not work under wayland and zsh as login shell

[Gunnar Hjalmarsson]

It's worth mentioning that the underlying issue is not im-config 
specific. Related open zsh bugs are  
(Debian) and  (Ubuntu).


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

Bug#940821: closed by Bastian Blank (No response by submitter)

[Salvatore Bonaccorso]

Control: reopen -1

Hi Anton,

On Sat, Feb 20, 2021 at 12:59:17PM +, Anton Ivanov wrote:
> On 20/02/2021 10:33, Debian Bug Tracking System wrote:
> > This is an automatic notification regarding your Bug report
> > which was filed against the src:linux package:
> > 
> > #940821: linux-image-5.2.0-2-amd64: file cache corruption with nfs4
> > 
> > It has been closed by Bastian Blank .
> > 
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Bastian Blank 
> >  by
> > replying to this email.
> > 
> > 
> I missed the question. Probably hit the spam bucket for some reason.
> 
> I am able to reproduce it with more recent versions as well.
> 
> The most recent one I have around is 5.4.0-0.bpo.2-amd64
> 
> Still reproducible 100% - just tested it.
> 
> It is trivial to reproduce if anyone actually bothers to do so. Just grab a
> big enough tree where make runs truly in parallel - openwrt is best, but
> even the Linux kernel does the job.
> 
> Mount it via nfs4 from another server (it will work even locally, but takes
> longer to reproduce - may take a whole afternoon)
> 
> Run while make -j 12 clean && make -j 12 ; do true ; done
> 
> Leave it to run. On 6 cores/12 threads it takes 2-3 builds of openwrt or ~
> 5-8 linux kernel builds to blow up. More cores - faster. Less cores slower.
> 
> I sent it to the mailing list too, but nobody could be bothered to even ask
> any questions.

Let's reopen then but can you try to followup with upstream? I think
that's the best place to handle the issue. 5.4.0-0.bpo.2-amd64 is in
meanwhile as well quite behind, can you still reproduce it with the
current stable series? Most ucrrent in backports is 5.10.13 based.

Regards,
Salvatore

Bug#940821: NFS Caching broken in 4.19.37

[Salvatore Bonaccorso]

Hi,

On Mon, Jul 08, 2019 at 07:19:54PM +0100, Anton Ivanov wrote:
> Hi list,
> 
> NFS caching appears broken in 4.19.37.
> 
> The more cores/threads the easier to reproduce. Tested with identical
> results on Ryzen 1600 and 1600X.
> 
> 1. Mount an openwrt build tree over NFS v4
> 2. Run make -j `cat /proc/cpuinfo | grep vendor | wc -l` ; make clean in a
> loop
> 3. Result after 3-4 iterations:
> 
> State on the client
> 
> ls -laF 
> /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
> 
> total 8
> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
> 
> State as seen on the server (mounted via nfs from localhost):
> 
> ls -laF 
> /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
> total 12
> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
> -rw-r--r-- 1 anivanov anivanov   32 Jul  8 11:40 ipcbuf.h
> 
> Actual state on the filesystem:
> 
> ls -laF 
> /exports/work/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
> total 12
> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
> -rw-r--r-- 1 anivanov anivanov   32 Jul  8 11:40 ipcbuf.h
> 
> So the client has quite clearly lost the plot. Telling it to drop caches and
> re-reading the directory shows the file present.
> 
> It is possible to reproduce this using a linux kernel tree too, just takes
> much more iterations - 10+ at least.
> 
> Both client and server run 4.19.37 from Debian buster. This is filed as
> debian bug 931500. I originally thought it to be autofs related, but IMHO it
> is actually something fundamentally broken in nfs caching resulting in cache
> corruption.

According to the reporter downstream in Debian, at
https://bugs.debian.org/940821#26 thi seem still reproducible with
more recent kernels than the initial reported. Is there anything Anton
can provide to try to track down the issue?

Anton, can you reproduce with current stable series?

Regards,
Salvatore

Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler

[Sascha Steinbiss]

Source: datatables.js
Severity: normal


If you are wondering why there haven't been any updates lately, I am sad
to announce that
current versions of datatables.js does not build anymore with the old
version of
closure-compiler in Debian. So far (up to 1.10.21) I managed to keep it
building
but we now have reached a point where some of the features used by
upstream start
to confuse the parser to the point of bailing out.
This is a log of the build for the current latest upstream version:

  DataTables build (1.10.23) - branch: master

  JS
  JSHint not installed at /usr/bin/jshint - skipping
JS compressing jquery.dataTables.js
  File size: 83936
JS compressing dataTables.bootstrap5.js
  File size: 2058
JS compressing dataTables.bootstrap4.js
  File size: 2098
JS compressing dataTables.bootstrap.js
  File size: 1979
JS compressing dataTables.bulma.js
/tmp/jquery-datatables.2247.HN3wa/dataTables.bulma.js:170: ERROR - Parse
error. missing ; before statement
let nav = $('');
^
  [...]

  CSS
CSS compressing dataTables.bootstrap5.css
Error: Invalid CSS after "both": expected expression (e.g. 1px, bold),
was ";"
on line 7 of
/build/datatables.js-1.10.23+dfsg/build/../built/css/dataTables.bootstrap5.css
  Use --trace for backtrace.
  File size: 0

I have seen #916145 and I am wondering what to do. Since I'm not a JS guy I
can't say if (or for how long) we might be able to patch our way around
this.
Otherwise it looks like we're going to be stuck with 1.10.21 for the
time being.

Cheers
Sascha

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

Bug#983091: xapian-core FTBFS on i386: test failure

[Olly Betts]

On Fri, Feb 19, 2021 at 11:36:46AM +0200, Adrian Bunk wrote:
> With the old debian/rules the test was only run with
> the SSE build.
> 
> If exact results are required and the x87 excess precision is unwanted,
> test with the non-SSE build can be fixed with:
> 
> --- debian/rules.old  2021-02-18 15:12:59.097207579 +
> +++ debian/rules  2021-02-18 15:13:51.537168694 +
> @@ -51,6 +51,10 @@
>  
>  export DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
>  
> +ifneq (,$(filter $(DEB_HOST_ARCH), i386 m68k))
> +export DEB_CXXFLAGS_MAINT_APPEND += -ffloat-store
> +endif
> +
>  # For i386 and *-i386.
>  ifeq ($(patsubst %-i386,i386,$(DEB_HOST_ARCH)), i386)
>  XAPIAN_BUILD_SSE := 1

Thanks for the report, and for tracking this down to excess precision.

The upstream code is meant to address excess precision in the small
number of places where it matters but I guess there's a newer instance
that hasn't been caught before, or a newer testcase uncovers an existing
problem (or perhaps newer GCC optimises differently and that's uncovered
this.)

The SSE2 build will get used by more i386 systems, so the overhead
from -ffloat-store won't affect many there at least, but it is a bit of
heavy hammer.  I'll take a look and see if I can fix this in a more
targetted way.  If not applying this for bullseye seems reasonable.
Or we could change the tests back to run just for the SSE2 build for
now - in real world use exact results are rarely a requirement, but
performance often is.

Cheers,
Olly

Bug#983170: s3ql: High load causes "Transport endpoint is not connected"

[Francesco P. Lovergine]

On Sat, Feb 20, 2021 at 01:24:16PM +, Graham Cobb wrote:

Package: s3ql
Version: 3.7.0+dfsg-2
Severity: important

Dear Maintainer,

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

  * What led up to the situation?
  * What exactly did you do (or not do) that was effective (or
ineffective)?
  * What was the outcome of this action?
  * What outcome did you expect instead?

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

After upgrading s3ql from 3.3.2+dfsg-1 I suffered from bug #982381 (trio) so
I tried manually installing trio 0.15 (as mentioned in that thread).
Although it allowed some files to be created, any long or complex operation
(such as a backup, or even an `rm -rf` of a large directory) cause a
'Software caused connection abort' error followed by
enormous numbers of 'Transport endpoint is not connected' errors.

In case it was some transient network problem, I used fsck.s3ql to fix the
filesystem and retried - same errors. And the same errors if I (fsck again
and) just try a `rm -rf` on a large directory.

I then tried installing trio 0.18. Same problem.

Mounting is working. fsck is working. Simple file operations are working.
But heavy load causes 'Software caused connection abort'. Completely repeatable.

The following commands reproduce the problem for me:

cd /mnt/mountpoint
count=100
mkdir testdir ; for f in `seq 1 $count` ; do mkdir testdir/$f ; dd 
if=/dev/urandom  bs=1000 count=1 of=testdir/$f/test status=none ; done
rm -rf testdir
umount /mnt/mountpoint

With the count at 100 the problem occurs when the unmount happens. If the count
is increased to 2000 the problem occurs during the run.

This is using the S3 backend.

By the way, this workload has been working for many years with no problems,
and was working with 3.3.2+dfsg-1 before I decided to try testing 3.7.0+dfsg-2.



Could you please follow-up with your ~/.s3ql/mount.log log about the error?

--
Francesco P. Lovergine

Bug#949519: sudo-ldap: Fails to connect to LDAP : "ldap_sasl_bind_s(): Can't contact LDAP server"

[Dennis Filder]

Control: tag -1 + moreinfo unreproducible

Jean-Christophe, are you still interested in figuring this out?  If so
you need to provide more information.  You also don't say what else
you have tried to investigate this.

I tried reproducing your observed behaviour, but it doesn't manifest
here unless I put "TLS_REQCERT allow" into my normal user's ~/.ldaprc
file (which is not a bug, but a misconfiguration).

"ldap_sasl_bind_s(): Can't contact LDAP server" is really just a
generic TLS error which could have a million different causes.  Some
ideas what could be going on:

* The certificates may have been generated with outdated TLS
  parameters or the server is running outdated configuration options.
  I recall that during the move to buster OpenSSL changed its default
  settings for what versions of TLS it still allows (TLS_CIPHER_SUITE,
  TLS_PROTOCOL_MIN).  Give us the output of:

  openssl s_client -debug -connect server2.mydomain.com:636 -verify 255 
 /tmp/sudo-l-strace.gz

  Also to turn off any initialization mechanisms run your ldapsearch
  commands like this:

  LDAPNOINIT=1 ldapsearch -x -H ...

  Tell us if this changes anything.

Until you can give us something that clearly points to the code of
sudo-ldap doing something it shouldn't we have to assume that this is
due to a misconfiguration.


Regards,
Dennis.

Bug#983086: zfsutils-linux: TRIM crashes SSD drives

[Antonio Russo]

Hello,

On 2/19/21 1:35 AM, Xavier wrote:
> 
> The recently added cron "TRIM the first Sunday of every month" makes some SSD 
> drives crash.
> 
> The problem appears on reasonnably busy and otherwise stable servers:
>* with about 100 containers,
>* each on a separate zvol, ext4 mounted with discard option,
>* on a 6 identical drives raidz2.
> 
> The issue has been observed on these drives:
>* Micron_5100_MTFDDAK960TCB
>* Samsung_SSD_850_EVO_1TB
>* Samsung_SSD_860_EVO_1TB
> 
> When affected (it not always the case), the systems could not complete the 
> cancelling of the trim with:
> # zpool trim -c pool
> Testing trim on one drive only, and reducing the rate to as low as 50, 
> did not help.

I am trying to understand the symptom---what exactly do you mean the "SSD 
drives crash"?
Is it just that you cannot cancel the trim? Or is there some other symptom?

> 
> A reset seems the only solution, followed by a zpool trim -c after reboot.
> 
> It would be wise to deactivate that cron by default, or at least to provide 
> some kind of convenient way to do so, like an option in /etc/default/zfs.
> 
> Thank you.
> 
> -- System Information:
> Debian Release: 10.8
>   APT prefers stable
>   APT policy: (900, 'stable'), (500, 'stable-updates'), (400, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.4.19 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages zfsutils-linux depends on:
> ii  libblkid12.33.1-0.1
> ii  libc62.31-9
> ii  libnvpair1linux  0.8.6-1~bpo10+1
> ii  libudev1 241-7~deb10u6
> ii  libuuid1 2.33.1-0.1
> ii  libuutil1linux   0.8.6-1~bpo10+1
> ii  libzfs2linux 0.8.6-1~bpo10+1
> ii  libzpool2linux   0.8.6-1~bpo10+1
> ii  python3  3.9.1-1
> ii  zlib1g   1:1.2.11.dfsg-1
> 
> Versions of packages zfsutils-linux recommends:
> ii  lsb-base10.2019051400
> ii  zfs-dkms [zfs-modules]  2.0.2-1
> ii  zfs-zed 0.8.6-1~bpo10+1
> 
> Versions of packages zfsutils-linux suggests:
> pn  nfs-kernel-server   
> pn  samba-common-bin
> pn  zfs-initramfs | zfs-dracut  
> 
> -- Configuration Files:
> /etc/default/zfs changed [not included]
> /etc/zfs/zfs-functions changed [not included]
> 
> -- no debconf information

You do not have a consistent set of zfs packages installed---please
fully upgrade to 2.0.3 (or at least 2.0.2).  You have zfs-dkms from
unstable, and the rest of zfs from backports.  I don't know exactly
what you've done to get this setup, but it is not a supported
configuration, and may be dangerous to your data.

Best,
Antonio


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#983189: mailman3-web should only depend on uwsgi-core, ont uwsgi

[Thomas Koch]

Package: mailman3-web
Version: 0+20200530-1

I believe, mailman3-web could depend just on uwsgi-core and does not need to 
depend on uwsgi.

mailman3-web contains it's own daemon/service mailman3-web.service. This 
service starts the uwsgi binary:

ExecStart=/usr/bin/uwsgi --plugin python3 --ini /etc/mailman3/uwsgi.ini

The uwsgi package also starts an uwsgi process. But the latter is not needed 
for mailman3-web. This creates an unnecessary idling daemon on the system which 
at a minimum confuses the system administrator.

mailman3-web apparently only needs the /usr/bin/uwsgi binary which is on my 
system provided by the alternative /usr/bin/uwsgi-core which comes from the 
package uwsgi-core.

Thank you! Thomas

Bug#983188: ITP: unikmer -- Toolkit for nucleic acid k-mer analysis

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: unikmer
  Version : 0.17.2-1
  Upstream Author : Wei Shen
* URL : https://github.com/shenwei356/unikmer
* License : Expat
  Programming Lang: Golang
  Description :  Toolkit for nucleic acid k-mer analysis
 unikmer is a golang package and a toolkit for nucleic acid k-mer
 analysis, providing functions including set operation k-mers
 optional with TaxIDs but without count information.
 .
 K-mers are either encoded (k<=32) or hashed (arbitrary k) into uint64,
 and serialized in binary file with extension .unik.
 .
 TaxIDs can be assigned when counting k-mers from genome
 sequences, and LCA (Lowest Common Ancestor) is computed during set
 opertions including computing union, intersecton, set difference,
 unique and repeated k-mers.


I shall maintain this package.

Bug#983186: autopkgtest: difference between qemu and lxc testbeds

[Ryutaroh Matsumoto]

Package: autopkgtest
Version: 5.16
Severity: important
Tags: bullseye sid

Dear Maintainer,

I set up testbeds by
debci setup -f -a amd64 -s sid -b qemu
debci setup -f -a amd64 -s sid -b lxc

"autopkgtest -u debci -B -U python3.9" behaves differently on QEMU and LXC 
testbeds.
On QEMU testbed, it fails with

[error] character map file `ISO-8859-1' not found: No such file or directory
[error] cannot read character map directory `/usr/share/i18n/charmaps': No such 
file or directory
[error] character map file `UTF-8' not found: No such file or directory
[error] cannot read character map directory `/usr/share/i18n/charmaps': No such 
file or directory

On the other hand, all tests pass on LXC testbed, as seen on ci.debian.net.

I have not understood how this difference appear...
Log of autopkgtest is attached.

Any difference betwen LXC and QEMU testbeds seems important,
so I chose "important" severity.

Best regards, Ryutaroh Matsumoto

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.1.20
ii  libdpkg-perl1.20.7.1
ii  procps  2:3.3.16-5
ii  python3 3.9.1-1
ii  python3-debian  0.1.39

Versions of packages autopkgtest recommends:
ii  autodep8  0.24

Versions of packages autopkgtest suggests:
ii  lxc   1:4.0.6-1
pn  lxd   
ii  ovmf  2020.11-2
ii  qemu-efi-aarch64  2020.11-2
ii  qemu-efi-arm  2020.11-2
ii  qemu-system   1:5.2+dfsg-3
ii  qemu-utils1:5.2+dfsg-3
pn  schroot   
ii  vmdb2 0.22-1

-- no debconf information


python3.9.tar.xz
Description: application/xz

Bug#983187: ITP: golang-github-will-rowe-nthash -- Go implementation of ntHash

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: golang-github-will-rowe-nthash
  Version : 0.3.0-1
  Upstream Author : Will Rowe
* URL : https://github.com/will-rowe/nthash
* License : Expat
  Programming Lang: Golang
  Description :  Go implementation of ntHash
 This is a Go implementation of the ntHash
 recursive hash function for hashing
 all possible k-mers in a DNA/RNA sequence.


I shall maintain this package.

Bug#983107: os-prober: generic subvolume support for btrfs

[Nicholas D Steeves]

Hi Osamu,

Correction for previous email: Fedora 33 does not use "subvol=rootfs",
it uses "subvol=root".  I'm not sure if they changed this sometime in
the last few years, or if I misremembered and typed "rootfs" by habit.

Reply follows inline:

Osamu Aoki  writes:



> If you want to use timeshift (Ubuntu origin?) or snapper (Suse origin
> ?), they seem to use non-ID-5 subvol for the system install, i.e.,
> root-FS.  People use these tools on Debian too.
>

Doesn't this mean the new subvol=@rootfs (without set-default=@rootfs)
actually fulfills the assumptions required by Timeshift (Ubuntu
subvol=@, no set-default=@) and Snapper?

Hideki, would you please confirm that the changes introduced in
partman-btrfs 53 do not break Snapper?  If so, is it difficult to fix
this in Snapper, and if necessary, do you have time to do so before
bullseye's release or would you like help?  I still worry that Snapper
might have SUSE-specific assumptions in its design (see previous message
at bug #983107 for more context), and if the "subvolid=5" aka "subvol=/"
(Debian pre-bullseye) has hidden a "set-default=@" (SUSE) assumption
that might now manifest as broken functionality in Snapper.
Alternatively, maybe snapper installs a grub config hook?



> === Additional Tips ===
>
> You can convert a system from EXT2/3/4 to btrfs as follows by booting
> system from another system on the multiboot set-up.
>
> File system conversion is trivial as described in
> https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3
>
> -
> $ sudo fsck.ext3 -f /dev/xxx
> $ sudo btrfs-convert /dev/xxx
> $ sudo mount -t btrfs /dev/xxx /mnt
> -

Ahhh.  Is the ext4-to-btrfs via btrfs-convert case the basis for your
preference for the use of subvol=/ or set-default=@foo?



> Also, you need to update many relevant parts of grub.cfg, too.  Roughly
> as ...
> -
> --- grub.cfg-orig   2021-02-17 09:32:35.855910912 +0900
> +++ grub.cfg2021-02-19 14:26:12.728005239 +0900
> ...
> -insmod ext2
> +insmod btrfs

Given "You can convert a system from EXT2/3/4 to btrfs as follows by
booting system from another system on the multiboot set-up": 

From a live boot with live/rescue media, update-grub already does the
right thing for subvolume renames, or moving rootfs from subvolid=5 to a
named subvolume mounted with "-o subvol=@foo", and I don't know why the
btrfs-convert case is special.  Why not, post-btrfs-convert:

1. umount the just-converted partition
   * suppose it's /dev/sda2
2. mount /dev/sda2 -o subvol=/ /target
3. btrfs sub snap /target /target/@rootfs
4. btrfs sub sync /target && btrfs fi sync /target
   * hasn't been necessary since linux-4.4 IIRC
5. umount /target
6. mount /dev/sda2 -o subvol=@rootfs /target
7. (make bind mounts)
8. chroot to /target as usual
9. update-grub as usual

ISTM that update-grub will do the right thing ("-insmod ext2; +insmod
btrfs") if the partition is unmounted, then remounted before running
update-grub.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#983185: ITP: golang-github-twotwotwo-sorts -- Parallel and radix sorting in Go

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: golang-github-twotwotwo-sorts
  Version : 0.0~git20160814.bf5c1f2-1
  Upstream Author : Randall Farmer
* URL : https://github.com/twotwotwo/sorts
* License : BSD-3-clause
  Programming Lang: Golang
  Description :  Parallel and radix sorting in Go
 sorts/sortutil sorts common slice types and adds
 functions to help sort floats. This package helps
 if sorting huge datasets is a bottleneck.

I shall maintain this package.

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

[Ondřej Surý]

Hi Kevin,

in git, I added the extra configuration commented out with a hint to take a
look at the PHP-FPM wiki page you linked. Eventually, this will get into
Debian.

Thanks for your contribution anyway, even if this didn't work out exactly
the way you proposed.

Ondrej

On Sat, 20 Feb 2021 at 14:59, Kevin Locke  wrote:

> On Sat, 2021-02-20 at 10:49 +0100, Ondřej Surý wrote:
> > Hi Kevin,
> >
> > I tried to add this patch to the PHP-FPM package, but it breaks existing
> > installations[1] and I had to revert the change.
> >
> > Since this won't ever get merged, so I am just closing the issue.
> >
> > 1. https://github.com/oerdnj/deb.sury.org/issues/1545
>
> Hi Ondrej,
>
> Thanks for the update.  My apologies for the regression.  Running Apache
> and PHP-FPM as different users with different hosted file visibility is
> an interesting case that I hadn't considered.  Not including the patch
> by default and closing the issue makes sense to me.
>
> Thanks again,
> Kevin
>

Bug#983146: sponsorship-requests: Backup next generation (bung)

[Robin Gustafsson]

Charles,

> I tried hard to make a source .deb but did not manage to do so.  Would
> you like me to share the system I use to create the .deb?

A source package is required for inclusion in Debian. The binary
packages are built automatically on Debian infrastructure and must use
certain build tools for that to work. So, to proceed, there needs to
be a compliant source package.

If you want to maintain this package in Debian yourself, see the
"Introduction for maintainers" [1] page. If you hope to find someone
else to maintain it in Debian, you should instead file a "Request for
package" (RFP) bug to add it to the list of requested packages [2].

[1] https://mentors.debian.net/intro-maintainers/
[2] https://www.debian.org/devel/wnpp/requested

Regards,
Robin

Bug#983107: os-prober: generic subvolume support for btrfs

[Nicholas D Steeves]

Hi Osamu!

§1
Would you like to join/co-found the nascent "Debian btrfs enablement"
team?

In the coming years there will be an increasing number of software that
will need a "get all valid bootable rootfs candidates for a btrfs
volume".  Right now we have GRUB, Debian Rescue (TODO), bootloaders for
ARM (TODO) and in the future systemd-boot (aspirationally TODO
bookworm), in addition to whatever software will be used for "boot
environments".

I wonder if os-prober should be the site for this "return list of
bootable subvolumes" functionality, rather than duplicating the logic in
multiple places?  Cyril?  I'm not sure because os-prober depends on
grub-common, which AFAIK isn't used on ARM.  Do we need a NEW package
for btrfs-related support functions?  Alternatively, btrfs-progs seems
like a logical place for functions like "get a list of all bootable
subvolumes".  Adam, what do you think, is btrfs-progs the right place
for helper functions that return volume layout, noting when a subvolume
is bootable, perhaps as bundled shell scripts?  Could "btrfs subvolume
list" be the right place for this?  And yes, I think this tooling should
ideally exist upstream and not be Debian-specific.

I suspect this functionality may be duplicated in Snapper.  P.S. Hideki
Yamane, who maintains Debian's Snapper package, ACKed installing Debian
to a subvolume (without the use of set-default) a long time ago, but
it's probably time to check in with him again (CCing him).

With truly generic subvolume support for grub that checks for valid
bootable rootfs candidates and creates a menu entry for each candidate
we will have a working prototype of "boot environments" today.  As far
as I know, only SUSE has this (IIRC via Snapper, probably with extra
grub hooks), plus Arch--on an opt-in basis--with grub-btrfs.

Osamu Aoki  writes:

> Package: os-prober
> Version: 1.78
> Severity: normal
>
> Issue:
> Currently Debian os-prober support only btrfs root-filesystem on the root of
> the btrfs, i.e., ID 5 (FS_TREE).  This makes auto generated grub.cfg to miss
> Linux install to btrfs for some Ubuntu and Suse since they put root-system
> under @ subvolume.

Thank you for bringing this issue to my attention!  Yes, I agree, we
should fix this.

> Existing patch in other distro:
> Ubuntu ships patched os-prober 1.77 to address its subvolume use (@ as root-
> filesystem) with hardcoded path and very rudamental check for /lib directory.
>
> 
> diff -pruN 1.77/linux-boot-probes/common/50mounted-tests 1.77ubuntu1/linux-
> boot-probes/common/50mounted-tests
> --- 1.77/linux-boot-probes/common/50mounted-tests   2018-08-10
> 19:23:18.0 +
> +++ 1.77ubuntu1/linux-boot-probes/common/50mounted-tests2020-11-02
> 11:12:51.0 +
> @@ -54,6 +54,19 @@ if type grub-mount >/dev/null 2>&1 && \
> mounted=1
> type="$(grub-probe -d "$partition" -t fs)"
> [ "$type" ] || type=fuseblk
> +
> +   case "$type" in
> +   btrfs)
> +   if [ -x "$tmpmnt/@/lib" ] && \
> +  ! mount --bind "$tmpmnt/@" "$tmpmnt"; then
> +   warn "failed to mount btrfs subvolume @ on
> $partition"
> +   if ! umount $tmpmnt; then
> +   warn "failed to umount $tmpmnt"
> +   fi
> +   mounted=
> +   fi
> +   ;;
> +   esac
>  fi
>
>  if [ "$mounted" ]; then
> --
>
> Discussion:
> Since we should offer the choice for the subbvolume name, this hardcoding "@"
> here is not elegant.

§2
Agreed, that hardcoding is not elegant; although, it does mirror the
hardcoding in their installer, so it's somewhat sensible for the
Ubuntu-specific case.  I imagine their plan was to prototype with
hardcoding, and later add user-defined config to their installer...but
then configurable subvol layout was never added.  My plan is to help
solve the "install to a named subvolume" case for bullseye, and to adapt
partman-LVM to btrfs semantics for bookworm's partman-btrfs, thus
enabling user-configurable subvolume layout in the installer.  IIRC
users installing Debian to btrfs using Calamares already get the
Ubuntu-desktop-style subvolume layout.

To solve the Ubuntu-specific case, I must ask: Do you know if Ubuntu's
upcoming new installer allows configurable subvolume layout?
  https://www.omgubuntu.co.uk/2021/02/ubuntu-is-working-on-a-brand-new-installer

If not, I'm not sure there's any urgency or benefit to accommodate what
they would call an officially unsupported custom config (to see why
set-default=@ is unsupported see §3).  I just tested the new "curtin"
Ubuntu server 20.10 installer, which installed directly to subvolid=5,
without creating any subvolumes.

I then tried installing Ubuntu Desktop 20.10, where the btrfs-flavour
partitioning recipe appears to have been replaced with ZFS, but where
manual 

Bug#980607: netcfg: FTBFS patches

[Bart Martens]

Dennis, Cyril,

Downloading the patches from the bts works fine. The patches can be applied
with ignoring whitespaces (option -l). The patches solve the FTBFS.

  |  (sid)bartm@carolus:~/src/sponsoring/netcfg-1.169$ patch -l -p1 < 
../netcfg_1.169-fix-CheckAPI.patch 
  |  patching file test/test_nc_v6_interface_configured.c
  |  patching file test/test_netcfg_gateway_reachable.c
  |  patching file test/test_inet_ptom.c
  |  patching file test/test_netcfg_network_address.c
  |  patching file test/test_inet_mton.c
  |  patching file test/test_netcfg_parse_cidr_address.c
  |  patching file test/srunner.c
  |  (sid)bartm@carolus:~/src/sponsoring/netcfg-1.169$ patch -l -p1 < 
../netcfg_1.169-fix-strncpy.patch 
  |  patching file autoconfig.c
  |  patching file dhcp.c
  |  patching file netcfg-common.c

Cheers,

Bart

Bug#982526: stockpile-clojure: FTBFS with OpenJDK 17 due to JDK detection error

[tony mancill]

On Thu, Feb 11, 2021 at 10:11:03AM +0100, Emmanuel Bourg wrote:
> Source: stockpile-clojure
> Severity: important
> Tags: ftbfs sid bookworm
> User: debian-j...@lists.debian.org
> Usertags: default-java17
> 
> stockpile-clojure fails to build with OpenJDK 17, it looks like the JDK isn't 
> properly detected:
> 
> 
>   make[1]: Entering directory '/<>'
>   msgfmt --java2 -d resources -r puppetlabs.stockpile.Messages -l en 
> locales/messages.pot
>   Writing resources/locales.clj
>   msgfmt: Java compiler not found, try installing gcj or set $JAVAC
>   msgfmt: compilation of Java class failed, please try --verbose or set $JAVAC
>   make[1]: *** [dev-resources/Makefile.i18n:86: 
> resources/puppetlabs/stockpile/Messages_en.class] Error 1
>   make[1]: Leaving directory '/<>'

I spent some time poking at this and problem appears to be in msgfmt
(part of gettext).  The same FTBFS occurs with
trapperkeeper-webserver-jetty9-clojure.

Likely related... gettext is also FTBFS against experimental with
OpenJDK 17 installed.  As you suggest, it appears to be an issue with
detecting javac.

(jdk-exp-amd64-sbuild)root@lark:/tmp# javac -version
javac 17-ea


From the configure during the gettext build:

...
checking for Java virtual machine... java
checking for Java compiler... no
...

Any concerns with me retitling this bug, reassigning it to gettext,
adding affects to trapperkeeper-webserver-jetty9-clojure, and then
filing a separate FTBFS bug against gettext for sid/bookworm?

Thanks,
tony


signature.asc
Description: PGP signature

Bug#983161: installation-reports: Acer A515-56G-71RB NX.A1MEH.002

[Holger Wansing]

Hi,

Am 20. Februar 2021 13:08:08 MEZ schrieb Bart Martens :
>On Sat, Feb 20, 2021 at 12:02:52PM +0100, Vincent Blut wrote:
>> Hi Bart,
>> 
>> Le 2021-02-20 09:32, Bart Martens a écrit :
>> > Package: installation-reports
>> > 
>> > Boot method: usb stick
>> > Image version: firmware-bullseye-DI-alpha3-amd64-netinst.iso
>> > Date: 20 feb 2021
>> > 
>> > Machine: Acer A515-56G-71RB NX.A1MEH.002
>> 
>> What kernel version is in use?
>> AFAIR, DI alpha 3 is based on Linux 5.9 which
>> is quite old now.
>
>Kernel version 5.10.13-1.
>
>DI alpha 3 is the most recent advertized here:
>https://www.debian.org/devel/debian-installer/

That's not correct, strictly speaking.
There is also the section with daily builds there, which has 
more recent images.

However, you have the latest kernel installed,
which is because when you have Internet access
during installation, all packages get automatically updated
to the latest version.

Holger

-- 
Sent from /e/ Mail on Fairphone3

Bug#974828: printer-driver-hpcups: bug of printer-driver-hpcups still present on debian sid kernel 5.10.3

[alain]

Package: printer-driver-hpcups
Version: 3.20.11+dfsg0-3
Followup-For: Bug #974828
X-Debbugs-Cc: compte.perso.de-al...@bbox.fr

alain@sid:~/Téléchargements$ apt policy printer-driver-hpcups hplip
printer-driver-hpcups:
  Installé : 3.20.11+dfsg0-3
  Candidat : 3.20.11+dfsg0-3
 Table de version :
 *** 3.20.11+dfsg0-3 500
500 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
 3.20.11+dfsg0-2 100
100 http://deb.debian.org/debian testing/main amd64 Packages
 3.18.12+dfsg0-2 100
100 http://deb.debian.org/debian stable/main amd64 Packages
hplip:
  Installé : 3.20.11+dfsg0-3
  Candidat : 3.20.11+dfsg0-3
 Table de version :
 *** 3.20.11+dfsg0-3 500
500 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
 3.20.11+dfsg0-2 100
100 http://deb.debian.org/debian testing/main amd64 Packages
 3.18.12+dfsg0-2 100
100 http://deb.debian.org/debian stable/main amd64 Packages

alain@sid:~/Téléchargements$ hp-check
Saving output in log file: /home/alain/Téléchargements/hp-check.log

HP Linux Imaging and Printing System (ver. 3.20.11)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling
the HPLIP supplied tarball (.tar.gz or
.run) to determine if the proper dependencies are installed to successfully
compile HPLIP.
2. Run-time check mode (-r or --run): Use this mode to determine if a distro
supplied package (.deb, .rpm, etc) or an
already built HPLIP supplied tarball has the proper dependencies installed to
successfully run.
3. Both compile- and run-time check mode (-b or --both) (Default): This mode
will check both of the above cases (both
compile- and run-time dependencies).

Check types:
a. EXTERNALDEP - External Dependencies
b. GENERALDEP - General Dependencies (required both at compile and run time)
c. COMPILEDEP - Compile time Dependencies
d. [All are run-time checks]
PYEXT SCANCONF QUEUES PERMISSION

Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

-Gtk-Message: 19:48:07.916: Failed to load module "canberra-gtk-module"
warning: debian-unstable version is not supported. Using debian-10.6 versions
dependencies to verify and install...

---
| SYSTEM INFO |
---

 Kernel: 5.10.0-3-amd64 #1 SMP Debian 5.10.13-1 (2021-02-06) GNU/Linux
 Host: sid
 Proc: 5.10.0-3-amd64 #1 SMP Debian 5.10.13-1 (2021-02-06) GNU/Linux
 Distribution: debian unstable
 Bitness: 64 bit


---
| HPLIP CONFIGURATION |
---

HPLIP-Version: HPLIP 3.20.11
HPLIP-Home: /usr/share/hplip
warning: HPLIP-Installation: Auto installation is not supported for debian
distro  unstable version

Current contents of '/etc/hp/hplip.conf' file:
# hplip.conf.  Generated from hplip.conf.in by configure.

[hplip]
version=3.20.11

[dirs]
home=/usr/share/hplip
run=/var/run
ppd=/usr/share/ppd/hplip/HP
ppdbase=/usr/share/ppd/hplip
doc=/usr/share/doc/hplip
html=/usr/share/doc/hplip-doc
icon=no
cupsbackend=/usr/lib/cups/backend
cupsfilter=/usr/lib/cups/filter
drv=/usr/share/cups/drv
bin=/usr/bin
apparmor=/etc/apparmor.d
# Following values are determined at configure time and cannot be changed.
[configure]
network-build=yes
libusb01-build=no
pp-build=no
gui-build=yes
scanner-build=yes
fax-build=yes
dbus-build=yes
cups11-build=no
doc-build=yes
shadow-build=no
hpijs-install=yes
foomatic-drv-install=yes
foomatic-ppd-install=no
foomatic-rip-hplip-install=no
hpcups-install=yes
cups-drv-install=yes
cups-ppd-install=no
internal-tag=3.20.11
restricted-build=no
ui-toolkit=qt5
qt3=no
qt4=no
qt5=yes
policy-kit=yes
lite-build=no
udev_sysfs_rules=no
hpcups-only-build=no
hpijs-only-build=no
apparmor_build=no
class-driver=no


Current contents of '/var/lib/hp/hplip.state' file:
Plugins are not installed. Could not access file: No such file or directory

Current contents of '~/.hplip/hplip.conf' file:
[commands]
scan = /usr/bin/simple-scan %SANE_URI%

[fax]
email_address =
voice_phone =

[last_used]
device_uri = escl:http://127.0.0.1:6
printer_name =
working_dir = .

[polling]
device_list =
enable = false
interval = 5

[refresh]
enable = false
rate = 30
type = 1

[settings]
systray_messages = 0
systray_visible = 0

[upgrade]
last_upgraded_time = 1613842662
notify_upgrade = true
pending_upgrade_time = 0

[installation]
date_time = 02/20/21 19:48:08
version = 3.20.11





-
| External Dependencies |
-

 error: cups  CUPS - Common Unix Printing System
REQUIRED1.1 -

Bug#884881: Bug#944114: Missing directory spec in Remap secdeb rule

[Eduard Bloch]

Hallo,
* john doe [Mon, Nov 04 2019, 03:47:00PM]:
> Package: apt-cacher-ng
> Version: 3.2-2
>
> Upon installation of AC-NG, the remap rule ('secdeb') for debian
> security is missing the directory spec ('/debian-security'):
>
> Rong remap rule without directory spec:
>
> Remap-secdeb: security.debian.org ; security.debian.org
> deb.debian.org/debian-security
>
> Working remap rule with directory spec:
>
> Remap-secdeb: security.debian.org /debian-security ; security.debian.org
> deb.debian.org/debian-security

Ok, so I think the default configuration has been PITA for some people
for the last couple of years and I am sorry. I intend to modify the
default mapping as shown below, or see:

https://salsa.debian.org/blade/apt-cacher-ng/-/commit/3090d97ed9794a64f509917c77f0bb7ebccf1fbf

Is this something we can agree on? I am not so sure about using
deb.debian.org as default backend.



index 9dbf87c..940feab 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -4,6 +4,9 @@ apt-cacher-ng (3.6.1) HAPPENS-TO-THE-BEAST-OF-US; urgency=low
   * Avoid potential file descriptor leak in download item collision handling
   * Extended mirror scan to guess {ftp2, ftp3}.XY.debian.org address aliases
 (Debian bug #951005)
+  * Extended security.debian.org rewriting to also include deb.debian.org
+requests and change default mirror for them all to deb.debian.org (Debian
+bugs #932093, previously #884881)

  --

diff --git a/conf/acng.conf.in b/conf/acng.conf.in
index 2f269ae..4147809 100644
--- a/conf/acng.conf.in
+++ b/conf/acng.conf.in
@@ -77,7 +77,7 @@ Remap-fedora: file:fedora_mirrors # Fedora Linux
 Remap-epel:   file:epel_mirrors # Fedora EPEL
 Remap-slrep:  file:sl_mirrors # Scientific Linux
 Remap-gentoo: file:gentoo_mirrors.gz /gentoo ; file:backends_gentoo # Gentoo 
Archives
-Remap-secdeb: security.debian.org ; security.debian.org 
deb.debian.org/debian-security
+Remap-secdeb: security.debian.org security.debian.org/debian-security 
deb.debian.org/debian-security /debian-security ; 
deb.debian.org/debian-security security.debian.org

 # Virtual page accessible in a web browser to see statistics and status
 # information, i.e. under http://localhost:3142/acng-report.html



Best Regards,
Eduard.
--
Atheismus ist keine Philosophie, er ist noch nicht ein mal eine
Weltsicht. Er ist schlichtweg die Weigerung, ohne Grund das Gegenteil
des Offensichtlichen zu glauben.

Bug#982956: Acknowledgement (linux-image-4.19.0-14-686-pae: task blocked for more)

[Alexey Kuznetsov]

Can be bug at here (same symptoms):

https://gitlab.freedesktop.org/drm/intel/-/issues/2905

-- AK


On Wed, Feb 17, 2021 at 3:03 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

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

Bug#936073: please have libffi6-dbgsym debug package

[Matthias Klose]

Version: 3.3~20180313-1

fixed.

Bug#983183: libpam-script: Wrong path for pam_script.so

[Christian Meyer]

Package: libpam-script
Version: 1.1.9-4+b1
Severity: grave
Tags: patch
Justification: renders package unusable
X-Debbugs-Cc: c2h...@web.de

Dear Maintainer,

after reinstalling my (FAI-driven) installation with bullseye (using stretch 
before and ignoring buster),
I found that pam-script doesn't work anymore.
/var/log/auth.log claims that:
PAM unable to dlopen(pam_script.so): 
/lib/x86_64-linux-gnu/security/pam_script.so: Couldn't open Shared-Object-file: 
File or directory not found
PAM adding faulty module: pam_script.so

Your package contains the file, but it lives in a wrong directory (and for me 
there is no other file in there):
/lib/security/pam_script.so

all other pam_*.so files live in /lib/x86_64-linux-gnu/security/
and a simple
ln -s /lib/security/pam_script.so /lib/x86_64-linux-gnu/security/pam_script.so
made pam_script work again.

I'm not knowing the details of PAM and pam_script, but I think simply moving 
the directory should be the right solution.
Please fix it in the remaining bullseye-freeze. 

Thank you
Christian Meyer


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

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

Versions of packages libpam-script depends on:
ii  libc6 2.31-9
ii  libpam0g  1.4.0-4

libpam-script recommends no packages.

libpam-script suggests no packages.

-- no debconf information

Bug#983182: RM: mash [armel armhf i386 mipsel] -- ROM; erroneous results on 32 bits CPUs

[Étienne Mollier]

Package: ftp.debian.org
Severity: normal

Greetings,

The mash package issues erroneous results on 32 bits systems.
This results in visible errors on another package: kleborate
fails parts of its test suite in which mash is involved[1].
Other dependencies are not buildable on 32 bits platforms.

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

We would prefer avoiding the risk of erroneous results to our
user base, so unless it turns out there is a need for 32 bits
support, the package should be removed from the archive for
these architectures:
  * armel
  * armhf
  * i386
  * mipsel

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/6, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#970325: tpm2-pkcs11: Provide buster-backports

[Bastian Germann]

On Thu, 7 Jan 2021 14:55:35 +0800 SZ Lin  wrote:

Hi,

The current maintainer - Alvin, lacks time to backport and maintain the
buster-backports version of tpm2-pkcs11 and it would be great if you can
do the backport task and co-maintain this package :-)

SZ


Please raise the libtss2-dev build dependency version to >= 2.3.0 
because that introduced the required tctildr library. Also, tpm2-tools 
build-dependency should require version >= 4 because 4.0.1-1 was the 
first Debian version to come with tpm2_import.


If no tpm2-tools backport is provided, it would also be okay to backport 
an earlier tpm2-pkcs11 package version like 1.2.0-1.

Bug#981411: binutils-arm-none-eabi Debian package copyright info

[John Scott]

Hello binutils-arm-none-eabi package contributors,

debian/copyright does not specify the license or copyright notices for
your packaging work.

I've used your package as a model for making binutils-sh-elf, but a
work without a license specified can't be considered free. Currently
the debian/copyright file is copied out of the main Binutils package
verbatim, which only specifies GNU's copyright of the binaries.

Could each of you specify what license you subject your contributions
to (such as the GNU GPL 3 or any later version)? That way the package
can be said to be free without a doubt and I can get mine accepted.

Thanks,
John


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

Bug#983181: xscreensaver-data-extra: newline in .desktop file

[Mark A. Hershberger]

Package: xscreensaver-data-extra
Version: 5.42+dfsg1-1
Severity: normal

Running apt upgrade and saw this:

Could not parse file 
"/usr/share/applications/screensavers/glitchpeg.desktop": Key file contains 
line ?several times a second.  After a while, finds a new image to corrupt. 
Written by Jamie Zawinski; 2018.? which is not a key-value pair, group, or 
comment

The problematic lines seems to these:

Comment=Loads an image, corrupts it, and then displays the corrupted 
version,
several times a second.  After a while, finds a new image to corrupt. 
Written by Jamie Zawinski; 2018.


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (1100, 'stable-updates'), (990, 'stable'), (40, 'testing'), (1, 
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages xscreensaver-data-extra depends on:
ii  dictionaries-common  1.28.3~bpo10+1
ii  libc62.28-10
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libice6  2:1.0.9-2
ii  libjpeg-turbo-progs  1:1.5.2-2+deb10u1
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.6.7-1+deb10u1
ii  libxext6 2:1.3.3-1+b2
ii  libxft2  2.3.2-2
ii  libxmu6  2:1.1.2-2+b3
ii  libxt6   1:1.1.5-1+b3
ii  netpbm   2:10.0-15.3+b2
ii  xscreensaver-data5.42+dfsg1-1

xscreensaver-data-extra recommends no packages.

xscreensaver-data-extra suggests no packages.

-- no debconf information

-- 
http://hexmode.com/

I cannot remember the books I've read any more than the meals I have eaten;
even so, they have made me.
-- Ralph Waldo Emerson

Bug#965965: openjdk-11-jdk-headless: JRE fails at startup on ARM Cortex A8

[Matthias Klose]

Please recheck with 11.0.11+3-3 from experimental.

Bug#982221: Use cdrtools - cdrkit needs to be removed, finally

[esitea1]

Use cdrtools ( https://www.berlios.de/software/cdrtools/ ) as it was the 
original and still the better option for burning CD, DVD, and BluRay. 
Cdrkit was always a poor choice since from the time it was forked from 
cdrtools, it was always inferior. It has seen next to no development in 
the many years since.

Bug#941993: cheese: Pixart Imaging, Inc. Typhoon Easycam USB 330K does no more work with cheese

[Elmar Stellnberger]

I know now why it does work with OpenSUSE but not with Debian:

GStreamer is compiled without libv4l2 code by default. Something that 
could be changed easily: 
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/644

Bug#913227: dcmqrcbm.cc:319:38: warning: '%d' directive writing between 1 and 11 bytes into a region of size between 0 and 128

[Sascha Steinbiss]

I assume this bug is obsolete, right? We already have 3.6.5 in testing
and I do not see these warnings anymore in the i386 build logs.

Cheers
Sascha

Bug#913585: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'Sint32' {aka 'int'} [-Wformat=]

[Sascha Steinbiss]

I assume this bug is obsolete, right? We already have 3.6.5 in testing
and I do not see these warnings anymore in the i386 build logs.

Cheers
Sascha

Bug#983178: Some validation errors are not actionable for translators

[Marcin Owsiany]

Package: www.debian.org
Severity: minor
Tags: l10n

Background
--

Validation errors are emailed daily to (among others) translation
coordinators by the validate-mail script:
https://salsa.debian.org/webmaster-team/cron/-/blob/master/scripts/validate-mail

This is very useful, since I *DO* want to be notified about issues
introduced by those who translate to my language (whether it's me or
someone else).


The issue
-

*However*, since most translated WML files have the same markup
structure as the English originals, most (if not all) validation errors
for English pages also apply to the translated pages. Compare for
example:

https://www-master.debian.org/build-logs/validate/en
and
https://www-master.debian.org/build-logs/validate/pl

In a typical ephemeral case (someone commits broken markup and it gets
fixed a couple days later) this is merely distracting. It was bugging me
whan I was actively working on the translations a couple of decades ago
:-) but it was never annoying enough to do something about it.

However these days there are some long-standing issues which will
probably take some more time to resolve: https://bugs.debian.org/980921
The fix is being discussed for weeks and is likely to take some more
time. This means it is not really actionable to a typical translator.

Even in case of smaller issues, unfortunately having very limited time
resources I cannot afford to chase every markup validation issue in the
that is merely copied with the structure of the page translated to my
language.


My proposal
---

What I'd like to propose is to take advantage of the fact that the
original and translated pages have the same structure, in order to make
translation coordinators' lives a little easier.

My idea is to change the validate-mail script: when mailing validation
errors of a given language (other than English), omit all the errors
which *also* appear in the English validation output.  It's not going to
be perfect (because line numbers will have to be ignored), but should
work reasonably well in most cases, and not interfere the steady state
(no validation errors in the English version).


regards,
Marcin

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

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

Bug#981211: Problem seems to disappear

[Patrick Franz]

Hi Kasper,

I'm closing this bug right now as it doesn't seem to stem from plasma-
desktop.
When you have found the root cause of the issue (e.g. the widget that 
causes it), feel free to either reopen the bug or reassign it to the 
corresponding package.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#983177: tpm2-tools: Provide buster-backports

[Bastian Germann]

Package: tpm2-tools
Control: block 970325 by -1
Control: block -1 by 983175
Severity: wishlist

Please provide the bullseye version (with tpm2_import) as buster-backports.

Bug#983176: tpm-udev: Provide buster-backports

[Bastian Germann]

Package: tpm-udev
Severity: wishlist
Control: block 983175 by -1

Please provide a buster-backports version of the package.

Bug#970875: Bug#970875: mash: inconsistent results on 32 vs 64 bits architectures

[Étienne Mollier]

Andreas Tille, on 2021-02-20 17:21:54 +0100:
> Great, would you mind uploading and file an RM bug report?

I'm on it!
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#983175: tpm2-tss: Provide buster-backports

[Bastian Germann]

Source: tpm2-tss
Control: block 970325 by -1
Severity: wishlist

Please provide a version >= 2.4 and < 3.0.2 (without the #974837 change) 
as buster-backports.

Bug#970875: Bug#970875: mash: inconsistent results on 32 vs 64 bits architectures

[Andreas Tille]

On Sat, Feb 20, 2021 at 03:47:10PM +0100, Étienne Mollier wrote:
> 
> I don't know by which end to solve the 32 bits failures here, so
> it might make sense to drop 32 bits.  None of the reverse
> dependencies I saw were available on 32 bits release
> architectures, either because of missing build dependencies
> (ariba, plasmidid) or failure to build from source (kleborate).
> 
> As far as I can see, the working set would be:
> 
>   Architecture: amd64 arm64 mips64el ppc64el s390x alpha ppc64 riscv64
> 
> (I don't include m68k on which kleborate built successfully,
>  because the test suite is not run on that architecture.
>  Otherwise I suspect it would fail.)

Great, would you mind uploading and file an RM bug report?  Feel
free to ask me to take over but I've granted upload permission
for mash in case you want to proceed.

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Bug#983168: nftables: command line parser misparse/double parse (some) quoted strings, log prefix can't contain various characters

[Peter Gervai]

Package: nftables
Version: 0.9.8-3
Severity: normal
Tags: upstream

# nft add rule inet purutty hopsz ip saddr 1.2.3.4 log prefix 'foo: '
Error: syntax error, unexpected colon, expecting end of file or newline or 
semicolon
add rule inet purutty hopsz ip saddr 1.2.3.4 log prefix foo:


Log prefix must be double-quoted since nft seem to remove quotes then reparse:

# nft add rule inet purutty hopsz ip saddr 1.2.3.4 log prefix '"foo: "'

Bug#982567: openms build-depends on removed package

[Filippo Rusconi]

Greetings, Andreas and Michael,

I hope you are doing fine.

On Fri, Feb 19, 2021 at 10:19:11PM +0100, Andreas Tille wrote:

Hi Filippo,

this is extremely unfortunate.  However, I guess the alternative would
have been to keep some RC buggy seqan-dev which would not have helped
openms as well.  I tried the same as Peter and replaced the
Build-Depends seqan-dev by libseqan2-dev.

I can confirm the observation from Peter about the missing header file.
I simply tried to comment those missing headers (next one is also
missing):


// #include 
// #include 

[...]

Thank you for your trials and explanations. I am no on vacation, which means
I'll finally find some time to try understand the implications of that SeqAn
upgrade.

I'll keep you posted with my findings.

Cheers,

Filippo


--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

Bug#981211: Problem seems to disappear

[Kasper Loopstra]

Hi Patrick,


Thanks for the response. Sorry my late reaction, I forgot to subscribe 
to this bugreport so I never saw the reply.



After my last time resetting Plasma I have decided not to use any 
desktop widgets at all. Now it seems like the problem is gone. I haven't 
taken the time to investigate which desktop widgets I was using, but it 
seems like either one of them caused an issue, or another update of my 
system fixed this bug.



Thanks,


Kasper.

Bug#980921: Validation of HTML5

[Marcin Owsiany]

Package: www.debian.org
Followup-For: Bug #980921

When thinking about the migration, please also take into account the
effect of moving to HTML on the validation script.

I don't know whether I did it correctly, but for me simply replacing the
doctype with "html" caused the validation script to fail with:

*** Errors validating ../view-source_https___www.debian.org.html: ***
Line 1, character 15:  no internal or external document type declaration
subset; will parse without validation
Line 51, character 24:  general entity "nbsp" not defined and no default
entity
Line 51, character 28:  reference to entity "nbsp" for which no system
identifier could be generated
Line 256, character 115:  reference to entity "nbsp" for which no system
identifier could be generated
Line 257, character 121:  reference to entity "nbsp" for which no system
identifier could be generated
Line 261, character 117:  reference to entity "nbsp" for which no system
identifier could be generated
Line 265, character 118:  reference to entity "nbsp" for which no system
identifier could be generated
Line 267, character 115:  reference to entity "nbsp" for which no system
identifier could be generated
Line 270, character 116:  reference to entity "nbsp" for which no system
identifier could be generated
Line 272, character 118:  reference to entity "nbsp" for which no system
identifier could be generated

I suppose this is because the validator is based on the DTDs in
/usr/share/sgml/html/... and there is none for HTML5 there?

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

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

Bug#896161: Hallo

[Eddie Debra]

Hallo,

Ich habe dir eine Mail geschickt, aber keine Antwort von dir, warum?

Eddie

Bug#982882: stellarium FTBFS on armel and mipsel

[Adrian Bunk]

Control: reassign -1 libqt5core5a 5.15.2+dfsg-4
Control: retitle -1 lconvert uses huge amounts of RAM
Control: affects -1 src:stellarium
Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-87010

On Thu, Feb 18, 2021 at 07:33:21PM +0100, Tomasz Buchert wrote:
> On 15/02/21 20:54, Paul Gevers wrote:
> > Source: stellarium
> > Version: 0.20.4-1
> > Severity: serious
> > Tags: ftbfs
> >
> > [...]
> 
> Seems like it is
> https://github.com/Stellarium/stellarium/issues/1131. This has been
> solved with https://bugreports.qt.io/browse/QTBUG-87010.
> 
> Surprisingly, the fix is not in qtbase-opensource-src-5.15.2+dfsg. I'm
> not sure why, it seems like the fix was intended to land there.
>...

I'm re-assigning the bug there.

cu
Adrian

Bug#753076: Hallo

[Eddie Debra]

Hallo,

Ich habe dir eine Mail geschickt, aber keine Antwort von dir, warum?

Eddie

Bug#705442: Hallo

[Eddie Debra]

Hallo,

Ich habe dir eine Mail geschickt, aber keine Antwort von dir, warum?

Eddie

Bug#983170: s3ql: High load causes "Transport endpoint is not connected"

[Francesco P. Lovergine]

severity 983170 grave
tags 983170 + upstream help
thanks

It seems to me that this version cannot simply be distributed as is.
Even, the wrong assumption about trio version compatibility renders it not 
compatible with bullseye status.


On Sat, Feb 20, 2021 at 01:24:16PM +, Graham Cobb wrote:

Package: s3ql
Version: 3.7.0+dfsg-2
Severity: important

Dear Maintainer,

After upgrading s3ql from 3.3.2+dfsg-1 I suffered from bug #982381 (trio) so
I tried manually installing trio 0.15 (as mentioned in that thread).
Although it allowed some files to be created, any long or complex operation
(such as a backup, or even an `rm -rf` of a large directory) cause a
'Software caused connection abort' error followed by
enormous numbers of 'Transport endpoint is not connected' errors.

In case it was some transient network problem, I used fsck.s3ql to fix the
filesystem and retried - same errors. And the same errors if I (fsck again
and) just try a `rm -rf` on a large directory.

I then tried installing trio 0.18. Same problem.

Mounting is working. fsck is working. Simple file operations are working.
But heavy load causes 'Software caused connection abort'. Completely repeatable.

The following commands reproduce the problem for me:

cd /mnt/mountpoint
count=100
mkdir testdir ; for f in `seq 1 $count` ; do mkdir testdir/$f ; dd 
if=/dev/urandom  bs=1000 count=1 of=testdir/$f/test status=none ; done
rm -rf testdir
umount /mnt/mountpoint

With the count at 100 the problem occurs when the unmount happens. If the count
is increased to 2000 the problem occurs during the run.

This is using the S3 backend.

By the way, this workload has been working for many years with no problems,
and was working with 3.3.2+dfsg-1 before I decided to try testing 3.7.0+dfsg-2.



--
Francesco P. Lovergine

Bug#264769: Hallo

[Eddie Debra]

Hallo,

Ich habe dir eine Mail geschickt, aber keine Antwort von dir, warum?

Eddie

Bug#983172: closed by Andreas Beckmann (Re: Bug#983172: nvidia-cuda-toolkit: Version of libcusolver11 lower than in the archive)

[Adrian Bunk]

On Sat, Feb 20, 2021 at 03:30:03PM +, Debian Bug Tracking System wrote:
>...
> On 2/20/21 2:36 PM, Adrian Bunk wrote:
> > Your upload included the binary package libcusolver11, version 
> > 11.1.0.135~11.2.1-1, for amd64,
> > however testing already has version 11.1.1+~11.0.2.68~11.2.0-2.
> > Uploads to unstable must have a higher version than present in testing.
> 
> Hmm, why didn't I get the reject per email?
>...

https://buildd.debian.org/status/fetch.php?pkg=nvidia-cuda-toolkit=amd64=11.2.1-1=1613465686=0

...
Source: nvidia-cuda-toolkit
...
Architecture: amd64
Version: 11.2.1-1
Distribution: sid
Urgency: medium
Maintainer: amd64 Build Daemon (x86-grnet-01) 

Changed-By: Andreas Beckmann 
...

> Andreas

cu
Adrian

Bug#983146: sponsorship-requests: Backup next generation (bung)

[Antonio Russo]

Hello,

> Please change the email address on this bug report from 
> send_only.aurin...@auroville.org.in to b...@charlesmatkinson.org

See controlling the Debian BTS [1].

> I tried hard to make a source .deb but did not manage to do so.
> Would you like me to share the system I use to create the .deb?

Please see the new maintainers guide [2].

The long and short of it is: Debian manages thousands of software
packages and provides a huge amount of freedom to maintainers in
how they do so.  However, your package MUST build from a single
call to debian/rules (see [3], /FTBFSIASW/).

This baseline level of uniformity allows Debian to support many
architectures and provide support for the full duration of a Debian
release.

> bung was not a Debian package so I thought the appropriate place
> to install it was under /opt.  If it becomes a Debian package
> then it should be installed in the conventional places. 

Since you are submitting a package to be included in Debian,
it will not be accepted unless it is packaged in a way that
is suitable for Debian---all the files should be placed in
accordance with the Debian FHS (see [4] and [5]).

Once you do this, be sure to use lintian---I suggest at least
looking at the "pedantic" results:

 lintian --verbose -L ">=pedantic" $changes_file

Sponsors are more likely to look at a lintian-clean package.

Best,
Antonio

[1] https://www.debian.org/Bugs/server-control#submitter
[2] https://www.debian.org/doc/manuals/maint-guide/
[3] https://ftp-master.debian.org/REJECT-FAQ.html
[4] https://wiki.debian.org/FilesystemHierarchyStandard
[5] https://www.debian.org/doc/debian-policy/ch-opersys.html