Bug#989589: FTFBS on s390x in 1.0.7

[Christian Ehrhardt]

Package: gdisk
Version: 1.0.7-1

Hi,
I wanted to let you know that the recent FTFBS on s390x in Debian [1]
and Ubuntu [2] is caused by a try to fix big endian byte swapping in
1.0.7 that actually made it break.

When you look at the logs it seems it is just failing for no apparent reason,
but with -x enabled in gdisk_test.sh one quickly sees there is some
string-mangling happening:

Number  Start (sector)End (sector)  Size   Code  Name
   12048  131038   63.0 MiB8300  䰀椀渀甀砀 昀椀氀攀猀礀猀琀攀洀

Reading the very same file with the old gdisk is good - so likely the
on-dis content is good as well:
Number  Start (sector)End (sector)  Size   Code  Name
   12048  131038   63.0 MiB8300  Linux filesystem

This is caused by GPTPart::GetDescription due to this change [3] in 1.0.7

Reverting this fixes change fixes the problem, so that is what I'd
suggest for the gdisk package that is stuck in unstable due to that.

P.S. I've reported the same upstream as well but their archive seems
slow to pick it up, so there is no linkable reference yet.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=gdisk&arch=s390x&ver=1.0.7-1&stamp=1617791278&raw=0
[2]: 
https://launchpadlibrarian.net/540613637/buildlog_ubuntu-impish-s390x.gdisk_1.0.7-1_BUILDING.txt.gz
[3]: 
https://sourceforge.net/p/gptfdisk/code/ci/86dd5fea351a5a55bea26b7622eb85ebd6075a60/
[4]:

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#989548: light-locker: Username field has focus when unlocking

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: tag -1 unreproducible moreinfo

On Mon, 2021-06-07 at 09:55 +0100, Keith Edmunds wrote:
New installation of Bullseye with XFCE and light-locker. When the screen is
locked,
the username is not populated and it also has focus. Previous versions of
light-locker
would fill in the username and put the focus on the password field.

If one is used to the previous behaviour and starts typing the password, it
appears in
clear text in the username field.

The username field should be populated with the logged-in user as that is by
far the most
likely user to be unlocking the system.

Hi Keith,

this is exactly the behavior I have here. I'm running a sid box, but it has
the same light-locker version (and I'm assuming you also use lightdm-gtk-
greeter, which also has the same version in both).

Are you sure you're not entering a key or something which would erase the
field content (since it's focused)?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmC/G18ACgkQ3rYcyPpX
RFtEKgf/Wa7T62T0yhmpAv7d0AVNi+N8UuYOb9yPHc/yAW+CausLRjtu4THOJ3JZ
Z/PEAe4t7AqnqHwWLp7313iq00BQv2sBwLCI5fEdlGWjqIgmblPY/MBxeCy9eFDY
p0mK3TIp53z89E1G3Z5qmGqcmL9RAytG9GXGe3ArChumHVMB+W38PQ03Ni3Lp1L+
3mDLDtoMxzZmxn2Ef+qRi4FqHmI5h7H46E9jz9+dFazuOl5TNd3sonz7FHORIXz8
aomJt+C3N3yPFpQD+fnS7BC8VDltPhAXPjg4mQ/2la0aoKNNRJIi0AUr0MW49OeR
700vq1WzbLzTaTqymfv1i6EJWP4zhg==
=LbL7
-END PGP SIGNATURE-

Bug#989589: Upstream engaged and Salsa interim fix

[Christian Ehrhardt]

Hi,
the discussion upstream started on
https://sourceforge.net/p/gptfdisk/mailman/gptfdisk-general/thread/8db702c5-642c-705d-294c-2df60a070ff6%40gmail.com/#msg37298402

Until then (which will likely be a 1.0.8) this MP would fix the issue
in Debian on 1.0.7:
https://salsa.debian.org/debian/gdisk/-/merge_requests/2

Reverting this isn't too bad as it is the very same behavior that we
have in 1.0.6-1.1 in testing.
But it would allow us to gain the other bits of 1.0.7 like the support
for three more partition types and the fix of some spurious error
messages.

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#989590: purple-lurch: add upstream README.md

[Paul Wise]

Package: purple-lurch
Version: 0.6.8+git20200527.388605-3
Severity: wishlist

Please include the upstream README.md in the package so that people can
read it without visiting GitHub. Since it includes a lot of install
information for Windows etc that Debian binary package users do not
need, it might be a good idea to strip that out of the shipped file.

-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'testing-security')
Architecture: amd64 (x86_64)

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

Versions of packages purple-lurch depends on:
ii  libaxc00.3.3-1+b1
ii  libc6  2.31-12
ii  libglib2.0-0   2.68.1-2
ii  libomemo0  0.7.0-1
ii  libpurple0 2.14.1-1
ii  libsignal-protocol-c2.3.2  2.3.3-1

purple-lurch recommends no packages.

purple-lurch suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Gilles Filippini]

Control: reassign -1 postgresql-13-postgis-3

Andreas Beckmann a écrit le 08/06/2021 à 08:27 :
An alternative solution would be to rename libhdf5*-103-1 back to 
libhdf5*-103 and add dependencies on the split out libraries (s.t. e.g. 
dependencies of a buster package depending on libhdf5-103 for a -hl 
library are still satisfied). These Depends can be removed once the 103 
SOVERSION gets bumped.


I don't think so. The problem is in postgis which *requires* a 2.5 
runtime to migrate databases from buster to bullseye.


I acknowledge and regret that this 103 to 103-1 hdf5 transition (*) is 
unfortunate and doesn't help at all with a workaround, but this is not 
where the problem lies in the first place. This painful postgis 
migration experience seems well [0] known [1] and documented [2] at 
several places.


[0] 
https://stackoverflow.com/questions/63413582/can-not-upgrade-postgis-2-5-to-3-0-1-for-postgresql-11-on-ubuntu

[1] https://github.com/postgis/docker-postgis/issues/207
[2] 
https://oslandia.com/en/2020/11/05/mettre-a-jour-vos-vieux-clusters-postgis/


The only solutions I can see are either to document postgis databases 
manual migration (such as in [2]) or to reintroduce a minimal 
postgis-2.5 runtime built against postgresql 13 to fix the scripted 
migration procedure.


(*) As a side note, this hdf5 transition was triggered by an hdf5 
Fortran API SONAME bump while the SONAME for the C library wasn't 
changed. All the hdf5 runtime libraries now have their own binary 
package to prevent such a Breaks / Replaces transition to happen again.


Best,

_g.

Bug#989591: ITP: golang-github-masterminds-sprig -- Useful template functions for Go templates.

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-masterminds-sprig
  Version : 3.2.1-1
  Upstream Author : Masterminds 
