Bug#767602: gnunet: Debian path are not honored

[Daniel Baumann]

close 767602 0.14.0-1
thanks

Hi,

as far as I can see this is no longer applicable to the current 0.14
version, and thus I'm closing the bug.

Regards,
Daniel

Bug#709604: gnunet-service-transport: crashes occasionally

[Daniel Baumann]

close 709604 0.14.0-1
thanks

Hi,

thank you for your report.

As far as I can see this is not applicable anymore to the current
version (0.14), thus I'm closing this bug.

Regards,
Daniel

Bug#744941: reassigning to debian-i18n

[Daniel Baumann]

reassign 744941 debian-i18n
retitle 744941 DDTP gnunet: improve German translation
thanks

Hi,

while I share the feeling that the German translation of the gnunet
package description could be improved, there's nothing I can do about it
in the package.

Unfortunately there's neither any DDTP specific nor debian-l10n
pseudo-package in the bts, so debian-i18n seams to be the closest fit
(not ideal, but still better than on src:gnunet). Hence reassigning it.

Regards,
Daniel

Bug#983658: distcc-pump: Incorrect path to include_server

[haruna]

Package: distcc-pump
Version: 3.4+really3.3.5-2
Severity: important

Dear Maintainer,

after installing / upgrading distcc and distcc-pump from testing the 
include_server path for distcc-pump is pointing to
`/usr/lib/python3.9/site-packages/include_server/...`

The include_server python package however is installed to  
`/usr/lib/python3/dist-packages/include_server`

This can either be resolved by copying the include_server package to the 
expected location or by changing `/usr/bin/distcc-pump`
@@ -40,7 +40,7 @@
 # to the installed include_server.py.
 # NOTE: DO NOT CHANGE THE LINE BELOW WITHOUT CHANGING THE SED IN
 #   Makefile.in:install-include-server.
-include_server='/usr/lib/python3.9/site-packages/include_server/include_server.py'
+include_server='/usr/lib/python3/dist-packages/include_server/include_server.py'


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

Kernel: Linux 4.19.0-14-amd64 (SMP w/2 CPU cores)
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 distcc-pump depends on:
ii  distcc   3.4+really3.3.5-2
ii  libc62.31-9
ii  python3  3.9.1-1

distcc-pump recommends no packages.

distcc-pump suggests no packages.

-- no debconf information

Bug#983623: ibus-mozc: does not work out-of-the-box on the GNOME desktop

[YOSHINO Yoshihito]

Package: ibus-mozc
Version: 2.23.2815.102+dfsg-4
Followup-For: Bug #983623

Dear Maintainer,

Attaching a slightly updated version of the .desktop file, which
honors XDG environment variables:

sed -i.old \
-e 's,.config,${XDG_CONFIG_HOME:-~/.config},g' \
-e 's,.local/share,${XDG_DATA_HOME:-~/.local/share},g' \
ibus-mozc-gnome-initial-setup.desktop

Thanks,

-- 
YOSHINO Yoshihito 


ibus-mozc-gnome-initial-setup.desktop
Description: Binary data

Bug#983659: golang-github-appc-cni: CVE-2021-20206

[Salvatore Bonaccorso]

Source: golang-github-appc-cni
Version: 0.8.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-github-appc-cni.

CVE-2021-20206[0].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-20206
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20206

Please adjust the affected versions in the BTS as needed.

As Thorsten has asked, I beleive this does not warrant a DSA fur
buster but can be fixed in a point release. Can you make sure the fix
goes though into bullseye?

Regards,
Salvatore

Bug#744941: Processed: reassigning to debian-i18n

[Helge Kreutzmann]

Hello,
forwarding to debian-l10n-german, the rest is in German.

On Sun, Feb 28, 2021 at 08:06:03AM +, Debian Bug Tracking System wrote:
> > reassign 744941 debian-i18n
> Bug #744941 [gnunet] peer-to-peer ain't "gleichberechtigte Netze"
> Bug reassigned from package 'gnunet' to 'debian-i18n'.
> Ignoring request to alter found versions of bug #744941 to the same values 
> previously set
> Ignoring request to alter fixed versions of bug #744941 to the same values 
> previously set
> > retitle 744941 DDTP gnunet: improve German translation
> Bug #744941 [debian-i18n] peer-to-peer ain't "gleichberechtigte Netze"
> Changed Bug title to 'DDTP gnunet: improve German translation' from 
> 'peer-to-peer ain't "gleichberechtigte Netze"'.
> > thanks
> Stopping processing here.

Kann sich einer der beim DDTP aktiven Übersetzer die Übersetzung der
Paketbeschreibung von „gnunet“ mal vornehmen und
überarbeiten/korrigieren?

Gerne kann die Übersetzung auch zum Korrekturlesen auf
debian-l10n-german@l.d.o verteilt werden.

Wenn das erledigt ist, bitte Debian-Fehler #744941 in der
Fehlerdatenbank durch eine E-Mail an 744941-d...@bugs.debian.org
schließen.

Vielen Dank & Grüße

helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#983660: Curl don't include zstd supportTR: Curl don't include zstd support

[Gilles Vollant]

Package: curl
Version: 7.74.0

When I invoke `curl --version', it list feature included on the curl
library.
Brotli compression library is included, but not Zstd. Both compression
library are included is the same way .

See https://daniel.haxx.se/blog/2020/08/19/curl-7-72-0-more-compression/ for
zstd added in feature.

Here is a transcript on recent build of Debian 11:


gvollant@debian11:~/soft_amabis$ lsb_release -a No LSB modules are
available.
Distributor ID: Debian
Description:Debian GNU/Linux bullseye/sid
Release:testing
Codename:   bullseye
gvollant@debian11:~/soft_amabis$ curl --version curl 7.74.0
(x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1j zlib/1.2.11 brotli/1.0.9
libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0
librtmp/2.3
Release-Date: 2020-12-09
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps mqtt
pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6
Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets



See transcript on manjaro Linux:

[gillesvollant@gillesvollant-manj ~]$ lsb_release -a
LSB Version:n/a
Distributor ID: ManjaroLinux
Description:Manjaro Linux
Release:20.2.1
Codename:   Nibia
[gillesvollant@gillesvollant-manj ~]$ curl --version curl 7.75.0
(x86_64-pc-linux-gnu) libcurl/7.75.0 OpenSSL/1.1.1i zlib/1.2.11 zstd/1.4.8
libidn2/2.3.0 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0
Release-Date: 2021-02-03
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3
pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HTTP2 HTTPS-proxy IDN IPv6


  I suggest adding zstd library support on curl package.

  I am using Debian GNU/Linux 2.2, kernel 2.2.17-pre-patch-13
  and libc6 2.1.3-10.

Bug#983661: zfs-linux: autopkgtest always fails on qemu testbed

[Ryutaroh Matsumoto]

Source: zfs-linux
Version: 2.0.3-1
Severity: important
Tags: sid bullseye

Dear Maintainer,

I made an autopkgtest qemu testbed by debci setup -f -s sid -a amd64 -b qemu.
Then I run autopkgtest -U -B -u debci zfs-linux -- qemu.
The test scripts in zfs-linux always fail. "summary" shows:


kernel-smoke-testFAIL non-zero exit status 1
kernel-ztest FAIL stderr: 
zfs-test-suite   FAIL non-zero exit status 1
dkms-zfs-testPASS
binary-debs-modules  PASS
binary-debs-modules-udeb PASS

The reason behind kernel-smoke-test and zfs-test-suite is

modprobe: FATAL: Module zfs not found in directory /lib/modules/5.10.0-3-amd64

The full log of autopkgtest is also attached.

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


zfs-log.tar.xz
Description: application/xz

Bug#767105: gnunet: user unable to access

[Daniel Baumann]

close 767105 0.14.0-1
thanks

Hi,

here are a few thoughts/notes..

first, the original problem per se doesn't exist anymore, and adding the
local unprivileged user to a group isn't something we should or could do
in the packaging (it's left for the local admin to do so, and adding a
debconf question for that doesn't make much sense).

then, the newer gnunet versions have moved to start and manage things
with systemd user services, which is great. this however needs more
documentation in the packaging and more thoughts on making this as
painless as possible while still being policy compliant.

for that, upstream has made a few things on top of the debian packaging
but they need to be adjusted for policy compliance.

so, while closing this bug, the 0.14.x packages will get this, in a
different way/different reasons etc., implemented in the next couple of
weeks.

Regards,
Daniel

Bug#972406: assertion failure in libgsf due to AppArmor failure

[Daniel Baumann]

close 972406 1:1.11-1
thanks

Hi,

thank you for the report. Luckily I cannot reproduce it anymore with the
current version in testing (and newer), so I think this has been solved
at some point in either of the three packages involved.

Regards,
Daniel

Bug#983662: openvpn: autopkgtest always fails on qemu testbed

[Ryutaroh Matsumoto]

Source: openvpn
Version: 2.5.1-1
Severity: normal
Tags: sid bullseye

Dear Maintainer,

I made an autopkgtest qemu testbed by debci setup -f -s sid -a amd64 -b qemu.
Then I run autopkgtest -U -B -u debci openvpn -- qemu.

The test scripts in openvpn always fail. "summary" shows:

server-setup-with-ca FAIL non-zero exit status 1
server-setup-with-static-key FAIL non-zero exit status 1

Inspection to log files does not give any useful cues to identify the
cuase of the test failure.
Full log of autopkgtest is attached.

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


openvpn-log.tar.xz
Description: application/xz

Bug#983663: openjpeg2: CVE-2020-27843

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.4.0-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/1297
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.3.0-2+deb10u1
Control: found -1 2.3.0-2

Hi,

The following vulnerability was published for openjpeg2.

CVE-2020-27843[0]:
| A flaw was found in OpenJPEG in versions prior to 2.4.0. This flaw
| allows an attacker to provide specially crafted input to the
| conversion or encoding functionality, causing an out-of-bounds read.
| The highest threat from this vulnerability is system availability.

The issue is prevented in 2.4.0 but as per upstream the commited
change is unlikely to be the proper fix. Thus still keeping the 2.4.0
as affected.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-27843
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27843
[1] https://github.com/uclouvain/openjpeg/issues/1297

Regards,
Salvatore

Bug#981553: CVE-2021-3156 backport for jessie

[Bastian Germann]

control: tag -1 - moreinfo

Am 27.02.21 um 17:34 schrieb Hilko Bengen:

Since LTS support for jessie ended on June 30, 2020, do you expect
anything else to happen with these?


I do not expect it. But as I fixed it for jessie and maybe there is 
someone out there who is interested, I provided the patches.


However, if someone is willing to release a new jessie version, please 
do so.

Bug#983664: jackson-dataformat-cbor: CVE-2020-28491

[Salvatore Bonaccorso]

Source: jackson-dataformat-cbor
Version: 2.7.8-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/FasterXML/jackson-dataformats-binary/issues/186
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for jackson-dataformat-cbor.

CVE-2020-28491[0]:
| This affects the package com.fasterxml.jackson.dataformat:jackson-
| dataformat-cbor from 0 and before 2.11.4, from 2.12.0-rc1 and before
| 2.12.1. Unchecked allocation of byte buffer can cause a
| java.lang.OutOfMemoryError exception.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-28491
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28491
[1] https://github.com/FasterXML/jackson-dataformats-binary/issues/186
[2] 
https://github.com/FasterXML/jackson-dataformats-binary/commit/de072d314af8f5f269c8abec6930652af67bc8e6
[2] https://snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONDATAFORMAT-1047329

Regards,
Salvatore

Bug#983665: cupt: annotate test dependencies

[Helmut Grohne]

Source: cupt
Version: 2.10.4+nmu1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cupt cannot be cross built from source, because its Build-Depends are
not satisfiable. Instead of looking into such a difficult problem, I
looked for easily droppable dependencies and noticed that debian/control
already partitions its build dependencies into functional categories via
source code comments. All that is missing here is annotating the already
separated test dependencies . Please consider applying the
attached patch.

Helmut
diff --minimal -Nru cupt-2.10.4+nmu1/debian/changelog 
cupt-2.10.4+nmu2/debian/changelog
--- cupt-2.10.4+nmu1/debian/changelog   2020-06-07 22:56:21.0 +0200
+++ cupt-2.10.4+nmu2/debian/changelog   2021-02-28 08:52:01.0 +0100
@@ -1,3 +1,10 @@
+cupt (2.10.4+nmu2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate test dependencies . (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 28 Feb 2021 08:52:01 +0100
+
 cupt (2.10.4+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru cupt-2.10.4+nmu1/debian/control 
cupt-2.10.4+nmu2/debian/control
--- cupt-2.10.4+nmu1/debian/control 2020-06-07 22:52:19.0 +0200
+++ cupt-2.10.4+nmu2/debian/control 2021-02-28 08:51:59.0 +0100
@@ -18,14 +18,14 @@
   doxygen,
   txt2tags,
 # test suite
-  gpgv (>= 2),
-  gnupg (>= 2),
-  ed,
-  libipc-run3-perl,
-  liblist-moreutils-perl,
-  libtest-dir-perl,
-  libexpect-simple-perl,
-  locales-all
+  gpgv (>= 2) ,
+  gnupg (>= 2) ,
+  ed ,
+  libipc-run3-perl ,
+  liblist-moreutils-perl ,
+  libtest-dir-perl ,
+  libexpect-simple-perl ,
+  locales-all 
 Maintainer: Eugene V. Lyubimkin 
 Homepage: https://wiki.debian.org/Cupt
 Standards-Version: 4.1.3

Bug#983666: fontforge FTCBFS: python build-depends not installable

[Helmut Grohne]

Source: fontforge
Version: 1:20201107~dfsg-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

fontforge fails to cross build from source, because its python build
depends are not installable. An earlier bug already moved much of the
documentation dependencies to B-D-I, so python is really all that is
left. fontforge requests the python interpreter for the host
architecture, but it really needs a runnable python interpreter and a
host architecture python development package. Please consider applying
the attached patch to multiarchify the dependencies.

Helmut
diff --minimal -Nru fontforge-20201107~dfsg/debian/changelog 
fontforge-20201107~dfsg/debian/changelog
--- fontforge-20201107~dfsg/debian/changelog2021-01-15 16:55:46.0 
+0100
+++ fontforge-20201107~dfsg/debian/changelog2021-02-28 08:58:14.0 
+0100
@@ -1,3 +1,10 @@
+fontforge (1:20201107~dfsg-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Mutiarchify python Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 28 Feb 2021 08:58:14 +0100
+
 fontforge (1:20201107~dfsg-4) unstable; urgency=medium
 
   * Rename extended to extendeddbl to avoid FTBFS on Hurd.
diff --minimal -Nru fontforge-20201107~dfsg/debian/control 
fontforge-20201107~dfsg/debian/control
--- fontforge-20201107~dfsg/debian/control  2021-01-15 08:41:04.0 
+0100
+++ fontforge-20201107~dfsg/debian/control  2021-02-28 08:58:13.0 
+0100
@@ -22,14 +22,15 @@
  libjpeg-dev,
  libpango1.0-dev,
  libpng-dev,
+ libpython3-dev,
  libspiro-dev,
  libtiff5-dev,
  libuninameslist-dev,
  libxml2-dev,
  libglib2.0-dev,
  ninja-build,
- python3,
- python3-dev,
+ python3:any,
+ python3-dev:any,
  libwoff-dev,
  libgtk-3-dev,
  pkg-kde-tools

Bug#983667: syncthing: Possible incorrect remote sync status after removing device/resetting index

[Simon Frei]

Package: syncthing
Version: 1.12.1~ds1-2
Severity: important

As discussed on the go-team mailing list [1], I am filing this bug to
address an important fix in upstream since the version to be included in
stable.

There's a bug in the code that determines sync status when removing a
device (or
resetting an index). This may leed to incorrect remote sync status.

The patch fixing this is attached.

[1]: https://lists.debian.org/debian-go/2021/02/msg00067.html

>From 631cf607495f4a21c72c731f3fb54bbeacd9af15 Mon Sep 17 00:00:00 2001
From: Simon Frei 
Date: Mon, 8 Feb 2021 08:38:41 +0100
Subject: [PATCH 4/4] lib/db: Fix and improve removing entries from global (ref
 #6501) (#7336)

---
 lib/db/db_test.go  | 43 ++
 lib/db/transactions.go | 27 --
 2 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/lib/db/db_test.go b/lib/db/db_test.go
index 07c2ae7bc..886e955fd 100644
--- a/lib/db/db_test.go
+++ b/lib/db/db_test.go
@@ -942,6 +942,49 @@ func TestDuplicateNeedCount(t *testing.T) {
 	}
 }
 
+func TestNeedAfterDropGlobal(t *testing.T) {
+	db := NewLowlevel(backend.OpenMemory())
+	defer db.Close()
+
+	folder := "test"
+	testFs := fs.NewFilesystem(fs.FilesystemTypeFake, "")
+
+	fs := NewFileSet(folder, testFs, db)
+
+	// Initial:
+	// Three devices and a file "test": local has Version 1, remoteDevice0
+	// Version 2 and remoteDevice2 doesn't have it.
+	// All of them have "bar", just so the db knows about remoteDevice2.
+	files := []protocol.FileInfo{
+		{Name: "foo", Version: protocol.Vector{}.Update(myID), Sequence: 1},
+		{Name: "bar", Version: protocol.Vector{}.Update(myID), Sequence: 2},
+	}
+	fs.Update(protocol.LocalDeviceID, files)
+	files[0].Version = files[0].Version.Update(myID)
+	fs.Update(remoteDevice0, files)
+	fs.Update(remoteDevice1, files[1:])
+
+	// remoteDevice1 needs one file: test
+	snap := fs.Snapshot()
+	c := snap.NeedSize(remoteDevice1)
+	if c.Files != 1 {
+		t.Errorf("Expected 1 needed files initially, got %v", c.Files)
+	}
+	snap.Release()
+
+	// Drop remoteDevice0, i.e. remove all their files from db.
+	// That changes the global file, which is now what local has.
+	fs.Drop(remoteDevice0)
+
+	// remoteDevice1 still needs test.
+	snap = fs.Snapshot()
+	c = snap.NeedSize(remoteDevice1)
+	if c.Files != 1 {
+		t.Errorf("Expected still 1 needed files, got %v", c.Files)
+	}
+	snap.Release()
+}
+
 func numBlockLists(db *Lowlevel) (int, error) {
 	it, err := db.Backend.NewPrefixIterator([]byte{KeyTypeBlockList})
 	if err != nil {
diff --git a/lib/db/transactions.go b/lib/db/transactions.go
index 02c9a8e05..e97dcdd25 100644
--- a/lib/db/transactions.go
+++ b/lib/db/transactions.go
@@ -813,11 +813,11 @@ func (t readWriteTransaction) removeFromGlobal(gk, keyBuf, folder, device, file
 	}
 
 	var global protocol.FileIntf
-	var gotGlobal, ok bool
+	var gotGlobal bool
 
-	globalFV, ok := fl.GetGlobal()
+	globalFV, haveGlobal := fl.GetGlobal()
 	// Add potential needs of the removed device
-	if ok && !globalFV.IsInvalid() && Need(globalFV, false, protocol.Vector{}) && !Need(oldGlobalFV, haveRemoved, removedFV.Version) {
+	if haveGlobal && !globalFV.IsInvalid() && Need(globalFV, false, protocol.Vector{}) && !Need(oldGlobalFV, haveRemoved, removedFV.Version) {
 		keyBuf, global, _, err = t.getGlobalFromVersionList(keyBuf, folder, file, true, fl)
 		if err != nil {
 			return nil, err
@@ -840,16 +840,23 @@ func (t readWriteTransaction) removeFromGlobal(gk, keyBuf, folder, device, file
 		return keyBuf, nil
 	}
 
-	var f protocol.FileIntf
-	keyBuf, f, err = t.getGlobalFromFileVersion(keyBuf, folder, file, true, oldGlobalFV)
+	var oldGlobal protocol.FileIntf
+	keyBuf, oldGlobal, err = t.getGlobalFromFileVersion(keyBuf, folder, file, true, oldGlobalFV)
 	if err != nil {
 		return nil, err
 	}
-	meta.removeFile(protocol.GlobalDeviceID, f)
+	meta.removeFile(protocol.GlobalDeviceID, oldGlobal)
 
 	// Remove potential device needs
-	if fv, have := fl.Get(protocol.LocalDeviceID[:]); Need(removedFV, have, fv.Version) {
-		meta.removeNeeded(protocol.LocalDeviceID, f)
+	shouldRemoveNeed := func(dev protocol.DeviceID) bool {
+		fv, have := fl.Get(dev[:])
+		if !Need(oldGlobalFV, have, fv.Version) {
+			return false // Didn't need it before
+		}
+		return !haveGlobal || !Need(globalFV, have, fv.Version)
+	}
+	if shouldRemoveNeed(protocol.LocalDeviceID) {
+		meta.removeNeeded(protocol.LocalDeviceID, oldGlobal)
 		if keyBuf, err = t.updateLocalNeed(keyBuf, folder, file, false); err != nil {
 			return nil, err
 		}
@@ -858,8 +865,8 @@ func (t readWriteTransaction) removeFromGlobal(gk, keyBuf, folder, device, file
 		if bytes.Equal(dev[:], device) { // Was the previous global
 			continue
 		}
-		if fv, have := fl.Get(dev[:]); Need(removedFV, have, fv.Version) {
-			meta.removeNeeded(dev, f)
+		if shouldRemoveNeed(dev) {
+			meta.removeNeeded(dev, oldGlobal)
 		}
 	}
 
-- 
2.30.0

Bug#983668: syncthing: Prevent dead-lock in index-sender on db error

[Simon Frei]

Package: syncthing
Version: 1.12.1~ds1-2
Severity: important

As discussed on the go-team mailing list [1], I am filing this bug to
address an important fix in upstream since the version to be included in
stable.

An error in the database can lead to a dead-lock in the index-sender.

The patch fixing this is attached.

[1]: https://lists.debian.org/debian-go/2021/02/msg00067.html
>From 6eed8ef5f0e253878221546afe395af103b1d43b Mon Sep 17 00:00:00 2001
From: Simon Frei 
Date: Wed, 30 Dec 2020 09:59:11 +0100
Subject: [PATCH 3/4] lib/model: Handle index sender terminating due to error
 (fixes #7231) (#7232)

---
 lib/model/indexsender.go | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lib/model/indexsender.go b/lib/model/indexsender.go
index 7bca77447..1883a7e83 100644
--- a/lib/model/indexsender.go
+++ b/lib/model/indexsender.go
@@ -30,6 +30,7 @@ type indexSender struct {
 	prevSequence int64
 	evLogger events.Logger
 	connClosed   chan struct{}
+	done chan struct{}
 	tokensuture.ServiceToken
 	pauseChanchan struct{}
 	resumeChan   chan *db.FileSet
@@ -38,6 +39,7 @@ type indexSender struct {
 func (s *indexSender) Serve(ctx context.Context) (err error) {
 	l.Debugf("Starting indexSender for %s to %s at %s (slv=%d)", s.folder, s.conn.ID(), s.conn, s.prevSequence)
 	defer func() {
+		close(s.done)
 		err = util.NoRestartErr(err)
 		l.Debugf("Exiting indexSender for %s to %s at %s: %v", s.folder, s.conn.ID(), s.conn, err)
 	}()
@@ -101,14 +103,14 @@ func (s *indexSender) Serve(ctx context.Context) (err error) {
 
 func (s *indexSender) resume(fset *db.FileSet) {
 	select {
-	case <-s.connClosed:
+	case <-s.done:
 	case s.resumeChan <- fset:
 	}
 }
 
 func (s *indexSender) pause() {
 	select {
-	case <-s.connClosed:
+	case <-s.done:
 	case s.pauseChan <- struct{}{}:
 	}
 }
@@ -314,6 +316,7 @@ func (r *indexSenderRegistry) addLocked(folder config.FolderConfiguration, fset
 	is := &indexSender{
 		conn: r.conn,
 		connClosed:   r.closed,
+		done: make(chan struct{}),
 		folder:   folder.ID,
 		folderIsReceiveEncrypted: folder.Type == config.FolderTypeReceiveEncrypted,
 		fset: fset,
@@ -366,7 +369,7 @@ func (r *indexSenderRegistry) removeAllExcept(except map[string]struct{}) {
 			delete(r.indexSenders, folder)
 		}
 	}
-	for folder := range r.indexSenders {
+	for folder := range r.startInfos {
 		if _, ok := except[folder]; !ok {
 			delete(r.startInfos, folder)
 		}
-- 
2.30.0

Bug#983669: syncthing: Mismatching index-ids that can cause index retransfer or inconsistency

[Simon Frei]

Package: syncthing
Version: 1.12.1~ds1-2
Severity: important

As discussed on the go-team mailing list [1], I am filing this bug to
address an important fix in upstream since the version to be included in
stable.

There have been reports of full index retransfers on almost every
restart [2], which uses significant resources (network, disk io, ...).
The underlying bug may also cause inconsistencies in the displayed sync
completion, though that has not been observed.

I propose to apply the PR fixing this [3] with the patch attached.
Please indicate if you'd prefer an MR on salsa, then I'll do that
instead in the future.

[1]: https://lists.debian.org/debian-go/2021/02/msg00067.html
[2]:
https://forum.syncthing.net/t/mismatching-index-id-for-us-on-almost-every-restart-again/16036
[3]: https://github.com/syncthing/syncthing/pull/7211
>From 5ee8b8a6aa4b5366a721f0531ef4df45780a3801 Mon Sep 17 00:00:00 2001
From: Simon Frei 
Date: Mon, 21 Dec 2020 11:32:59 +0100
Subject: [PATCH 1/4] lib/db: Prevent IndexID creation race (#7211)

---
 lib/db/lowlevel.go |  2 ++
 lib/db/set.go  | 33 ++---
 lib/db/set_test.go | 26 ++
 3 files changed, 50 insertions(+), 11 deletions(-)

diff --git a/lib/db/lowlevel.go b/lib/db/lowlevel.go
index 8074564aa..347237ea4 100644
--- a/lib/db/lowlevel.go
+++ b/lib/db/lowlevel.go
@@ -65,6 +65,7 @@ type Lowlevel struct {
 	gcKeyCount int
 	indirectGCInterval time.Duration
 	recheckIntervaltime.Duration
+	oneFileSetCreated  chan struct{}
 }
 
 func NewLowlevel(backend backend.Backend, opts ...Option) *Lowlevel {
@@ -81,6 +82,7 @@ func NewLowlevel(backend backend.Backend, opts ...Option) *Lowlevel {
 		gcMut:  sync.NewRWMutex(),
 		indirectGCInterval: indirectGCDefaultInterval,
 		recheckInterval:recheckDefaultInterval,
+		oneFileSetCreated:  make(chan struct{}),
 	}
 	for _, opt := range opts {
 		opt(db)
diff --git a/lib/db/set.go b/lib/db/set.go
index 41e1c7ecd..66bf2ccc6 100644
--- a/lib/db/set.go
+++ b/lib/db/set.go
@@ -39,13 +39,27 @@ type FileSet struct {
 type Iterator func(f protocol.FileIntf) bool
 
 func NewFileSet(folder string, fs fs.Filesystem, db *Lowlevel) *FileSet {
-	return &FileSet{
+	select {
+	case <-db.oneFileSetCreated:
+	default:
+		close(db.oneFileSetCreated)
+	}
+	s := &FileSet{
 		folder:  folder,
 		fs:  fs,
 		db:  db,
 		meta:db.loadMetadataTracker(folder),
 		updateMutex: sync.NewMutex(),
 	}
+	if id := s.IndexID(protocol.LocalDeviceID); id == 0 {
+		// No index ID set yet. We create one now.
+		id = protocol.NewIndexID()
+		err := s.db.setIndexID(protocol.LocalDeviceID[:], []byte(s.folder), id)
+		if err != nil && !backend.IsClosed(err) {
+			fatalError(err, fmt.Sprintf("%s Creating new IndexID", s.folder), s.db)
+		}
+	}
+	return s
 }
 
 func (s *FileSet) Drop(device protocol.DeviceID) {
@@ -357,16 +371,6 @@ func (s *FileSet) IndexID(device protocol.DeviceID) protocol.IndexID {
 	} else if err != nil {
 		fatalError(err, opStr, s.db)
 	}
-	if id == 0 && device == protocol.LocalDeviceID {
-		// No index ID set yet. We create one now.
-		id = protocol.NewIndexID()
-		err := s.db.setIndexID(device[:], []byte(s.folder), id)
-		if backend.IsClosed(err) {
-			return 0
-		} else if err != nil {
-			fatalError(err, opStr, s.db)
-		}
-	}
 	return id
 }
 
@@ -432,7 +436,14 @@ func DropFolder(db *Lowlevel, folder string) {
 
 // DropDeltaIndexIDs removes all delta index IDs from the database.
 // This will cause a full index transmission on the next connection.
+// Must be called before using FileSets, i.e. before NewFileSet is called for
+// the first time.
 func DropDeltaIndexIDs(db *Lowlevel) {
+	select {
+	case <-db.oneFileSetCreated:
+		panic("DropDeltaIndexIDs must not be called after NewFileSet for the same Lowlevel")
+	default:
+	}
 	opStr := "DropDeltaIndexIDs"
 	l.Debugf(opStr)
 	dbi, err := db.NewPrefixIterator([]byte{KeyTypeIndexID})
diff --git a/lib/db/set_test.go b/lib/db/set_test.go
index e2833ffbb..89adee96d 100644
--- a/lib/db/set_test.go
+++ b/lib/db/set_test.go
@@ -1757,6 +1757,32 @@ func TestNoIndexIDResetOnDrop(t *testing.T) {
 	}
 }
 
+func TestConcurrentIndexID(t *testing.T) {
+	done := make(chan struct{})
+	var ids [2]protocol.IndexID
+	setID := func(s *db.FileSet, i int) {
+		ids[i] = s.IndexID(protocol.LocalDeviceID)
+		done <- struct{}{}
+	}
+
+	max := 100
+	if testing.Short() {
+		max = 10
+	}
+	for i := 0; i < max; i++ {
+		ldb := db.NewLowlevel(backend.OpenMemory())
+		s := db.NewFileSet("test", fs.NewFilesystem(fs.FilesystemTypeFake, ""), ldb)
+		go setID(s, 0)
+		go setID(s, 1)
+		<-done
+		<-done
+		ldb.Close()
+		if ids[0] != ids[1] {
+			t.Fatalf("IDs differ after %v rounds", i)
+		}
+	}
+}
+
 func replace(fs *db.FileSet, device protocol.DeviceID, files []protocol.FileInfo) {
 	fs.Drop(device)
 	fs.Update(device, files)
-- 
2.30.0

Bug#983670: syncthing: Connection take a long time to close after an error

[Simon Frei]

Package: syncthing
Version: 1.12.1~ds1-2
Severity: important

As discussed on the go-team mailing list [1], I am filing this bug to
address an important fix in upstream since the version to be included in
stable.

If an error occurs on the connection, the underlying tls connection isn't
closed. The connection is only noticed as closed and reestablished onced
timed
out, which adds a lot of unnecessary delay.

The patch fixing this is attached.

[1]: https://lists.debian.org/debian-go/2021/02/msg00067.html


From dfc03a6a37f9e13a151754fb5b3ea4a9aeaae94f Mon Sep 17 00:00:00 2001
From: Simon Frei 
Date: Mon, 21 Dec 2020 11:40:51 +0100
Subject: [PATCH 2/4] lib: Close underlying conn in protocol (fixes #7165)
 (#7212)

---
 lib/api/mocked_model_test.go   |  5 ++--
 lib/connections/service.go |  7 ++---
 lib/connections/structs.go | 33 +++--
 lib/model/fakeconns_test.go| 52 ++
 lib/model/model.go | 10 +++
 lib/model/model_test.go|  2 +-
 lib/protocol/benchmark_test.go |  5 ++--
 lib/protocol/encryption.go |  5 +---
 lib/protocol/protocol.go   | 42 +--
 lib/protocol/protocol_test.go  | 22 +++---
 lib/testutils/testutils.go | 47 ++
 11 files changed, 106 insertions(+), 124 deletions(-)

diff --git a/lib/api/mocked_model_test.go b/lib/api/mocked_model_test.go
index 68bd07809..a9a0c9922 100644
--- a/lib/api/mocked_model_test.go
+++ b/lib/api/mocked_model_test.go
@@ -11,7 +11,6 @@ import (
 	"net"
 	"time"
 
-	"github.com/syncthing/syncthing/lib/connections"
 	"github.com/syncthing/syncthing/lib/db"
 	"github.com/syncthing/syncthing/lib/model"
 	"github.com/syncthing/syncthing/lib/protocol"
@@ -114,7 +113,7 @@ func (m *mockedModel) ScanFolderSubdirs(folder string, subs []string) error {
 
 func (m *mockedModel) BringToFront(folder, file string) {}
 
-func (m *mockedModel) Connection(deviceID protocol.DeviceID) (connections.Connection, bool) {
+func (m *mockedModel) Connection(deviceID protocol.DeviceID) (protocol.Connection, bool) {
 	return nil, false
 }
 
@@ -157,7 +156,7 @@ func (m *mockedModel) DownloadProgress(deviceID protocol.DeviceID, folder string
 	return nil
 }
 
-func (m *mockedModel) AddConnection(conn connections.Connection, hello protocol.Hello) {}
+func (m *mockedModel) AddConnection(conn protocol.Connection, hello protocol.Hello) {}
 
 func (m *mockedModel) OnHello(protocol.DeviceID, net.Addr, protocol.Hello) error {
 	return nil
diff --git a/lib/connections/service.go b/lib/connections/service.go
index 4a347be57..d93e11379 100644
--- a/lib/connections/service.go
+++ b/lib/connections/service.go
@@ -325,15 +325,14 @@ func (s *service) handle(ctx context.Context) error {
 		var protoConn protocol.Connection
 		passwords := s.cfg.FolderPasswords(remoteID)
 		if len(passwords) > 0 {
-			protoConn = protocol.NewEncryptedConnection(passwords, remoteID, rd, wr, s.model, c.String(), deviceCfg.Compression)
+			protoConn = protocol.NewEncryptedConnection(passwords, remoteID, rd, wr, c, s.model, c, deviceCfg.Compression)
 		} else {
-			protoConn = protocol.NewConnection(remoteID, rd, wr, s.model, c.String(), deviceCfg.Compression)
+			protoConn = protocol.NewConnection(remoteID, rd, wr, c, s.model, c, deviceCfg.Compression)
 		}
-		modelConn := completeConn{c, protoConn}
 
 		l.Infof("Established secure connection to %s at %s", remoteID, c)
 
-		s.model.AddConnection(modelConn, hello)
+		s.model.AddConnection(protoConn, hello)
 		continue
 	}
 	return nil
diff --git a/lib/connections/structs.go b/lib/connections/structs.go
index 3918a95fc..f750effe4 100644
--- a/lib/connections/structs.go
+++ b/lib/connections/structs.go
@@ -22,31 +22,6 @@ import (
 	"github.com/thejerf/suture/v4"
 )
 
-// Connection is what we expose to the outside. It is a protocol.Connection
-// that can be closed and has some metadata.
-type Connection interface {
-	protocol.Connection
-	Type() string
-	Transport() string
-	RemoteAddr() net.Addr
-	Priority() int
-	String() string
-	Crypto() string
-}
-
-// completeConn is the aggregation of an internalConn and the
-// protocol.Connection running on top of it. It implements the Connection
-// interface.
-type completeConn struct {
-	internalConn
-	protocol.Connection
-}
-
-func (c completeConn) Close(err error) {
-	c.Connection.Close(err)
-	c.internalConn.Close()
-}
-
 type tlsConn interface {
 	io.ReadWriteCloser
 	ConnectionState() tls.ConnectionState
@@ -107,12 +82,12 @@ func (t connType) Transport() string {
 	}
 }
 
-func (c internalConn) Close() {
+func (c internalConn) Close() error {
 	// *tls.Conn.Close() does more than it says on the tin. Specifically, it
 	// sends a TLS alert message, which might block forever if the
 	// connection is dead and we don't have a deadline set.
 	_ = c.SetWriteDeadline(time.Now().Add(250 * time.Millisecond))
-	_ = c.tlsConn.Close()
+	return c.tlsConn.Close()
 }
 
 func (c internalConn) Type() str

Bug#983671: reportbug: Please detect when exim is configured to work locally only

[Simon Frei]

Package: reportbug
Version: 7.10.2
Severity: wishlist

Dear Maintainer,

I tried to send a bug report and failed, for the reasons explained when
reporting a bug against reportbug: Exim is by default set up to deliver
mails locally only.
However reportbug did not indicate in any way it was the case, quite the
contrary. It reported success and thanked me for reporting the bug. It
would be very helpful if reportbug detected that the mail wasn't
actually sent respectively already before, that exim is configured for
local mail only, and then prints a notice to the user about it.
Basically the exact text displayed when reporting a bug against
reportbug could be printed verbatim there.

Best,
Simon


-- Package-specific info:
** /home/simon/.reportbugrc:
email freisi...@gmail.com

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

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

Versions of packages reportbug depends on:
ii apt 2.1.20
ii python3 3.9.1-1
ii python3-reportbug 7.10.2
ii sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn claws-mail 
pn debconf-utils 
pn debsums 
pn dlocate 
ii emacs-bin-common 1:27.1+1-3
ii exim4-daemon-light [mail-transport-agent] 4.94-15
ii file 1:5.39-3
ii gnupg 2.2.27-1
pn python3-urwid 
pn reportbug-gtk 
ii xdg-utils 1.1.3-4

Versions of packages python3-reportbug depends on:
ii apt 2.1.20
ii file 1:5.39-3
ii python3 3.9.1-1
ii python3-apt 2.1.7
ii python3-debian 0.1.39
ii python3-debianbts 3.1.0
ii python3-requests 2.25.1+dfsg-2
ii sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983672: linux-image: fails to recognize certain microSD cards

[José Luis González]

Package: linux-image-4.19.0-13-amd64
Version: 4.19.160-2
Tags: patch upstream

Certain SD cards set a flag that isn't really defined in the SD spec
but the mmc should be ignoring. It turns out it doesn't, so the cards
don't get recognized properly making it impossible to use them.

There is a bug reported in kernel.org's bugzilla that explains it all:

https://bugzilla.kernel.org/show_bug.cgi?id=202473

Contained is a very small patch that fixes the problem:

https://patchwork.kernel.org/project/linux-mmc/patch/20190827081043.15443-1-ulf.hans...@linaro.org/

Please, incorporate the patch so that we can use these cards.

I have tested both version 4.19.160-2 and version 5.9.15-1~bpo10+1
(this from buster-backports), and neither mount my card successfully so
I understand the patch isn't incorporated to either.

I'd very much appreciate if the fix got into buster-backports.

Thank you so much in advance.

Bug#898177: [related feature respect /etc/mailname] Re: please add MAILFROM to cron

[Tomas Pospisek]

:+1 thanks Javier!

On Fri, 26 Feb 2021, Javier Fernandez-Sanguino wrote:


Dear Tomas,

El jue., 25 feb. 2021 12:52, Tomas Pospisek  escribió:
  Javier,

  seeing that you do not seem to have been working on cron for a few years
  would it be OK with you if I posted something along these lines to
  debian-devel:

I can send a message along the lines of your proposal below to d-d. Will 
schedule it to do it soon.

Bug#983673: octave-openems: missing h5readatt_octave.cc

[Wolfgang Rosner]

Package: octave-openems
Version: 0.0.35+dfsg.1-3
Severity: normal
Tags: d-i

Installed openems and octave-openems

tried tutorials to "check correct installation".
failed at
https://openems.de/index.php/Tutorial:_Rectangular_Waveguide.html

- plot 3 is empty
- seems to have trouble to set up hdf5

digging down, I could find a "works for me workaround", but no patch yet
dropping my findings here, just in case sbdy wants to pick up


8<-
octave:35> setup
setting up openEMS matlab/octave interface
compiling oct files
HDF5 library path found
at: /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.so 
/usr/lib/x86_64-linux-gnu/hdf5/openmpi
HDF5 include path found at: /usr/include/hdf5/serial/hdf5.h
/usr/include/hdf5/openmpi
g++: error: h5readatt_octave.cc: Datei oder Verzeichnis nicht gefunden
--8<-

what I found:

- issue not covered in recent unstable changelog
- h5readatt_octave.cc is missing
- maybe deliberately, since it does not work?
- looks like the upstream "setup.m" does not get it right in debian
  ecosystem
- I have both libhdf5-103:amd64 (aka 'serial') and
  libhdf5-openmpi-103:amd64 installed
- trying to uninstall openmpi version pulls out octave-openems, too

so I tried

- pulled h5readatt_octave.cc from upstream source to try manual build
- can build with
mkoctfile -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi
  -I/usr/include/hdf5/openmpi
  -I/usr/lib/x86_64-linux-gnu/openmpi/include -lhdf5 h5readatt_octave.cc

- upstream "setup.m" appears just to include hdf5, not the
/usr/lib/x86_64-linux-gnu/openmpi/include

-  and it does not run in the tutorial:

---8<---
error: ReadHDF5Attribute:
/usr/share/octave/packages/openems-0.0.35/h5readatt_octave.oct: failed
  to load: /usr/share/octave/packages/openems-0.0.35/h5readatt_octave.oct:
  undefined symbol: _ZN3MPI8Datatype4FreeEv 
---8<---

... obviously there are deeper dependency issues...

- next try: manually select serial hdf5:

mkoctfile -L/usr/lib/x86_64-linux-gnu/hdf5/serial
  -I/usr/include/hdf5/serial -lhdf5 h5readatt_octave.cc


OK, this way it works (both manual build and tutorial)
... just to find out that the hdf5 plot capabilities are quite
rudimentary.


So maybe there is no serious need for octave hdf5 beyond the tutorial?
At least not in applications that beg for openmpi.
Assume they'll use sth more serious like paraview?

Proposals to remove the hurdle for beginners:
- leave it as it is but put a proper note at a proper place 
  e.g. in the console output of setup.m
- strip down half baken upstream setup.m to forcefully/preferrable 
  compile against 'serial', not 'openmpi'
- remove the openmpi dependency of octeave-openems


You decide.





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

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

Versions of packages octave-openems depends on:
ii  epstool 3.09-1
ii  fig2dev [transfig]  1:3.2.7a-5+deb10u3
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgomp18.3.0-6
ii  libhdf5-cpp-103 1.10.4+repack-10
ii  liboctave6  4.4.1-5
ii  libstdc++6  8.3.0-6
ii  octave  4.4.1-5
ii  openems 0.0.35+dfsg.1-3

octave-openems recommends no packages.

octave-openems suggests no packages.

-- no debconf information

Bug#983674: libvirt: autopkgtest always fails on qemu testbed with -u debci

[Ryutaroh Matsumoto]

Source: libvirt
Version: 7.0.0-3
Severity: important
Tags: sid bullseye

Dear Maintainer,

I made an autopkgtest qemu testbed by debci setup -f -s sid -a amd64 -b qemu.
Then I run autopkgtest -U -B -u debci libvirt -- qemu.

"smoke-qemu-session" always fails. Its stdout shows

echo Running as debci
  QEMU: Checking for hardware virtualization : 
PASS
  QEMU: Checking if device /dev/kvm exists   : 
PASS
  QEMU: Checking if device /dev/kvm is accessible: 
FAIL (Check /dev/kvm is world writable or you are in a group that is allowed to 
access it)
  QEMU: Checking if device /dev/vhost-net exists : 
PASS
  QEMU: Checking if device /dev/net/tun exists   : 
PASS
  QEMU: Checking for cgroup 'cpu' controller support : 
PASS
  QEMU: Checking for cgroup 'cpuacct' controller support : 
PASS
  QEMU: Checking for cgroup 'cpuset' controller support  : 
PASS
  QEMU: Checking for cgroup 'memory' controller support  : 
PASS
  QEMU: Checking for cgroup 'devices' controller support : 
WARN (Enable 'devices' in kernel Kconfig file or mount/enable cgroup controller 
in your system)
  QEMU: Checking for cgroup 'blkio' controller support   : 
PASS
  QEMU: Checking for device assignment IOMMU support : 
WARN (No ACPI DMAR table found, IOMMU either disabled in BIOS or not supported 
by this hardware platform)
  QEMU: Checking for secure guest support: 
WARN (Unknown if this platform has Secure Guest support)


Its stderr shows


+ virt-host-validate qemu
+ true
+ virsh capabilities
+ virsh capabilities
+ grep -qs arch name='x86_64'
+ virsh capabilities
+ grep -qs os_type>hvm
+ virt-xml-validate debian/tests/smoke-qemu-session.xml
debian/tests/smoke-qemu-session.xml validates
+ virsh define debian/tests/smoke-qemu-session.xml
error: Failed to define domain from debian/tests/smoke-qemu-session.xml
error: unsupported configuration: Emulator '/usr/bin/kvm' does not support virt 
type 'kvm'
+ cleanup
+ [ -z  ]
+ virsh destroy sqs
error: failed to get domain 'sqs'
+ true
+ virsh undefine sqs
error: failed to get domain 'sqs'
+ true
+ CLEANED_UP=1

I suspect that "Rectrictions: needs-root" is forgotten in the test 
specification.

The full log of autopkgtest is attached.

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


libvirt-log.tar.xz
Description: application/xz

Bug#983675: wev: Emits "invalid version" error at startup and consumes 100% CPU

[Ben Harris]

Package: wev
Version: 1.0.0-2
Severity: important
X-Debbugs-Cc: bj...@bjh21.me.uk

Dear Maintainer,

When run with no arguments, "wev" emits an error message and then 
hangs.  "top" shows its CPU usage as 100.0% and on my laptop the fan 
starts up suggesting a lot of CPU usage.  The precise error message 
depends on which Wayland compositor wev running under.

Under GNOME Shell (gnome-shell 3.38.3-2):

wl_registry@2: error 0: invalid version for global wl_seat (17): have 5, wanted 
6

Under Weston (weston 9.0.0-2):

wl_registry@2: error 0: invalid version for global xdg_wm_base (18): have 1, 
wanted 2

I think that, even if wev can't run under a particular compositor, it 
should not consume 100% of a CPU thread while doing so.  I have tagged 
this bug as "important" because it seems that this makes wev useless 
under two major Wayland compositors.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 wev depends on:
ii  libc6   2.31-9
ii  libwayland-client0  1.18.0-2~exp1.1
ii  libxkbcommon0   1.0.3-2

wev recommends no packages.

wev suggests no packages.

-- no debconf information

Bug#983567: Subject: systemd-nspawn: can not run any command related changing the timestamp of files in the i386 bullseye chroot

[Michael Biebl]

Am 26.02.2021 um 18:20 schrieb Michael Biebl:

Control: tags -1 + moreinfo

Hello Binh

Am 26.02.21 um 12:13 schrieb binh1.tran...@toshiba.co.jp:
I enter to the bullseye chroot with i386 architecture by 
systemd-nspawncommand,
and i can't run any command related changing the timestamp of files 
asbelow:

debian-buster:~$ mkdir chroot-bullseye-i386
debian-buster:~$ sudo debootstrap --arch=i386 
bullseyechroot-bullseye-i386 http://deb.debian.org/debian/
debian-buster:~$ sudo systemd-nspawn -q --resolv-conf=off 
--timezone=off-D chroot-bullseye-i386

root@chroot-bullseye-i386:~# touch /usr/bin/bootctl
touch: setting times of '/usr/bin/bootctl': Operation not permitted
root@chroot-bullseye-i386:~# date
Thu Jan 1 00:00:01 UTC 1970

Is this bug of systemd-container package?


Can you describe your host system?


Architecure, debian release etc.
Do you use AppArmor, SeLInux,...?

Bug#983514: cockpit-ws: cockpit tries to write in /etc

[Martin Pitt]

Control: tag -1 upstream fixed-upstream pending
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15438

Hello Nicolas,

Nicolas George [2021-02-25 12:27 +0100]:
> When trying for a read-only root filesystem, I am blocked by the fact
> that cockpit tries to write in /etc at startup:
> 
> Feb 03 17:12:09 kruppe systemd[1]: Starting Cockpit Web Service...
> Feb 03 17:12:09 kruppe remotectl[693]: remotectl: couldn't set certificate 
> permissions: /etc/cockpit/ws-certs.d/0-self-signed.cert: Read-only file system
> Feb 03 17:12:09 kruppe systemd[1]: cockpit.service: Control process exited, 
> code=exited, status=1/FAILURE

Thanks for your report! I sent an upstream PR to fix this.

Martin

Bug#983657: debian-policy: weaken manual page requirement

[Bill Allombert]

On Sun, Feb 28, 2021 at 08:29:21AM +0100, Helmut Grohne wrote:
> So this is actually asking for two distinct things:
>  * Allow moving manual pages to dependencies
>  * Allow demoting such dependencies to recommends
> 
> A possible wording in ch-docs.rst could be:
>  Each program, utility, and function should have an associated manual
> -page included in the same package. It is suggested that all
> +page included in the same package or one of its dependencies or
> +recommended packages. It is suggested that all
>  configuration files also have a manual page included as well. Manual
>  pages for protocols and other auxiliary things are optional.
> 
> What do you think?

The goal is to avoid program to be installed but not their manpages,
so generally I do not find Recommends to be enough.
I would object to manual page being moved to a -doc package even if they
are Recommended, because -doc packages tend to be large while manpages
are usually short and do not require pdf/html readers.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#983676: Add option to set `APT::Keep-Downloaded-Packages` to `true`

[Jonas Meurer]

Package: sbuild
Version: 0.78.1-2
Severity: wishlist

Hello,

since release 0.77.0-1 (commit 1159497b26aabbb3380ac3475c11aff556ca1de2), sbuild
sets the apt configuration option `APT::Keep-Downloaded-Packages` to `false`.
This results in all downloaded packages (e.g. build-dependencies, lintian and
dependencies, etc.) to be thrown away immediately.

While I agree that this should be the default behaviour, there's situations when
instead keeping the packages would be desired: when you're on a data-limited
plan or have limited bandwidth available and you keep rebuilding a package for
debugging purposes, it can be really annoying that sbuild keeps re-downloading
all required packages on each iteration.

For now, I just commented out the respective line that sets the option in
`/usr/share/perl5/Sbuild/ResolverBase.pm`, but a proper sbuild configuration
(and commandline) option would be really nice to have :)

Kind regards
 jonas

Bug#983676: Add option to set `APT::Keep-Downloaded-Packages` to `true`

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Jonas Meurer (2021-02-28 12:05:58)
> since release 0.77.0-1 (commit 1159497b26aabbb3380ac3475c11aff556ca1de2),
> sbuild sets the apt configuration option `APT::Keep-Downloaded-Packages` to
> `false`.  This results in all downloaded packages (e.g. build-dependencies,
> lintian and dependencies, etc.) to be thrown away immediately.
> 
> While I agree that this should be the default behaviour, there's situations 
> when
> instead keeping the packages would be desired: when you're on a data-limited
> plan or have limited bandwidth available and you keep rebuilding a package for
> debugging purposes, it can be really annoying that sbuild keeps re-downloading
> all required packages on each iteration.
> 
> For now, I just commented out the respective line that sets the option in
> `/usr/share/perl5/Sbuild/ResolverBase.pm`, but a proper sbuild configuration
> (and commandline) option would be really nice to have :)

in what way is the APT_KEEP_DOWNLOADED_PACKAGES configuration option (see the
sbuild.conf man page) not sufficient for your use-case?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#983678: Freeze exception for ncdc/1.22.1-2

[Boris Pek]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Dear release team,

Please consider a release exception for my package ncdc [1].

While this package is new in Debian, the project has long history [2], program
is stable and well tested in other GNU/Linux distros [3], upstream is active
and responsive.

Once ncdc package migrates to Debian Bullseye I'll open a removal request for
package microdc2 [4]:
+ project is dead:
   * official website does not exist anymore
   * last release (0.15.6) was in 2006 [5]
   * last commit to git repo was 2013 [6]
   * git repository has been explicitly marked as archived
   * upstream developer is not responsive
+ package is unmaintained [7]

Now microdc2 package does not have known RC bugs and its removal is not urgent
yet, but besides dead upstream there are few additional reasons for this:
* program does not support modern ADC protocol while in Debian repository there
  is server software [8] only for this protocol
* program lucks a lot of features required by regular users (for example,
  connecting to multiple hubs at the same time, etc.)
* ncdc fills the same niche (command line DC client) and has a lot of features
  absent in microdc2

[1] https://tracker.debian.org/pkg/ncdc
[2] https://dev.yorhel.nl/ncdc/changes
[3] https://repology.org/project/ncdc/versions
[4] https://tracker.debian.org/pkg/microdc2
[5] https://github.com/jnwatts/microdc2#news
[6] https://github.com/jnwatts/microdc2/commits/master
[7] https://bugs.debian.org/980954
[8] https://wiki.debian.org/Direct_Connect

Best regards,
Boris

Bug#983679: searx: Extraneous /searx/ added to URL

[Alex Dekker]

Package: searx
Version: 0.18.0+dfsg1-1
Severity: normal

Dear Maintainer,

It appears that Searx is adding an extra /searx/ to its own URLs.
My setup is:
- Apache hosting my domain example.org and proxying Searx to example.org/searx/
- uwsgi hosting Searx.

Accessing example.org/searx, I see logs of 404s in the UWSGI log file:

[pid: 1844588|app: 0|req: 59/139] ::1 () {50 vars in 1319 bytes} [Sun Feb 28 
10:45:14 2021] GET /searx/ => generated 11037 bytes in 5 msecs (HTTP/1.1 200) 3 
headers in 114 bytes (1 switches on core 0)
[pid: 1844588|app: 0|req: 60/140] ::1 () {48 vars in 1357 bytes} [Sun Feb 28 
10:45:14 2021] GET /searx/searx/static/js/jquery-1.11.1.min.js => generated 
3673 bytes in 7 msecs (HTTP/1.1 404) 3 headers in 120 bytes (1 switches on core 
0)
[pid: 1844590|app: 0|req: 23/141] ::1 () {48 vars in 1356 bytes} [Sun Feb 28 
10:45:14 2021] GET /searx/searx/static/css/leaflet.min.css => generated 3673 
bytes in 7 msecs (HTTP/1.1 404) 3 headers in 120 bytes (1 switches on core 0)
[pid: 1844589|app: 0|req: 37/142] ::1 () {48 vars in 1341 bytes} [Sun Feb 28 
10:45:14 2021] GET /searx/searx/static/js/bootstrap.min.js => generated 3673 
bytes in 4 msecs (HTTP/1.1 404) 3 headers in 120 bytes (2 switches on core 0)
[pid: 1844591|app: 0|req: 23/143] ::1 () {48 vars in 1416 bytes} [Sun Feb 28 
10:45:14 2021] GET /searx/searx/static/themes/oscar/css/logicodev.min.css => 
generated 3673 bytes in 4 msecs (HTTP/1.1 404) 3 headers in 120 bytes (2 
switches on core 0)
[pid: 1844589|app: 0|req: 38/144] ::1 () {48 vars in 1364 bytes} [Sun Feb 28 
10:45:14 2021] GET /searx/searx/static/css/bootstrap.min.css => generated 3673 
bytes in 8 msecs (HTTP/1.1 404) 3 headers in 120 bytes (1 switches on core 0)

Obviously this leads to a rather odd looking results page as all the extra 
elements cannot be loaded.
I have found a workaround: change 

base_url : "https://example.org/searx";
to
base_url : "https://example.org/";

This seems intuitively wrong to me but it works!

I think this issue began after upgrading to 0.18. I am not 100% certain here as 
I have not used Searx for a while because it has been choking on Google 
results. I try it every now and then to see if it's started working again.




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

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1), 
LANGUAGE=en_GB:en_US:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages searx depends on:
ii  python33.9.1-1
ii  python3-searx  0.18.0+dfsg1-1

searx recommends no packages.

Versions of packages searx suggests:
pn  nginx 
ii  uwsgi 2.0.19.1-6
ii  uwsgi-plugin-python3  2.0.19.1-6

-- no debconf information

Bug#983529: Backport mailman3 for buster

[Jonas Meurer]

Hello Thomas,

Am 25.02.21 um 18:57 schrieb Thomas Koch:

What do you think about providing a backport of mailman3 3.3.3-1 for Buster?

I'm about to setup mailman for a German organization that would like to have 
localized messages. But those are only available in 3.3.3.

This would of course only make sense together with backports for hyperkitty and 
posterious.


I'm not sure whether I consider the effort of updating the whole 
mailman3 stack in buster-backports worthwhile. Bullseye is around the 
cornder. Why not install a fresh bullseye box instead and setup mailman3 
there?


I didn't check yet, but from my memories we'd have to backport quite 
some dependencies as well.


Kind regards
 jonas



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983680: RM: kcm-ufw/experimental -- RoQA; dead upstream; depends on removed KDE 4 libraries

[Pino Toscano]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: sh...@sorbom.com

Hi,

please remove kcm-ufw from Debian (currently only in experimental).
The last release upstream was more than 7 years ago, and it has seen
basically no development since then. Furthermore, it was based on the
KDE libraries 4.x, which were removed from Debian, so this source
cannot be build anymore.

Thanks,
-- 
Pino

Bug#982510: libfilezilla11: libgnutls30 v3.7.0-5 breaks libfilezilla11 but downgrade to v3.6.15-4 still works

[Adrian Bunk]

Control: tags -1 -patch

On Thu, Feb 11, 2021 at 06:52:43AM +0100, Etilem wrote:
> Package: libfilezilla11
> Version: 0.26.0-1+b1
> Severity: important
> Tags: patch
> 
> Hello,
> 
> While using
> 
>   filezilla v3.52.2-3
> 
> and
> 
>   libgnutls30 v3.7.0-5
> 
> I was unable to make a PASV connection to a PureFTP server, but after
> downgrading to
> 
>   libgnutls30 v3.6.15-4
> 
> everything worked.
>...

Thanks for the report.

Does it work with libgnutls30 v3.7.0-7 ?

cu
Adrian

Bug#983681: Hyperkitty API token is not set in Hyperkitty configuration

[Thomas Koch]

Package: mailman3-web
Version: 0+20180916-8

The README.Debian.gz claims:

 * A secure API token for the Hyperkitty archiver is generated and
   set both in the Django and in the Hyperkitty configuration.

However I only see this token being set in MAILMAN_ARCHIVER_KEY in 
/etc/mailman3/mailman-web.py.
The api_key setting in section general of /etc/mailman3/mailman-hyperkitty.cfg 
is still "SecretArchiverAPIKey".

This has probably not yet been reported since the hyperkitty configuration 
still needs manual intervention anyways, e.g. enabling the archiver in 
mailman.cfg.

Bug#983682: Freeze exception for psi-plugins/1.5-2

[Boris Pek]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception
X-Debbugs-CC: tehn...@debian.org, pkg-xmpp-de...@lists.alioth.debian.org

Dear release team,

Please consider a release exception for new package psi-plugins [1].

 This package contains officially supported plugins for Psi:
 * Attention
 * Autoreply
 * Birthday Reminder
 * Chess
 * Cleaner
 * Client Switcher
 * Conference Logger
 * Content Downloader
 * Enum Messages
 * Extended Menu
 * Extended Options
 * Gomoku Game
 * History Keeper
 * Image
 * Image Preview
 * Jabber Disk
 * Juick
 * Message Filter
 * OpenPGP
 * Off-the-Record
 * PEP Change Notify
 * QIP X-Statuses
 * Screenshot
 * Stop Spam
 * Storage Notes
 * Translate
 * Video Status
 * Watcher
 .
 Psi is a cross-platform powerful XMPP client designed for experienced users.
 User interface of program is very flexible in customization. For example,
 there are "multi windows" and "all in one" modes, support of different
 iconsets and themes. Psi supports file sharing and audio/video calls. Security
 is also a major consideration, and Psi provides it for both client-to-server
 (TLS) and client-to-client (OpenPGP, OTR, OMEMO) via appropriate plugins.


While psi-plugins package is new in Debian, the project has long history [2],
these plugins are stable and well tested in other GNU/Linux distros and even
in Debian [3], upstream is active and responsive, Psi 1.x releases cycle
receives only bug fixes, backported from git master branch (where active
development of next Psi 2.0 release is done).

Yes, Psi program may still be used without these plugins, but I believe that
additional features provided by them will be highly demanded by Debian users.

[1] https://tracker.debian.org/pkg/psi-plugins
[2] https://github.com/psi-im/plugins/tags
[3] In fact psi-plus-plugins package [4] used the same code base approximately
between Psi+ 0.16.19  and 1.2.40 releases [5] (2012-2017). Just a reminder:
Psi+ is a development branch of Psi with rolling release development model.
Users who wants to receive new features and bug fixes very quickly may use
Psi+ on daily basis. Users who do not care about new trends and prefer
constancy may choose Psi as it uses classical development model and its
releases are very rare.
[4] https://packages.debian.org/sid/psi-plus-plugins
[5] https://salsa.debian.org/xmpp-team/psi-plus/-/blob/master/debian/changelog

Best regards,
Boris

Bug#841666: release-notes: recommend installing usrmerge on upgrade to stretch

[Joost van Baal-Ilić]

On Sun, Feb 28, 2021 at 01:52:11AM +, Dimitri John Ledkov wrote:
> Hi,
> 
> On Sat, 27 Feb 2021 at 22:38, Marco d'Itri  wrote:
> >
> > On Feb 27, Paul Gevers  wrote:
> >
> > > > Due to systemd changes, currently usrmerge requires a reboot to 
> > > > complete.
> > > > To lower support load on the community, as the usrmerge author I suggest
> > > > that we wait to explicitly recommend users to install it until we will
> > > > have implemented running it from the initramfs or some other workaround.
> > > > Hence, for buster +1.
> > > What's the current status on this? Should we recommend anything of this
> > > kind already in the bullseye release notes? If so, can either of you
> > > maybe propose some text?
> > Actually this is not clear: me and other people attempted some more
> > conversions and we have not been able to reproduce this anymore: the
> > conversion just works as expected with no mid-conversion reboot needed.
> > So we assumed that whatever the problem was with the systemd bind mounts
> > it was "fixed" at some point.
> >
> > Cc'ing Dimitri John who did some related work on the Ubuntu side and
> > maybe has more data.
> 
> Ubuntu has been installing systems usrmerged since Disco.
> In the upcoming hirsute release, we also installing usrmerge package
> as part of the upgrade.
> But it means that one has to install bionic then upgrade to at least
> focal, before upgrading to hirsute with this being performed.
> It also means in Ubuntu during the upgrade people are booted with
> 245.4 systemd.
> I have not managed to find any units that prevent ugprade to usrmerge so far.
> 
> Can you please advise which systemd unit options have broken the
> upgrades in the past? And are they still in place, or have evolved to
> be more specific / not problematic anymore?

FWIW: Debian Bug #978636 "move to merged-usr-only?" in Package: tech-ctte @
bugs.debian.org/978636 might have some interesting background information.

Bye,

Joost

Bug#982939: RFS: libatomprobe/0+20210207-1 [ITP] -- Development files for libatomprobe

[D Haley]

Hi,

Firstly thanks for looking at the package.

I've updated the copyright file (MIT), and fixed the swig build error.
I've checked the build under cowbuild, and it works OK now. This was a
missed build-depend as I already have swig installed.

Thanks!

On 17.02.21 10:31, Adam Borowski wrote:
> On Tue, Feb 16, 2021 at 11:06:05PM +, D Haley wrote:
>>  * Package name: libatomprobe
>>Version : 0+20210207-1
>>  * URL : http://apttools.sourceforge.io/index.html
>>   libatomprobe-dev - Development files for libatomprobe
>>   libatomprobe0 - Library for processing Atom Probe Tomography (APT) data
> Hi!
> The copyright file misses at least Expat-licensed data/naturalAbundance.xml
> (Copyright (c) 2007, 2008 Metamolecular, LLC).
>
> Building fails with:
> CMake Error at 
> /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 
> (message):
>   Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
>
> (Full log attached).
>
>
> Meow!

Bug#983684: mupdf: CVE-2021-3407

[Salvatore Bonaccorso]

Source: mupdf
Version: 1.17.0+ds1-1.2
Severity: important
Tags: security upstream
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=703366
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for mupdf.

CVE-2021-3407[0]:
| A flaw was found in mupdf 1.18.0. Double free of object during
| linearization may lead to memory corruption and other potential
| consequences.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3407
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3407
[1] https://bugs.ghostscript.com/show_bug.cgi?id=703366 
[2] 
http://git.ghostscript.com/?p=mupdf.git;h=cee7cefc610d42fd383b3c80c12cbc675443176a

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#983685: python-passlib: Homepage is 404

[Adrian Bunk]

Source: python-passlib
Version: 1.7.2-2
Severity: normal

https://bitbucket.org/ecollins/passlib/wiki/Home is 404

A replacement might be https://pypi.org/project/passlib/

Bug#983686: libcaca: CVE-2021-3410

[Salvatore Bonaccorso]

Source: libcaca
Version: 0.99.beta19-2.1
Severity: important
Tags: security upstream
Forwarded: https://github.com/cacalabs/libcaca/issues/52
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libcaca.

CVE-2021-3410[0]:
| A flaw was found in libcaca v0.99.beta19. A buffer overflow issue in
| caca_resize function in libcaca/caca/canvas.c may lead to local
| execution of arbitrary code in the user context.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3410
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3410
[1] https://github.com/cacalabs/libcaca/issues/52

Regards,
Salvatore

Bug#983684: mupdf: diff for NMU version 1.17.0+ds1-1.3

[Salvatore Bonaccorso]

Control: tags 983684 + patch
Control: tags 983684 + pending
Control: severity 983684 serious

(make RC as this should go into bullseye).

Dear maintainer,

I've prepared an NMU for mupdf (versioned as 1.17.0+ds1-1.3) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru mupdf-1.17.0+ds1/debian/changelog mupdf-1.17.0+ds1/debian/changelog
--- mupdf-1.17.0+ds1/debian/changelog	2020-11-28 14:59:08.0 +0100
+++ mupdf-1.17.0+ds1/debian/changelog	2021-02-28 13:40:40.0 +0100
@@ -1,3 +1,11 @@
+mupdf (1.17.0+ds1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix double free of object during linearization (CVE-2021-3407)
+(Closes: #983684)
+
+ -- Salvatore Bonaccorso   Sun, 28 Feb 2021 13:40:40 +0100
+
 mupdf (1.17.0+ds1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mupdf-1.17.0+ds1/debian/patches/0012-Bug-703366-Fix-double-free-of-object-during-lineariz.patch mupdf-1.17.0+ds1/debian/patches/0012-Bug-703366-Fix-double-free-of-object-during-lineariz.patch
--- mupdf-1.17.0+ds1/debian/patches/0012-Bug-703366-Fix-double-free-of-object-during-lineariz.patch	1970-01-01 01:00:00.0 +0100
+++ mupdf-1.17.0+ds1/debian/patches/0012-Bug-703366-Fix-double-free-of-object-during-lineariz.patch	2021-02-28 13:40:40.0 +0100
@@ -0,0 +1,51 @@
+From: Robin Watts 
+Date: Fri, 22 Jan 2021 17:05:15 +
+Subject: Bug 703366: Fix double free of object during linearization.
+origin: http://git.ghostscript.com/?p=mupdf.git;h=cee7cefc610d42fd383b3c80c12cbc675443176a
+Bug: https://bugs.ghostscript.com/show_bug.cgi?id=703366
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-3407
+Bug-Debian: https://bugs.debian.org/983684
+
+This appears to happen because we parse an illegal object from
+a broken file and assign it to object 0, which is defined to
+be free.
+
+Here, we fix the parsing code so this can't happen.
+---
+ source/pdf/pdf-parse.c | 6 ++
+ source/pdf/pdf-xref.c  | 2 ++
+ 2 files changed, 8 insertions(+)
+
+diff --git a/source/pdf/pdf-parse.c b/source/pdf/pdf-parse.c
+index 7abc8c3d41aa..5761c3351773 100644
+--- a/source/pdf/pdf-parse.c
 b/source/pdf/pdf-parse.c
+@@ -749,6 +749,12 @@ pdf_parse_ind_obj(fz_context *ctx, pdf_document *doc,
+ 		fz_throw(ctx, FZ_ERROR_SYNTAX, "expected generation number (%d ? obj)", num);
+ 	}
+ 	gen = buf->i;
++	if (gen < 0 || gen >= 65536)
++	{
++		if (try_repair)
++			*try_repair = 1;
++		fz_throw(ctx, FZ_ERROR_SYNTAX, "invalid generation number (%d)", gen);
++	}
+ 
+ 	tok = pdf_lex(ctx, file, buf);
+ 	if (tok != PDF_TOK_OBJ)
+diff --git a/source/pdf/pdf-xref.c b/source/pdf/pdf-xref.c
+index 1b2bdcd59d70..30197b4b8577 100644
+--- a/source/pdf/pdf-xref.c
 b/source/pdf/pdf-xref.c
+@@ -1190,6 +1190,8 @@ pdf_read_new_xref(fz_context *ctx, pdf_document *doc, pdf_lexbuf *buf)
+ 	{
+ 		ofs = fz_tell(ctx, doc->file);
+ 		trailer = pdf_parse_ind_obj(ctx, doc, doc->file, buf, &num, &gen, &stm_ofs, NULL);
++		if (num == 0)
++			fz_throw(ctx, FZ_ERROR_GENERIC, "Trailer object number cannot be 0\n");
+ 	}
+ 	fz_catch(ctx)
+ 	{
+-- 
+2.30.0
+
diff -Nru mupdf-1.17.0+ds1/debian/patches/series mupdf-1.17.0+ds1/debian/patches/series
--- mupdf-1.17.0+ds1/debian/patches/series	2020-11-28 14:59:08.0 +0100
+++ mupdf-1.17.0+ds1/debian/patches/series	2021-02-28 13:40:40.0 +0100
@@ -8,3 +8,4 @@
 0008-Build-mupdf-without-executable-stack.patch
 0010-Prevent-thirdparty-archive-build.patch
 0011-Bug-702857-Detect-avoid-overflow-when-calculating-si.patch
+0012-Bug-703366-Fix-double-free-of-object-during-lineariz.patch

Bug#983687: RFS: bambootracker/0.4.6-1 [RC] -- YM2608 (OPNA, sound chip of Yamaha) music tracker

[Gürkan Myczko]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: bambootracker
   Version : 0.4.6-1
   Upstream Author : Rerrah
 * URL : https://github.com/rerrahkr/BambooTracker
 * License : GPL-2+, BSD-3-clause, CC-BY-SA-3.0
 * Vcs : 
https://salsa.debian.org/multimedia-team/bambootracker

   Section : sound

It builds those binary packages:

  bambootracker - YM2608 (OPNA, sound chip of Yamaha) music tracker

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/b/bambootracker/bambootracker_0.4.6-1.dsc


Changes since the last upload:

 bambootracker (0.4.6-1) unstable; urgency=medium
 .
   * New upstream release.
   * Thanks Adrian Bunk for the hint to fix FTBFS on 32bit.
 (Closes: #974580).
   * Bump standards version to 4.5.1.
   * d/manpages: added.
   * d/copyright: update paragraph paths.

Regards,
--
  Gürkan Myczko

Bug#964477: Upgrade from Buster to testing/Bullseye works now

[Axel Rohde]

Dear maintainers,

with the removal of gcc-8 the upgrade from
Buster to testing/Bullseye works now flawlessly.
Thank you very much!

Bug#981243: libboost-log1.74.0 prevents debootsrap to finish correctly

[Adrian Bunk]

Control: reassign -1 deboostrap
Control: retitle -1 debootstrap: No dependency resolution of Provides

On Thu, Jan 28, 2021 at 10:30:18AM +0100, Radoslav Bodó wrote:
> Package: libboost-log1.74.0
> Version: 1.74.0-8
> Severity: important
> 
> Hello,
> 
> as we are preparing ourselves for the new release, we've found that
> debootstrap installation process gets interrupted possibly by libboost
> (coming along with puppet/facter).
> 
> The process does not finish correctly and leaves generated template in
> an unusable state which must be manually fixed on several places (apt
> --fix-missing, cleanup policy.d)
> 
> Here comes our build command and produced failures:
> 
> ```
> debootstrap
> --include=less,vim,ca-certificates,xfsprogs,git,puppet,lsb-release,openssh-server,krb5-user,python3,man-db,curl,linux-image-amd64
> bullseye target_template http://ftp.cz.debian.org/debian
>...
> dpkg: dependency problems prevent configuration of libboost-log1.74.0:
>  libboost-log1.74.0 depends on libboost-regex1.74.0-icu67; however:
>   Package libboost-regex1.74.0-icu67 is not installed.
>...
> Any help in this regard would be appreciated.