* URL : https://github.com/Masterminds/sprig
* License : Expat
  Programming Lang: Go
  Description : Useful template functions for Go templates. 

 The Go language comes with a built-in template language
 (http://golang.org/pkg/text/template/), but not very many template
 functions. Sprig is a library that provides more than 100 commonly used
 template functions.
 
 It is inspired by the template functions found in Twig
 (http://twig.sensiolabs.org/documentation) and in various JavaScript
 libraries, such as underscore.js (http://underscorejs.org/).
 
 The API documentation is available at GoDoc.org 
 (http://godoc.org/github.com/Masterminds/sprig/).

Reasoning: This library is a build dependency of the caddywebserver:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890

Bug#989592: unblock: dino-im/0.2.0-3

[Martin]

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

Please unblock package dino-im.

0.2.0-3 fixes CVE-2021-33896 and another related bug.

Both fixes are in upstream version 0.2.1, but applied as patches here.

debdiff is attached.

unblock dino-im/0.2.0-3
diff -Nru dino-im-0.2.0/debian/changelog dino-im-0.2.0/debian/changelog
--- dino-im-0.2.0/debian/changelog	2021-03-22 22:38:23.0 +
+++ dino-im-0.2.0/debian/changelog	2021-06-07 17:43:27.0 +
@@ -1,3 +1,11 @@
+dino-im (0.2.0-3) unstable; urgency=critical
+
+  * Fix file traversal issue on incoming file transfers (CVE-2021-33896)
+  * Don't remove characters after '#' in filename
+Thanks to fiaxh (Dino upstream) for both patches!
+
+ -- Martin   Mon, 07 Jun 2021 17:43:27 +
+
 dino-im (0.2.0-2) unstable; urgency=medium
 
   * Add upstream patch to adjust Real for latest vala version
diff -Nru dino-im-0.2.0/debian/patches/dont-remove-characters-after-numbersign-in-filename.patch dino-im-0.2.0/debian/patches/dont-remove-characters-after-numbersign-in-filename.patch
--- dino-im-0.2.0/debian/patches/dont-remove-characters-after-numbersign-in-filename.patch	1970-01-01 00:00:00.0 +
+++ dino-im-0.2.0/debian/patches/dont-remove-characters-after-numbersign-in-filename.patch	2021-06-07 17:39:41.0 +
@@ -0,0 +1,22 @@
+Description: Don't remove characters after '#' in filename
+Author:fiaxh  
+Origin: upstream
+Applied-Upstream: ce292d03e37f146853417855986bf5541b50d2ae
+Last-Update: 2021-06-07
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/plugins/http-files/src/file_provider.vala
 b/plugins/http-files/src/file_provider.vala
+@@ -142,10 +142,11 @@
+ }
+ 
+ private string extract_file_name_from_url(string url) {
+-string ret = Uri.unescape_string(url.substring(url.last_index_of("/") + 1));
++string ret = url;
+ if (ret.contains("#")) {
+ ret = ret.substring(0, ret.last_index_of("#"));
+ }
++ret = Uri.unescape_string(ret.substring(ret.last_index_of("/") + 1));
+ return ret;
+ }
+ 
diff -Nru dino-im-0.2.0/debian/patches/fix-file-traversal-issue-on-incoming-file-transfers.patch dino-im-0.2.0/debian/patches/fix-file-traversal-issue-on-incoming-file-transfers.patch
--- dino-im-0.2.0/debian/patches/fix-file-traversal-issue-on-incoming-file-transfers.patch	1970-01-01 00:00:00.0 +
+++ dino-im-0.2.0/debian/patches/fix-file-traversal-issue-on-incoming-file-transfers.patch	2021-06-07 17:31:09.0 +
@@ -0,0 +1,30 @@
+Description: Fix file traversal issue on incoming file transfers
+Author: fiaxh 
+Origin: upstream
+Bug: https://dino.im/security/cve-2021-33896/
+Applied-Upstream: 0c8d25b7a3e7a10a506f1e19b868fe9b0c761495
+Last-Update: 2021-06-07
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/libdino/src/entity/file_transfer.vala
 b/libdino/src/entity/file_transfer.vala
+@@ -45,7 +45,18 @@
+ }
+ }
+ 
+-public string file_name { get; set; }
++private string file_name_;
++public string file_name {
++get { return file_name_; }
++set {
++file_name_ = Path.get_basename(value);
++if (file_name_ == Path.DIR_SEPARATOR_S || file_name_ == ".") {
++file_name_ = "unknown filename";
++} else if (file_name_.has_prefix(".")) {
++file_name_ = "_" + file_name_;
++}
++}
++}
+ private string? server_file_name_ = null;
+ public string server_file_name {
+ get { return server_file_name_ ?? file_name; }
diff -Nru dino-im-0.2.0/debian/patches/series dino-im-0.2.0/debian/patches/series
--- dino-im-0.2.0/debian/patches/series	2021-03-22 22:38:23.0 +
+++ dino-im-0.2.0/debian/patches/series	2021-06-07 17:35:09.0 +
@@ -1,3 +1,5 @@
+dont-remove-characters-after-numbersign-in-filename.patch
+fix-file-traversal-issue-on-incoming-file-transfers.patch
 adjust-real-for-latest-vala.patch
 rename-to-dino-im.patch
 fix_library_path.patch

Bug#989548: light-locker: Username field has focus when unlocking

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

[please keep the bug number on CC so exchanges are public, this is a bug
report and not a support channel :)]

On Tue, 2021-06-08 at 08:43 +0100, Keith Edmunds wrote:
> I've just locked the screen and the dialog box appears with no username
> populated.
> 
> Even if your hypothesis were correct, why is the focus on the username
> field? If the username is populated, the focus should be on the password
> field.

Here the behavior is as you say: the username is populated (and actually
selected), but the focus in on the password field (and as I understand it,
it's the behavior you had as well before the Bullseye upgrade).
> 
> I can record a video of the behaviour I see if you want.

I don't think that's really necessary, I trust you on this, I just don't know
what happens on your box (which doesn't on mine). You might want to take a
look at logs in /var/log/lightdm (and maybe .xsession-errors as well).

Did you maybe change something in the default lightdm configuration (like
having the userlist displayed?).

Is accountsservice installed on your box?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmC/K2YACgkQ3rYcyPpX
RFu2DAf/euW6Kyyn/noYc8KV5xZ+IVQ18xoqTuxvJF2/XY2T4N0N8r4DRccXmamP
VSxHkyufIvHtD98OIvV5jz06MaTvRvIjp1HQ29EmfBu6HLHbgFG0sb8Dntdw6W5c
g+OnN3ky2ILcyUVOxJtF1gJOL610lkwJwY5diYVJVe2OYWaIuv1ANsLoe3whYEaY
xi/tBXJaDBffG+WiTFK3NOQhs6gvWJYJriHUbcN6f0ovY+W6OrCdrJ0CFrveu0hg
1BoI9k0p73KNIz+BqqPXP5KA3l4nXaBT50cmOslCpJUmBvqpG9NdzvKxRqdrfdEg
l6P4KjvCE3E6Q/Gl6nfCzK5+6lBMYQ==
=ysAi
-END PGP SIGNATURE-

Bug#972245: fixed in 11.0.11+8-1

[Matthias Klose]

Version: 11.0.11+8-1

fixed in 11.0.11+8-1

Bug#989593: installation report Raspberry Pi 4 UEFI

[Marc Haber]

Package: installation-reports
Version: 2.78
Severity: normal
Tags: d-i

Hi,

I followed the instructions given on
https://www.raspberrypi.org/forums/viewtopic.php?t=282839
to install Debian on a Raspberry Pi using the UEFI firmware
available for the raspi.

This involves unpacking the official Debian 11 image into an ESP
partition on an USB medium and using the Rasberry Pi UEFI firmware
to boot the installer via UEFI => grub => Linux. Once the
installe has started, this feels 100 % like a standard Debian
installation.

I experienced the following issues:

"Detecting Hardware" complains about missing firmware. I guess
that's Wifi related, since the Wifi Interface doesn't work in the
installed system and the 1000Base-TX interface works fine without.

Requesting German keyboard layout does not work in the beginning
of installation, domain name and user name configuration still happens
with the default US keyboard layout. Later, when configuring the
network mirror, the keyboard layout has been changed to the requested
german layout. I guess this happens during base system installation.

For very strange reasons, the installed system ends up without
/sbin/start-stop-daemon despite the dpkg package being in state "ii".
This is reproducible. In the installer, I see a temporary diversion of
/sbin/start-stop-daemon, but in the installed system, dpkg-divert --list
doesn't show that.

/var/lib/dpkg/diversions-old has those three lines:
/sbin/start-stop-daemon
/sbin/start-stop-daemon.REAL
:

There is no /sbin/start-stop-daemon.REAL though.

And, the installed system does neither have /var/log/installer nor
/var/log/debian-installer. This is also reproducible :-(   Where would I
find the files that get copied to /target/var/log/installer in the
still running installer?

Greetings
Marc

-- Package-specific info:

installation-report depends on no packages.

Versions of packages installation-report recommends:
ii  pciutils   1:3.7.0-5
ii  reportbug  7.10.3

installation-report suggests no packages.

-- no debconf information

Bug#989594: golang-github-masterminds-semver-dev: Outdated package

[Peymaneh Nejad]

Package: golang-github-masterminds-semver-dev
Version: 1.4.2-2
Severity: normal

Dear Maintainers,

I am packaging the golang library github.com/Masterminds/sprig which
depends on version 3 this library[1]. Could you please update this 
package to v3? 

Happy to write a patch myself and send via mail or merge request on salsa if 
you wish

kind regards,
Peymaneh

[1] 
https://github.com/Masterminds/sprig/blob/3ac42c7bc5e4be6aa534e036fb19dde4a996da2e/go.mod#L7

Bug#989562: apache2: CVE-2021-31618: NULL pointer dereference on specially crafted HTTP/2 request

[Yadd]

Le 08/06/2021 à 08:25, Yadd a écrit :
> Le 08/06/2021 à 07:58, Yadd a écrit :
>> Le 07/06/2021 à 17:34, Salvatore Bonaccorso a écrit :
>>> Source: apache2
>>> Version: 2.4.47-1
>>> Severity: grave
>>> Tags: security upstream
>>> Justification: user security hole
>>> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
>>> 
>>>
>>> Hi,
>>>
>>> The following vulnerability was published for apache2.
>>>
>>> CVE-2021-31618[0]:
>>> | httpd: NULL pointer dereference on specially crafted HTTP/2 request
>>>
>>> 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-31618
>>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31618
>>> [1] 
>>> https://github.com/apache/httpd/commit/a4fba223668c554e06bc78d6e3a88f33d4238ae4
>>> [2] https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2021-31618
>>>
>>> Please adjust the affected versions in the BTS as needed.
>>>
>>> Regards,
>>> Salvatore
>>
>> Hi all,
>>
>> I can't import the whole patch for Bullseye since it is written for
>> 2.4.47. I think the best solution is to import the whole http2 module in
>> Bullseye. This gives the attached patch
>>
>> Cheers,
>> Yadd
> 
> We can also fix this for Buster using the same way (we did it previously
> for 2.4.46). Here is the debdiff

Update for Buster
diff --git a/debian/changelog b/debian/changelog
index b6096f7d..2cb587ef 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+apache2 (2.4.38-3+deb10u5) buster-security; urgency=medium
+
+  * Import the whole HTTP2 module from 2.4.48 (Closes: #989562, CVE-2021-31618)
+
+ -- Yadd   Tue, 08 Jun 2021 08:20:24 +0200
+
 apache2 (2.4.38-3+deb10u4) buster-security; urgency=high
 
   * Import http2 modules from 2.4.46 (Closes: CVE-2020-9490, CVE-2020-11993)
diff --git a/debian/patches/import-http2-module-from-2.4.46.patch 
b/debian/patches/import-http2-module-from-2.4.46.patch
index cdca37d0..6742686b 100644
--- a/debian/patches/import-http2-module-from-2.4.46.patch
+++ b/debian/patches/import-http2-module-from-2.4.46.patch
@@ -1,15 +1,16 @@
-Description: import http2 module from 2.4.41
+Description: import http2 module from 2.4.48
  There are too many changes in http2 module to distiguish CVE-2019-9517,
- CVE-2019-10082 and CVE-2019-10081 changes.
+ CVE-2019-10082, CVE-2019-10081 and CVE-2021-31618 changes.
 Author: Apache authors
 Bug: https://security-tracker.debian.org/tracker/CVE-2019-9517
  https://security-tracker.debian.org/tracker/CVE-2019-10082
  https://security-tracker.debian.org/tracker/CVE-2019-10081
  https://security-tracker.debian.org/tracker/CVE-2020-9490
  https://security-tracker.debian.org/tracker/CVE-2020-11993
+ https://security-tracker.debian.org/tracker/CVE-2021-31618
 Forwarded: not-needed
 Reviewed-By: Xavier Guimard 
-Last-Update: 2020-08-25
+Last-Update: 2021-06-08
 
 --- a/modules/http2/config2.m4
 +++ b/modules/http2/config2.m4
@@ -39,7 +40,7 @@ Last-Update: 2020-08-25
  /* Maximum number of padding bytes in a frame, rfc7540 */
  #define H2_MAX_PADLEN   256
  /* Initial default window size, RFC 7540 ch. 6.5.2 */
-@@ -138,7 +138,7 @@
+@@ -138,11 +138,22 @@
  apr_table_t *headers;
  
  apr_time_t request_time;
@@ -47,8 +48,23 @@ Last-Update: 2020-08-25
 +unsigned int chunked : 1;   /* iff request body needs to be forwarded as 
chunked */
  unsigned int serialize : 1; /* iff this request is written in HTTP/1.1 
serialization */
  apr_off_t raw_bytes;/* RAW network bytes that generated this 
request - if known. */
++int http_status;/* Store a possible HTTP status code that gets
++ * defined before creating the dummy HTTP/1.1
++ * request e.g. due to an error already
++ * detected.
++ */
  };
-@@ -162,5 +162,6 @@
+ 
++/*
++ * A possible HTTP status code is not defined yet. See the http_status field
++ * in struct h2_request above for further explanation.
++ */
++#define H2_HTTP_STATUS_UNSET (0)
++
+ typedef struct h2_headers h2_headers;
+ 
+ struct h2_headers {
+@@ -162,5 +173,6 @@
  #define H2_FILTER_DEBUG_NOTE"http2-debug"
  #define H2_HDR_CONFORMANCE  "http2-hdr-conformance"
  #define H2_HDR_CONFORMANCE_UNSAFE  "unsafe"
@@ -57,7 +73,15 @@ Last-Update: 2020-08-25
  #endif /* defined(__mod_h2__h2__) */
 --- a/modules/http2/h2_alt_svc.c
 +++ b/modules/http2/h2_alt_svc.c
-@@ -75,7 +75,7 @@
+@@ -19,6 +19,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ #include "h2_private.h"
+@@ -75,7 +76,7 @@
  
  static int h2_alt_svc_handler(request_rec *r)
  {
@@ -66,7 +90,7 @@ Last-Update: 2020-08-25
  int i;
  
  if (r->connection->keepalives > 0) {
-@@ -87,8 +87,8 @@
+@@ -87,8 +88,8 @@
  return DECLINED;
  }
 

Bug#989596: ImportError when used with python3.9

[Sebastien Bacher]

Package: nautilus-admin
Version: 1.1.9-3
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

The bug has been initially reported on
https://bugs.launchpad.net/ubuntu/+source/nautilus-admin/+bug/1924573

'$ nautilus -q
Traceback (most recent call last):
  File "/usr/share/nautilus-python/extensions/nautilus-admin.py", line
25, in 
    from gettext import gettext, locale, bindtextdomain, textdomain
ImportError: cannot import name 'locale' from 'gettext'
(/usr/lib/python3.9/gettext.py)'

The attached patch fixes the issue and comes from
https://github.com/TomaszGasior/mushrooms-rpms/issues/41

Cbeers,

diff -Nru nautilus-admin-1.1.9/debian/changelog nautilus-admin-1.1.9/debian/changelog
--- nautilus-admin-1.1.9/debian/changelog	2019-11-04 21:11:13.0 +0100
+++ nautilus-admin-1.1.9/debian/changelog	2021-06-08 10:48:53.0 +0200
@@ -1,3 +1,11 @@
+nautilus-admin (1.1.9-3.1) unstable; urgency=medium
+
+  * debian/patches/new-python-compat.patch:
+- fix the locale import to be compatible with python 3.9,
+  thanks Kesantielu (lp: #1924573)
+
+ -- Sebastien Bacher   Tue, 08 Jun 2021 10:48:53 +0200
+
 nautilus-admin (1.1.9-3) unstable; urgency=medium
 
   [ Carlos Maddela ]
diff -Nru nautilus-admin-1.1.9/debian/patches/new-python-compat.patch nautilus-admin-1.1.9/debian/patches/new-python-compat.patch
--- nautilus-admin-1.1.9/debian/patches/new-python-compat.patch	1970-01-01 01:00:00.0 +0100
+++ nautilus-admin-1.1.9/debian/patches/new-python-compat.patch	2021-06-08 10:48:53.0 +0200
@@ -0,0 +1,29 @@
+From a51885e75338a9d45f8873d47db067bb81c8071a Mon Sep 17 00:00:00 2001
+From: Vitor Lopes 
+Date: Thu, 3 Dec 2020 16:49:07 +
+Subject: [PATCH] fix for python9
+https://github.com/TomaszGasior/mushrooms-rpms/issues/41
+---
+ extension/nautilus-admin.py | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/extension/nautilus-admin.py b/extension/nautilus-admin.py
+index 683a484..4719bbc 100644
+--- a/extension/nautilus-admin.py
 b/extension/nautilus-admin.py
+@@ -22,7 +22,13 @@
+ require_version('Nautilus', '3.0')
+ 
+ from gi.repository import Nautilus, GObject
+-from gettext import gettext, locale, bindtextdomain, textdomain
++from gettext import gettext, bindtextdomain, textdomain
++try:
++	# python 8
++	from gettext import locale
++except ImportError:
++	# python 9
++	import locale
+ 
+ ROOT_UID = 0
+ NAUTILUS_PATH="@NAUTILUS_PATH@"
+
diff -Nru nautilus-admin-1.1.9/debian/patches/series nautilus-admin-1.1.9/debian/patches/series
--- nautilus-admin-1.1.9/debian/patches/series	2019-11-04 21:11:13.0 +0100
+++ nautilus-admin-1.1.9/debian/patches/series	2021-06-08 10:48:53.0 +0200
@@ -1,2 +1,3 @@
 out-of-place-build.patch
 update-german-translation.patch
+new-python-compat.patch

Bug#989595: unblock: webkit2gtk/2.32.1-2

[Alberto Garcia]

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

Please unblock package webkit2gtk

webkit2gtk has always used (and recommended) gstreamer1.0-plugins-good
for media playback, but since 2.32.x it will crash (assert) if a
suitable plugin is not found. gstreamer1.0-plugins-good is one of
the most installed packages in Debian and is used by many multimedia
apps so the chances of it being missing are low, but they are still
there. See #989332 for an example and #989198 (message 29) for more
details on the problem.

This upload changes gstreamer1.0-plugins-good from a recommendation to
a dependency and also recommends plugins-bad (needed for e.g. YouTube
videos).

Debdiff attached.

Regards,

Berto

unblock webkit2gtk/2.32.1-2
diff -Nru webkit2gtk-2.32.1/debian/changelog webkit2gtk-2.32.1/debian/changelog
--- webkit2gtk-2.32.1/debian/changelog  2021-05-10 12:20:44.0 +0200
+++ webkit2gtk-2.32.1/debian/changelog  2021-06-07 10:39:51.0 +0200
@@ -1,3 +1,14 @@
+webkit2gtk (2.32.1-2) unstable; urgency=high
+
+  * debian/control:
++ Update the dependencies on GStreamer plugins (Closes: #989332):
+  - WebKitGTK really expects at least the -base and -good sets.
+  - For video playback (e.g YouTube) -bad is also recommended.
+  - The pulseaudio plugin was merged into the -good package so it will
+be always be available now. Move -alsa to Suggests.
+
+ -- Alberto Garcia   Mon, 07 Jun 2021 10:39:51 +0200
+
 webkit2gtk (2.32.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru webkit2gtk-2.32.1/debian/control webkit2gtk-2.32.1/debian/control
--- webkit2gtk-2.32.1/debian/control2021-05-10 12:20:44.0 +0200
+++ webkit2gtk-2.32.1/debian/control2021-06-07 10:39:51.0 +0200
@@ -138,16 +138,18 @@
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: libjavascriptcoregtk-4.0-18 (= ${binary:Version}),
+ gstreamer1.0-plugins-base,
+ gstreamer1.0-plugins-good,
  ${bwrap:Depends},
  ${shlibs:Depends},
  ${misc:Depends}
-Recommends: gstreamer1.0-plugins-good,
-gstreamer1.0-pulseaudio | gstreamer1.0-alsa,
+Recommends: gstreamer1.0-plugins-bad,
 gstreamer1.0-gl,
 libgl1-mesa-dri,
 ${bwrap:Recommends},
 ${gst:Recommends}
-Suggests: ${gst:Suggests}
+Suggests: ${gst:Suggests},
+ gstreamer1.0-alsa
 Breaks: evolution (<< 3.34.1)
 Description: Web content engine library for GTK
  WebKit is a web content engine, derived from KHTML and KJS from KDE, and

Bug#983843: 0.9.16 contains the related fixes

[Christian Ehrhardt]

Hi,
I wanted to ping on this bug to let you know that 0.9.16 was tagged on
30th of April and among other things it contains the fixes for this on
s390x and ppc64el:
https://github.com/neutrinolabs/xrdp/commit/1d1ec9614f84243e4a08256f82994278d082b592
https://github.com/neutrinolabs/xrdp/commit/3b81df3f9e894dd164f86d8cf87c3a171ced6d08

So I think either backporting these two for now (since we are in
freeze) or going to 0.9.16 (maybe later on) should resolve this issue.

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#989593: installation report Raspberry Pi 4 UEFI

[Cyril Brulebois]

Hallo Marc,

Marc Haber  (2021-06-08):
> I followed the instructions given on
> https://www.raspberrypi.org/forums/viewtopic.php?t=282839
> to install Debian on a Raspberry Pi using the UEFI firmware
> available for the raspi.
> 
> This involves unpacking the official Debian 11 image into an ESP
> partition on an USB medium and using the Rasberry Pi UEFI firmware
> to boot the installer via UEFI => grub => Linux. Once the
> installe has started, this feels 100 % like a standard Debian
> installation.

Fun!

> I experienced the following issues:
> 
> "Detecting Hardware" complains about missing firmware. I guess
> that's Wifi related, since the Wifi Interface doesn't work in the
> installed system and the 1000Base-TX interface works fine without.

AFAICR (I'll get back to that soon enough) you should get a message
indicating which files were expected, so that you don't have to guess.

> Requesting German keyboard layout does not work in the beginning of
> installation, domain name and user name configuration still happens
> with the default US keyboard layout. Later, when configuring the
> network mirror, the keyboard layout has been changed to the requested
> german layout. I guess this happens during base system installation.

Was that with the text or graphical installer?

> For very strange reasons, the installed system ends up without
> /sbin/start-stop-daemon despite the dpkg package being in state "ii".
> This is reproducible. In the installer, I see a temporary diversion of
> /sbin/start-stop-daemon, but in the installed system, dpkg-divert
> --list doesn't show that.
> 
> /var/lib/dpkg/diversions-old has those three lines:
> /sbin/start-stop-daemon
> /sbin/start-stop-daemon.REAL
> :
> 
> There is no /sbin/start-stop-daemon.REAL though.

A quick grep across our source packages show 3 possibilities:
 - debootstrap
 - debian-installer-utils
 - apt-setup (code apparently copied from d-i-utils until some clean-up
   happens, which never did)

> And, the installed system does neither have /var/log/installer nor
> /var/log/debian-installer. This is also reproducible :-(   Where would
> I find the files that get copied to /target/var/log/installer in the
> still running installer?

Simply /var/log/syslog for the main log. Other files are mentioned
there:
  
https://salsa.debian.org/installer-team/installation-report/-/blob/master/debian/installation-report.postinst


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


signature.asc
Description: PGP signature

Bug#954793: Packaging caddyserver-certmagic

[Peymaneh Nejad]

Hi,

I'm working on packaging caddy 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890) and would like to 
pick up this itp


Kind regards,
Peymaneh

Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11

[Jan Gru]

Hello Samuel,

thank you for your reply.

On 07.06.21 17:16, Samuel Henrique wrote:

Control: severity -1 normal

Hello Jan,

Thanks for the detailed explanation and for pushing your integration
tests. I have pushed them[0] to the main repo (with the same changes
we discussed in the rsakeyfind MR) making use of the "-t 50"
parameter. So the package can have integ tests even before we get to
solve the problem, I hope you don't mind.

Absolutely not, thanks for merging!

It looks like it's not gonna be very easy to debug this, and
considering the way the package works[1], I'm lowering the severity to
normal and I'll likely not gonna try to fix it (anybody reading this
please feel free to submit MRs).
You could consider to raise the default threshold via a patch as a 
workaround until the bug can be fixed.

What do you think of this proposal?

In order to debug this you will probably have to get a stacktrace for
two runs of aeskeyfind against the same dump file, one for each
version of glibc (or whatever is the suspect), and compare them to see
where's the difference in computation occurring for the xor variables.
This is gonna be quite complicated as those variables get changed
inside a loop (for the chunks of memory retrieved) and you're only
interested in one of those iterations (maybe the dump can be
simplified to contain only the key).

I bet it would be an interesting and cool investigation, but one would
have to have enough time for it, so don't feel pressured to do so, the
fact that you found the issue and contributed the integ tests already
put the package in a much better position.
Thanks for the hints. It seems to be challenging and time consuming, 
indeed.
I will put it on my backlog, maybe I will find time to tackle it, but I 
can't promise that.


If someone wants to tackle the issue, it would be great to keep us 
updated here in this thread.


Best regards
    Jan

Bug#988781: hurfbuzz: please package harfbuzz-subset

[Emilio Pozuelo Monfort]

On 19/05/2021 16:44, Mattia Rizzolo wrote:

Source: harfbuzz
Version: 2.7.4-1
Severity: wishlist

Dear maintainer,

I'm packaging the latest scribus 1.5.7, and they have added an
(optional) dependency on harfbuzz-subset.

+# OpenType subsetting support
+pkg_check_modules(HARFBUZZ_SUBSET harfbuzz-subset>=2.4.0)
+if (HARFBUZZ_SUBSET_FOUND)
+   message("Harfbuzz subset library Found OK")
+   set (HAVE_HARFBUZZ_SUBSET ON)
+endif()


Looking, it seems that you are explicitly not packaging it:
 override_dh_install:
dh_install --exclude=subset


Could you please consider including it in the Debian packaging?


It's not packaged because the API was (maybe still is) unstable. From the NEWS 
file:

| Overview of changes leading to 1.7.6
| Wednesday, March 7, 2018
| - New experimental harfbuzz-subset library. All of hb-subset.h
|   is experimental right now and API WILL change.
|
| Overview of changes leading to 1.7.7
| Tuesday, June 5, 2018
| - Significant libharfbuzz-subset changes. API subject to change.

I think we can package it, as hopefully the API is (somewhat) stable now and we 
don't need transitions without SONAME changes (and with conflicting, renamed 
packages).


MRs welcome.

Cheers,
Emilio

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Andreas Beckmann]

Package: release.debian.org
Severity: normal

Let's start with the debian-release@ discussion here, this may be turned
into an unblock request later. 

On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder  wrote:
> One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a
> Breaks: libgdal20 (< 2.5.0~), but the libgdal20 in Buster is 2.4.0,
> and postgresql-11-postgis-2.5 depends on that.  libgdal28 depends on
> gdal-data (>=3.2.1+dfsg-1).  To me it looks like there's no way to
> keep postgresql-11-postgis-2.5 around if anything that depends on
> libgdal28 (postgis, libopencv-imgcodecs4.5, ...) gets installed.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988722#31

gdal can rename gdal-data to gdal3-data, build with
--datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
Thus libgdal20 + gdal-data from buster should be co-installable with
libgdal28 + gdal3-data from bullseye and survive the upgrade if needed.

A patch doing this is attached, I'm now testing the upgrade paths
(along the introduction of the libhdf5*-103 metapackages).

A good gdal bug to reuse would be #986975

Updating gdal may be a bit more tricky, because testing has 3.2.1 while
sid has 3.2.2.


Andreas
diff -Nru gdal-3.2.1+dfsg/debian/changelog gdal-3.2.1+dfsg/debian/changelog
--- gdal-3.2.1+dfsg/debian/changelog2021-01-04 13:49:29.0 +0100
+++ gdal-3.2.1+dfsg/debian/changelog2021-06-07 09:02:51.0 +0200
@@ -1,3 +1,12 @@
+gdal (3.2.1+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename gdal-data to gdal3-data and build with --datadir=/usr/share/gdal3.
+This is a workaround for upgrade issues caused by libgdal20 (in buster)
+and libgdal28 (in bullseye) not being co-installable.  (Closes: #xx)
+
+ -- Andreas Beckmann   Mon, 07 Jun 2021 09:02:51 +0200
+
 gdal (3.2.1+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru gdal-3.2.1+dfsg/debian/control gdal-3.2.1+dfsg/debian/control
--- gdal-3.2.1+dfsg/debian/control  2021-01-04 13:44:44.0 +0100
+++ gdal-3.2.1+dfsg/debian/control  2021-06-07 09:02:51.0 +0200
@@ -68,7 +68,7 @@
 Package: libgdal28
 Architecture: any
 Section: libs
-Depends: gdal-data (>= ${source:Version}),
+Depends: gdal3-data (>= ${source:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Recommends: proj-bin
@@ -189,11 +189,10 @@
  namely gdal_translate, gdalinfo, gdaladdo, gdalwarp, ogr2ogr, ogrinfo,
  ogrtindex.
 
-Package: gdal-data
+Package: gdal3-data
 Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends}
-Breaks: libgdal20 (<< 2.5.0~)
 Description: Geospatial Data Abstraction Library - Data files
  GDAL is a translator library for raster geospatial data formats.
  As a library, it presents a single abstract data model to the
diff -Nru gdal-3.2.1+dfsg/debian/gdal-data.install 
gdal-3.2.1+dfsg/debian/gdal-data.install
--- gdal-3.2.1+dfsg/debian/gdal-data.install2020-10-20 05:44:12.0 
+0200
+++ gdal-3.2.1+dfsg/debian/gdal-data.install1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-usr/share/gdal
diff -Nru gdal-3.2.1+dfsg/debian/gdal-data.lintian-overrides 
gdal-3.2.1+dfsg/debian/gdal-data.lintian-overrides
--- gdal-3.2.1+dfsg/debian/gdal-data.lintian-overrides  2020-10-24 
06:58:20.0 +0200
+++ gdal-3.2.1+dfsg/debian/gdal-data.lintian-overrides  1970-01-01 
01:00:00.0 +0100
@@ -1,6 +0,0 @@
-# Not a problem
-national-encoding usr/share/gdal/s57expectedinput.csv
-
-# Not documentation
-package-contains-documentation-outside-usr-share-doc usr/share/gdal/pci_*.txt
-
diff -Nru gdal-3.2.1+dfsg/debian/gdal3-data.install 
gdal-3.2.1+dfsg/debian/gdal3-data.install
--- gdal-3.2.1+dfsg/debian/gdal3-data.install   1970-01-01 01:00:00.0 
+0100
+++ gdal-3.2.1+dfsg/debian/gdal3-data.install   2021-06-07 09:02:01.0 
+0200
@@ -0,0 +1 @@
+usr/share/gdal3
diff -Nru gdal-3.2.1+dfsg/debian/gdal3-data.lintian-overrides 
gdal-3.2.1+dfsg/debian/gdal3-data.lintian-overrides
--- gdal-3.2.1+dfsg/debian/gdal3-data.lintian-overrides 1970-01-01 
01:00:00.0 +0100
+++ gdal-3.2.1+dfsg/debian/gdal3-data.lintian-overrides 2021-06-07 
09:01:48.0 +0200
@@ -0,0 +1,6 @@
+# Not a problem
+national-encoding usr/share/gdal3/s57expectedinput.csv
+
+# Not documentation
+package-contains-documentation-outside-usr-share-doc usr/share/gdal3/pci_*.txt
+
diff -Nru gdal-3.2.1+dfsg/debian/rules gdal-3.2.1+dfsg/debian/rules
--- gdal-3.2.1+dfsg/debian/rules2021-01-04 13:44:33.0 +0100
+++ gdal-3.2.1+dfsg/debian/rules2021-06-07 09:02:46.0 +0200
@@ -117,6 +117,7 @@
 override_dh_auto_configure:
for V in $(PYVERS); do \
PYTHON=/usr/bin/python$$V ./configure --prefix=/usr \
+   --datadir=\$$\{prefix\}/share/gdal3 \
--mandir=\$$\{prefix\}/share/man \
--includedir=\$$\{prefix\}/include/gdal \
--with-hide-internal-symbols=yes \

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Andreas Beckmann]

On 08/06/2021 08.27, Andreas Beckmann wrote:
Or, wait, easier: we can reintroduce metapackages libhdf5*-103 depending 
on libhdf5*-103-1 and all the other packages containing libraries that 
were in the merged package in buster.



I actually like that solution and will try to come up with a patch ;-)


Here it is. Now testing upgrades ...
There were some new symbols ... but they appeared independently of my 
changes (I built in bullseye, not sid, in case it does matter).


Andreas
diff -Nru hdf5-1.10.6+repack/debian/changelog hdf5-1.10.6+repack/debian/changelog
--- hdf5-1.10.6+repack/debian/changelog	2020-04-24 20:00:42.0 +0200
+++ hdf5-1.10.6+repack/debian/changelog	2021-06-08 08:57:04.0 +0200
@@ -1,3 +1,18 @@
+hdf5 (1.10.6+repack-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reintroduce libhdf5-103, libhdf5-cpp-103, libhdf5-openmpi-103,
+libhdf5-mpich-103 as metapackages depending on the individual library
+packages that were bundled under these names in buster. This is a
+workaround for upgrade issues caused by libhdf5-103 (in buster) and
+libhdf5-103-1 (in bullseye) not being co-installable.  (Closes: #988722)
+The metapackages cannot depend on libhdf5{,-openmpi,-mpich}-fortran100
+because these had the SOVERSION bumped from 100 to 102, but luckily there
+are no known users of these libraries in buster.
+  * Add a new symbol to libhdf5*-cpp-103-1.symbols.
+
+ -- Andreas Beckmann   Tue, 08 Jun 2021 08:57:04 +0200
+
 hdf5 (1.10.6+repack-2) unstable; urgency=medium
 
   * Default plugindir per flavor
diff -Nru hdf5-1.10.6+repack/debian/control hdf5-1.10.6+repack/debian/control
--- hdf5-1.10.6+repack/debian/control	2020-04-24 20:00:42.0 +0200
+++ hdf5-1.10.6+repack/debian/control	2021-06-08 08:57:04.0 +0200
@@ -28,8 +28,8 @@
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
-Breaks: libhdf5-103
-Replaces: libhdf5-103
+Breaks: libhdf5-103 (<< 1.10.5)
+Replaces: libhdf5-103 (<< 1.10.5)
 Description: HDF5 C runtime files - serial version
  Hierarchical Data Format 5 (HDF5) is a file format and library for
  storing scientific data.  HDF5 was designed and implemented to address
@@ -88,14 +88,35 @@
  This package contains the high level Fortran API runtime files for serial
  platforms.
 
+Package: libhdf5-103
+Architecture: any
+Multi-Arch: same
+Section: libs
+Depends: libhdf5-103-1 (= ${binary:Version}),
+#libhdf5-fortran-102 (= ${binary:Version}),
+ libhdf5-hl-100 (= ${binary:Version}),
+ libhdf5-hl-fortran-100 (= ${binary:Version}),
+ ${misc:Depends}
+Description: HDF5 C runtime files - serial version (metapackage)
+ Hierarchical Data Format 5 (HDF5) is a file format and library for
+ storing scientific data.  HDF5 was designed and implemented to address
+ the deficiencies of HDF4.x. It has a more powerful and flexible data
+ model, supports files larger than 2 GB, and supports parallel I/O.
+ .
+ This package contains the C runtime files for serial platforms.
+ .
+ This metapackage helps upgrading from the single package bundling
+ multiple libraries in buster to the individiual library packages in
+ bullseye. It can be safely removed.
+
 Package: libhdf5-cpp-103-1
 Architecture: any
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
-Breaks: libhdf5-cpp-103
-Replaces: libhdf5-cpp-103
+Breaks: libhdf5-cpp-103 (<< 1.10.5)
+Replaces: libhdf5-cpp-103 (<< 1.10.5)
 Description: HDF5 - C++ runtime files - serial version
  Hierarchical Data Format 5 (HDF5) is a file format and library for
  storing scientific data.  HDF5 was designed and implemented to address
@@ -122,6 +143,25 @@
  This package contains the high level C++ API runtime files for serial
  platforms.
 
+Package: libhdf5-cpp-103
+Architecture: any
+Multi-Arch: same
+Section: libs
+Depends: libhdf5-cpp-103-1 (= ${binary:Version}),
+ libhdf5-hl-cpp-100 (= ${binary:Version}),
+ ${misc:Depends}
+Description: HDF5 - C++ runtime files - serial version (metapackage)
+ Hierarchical Data Format 5 (HDF5) is a file format and library for
+ storing scientific data.  HDF5 was designed and implemented to address
+ the deficiencies of HDF4.x. It has a more powerful and flexible data
+ model, supports files larger than 2 GB, and supports parallel I/O.
+ .
+ This package contains the C++ runtime files for serial platforms.
+ .
+ This metapackage helps upgrading from the single package bundling
+ multiple libraries in buster to the individiual library packages in
+ bullseye. It can be safely removed.
+
 Package: libhdf5-dev
 Architecture: any
 Section: libdevel
@@ -155,8 +195,8 @@
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
-Breaks: libhdf5-openmpi-103
-Replaces: libhdf5-openmpi-103
+Breaks: libhdf5-openmpi-103 (<< 1.10.5)
+Replaces: libhdf5-openmpi-103 (<< 1.10.5)
 Description: HDF5 - C runtime files - OpenMPI version
 

Bug#989598: unblock: trilinos/12.18.1-2

[Drew Parsons]

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

Please unblock package trilinos

[ Reason ]

libtrilinos-ml-dev was missing Depends: libtrilinos-aztecoo-dev
Reported in Bug#989488.


[ Impact ]

libtrilinos-ml-dev may appear to behave incorrectly ih
libtrilinos-aztecoo-dev is not installed, giving errors like

 /usr/include/trilinos/ml_aztec_utils.h:28:10: fatal error: az_aztec.h: No such 
file or directory
 28 | #include "az_aztec.h"


[ Tests ]

trilinos does not have its own tests, but debci tests of dependent
packages have passed.

[ Risks ]

Trivial administrative update to packaging. Negligible risk.


[ Checklist ]
  [x ] all changes are documented in the d/changelog
  [x ] I reviewed all changes and I approve them
  [x ] attach debdiff against the package in testing

[ Other info ]

Graham's preapproval has been discussed already in Bug#989488.


unblock trilinos/12.18.1-2
diff -Nru trilinos-12.18.1/debian/changelog trilinos-12.18.1/debian/changelog
--- trilinos-12.18.1/debian/changelog   2020-11-15 17:52:14.0 +0100
+++ trilinos-12.18.1/debian/changelog   2021-06-05 12:50:20.0 +0200
@@ -1,3 +1,11 @@
+trilinos (12.18.1-2) unstable; urgency=medium
+
+  * Team upload.
+  * libtrilinos-ml-dev Depends: libtrilinos-aztecoo-dev.
+Closes: #989488.
+
+ -- Drew Parsons   Sat, 05 Jun 2021 12:50:20 +0200
+
 trilinos (12.18.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru trilinos-12.18.1/debian/control trilinos-12.18.1/debian/control
--- trilinos-12.18.1/debian/control 2020-11-15 17:52:10.0 +0100
+++ trilinos-12.18.1/debian/control 2021-06-05 12:50:20.0 +0200
@@ -582,7 +582,8 @@
 Section: libdevel
 # Manually add libtrilinos-trilinosss-dev as dependency until
 #  is resolved.
-Depends: libtrilinos-ml12 (= ${binary:Version}), trilinos-dev, 
${misc:Depends}, libtrilinos-trilinosss-dev
+Depends: libtrilinos-ml12 (= ${binary:Version}), trilinos-dev, ${misc:Depends},
+ libtrilinos-aztecoo-dev, libtrilinos-trilinosss-dev
 Suggests: trilinos-doc
 Description: multigrid preconditioning - development files
  ML is Sandia's main multigrid preconditioning package. ML is designed to solve

Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames

[Filippo Giunchedi]

Package: swift-container
Version: 2.26.0-10
Severity: important
File: /usr/bin/swift-container-reconciler

Dear Maintainer,
I'm experimenting with Swift on Bullseye and came across a problem with
container-reconciler (possibly others) when using hostnames in
memcache_servers. Namely these errors:

Jun 08 09:54:08 ms-be-01 swift-container-reconciler[70736]: Timeout getting a 
connection to memcached: HOST1:11211: MemcachePoolTimeout (1.0s) (txn: 
txf2bfe46649374ed6b1a47-0060bf3e3f)
Jun 08 09:54:09 ms-be-01 swift-container-reconciler[70736]: Timeout getting a 
connection to memcached: HOST2:11211: MemcachePoolTimeout (1.0s) (txn: 
txf2bfe46649374ed6b1a47-0060bf3e3f)

and I have HOST1 HOST2 in container-reconciler.conf:

memcache_servers = HOST1:11211,HOST2:11211

Manually testing the connection works as expected, and after some debugging it
looks like using ip addresses in the configuration works, unlike using
hostnames. In this case hostname resolution happens via DNS, which makes me
think this is related to #971530. The bug is possibly affecting other parts of
swift + memcache, though I haven't been able to find other examples in my
testing so far.

best,
Filippo

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

Kernel: Linux 5.10.0-6-cloud-amd64 (SMP w/1 CPU thread)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 swift-container depends on:
ii  init-system-helpers   1.60
ii  lsb-base  11.1.0
ii  openstack-pkg-tools   117
ii  python3   3.9.2-3
ii  python3-pastescript   2.0.2-4
ii  python3-swift 2.26.0-10
ii  rsync 3.2.3-4
ii  swift 2.26.0-10
ii  uwsgi-plugin-python3  2.0.19.1-6

Versions of packages swift-container recommends:
pn  swift-drive-audit  

swift-container suggests no packages.

-- Configuration Files:
/etc/swift/container-reconciler.conf [Errno 13] Permission denied: 
'/etc/swift/container-reconciler.conf'
/etc/swift/container-server.conf [Errno 13] Permission denied: 
'/etc/swift/container-server.conf'
/etc/swift/internal-client.conf [Errno 13] Permission denied: 
'/etc/swift/internal-client.conf'
/etc/swift/swift-container-server-uwsgi.ini [Errno 13] Permission denied: 
'/etc/swift/swift-container-server-uwsgi.ini'

-- no debconf information

Bug#989562: apache2: CVE-2021-31618: NULL pointer dereference on specially crafted HTTP/2 request

[Yadd]

Le 08/06/2021 à 10:51, Yadd a écrit :
> Le 08/06/2021 à 08:25, Yadd a écrit :
>> Le 08/06/2021 à 07:58, Yadd a écrit :
>>> Le 07/06/2021 à 17:34, Salvatore Bonaccorso a écrit :
 Source: apache2
 Version: 2.4.47-1
 Severity: grave
 Tags: security upstream
 Justification: user security hole
 X-Debbugs-Cc: car...@debian.org, Debian Security Team 
 

 Hi,

 The following vulnerability was published for apache2.

 CVE-2021-31618[0]:
 | httpd: NULL pointer dereference on specially crafted HTTP/2 request

 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-31618
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31618
 [1] 
 https://github.com/apache/httpd/commit/a4fba223668c554e06bc78d6e3a88f33d4238ae4
 [2] 
 https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2021-31618

 Please adjust the affected versions in the BTS as needed.

 Regards,
 Salvatore
>>>
>>> Hi all,
>>>
>>> I can't import the whole patch for Bullseye since it is written for
>>> 2.4.47. I think the best solution is to import the whole http2 module in
>>> Bullseye. This gives the attached patch
>>>
>>> Cheers,
>>> Yadd
>>
>> We can also fix this for Buster using the same way (we did it previously
>> for 2.4.46). Here is the debdiff
> 
> Update for Buster

I as wrong for both Bullseye and Buster: we can't import HTTP2 from
2.4.28 (too intrusive: SSL stack changed)

So I'll try to patch Apache but it seems not easy to do...

Cheers (and sorry),
Yadd

Bug#989586: firefox-esr: Letras borradas no jornal digital da Folha de São Paulo.

[Flávio Pimentel]

Package: firefox-esr
Version: 78.10.0esr-1
Severity: normal
X-Debbugs-Cc: flaw...@tutanota.com

Dear Maintainer,

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

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

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


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-12
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.2-0+deb11u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-5
ii  libgtk2.0-02.24.33-2
ii  pulseaudio 14.2-2

-- no debconf information

Bug#988046: bind9: does not honor CPPFLAGS

[Emilio Pozuelo Monfort]

On 08/05/2021 20:43, Ondřej Surý wrote:

Emilio,

could you please post this to the upstream gitLab.isc.org? Ping me when you 
create the account, I will have to bump the project limit, so you can fork.

I would be happy to merge this upstream.


Thanks! Can you apply the attached patch? I'd prefer to not create that extra 
account if I don't have to, but if it's somehow required then I can do it.



Fortunately, I’ve already changed the build system to use automake in the 
development branch, but it was quite an effort, so I didn’t make it in time for 
9.16, but the next stable (9.18) will be pretty standard.


Nice!

Cheers,
Emilio
>From 6748327732af53ee2dd6660a34bac5f15f73f812 Mon Sep 17 00:00:00 2001
From: Emilio Pozuelo Monfort 
Date: Tue, 8 Jun 2021 12:16:41 +0200
Subject: [PATCH] Honor CPPFLAGS

---
 make/rules.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/make/rules.in b/make/rules.in
index 5dd9130062..ac214fba17 100644
--- a/make/rules.in
+++ b/make/rules.in
@@ -105,6 +105,7 @@ install uninstall clean distclean maintainer-clean doc docclean man manclean::
 
 CC = 		@CC@
 CFLAGS =	@CFLAGS@
+CPPFLAGS =	@CPPFLAGS@
 LDFLAGS =	@LDFLAGS@
 STD_CINCLUDES =	@STD_CINCLUDES@
 STD_CDEFINES =	@STD_CDEFINES@
@@ -160,7 +161,7 @@ ALWAYS_DEFINES = @ALWAYS_DEFINES@
 ALWAYS_WARNINGS =
 
 ALL_CPPFLAGS = \
-	${ALWAYS_INCLUDES} ${CINCLUDES} ${STD_CINCLUDES} \
+	${CPPFLAGS} ${ALWAYS_INCLUDES} ${CINCLUDES} ${STD_CINCLUDES} \
 	${ALWAYS_DEFINES} ${CDEFINES} ${STD_CDEFINES}
 
 ALL_CFLAGS = ${EXT_CFLAGS} ${ALL_CPPFLAGS} ${CFLAGS} \
-- 
2.30.2

Bug#989599: upgrade issue: apt: fails to upgrade guile-2.2-libs from buster to bullseye

[Andreas Beckmann]

Followup-For: Bug #989599

Let's start the debian-release@ discussion here and decide which package
needs to get unblocked later ;-) We can turn this into an unblock bug
then.

This issue shows up e.g. on all (at least most) upgrade paths where 'cron'
was installed.


Andreas

Bug#989601: ITP: vulkan-volk -- Meta-loader for Vulkan API

[Dylan Aïssi]

Package: wnpp
Owner: Dylan Aïssi 
Severity: wishlist

Package name: vulkan-volk
URL: https://github.com/zeux/volk
License: MIT
Description: Meta-loader for Vulkan API
 Volk allows you to dynamically load entrypoints required to use Vulkan
 without linking to vulkan-1.dll or statically linking Vulkan loader.
 Additionally, volk simplifies the use of Vulkan extensions by automatically
 loading all associated entrypoints. Finally, volk enables loading Vulkan
 entrypoints directly from the driver which can increase performance by
 skipping loader dispatch overhead.

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Sebastiaan Couwenberg]

On 6/8/21 11:56 AM, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> 
> Let's start with the debian-release@ discussion here, this may be turned
> into an unblock request later. 
> 
> On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder  wrote:
>> One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a
>> Breaks: libgdal20 (< 2.5.0~), but the libgdal20 in Buster is 2.4.0,
>> and postgresql-11-postgis-2.5 depends on that.  libgdal28 depends on
>> gdal-data (>=3.2.1+dfsg-1).  To me it looks like there's no way to
>> keep postgresql-11-postgis-2.5 around if anything that depends on
>> libgdal28 (postgis, libopencv-imgcodecs4.5, ...) gets installed.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988722#31
> 
> gdal can rename gdal-data to gdal3-data, build with
> --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
> Thus libgdal20 + gdal-data from buster should be co-installable with
> libgdal28 + gdal3-data from bullseye and survive the upgrade if needed.
> 
> A patch doing this is attached, I'm now testing the upgrade paths
> (along the introduction of the libhdf5*-103 metapackages).
> 
> A good gdal bug to reuse would be #986975
> 
> Updating gdal may be a bit more tricky, because testing has 3.2.1 while
> sid has 3.2.2.

gdal won't be updated in unstable before the bullseye release as
mentioned in #986975.

You don't need to worry about the old postgis, using pg_upgradecluster
for postgis databases is not supported. PostGIS databases need to be
recreated after the distribution upgrade or hacks need to be used, this
is nothing new (but hopefully the bookworm distribution upgrade will be
better if it also has postgis 3.x).

Please spend your time on other more deserving packages.

Kind Regards,

Bas

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

Bug#989588: firefox-esr: https://acervo.folha.com.br/digital/leitor.do?numero=49552 (Letters blurred when zoomed by 200%.)

[Flávio Pimentel]

Package: firefox-esr
Version: 78.10.0esr-1
Severity: normal
X-Debbugs-Cc: flaw...@tutanota.com

Dear Maintainer,

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

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

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


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-12
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.2-0+deb11u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-5
ii  libgtk2.0-02.24.33-2
ii  pulseaudio 14.2-2

-- no debconf information

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Andreas Beckmann]

On 08/06/2021 12.22, Sebastiaan Couwenberg wrote:

Please spend your time on other more deserving packages.


I'm not caring that much about postgis but about getting clean upgrade 
paths if hdf5 and or gdal are involved because of the (transitive) 
non-co-installability of libhdf5*-103/libhdf5*-103-1 and 
libgdal20/libgdal28 which sometimes result in partial upgrades (keeping 
buster versions installed while packages could be upgraded to bullseye) 
or unwanted removals (removing the package rather than upgrading it to 
the bullseye version).


Andreas

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Gilles Filippini]

Andreas Beckmann a écrit le 08/06/2021 à 11:57 :

On 08/06/2021 08.27, Andreas Beckmann wrote:
Or, wait, easier: we can reintroduce metapackages libhdf5*-103 
depending on libhdf5*-103-1 and all the other packages containing 
libraries that were in the merged package in buster.



I actually like that solution and will try to come up with a patch ;-)


That could to the trick, indeed.


Here it is. Now testing upgrades ...


Yes please.

There were some new symbols ... but they appeared independently of my 
changes (I built in bullseye, not sid, in case it does matter).


OK.

This patch shouldn't close the bug as it only allows for a tedious 
workaround (installing back postgresql-11-postgis-2.5 from buster).


But the actual bug will still need to be addressed: postgis requires 
previous runtime to be able to migrate data.


Best,

_g.

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Sebastiaan Couwenberg]

On 6/8/21 12:42 PM, Gilles Filippini wrote:
> But the actual bug will still need to be addressed: postgis requires
> previous runtime to be able to migrate data.

That's an upstream issue, which they don't take very seriously. Some
upstream developers don't like the status quo either, hence the change
in PostGIS 3.0 to drop the minor version to ease this issue somewhat.
But they haven't committed to resolving it entirely.

As I've stated many times now, PostGIS databases need to be recreated
after distribution upgrades or hacks need to be used like they always
have. This is not something new, and not something that will be
addressed in the postgis package.

Kind Regards,

Bas

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

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Sebastian Ramacher]

On 2021-06-08 11:57:13, Andreas Beckmann wrote:
> On 08/06/2021 08.27, Andreas Beckmann wrote:
> > Or, wait, easier: we can reintroduce metapackages libhdf5*-103 depending
> > on libhdf5*-103-1 and all the other packages containing libraries that
> > were in the merged package in buster.
> 
> > I actually like that solution and will try to come up with a patch ;-)
> 
> Here it is. Now testing upgrades ...
> There were some new symbols ... but they appeared independently of my
> changes (I built in bullseye, not sid, in case it does matter).

Thanks Andreas! Once that tests are done and the packages was uploaded,
please let me know so that I can add the appropriate hints on the
release team side.

FWIW, the symbol is a template instantiation of a function from the
standard library and should be marked as optional.

Cheers

> 
> Andreas

> diff -Nru hdf5-1.10.6+repack/debian/changelog 
> hdf5-1.10.6+repack/debian/changelog
> --- hdf5-1.10.6+repack/debian/changelog   2020-04-24 20:00:42.0 
> +0200
> +++ hdf5-1.10.6+repack/debian/changelog   2021-06-08 08:57:04.0 
> +0200
> @@ -1,3 +1,18 @@
> +hdf5 (1.10.6+repack-2.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Reintroduce libhdf5-103, libhdf5-cpp-103, libhdf5-openmpi-103,
> +libhdf5-mpich-103 as metapackages depending on the individual library
> +packages that were bundled under these names in buster. This is a
> +workaround for upgrade issues caused by libhdf5-103 (in buster) and
> +libhdf5-103-1 (in bullseye) not being co-installable.  (Closes: #988722)
> +The metapackages cannot depend on libhdf5{,-openmpi,-mpich}-fortran100
> +because these had the SOVERSION bumped from 100 to 102, but luckily there
> +are no known users of these libraries in buster.
> +  * Add a new symbol to libhdf5*-cpp-103-1.symbols.
> +
> + -- Andreas Beckmann   Tue, 08 Jun 2021 08:57:04 +0200
> +
>  hdf5 (1.10.6+repack-2) unstable; urgency=medium
>  
>* Default plugindir per flavor
> diff -Nru hdf5-1.10.6+repack/debian/control hdf5-1.10.6+repack/debian/control
> --- hdf5-1.10.6+repack/debian/control 2020-04-24 20:00:42.0 +0200
> +++ hdf5-1.10.6+repack/debian/control 2021-06-08 08:57:04.0 +0200
> @@ -28,8 +28,8 @@
>  Depends: ${shlibs:Depends},
>   ${misc:Depends}
>  Pre-Depends: ${misc:Pre-Depends}
> -Breaks: libhdf5-103
> -Replaces: libhdf5-103
> +Breaks: libhdf5-103 (<< 1.10.5)
> +Replaces: libhdf5-103 (<< 1.10.5)
>  Description: HDF5 C runtime files - serial version
>   Hierarchical Data Format 5 (HDF5) is a file format and library for
>   storing scientific data.  HDF5 was designed and implemented to address
> @@ -88,14 +88,35 @@
>   This package contains the high level Fortran API runtime files for serial
>   platforms.
>  
> +Package: libhdf5-103
> +Architecture: any
> +Multi-Arch: same
> +Section: libs
> +Depends: libhdf5-103-1 (= ${binary:Version}),
> +#libhdf5-fortran-102 (= ${binary:Version}),
> + libhdf5-hl-100 (= ${binary:Version}),
> + libhdf5-hl-fortran-100 (= ${binary:Version}),
> + ${misc:Depends}
> +Description: HDF5 C runtime files - serial version (metapackage)
> + Hierarchical Data Format 5 (HDF5) is a file format and library for
> + storing scientific data.  HDF5 was designed and implemented to address
> + the deficiencies of HDF4.x. It has a more powerful and flexible data
> + model, supports files larger than 2 GB, and supports parallel I/O.
> + .
> + This package contains the C runtime files for serial platforms.
> + .
> + This metapackage helps upgrading from the single package bundling
> + multiple libraries in buster to the individiual library packages in
> + bullseye. It can be safely removed.
> +
>  Package: libhdf5-cpp-103-1
>  Architecture: any
>  Multi-Arch: same
>  Section: libs
>  Depends: ${shlibs:Depends},
>   ${misc:Depends}
> -Breaks: libhdf5-cpp-103
> -Replaces: libhdf5-cpp-103
> +Breaks: libhdf5-cpp-103 (<< 1.10.5)
> +Replaces: libhdf5-cpp-103 (<< 1.10.5)
>  Description: HDF5 - C++ runtime files - serial version
>   Hierarchical Data Format 5 (HDF5) is a file format and library for
>   storing scientific data.  HDF5 was designed and implemented to address
> @@ -122,6 +143,25 @@
>   This package contains the high level C++ API runtime files for serial
>   platforms.
>  
> +Package: libhdf5-cpp-103
> +Architecture: any
> +Multi-Arch: same
> +Section: libs
> +Depends: libhdf5-cpp-103-1 (= ${binary:Version}),
> + libhdf5-hl-cpp-100 (= ${binary:Version}),
> + ${misc:Depends}
> +Description: HDF5 - C++ runtime files - serial version (metapackage)
> + Hierarchical Data Format 5 (HDF5) is a file format and library for
> + storing scientific data.  HDF5 was designed and implemented to address
> + the deficiencies of HDF4.x. It has a more powerful and flexible data
> + model, supports files larger than 2 GB, and supports parallel I/O.
> + .
> + This package contains the C++ runtime files for seri

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Michael Biebl]

Am 01.06.21 um 17:26 schrieb Matt Corallo:

The above command paste should basically do it, eg install lxc, then 
`lxc-create --name fuzzer -t download` to create a (debian) container, 
then install sshd inside of it via apt, then run the `systemd-run --user 
-p "Delegate=yes" --unit=fuzzer -- lxc-start --name fuzzer -- 
/usr/sbin/sshd -D` command to spawn it, then log out of the ssh session 
which spawned it. There's likely some network configuration which needs 
to happen in between but I don't know off-hand how to set it up without 
public IPs for things.


I assume this means you run lxc-start as unprivileged user?
This requires additional configuration. At least I only get


lxc-create: fuzzer: confile.c: parse_line: 2664 Invalid argument - Unknown configuration 
key "lxc.id_map"
lxc-create: fuzzer: parse.c: lxc_file_for_each_line_mmap: 131 Failed to parse config file 
"/home/michael/.config/lxc/default.conf" at line "lxc.id_map = u 0 951968 65536"
lxc-create: fuzzer: conf.c: userns_exec_mapped_root: 4489 No uid mapping for 
container root
lxc-create: fuzzer: lxccontainer.c: do_storage_create: 1292 Error chowning 
"/home/michael/.local/share/lxc/fuzzer/rootfs" to container root
lxc-create: fuzzer: conf.c: suggest_default_idmap: 4811 You must either run as 
root, or define uid mappings
lxc-create: fuzzer: conf.c: suggest_default_idmap: 4812 To pass uid mappings to 
lxc-create, you could create
lxc-create: fuzzer: conf.c: suggest_default_idmap: 4813 
~/.config/lxc/default.conf:
lxc-create: fuzzer: conf.c: suggest_default_idmap: 4814 lxc.include = 
/etc/lxc/default.conf
lxc-create: fuzzer: conf.c: suggest_default_idmap: 4815 lxc.idmap = u 0 951968 
65536
lxc-create: fuzzer: conf.c: suggest_default_idmap: 4816 lxc.idmap = g 0 951968 
65536
lxc-create: fuzzer: lxccontainer.c: do_lxcapi_create: 1871 Failed to create 
(none) storage for fuzzer
lxc-create: fuzzer: tools/lxc_create.c: main: 319 Failed to create container 
fuzzer



Do you have a more minimal reproducer that doesn't involve lxc?



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Michael Biebl]

Am 01.06.21 um 17:26 schrieb Matt Corallo:
lxc-start --name fuzzer -- 
/usr/sbin/sshd -D` command to spawn it, then log out of the ssh session 


What's the output of
systemctl --user status fuzzer.service
systemctl --user show fuzzer.service

and loginctl user-status 1000
after you've logged out as 1000




OpenPGP_signature
Description: OpenPGP digital signature

Bug#925961: segfault in libdovecot-storage (mail_set_critical) at unknown circumstances

[Simon Josefsson]

Version: 1:2.3.4.1-5+deb10u6

Hi!  On May 18, 19 and 24 I saw repeated crashes that looked similar to
the ones reported here before.  Syslog content and one backtrace below.
I haven't seen the problem since then.  I don't know what kind of device
this was.  Note that the connection was authenticated correctly.

/Simon

root@uggla:~# coredumpctl info 30625
   PID: 30625 (imap)
   UID: 115 (dovmail)
   GID: 122 (dovmail)
Signal: 11 (SEGV)
 Timestamp: Mon 2021-05-24 19:14:30 UTC (2 weeks 0 days ago)
  Command Line: dovecot/imap postlogin
Executable: /usr/lib/dovecot/imap
 Control Group: /system.slice/dovecot.service
  Unit: dovecot.service
 Slice: system.slice
   Boot ID: 246f0c28fe2d43e5ab7d0df6fadb97e9
Machine ID: 91d76afe2fc543e49fa0c766b415c23c
  Hostname: uggla
   Storage: 
/var/lib/systemd/coredump/core.imap.115.246f0c28fe2d43e5ab7d0df6fadb97e9.30625.162188367000.lz4
   Message: Process 30625 (imap) of user 115 dumped core.

Stack trace of thread 30625:
#0  0x7f2957682bd0 mail_set_critical 
(libdovecot-storage.so.0)
#1  0x7f29576add65 maildir_transaction_save_commit_pre 
(libdovecot-storage.so.0)
#2  0x7f295770783b n/a (libdovecot-storage.so.0)
#3  0x7f2957721f30 mail_index_transaction_commit_full 
(libdovecot-storage.so.0)
#4  0x7f2957707d91 index_transaction_commit 
(libdovecot-storage.so.0)
#5  0x7f29576e4277 n/a (libdovecot-storage.so.0)
#6  0x7f295768506b mailbox_transaction_commit_get_changes 
(libdovecot-storage.so.0)
#7  0x55f4f315aaaf n/a (imap)
#8  0x55f4f3167dc0 command_exec (imap)
#9  0x55f4f31663f2 n/a (imap)
#10 0x55f4f3166494 n/a (imap)
#11 0x55f4f3166845 client_handle_input (imap)
#12 0x55f4f3166d6e client_input (imap)
#13 0x7f295758cbef io_loop_call_io (libdovecot.so.0)
#14 0x7f295758e1e6 io_loop_handler_run_internal 
(libdovecot.so.0)
#15 0x7f295758cc8c io_loop_handler_run (libdovecot.so.0)
#16 0x7f295758cdf0 io_loop_run (libdovecot.so.0)
#17 0x7f295750d123 master_service_run (libdovecot.so.0)
#18 0x55f4f3158bf5 main (imap)
#19 0x7f29572f709b __libc_start_main (libc.so.6)
#20 0x55f4f3158d8a _start (imap)

May 24 17:57:10 uggla dovecot: imap-login: Login: user=, 
method=CRAM-MD5, rip=2001:9b1:41ac:ff00:60cf:be83:d196:9c4f, 
lip=2001:9b1:8633::107, mpid=30625, TLS, TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits)
...
May 24 19:14:30 uggla kernel: [295182.948459] show_signal_msg: 2 callbacks 
suppressed
May 24 19:14:30 uggla kernel: [295182.948467] imap[30625]: segfault at 20 ip 
7f2957682bd0 sp 7fff90234bd0 error 4 in 
libdovecot-storage.so.0.0.0[7f295766+d1000]
May 24 19:14:30 uggla kernel: [295182.948481] Code: 00 00 48 89 44 24 18 48 8d 
44 24 30 c7 44 24 14 30 00 00 00 48 89 44 24 20 e8 bc 44 fe ff 48 8d 74 24 10 
48 89 ef 89 44 24 0c  43 20 02 74 4a e8 d5 2d fe ff 48 8b 3b 48 8d \
35 22 04 0b 00 48
May 24 19:14:30 uggla systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
May 24 19:14:30 uggla systemd[1]: Started Process Core Dump (PID 20806/UID 0).
May 24 19:14:30 uggla dovecot: 
imap(simon)<30625>: Fatal: master: 
service(imap): child 30625 killed with signal 11 (core dumped)
May 24 19:14:30 uggla systemd-coredump[20807]: Process 30625 (imap) of user 115 
dumped core.#012#012Stack trace of thread 30625:#012#0  0x7f2957682bd0 
mail_set_critical (libdovecot-storage.so.0)#012#1  0x7f29576add65 mai\
ldir_transaction_save_commit_pre (libdovecot-storage.so.0)#012#2  
0x7f295770783b n/a (libdovecot-storage.so.0)#012#3  0x7f2957721f30 
mail_index_transaction_commit_full (libdovecot-storage.so.0)#012#4  
0x7f2957707d91 \
index_transaction_commit (libdovecot-storage.so.0)#012#5  0x7f29576e4277 
n/a (libdovecot-storage.so.0)#012#6  0x7f295768506b 
mailbox_transaction_commit_get_changes (libdovecot-storage.so.0)#012#7  
0x55f4f315aaaf n/a \
(imap)#012#8  0x55f4f3167dc0 command_exec (imap)#012#9  0x55f4f31663f2 
n/a (imap)#012#10 0x55f4f3166494 n/a (imap)#012#11 0x55f4f3166845 
client_handle_input (imap)#012#12 0x55f4f3166d6e client_input (imap)#01\
2#13 0x7f295758cbef io_loop_call_io (libdovecot.so.0)#012#14 
0x7f295758e1e6 io_loop_handler_run_internal (libdovecot.so.0)#012#15 
0x7f295758cc8c io_loop_handler_run (libdovecot.so.0)#012#16 
0x7f295758cdf0 io_loop\
_run (libdovecot.so.0)#012#17 0x7f295750d123 master_service_run 
(libdovecot.so.0)#012#18 0x55f4f3158bf5 main (imap)#012#19 
0x7f29572f709b __libc_start_main (libc.so.6)#012#20 0x55f4f3158d8a 
_start (

Bug#989486: RFS: python-click-log/0.3.2-1 -- Logging integration for Click - Python 3.x

[Fabrice Bauzac-Stehly]

Nilesh Patra  writes:

> * The pristine tar contained .tar.gz.*, it should
> instead contain .orig.tar.gz for origtargz both for the sake of
> consistency and for origtargz to run fine

Oops, OK, I have just re-run pristine-tar on the .orig file and
committed.

> * We are in freeze time, and a new version upload unless absolutely
> necessary isn't appropriate[2]. This package does not seem to have any
> (RC) bug or affecting any package that a version bump would be
> desired.
>
> Hence, this should be uploaded after bullseye release. Feel free to
> ping me then, and I'll happily sponsor. Also, please take a look at my
> commits in salsa.
>
> [2]: https://release.debian.org/testing/freeze_policy.html

I'm fine with waiting.  After the freeze, I think it will be ready for
uploading (I don't want to spam mentors.d.o during the freeze).

Thanks a lot for your help!

Best regards

-- 
Fabrice Bauzac-Stehly
PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6

Bug#976148: lxml: enable test suite during build

[Emilio Pozuelo Monfort]

On 19/05/2021 10:01, Matthias Klose wrote:

On 11/30/20 2:36 PM, Emilio Pozuelo Monfort wrote:

Source: lxml
Version: 4.6.1-1
Severity: normal
Tags: patch

Hi,

The attached patch runs the test suite for each supported python
version. It'd be good to do that to ensure lxml's funcionality.
The patch needs to do an in-tree build so that etree.so can be found.
I couldn't find a workaround for that but if that's a blocker I could
investigate further to avoid that in-tree build.


do we get that "for free" when using pybuild for the build?


pybuild also does out of tree builds (for py3.* and for py3.*-dbg). The same 
problem arises, I somehow can't get the out of tree etree.so picked up (setting 
up PYTHONPATH), perhaps because some files are being read from src/lxml/*.py 
(package lxml), while others (etree.so) need to be read from 
.pybuild/cpython3_3.9/build/lxml/ (also package lxml).


This seems to work:

cp .pybuild/cpython3_3.9/build/lxml/etree.cpython-39-x86_64-linux-gnu.so 
src/lxml/etree.so
cp .pybuild/cpython3_3.9/build/lxml/objectify.cpython-39-x86_64-linux-gnu.so 
src/lxml/objectify.so


python3.9 ./test.py
Skipping tests in lxml.cssselect - external cssselect package is not installed
Comparing with ElementTree 1.3.0

TESTED VERSION: 4.6.1
Python:   sys.version_info(major=3, minor=9, micro=2, 
releaselevel='final', serial=0)

lxml.etree:   (4, 6, 1, 0)
libxml used:  (2, 9, 10)
libxml compiled:  (2, 9, 10)
libxslt used: (1, 1, 34)
libxslt compiled: (1, 1, 34)
FS encoding:  utf-8
Default encoding: utf-8
Max Unicode:  1114111

--
Ran 1938 tests in 3.742s


...but it's still somewhat hacky. Perhaps more modules need to be listed in 
setupinfo.py, and not just the compiled ones, so that src/*.py end up in 
.pybuild/cpython3_3.9/build/ and we don't have compiled and non-compiled modules 
split across two dirs? Or maybe there's something else I have missed that can be 
done to load the extension.


Cheers,
Emilio

Bug#989602: dpkg-deb overwrites symlinks with directories

[Marc Haber]

Package: dpkg
Version: 1.20.9
Severity: minor

Hi,

dpkg-deb -x package.deb happily overwrites symlinks on the filesystems
with directories. I don't know whether this is desired behavior.

tl;dr:
For some reason, a system of mine ended up without
/sbin/start-stop-daemon. Not knowing about dpkg --force-bad-path, I was
unable to use dpkg to repair dpkg because dpkg refuses work if there is
no /sbin/start-stop-daemon.

dpkg-deb -x /var/cache/apt/archives/dpkg*.deb / happily replaced the
/sbin => /usr/sbin with an /sbin directory containing only
/sbin/start-stop-daemon.

Wouldn't it be nicer to have dpkg follow symlinks before creating
directories in the times of usrmerge?

Severity: minor because dpkg --force-bad-path --install dpkg*.deb works.

Greetings
Marc


-- Package-specific info:

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

Kernel: Linux 5.12.9-zgws1 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
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.31-12
ii  liblzma5 5.2.5-2
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

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

-- no debconf information

Bug#989593: installation report Raspberry Pi 4 UEFI

[Marc Haber]

On Tue, Jun 08, 2021 at 11:17:51AM +0200, Cyril Brulebois wrote:
> Marc Haber  (2021-06-08):
> > I followed the instructions given on
> > https://www.raspberrypi.org/forums/viewtopic.php?t=282839
> > to install Debian on a Raspberry Pi using the UEFI firmware
> > available for the raspi.
> > 
> > This involves unpacking the official Debian 11 image into an ESP
> > partition on an USB medium and using the Rasberry Pi UEFI firmware
> > to boot the installer via UEFI => grub => Linux. Once the
> > installe has started, this feels 100 % like a standard Debian
> > installation.
> 
> Fun!

Yes!

> > I experienced the following issues:
> > 
> > "Detecting Hardware" complains about missing firmware. I guess
> > that's Wifi related, since the Wifi Interface doesn't work in the
> > installed system and the 1000Base-TX interface works fine without.
> 
> AFAICR (I'll get back to that soon enough) you should get a message
> indicating which files were expected, so that you don't have to guess.

The Raspi 4 has both Wifi and Ethernet interfaces named brcmsomething,
so it's still kind of guessing, but I have verified in the mean time
that it's actually really the Wifi firmware.

> > Requesting German keyboard layout does not work in the beginning of
> > installation, domain name and user name configuration still happens
> > with the default US keyboard layout. Later, when configuring the
> > network mirror, the keyboard layout has been changed to the requested
> > german layout. I guess this happens during base system installation.
> 
> Was that with the text or graphical installer?

Text installer ("expert"). I have used the graphical installer just a
handful of times in two decades.

Since my default domain types differently with US and DE keyboard, I
guess this might be an actual regression, I would have noticed this in
earlier versions of the installer.

> > For very strange reasons, the installed system ends up without
> > /sbin/start-stop-daemon despite the dpkg package being in state "ii".
> > This is reproducible. In the installer, I see a temporary diversion of
> > /sbin/start-stop-daemon, but in the installed system, dpkg-divert
> > --list doesn't show that.
> > 
> > /var/lib/dpkg/diversions-old has those three lines:
> > /sbin/start-stop-daemon
> > /sbin/start-stop-daemon.REAL
> > :
> > 
> > There is no /sbin/start-stop-daemon.REAL though.
> 
> A quick grep across our source packages show 3 possibilities:
>  - debootstrap
>  - debian-installer-utils
>  - apt-setup (code apparently copied from d-i-utils until some clean-up
>happens, which never did)
> 
> > And, the installed system does neither have /var/log/installer nor
> > /var/log/debian-installer. This is also reproducible :-(   Where would
> > I find the files that get copied to /target/var/log/installer in the
> > still running installer?
> 
> Simply /var/log/syslog for the main log. Other files are mentioned
> there:
>   
> https://salsa.debian.org/installer-team/installation-report/-/blob/master/debian/installation-report.postinst

Is there anything you need from me to go on?

Greetings
Marc

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

Bug#971530: dnspython 2.x breaks all of OpenStack

[Filippo Giunchedi]

On Tue, Jun 01, 2021 at 10:30:38AM +, Filippo Giunchedi wrote:
> Do you have pointers to these fixes I could look at? I ran into this bug while
> testing Swift on Bullseye, specifically container-reconciler + 
> memcache_servers
> with hostnames doesn't seem to work for me (while using ip addresses does 
> work).

FTR the specific bug for swift is now #989600

Bug#987764: devscripts: [bts] bts bugs is racy

[Romain Porte]

Hello,

On Thu, 29 Apr 2021 09:18:59 +0200 Tobias Frost  wrote:

> Package: devscripts
> Version: 2.21.1
> Severity: normal
>
> bts bugs does (at least here) not work with (an already opened*) firefox,
> as the generated temporariy file is already deleted when firefox tries to
> open it.
> A workaround is to not delete the temporary file by saying UNLINK => 0 in
> line 3843 of /usr/bin/bts, but that is not a proper fix…
>
> (* Not tested if firefox was closed before.)

I can reproduce this bug locally. If firefox is closed, then the bug
will display fine, as the temporary file will be created before firefox
is opened, and deleted when firefox is closed. However, when already
running a firefox instance, the temporary file seems to be deleted early.

I think this is because calling `firefox` when another instance is
running will return immediatly (and open a new tab in the existing
instance). The devscript probably deletes the temporary file directly
upon program return.

Best regards,

Romain.

Bug#949336: integritysetup: HMAC(SHA256) key truncated to 106/114bytes in standalone mode

[Guilhem Moulin]

Hi Jonas!

On Mon, 07 Jun 2021 at 21:54:50 +0200, Jonas Meurer wrote:
>> I'm not sure how what the best way to proceed for Bullseye.  Jonas,
>> what's your take about this?
> 
> First sorry for not responding earlier. I simply missed this mail in my
> backlog :-/

No worries!

> I would suggest to take the most pragmatic approach and don't care about
> this corner case. Given that, no stable release ever shipped with a faulty
> integritysetup and that I would expect every user who ran unstable/testing
> back when keys hat 106 bytes to still run unstable/testing, let's just keep
> it the way it is, no?

Great, then we're on the same page :-)  That's a good summary, AFAIK the
only report so far is this bug from nbf who is using a 106 bytes
truncation, and with that key size Bullseye's integritysetup isn't more
broken than Buster's.  So let's skip this for 11.0 and maybe revisit
later via s-p-u if needs be.

Thanks for the feedback!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

[Jochen Sprickerhof]

Hi,

friendly ping on the sagemath issue as it will be dropped from testing 
on the 18., otherwise.
As far as I read there are a number of proposals (downgrade, ignore test 
results..) besides fixing the tests. I'm happy to help with this but 
leave it to the maintainers how to approach this.


Cheers Jochen

* Tobias Hansen  [2021-05-19 15:01]:

Hi,

On 5/18/21 8:25 PM, Jochen Sprickerhof wrote:


I think there are a number of problems:
- Tests not being executed due to the open file limit ("Killing test" in   the 
log). If you want to use the tests as an indicator if the build   works, you should make 
sure the all tests are executed, otherwise 200   tolerated failures is arbitrary.



I have been struggling with this for quite a while and I don't know how to fix 
it. It comes and goes and does not seem to affect vanilla upstream builds. This 
has impacted progress on the package since one cannot properly work on it when 
the test suite crashes. I tried asking upstream for help here and provided more 
details:

https://groups.google.com/g/sage-packaging/c/1G_3JiIcbvY



- I found a number of segfaults in the tests, like:
  sage -t --long --random-seed=0 src/sage/interfaces/singular.py  # Killed due 
to segmentation fault
- Looking at the amd64 log of the buildd:
  Error: 202 tests failed, up to 200 failures are tolerated
  Yes: 202 tests failed, up to 400 failures are tolerated for rerun
  Success: 192 tests failed, up to 200 failures are tolerated
  does that mean we ran the test twice and it passed the second time   cause 
there where 10 failures less? Can we be sure that this always   succeeds? 192 
is really close to 200.
- I still see cython: not found in the logs, so there are definitely   tests 
broken due to that. Maybe it makes sense to define tests which   are allowed to 
break and other which should succeed?



I agree, segfaults and the cython issue should be fixed. The number of failed 
tests always grows with time when dependencies change and sagemath is not 
adapted accordingly.

Best,

Tobias


signature.asc
Description: PGP signature

Bug#989589: Actually read/display is good now, but write was always wrong

[Christian Ehrhardt]

If you follow the discussion I linked when opening the bug as [3]
you'll find more.
But the TL;DR is that sgdisk/gdisk always (and still) write the
labels/names byte-swapped on s390x (or probably in general big
endian).

So I'd suggest to not revert the change, and instead wait for a fix to
the write code-path that then should be applied.

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#988781: hurfbuzz: please package harfbuzz-subset

[Mattia Rizzolo]

Hi Emilio,

thanks for reaching back.

On Tue, Jun 08, 2021 at 11:55:03AM +0200, Emilio Pozuelo Monfort wrote:
> > Could you please consider including it in the Debian packaging?
> 
> It's not packaged because the API was (maybe still is) unstable. From the 
> NEWS file:

I decided to ask upstream first:
https://github.com/harfbuzz/harfbuzz/issues/3012

> I think we can package it, as hopefully the API is (somewhat) stable now and
> we don't need transitions without SONAME changes (and with conflicting,
> renamed packages).
> 
> MRs welcome.

I'll open an MR against salsa/harfbuzz if I receive the go-ahead from
upstream, thank you.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#989589: Real fix just got merged

[Christian Ehrhardt]

FYI - at https://sourceforge.net/p/gptfdisk/code/merge-requests/26/ a
real fix for the underlying problem has been merged upstream.

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#989603: ocsinventory-server: Does not start after install

[Enrico Rossi]

Package: ocsinventory-server
Version: 2.8+dfsg1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: e.ro...@tecnobrain.com

Dear Maintainer,

after installing the package on a clean and dedicated server, following
the README.Debian file provided on:

Post-installation notes
---

Please note that after first installation, or after an upgrade, it's recommended
to call http://your_ocs_server/ocsreports/install.php ;

but the apache server does not start with the error:

[Tue Jun 08 11:35:37.412729 2021] [perl:error] [pid 589] Can't locate 
Apache/Ocsinventory/Plugins/Apache.pm in @INC (you may need to install the 
Apache::Ocsinventory::Plugins::Apache module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 
/usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 
/usr/local/lib/site_perl /etc/apache2) at (eval 13) line 1.\n
[Tue Jun 08 11:35:37.412792 2021] [perl:error] [pid 589] Can't load Perl module 
Apache::Ocsinventory::Plugins::Apache for server inventory.example.org:0, 
exiting...

Thanks for maintaining.
E.

-- 
GPG key: 4096R/5E0195FAF2133176 2010-10-19 Enrico Rossi 

Bug#909473: fstrim shows incorrect trimmed size after reboot

[Laurent Bigonville]

Control: tags -1 - moreinfo

Le 28/05/21 à 21:28, Salvatore Bonaccorso a écrit :

Control: tags -1 + moreinfo

Hi Laurent,

On Mon, Sep 24, 2018 at 01:37:01PM +0200, Laurent Bigonville wrote:

Package: src:linux
Version: 4.18.8-1
Severity: normal

Hi,

Not sure who to blame here, but when running fstrim -va it show the size
of the disk it has trimmed, if I'm running fstrim again it shows 0 for
all the disk.

If I reboot, and then run fstrim again it shows (almost) the same value
as the 1st time. All the disks have the discard option enabled, all fs
are ext4, except /boot which is ext2/

See the logs:

bigon@valinor:~$ journalctl -u fstrim.service
-- Logs begin at Sat 2018-09-08 12:48:02 CEST, end at Mon 2018-09-24 13:32:05 
CEST. --
sep 17 10:44:21 valinor systemd[1]: Starting Discard unused blocks...
sep 17 10:44:51 valinor fstrim[11186]: /var/cache/apt-cacher-ng : 930,1 MiB 
(975245312 octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/sbuild/build : 9,8 GiB 
(10463989760 octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/docker : 10 GiB (10713788416 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /home : 11,3 GiB (12105969664 octets) 
taillés
sep 17 10:44:51 valinor fstrim[11186]: /boot : 126,9 MiB (133014528 octets) 
taillés
sep 17 10:44:51 valinor fstrim[11186]: / : 8,6 GiB (9217847296 octets) taillés
sep 17 10:44:51 valinor systemd[1]: Started Discard unused blocks.
-- Reboot --
sep 24 10:12:35 valinor systemd[1]: Starting Discard unused blocks...
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/sbuild/build : 9,8 GiB 
(10455736320 octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/cache/apt-cacher-ng : 922,8 MiB 
(967565312 octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/docker : 11,4 GiB (12180299776 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /home : 11 GiB (11825807360 octets) 
taillés
sep 24 10:13:08 valinor fstrim[26936]: /boot : 126,9 MiB (133008384 octets) 
taillés
sep 24 10:13:08 valinor fstrim[26936]: / : 8,6 GiB (9219850240 octets) taillés
sep 24 10:13:08 valinor systemd[1]: Started Discard unused blocks.
-- Reboot --
sep 24 13:20:54 valinor systemd[1]: Starting Discard unused blocks...
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/docker : 11,4 GiB (12181008384 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/cache/apt-cacher-ng : 793,9 MiB 
(832487424 octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /home : 10,8 GiB (11617431552 octets) 
taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/sbuild/build : 9,8 GiB 
(10463989760 octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /boot : 126,9 MiB (133008384 octets) 
taillés
sep 24 13:21:28 valinor fstrim[6751]: / : 8,6 GiB (9211752448 octets) taillés
sep 24 13:21:28 valinor systemd[1]: Started Discard unused blocks.
sep 24 13:32:05 valinor systemd[1]: Starting Discard unused blocks...
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/docker : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/cache/apt-cacher-ng : 0 B (0 octets) 
taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/libvirt : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /home : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/sbuild/build : 0 B (0 octets) 
taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/flatpak : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /boot : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: / : 0 B (0 octets) taillés
sep 24 13:32:05 valinor systemd[1]: Started Discard unused blocks.

There is definitely something boggus here

Is this still something you are able to reproduce this way with a
recent kernel?


Hello Salvatore,

Yes, just tested it now and  it's still happening with the kernel 
currently in unstable (5.10.40-1)

Bug#989604: libssl1.1: segfault on arm64 (M1) with some ciphers e.g. curl https://dl.yarnpkg.com

[David Scott]

Package: libssl1.1
Version: 1.1.1d-0+deb10u6
Severity: normal

Dear Maintainer,

This bug appears to be fixed by 1.1.1k-1 in testing. I couldn't spot it
in the issue tracker but thought I'd mention it just in case.

On my arm64 machine (Apple M1) if I run Debian buster (in a Linux container
inside a qemu VM) with 1.1.1d-0+deb10u6 *and* expose the host's CPUID to the
VM running the container i.e.

```
root@1a99ac25e4fd:/# cat /proc/cpuinfo
processor   : 0
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp 
asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit 
uscat ilrcpc flagm ssbs sb paca pacg dcpodp flagm2 frint
```

then this crashes:

```
root@1a99ac25e4fd:/# curl -vvv https://dl.yarnpkg.com
* Expire in 0 ms for 6 (transfer 0xfbedef30)
* Expire in 1 ms for 1 (transfer 0xfbedef30)
...
*   Trying 104.18.126.100...
* TCP_NODELAY set
* Expire in 149997 ms for 3 (transfer 0xfbedef30)
* Expire in 200 ms for 4 (transfer 0xfbedef30)
* Connected to dl.yarnpkg.com (104.18.126.100) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=San Francisco; O=Cloudflare, Inc.; 
CN=sni.cloudflaressl.com
*  start date: Aug 18 00:00:00 2020 GMT
*  expire date: Aug 18 12:00:00 2021 GMT
*  subjectAltName: host "dl.yarnpkg.com" matched cert's "*.yarnpkg.com"
*  issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0xfbedef30)
> GET / HTTP/2
> Host: dl.yarnpkg.com
> User-Agent: curl/7.64.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
Segmentation fault
```

Other URLs work fine.

The `curl` succeeds if I hide some of the CPUID flags e.g. by
pretending the system is a cortex-a57 (with `qemu -cpu cortex-a57`):
```
/ # cat /proc/cpuinfo
processor   : 0
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 fphp asimdhp cpuid 
dit
```

If I take a broken buster system and replace the `libcrypto.so.1.1` with
the one from testing, the bug is fixed.

So I think it's a bug in the buster version of libssl1.1, detecting some
CPU feature, misusing it and crashing. The bug appears to be fixed in
testing.

-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.25-linuxkit (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libssl1.1 depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10

libssl1.1 recommends no packages.

libssl1.1 suggests no packages.

-- no debconf information

Thanks for all your work!
David

Bug#989606: inkscape: package 2geom separately

[Mattia Rizzolo]

Source: inkscape
Version: 1.1-1
Severity: minor

Starting with 1.1 inkscape wants 2geom, a library developed by the
inkscape developers themselves, and also bundled within inkscape in case
it's not available system-wide.

For now I'm using the bundled version, but we should decouple it and use
a system-installed shared library instead.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#989603: ocsinventory-server: Does not start after install

[Enrico Rossi]

Hi,

looks like the:

/usr/share/perl5/Apache/Ocsinventory/Plugins/Apache.pm

file is missing. It was present in the old (buster) version.

E.

-- 
GPG key: 4096R/5E0195FAF2133176 2010-10-19 Enrico Rossi 

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Michael Biebl]

Control: tags -1 + unreproducible

So, I've been following the instructions in 
/usr/share/doc/lxc/README.Debian to allow unprivileged containers.


After that, I could successfully run a container. I used the command 
line as suggested in that README.Debian:


$ systemd-run --scope --quiet --user --property=Delegate=yes \
lxc-start -n mycontainer


Once I logged out, the systemd --user session was stopped including the 
container, which is expected, as ansgar wrote.


After enabling "linger" for that user, the systemd --user session was 
not stopped anymore after logging out and the container continued running.


I'm thus marking this bug report as unreproducible.

(note that the lxc maintainers recommend to use --scope with systemd-run)

Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Michael Biebl]

Am 08.06.21 um 16:19 schrieb Michael Biebl:

After enabling "linger" for that user, the systemd --user session was 
not stopped anymore after logging out and the container continued running.



# systemd-cgls
Control group /:
-.slice
├─user.slice 
│ ├─user-0.slice 
│ │ ├─session-1.scope 
│ │ │ ├─ 438 /bin/login -p --

│ │ │ ├─ 553 -bash
│ │ │ └─1440 systemd-cgls
│ │ └─user@0.service …
│ │   └─init.scope 
│ │ ├─534 /lib/systemd/systemd --user

│ │ └─535 (sd-pam)
│ └─user-1000.slice 
│   └─user@1000.service …
│ ├─app.slice 
│ │ └─run-rc9609178954b49f684f37595d92e5171.scope 
│ │   ├─lxc.monitor.mycontainer 
│ │   │ └─1242 [lxc monitor] /home/michael/.local/share/lxc mycontainer
│ │   └─lxc.payload.mycontainer 
│ │ ├─init.scope 
│ │ │ └─1248 /sbin/init
│ │ └─system.slice 
│ │   ├─networking.service 
│ │   │ └─1350 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /…
│ │   ├─systemd-journald.service 
│ │   │ └─1326 /lib/systemd/systemd-journald
│ │   ├─console-getty.service 
│ │   │ └─1394 /sbin/agetty -o -p -- \u --noclear --keep-baud console 1…
│ │   ├─system-container\x2dgetty.slice 
│ │   │ ├─container-getty@0.service 
│ │   │ │ └─1395 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/0 1…
│ │   │ ├─container-getty@2.service 
│ │   │ │ └─1397 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/2 1…
│ │   │ ├─container-getty@1.service 
│ │   │ │ └─1396 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/1 1…
│ │   │ └─container-getty@3.service 
│ │   │   └─1398 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/3 1…
│ │   ├─dbus.service 
│ │   │ └─1370 /usr/bin/dbus-daemon --system --address=systemd: --nofor…
│ │   └─systemd-logind.service 
│ │ └─1372 /lib/systemd/systemd-logind
│ └─init.scope 
│   ├─1182 /lib/systemd/systemd --user

│   └─1184 (sd-pam)
├─init.scope 
│ └─1 /sbin/init
└─system.slice 
  ├─lxc-net.service 
  │ └─492 dnsmasq --conf-file=/dev/null -u dnsmasq --strict-order --bind-interf…
  ├─systemd-udevd.service 
  │ └─232 /lib/systemd/systemd-udevd
  ├─cron.service 
  │ └─402 /usr/sbin/cron -f
  ├─systemd-journald.service 
  │ └─214 /lib/systemd/systemd-journald
  ├─ssh.service 
  │ └─457 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
  ├─ifup@enp1s0.service 
  │ └─449 /sbin/dhclient -4 -v -i -pf /run/dhclient.enp1s0.pid -lf /var/lib/dhc…
  ├─rsyslog.service 
  │ └─411 /usr/sbin/rsyslogd -n -iNONE

  ├─lxcfs.service …
  │ └─407 /usr/bin/lxcfs /var/lib/lxcfs
  ├─dbus.service 
  │ └─403 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile…
  ├─systemd-timesyncd.service 
  │ └─261 /lib/systemd/systemd-timesyncd
  ├─system-getty.slice 
  │ ├─getty@tty6.service 
  │ │ └─896 /sbin/agetty -o -p -- \u --noclear tty6 linux
  │ └─getty@tty2.service 
  │   └─1377 /sbin/agetty -o -p -- \u --noclear tty2 linux
  └─systemd-logind.service 
└─417 /lib/systemd/systemd-logind


# loginctl show-user michael
UID=1000
GID=1000
Name=michael
Timestamp=Tue 2021-06-08 16:08:20 CEST
TimestampMonotonic=280083967
RuntimePath=/run/user/1000
Service=user@1000.service
Slice=user-1000.slice
State=lingering
Sessions=
IdleHint=yes
IdleSinceHint=0
IdleSinceHintMonotonic=0
Linger=yes





OpenPGP_signature
Description: OpenPGP digital signature

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Michael Biebl]

Am 08.06.21 um 16:23 schrieb Michael Biebl:

Am 08.06.21 um 16:19 schrieb Michael Biebl:

After enabling "linger" for that user, the systemd --user session was 
not stopped anymore after logging out and the container continued 
running.



# systemd-cgls


Attaching output as file, to avoid it getting mangled.



# systemd-cgls
Control group /:
-.slice
├─user.slice 
│ ├─user-0.slice 
│ │ ├─session-1.scope 
│ │ │ ├─ 438 /bin/login -p --
│ │ │ ├─ 553 -bash
│ │ │ └─1440 systemd-cgls
│ │ └─user@0.service …
│ │   └─init.scope 
│ │ ├─534 /lib/systemd/systemd --user
│ │ └─535 (sd-pam)
│ └─user-1000.slice 
│   └─user@1000.service …
│ ├─app.slice 
│ │ └─run-rc9609178954b49f684f37595d92e5171.scope 
│ │   ├─lxc.monitor.mycontainer 
│ │   │ └─1242 [lxc monitor] /home/michael/.local/share/lxc mycontainer
│ │   └─lxc.payload.mycontainer 
│ │ ├─init.scope 
│ │ │ └─1248 /sbin/init
│ │ └─system.slice 
│ │   ├─networking.service 
│ │   │ └─1350 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /…
│ │   ├─systemd-journald.service 
│ │   │ └─1326 /lib/systemd/systemd-journald
│ │   ├─console-getty.service 
│ │   │ └─1394 /sbin/agetty -o -p -- \u --noclear --keep-baud console 1…
│ │   ├─system-container\x2dgetty.slice 
│ │   │ ├─container-getty@0.service 
│ │   │ │ └─1395 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/0 1…
│ │   │ ├─container-getty@2.service 
│ │   │ │ └─1397 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/2 1…
│ │   │ ├─container-getty@1.service 
│ │   │ │ └─1396 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/1 1…
│ │   │ └─container-getty@3.service 
│ │   │   └─1398 /sbin/agetty -o -p -- \u --noclear --keep-baud pts/3 1…
│ │   ├─dbus.service 
│ │   │ └─1370 /usr/bin/dbus-daemon --system --address=systemd: --nofor…
│ │   └─systemd-logind.service 
│ │ └─1372 /lib/systemd/systemd-logind
│ └─init.scope 
│   ├─1182 /lib/systemd/systemd --user
│   └─1184 (sd-pam)
├─init.scope 
│ └─1 /sbin/init
└─system.slice 
  ├─lxc-net.service 
  │ └─492 dnsmasq --conf-file=/dev/null -u dnsmasq --strict-order --bind-interf…
  ├─systemd-udevd.service 
  │ └─232 /lib/systemd/systemd-udevd
  ├─cron.service 
  │ └─402 /usr/sbin/cron -f
  ├─systemd-journald.service 
  │ └─214 /lib/systemd/systemd-journald
  ├─ssh.service 
  │ └─457 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
  ├─ifup@enp1s0.service 
  │ └─449 /sbin/dhclient -4 -v -i -pf /run/dhclient.enp1s0.pid -lf /var/lib/dhc…
  ├─rsyslog.service 
  │ └─411 /usr/sbin/rsyslogd -n -iNONE
  ├─lxcfs.service …
  │ └─407 /usr/bin/lxcfs /var/lib/lxcfs
  ├─dbus.service 
  │ └─403 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile…
  ├─systemd-timesyncd.service 
  │ └─261 /lib/systemd/systemd-timesyncd
  ├─system-getty.slice 
  │ ├─getty@tty6.service 
  │ │ └─896 /sbin/agetty -o -p -- \u --noclear tty6 linux
  │ └─getty@tty2.service 
  │   └─1377 /sbin/agetty -o -p -- \u --noclear tty2 linux
  └─systemd-logind.service 
└─417 /lib/systemd/systemd-logind

# loginctl show-user michael
UID=1000
GID=1000
Name=michael
Timestamp=Tue 2021-06-08 16:08:20 CEST
TimestampMonotonic=280083967
RuntimePath=/run/user/1000
Service=user@1000.service
Slice=user-1000.slice
State=lingering
Sessions=
IdleHint=yes
IdleSinceHint=0
IdleSinceHintMonotonic=0
Linger=yes


OpenPGP_signature
Description: OpenPGP digital signature

Bug#985094: [RFS] ITP: ortools -- Google Optimization Tools

[Romain Porte]

X-Debbugs-Cc: debian-scie...@lists.debian.org

Hi,

The package has been pushed to debian-science team's salsa:

https://salsa.debian.org/science-team/ortools

Please review.

Best regards,

Romain.

Bug#989603: ocsinventory-server: Does not start after install

[Enrico Rossi]

Hi,

finally copy/paste the same file from the Buster version seems to solve
the problem.

/usr/share/perl5/Apache/Ocsinventory/Plugins/Apache.pm

Tnx
E.

-- 
GPG key: 4096R/5E0195FAF2133176 2010-10-19 Enrico Rossi 

Bug#989607: ITP: 2geom -- robust computational geometry framework

[Mattia Rizzolo]

Package: wnpp
Severity: wishlist
Owner: Mattia Rizzolo 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-multime...@lists.debian.org
Control: block 989606 by -1

* Package name: 2geom
  Version : 1.1
  Upstream Author : Inkscape developers
* URL : https://gitlab.com/inkscape/lib2geom
* License : LGPLG-2.1 or MPL-1.1
  Programming Lang: C++
  Description : robust computational geometry framework

The library is descended from a set of geometric routines present in
Inkscape, a vector graphics editor based around the Scalable Vector
Graphics format, the most widespread vector graphics interchange format
on the Web and a W3C Recommendation. Due to this legacy, not all parts
of the API form a coherent whole (yet).
Rendering is outside the scope of this library, and it is assumed
something like libcairo or similar is employed for this.  2geom
concentrates on higher level algorithms and geometric computations.



This library was developed mainly to be used by Inkscape, but it's
released separately in the hope to be useful to others.

I plan to maintain it within the Debian Multimedia team (like I do for
inkscape), and welcome others to join me.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#989593: installation report Raspberry Pi 4 UEFI

[Cyril Brulebois]

Marc Haber  (2021-06-08):
> The Raspi 4 has both Wifi and Ethernet interfaces named brcmsomething,
> so it's still kind of guessing, but I have verified in the mean time
> that it's actually really the Wifi firmware.

Alright, thanks for confirming.

> Text installer ("expert"). I have used the graphical installer just a
> handful of times in two decades.

OK, good guess then, but checking never hurts.

> Since my default domain types differently with US and DE keyboard, I
> guess this might be an actual regression, I would have noticed this in
> earlier versions of the installer.

I guess someone could try various images outside the Pi 4 setup and see
whether/when that regressed. Given the following issue (ssd), I wouldn't
rule out some Pi-specific, but such a trivial thing seems a little
strange… That being said, I test the graphical installer most of the
time, and I don't know the specifics of the text version by heart.

> > Simply /var/log/syslog for the main log. Other files are mentioned
> > there:
> >   
> > https://salsa.debian.org/installer-team/installation-report/-/blob/master/debian/installation-report.postinst
> 
> Is there anything you need from me to go on?

If you were to retry the installation, saving /var/log/syslog manually
before rebooting into the installed system would be useful. Without it,
I fear much guessing would be needed to try and figure out what happened
on that system specifically. Unless someone else has better ideas of
course.


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


signature.asc
Description: PGP signature

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

[Julien Puydt]

Hi,

Le mardi 08 juin 2021 à 14:58 +0200, Jochen Sprickerhof a écrit :
> 
> friendly ping on the sagemath issue as it will be dropped from
> testing 
> on the 18., otherwise.
> As far as I read there are a number of proposals (downgrade, ignore
> test 
> results..) besides fixing the tests. I'm happy to help with this but 
> leave it to the maintainers how to approach this.

I've been convinced that getting a fragile sagemath in next stable
wouldn't be a good thing.

Cheers,

JP

Bug#989608: Create /var/spool/exim4/msglog.OLD upon installation

[Thomas Landauer]

Package: exim4
Severity: wishlist

It looks like the /var/spool/exim4/msglog.OLD directory is only created 
by Exim itself after the first messagelog is going to be written there.


If you need custom permissions on this directory, it would be nice to be 
able to set those permissions right within the deployment process, i.e. 
before Exim has sent any mail. So I'm suggesting to create it right 
away, during the installation.


I've already suggested this at 
https://bugs.exim.org/show_bug.cgi?id=2768 but got the answer that this 
is more a distribution thing :-)




--
Schöne Grüße
Thomas Landauer

Bug#989602: dpkg-deb overwrites symlinks with directories

[Johannes Schauer Marin Rodrigues]

On Tue, 08 Jun 2021 14:08:46 +0200 Marc Haber  
wrote:
> dpkg-deb -x package.deb happily overwrites symlinks on the filesystems
> with directories. I don't know whether this is desired behavior.
> 
> tl;dr:
> For some reason, a system of mine ended up without
> /sbin/start-stop-daemon. Not knowing about dpkg --force-bad-path, I was
> unable to use dpkg to repair dpkg because dpkg refuses work if there is
> no /sbin/start-stop-daemon.
> 
> dpkg-deb -x /var/cache/apt/archives/dpkg*.deb / happily replaced the
> /sbin => /usr/sbin with an /sbin directory containing only
> /sbin/start-stop-daemon.
> 
> Wouldn't it be nicer to have dpkg follow symlinks before creating
> directories in the times of usrmerge?
> 
> Severity: minor because dpkg --force-bad-path --install dpkg*.deb works.

you can also use:

dpkg-deb --fsys-tarfile dpkg*.deb | tar -C / --keep-directory-symlink --extract 
--file -

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#989609: unblock: rdma-core/33.2-1

[Benjamin Drung]

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

Please unblock package rdma-core

The rdma-core projects follows a similar release process than the linux
kernel developers. The point releases only contain backported fixes. I
had a look at those commits between our git snapshot from 2021-03-17 and
the 33.2 release.

[ Reason ]
The 33.2 release contains more bugfixes.

[ Impact ]
Users with InfiniBand hardware might not benefit from the fixes.

[ Tests ]
The upstream project has test cases, but our package does not run the
tests, because they rely on having InfiniBand hardware.

[ Risks ]
The package is not a leaf package, but only needed for users with RDMA
hardware. Since we have a good upstream relationship, the code from
upstream is unchanged. In case of a regression, upstream will be
affected as well.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock rdma-core/33.2-1

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet
diff -Nru rdma-core-33.1+git20210317/buildlib/centos6.spec 
rdma-core-33.2/buildlib/centos6.spec
--- rdma-core-33.1+git20210317/buildlib/centos6.spec2021-04-06 
10:12:51.0 +0200
+++ rdma-core-33.2/buildlib/centos6.spec2021-06-03 09:20:05.0 
+0200
@@ -1,5 +1,5 @@
 Name: rdma-core
-Version: 33.1
+Version: 33.2
 Release: 1%{?dist}
 Summary: RDMA core userspace libraries and daemons
 
diff -Nru rdma-core-33.1+git20210317/buildlib/RDMA_EnableCStd.cmake 
rdma-core-33.2/buildlib/RDMA_EnableCStd.cmake
--- rdma-core-33.1+git20210317/buildlib/RDMA_EnableCStd.cmake   2021-04-06 
10:12:51.0 +0200
+++ rdma-core-33.2/buildlib/RDMA_EnableCStd.cmake   2021-06-03 
09:20:05.0 +0200
@@ -58,9 +58,15 @@
   endif()
 endfunction()
 
+function(RDMA_Check_C_Compiles TO_VAR CHECK_PROGRAM)
+  set(CMAKE_REQUIRED_FLAGS "${ARGV2} -Werror")
+  CHECK_C_SOURCE_COMPILES("${CHECK_PROGRAM}" ${TO_VAR})
+  set(${TO_VAR} ${${TO_VAR}} PARENT_SCOPE)
+endfunction()
+
 function(RDMA_Check_Aliasing TO_VAR)
   SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -O2")
-  CHECK_C_SOURCE_COMPILES("
+  RDMA_Check_C_Compiles(HAVE_WORKING_STRICT_ALIASING "
 struct in6_addr {unsigned int u6_addr32[4];};
 struct iphdr {unsigned int daddr;};
 union ibv_gid {unsigned char raw[16];};
@@ -80,8 +86,7 @@
map_ipv4_addr_to_ipv6(&a);
return set_ah_attr_by_ipv4(&h);
 }"
-HAVE_WORKING_STRICT_ALIASING
-FAIL_REGEX "warning")
+  )
 
   set(${TO_VAR} "${HAVE_WORKING_STRICT_ALIASING}" PARENT_SCOPE)
 endfunction()
@@ -107,20 +112,12 @@
 #endif
 ")
 
-  CHECK_C_SOURCE_COMPILES(
-"${SSE_CHECK_PROGRAM}"
-HAVE_TARGET_SSE
-FAIL_REGEX "warning")
+  RDMA_Check_C_Compiles(HAVE_TARGET_SSE "${SSE_CHECK_PROGRAM}")
 
   if(NOT HAVE_TARGET_SSE)
 # Older compiler, we can work around this by adding -msse instead of
 # relying on the function attribute.
-set(CMAKE_REQUIRED_FLAGS "-msse")
-CHECK_C_SOURCE_COMPILES(
-  "${SSE_CHECK_PROGRAM}"
-  NEED_MSSE_FLAG
-  FAIL_REGEX "warning")
-set(CMAKE_REQUIRED_FLAGS)
+RDMA_Check_C_Compiles(NEED_MSSE_FLAG "${SSE_CHECK_PROGRAM}" "-msse")
 
 if(NEED_MSSE_FLAG)
   set(SSE_FLAGS "-msse" PARENT_SCOPE)
diff -Nru rdma-core-33.1+git20210317/CMakeLists.txt 
rdma-core-33.2/CMakeLists.txt
--- rdma-core-33.1+git20210317/CMakeLists.txt   2021-04-06 10:12:51.0 
+0200
+++ rdma-core-33.2/CMakeLists.txt   2021-06-03 09:20:05.0 +0200
@@ -72,7 +72,7 @@
 set(PACKAGE_NAME "RDMA")
 
 # See Documentation/versioning.md
-set(PACKAGE_VERSION "33.1")
+set(PACKAGE_VERSION "33.2")
 # When this is changed the values in these files need changing too:
 #   debian/control
 #   debian/libibverbs1.symbols
@@ -233,26 +233,21 @@
 
 # At some point after 4.4 gcc fixed shadow to ignore function vs variable
 # conflicts
-set(SAFE_CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS}")
-  set(CMAKE_REQUIRED_FLAGS "-Wshadow")
-CHECK_C_SOURCE_COMPILES("
+RDMA_Check_C_Compiles(HAVE_C_WORKING_SHADOW "
  #include 
  int main(int argc,const char *argv[]) { int access = 1; return access; }"
-  HAVE_C_WORKING_SHADOW
-  FAIL_REGEX "warning")
+  "-Wshadow")
 if (HAVE_C_WORKING_SHADOW)
   RDMA_AddOptCFlag(CMAKE_C_FLAGS HAVE_C_WORKING_SHADOW "-Wshadow")
 endif()
-set(CMAKE_REQUIRED_FLAGS "${SAFE_CMAKE_REQUIRED_FLAGS}")
 
 # At some point around 5.4 gcc fixed missing-field-initializers to ignore this
 # common idiom we use extensively. Since this is a useful warning for
 # de

Bug#989605: mirror submission for mirror.alwyzon.net

[Peter Palfrader]

Hi!

On Tue, 08 Jun 2021, Alwyzon wrote:

> Submission-Type: new
> Site: mirror.alwyzon.net
> Type: leaf
> Archive-architecture: amd64 i386
> Archive-http: /debian/
> Maintainer: Alwyzon 
> Country: AT Austria
> Location: Vienna
> Sponsor: Alwyzon https://www.alwyzon.com/

Can you tell us a bit more about your DNS setup?

It seems alwyzon.com only has a single IPv4 nameserver, and both
nameservers share the same IPv6 address.  How does the dns service for
this domain provide availability against spof?

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

Bug#989610: unblock: orthanc-webviewer/2.7-4

[Sebastien Jodogne]

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

Please unblock package orthanc-webviewer

[ Reason ]
This version fixes issue #989127 (package statically links without using a
Built-Using attribute), that has the "serious" severity.

[ Impact ]
None, as no other package depends on this package.

[ Tests ]
I have run the upstream unit tests, as well as the upstream integration tests.

[ Risks ]
As can be seen in the debdiff, the only modification wrt. the version currently
in testing (orthanc-webviewer/2.7-3) is the addition of the "Built-Using"
attribute on the binary package. So, I see no potential risk.

Many thanks in advance,
Sébastien-

unblock orthanc-webviewer/2.7-4
diff -Nru orthanc-webviewer-2.7/debian/changelog 
orthanc-webviewer-2.7/debian/changelog
--- orthanc-webviewer-2.7/debian/changelog  2021-02-26 14:41:24.0 
+0100
+++ orthanc-webviewer-2.7/debian/changelog  2021-06-07 14:21:25.0 
+0200
@@ -1,3 +1,9 @@
+orthanc-webviewer (2.7-4) unstable; urgency=medium
+
+  * Added missing "Built-Using" attribute. Closes: #989127
+
+ -- Sebastien Jodogne   Mon, 07 Jun 2021 14:21:25 +0200
+
 orthanc-webviewer (2.7-3) unstable; urgency=medium
 
   * Statically link against the Orthanc framework
diff -Nru orthanc-webviewer-2.7/debian/control 
orthanc-webviewer-2.7/debian/control
--- orthanc-webviewer-2.7/debian/control2021-02-26 14:38:57.0 
+0100
+++ orthanc-webviewer-2.7/debian/control2021-06-07 14:21:25.0 
+0200
@@ -29,6 +29,7 @@
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  orthanc (>= 1.7.1)
+Built-Using: ${orthancframework:Built-Using}
 Description: Web viewer of medical images for Orthanc
  Orthanc Web Viewer is a plugin to Orthanc, a lightweight, RESTful Vendor
  Neutral Archive for medical imaging. It extends Orthanc with an integrated
diff -Nru orthanc-webviewer-2.7/debian/rules orthanc-webviewer-2.7/debian/rules
--- orthanc-webviewer-2.7/debian/rules  2021-02-26 14:41:24.0 +0100
+++ orthanc-webviewer-2.7/debian/rules  2021-06-07 14:21:25.0 +0200
@@ -26,6 +26,13 @@
"-DORTHANC_FRAMEWORK_ADDITIONAL_LIBRARIES=boost_filesystem 
boost_iostreams boost_locale boost_regex boost_thread jsoncpp pugixml uuid 
sqlite3" \
-DCMAKE_BUILD_TYPE=None   # The build type must be set to None, see 
#711515
 
+# Automated generation of the "Built-Using" attribute in "d/control"
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989127
+# Adapted from:
+# https://wiki.debian.org/SIMDEverywhere#Approach (Point 6)
+override_dh_gencontrol:
+   dh_gencontrol -- -Vorthancframework:Built-Using="$(shell dpkg-query -f 
'$${source:Package} (= $${source:Version}), ' -W liborthancframework-dev)"
+
 override_dh_auto_configure:
 # Place the third-party JavaScript libraries at the location
 # expected by CMake

Bug#989608: Create /var/spool/exim4/msglog.OLD upon installation

[Andreas Metzler]

On 2021-06-08 Thomas Landauer  wrote:
> Package: exim4
> Severity: wishlist

> It looks like the /var/spool/exim4/msglog.OLD directory is only created by
> Exim itself after the first messagelog is going to be written there.

> If you need custom permissions on this directory, it would be nice to be
> able to set those permissions right within the deployment process, i.e.
> before Exim has sent any mail. So I'm suggesting to create it right away,
> during the installation.

> I've already suggested this at https://bugs.exim.org/show_bug.cgi?id=2768
> but got the answer that this is more a distribution thing :-)

Hello Thomas,

/var/spool/exim4/msglog.OLD is only used if a specific exim4 setting is
enabled which is not enabled by default. So enabling this requires a
local manual step and when you do it you can also mkdir the directory
with specific local permissions. You can use dpkg-statoverride
which you could not use before, but that is a small win, imho.
The benefit-cost-ratio seems to be off, shipping an empty directory in
millions of installations that is going to be useless for all but a few
installations.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

Hmmm, with set-linger and --scope I can't seem to reproduce now either, its possible I had forgotten the --scope at some 
point while testing set-linger before, sorry for the noise here.


Still, based on my read of #825394, it seems like it should be the case that you do not need set-linger and the default 
behavior should be that things aren't automatically killed in the background? Is that something that was an intentional 
change?


The systemd-run manpage seems to indicate that with debian's default change of KillUserProcesses=no this should not 
occur with or without linger. In either case, it seems the manpage should be updated to describe this behavior, and 
maybe updated to mention that KilUserProcesses is *not* the default on Debian, which it states in the EXAMPLES section.


Thanks,
Matt

On 6/8/21 10:19, Michael Biebl wrote:

Control: tags -1 + unreproducible

So, I've been following the instructions in /usr/share/doc/lxc/README.Debian to 
allow unprivileged containers.

After that, I could successfully run a container. I used the command line as 
suggested in that README.Debian:

$ systemd-run --scope --quiet --user --property=Delegate=yes \
     lxc-start -n mycontainer


Once I logged out, the systemd --user session was stopped including the 
container, which is expected, as ansgar wrote.

After enabling "linger" for that user, the systemd --user session was not stopped anymore after logging out and the 
container continued running.


I'm thus marking this bug report as unreproducible.

(note that the lxc maintainers recommend to use --scope with systemd-run)

Michael

Bug#989192: diffoscope: Differences in file lists are repeated at each depth level

[Chris Lamb]

forwarded 989192 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/263
thanks

I've forwarded this upstream here (so all our bugs are in the same place):

  https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/263


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#989611: unblock: orthanc-wsi/1.0-3

[Sebastien Jodogne]

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

Please unblock package orthanc-wsi

[ Reason ]
This version fixes issue #989126 (package statically links without using a
Built-Using attribute), that has the "serious" severity.

[ Impact ]
None, as no other package depends on this package.

[ Tests ]
I have run the upstream unit tests, as well as the upstream integration tests.

[ Risks ]
As can be seen in the debdiff, the only modification wrt. the version currently
in testing (orthanc-wsi/1.0-2) is the addition of the "Built-Using" attribute
on the binary package. So, I see no potential risk.

Many thanks in advance,
Sébastien-

unblock orthanc-wsi/1.0-3
diff -Nru orthanc-wsi-1.0/debian/changelog orthanc-wsi-1.0/debian/changelog
--- orthanc-wsi-1.0/debian/changelog2021-02-26 16:01:23.0 +0100
+++ orthanc-wsi-1.0/debian/changelog2021-06-07 14:34:06.0 +0200
@@ -1,3 +1,9 @@
+orthanc-wsi (1.0-3) unstable; urgency=medium
+
+  * Added missing "Built-Using" attribute. Closes: #989126
+
+ -- Sebastien Jodogne   Mon, 07 Jun 2021 14:34:06 +0200
+
 orthanc-wsi (1.0-2) unstable; urgency=medium
 
   * Statically link against the Orthanc framework
diff -Nru orthanc-wsi-1.0/debian/control orthanc-wsi-1.0/debian/control
--- orthanc-wsi-1.0/debian/control  2021-02-26 16:01:23.0 +0100
+++ orthanc-wsi-1.0/debian/control  2021-06-07 14:34:06.0 +0200
@@ -24,6 +24,7 @@
 Architecture: any
 Depends: ${misc:Depends},
  ${shlibs:Depends}
+Built-Using: ${orthancframework:Built-Using}
 Recommends: orthanc (>= 1.1.0),
 libopenslide0
 Description: Whole-slide imaging support for Orthanc (digital pathology)
diff -Nru orthanc-wsi-1.0/debian/rules orthanc-wsi-1.0/debian/rules
--- orthanc-wsi-1.0/debian/rules2021-02-26 16:01:23.0 +0100
+++ orthanc-wsi-1.0/debian/rules2021-06-07 14:34:06.0 +0200
@@ -33,6 +33,13 @@
-DOPENLAYERS_JS=$(CURDIR)/BuildViewer/ol.min.js \
-DCMAKE_BUILD_TYPE=None   # The build type must be set to None, see 
#711515
 
+# Automated generation of the "Built-Using" attribute in "d/control"
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989126
+# Adapted from:
+# https://wiki.debian.org/SIMDEverywhere#Approach (Point 6)
+override_dh_gencontrol:
+   dh_gencontrol -- -Vorthancframework:Built-Using="$(shell dpkg-query -f 
'$${source:Package} (= $${source:Version}), ' -W liborthancframework-dev)"
+
 override_dh_auto_configure:
 # Configure the command-line tools
mkdir BuildApplications

Bug#989612: mke2fs -E offset=N still warns about existing partition table at the beginning

[Josh Triplett]

Package: e2fsprogs
Version: 1.46.2-2
Severity: normal
File: /sbin/mke2fs
X-Debbugs-Cc: j...@joshtriplett.org

mke2fs with -E offset=N does not seem to take the offset into account
when checking the target to see if it seems to already contain
something. For instance:

/tmp$ truncate -s 1G disk.img
/tmp$ echo '8,+,L' | sfdisk --lock --no-reread --no-tell-kernel disk.img
Disk disk.img: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

>>> Created a new DOS disklabel with disk identifier 0x729c5118.
disk.img1: Created a new partition 1 of type 'Linux' and of size 1024 MiB.
disk.img2: Done.

New situation:
Disklabel type: dos
Disk identifier: 0x729c5118

Device Boot Start End Sectors  Size Id Type
disk.img1   8 2097151 2097144 1024M 83 Linux

The partition table has been altered.
/tmp$ mkfs.ext4 -E offset=4096 disk.img
mke2fs 1.46.2 (28-Feb-2021)
Found a dos partition table in disk.img
Proceed anyway? (y,N)



I deeply appreciate that mke2fs checks for existing data before
overwriting it, and I'd prefer to not just pass -F here. I think the
"plausible" checks should take the offset into account.


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

Kernel: Linux 5.12.8 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages e2fsprogs depends on:
ii  libblkid12.36.1-7
ii  libc62.31-12
ii  libcom-err2  1.46.2-2
ii  libext2fs2   1.46.2-2
ii  libss2   1.46.2-2
ii  libuuid1 2.36.1-7
ii  logsave  1.46.2-2

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.4-1

-- no debconf information

Bug#989613: unblock: orthanc-dicomweb/1.5+dfsg-3

[Sebastien Jodogne]

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

Please unblock package orthanc-dicomweb

[ Reason ]
This version fixes issue #989128 (package statically links without using a
Built-Using attribute), that has the "serious" severity.

[ Impact ]
None, as no other package depends on this package.

[ Tests ]
I have run the upstream unit tests, as well as the upstream integration tests.

[ Risks ]
As can be seen in the debdiff, the only modification wrt. the version currently
in testing (orthanc-dicomweb/1.5+dfsg-2) is the addition of the "Built-Using"
attribute on the binary package. So, I see no potential risk.

Many thanks in advance,
Sébastien-

unblock orthanc-dicomweb/1.5+dfsg-3
diff -Nru orthanc-dicomweb-1.5+dfsg/debian/changelog 
orthanc-dicomweb-1.5+dfsg/debian/changelog
--- orthanc-dicomweb-1.5+dfsg/debian/changelog  2021-02-26 15:25:00.0 
+0100
+++ orthanc-dicomweb-1.5+dfsg/debian/changelog  2021-06-07 11:17:44.0 
+0200
@@ -1,3 +1,10 @@
+orthanc-dicomweb (1.5+dfsg-3) unstable; urgency=medium
+
+  * Added missing "Built-Using" attribute (backport from experimental).
+Closes: #989128
+
+ -- Sebastien Jodogne   Mon, 07 Jun 2021 11:17:44 +0200
+
 orthanc-dicomweb (1.5+dfsg-2) unstable; urgency=medium
 
   * Statically link against the Orthanc framework
diff -Nru orthanc-dicomweb-1.5+dfsg/debian/control 
orthanc-dicomweb-1.5+dfsg/debian/control
--- orthanc-dicomweb-1.5+dfsg/debian/control2021-02-26 15:25:00.0 
+0100
+++ orthanc-dicomweb-1.5+dfsg/debian/control2021-06-07 11:17:44.0 
+0200
@@ -26,6 +26,7 @@
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  orthanc (>= 1.7.0)
+Built-Using: ${orthancframework:Built-Using}
 Description: Plugin to extend Orthanc with support of WADO and DICOMweb
  Orthanc DICOMweb is a plugin to Orthanc, the lightweight, RESTful Vendor
  Neutral Archive for medical imaging. It extends the Orthanc core with
diff -Nru orthanc-dicomweb-1.5+dfsg/debian/rules 
orthanc-dicomweb-1.5+dfsg/debian/rules
--- orthanc-dicomweb-1.5+dfsg/debian/rules  2021-02-26 15:25:00.0 
+0100
+++ orthanc-dicomweb-1.5+dfsg/debian/rules  2021-06-07 11:17:44.0 
+0200
@@ -24,6 +24,13 @@
 "-DORTHANC_FRAMEWORK_ADDITIONAL_LIBRARIES=boost_filesystem 
boost_iostreams boost_locale boost_regex boost_thread jsoncpp pugixml uuid 
sqlite3 dcmdata dcmjpeg dcmjpls ofstd dcmimage" \
 -DCMAKE_BUILD_TYPE=None  # The build type must be set to None, see 
#711515
 
+# Automated generation of the "Built-Using" attribute in "d/control"
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989128
+# Adapted from:
+# https://wiki.debian.org/SIMDEverywhere#Approach (Point 6)
+override_dh_gencontrol:
+   dh_gencontrol -- -Vorthancframework:Built-Using="$(shell dpkg-query -f 
'$${source:Package} (= $${source:Version}), ' -W liborthancframework-dev)"
+
 override_dh_auto_configure:
 # Place back the jquery library from Debian
cp /usr/share/javascript/jquery/jquery.min.js 
Resources/Samples/JavaScript/jquery.min.js

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Michael Biebl]

Am 08.06.2021 um 18:08 schrieb Matt Corallo:
Hmmm, with set-linger and --scope I can't seem to reproduce now either, 
its possible I had forgotten the --scope at some point while testing 
set-linger before, sorry for the noise here.


Still, based on my read of #825394, it seems like it should be the case 
that you do not need set-linger and the default behavior should be that 
things aren't automatically killed in the background? Is that something 
that was an intentional change?


Change to what exactly?

I guess we need to differentiate between login and user sessions.
It's my understanding that KillUserProcesses= only affects a login session.

If you start a process as part of a user session (which is what 
systemd-run --user does), ending that user session will stop that process.


The systemd-run manpage seems to indicate that with debian's default 
change of KillUserProcesses=no this should not occur with or without 
linger. In either case, it seems the manpage should be updated to 
describe this behavior, and maybe updated to mention that 
KilUserProcesses is *not* the default on Debian, which it states in the 
EXAMPLES section.


We had this discussion in the past. The man pages document the upstream 
default behaviour. Patching all man pages to reflect Debian specific 
changes is unfortunately not maintainable. Sorry.


Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Michael Biebl]

Am 08.06.2021 um 18:31 schrieb Michael Biebl:

Am 08.06.2021 um 18:08 schrieb Matt Corallo:
Hmmm, with set-linger and --scope I can't seem to reproduce now 
either, its possible I had forgotten the --scope at some point while 
testing set-linger before, sorry for the noise here.


Still, based on my read of #825394, it seems like it should be the 
case that you do not need set-linger and the default behavior should 
be that things aren't automatically killed in the background? Is that 
something that was an intentional change?


Change to what exactly?


Did you use systemd-run in buster to start your lxc containers?
You need to be very explicit, otherwise I can only guess what exactly 
you were/are doing.

Bug#989608: Create /var/spool/exim4/msglog.OLD upon installation

[Thomas Landauer]

Yeah, sorry, I forgot that.

BTW: The setting is `preserve_message_logs`, see 
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-log_files.html#SECID260


You can close this (I don't know how to...)

Cheers,
Thomas

Am 08.06.21 um 18:05 schrieb Andreas Metzler:

On 2021-06-08 Thomas Landauer  wrote:

Package: exim4
Severity: wishlist



It looks like the /var/spool/exim4/msglog.OLD directory is only created by
Exim itself after the first messagelog is going to be written there.



If you need custom permissions on this directory, it would be nice to be
able to set those permissions right within the deployment process, i.e.
before Exim has sent any mail. So I'm suggesting to create it right away,
during the installation.



I've already suggested this at https://bugs.exim.org/show_bug.cgi?id=2768
but got the answer that this is more a distribution thing :-)


Hello Thomas,

/var/spool/exim4/msglog.OLD is only used if a specific exim4 setting is
enabled which is not enabled by default. So enabling this requires a
local manual step and when you do it you can also mkdir the directory
with specific local permissions. You can use dpkg-statoverride
which you could not use before, but that is a small win, imho.
The benefit-cost-ratio seems to be off, shipping an empty directory in
millions of installations that is going to be useless for all but a few
installations.

cu Andreas

Bug#989551: linux-image-5.10.0-7-amd64: linux-image-5.10.0.7-amd64 hang on boot. Shows symbols: '^@^@^@' and nothing else. Debian testing.

[Михаил Осипов]

 > What led up to the situation?
I have updated linux-image-amd64 to 5.10.0.7-amd64.

> What exactly did you do (or not do) that was effective (or ineffective)?
Loaded laptop with new kernel.

> What was the outcome of this action?
Boot freeze.

> What outcome did you expect instead?
Normal boot.

P.S. Laptop Lenovo Ideapad 5 14ARE05.
-
С уважением, Михаил Осипов.


пн, 7 июн. 2021 г. в 14:38, Salvatore Bonaccorso :

> Control: notfound -1 5.10.28-1
> Control: found -1 5.10.38-1
> Control: tags -1 + moreinfo
>
> On Mon, Jun 07, 2021 at 02:09:20PM +0300, Mikhail Osipov wrote:
> > Package: src:linux
> > Version: 5.10.28-1
> > Severity: important
> > X-Debbugs-Cc: osm...@gmail.com
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where
> appropriate ***
> >
> >* What led up to the situation?
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >* What was the outcome of this action?
> >* What outcome did you expect instead?
> >
> > *** End of the template - remove these template lines ***
>
> I'm assuming here it is relating to the
> https://lists.debian.org/debian-kernel/2021/06/msg00066.html report,
> thus adjusting the found version to 5.10.38-1.
>
> Mikhail, we have only litte information here to sensibly tackle the
> problem.
>
> When you boot 5.10.38-1 do you get any usefull information logged in
> the logs? Can you attach those to the bug?
>
> Please try to boot without quiet (and splash), do you get more
> information printed and indication where it hangs?
>
> Regards,
> Salvatore
>

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

On 6/8/21 12:31, Michael Biebl wrote:

Am 08.06.2021 um 18:08 schrieb Matt Corallo:
Hmmm, with set-linger and --scope I can't seem to reproduce now either, its possible I had forgotten the --scope at 
some point while testing set-linger before, sorry for the noise here.


Still, based on my read of #825394, it seems like it should be the case that you do not need set-linger and the 
default behavior should be that things aren't automatically killed in the background? Is that something that was an 
intentional change?


Change to what exactly?

I guess we need to differentiate between login and user sessions.
It's my understanding that KillUserProcesses= only affects a login session.


I admit I am definitely not a systemd expert (which I suppose should be obvious by now :) ), so have no idea what this 
means, and systemd-run's man page doesn't really elucidate it. Not Debian's or your problem, of course, though.


If you start a process as part of a user session (which is what systemd-run --user does), ending that user session will 
stop that process.


Is there an alternate way to run things that lxc should instead be recommending? In my interactions with the lxc folks 
it seems this workaround is only relevant for Debian bullseye, so maybe other distros are patching systemd or changing 
cgroup settings such that interacting with systemd isn't required.


Similar to the discussion in 825394, having daemons  spontaneously killed is incredibly surprising, maybe it makes sense 
to enable-linger by default?


> Did you use systemd-run in buster to start your lxc containers?
> You need to be very explicit, otherwise I can only guess what exactly you 
were/are doing.

No, but also didn't need to, its only with bullseye that (systemd's ?) cgroup settings prevent direct calls to 
lxc-start, which is what makes the whole thing such a mess - one cannot simply call lxc functions anymore because 
systemd gets in the way. Using systemd for this, sadly, is an excercize in puzzling through man pages and lack of 
documentation for how to do any of this (half of the lxc docs for how to do this are because I had to ask lxc 
maintainers how to do basic lxc things with bullseye).


Thanks,
Matt

Bug#989605: mirror submission for mirror.alwyzon.net

[Michael Hohl]

Hi!

Sure, I'm just not sure why you would think that Alwyzon.com runs on one 
Nameserver? There are two nameservers, ns1.alwyzon.net and ns3.alwyzon.net (for 
historical reasons, there is no longer a ns2). Both have IPv4 addresses 
assigned and run in geographically separate locations (Austria and the 
Netherlands):

> dig alwyzon.com NS

; <<>> DiG 9.10.6 <<>> alwyzon.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22643
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;alwyzon.com.   IN  NS

;; ANSWER SECTION:
alwyzon.com.86400   IN  NS  ns1.alwyzon.net.
alwyzon.com.86400   IN  NS  ns3.alwyzon.net.

;; Query time: 47 msec
;; SERVER: 2a0d:f302:100::100#53(2a0d:f302:100::100)
;; WHEN: Tue Jun 08 17:57:45 CEST 2021
;; MSG SIZE  rcvd: 87

> host ns1.alwyzon.net
ns1.alwyzon.net has address 193.219.97.6
ns1.alwyzon.net has IPv6 address 2a0d:f300::6

> host ns3.alwyzon.net
ns3.alwyzon.net has address 46.102.157.71
ns3.alwyzon.net has IPv6 address 2a0d:f302:101:1a2a::1

Regards,
Michael

Btw. your mail setup seems a bit off: the email has a "Reply-To: Debian Mirror 
Team <989...@debian.org>" header set, but that address doesn't seem to exist. I 
got a "550 unroutable address" from "mailly.debian.org[82.195.75.114]". If you 
are receiving this mail, I assume it should be "989...@bugs.debian.org" (just a 
guess as that was the sender domain used for the system notifications and used 
by your mail as Cc).


On 08.06.21, 17:49, "Peter Palfrader"  wrote:

Hi!

On Tue, 08 Jun 2021, Alwyzon wrote:

> Submission-Type: new
> Site: mirror.alwyzon.net
> Type: leaf
> Archive-architecture: amd64 i386
> Archive-http: /debian/
> Maintainer: Alwyzon 
> Country: AT Austria
> Location: Vienna
> Sponsor: Alwyzon https://www.alwyzon.com/

Can you tell us a bit more about your DNS setup?

It seems alwyzon.com only has a single IPv4 nameserver, and both
nameservers share the same IPv6 address.  How does the dns service for
this domain provide availability against spof?

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

Bug#895201: trousers uninstallable / postinst relaxing / fixes

[Dan Bungert]

One note on the suggested fix from Florian:

I don't think we can use shopt with bare /bin/sh, so the suggested
change to the init script will also fail with an error.

I ended up using:

  if [ "$(echo /dev/tpm*)" != "/dev/tpm*" ]

which is good enough for my usage but I have not tested it further.

-Dan

Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool

[Tobias Frost]

On Tue, Jun 08, 2021 at 02:50:47PM +0800, clay stan wrote:
> Tobias Frost  于2021年6月3日周四 上午1:33写道：
> >
> > Control: tags -1 moreinfo
> >
> > Hi Clay,
> >
> > here's a review:
> > - The patch: The dep3 header, the field Bug-Debian is wrong, the ITP is not
> >   related to the patch
> 
> Thanks, I've updated.
> 
> > - The patch looks strange to me: Why do you patch the Makefile? What do you
> >   want to archieve? Parts of the patching seems ok (like avoiding stomping 
> > over
> > CFLAGS, but other parts seems excessive, removing sane parts to me…
> 
> The original compilation parameters will also cause Lintian to report errors,
> hardening no bind now, hardening no mandatory functions.
> I'll try to solve them in debian/rules by
> https://wiki.debian.org/Hardening, but it doesn't work
> 
>and the sane parts, you mean?

You've basically completly rewritten a (mostly) working Makefile
With your comment I assume that you just wanted to have hardening,
so _just_ those parts should have been patched.
And that would be:

--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 CC ?= gcc
 
-CFLAGS+=-Wall -Wextra -pedantic -fstack-protector-all -pedantic -std=c99
+CFLAGS:=-Wall -Wextra -pedantic -fstack-protector-all -pedantic -std=c99 
${CFLAGS} ${CPPFLAGS} ${LDFLAGS}
 SANITY_FLAGS=-Wfloat-equal -Wshadow -Wpointer-arith
 
 PREFIX ?= /usr

(+ adding export DEB_BUILD_MAINT_OPTIONS = hardening=+all to d/rules)

So, see it as recommendation: I'd keep patches really minimal. Or they
will create you a lot of work…

It is a burden to carry such an intrusive patch, especially if upstream
explictly expressed that he does not generally welcome patches
if they target the Makefile.

Just one example where I think the upstream part is better:
-PREFIX ?= /usr
+PREFIX = /usr

Some other stuff could be done with debhelper overrides, so
that the patch can get smaller…

But you do you… I just strongly recommend to revisit the topic.
On top, non-upstreamable patches are bad…
 
> >   - Upstream seems to support arm, you patch that out?
> 
> Upstream support arm means the mobile arm chips, like Snapdragon, MediaTek,
> not arm PC, They are not supported by Debian.

This is not a strong reason to disable arm support entirely…
(A quick internet search suggests that there is some support for Debian on e.g
Snapdragon. And there seems to be derivates; even if not, maybe someone wants
to enhance cpufetch on the basis of the Debian package.)

> >   - There is no LDCFLAGS -> did you mean LDFLAGS?
> 
> Yeah, I've updated. Thanks again.
> 
> >
> > - (not a blocker) Please send the manpage upstream for inclusion.

Regarding the manpage: I've diffed the manpage (cpufetch.1 and
debian/cpufetch.1). They are almost identical. With just small fixes done by
you. However, you claim (sole) copyright on it. That is not appropiate.

I would patch the manpage, if it needs fixing: The header of the upstream ones
says that upstream builds it using help2man (but hav not integrated that into
their Makefile), so possibly this is another route to go: Rebuild at build
time.

-- 
tobi

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Michael Biebl]

Am 08.06.2021 um 19:05 schrieb Matt Corallo:



On 6/8/21 12:31, Michael Biebl wrote:

Am 08.06.2021 um 18:08 schrieb Matt Corallo:
Hmmm, with set-linger and --scope I can't seem to reproduce now 
either, its possible I had forgotten the --scope at some point while 
testing set-linger before, sorry for the noise here.


Still, based on my read of #825394, it seems like it should be the 
case that you do not need set-linger and the default behavior should 
be that things aren't automatically killed in the background? Is that 
something that was an intentional change?


Change to what exactly?

I guess we need to differentiate between login and user sessions.
It's my understanding that KillUserProcesses= only affects a login 
session.


I admit I am definitely not a systemd expert (which I suppose should be 
obvious by now :) ), so have no idea what this means, and systemd-run's 
man page doesn't really elucidate it. Not Debian's or your problem, of 
course, though.


If you start a process as part of a user session (which is what 
systemd-run --user does), ending that user session will stop that 
process.


Is there an alternate way to run things that lxc should instead be 
recommending? In my interactions with the lxc folks it seems this 
workaround is only relevant for Debian bullseye, so maybe other distros 
are patching systemd or changing cgroup settings such that interacting 
with systemd isn't required.


Are you sure? Which distros are that? Which exact version of that distro?

Similar to the discussion in 825394, having daemons  spontaneously 
killed is incredibly surprising, maybe it makes sense to enable-linger 
by default?


That's not a good idea I think.
Starting long running daemons from a user session is not the norm, I'd 
argue.



 > Did you use systemd-run in buster to start your lxc containers?
 > You need to be very explicit, otherwise I can only guess what exactly 
you were/are doing.


No, but also didn't need to, its only with bullseye that (systemd's ?) 
cgroup settings prevent direct calls to lxc-start, which is what makes 
the whole thing such a mess - one cannot simply call lxc functions 
anymore because systemd gets in the way. Using systemd for this, sadly, 
is an excercize in puzzling through man pages and lack of documentation 
for how to do any of this (half of the lxc docs for how to do this are 
because I had to ask lxc maintainers how to do basic lxc things with 
bullseye).


bullseye changed to cgroupv2 (see systemd's NEWS entry [1]). Other 
distros (like Fedora) made that switch a while ago


Maybe the best that can be done here is to document in lxc's 
README.Debian, that if you use unprivileged containers and you use 
systemd-run, you should also use linger if you want those daemons to 
persist.


In any case, I'm not sure there remains anything to be done on the 
systemd side. Afaics, everything behaves as documented.



Michael

[1] 
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/systemd.NEWS#L1




OpenPGP_signature
Description: OpenPGP digital signature

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Michael Biebl]

Am 07.06.2021 um 21:20 schrieb Matt Corallo:
Is there any further information I can provide to help debug this (or 
should it get a -moreinfo)?


Note that of interest may be that the workaround of spawning in a screen 
session only works if lxc-start is passed the -F command which places it 
in the foreground (though sshd still gets the -D option running inside 
the container).



Let me elaborate a bit more what's happening here.

A systemd --user session (user session) is typically tied to a login 
session. As long as you have 1 (or more) login sessions you have a 
single (reference counted) user session.
Once the last login session stops (has no more processes) the associated 
user session is stopped as well (unless you enabled lingering [1]).


Now, if you start a screen session inside your login session, you 
artifically keep your login session alive after loggin out 
(KillUserProcesses=no prevents screen from being killed).


As a result, your user session also kept alive as well.

Hope this clarifies.

Michael


[1] Linger will start the user session when the system boots and keep it 
always active. Which is why it's not a good idea to enable this globally.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

On 6/8/21 14:02, Michael Biebl wrote:
Is there an alternate way to run things that lxc should instead be recommending? In my interactions with the lxc folks 
it seems this workaround is only relevant for Debian bullseye, so maybe other distros are patching systemd or changing 
cgroup settings such that interacting with systemd isn't required.


Are you sure? Which distros are that? Which exact version of that distro?


No, I'm not sure, but that was the response any time I mentioned systemd-run was immediately "I assume Debian bullseye 
or something". Its possible it also impacts fedora and the Ubuntu folks just have some crazy workaround that doesn't 
really make sense.


Similar to the discussion in 825394, having daemons  spontaneously killed is incredibly surprising, maybe it makes 
sense to enable-linger by default?


That's not a good idea I think.
Starting long running daemons from a user session is not the norm, I'd argue.


Would defer to you, I've never seen systemd-run used or mentioned anywhere 
outside of lxc.


In any case, I'm not sure there remains anything to be done on the systemd 
side. Afaics, everything behaves as documented.


Sounds good.

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

On 2021-06-07 08:51, Shengjing Zhu wrote:

On Mon, Jun 07, 2021 at 08:04:14AM +0200, Gunnar Hjalmarsson wrote:

How about uploading the "fcitx5" -> "fcitx" change to experimental
for now? And possibly upload to bullseye soon after the release of
Debian 11.


Yes, please. And after release, the change could be updated in
unstable ASAP to get more feedback from users.


I sync'ed im-config 0.47-1 to Ubuntu impish (coming 21.10), and asked 
the Ubuntu Kylin folks to test fcitx 5 and report back if they run into 
issues.


https://bugs.launchpad.net/ubuntu/+source/im-config/+bug/1928360/comments/27

--
Gunnar

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Michael Biebl]

Am 08.06.2021 um 20:12 schrieb Matt Corallo:



On 6/8/21 14:02, Michael Biebl wrote:
Is there an alternate way to run things that lxc should instead be 
recommending? In my interactions with the lxc folks it seems this 
workaround is only relevant for Debian bullseye, so maybe other 
distros are patching systemd or changing cgroup settings such that 
interacting with systemd isn't required.


Are you sure? Which distros are that? Which exact version of that distro?


No, I'm not sure, but that was the response any time I mentioned 
systemd-run was immediately "I assume Debian bullseye or something". Its 
possible it also impacts fedora and the Ubuntu folks just have some 
crazy workaround that doesn't really make sense.


lxc fiddles with cgroups. In cgroupv2 [1] mode, there can only be a 
single manager of the cgroup hierarchy. In a systemd based system, this 
is PID 1, i.e. systemd.


Which is why lxc needs to delegate this to systemd in bullseye.
I thought Ubuntu was following Debian here, but apparently they deviate 
here [2].


Sooner or later they'll switch to cgroupv2 as well, as cgroupv1 is 
basically dead.


Michael


[1] https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html
[2] 
https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/rules?h=ubuntu/impish#n70




OpenPGP_signature
Description: OpenPGP digital signature

Bug#989614: bluez: CVE-2021-0129 CVE-2020-26558

[Salvatore Bonaccorso]

Source: bluez
Version: 5.55-3
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for bluez.

CVE-2021-0129[0], and

CVE-2020-26558[1]:
| Bluetooth LE and BR/EDR secure pairing in Bluetooth Core Specification
| 2.1 through 5.2 may permit a nearby man-in-the-middle attacker to
| identify the Passkey used during pairing (in the Passkey
| authentication procedure) by reflection of the public key and the
| authentication evidence of the initiating device, potentially
| permitting this attacker to complete authenticated pairing with the
| responding device using the correct Passkey for the pairing session.
| The attack methodology determines the Passkey value one bit at a time.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-0129
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-0129
[1] https://security-tracker.debian.org/tracker/CVE-2020-26558
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26558
[2] 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00517.html
[3] 
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=00da0fb4972cf59e1c075f313da81ea549cb8738

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#989551: linux-image-5.10.0-7-amd64: linux-image-5.10.0.7-amd64 hang on boot. Shows symbols: '^@^@^@' and nothing else. Debian testing.

[Salvatore Bonaccorso]

Hi,

On Tue, Jun 08, 2021 at 08:01:49PM +0300, Михаил Осипов wrote:
>  > What led up to the situation?
> I have updated linux-image-amd64 to 5.10.0.7-amd64.
> 
> > What exactly did you do (or not do) that was effective (or ineffective)?
> Loaded laptop with new kernel.
> 
> > What was the outcome of this action?
> Boot freeze.
> 
> > What outcome did you expect instead?
> Normal boot.

Yes that is somehow clear ;-)

Did you see my question below?

> > I'm assuming here it is relating to the
> > https://lists.debian.org/debian-kernel/2021/06/msg00066.html report,
> > thus adjusting the found version to 5.10.38-1.
> >
> > Mikhail, we have only litte information here to sensibly tackle the
> > problem.
> >
> > When you boot 5.10.38-1 do you get any usefull information logged in
> > the logs? Can you attach those to the bug?
> >
> > Please try to boot without quiet (and splash), do you get more
> > information printed and indication where it hangs?

Is the system in such a state that you can get to those? (and if not
after a boot with the old kernel, do you find at least part of that
information swritten to the logs)?

Regards,
Salvatore

Bug#989615: intel-microcode: CVE-2020-24511 CVE-2020-24512 CVE-2020-24513 CVE-2021-24489 (INTEL-SA-00464, INTEL-SA-00465, INTEL-SA-00442)

[Salvatore Bonaccorso]

Source: intel-microcode
Version: 3.20210216.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.20200609.2~deb10u1

Hi,

The following vulnerabilities were published for intel-microcode.

CVE-2020-24511[0] (INTEL-SA-00464), CVE-2020-24512[1]
(INTEL-SA-00464), CVE-2020-24513[2] (INTEL-SA-00465),
CVE-2021-24489[3] (INTEL-SA-00442).

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-24511
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24511
[1] https://security-tracker.debian.org/tracker/CVE-2020-24512
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24512
[2] https://security-tracker.debian.org/tracker/CVE-2020-24513
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24513
[3] https://security-tracker.debian.org/tracker/CVE-2021-24489
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-24489
[4] 
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20210608

Regards,
Salvatore

Bug#989616: netbeans: Package exists (as source only?) but not installable

[benjamin melançon]

Source: netbeans
Version: 12.1-3
Severity: serious
Tags: d-i ftbfs
Justification: fails to build from source
X-Debbugs-Cc: ben+deb...@agaric.coop

Dear Maintainer,

Trying to install Netbeans i thought i found it in testing (bullseye) -
https://packages.debian.org/source/stretch/netbeans

I know realize that's only the 'source', but i feel that if there is no
corresponding actual package some explanation should be identifiable on the
source page.

Moreover the tracker makes it look like everything is OK:
https://tracker.debian.org/pkg/netbeans

So, i'm trying to figure out how to 'sudo apt install netbeans' -- having that
work, of course, would be fantastic, if there's just one minor hiccup with
producing the package.

But i'm also hoping that messages on packages.debian.org, in apt, and in the
Software app can be improved.  Status and next steps being clear to all would
be very helpful for both users and potential contributors.

Thank you!!!

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

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

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Michael Biebl]

Am 08.06.2021 um 19:05 schrieb Matt Corallo:



On 6/8/21 12:31, Michael Biebl wrote:

Am 08.06.2021 um 18:08 schrieb Matt Corallo:
Hmmm, with set-linger and --scope I can't seem to reproduce now 
either, its possible I had forgotten the --scope at some point while 
testing set-linger before, sorry for the noise here.


Still, based on my read of #825394, it seems like it should be the 
case that you do not need set-linger and the default behavior should 
be that things aren't automatically killed in the background? Is that 
something that was an intentional change?


Change to what exactly?

I guess we need to differentiate between login and user sessions.
It's my understanding that KillUserProcesses= only affects a login 
session.


I admit I am definitely not a systemd expert (which I suppose should be 
obvious by now :) ), so have no idea what this means, and systemd-run's 
man page doesn't really elucidate it. Not Debian's or your problem, of 
course, though.


If you start a process as part of a user session (which is what 
systemd-run --user does), ending that user session will stop that 
process.


Is there an alternate way to run things that lxc should instead be 
recommending? In my interactions with the lxc folks it seems this 
workaround is only relevant for Debian bullseye, so maybe other distros 
are patching systemd or changing cgroup settings such that interacting 
with systemd isn't required.


Similar to the discussion in 825394, having daemons  spontaneously 
killed is incredibly surprising, maybe it makes sense to enable-linger 
by default?


 > Did you use systemd-run in buster to start your lxc containers?
 > You need to be very explicit, otherwise I can only guess what exactly 
you were/are doing.


No, but also didn't need to, its only with bullseye that (systemd's ?) 
cgroup settings prevent direct calls to lxc-start, which is what makes 
the whole thing such a mess - one cannot simply call lxc functions 
anymore because systemd gets in the way. Using systemd for this, sadly, 
is an excercize in puzzling through man pages and lack of documentation 
for how to do any of this (half of the lxc docs for how to do this are 
because I had to ask lxc maintainers how to do basic lxc things with 
bullseye).


Antonio, Stéphane, do you have any input how we can improve the 
situation here?


A short summary: Debian bullseye switched to cgroupv2 which now makes it 
necessary to run lxc-start as unprivileged user via "systemd-run -p 
Delegate=yes".
This in turn makes the lxc processes part of the systemd --user session, 
not the login session. Which in turn requires "linger" to enable daemon 
processes to persist once a user logs out.


Maybe I missed something and linger is the only option in this case (and 
lxc's README.Debian could have a note about this). Or maybe there is a 
different way to achieve what Matt is trying to do?


Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#989616: netbeans: Package exists (as source only?) but not installable

[Salvatore Bonaccorso]

[Big disclaimer: I'm not the maintainer but spotted the RC bug filled]

Hi,

On Tue, Jun 08, 2021 at 03:32:18PM -0400, benjamin melançon wrote:
> Source: netbeans
> Version: 12.1-3
> Severity: serious
> Tags: d-i ftbfs
> Justification: fails to build from source
> X-Debbugs-Cc: ben+deb...@agaric.coop
> 
> Dear Maintainer,
> 
> Trying to install Netbeans i thought i found it in testing (bullseye) -
> https://packages.debian.org/source/stretch/netbeans
> 
> I know realize that's only the 'source', but i feel that if there is no
> corresponding actual package some explanation should be identifiable on the
> source page.
> 
> Moreover the tracker makes it look like everything is OK:
> https://tracker.debian.org/pkg/netbeans
> 
> So, i'm trying to figure out how to 'sudo apt install netbeans' -- having that
> work, of course, would be fantastic, if there's just one minor hiccup with
> producing the package.
> 
> But i'm also hoping that messages on packages.debian.org, in apt, and in the
> Software app can be improved.  Status and next steps being clear to all would
> be very helpful for both users and potential contributors.

See the changelog entry from 12.1-1:

netbeans (12.1-1) unstable; urgency=medium

  * Only build libnb-absolutelayout-java from now on. Drop netbeans and Co
because it is not viable to maintain the editor in Debian. We recommend to
install the flatpack version from flathub instead.
(Closes: #925509, #929561, #960692, #815028, #805769, #920706, #922190)
(Closes: #960749, #653132, #877626, #935008)
  * Remove Andrew Ross from Uploaders. He is not active anymore.

 -- Markus Koschany   Sat, 03 Oct 2020 22:51:24 +0200

So this was on purpose.

Regards,
Salvatore

Bug#909473: fstrim shows incorrect trimmed size after reboot

[Bastian Blank]

Hi

On Tue, Jun 08, 2021 at 03:48:11PM +0200, Laurent Bigonville wrote:
> > > There is definitely something boggus here
> Yes, just tested it now and  it's still happening with the kernel currently
> in unstable (5.10.40-1)

Why do you think this numbers are wrong?  "fstrim" initially requests
discard of all unused blocks, so a large number.  But why should it do
the same on subsequent calls while it still knows what it did the last
time?

ext4 caches the information if a particular block group was trimmed, but
this information is not persistent.  (Using bit
EXT4_GROUP_INFO_WAS_TRIMMED_BIT in ext4_group_info.bb_state.)

Bastian

-- 
Live long and prosper.
-- Spock, "Amok Time", stardate 3372.7

Bug#989617: cimg-doc: cimg -- Fails to build reproducibly

[Nilesh Patra]

Package: cimg-doc
Version: 2.9.4+dfsg-2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
X-Debbugs-Cc: nil...@debian.org, reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

cimg vendors a few docs which are non deterministic in nature.
However on tweaking around, it looks like those few files are not really
needed, hence removing them makes it reproducible.

I have already committed to
salsa(https://salsa.debian.org/science-team/cimg/-/commit/51931c53791d4958a04a9a5bb4dce1733f48ce25)
and will upload post bullseye release.
Pasting the patch too

--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,7 @@ override_dh_install:
sed -i "s?#define cimg_plugin \"examples/$$file\"?#define 
cimg_plugin \"$$file\"?" $$file ; \
done
mv html/reference/* debian/$(doc)/usr/share/doc/cimg-dev/html
+   find debian -type f -name "_form*" -delete

 override_dh_auto_clean:
-cd examples && $(MAKE) clean


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

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

Versions of packages cimg-doc depends on:
ii  libjs-jquery  3.5.1+dfsg-4

cimg-doc recommends no packages.

cimg-doc suggests no packages.

Bug#989495: bluez: diff for NMU version 5.55-3.1

[Salvatore Bonaccorso]

Control: tags 989495 + patch
Control: tags 989495 + pending
Control: tags 989614 + patch
Control: tags 989614 + pending

Dear maintainer,

I've prepared an NMU for bluez (versioned as 5.55-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru bluez-5.55/debian/changelog bluez-5.55/debian/changelog
--- bluez-5.55/debian/changelog	2021-01-02 07:57:41.0 +0100
+++ bluez-5.55/debian/changelog	2021-06-08 21:34:10.0 +0200
@@ -1,3 +1,12 @@
+bluez (5.55-3.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * main: Don't warn for unset config option (Closes: #989495)
+  * shared/gatt-server: Fix not properly checking for secure flags
+(CVE-2020-26558, CVE-2021-0129) (Closes: #989614)
+
+ -- Salvatore Bonaccorso   Tue, 08 Jun 2021 21:34:10 +0200
+
 bluez (5.55-3) unstable; urgency=medium
 
   * Add d/salsa-ci.yml.
diff -Nru bluez-5.55/debian/patches/main-Don-t-warn-for-unset-config-option.patch bluez-5.55/debian/patches/main-Don-t-warn-for-unset-config-option.patch
--- bluez-5.55/debian/patches/main-Don-t-warn-for-unset-config-option.patch	1970-01-01 01:00:00.0 +0100
+++ bluez-5.55/debian/patches/main-Don-t-warn-for-unset-config-option.patch	2021-06-08 21:34:10.0 +0200
@@ -0,0 +1,23 @@
+From: Luiz Augusto von Dentz 
+Date: Mon, 9 Nov 2020 14:57:56 -0800
+Subject: main: Don't warn for unset config option
+Origin: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=02e46e9df6b0d897e6ba67dc3ea18e5e9c510e44
+Bug-Debian: https://bugs.debian.org/989495
+Bug: https://github.com/bluez/bluez/issues/51
+
+Unset options shall not be printed if debug is not enabled.
+---
+ src/main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/main.c
 b/src/main.c
+@@ -444,7 +444,7 @@ static void parse_controller_config(GKey
+ 		int val = g_key_file_get_integer(config, "Controller",
+ 		params[i].val_name, &err);
+ 		if (err) {
+-			warn("%s", err->message);
++			DBG("%s", err->message);
+ 			g_clear_error(&err);
+ 		} else {
+ 			info("%s=%d", params[i].val_name, val);
diff -Nru bluez-5.55/debian/patches/series bluez-5.55/debian/patches/series
--- bluez-5.55/debian/patches/series	2021-01-02 07:57:41.0 +0100
+++ bluez-5.55/debian/patches/series	2021-06-08 21:34:10.0 +0200
@@ -10,3 +10,5 @@
 shared-gatt-client-Fix-segfault-after-PIN-entry.patch
 main.conf-Add-more-details-Closes-904212.patch
 headers-use-releative-symlinks.patch
+main-Don-t-warn-for-unset-config-option.patch
+shared-gatt-server-Fix-not-properly-checking-for-sec.patch
diff -Nru bluez-5.55/debian/patches/shared-gatt-server-Fix-not-properly-checking-for-sec.patch bluez-5.55/debian/patches/shared-gatt-server-Fix-not-properly-checking-for-sec.patch
--- bluez-5.55/debian/patches/shared-gatt-server-Fix-not-properly-checking-for-sec.patch	1970-01-01 01:00:00.0 +0100
+++ bluez-5.55/debian/patches/shared-gatt-server-Fix-not-properly-checking-for-sec.patch	2021-06-08 21:34:10.0 +0200
@@ -0,0 +1,108 @@
+From: Luiz Augusto von Dentz 
+Date: Tue, 2 Mar 2021 11:38:33 -0800
+Subject: shared/gatt-server: Fix not properly checking for secure flags
+Origin: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit?id=00da0fb4972cf59e1c075f313da81ea549cb8738
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-26558
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-0129
+Bug-Debian: https://bugs.debian.org/989614
+
+When passing the mask to check_permissions all valid permissions for
+the operation must be set including BT_ATT_PERM_SECURE flags.
+---
+ src/shared/att-types.h   |  8 
+ src/shared/gatt-server.c | 25 +++--
+ 2 files changed, 15 insertions(+), 18 deletions(-)
+
+diff --git a/src/shared/att-types.h b/src/shared/att-types.h
+index 7108b4e94ab3..3adc05d9e357 100644
+--- a/src/shared/att-types.h
 b/src/shared/att-types.h
+@@ -129,6 +129,14 @@ struct bt_att_pdu_error_rsp {
+ #define BT_ATT_PERM_WRITE_SECURE	0x0200
+ #define BT_ATT_PERM_SECURE		(BT_ATT_PERM_READ_SECURE | \
+ 	BT_ATT_PERM_WRITE_SECURE)
++#define BT_ATT_PERM_READ_MASK		(BT_ATT_PERM_READ | \
++	BT_ATT_PERM_READ_AUTHEN | \
++	BT_ATT_PERM_READ_ENCRYPT | \
++	BT_ATT_PERM_READ_SECURE)
++#define BT_ATT_PERM_WRITE_MASK		(BT_ATT_PERM_WRITE | \
++	BT_ATT_PERM_WRITE_AUTHEN | \
++	BT_ATT_PERM_WRITE_ENCRYPT | \
++	BT_ATT_PERM_WRITE_SECURE)
+ 
+ /* GATT Characteristic Properties Bitfield values */
+ #define BT_GATT_CHRC_PROP_BROADCAST			0x01
+diff --git a/src/shared/gatt-server.c b/src/shared/gatt-server.c
+index b5f7de7dc3d9..970c35f94e51 100644
+--- a/src/shared/gatt-server.c
 b/src/shared/gatt-server.c
+@@ -444,9 +444,7 @@ static void process_read_by_type(struct async_read_op *op)
+ 		return;
+ 	}
+ 
+-	ecode = check_permissions(server, attr, BT_ATT_PERM_READ |
+-		BT_ATT_PERM_READ_AUTHEN |
+-		BT_ATT_PERM_READ_ENCRYPT);
++	ecode = check_p

Bug#989593: installation report Raspberry Pi 4 UEFI

[Marc Haber]

On Tue, Jun 08, 2021 at 09:27:57PM +0200, Holger Wansing wrote:
> I checked with rc1 and the *brandnew* rc2 netinst images on amd64 qemu
> VM machine (text installer), and I cannot reproduce such issue with wrong 
> keyboard layout; German is correctly available immediately after the 
> "Configure keyboard" step.
> 
> So, I guess that a Pi-specific thingy somehow.

On the Pi, keyboard-configuration, console-data etc only seem to get
installed at the end of the "installing the base system" step, after
which the keyboard setting works.

The more pressing issue IMO is the deletion of /sbin/start-stop-daemon.

Greetings
Marc

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

Bug#989619: task-kde-desktop: Wrong wallpaper installed on clean installation of Bullseye (Desktop & Lock)

[Andy Simpkins]

Package: task-kde-desktop
Version: 3.67
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   Testing Weekly builds of DI ready for release  (build 2021-06-07)
   
  * What exactly did you do (or not do) that was effective (or
   ineffective)?
   Clean installation into seporate VMs of all installation
media.  Only
KDE desktop is affected.  All other desktops correctly install and
select the 'Homeworld' wallpaper and lock screens.


   * What was the outcome of this action?
   KDE desktopinstallation had 'shell' as default walpaper and as
   'lockscreen'
   
  * What outcome did you expect instead?
  I expected to see 'Homeworld' as the default wallpaper and lock
screen
- it wasn't 'shell' was set as the default.
Homeworld was installed, just not as the active setting
Login screen correctly showed 'homeworld'


I beleive that this would be an embarissment if we fail to correctly
theme the default desktop on KDE by bullseye release.
Note I have also tested GNOME, XFCE, Gnome FlashBack, Cinnamon, Mate,
LXQt, LXDE all sucessfully.

/RattusRattus

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

Bug#989618: unblock: libwebp/0.6.1-2.1

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: j...@debian.org

Please unblock libwebp and age it to five days.

It fixes all open security issues. There is RC #914315
about updating to a new version, but bumping to 1.2.0
is obviously not a solution at this time of the freeze.
Still I think the RC bugs should stay open (bookworm
definitely must not release with 0.6 :-), so please tag it
bullseye-ignore.

unblock libwebp/0.6.1-2.1

Cheers,
Moritz

Debdiff:

diff -Nru libwebp-0.6.1/debian/changelog libwebp-0.6.1/debian/changelog
--- libwebp-0.6.1/debian/changelog  2018-03-01 21:51:06.0 +0100
+++ libwebp-0.6.1/debian/changelog  2021-06-05 19:35:57.0 +0200
@@ -1,3 +1,12 @@
+libwebp (0.6.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix multiple security issues: CVE-2018-25009, CVE-2018-25010, 
CVE-2018-25011
+CVE-2020-36328, CVE-2018-25013, CVE-2018-25014, CVE-2020-36329, 
CVE-2020-36330
+CVE-2020-36331, CVE-2020-36332
+
+ -- Moritz Muehlenhoff   Sat, 05 Jun 2021 19:35:57 +0200
+
 libwebp (0.6.1-2) unstable; urgency=medium
 
   * Fix lintian warning on manpage
diff -Nru libwebp-0.6.1/debian/patches/security-fixes.patch 
libwebp-0.6.1/debian/patches/security-fixes.patch
--- libwebp-0.6.1/debian/patches/security-fixes.patch   1970-01-01 
01:00:00.0 +0100
+++ libwebp-0.6.1/debian/patches/security-fixes.patch   2021-06-05 
19:34:56.0 +0200
@@ -0,0 +1,355 @@
+Patches for the following CVE IDs:
+
+CVE-2018-25009
+CVE-2018-25010
+CVE-2018-25011
+CVE-2020-36328
+CVE-2018-25013
+CVE-2018-25014
+CVE-2020-36329
+CVE-2020-36330
+CVE-2020-36331
+CVE-2020-36332
+
+Comprised of the following upstream commits:
+1344a2e947c749d231141a295327e5b99b444d63
+2c70ad76c94db5427d37ab4b85dc89b94dd75e01
+39cb9aad85ca7bb1d193013460db1f8cc6bff109
+569001f19fc81fcb5ab358f587a54c62e7c4665c
+907208f97ead639bd521cf355a2f203f462eade6
+95fd65070662e01cc9170cf5c0859a710097
+be738c6d396fa5a272c1b209be4379a7532debfe
+dad31750e374eff8e02fb467eb562d4bf236ed6e
+dce5d7643177633ebe3513af492ea8c08c299cf3
+eb82ce76ddca13ad6fb13376bb58b9fd3f850e9e
+
+--- libwebp-0.6.1.orig/src/dec/buffer_dec.c
 libwebp-0.6.1/src/dec/buffer_dec.c
+@@ -74,7 +74,8 @@ static VP8StatusCode CheckDecBuffer(cons
+   } else {// RGB checks
+ const WebPRGBABuffer* const buf = &buffer->u.RGBA;
+ const int stride = abs(buf->stride);
+-const uint64_t size = MIN_BUFFER_SIZE(width, height, stride);
++const uint64_t size =
++MIN_BUFFER_SIZE(width * kModeBpp[mode], height, stride);
+ ok &= (size <= buf->size);
+ ok &= (stride >= width * kModeBpp[mode]);
+ ok &= (buf->rgba != NULL);
+--- libwebp-0.6.1.orig/src/dec/idec_dec.c
 libwebp-0.6.1/src/dec/idec_dec.c
+@@ -283,10 +283,8 @@ static void RestoreContext(const MBConte
+ 
+ static VP8StatusCode IDecError(WebPIDecoder* const idec, VP8StatusCode error) 
{
+   if (idec->state_ == STATE_VP8_DATA) {
+-VP8Io* const io = &idec->io_;
+-if (io->teardown != NULL) {
+-  io->teardown(io);
+-}
++// Synchronize the thread, clean-up and check for errors.
++VP8ExitCritical((VP8Decoder*)idec->dec_, &idec->io_);
+   }
+   idec->state_ = STATE_ERROR;
+   return error;
+@@ -473,6 +471,12 @@ static VP8StatusCode DecodeRemaining(Web
+ MemDataSize(&idec->mem_) > MAX_MB_SIZE) {
+   return IDecError(idec, VP8_STATUS_BITSTREAM_ERROR);
+ }
++// Synchronize the threads.
++if (dec->mt_method_ > 0) {
++  if (!WebPGetWorkerInterface()->Sync(&dec->worker_)) {
++return IDecError(idec, VP8_STATUS_BITSTREAM_ERROR);
++  }
++}
+ RestoreContext(&context, dec, token_br);
+ return VP8_STATUS_SUSPENDED;
+   }
+--- libwebp-0.6.1.orig/src/dec/vp8l_dec.c
 libwebp-0.6.1/src/dec/vp8l_dec.c
+@@ -362,12 +362,19 @@ static int ReadHuffmanCodes(VP8LDecoder*
+   VP8LMetadata* const hdr = &dec->hdr_;
+   uint32_t* huffman_image = NULL;
+   HTreeGroup* htree_groups = NULL;
++  // When reading htrees, some might be unused, as the format allows it.
++  // We will still read them but put them in this htree_group_bogus.
++  HTreeGroup htree_group_bogus;
+   HuffmanCode* huffman_tables = NULL;
++  HuffmanCode* huffman_tables_bogus = NULL;
+   HuffmanCode* next = NULL;
+   int num_htree_groups = 1;
++  int num_htree_groups_max = 1;
+   int max_alphabet_size = 0;
+   int* code_lengths = NULL;
+   const int table_size = kTableSize[color_cache_bits];
++  int* mapping = NULL;
++  int ok = 0;
+ 
+   if (allow_recursion && VP8LReadBits(br, 1)) {
+ // use meta Huffman codes.
+@@ -384,10 +391,42 @@ static int ReadHuffmanCodes(VP8LDecoder*
+   // The huffman data is stored in red and green bytes.
+   const int group = (huffman_image[i] >> 8) & 0x;
+   huffman_image[i] = group;
+-  if (group >= num_htree_groups) {
+-num_htree_groups = group + 1;
++   

Bug#987726: nvidia-graphics-drivers-legacy-390xx 390.143-1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 987726 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers-legacy-390xx
Version: 390.143-1~deb10u1

Explanation: fix improper access control vulnerability [CVE‑2021‑1076]; fix 
installation failure on Linux 5.11 release candidates

Bug#988453: rust-rustyline 3.0.0-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 988453 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: rust-rustyline
Version: 3.0.0-2+deb10u1

Explanation: fix build with newer rustc

Bug#988936: mqtt-client 1.14-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 988936 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: mqtt-client
Version: 1.14-1+deb10u1

Explanation: fix denial of service issue [CVE-2019-0222]