>From the manpage of deboostrap:

   --no-resolve-deps
  By default, debootstrap will attempt  to  automatically  resolve
  any  missing  dependencies, warning if any are found.  Note that
  this is not a complete dependency resolve in the sense  of  dpkg
  or  apt,  and  that  it is far better to specify the entire base
  system than rely on this option.  With this option set, this be‐
  haviour is disabled.


This is a bug in debootstrap which should really use a dependency solver 
like apt, but AFAIK noone is working on this.

As workaround, adding libboost-regex1.74.0 to the --include list might 
solve the problem.


> Best regards
> bodik

cu
Adrian

Bug#981422: xdg-utils: autopkgtest failure: make: dh: No such file or directory

[Antonio Terceiro]

On Sun, 31 Jan 2021 00:22:25 +0300 Nicholas Guriev  wrote:
> Hello!
> 
> On Sat, 2021-01-30 at 21:54 +0100, Paul Gevers wrote:
> > You recently added an autopkgtest to your package xdg-utils, great.
> > However, it fails. Currently this failure is blocking the migration to
> > testing [1]. Can you please investigate the situation and fix it?
> 
> There are several ways to fix the failure.
> 
> 1. Replace `debian/rules patch` line in a test script with `chmod +x
> autotests/tty{on,off}`.
> 
> --- a/debian/tests/entry
> +++ b/debian/tests/entry
> @@ -13,6 +13,6 @@ fi
>  BASH_XTRACEFD=1
>  set -x
> ·
> -debian/rules patch
>  ./configure
> +chmod +x autotests/tty{on,off}
>  make autotest SHELL="${1:-/bin/sh}"
> 
> https://salsa.debian.org/freedesktop-team/xdg-utils/-/commit/9928933504932f19fb39a0f671cdc7be78aada29
> 
> 2. Put the "patch" target back as it was in -3 revision, and fix arch-
> independent build.
> 
> https://salsa.debian.org/freedesktop-team/xdg-utils/-/merge_requests/4/diffs?commit_id=0617f9284ae4d79b51c4ad4bc7d781e93561cb23
> 
> I still prefer the later option with the "patch" target. Because that
> chmod fixes flaws of quilt and dpkg and this solutions is more
> universal. I hope someone will choose to upload another one-liner fix.

Please drop patching from the test entirely. autopkgtests are supposed
to _start_ running against a fully patched source tree. autopkgtest(1)
does this automatically.

I understand that this might be convenient when working on the package,
but please automate it in a way that it's not also done when running the
autopkgtest "for real".


signature.asc
Description: PGP signature

Bug#983688: tasksel-data: gnome-flashback-desktop task in Japanese environment should pull task-japanese-gnome-desktop

[YOSHINO Yoshihito]

Package: tasksel-data
Version: 3.64
Severity: important
Tags: bullseye l10n patch

Dear Maintainer,

The GNOME Flashback desktop is similar to the original GNOME desktop.

For Japanese users, when the GNOME Flashback desktop is installed,
it is expected to also install the task-japanese-gnome-desktop package.

The attached patch adds "japanese-gnome-flashback-desktop" Task
which behaves just like "japanese-gnome-desktop" Task for
"gnome-flashback-desktop" Task,
which installs the task-japanese-gnome-desktop package.
Note that this patch does NOT add a new binary package, but just adds
a new Task.

Thanks in advance,
-- 
YOSHINO Yoshihito 

-- 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/1 CPU thread)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 tasksel-data depends on:
ii  tasksel  3.64

Versions of packages tasksel-data recommends:
ii  laptop-detect  0.16

tasksel-data suggests no packages.

-- no debconf information
--- tasksel-3.64/tasks/japanese-gnome-flashback-desktop	1970-01-01 09:00:00.0 +0900
+++ tasksel-3.64/tasks/japanese-gnome-flashback-desktop	2021-02-28 17:37:14.982899811 +0900
@@ -0,0 +1,5 @@
+Task: japanese-gnome-flashback-desktop
+Enhances: gnome-flashback-desktop, japanese-desktop
+Section: l10n
+Key:
+  task-japanese-gnome-desktop

Bug#983346: Update gitlab to 13.7.7 (installation fails - need help)

[Pirate Praveen]

On Sat, 27 Feb 2021 17:33:40 +0530 Pirate Praveen 
 wrote:

> This commit makes the upgrade work.
>
> 
https://salsa.debian.org/ruby-team/gitlab/-/commit/98741d55b7ed4b5eb1985981ab82e171c7d0e0c9


Looks like this did not really fix the issue when I tried it again on 
another machine :(

Bug#981243: libboost-log1.74.0 prevents debootsrap to finish correctly

[Cyril Brulebois]

Adrian Bunk  (2021-02-28):
> This is a bug in debootstrap which should really use a dependency
> solver like apt, but AFAIK noone is working on this.

Well debootstrap's goal is what it says in the name, which is
bootstrapping. Just install a base system first and install whatever
packages you need using apt afterwards, and voilà.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#983346: Update gitlab to 13.7.7 (installation fails - need help)

[Pirate Praveen]

Control: forwarded -1 
https://gitlab.com/gitlab-org/gitlab/-/issues/323024


On Sun, Feb 28, 2021 at 6:56 pm, Pirate Praveen 
 wrote:
On Sat, 27 Feb 2021 17:33:40 +0530 Pirate Praveen 
 wrote:

> This commit makes the upgrade work.
>
> 
https://salsa.debian.org/ruby-team/gitlab/-/commit/98741d55b7ed4b5eb1985981ab82e171c7d0e0c9


Looks like this did not really fix the issue when I tried it again on 
another machine :(


Asking upstream for help 
https://gitlab.com/gitlab-org/gitlab/-/issues/323024

Bug#983689: RFS: shotcut/21.02.27+ds-1 -- video editor

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: shotcut
   Version : 21.02.27+ds-1
   Upstream Author : Dan Dennedy  and Brian Matherly 


 * URL : https://www.shotcut.org/
 * License : GPL-3+, LGPL-2.1+
 * Vcs : https://salsa.debian.org/multimedia-team/shotcut
   Section : video

It builds those binary packages:

  shotcut-data - video editor data
  shotcut - video editor

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/s/shotcut/shotcut_21.02.27+ds-1.dsc


Changes since the last upload:

 shotcut (21.02.27+ds-1) experimental; urgency=medium
 .
   * New upstream version.

Regards,
--
  Gürkan Myczko

Bug#983690: Care for FAQ

[Geert Stappers]

Package: java-common
Severity: wish


Hi,

Debian java FAQ has currently no information on setting JAVA_HOME

https://www.debian.org/doc/manuals/debian-java-faq/index.en.html
is from 2014


Please give the Debian Java FAQ  some tender, love and care.


 
Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#983692: cloud.debian.org: set up APT pinning for unstable in the 'testing' image?

[Lucas Nussbaum]

Package: cloud.debian.org
Severity: wishlist
User: cloud.debian@packages.debian.org
Usertags: vagrant image

Hi,

Should we set up APT pinning in the 'testing' image, to make it easy to
install some packages from unstable? This used to be done with the
former build process, if I remember correctly.

Lucas

Bug#983691: cloud.debian.org: provide images for vagrant-lxc/vagrant-lxd?

[Lucas Nussbaum]

Package: cloud.debian.org
Severity: wishlist
User: cloud.debian@packages.debian.org
Usertags: vagrant image

Hi,

Should we provide images for the vagrant lxc or lxd plugin?
The lxc plugin is dead upstream, but the lxd one seems actively
maintained: https://gitlab.com/catalyst-it/devtools/vagrant-lxd
(images for both plugins use the same format).

Lucas

Bug#982510: libfilezilla11: libgnutls30 v3.7.0-5 breaks libfilezilla11 but downgrade to v3.6.15-4 still works

[Philip Wyett]

On Sun, 2021-02-28 at 14:09 +0200, Adrian Bunk wrote:
> Control: tags -1 -patch
> 
> On Thu, Feb 11, 2021 at 06:52:43AM +0100, Etilem wrote:
> > Package: libfilezilla11
> > Version: 0.26.0-1+b1
> > Severity: important
> > Tags: patch
> > 
> > Hello,
> > 
> > While using
> > 
> >   filezilla v3.52.2-3
> > 
> > and
> > 
> >   libgnutls30 v3.7.0-5
> > 
> > I was unable to make a PASV connection to a PureFTP server, but
> > after
> > downgrading to
> > 
> >   libgnutls30 v3.6.15-4
> > 
> > everything worked.
> > ...
> 
> Thanks for the report.
> 
> Does it work with libgnutls30 v3.7.0-7 ?
> 
> cu
> Adrian
> 

Hi Adrian,

Yes it does work with v3.7.0-7.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#982578: stunnel4: CVE-2021-20230: client certificate not correctly verified when redirect and verifyChain options are used

[Salvatore Bonaccorso]

Hi Peter,

As the bullseye realease (respetively the hard freeze is approaching),
can you please have a look so that the fix is included in bullseye?

Regards,
Salvatore

Bug#983690: Fwd: Setting JAVA_HOME

[Geert Stappers]

Information about   JAVA_HOME

- Forwarded message from Thorsten Glaser -

Date: Sun, 28 Feb 2021 14:43:34 +0100 (CET)
From: Thorsten Glaser
To: Geert Stappers
cc: debian-j...@lists.debian.org
Subject: Re: Setting  JAVA_HOME

On Sun, 28 Feb 2021, Geert Stappers wrote:

> To what should JAVA_HOME be set?

It should be unset. Also ideally, you have only ever one JRE installed.

Everything else is a nightmare.

To make this work with Java >8 and Maven, you’ll need¹…


jre-not-below-jdk


${java.home}/bin/javadoc






org.apache.maven.plugins

maven-javadoc-plugin


${java.home}/bin/javadoc






… or the Debian-patched version of the maven-javadoc-plugin.

bye,
//mirabilos
① see 
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tartools/mvnparent.git
  or use…

org.evolvis.tartools
maven-parent
2.1

-- 
Infrastrukturexperte • tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*

- End forwarded message -

Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#841666: release-notes: recommend installing usrmerge on upgrade to stretch

[Marco d'Itri]

On Feb 28, Dimitri John Ledkov  wrote:

> Can you please advise which systemd unit options have broken the
> upgrades in the past? And are they still in place, or have evolved to
> be more specific / not problematic anymore?
Accordingly to the error message (which I wrote in 2015) this was about 
ProtectSystem, which was new at the time and started being used by some 
of the systemd daemons.
Since it is widely used nowadays then it looks like that whatever forced 
the conversion to stop has been changed.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#982892: ITP: binutils-or1k-elf -- GNU binary utilities for the Open RISC 1000 processors

[Nicolas Boulenguez]

Adding Matthias Klose, maintainer of 'binutils', to CCs.
Log at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982892.

This discussion has nothing specific to or1k.  I suggest to move to
https://wiki.debian.org/PackagingLessCommonBinutilsTargets.

Can you describe the scenarios you want to avoid?  The binutils-* are
quite different from each other.

Small wrappers like binutils-{bpf,or1k-elf,...} are Built-Using:
binutils-source.  As long as they build against latest binutils, there
is no difference with building them from binutils.dsc.  But if/when
they FTBFS, the failure does not involve unrelated maintainers.

On the other hand, some binutils-* packages keep an old copy the
binutils source tarball, for example because the patches from the
hardware vendor have not been rebased yet.  The Debian maintainers
know very well that this is not ideal, but in this case sharing the
source package is simply not an option.

[binutils.dsc]
> even includes alpha, m68k riscv64 and sh4. I'd say that or1k is not
> a stranger among these.

As far as I understand, 'binutils' now only intends to support
released Debian architectures, and these are historical exceptions.

> binutils-ports (or similar)

This would be 'or similar', as 'port' in Debian suggests 'hopefully
soon a released architecture'.

Bug#983693: hoel: package descriptions wrongly say PostgreSQL is barely supported

[Daniele Forsi]

Source: hoel
Severity: minor

Dear Maintainer,

please consider updating package descriptions removing the word "barely" since 
support for
PostgreSQL seems to be fully functional since this commit
https://github.com/babelouest/hoel/commit/88d3b66a3f7c793dd6c62af925b30b94ab248073#diff-b335630551682c19a781af

thanks,
Daniele

Bug#983694: dpkg: Add "write-once" flag to conffiles that can then be created via the fsys-tarfile.

[Tim Woodall]

Package: dpkg
Version: 1.20.7.1
Severity: wishlist

Dear Maintainer,

This is a wishlist item relate to:
Re: Bug#924401: #924401 base-files fails postinst when base-passwd is unpacked

With the patch included below the problem packages, Provides: awk and
base-passwd can be trivially modified so that they provide their
essential functionality via the fsys-tarfile only and do not need to
rely on the configure scripts to work before ever being configured.

This means that you need nothing more than apt to bootstrap a release as
apt can correctly work out the right order to configure the packages.

I also include example patches to base-passwd and mawk (gawk and
original-awk need almost identical changes to mawk)


The core feature is to add support for a flag "write-once" for
conffiles. In most circumstances this operates identical to a regular
conffile, however, it disables all questions about future changes and
always leaves the installed version untouched (except on purge).

The two base-passwd files are tagged like this and no longer need to be
created in the maintainer scripts for base-passwd essential
functionality to be avilable.

gawk/mawk/original-awk ship with a symlink
/usr/bin/awk -> /usr/bin/{g,m,original-}awk that is tagged similarly.
This does, currently cause a warning from dpkg-deb as the package is
built.

Under normal use cases /usr/bin/awk will exist and be maintained via the
alternatives mechanism, so dpkg will not use this packaged symlink as it
will see an existing file and "keep" it. But during bootstrapping when
the deb is initially unpacked using tar the symlink will be created and
so the awk functionality will be available before the correct symlink is
created via the maintainter scripts.

N.B. I think that it is probably necessary that gawk, mawk and
essential-awk are patched at the same time after this dpkg feature is
added. Otherwise I think that installing a package that doesn't use this
feature for the /usr/bin/awk symlink and then purging one that does will
result in the symlink being removed! There may will be other corner
cases like this that I'm unaware of.



= dpkg patch

diff -urN dpkg-1.20.7.1.orig/dpkg-deb/build.c dpkg-1.20.7.1/dpkg-deb/build.c
--- dpkg-1.20.7.1.orig/dpkg-deb/build.c 2021-01-09 06:04:59.0 +
+++ dpkg-1.20.7.1/dpkg-deb/build.c  2021-02-25 16:44:23.661053441 +
@@ -316,6 +316,9 @@
 
   if (strcmp(flag, "remove-on-upgrade") == 0)
 remove_on_upgrade = true;
+  else if (strcmp(flag, "write-once") == 0) {
+/* do nothing */
+  }
   else
 ohshit(_("unknown flag '%s' for conffile '%s'"), flag, conffilename);
 }
diff -urN dpkg-1.20.7.1.orig/lib/dpkg/dpkg-db.h dpkg-1.20.7.1/lib/dpkg/dpkg-db.h
--- dpkg-1.20.7.1.orig/lib/dpkg/dpkg-db.h   2021-01-09 06:04:59.0 
+
+++ dpkg-1.20.7.1/lib/dpkg/dpkg-db.h2021-02-25 16:42:48.269440879 +
@@ -83,6 +83,7 @@
   const char *hash;
   bool obsolete;
   bool remove_on_upgrade;
+  bool write_once;
 };
 
 struct archivedetails {
diff -urN dpkg-1.20.7.1.orig/lib/dpkg/dump.c dpkg-1.20.7.1/lib/dpkg/dump.c
--- dpkg-1.20.7.1.orig/lib/dpkg/dump.c  2021-01-09 06:04:59.0 +
+++ dpkg-1.20.7.1/lib/dpkg/dump.c   2021-02-25 16:39:12.917286986 +
@@ -396,6 +396,8 @@
   varbuf_add_str(vb, " obsolete");
 if (i->remove_on_upgrade)
   varbuf_add_str(vb, " remove-on-upgrade");
+if (i->write_once)
+  varbuf_add_str(vb, " write-once");
   }
   if (flags&fw_printheader)
 varbuf_add_char(vb, '\n');
diff -urN dpkg-1.20.7.1.orig/lib/dpkg/fields.c dpkg-1.20.7.1/lib/dpkg/fields.c
--- dpkg-1.20.7.1.orig/lib/dpkg/fields.c2021-01-09 06:04:59.0 
+
+++ dpkg-1.20.7.1/lib/dpkg/fields.c 2021-02-25 16:42:39.697116256 +
@@ -347,10 +347,11 @@
 {
   static const char obsolete_str[]= "obsolete";
   static const char remove_on_upgrade_str[] = "remove-on-upgrade";
+  static const char write_once_str[] = "write-once";
   struct conffile **lastp, *newlink;
   const char *endent, *endfn, *hashstart;
   int c, namelen, hashlen;
-  bool obsolete, remove_on_upgrade;
+  bool obsolete, remove_on_upgrade, write_once;
   char *newptr;
 
   lastp = &pkgbin->conffiles;
@@ -371,6 +372,12 @@
   conffvalue_lastword(value, endfn, endent, &hashstart, &hashlen, &endfn,
   ps);
 
+write_once = (hashlen == sizeof(write_once_str) - 1 &&
+ memcmp(hashstart, write_once_str, hashlen) == 0);
+if (write_once)
+  conffvalue_lastword(value, endfn, endent, &hashstart, &hashlen, &endfn,
+  ps);
+
 obsolete= (hashlen == sizeof(obsolete_str)-1 &&
memcmp(hashstart, obsolete_str, hashlen) == 0);
 if (obsolete)
@@ -395,6 +402,7 @@
 newlink->hash= newptr;
 newlink->obsolete= obsolete;
 newlink->remove_on_upgrade = remove_on_upgrade;
+newlink->write_once = write_once;
 newlink->next =NULL;
 *lastp= newlink;
 lastp=

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

[YOSHINO Yoshihito]

Package: ibus-anthy
Version: 1.5.11-2
Severity: important
Tags: patch

Dear Maintainer,

On the GNOME desktop, manual set-up in GNOME Settings is required
in order to make ibus-anthy to work.

I have prepared an XDG Autostart .desktop file which should be installed to
/etc/xdg/autostart/ibus-anthy-gnome-initial-setup.desktop
and its corresponding script to be installed to
/usr/share/ibus-anthy/ibus-anthy-gnome-initial-setup.sh
to automatically set-up ibus-anthy immediately after each user's next login.

Sorry for the tight schedule, but hopefully this should be included in
the bullseye release
(See also Bug#983653.)

Thanks in advance,
-- 
YOSHINO Yoshihito 

-- 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/1 CPU thread)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 ibus-anthy depends on:
ii  anthy1:0.4-2
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  ibus 1.5.23-2
ii  libanthy11:0.4-2
ii  libc62.31-9
ii  libglib2.0-0 2.66.7-1
ii  python3  3.9.1-1

ibus-anthy recommends no packages.

ibus-anthy suggests no packages.

-- no debconf information


ibus-anthy-gnome-initial-setup.desktop
Description: Binary data


ibus-anthy-gnome-initial-setup.sh
Description: Bourne shell script

Bug#983696: python-igraph: Missing build dependency on cmake

[Adrian Bunk]

Source: python-igraph
Version: 0.9.0-1
Severity: serious
Tags: ftbfs

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

...
We are going to build the C core of igraph.
  Source folder: vendor/source/igraph
  Build folder: vendor/build/igraph
  Install folder: vendor/install/igraph

igraph uses CMake as the build system. You need to install CMake before 
compiling igraph.
error: [Errno 2] No such file or directory: 
'/<>/vendor/install/igraph/build.cfg'
E: pybuild pybuild:353: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py build 
dh_auto_build: error: pybuild --build -i python{version} -p 3.9 returned exit 
code 13
make: *** [debian/rules:15: binary-arch] Error 25

Bug#983677: gscan2pdf: Cannot change paper format anymore

[Rainer Dorsch]

Package: gscan2pdf
Version: 2.11.0-1
Severity: important

Dear Maintainer,

I added a paper format "A5" sometime back to gscan2pdf, which worked
as expected. Recently, I scanned A5 documents again. Now I wanted to
switch back to A4, but this did not work:

When I try to change the format to A4, it toggles a few (2?) times
fast between A5 and A4 and settles at A5 again. I.e. I cannot modify
the setting anymore.

I rate the severity as important, because it is a sever reduction of
functionality for a user of gscan2pdf if the user hits this issue.

I send a log with a separate email.

Thanks
Rainer


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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.11.60+dfsg-1
ii  imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1.1
ii  libfilesys-df-perl 0.92-6+b6
ii  libgoocanvas2-perl 0.06-2
ii  libgtk3-imageview-perl 6-1
ii  libgtk3-perl   0.038-1
ii  libgtk3-simplelist-perl0.21-1
ii  libhtml-parser-perl3.75-1+b1
ii  libimage-magick-perl   8:6.9.11.60+dfsg-1
ii  libimage-sane-perl 5-1+b1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-codes-perl   3.66-1
ii  liblocale-gettext-perl 1.07-4+b1
ii  liblog-log4perl-perl   1.54-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b9
ii  libpdf-builder-perl3.021-1
ii  libproc-processtable-perl  0.59-2+b1
ii  libreadonly-perl   2.050-3
ii  librsvg2-common2.50.3+dfsg-1
ii  libset-intspan-perl1.19-1.1
ii  libtiff-tools  4.2.0-1
ii  libtry-tiny-perl   0.30-1
ii  sane-utils 1.0.31-4

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin   3.5.28-1
ii  pdftk   2.02-5+b1
ii  pdftk-java [pdftk]  3.2.2-1
ii  tesseract-ocr   4.1.1-2.1
ii  unpaper 6.1-2+b2
ii  xdg-utils   1.1.3-4

gscan2pdf suggests no packages.

-- no debconf information

Bug#983697: FTBFS: Failing tests

[Hans Joachim Desserud]

Source: trapperkeeper-webserver-jetty9-clojure
Version: 4.1.0-2
Severity: serious
Justification: FTBFS in unstable
Tags: ftbfs

Dear Maintainer,

The latest version of trapperkeeper-webserver-jetty9-clojure currently
fails to build due to failing tests:
...
Ran 86 tests containing 588 assertions.
10 failures, 0 errors.
Tests failed.
make[1]: *** [debian/rules:25: override_dh_auto_test] Error 1
make[1]: Leaving directory 
'/build/1st/trapperkeeper-webserver-jetty9-clojure-4.1.0'

make: *** [debian/rules:11: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


See also
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/trapperkeeper-webserver-jetty9-clojure.html
for more information

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/3 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#983698: spice: CVE-2021-20201: Client initiated renegotiation denial of service

[Salvatore Bonaccorso]

Source: spice
Version: 0.14.3-2
Severity: important
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/spice/spice/-/issues/49
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.14.0-1.3+deb10u1
Control: found -1 0.14.0-1.3

Hi,

The following vulnerability was published for spice.

CVE-2021-20201[0]:
| Client initiated renegotiation denial of service

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-20201
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20201
[1] https://gitlab.freedesktop.org/spice/spice/-/issues/49

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#932456: Possible Patch

[Reto Buerki]

On 2/27/21 5:55 PM, Fabian Zaremba wrote:
> If I can help test this by providing source / binary packages or a
> Docker build environment please let me know.

Could you provide a binary package for Buster containing this patch? I
would like to test this.

Cheers

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

[YOSHINO Yoshihito]

Package: ibus-anthy
Followup-For: Bug #983695

Dear Maintainer,

I have created a merge request on salsa at
https://salsa.debian.org/input-method-team/ibus-anthy/-/merge_requests/2

Thanks in advance,
-- 
YOSHINO Yoshihito 

Bug#983699: ITP: python-commoncode -- set of common functions and utilities for handling various things like paths, dates, files and hashes

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: python-commoncode
  Version : 21.1.21
  Upstream Author : Philippe Ombredanne
* URL : https://github.com/nexB/commoncode
* License : Apache-2.0
  Programming Lang: Python
  Description : set of common  functions and utilities for handling various 
things like paths, dates, files and hashes

Commoncode provides a set of common functions and utilities for handling 
various things like paths, dates, files and hashes. It started as library in 
scancode-toolkit. Visit https://aboutcode.org and https://github.com/nexB/ for 
support and download.

It is a dependency for scancode-toolkit

Bug#983408: How to build the packages from sources

[Benoît Sibaud]

Hi,

well that may not be the right/proper way to produce the packages, but in the 
mean time, some instructions if you ever want to produce your own packages 
https://linuxfr.org/users/oumph/journaux/compilation-de-0-a-d-alpha-24-pour-debian-buster
 (in French).

Main changes I've noted:
- libmozjs78 instead of libmozjs38 (part of the 0.A.D. release notes)
- require nvtt >= 2.1.0 (only in Debian experimental for now), so I fallback to 
the non-system version (so extra libs to deploy, and maybe extra packages 
needed to build)

Regards,

-- 
Benoît Sibaud

Bug#983698: spice: diff for NMU version 0.14.3-2.1

[Salvatore Bonaccorso]

Control: tags 983698 + patch
Control: tags 983698 + pending

Dear maintainer,

I've prepared an NMU for spice (versioned as 0.14.3-2.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Related merge request is
https://salsa.debian.org/qemu-team/spice/-/merge_requests/3 and the
sole reason I did is tho have more such issues fixed in bullseye if
possible. On the other side the issue would otherwise not be urgent
and is defintively more on the no-dsa range for a stable release.

Furthermore used both commits from upstream although only one would be
relevant.

Let me know if I should cancel it as well if you would not like to see
this change in this way as proposed.

Regards,
Salvatore
diff -Nru spice-0.14.3/debian/changelog spice-0.14.3/debian/changelog
--- spice-0.14.3/debian/changelog	2020-10-29 08:57:02.0 +0100
+++ spice-0.14.3/debian/changelog	2021-02-28 16:29:54.0 +0100
@@ -1,3 +1,13 @@
+spice (0.14.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Client initiated renegotiation denial of service (CVE-2021-20201)
+(Closes: #983698)
+- With OpenSSL 1.1: Disable client-initiated renegotiation
+- With OpenSSL 1.0.2 and earlier: disable client-side renegotiation
+
+ -- Salvatore Bonaccorso   Sun, 28 Feb 2021 16:29:54 +0100
+
 spice (0.14.3-2) unstable; urgency=medium
 
   [ Christian Ehrhardt ]
diff -Nru spice-0.14.3/debian/patches/With-OpenSSL-1.0.2-and-earlier-disable-client-side-r.patch spice-0.14.3/debian/patches/With-OpenSSL-1.0.2-and-earlier-disable-client-side-r.patch
--- spice-0.14.3/debian/patches/With-OpenSSL-1.0.2-and-earlier-disable-client-side-r.patch	1970-01-01 01:00:00.0 +0100
+++ spice-0.14.3/debian/patches/With-OpenSSL-1.0.2-and-earlier-disable-client-side-r.patch	2021-02-28 16:29:54.0 +0100
@@ -0,0 +1,37 @@
+From: =?UTF-8?q?Julien=20Rop=C3=A9?= 
+Date: Thu, 3 Dec 2020 09:33:48 +0100
+Subject: [2/2] With OpenSSL 1.0.2 and earlier: disable client-side
+ renegotiation.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+Origin: https://gitlab.freedesktop.org/spice/spice/-/commit/95a0cfac8a1c8eff50f05e65df945da3bb501fc9
+Bug: https://gitlab.freedesktop.org/spice/spice/-/issues/49
+Bug-Debian: https://bugs.debian.org/983698
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-20201
+
+Fixed issue #49
+Fixes BZ#1904459
+
+Signed-off-by: Julien Rop?? 
+Reported-by: BlackKD
+Acked-by: Frediano Ziglio 
+[Salvatore Bonaccorso: Backport to 0.14.3: Filename change]
+---
+ server/red-stream.cpp | 5 +
+ 1 file changed, 5 insertions(+)
+
+--- a/server/red-stream.c
 b/server/red-stream.c
+@@ -523,6 +523,11 @@ RedStreamSslStatus red_stream_ssl_accept
+ return RED_STREAM_SSL_STATUS_OK;
+ }
+ 
++#ifndef SSL_OP_NO_RENEGOTIATION
++// With OpenSSL 1.0.2 and earlier: disable client-side renogotiation
++stream->priv->ssl->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;
++#endif
++
+ ssl_error = SSL_get_error(stream->priv->ssl, return_code);
+ if (return_code == -1 && (ssl_error == SSL_ERROR_WANT_READ ||
+   ssl_error == SSL_ERROR_WANT_WRITE)) {
diff -Nru spice-0.14.3/debian/patches/With-OpenSSL-1.1-Disable-client-initiated-renegotiat.patch spice-0.14.3/debian/patches/With-OpenSSL-1.1-Disable-client-initiated-renegotiat.patch
--- spice-0.14.3/debian/patches/With-OpenSSL-1.1-Disable-client-initiated-renegotiat.patch	1970-01-01 01:00:00.0 +0100
+++ spice-0.14.3/debian/patches/With-OpenSSL-1.1-Disable-client-initiated-renegotiat.patch	2021-02-28 16:29:54.0 +0100
@@ -0,0 +1,35 @@
+From: =?UTF-8?q?Julien=20Rop=C3=A9?= 
+Date: Wed, 2 Dec 2020 13:39:27 +0100
+Subject: [1/2] With OpenSSL 1.1: Disable client-initiated renegotiation.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+Origin: https://gitlab.freedesktop.org/spice/spice/-/commit/ca5bbc5692e052159bce1a75f55dc60b36078749
+Bug: https://gitlab.freedesktop.org/spice/spice/-/issues/49
+Bug-Debian: https://bugs.debian.org/983698
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-20201
+
+Fixes issue #49
+Fixes BZ#1904459
+
+Signed-off-by: Julien Rop?? 
+Reported-by: BlackKD
+Acked-by: Frediano Ziglio 
+[Salvatore Bonaccorso: Backport to 0.14.3: Filename change]
+---
+ server/reds.cpp | 4 
+ 1 file changed, 4 insertions(+)
+
+--- a/server/reds.c
 b/server/reds.c
+@@ -2862,6 +2862,10 @@ static int reds_init_ssl(RedsState *reds
+  * When some other SSL/TLS version becomes obsolete, add it to this
+  * variable. */
+ long ssl_options = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION | SSL_OP_NO_TLSv1;
++#ifdef SSL_OP_NO_RENEGOTIATION
++// With OpenSSL 1.1: Disable all renegotiation in TLSv1.2 and earlier
++ssl_options |= SSL_OP_NO_RENEGOTIATION;
++#endif
+ 
+ /* Global system initialization*/
+ openssl_global_init();
dif

Bug#983685: python-passlib: Homepage is 404

[Andrey Rahmatullin]

On Sun, Feb 28, 2021 at 02:49:00PM +0200, Adrian Bunk wrote:
> Source: python-passlib
> Version: 1.7.2-2
> Severity: normal
> 
> https://bitbucket.org/ecollins/passlib/wiki/Home is 404
> 
> A replacement might be https://pypi.org/project/passlib/
The new repo is at https://foss.heptapod.net/python-libs/passlib and there
is a wiki page at
https://foss.heptapod.net/python-libs/passlib/-/wikis/home so that can be
used as a direct replacement.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

[Boyuan Yang]

在 2021-03-01星期一的 00:19 +0900，YOSHINO Yoshihito写道：
> Package: ibus-anthy
> Followup-For: Bug #983695
> 
> Dear Maintainer,
> 
> I have created a merge request on salsa at
> https://salsa.debian.org/input-method-team/ibus-anthy/-/merge_requests/2
> 
> Thanks in advance,

This patch looks suboptimal and personally I am not in the position of
merging it. It would be great if Japanese users and Anthy users could
review the current condition. Meanwhile I will upload ibus-anthy 1.5.12
without this patch first.

Thanks,
Boyuan Yang


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

Bug#807722: xaos: i386 illegal instruction

[Kovács Zoltán]

I tried if this problem persists on Ubuntu 18.04, XaoS 4.2.1, current
GitHub sources (compiled via "qmake && make"). The answer is: no. Version
4+ actually no longer uses the m4/ stuff. So, I guess, this issue can be
closed unless anyone is still interested in the 3.x sources.

Best, Zoltan

-- 

*Dr. Zoltán** Kovács, MSc*

Institut Ausbildung




*Private Pädagogische Hochschule der Diözese Linz*
*Private University of Education, Diocese Linz**Salesianumweg 3, 4020 Linz*
*Mail: zoltan.kov...@ph-linz.at *

*Web: www.ph-linz.at *

Bug#978163: go-dep: Not release with bullseye

[Shengjing Zhu]

Control: retitle -1 RM: go-dep -- RoQA; unmaintained upstream
Control: severity -1 normal
Control: reassign -1 ftp.debian.org

On Sun, Dec 27, 2020 at 4:27 AM Shengjing Zhu  wrote:
>
> Package: go-dep
> Version: 0.5.4-3
> Severity: serious
> X-Debbugs-Cc: z...@debian.org, ben...@debian.org, f...@debian.org
>
> Dear Maintainer,
>
> dep is deprecated by upstream. The upstream repo is now read-only.
> Users should have migrated to Go modules.
>
> I was thinking just to request RM, but let's try removing it from
> testing first.
>

It has been removed from testing already. No need to keep it in unstable.

-- 
Shengjing Zhu

Bug#983683: gdebi: downgrade policykit-1 as a Recommends only

[Thierry B.]

Package: gdebi
Version: 0.9.5.7+nmu4
Severity: wishlist

Dear Maintainer,

Using Devuan without policykit, the package gdebi can't be installed. 
However

it is not a strong dependency, as I remove this dependency from the deb
and it works fine for more than 2 years.

So policykit-1 could be only Recommended.


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera/ceres)
Release:testing/unstable
Codename:   n/a
Architecture: x86_64

Kernel: Linux 5.10.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en

Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gdebi depends on:
ii  gdebi-core0.9.5.7+nmu4
ii  gir1.2-gtk-3.03.24.24-1
ii  gir1.2-vte-2.91   0.62.2-1
ii  gnome-icon-theme  3.12.0-3
ii  python3   3.9.1-1
ii  python3-gi3.38.0-2

Versions of packages gdebi recommends:
pn  libgtk2-perl  
ii  lintian   2.104.0
ii  shared-mime-info  2.0-1

gdebi suggests no packages.

-- no debconf information

Bug#983677: Logfile

[Rainer Dorsch]

Hi,

attached is the logfile for the bugreport.

Thanks
Rainer
-- 
Rainer Dorsch
http://bokomoko.de/

paper-format.log.xz
Description: application/xz

Bug#983700: sga: reduce Build-Depends

[Helmut Grohne]

Source: sga
Version: 0.10.15-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

sga cannot satisfy its cross Build-Depends. Instead of looking into such
a difficult problem, I looked into easily droppable dependencies. It
turns out that it actually doesn't need the gawk implementation of awk.
Since awk is essential, we can drop the dependency. The Build-Depends
also include (nicely commented) runtime dependencies. I think it would
be reasonable to annotate them . It does build without them.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru sga-0.10.15/debian/changelog sga-0.10.15/debian/changelog
--- sga-0.10.15/debian/changelog2019-12-22 19:05:15.0 +0100
+++ sga-0.10.15/debian/changelog2021-02-28 10:48:54.0 +0100
@@ -1,3 +1,12 @@
+sga (0.10.15-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop gawk as it builds with any awk, which is essential.
++ Annotate runtime dependencies .
+
+ -- Helmut Grohne   Sun, 28 Feb 2021 10:48:54 +0100
+
 sga (0.10.15-5) unstable; urgency=medium
 
   * Use 2to3 to port to Python3
diff --minimal -Nru sga-0.10.15/debian/control sga-0.10.15/debian/control
--- sga-0.10.15/debian/control  2019-12-22 19:05:15.0 +0100
+++ sga-0.10.15/debian/control  2021-02-28 10:48:51.0 +0100
@@ -9,14 +9,13 @@
libsparsehash-dev,
zlib1g-dev | libz-dev,
libbamtools-dev,
-   gawk,
help2man,
 # Run-Time Depends
 # (to prevent building on architectures where it won't be installable)
-   samtools,
-   python3,
-   python3-ruffus,
-   python3-pysam
+   samtools ,
+   python3 ,
+   python3-ruffus ,
+   python3-pysam 
 Standards-Version: 4.4.1
 Vcs-Browser: https://salsa.debian.org/med-team/sga
 Vcs-Git: https://salsa.debian.org/med-team/sga.git

Bug#983701: krb5-strength FTBFS when passing the nocheck build profile

[Helmut Grohne]

Source: krb5-strength
Severity: important
Version: 3.2-2
Tags: ftbfs patch

krb5-strength fails to build from source when passing the nocheck build
profile. When you (Russ) applied my previous patch, you were a little
too eager and annotated a number of other dependencies  than I
proposed. However, I already supplied the maximal set that kept
krb5-strength building. Annotating any of those other dependencies makes
it FTBFS (unless you also change something about the build system). So
please consider applying the attached patch to revert those other
 annotations or (better) change the build instructions to
really not require them.

Helmut
diff --minimal -Nru krb5-strength-3.2/debian/changelog 
krb5-strength-3.2/debian/changelog
--- krb5-strength-3.2/debian/changelog  2020-12-31 03:11:26.0 +0100
+++ krb5-strength-3.2/debian/changelog  2021-02-28 17:09:46.0 +0100
@@ -1,3 +1,10 @@
+krb5-strength (3.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with nocheck profile. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 28 Feb 2021 17:09:46 +0100
+
 krb5-strength (3.2-2) unstable; urgency=medium
 
   * Mark build dependencies used only for the test suite with .
diff --minimal -Nru krb5-strength-3.2/debian/control 
krb5-strength-3.2/debian/control
--- krb5-strength-3.2/debian/control2020-12-31 03:11:26.0 +0100
+++ krb5-strength-3.2/debian/control2021-02-28 17:09:46.0 +0100
@@ -9,21 +9,21 @@
  libcrack2-dev,
  libcrypt-pbkdf2-perl ,
  libdb-file-lock-perl ,
- libdbd-sqlite3-perl ,
- libdbi-perl ,
+ libdbd-sqlite3-perl,
+ libdbi-perl,
  libgetopt-long-descriptive-perl ,
  libipc-run-perl ,
- libjson-perl ,
+ libjson-perl,
  libkrb5-dev (>= 1.9),
- libperl6-slurp-perl ,
- libreadonly-perl ,
+ libperl6-slurp-perl,
+ libreadonly-perl,
  libsqlite3-dev,
  libtest-minimumversion-perl ,
  libtest-pod-perl ,
  libtest-strict-perl ,
  perl,
  pkg-config,
- tinycdb ,
+ tinycdb,
 Rules-Requires-Root: no
 Standards-Version: 4.5.1
 Homepage: https://www.eyrie.org/~eagle/software/krb5-strength/

Bug#982892: ITP: binutils-or1k-elf -- GNU binary utilities for the Open RISC 1000 processors

[Helmut Grohne]

On Sun, Feb 28, 2021 at 03:23:47PM +0100, Nicolas Boulenguez wrote:
> Can you describe the scenarios you want to avoid?  The binutils-* are
> quite different from each other.

Some binutils bug is discovered. Once understood, Matthias is usually
quick at uploading a fixed binutils. However binutils-* are not uploaded
at the same frequency and still exhibit the bug. The bug is usually
closed and it takes a while to figure that we still have a copy of it in
the archive, because some binutils-* wasn't rebuilt.

Reproducibility is another issue. If you natively build an or1k package
and compare it to a cross built one, the cross build usually does not
reproduce the native build, because the cross toolchains are outdated
with respect to the native toolchains.

A solution to both would be regularly uploading the binutils wrapper
packages. However, that's not what is happening in practice. The second
best solution is reducing their number as much as possible. Doing so
makes updating them all remotely feasible.

> Small wrappers like binutils-{bpf,or1k-elf,...} are Built-Using:
> binutils-source.  As long as they build against latest binutils, there
> is no difference with building them from binutils.dsc.  But if/when
> they FTBFS, the failure does not involve unrelated maintainers.

In practice, the wrapper packages are always outdated and for or1k, you
wouldn't expect frequent FTBFS.

> On the other hand, some binutils-* packages keep an old copy the
> binutils source tarball, for example because the patches from the
> hardware vendor have not been rebased yet.  The Debian maintainers
> know very well that this is not ideal, but in this case sharing the
> source package is simply not an option.

For more exotic binutils - in particular those needing patches or older
versions - using a separate source package is reasonable. or1k does not
seem to fall into that category. All we need to do is change one line in
the binutils source package and be done.

Helmut

Bug#983657: debian-policy: weaken manual page requirement

[Helmut Grohne]

On Sun, Feb 28, 2021 at 11:58:08AM +0100, Bill Allombert wrote:
> On Sun, Feb 28, 2021 at 08:29:21AM +0100, Helmut Grohne wrote:
> > So this is actually asking for two distinct things:
> >  * Allow moving manual pages to dependencies
> >  * Allow demoting such dependencies to recommends
> > 
> > A possible wording in ch-docs.rst could be:
> >  Each program, utility, and function should have an associated manual
> > -page included in the same package. It is suggested that all
> > +page included in the same package or one of its dependencies or
> > +recommended packages. It is suggested that all
> >  configuration files also have a manual page included as well. Manual
> >  pages for protocols and other auxiliary things are optional.
> > 
> > What do you think?
> 
> The goal is to avoid program to be installed but not their manpages,
> so generally I do not find Recommends to be enough.

If we cannot build consensus around that second part, so be it. But
maybe the other part (moving manual pages to dependencies) can reach
consensus?

Helmut

Bug#940613: Any updates?

[Gard Spreemann]

Hi,

I see version 1.0 of this software was just released, and has been
making its way around the web. It looks really neat! Do you think you'll
be interested in picking back up your packaging efforts for after the
Bullseye release? I'm happy to lend a hand.


Best,
Gard

Bug#958787: maven-cache-cleanup: diff for NMU version 1.0.4-1.2

[tony mancill]

On Sat, Feb 27, 2021 at 04:16:18PM +0200, Adrian Bunk wrote:
> I've prepared an NMU for maven-cache-cleanup (versioned as 1.0.4-1.2) 
> and uploaded it to DELAYED/1. Please feel free to tell me if I should 
> cancel it.

Thank you Adrian.  I will apply the dsc to packaging repo and
acknowledge in the next upload.

Bug#983677: Further information

[Rainer Dorsch]

Hi,

after I submitted the bug report I made these additional observations:

I can still change to self-added paper formats, but not to pre-defined formats, 
like A4, US Letter, US legal

It seems to be related to ADF, switching first to flatbed, then change the 
paper 
format, then switch back to ADF works.

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Bug#940613: Any updates?

[Sergio Durigan Junior]

On Sunday, February 28 2021, Gard Spreemann wrote:

> Hi,
>
> I see version 1.0 of this software was just released, and has been
> making its way around the web. It looks really neat! Do you think you'll
> be interested in picking back up your packaging efforts for after the
> Bullseye release? I'm happy to lend a hand.

Thank you for your interest.  I'm actually finishing the package right
now.  I should upload it to experimental in the next couple of days.

The problem is that we're in freeze now, so I can't upload it directly
to unstable, but I will talk to the release team and see if they can
make an exception for this one.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

Bug#983704: Switch to fcitx5 for Simplified and Traditional Chinese desktop

[Shengjing Zhu]

Package: tasksel
Version: 3.64
Severity: important
X-Debbugs-Cc: z...@debian.org, debian-chinese...@lists.debian.org, 
debian-chinese-b...@lists.debian.org

Please replace fcitx with fcitx5 in Bullseye for Chinese desktops.

fcitx doesn't work for Wayland users. And the upstream develop of fcitx
is in maintenance mode.

fcitx5 is developed by same upstream, and works for Wayland.

Fcitx5 reaches its stable version in 2020-11. I and other DDs have used it
for months. And it works well.

So I think it's better to replace fcitx with fcitx5 for Bullseye, instead of
documenting in release notes that tells users to switch to Xorg.


signature.asc
Description: PGP signature

Bug#785495: Bug is back on 3.38.2.1-1

[Andre Etienne]

On Sun, 28 Feb 2021 00:33:56 + Andre Etienne 
 wrote:

> On Sat, 27 Feb 2021 02:51:22 + Andre Etienne
>  wrote:
> > Hi all,
> >
> >
> > With Buster (gdm3 3.30.2-3 ) using DisallowTCP=false add the "-listen
> > tcp" in command line and I can connect remotely.
> >
> > With gdm3 3.38.2.1-1, using DisallowTCP=false remove the "-nolisten 
tcp"

> > but do not add "-listen tcp" so I can not connect remotely.
> >
> >
> > Thanks
> >
> >
>
> Ok,
>
> I try a little trick:
>
> in gdm-server.c and gdm-x-session.c, I remove the conditional if:
>
> #ifdef HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY (and corresponding #else
> and #endif), leaving the remaining code.
>
> I compile the code and now I have the "-listen tcp"  in command line.
>
> So the problem certainly come from the
> HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY condition.
>
> Cheers
>
>
>
>

Hi All,

I re-download source from Debian site, and meson.build now include 
HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY condition.


This solve my trouble, I have the "-listen tcp"  in command line.

Thanks

Bug#983705: RFS: python-mockito/1.2.2-1 [ITP] -- Spying framework for Python - documentation

[Fabrice Bauzac-Stehly]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-mockito":

 * Package name: python-mockito
   Version : 1.2.2-1
   Upstream Author : https://github.com/kaste/mockito-python/issues
 * URL : https://github.com/kaste/mockito-python
 * License : Expat
 * Vcs : 
https://salsa.debian.org/python-team/packages/python-mockito
   Section : python

It builds those binary packages:

  python-mockito-doc - Spying framework for Python - documentation
  python3-mockito - Spying framework for Python

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

  https://mentors.debian.net/package/python-mockito/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-mockito/python-mockito_1.2.2-1.dsc

Changes since the last upload:

 python-mockito (1.2.2-1) unstable; urgency=low
 .
   * Initial release. Closes: #981067

Best regards
--
Fabrice Bauzac-Stehly
PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Bug#983346: Update gitlab to 13.7.7 (installation fails - need help)

[Pirate Praveen]

On Sun, 28 Feb 2021 19:04:24 +0530 Pirate Praveen 
 wrote:

> Asking upstream for help
> https://gitlab.com/gitlab-org/gitlab/-/issues/323024

Removing these 3 files makes the upgrade to proceed,
/usr/share/gitlab/config/feature_flags/ops/api_kaminari_count_with 
_limit.yml

/usr/share/gitlab/config/feature_flags/licensed/resource_access_token.yml
/usr/share/gitlab/config/feature_flags/ops/marginalia.yml

Of these 3 
/usr/share/gitlab/config/feature_flags/licensed/resource_access_token.yml

can definitely be removed as it is not present in current version.

I think these are safe to remove, but I will wait a few days for an 
answer from upstream (till there is a new security release).


Or if someone else can confirm, this is safe, I can remove it as well.

Bug#981243: libboost-log1.74.0 prevents debootsrap to finish correctly

[Radoslav Bodó]

> Adrian Bunk  (2021-02-28):
>> This is a bug in debootstrap which should really use a dependency
>> solver like apt, but AFAIK noone is working on this.
>
> Well debootstrap's goal is what it says in the name, which is
> bootstrapping. Just install a base system first and install whatever
> packages you need using apt afterwards, and voilà.

Hello,

the '--include' has been working fine for years so I suspected a problem
in libboost at first. we've replaced it for 'chroot apt-get' and we'll
proceed with that further on.

Thank you for your replies, I guess the bugreport can be closed.

bodik



signature.asc
Description: OpenPGP digital signature

Bug#983701: krb5-strength FTBFS when passing the nocheck build profile

[Russ Allbery]

Helmut Grohne  writes:

> krb5-strength fails to build from source when passing the nocheck build
> profile. When you (Russ) applied my previous patch, you were a little
> too eager and annotated a number of other dependencies  than I
> proposed. However, I already supplied the maximal set that kept
> krb5-strength building. Annotating any of those other dependencies makes
> it FTBFS (unless you also change something about the build system).

Ugh, I'm sorry.  That's *definitely* a bug; none of those dependencies
should be necessary to build the package.  But I'll work on fixing that
upstream and get this fix into Debian in the meantime for the release.

-- 
Russ Allbery (r...@debian.org)  

Bug#983706: gzip FTBFS on mips64el: FAIL: timestamp

[Adrian Bunk]

Source: gzip
Version: 1.10-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=gzip&arch=mips64el&ver=1.10-3&stamp=1614531854&raw=0

...
FAIL: timestamp
===

+ initial_cwd_=/<>/builddir/tests
+ testdir_prefix_
+ printf gt
+ pfx_=gt
+ mktempd_ /<>/builddir/tests gt-timestamp.
+ destdir_=/<>/builddir/tests
+ template_=gt-timestamp.
+ MAX_TRIES_=4
+ destdir_slash_=/<>/builddir/tests/
+ unset TMPDIR
+ d=/<>/builddir/tests/gt-timestamp.TDZE
+ :
+ test -d /<>/builddir/tests/gt-timestamp.TDZE
+ ls -dgo /<>/builddir/tests/gt-timestamp.TDZE
+ perms=drwx-- 2 40 Feb 28 17:04 
/<>/builddir/tests/gt-timestamp.TDZE
+ :
+ echo /<>/builddir/tests/gt-timestamp.TDZE
+ return
+ test_dir_=/<>/builddir/tests/gt-timestamp.TDZE
+ cd /<>/builddir/tests/gt-timestamp.TDZE
+ gl_init_sh_nl_=

+ IFS=  

+ expr 1 + 128
+ eval trap 'Exit 129' 1
+ trap Exit 129 1
+ expr 2 + 128
+ eval trap 'Exit 130' 2
+ trap Exit 130 2
+ expr 3 + 128
+ eval trap 'Exit 131' 3
+ trap Exit 131 3
+ expr 13 + 128
+ eval trap 'Exit 141' 13
+ trap Exit 141 13
+ expr 15 + 128
+ eval trap 'Exit 143' 15
+ trap Exit 143 15
+ trap remove_tmp_ 0
+ path_prepend_ ..
+ test 1 != 0
+ path_dir_=..
+ abs_path_dir_=/<>/builddir/tests/..
+ 
PATH=/<>/builddir/tests/..:/<>/builddir:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
+ create_exe_shims_ /<>/builddir/tests/..
+ return 0
+ shift
+ test 0 != 0
+ export PATH
+ TZ=UTC0
+ export TZ
+ oldIFS=   

+ IFS=~
+ set 19010101 Jan  1  1901
+ time=19010101
+ date=Jan  1  1901
+ IFS=  

+ touch -t 19010101 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan  1  1901 in
+ returns_ 2 gzip in
+ fail=1
+ rm -f in.gz in
+ IFS=~
+ set 196912312359.59 Dec 31  1969
+ time=196912312359.59
+ date=Dec 31  1969
+ IFS=  

+ touch -t 196912312359.59 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Dec 31  1969 in
+ returns_ 2 gzip in
+ fail=1
+ rm -f in.gz in
+ IFS=~
+ set 19700101 Jan  1  1970
+ time=19700101
+ date=Jan  1  1970
+ IFS=  

+ touch -t 19700101 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan  1  1970 in
+ returns_ 2 gzip in
gzip: in: warning: file timestamp out of range for gzip format
+ rm -f in.gz in
+ IFS=~
+ set 210602070628.16 Feb  7  2106
+ time=210602070628.16
+ date=Feb  7  2106
+ IFS=  

+ touch -t 210602070628.16 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Feb  7  2106 in
+ returns_ 2 gzip in
gzip: in: warning: file timestamp out of range for gzip format
+ rm -f in.gz in
+ IFS=~
+ set 19700101.01 Jan  1  1970
+ time=19700101.01
+ date=Jan  1  1970
+ IFS=  

+ touch -t 19700101.01 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan  1  1970 in
+ gzip in
+ rm -f in.gz in
+ IFS=~
+ set 203801190314.07 Jan 19  2038
+ time=203801190314.07
+ date=Jan 19  2038
+ IFS=  

+ touch -t 203801190314.07 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan 19  2038 in
+ gzip in
+ rm -f in.gz in
+ IFS=~
+ set 203801190314.08 Jan 19  2038
+ time=203801190314.08
+ date=Jan 19  2038
+ IFS=  

+ touch -t 203801190314.08 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Jan 19  2038 in
+ gzip in
+ rm -f in.gz in
+ IFS=~
+ set 210602070628.15 Feb  7  2106
+ time=210602070628.15
+ date=Feb  7  2106
+ IFS=  

+ touch -t 210602070628.15 in
+ ls -l in
+ ls_l=-rw-rw-r-- 1 buildd buildd 0 Feb  7  2106 in
+ gzip in
+ rm -f in.gz in
+ printf \037\213\10\0\377\377\377\377\0\377\3\0\0\0\0\0\0\0\0\0
+ gzip -Nlv
method  crc date  time   compresseduncompressed  ratio 
uncompressed_name
defla  Feb  7 06:28  20   0   0.0% 
stdout
+ status=0
+ test 0 -eq 0
+ :
+ gzip --no-name
+ Exit 1
+ set +e
+ exit 1
+ exit 1
+ remove_tmp_
+ __st=1
+ cleanup_
+ :
+ test  = yes
+ cd /<>/builddir/tests
+ chmod -R u+rwx /<>/builddir/tests/gt-timestamp.TDZE
+ rm -rf /<>/builddir/tests/gt-timestamp.TDZE
+ exit 1
FAIL timestamp (exit status: 1)


Testsuite summary for gzip 1.10

# TOTAL: 22
# PASS:  21
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log
Please report to bug-g...@gnu.org

make[5]: *** [Makefile:1674: test-suite.log] Error 1



On the porterbox eller, 1.10-2 fails the same as 1.10-3.
1.10-3 builds in a buster chroot.

The breakage is likely caused or triggered by a change to
some other package like gcc/glibc/...

The linux-mips list is CC'ed.

Bug#983657: debian-policy: weaken manual page requirement

[Sean Whitton]

Hello,

On Sun 28 Feb 2021 at 05:41PM +01, Helmut Grohne wrote:

> If we cannot build consensus around that second part, so be it. But
> maybe the other part (moving manual pages to dependencies) can reach
> consensus?

Can you post a patch just doing the moving manpages to dependencies part
and indicate that you are seeking seconds?  Then we can get that
applied.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#931402: could not leave editor on examining a config file conflict

[Norman Rasmussen]

Package: dpkg
Version: 1.20.7.1
Followup-For: Bug #931402

I can reproduce this in just the shell that's started. Ctrl-C doesn't
seem to have any immediate effect. However once the shell is exited, the
Ctrl-C causes dpkg to terminate early.

I suspect that dpkg isn't creating a new foreground process group, so
the SIGINT from Ctrl-C is being delivered to dpkg instead of the shell
(or relevant sub-process like the editor).

Adding a setsid or setpgid call somewhere in spawn_shell and/or
show_diff would probably fix it.

-- Package-specific info:

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.30-2
ii  liblzma5 5.2.4-1+b1
ii  libselinux1  3.1-2+b2
ii  tar  1.29b-2
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.1.20
pn  debsig-verify  

-- no debconf information

Bug#983708: passdev and systemd use conflicting syntax for keyfile

[schaarsc]

Package: cryptsetup-initramfs
Version: 2:2.3.4-2~bpo10+2

systemd  247.2-5~bpo10+1

I recently switched to buster-backports and noticed an issue that (I think) 
could potentially break
systems migrating to bullseye.
On a system having encrypted root, keyfile on usb-stick and multiple btrfs 
subvolumes, the system
fails to mount all subvolumes.

If there is no solution, then maybe a hint in the README could be added.

== Root cause ==

/etc/crypttab is used by passdev and systemd, but using different syntax
passdev expects[1] :
systemd expects[2] :


== Setup ==

/etc/crypttab
(this is in one line, split to avoid random line breaks)
root-luks
/dev/sda2
/dev/disk/by-label/usbkeys:/root.key
luks,keyscript=passdev,initramfs


/etc/fstab
/dev/sda1/boot   ext2
/dev/mapper/root-luks/   btrfs subvol=@
/dev/mapper/root-luks/.snapshots btrfs subvol=@snapshots
/dev/mapper/root-luks/home   btrfs subvol=@home


== Observed issues ==

1. grub starts initramfs
2. cryptsetup-initramfs opens root-luks
3. systemd-cryptsetup-generator starts
4. Error: failed to mount run-systemd-cryptsetup-keydev\\x2droot\\x2dluks.mount
5. .snapshots and home is not mounted because of missing "dependency" for 
root-luks


== Workaround ==

create a systemd-mount file for the usb-stick
/etc/systemd/system/run-systemd-cryptsetup-keydev\\x2droot\\x2dluks.mount
What=/dev/disk/by-label/usbkeys
Where=/run/systemd/cryptsetup/keydev-root-luks
Options=ro

== References ==
1. /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz
2. https://www.freedesktop.org/software/systemd/man/crypttab.html

Bug#983709: nn: back_act.sh:

[Bjarni Ingi Gislason]

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

Dear Maintainer,

>From 0f46483d7b072826e6ec74221db0a95d3fe8840c Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 28 Feb 2021 18:08:47 +
>Subject: [PATCH] back_act.sh: empty file $ACTIVE after saving it

  back_act.sh: empty file $ACTIVE after saving it

Signed-off-by: Bjarni Ingi Gislason 
---
 back_act.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/back_act.sh b/back_act.sh
index c5cebf4..a99cf7d 100644
--- a/back_act.sh
+++ b/back_act.sh
@@ -29,5 +29,5 @@ do
p=$i
 done
 
-cp $ACTIVE active.0
+cp $ACTIVE active.0 && : > $ACTIVE || :
 chmod 644 active.0
-- 
2.30.1



-- 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#983710: put-dns: [INTL:pt] Updated Portuguese translation for debconf messages

[Traduz - DebianPT]

Package: put-dns
Version: 0.0.2-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for put-dns's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
--
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org
















# Portuguese translation for put-dns messages.
# Copyright (C) 2021 Miguel Figueiredo 
# This file is distributed under the same license as the put-dns package.
# Miguel Figueiredo , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: put-dns\n"
"Report-Msgid-Bugs-To: put-...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-22 08:32+\n"
"PO-Revision-Date: 2021-02-28 18:26+\n"
"Last-Translator: Miguel Figueiredo \n"
"Language-Team: Portuguese \n"
"Language: Portuguese\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Automatically update domain in put-dns.conf?"
msgstr "Atualizar automaticamente o domínio em put-dns.conf?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"If enabled put-dns will, on configuration, try to detect a valid external "
"domain name on the current system and update the put-dns.conf configuration "
"file to use it. If disabled then the configuration will not be automatically "
"updated."
msgstr ""
"Se estiver ativo, durante a configuração o put-dns irá, tentar detetar um "
"nome de domínio externo válido no sistema atual e atualizar o ficheiro de "
"configuração put-dns.conf para o utilizar. Se estiver desabilitado, então "
"o ficheiro de configuração não será atualizado automaticamente."