Bug#985388: hdbm.c: add a type declaration to empty parentheses; correct type with a cast

[Bjarni Ingi Gislason]

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

Dear Maintainer,

>From 68adae10902d62c3efeacdb1f86b334e0a115f10 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 17 Mar 2021 04:20:06 +
>Subject: [PATCH] hdbm.c: add a type declaration to empty parentheses; correct
> type with a cast

hdbm.c:

  Add a type declaration to an empty parenthesis in the functions
"hdbmcreate()", "hdbmentry()", and "hdbmwalk()".

  Add a cast in comparisons of "int" versus "unsigned int".

Signed-off-by: Bjarni Ingi Gislason 
---
 hdbm.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/hdbm.c b/hdbm.c
index 6b8cbd2..1b47644 100644
--- a/hdbm.c
+++ b/hdbm.c
@@ -113,7 +113,7 @@ hdbmdef(register HDBMDATUM key)
 }
 
 HASHTABLE  *
-hdbmcreate(register unsigned size, unsigned (*hashfunc) ())
+hdbmcreate(register unsigned size, unsigned (*hashfunc) (void))
  /* size   a crude guide to size */
 {
 register HASHTABLE *tbl;
@@ -163,7 +163,7 @@ hefree(register HASHENT * hp)
 void
 hdbmdestroy(register HASHTABLE * tbl)
 {
-register unsigned idx;
+register unsigned int idx;
 register HASHENT *hp, *next;
 register HASHENT **hepp;
 register inttblsize;
@@ -172,7 +172,7 @@ hdbmdestroy(register HASHTABLE * tbl)
return;
 tblsize = tbl->ht_size;
 hepp = tbl->ht_addr;
-for (idx = 0; idx < tblsize; idx++) {
+for (idx = 0; idx < (unsigned int) tblsize; idx++) {
for (hp = hepp[idx]; hp != NULL; hp = next) {
next = hp->he_next;
hp->he_next = NULL;
@@ -208,7 +208,7 @@ hdbmfind(register HASHTABLE * tbl, HDBMDATUM key)
 hepp = >ht_addr[(*tbl->ht_hash) (key) % size];
 for (hp = *hepp; hp != NULL; prevhp = hp, hp = hp->he_next) {
hpkeydat = hp->he_key.dat_ptr;
-   if (hp->he_key.dat_len == keylen && hpkeydat[0] == keydat[0] &&
+   if (hp->he_key.dat_len == (unsigned int) keylen && hpkeydat[0] == 
keydat[0] &&
memcmp(hpkeydat, keydat, keylen) == 0)
break;
 }
@@ -257,7 +257,7 @@ hdbmstore(register HASHTABLE * tbl, HDBMDATUM key, 
HDBMDATUM data)
 
 /* return any existing entry for key; otherwise call allocator to make one */
 HDBMDATUM
-hdbmentry(register HASHTABLE * tbl, HDBMDATUM key, HDBMDATUM(*allocator) ())
+hdbmentry(register HASHTABLE * tbl, HDBMDATUM key, HDBMDATUM(*allocator) 
(HDBMDATUM))
 {
 register HASHENT *hp;
 register HASHENT **nextp;
@@ -325,7 +325,8 @@ hdbmfetch(register HASHTABLE * tbl, HDBMDATUM key)
  * the same time.
  */
 void
-hdbmwalk(HASHTABLE * tbl, register int (*nodefunc) (), 
register char *hook)
+hdbmwalk(HASHTABLE * tbl, register int (*nodefunc)
+   (HDBMDATUM, HDBMDATUM, char *), register char *hook)
  /* hook   (void *) really */
 {
 register unsigned idx;
@@ -337,7 +338,7 @@ void
return;
 hepp = tbl->ht_addr;
 tblsize = tbl->ht_size;
-for (idx = 0; idx < tblsize; idx++)
+for (idx = 0; idx < (unsigned int) tblsize; idx++)
for (hp = hepp[idx]; hp != NULL; hp = hp->he_next)
(*nodefunc) (hp->he_key, hp->he_data, hook);
 }
-- 
2.30.2



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

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

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#982262: vrrender: fails to start, missing directory

[Andreas Tille]

Hi Flavien,

On Tue, Mar 16, 2021 at 11:59:21PM +0100, Flavien Bridault wrote:
> I updated Sight to 20.3 and added a patch to fix this bug as well. VRRender
> launches well for me now.

May be you are not comfortable with the freeze policy.  We are currently
in deep freeze.  This means:
  * no new upstream versions
  * only minimum fixes for release critical bugs
  * uploads to unstable with other changes are discouraged to enable
small changes uploads for potential RC bugs

> Could you please upload the changes if everything looks ok for you ?

There are three options:

  1. I can upload your changes to experimental - but this is probably
 not really what you want.
  2. We can simply wait to fix this issue until Debian 11 is released
 and your changes are targeting to the next release
  3. The severity of the VRRender bug will be bumped to serious (which
 is release critical.  Than we need to revert the upstream version
 bump and apply only the said bug.

I have no idea what option you and the bug reporter might prefer.

> Thank you.

Thank you for your work anyway

 Andreas.

> Kind regards,
> 
> Le 14/02/2021 à 10:25, Flavien Bridault a écrit :
> > 
> > Hi Andreas,
> > 
> > I'll have a look, thanks for notifying me.
> > 
> > Cheers,
> > 
> > Le 08/02/2021 à 09:52, Andreas Tille a écrit :
> > > Hi Flavien,
> > > 
> > > I think the directory in question should be /usr/share/sight.
> > > 
> > > Could you please have a look?
> > > 
> > > Kind regards
> > > 
> > >   Andreas.
> > > 
> > > On Sun, Feb 07, 2021 at 10:49:15PM +0100, Andrea Borgia wrote:
> > > > Package: vrrender
> > > > Version: 20.2.0-1
> > > > Severity: normal
> > > > 
> > > > Dear Maintainer,
> > > > 
> > > > installing with "sudo apt install vrrender", it fails to start with 
> > > > this error:
> > > > 
> > > > [3][00:00:00.001253][warning] [RuntimeException.cpp:42] 
> > > > '/usr/lib/share/sight': not a directory.
> > > > [4][00:00:00.001322][warning] [RuntimeException.cpp:42] Error while 
> > > > adding modules. '/usr/lib/share/sight': not a directory.
> > > > terminate called after throwing an instance of 
> > > > 'fwRuntime::RuntimeException'
> > > >what():  Error while adding modules. '/usr/lib/share/sight': not a 
> > > > directory.
> > > > 
> > > > note: /usr/share/sight exists, though.
> > > > 
> > > > -- System Information:
> > > > Debian Release: bullseye/sid
> > > >APT prefers stable-updates
> > > >APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 
> > > > 'stable')
> > > > Architecture: amd64 (x86_64)
> > > > Foreign Architectures: i386
> > > > 
> > > > Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
> > > > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > > > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
> > > > LANGUAGE not set
> > > > Shell: /bin/sh linked to /bin/dash
> > > > Init: systemd (via /run/systemd/system)
> > > > LSM: AppArmor: enabled
> > > > 
> > > > Versions of packages vrrender depends on:
> > > > ii  libsight  20.2.0-1
> > > > 
> > > > vrrender recommends no packages.
> > > > 
> > > > vrrender suggests no packages.
> > > > 
> > > > -- no debconf information
> > > > 
> > > > ___
> > > > Debian-med-packaging mailing list
> > > > debian-med-packag...@alioth-lists.debian.net
> > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> > -- 
> > Flavien BRIDAULT-LOUCHEZ
> > *Dr. Flavien BRIDAULT*
> > Director of Software Development
> > IRCAD France & IRCAD Africa
> > 
> > flavien.brida...@ircad.fr 
> > Tél. : +33 (0)3 88 119 201
> > IRCAD France
> > http://www.ircad.fr/
> > http://www.ircad.africa/ 
> > 
> > Suivez l'IRCAD sur Facebook
> > 
> > 
> > *IRCAD France*
> > Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex
> > - FRANCE
> > 
> -- 
> Flavien BRIDAULT-LOUCHEZ
> *Dr. Flavien BRIDAULT*
> Director of Software Development
> IRCAD France & IRCAD Africa
> 
> flavien.brida...@ircad.fr 
> Tél. : +33 (0)3 88 119 201
>   IRCAD France
> http://www.ircad.fr/
> http://www.ircad.africa/ 
> 
> Suivez l'IRCAD sur Facebook
> 
> 
> *IRCAD France*
> Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex -
> FRANCE
> 




-- 
http://fam-tille.de

Bug#985384: [pcp] Bug#985384: pcp: Need to write permission to /var/log/pcp/pmfind/

[Nathan Scott]

Hi Yabuki,

On Wed, Mar 17, 2021 at 11:45 AM YABUKI Yukiharu  wrote:
> [...]
> Your pcp package need to give write permissions to /var/log/pcp/pmfind/
> pcp claims that it could not touch /var/log/pcp/pmfind/pmfind_check.log.

Thanks for letting us know - this will be fixed in the pcp-5.3.0 release.

cheers.

--
Nathan

Bug#985387: prefix.c: remove the prototype for *tmp_directory; add a comment

[Bjarni Ingi Gislason]

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

Dear Maintainer,

>From e0c34ce475847a65f26f5de685dae047fa22060d Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 17 Mar 2021 01:47:26 +
>Subject: [PATCH] prefix.c: remove the prototype for *tmp_directory; add a
> comment

Signed-off-by: Bjarni Ingi Gislason 
---
 prefix.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/prefix.c b/prefix.c
index b8fedb4..69480c5 100644
--- a/prefix.c
+++ b/prefix.c
@@ -16,7 +16,6 @@ extern char*help_directory;
 extern char*bin_directory;
 extern char*db_directory;
 extern char*db_data_directory;
-extern char*tmp_directory;
 extern char*log_file;
 
 #define SHELL_PREFIX   0x01
@@ -149,6 +148,10 @@ main(int argc, char *argv[])
 exit(0);
 }
 
+/* The following function definitions are necessary for making "mkprefix"
+from "prefix.o" and "global.o" and linking.
+*/
+
 void
 nn_exit(int n)
 {
-- 
2.30.2



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

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

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#985386: RM: rust-kamadak-exif/0.3.1-2

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: car...@debian.org,kpc...@rxv.cc,j...@debian.org


Hi

According to https://bugs.debian.org/985309#10 please add a removal
hint for the package 'rust-kamadak-exif' from testing.

Regards,
Salvatore

Bug#981186: linux: Enable CMN-600 interconnect on arm64

[Wookey]

There is hardware publicly available to buy now that uses the CMN-600 
interconnect so we really should turn it on for this stable release if 
at all possible.


The Ampere ALTRA:https://store.avantek.co.uk/arm-servers.html


Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

Bug#985150: systemd-udevd is trying read from unused module acpi-cpufreq

[Anonimno]

On Tue, 2021-03-16 at 21:05 +0100, Michael Biebl wrote:
> Am 16.03.21 um 21:01 schrieb Anonimno:
> > Attached please find the boot log.
> > As you can probably see, the error msg is not there directly after
> > the
> > boot. It shows up some time later. Didn't figure out, if there is a
> > specific trigger e.g. suspend or similar.
> 
> Maybe you have laptop-mode-tools or something similar installed. l-m-
> t 
> is known to do weird stuff.
> 
> Michael
> 
> 

I have TLP installed. This could be a trigger ... will take a look.
Now running for an hour or so, without suspend or similar. Nothing in
the logs until now.

Bug#985385: libstdc++-8: std::filesystem is limited to 2GB max file size on 32-bit OS

[Rosen Penev]

Package: libstdc++-8-dev
Version: 8.3.0-6
Severity: important
File: libstdc++-8
Tags: lfs newcomer

Dear Maintainer,

   * What led up to the situation?
 Using std::filesystem.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Have to use C stat function, which is not good when others add code.
   * What was the outcome of this action?
 Temporarily fixed.
   * What outcome did you expect instead?
 Permanently fixed.

   This was fixed in GCC 8.4. See 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947
   and 
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=761696abfe0a772315449e3d2b57de76756f5953


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.10.21-mvebu (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libstdc++-8-dev:armhf depends on:
ii  gcc-8-base8.3.0-6
ii  libc6-dev 2.28-10
ii  libgcc-8-dev  8.3.0-6
ii  libstdc++68.3.0-6

libstdc++-8-dev:armhf recommends no packages.

Versions of packages libstdc++-8-dev:armhf suggests:
pn  libstdc++-8-doc  

-- no debconf information

Bug#985384: pcp: Need to write permission to /var/log/pcp/pmfind/

[YABUKI Yukiharu]

Package: pcp
Version: 5.2.6-1
Severity: normal

Dear Maintainer,

Your pcp package need to give write permissions to /var/log/pcp/pmfind/
pcp claims that it could not touch /var/log/pcp/pmfind/pmfind_check.log.

```
root@Odayla:/home/yabuki# LANG=C ls -la /var/log/pcp/pmfind/
total 0
drwxr-xr-x 1 root root  0 Dec 18 06:11 .
drwxrwxr-x 1 pcp  pcp  98 Feb  4 03:25 ..
```


I realized that pcp user got a lot of mails like that:

```
From pcp@localhost Sun Jan 10 14:59:07 2021
Return-path: 
Envelope-to: pcp@localhost
Delivery-date: Sun, 10 Jan 2021 14:59:07 +0900
Received: from pcp by Odayla with local (Exim 4.94)
(envelope-from )
id 1kyTkj-00BDW0-Gl
for pcp@localhost; Sun, 10 Jan 2021 14:59:03 +0900
From: root@localhost (Cron Daemon)
To: pcp@localhost
Subject: Cron   /usr/lib/pcp/bin/pmfind_check
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Cron-Env: 
X-Cron-Env: 
X-Cron-Env: 
X-Cron-Env: 
Message-Id: 
Date: Sun, 10 Jan 2021 14:59:01 +0900

touch: '/var/log/pcp/pmfind/pmfind_check.log' に touch できません: 許可がありません
/usr/lib/pcp/bin/pmfind_check: 136: cannot create 
/var/log/pcp/pmfind/pmfind_check.log: Permission denied
```

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

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

Versions of packages pcp depends on:
ii  gawk1:5.1.0-1
ii  libc6   2.31-9
ii  libncurses6 6.2+20201114-2
ii  libncursesw66.2+20201114-2
ii  libpcp-gui2 5.2.6-1
ii  libpcp-import1  5.2.6-1
ii  libpcp-mmv1 5.2.6-1
ii  libpcp-pmda35.2.6-1
ii  libpcp-trace2   5.2.6-1
ii  libpcp-web1 5.2.6-1
ii  libpcp3 5.2.6-1
ii  libpfm4 4.11.1+git8-gc96ebc0-1
ii  libreadline88.1-1
ii  libssl1.1   1.1.1j-1
ii  libsystemd0 247.3-3
ii  libtinfo6   6.2+20201114-2
ii  libuv1  1.40.0-1
ii  procps  2:3.3.17-4
ii  python3 3.9.2-2
ii  python3-pcp 5.2.6-1

Versions of packages pcp recommends:
ii  libpcp-pmda-perl  5.2.6-1

Versions of packages pcp suggests:
pn  bpftrace
pn  libpcp-import-perl  
ii  pcp-gui 5.2.6-1
pn  redis-server

-- no debconf information

Bug#985372: [hel...@subdivi.de: Bug#985372: libxcrypt FTCBFS: glibc version detection inspects build architecture libc]

[Zack Weinberg]

Merged as 86d1e4e3815fa6c47613bda86820ee50e41ebd11, thank you for the
patch.  It's good to know someone is testing cross compilation.

zw

Bug#983776: libvkd3d-dev 1.2-3 breaks multi-arch support

[Francois Gouget]

On Tue, 16 Mar 2021, Sveinar Søpler wrote:
[...]
> > The output produced by i386 and amd64 (or any other, for that matter) builds
> > of vkd3d-compiler should be identical; if it isn't, that would be considered
> > a bug. For the record, I would be inclined to agree that the -dev package is
> > not the appropriate place for vkd3d-compiler.
> 
> How would vkd3d-compiler be identical regardless of arch?

It's not vkd3d-compiler that's identical regardless of arch. It's the 
output of vkd3d-compiler which is.

What this means is it makes sense to put vkd3d-compiler in its own 
package with Multi-Arch: foreign.

-- 
Francois Gouget   http://fgouget.free.fr/
   Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

Bug#985150: systemd-udevd is trying read from unused module acpi-cpufreq

[Anonimno]

On Tue, 2021-03-16 at 21:04 +0100, Michael Biebl wrote:
> Am 16.03.21 um 21:01 schrieb Anonimno:
> > Attached please find the boot log.
> > As you can probably see, the error msg is not there directly after
> > the
> > boot. It shows up some time later. Didn't figure out, if there is a
> > specific trigger e.g. suspend or similar.
> 
> Ok, we need a journal log from when the problem shows up.
> 
> 

I will keep the laptop powered on and have a look every once in a while
in the logs. As soon as it pops up, you'll get it :).

Bug#954794: Permit packages to declare dependencies on Essential packages

[Javier Serrano Polo]

On Mon, 16 Nov 2020 16:11:53 -0800 Jonathan Nieder 
wrote:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=nonessentiale2fsprogs;users=helm...@debian.org
> shows that people are already adding explicit dependencies on it,
> which means that
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954794;msg=111 is
> the de facto policy / what people believe policy to say.

So, should policy change? Currently, it says that packages "should not"
declare essential dependencies, which is more permissive than "must
not". Is the workflow with e2fsprogs the path to follow?

smime.p7s
Description: S/MIME cryptographic signature

Bug#982803: procps: broken alternative for /usr/bin/w left on the system

[Paul Wise]

On Thu, 2021-03-11 at 18:29 +0800, Paul Wise wrote:

> The alternative could have been removed in the new preinst before
> /usr/bin/w is removed by dpkg during the upgrade process.
> 
> https://www.debian.org/doc/debian-policy/ap-flowcharts.html

Should I file a new bug about switching to this?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#960727: errors during upgrade

[Paul Wise]

Package: python3-lib2to3
Version: 3.9.2-1
Followup-For: Bug #960727

Errors still happen in clean chroot in upgrade from buster to bullseye:

   $ sudo cowbuilder --login --basepath /var/cache/pbuilder/base.cow.buster/
   ...
   # apt install python3-lib2to3 ; sed -i s/buster/bullseye/ 
/etc/apt/sources.list ; apt update ; apt upgrade ; apt dist-upgrade
   ...
   Setting up python3-lib2to3 (3.7.3-1) ...
   ...
   Preparing to unpack .../python3-lib2to3_3.9.2-1_all.deb ...
   Unpacking python3-lib2to3 (3.9.2-1) over (3.7.3-1) ...
   ...
   Setting up python3-lib2to3 (3.9.2-1) ...
   find: '/usr/lib/python3.7/lib2to3': No such file or directory
   find: '/usr/lib/python3.7/lib2to3': No such file or directory

-- System Information:
Debian Release: bullseye/sid
  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-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 python3-lib2to3 depends on:
ii  python3  3.9.2-2

python3-lib2to3 recommends no packages.

python3-lib2to3 suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#985383: auditd: Stopping of auditd service cause segmentation fault

[Mortuza Ali]

Package: auditd
Version: 1:2.8.4-3
Severity: important
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
Stop auditd service using 'service auditd stop'
Modify the following settings in /etc/audit/auditd.conf:
 write_logs = no
 #log_file = 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Start the auditd service using 'service auditd start'; and then
 Stop the auditd service using 'service auditd stop'
 Check the status of auditd using 'service auditd status'

   * What was the outcome of this action?
 auditd status is showing the following:

● auditd.service - Security Auditing Service
   Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: 
enabled)
   Active: failed (Result: core-dump) since Wed 2021-03-17 09:39:27 ACDT; 2s ago
 Docs: man:auditd(8)
   https://github.com/linux-audit/audit-documentation
  Process: 9564 ExecStart=/sbin/auditd (code=exited, status=0/SUCCESS)
  Process: 9569 ExecStartPost=/sbin/augenrules --load (code=exited, 
status=0/SUCCESS)
 Main PID: 9565 (code=dumped, signal=SEGV)
 
   * What outcome did you expect instead?
 Expected auditd not to seg fault. Following is the expected
 outcome:

 ● auditd.service - Security Auditing Service
   Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: 
enabled)
   Active: inactive (dead) since Wed 2021-03-17 10:04:16 ACDT; 1s ago
 Docs: man:auditd(8)
   https://github.com/linux-audit/audit-documentation
  Process: 9705 ExecStart=/sbin/auditd (code=exited, status=0/SUCCESS)
  Process: 9710 ExecStartPost=/sbin/augenrules --load (code=exited, 
status=0/SUCCESS)
 Main PID: 9706 (code=exited, status=0/SUCCESS)

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

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

Versions of packages auditd depends on:
ii  libaudit1 1:2.8.4-3
ii  libauparse0   1:2.8.4-3
ii  libc6 2.28-10
ii  libgssapi-krb5-2  1.17-3+deb10u1
ii  libkrb5-3 1.17-3+deb10u1
ii  libwrap0  7.6.q-28
ii  lsb-base  10.2019051400
ii  mawk  1.3.3-17+b3

auditd recommends no packages.

Versions of packages auditd suggests:
pn  audispd-plugins  

-- Configuration Files:
/etc/audisp/audispd.conf [Errno 13] Permission denied: 
'/etc/audisp/audispd.conf'
/etc/audisp/plugins.d/af_unix.conf [Errno 13] Permission denied: 
'/etc/audisp/plugins.d/af_unix.conf'
/etc/audisp/plugins.d/syslog.conf [Errno 13] Permission denied: 
'/etc/audisp/plugins.d/syslog.conf'
/etc/audit/audit-stop.rules [Errno 13] Permission denied: 
'/etc/audit/audit-stop.rules'
/etc/audit/auditd.conf [Errno 13] Permission denied: '/etc/audit/auditd.conf'
/etc/audit/rules.d/audit.rules [Errno 13] Permission denied: 
'/etc/audit/rules.d/audit.rules'

-- no debconf information

Bug#985382: hdbmint.h: add a type declaration to an empty parenthesis

[Bjarni Ingi Gislason]

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

Dear Maintainer,

>From 4a86cb235c7fe0faaa4cff0c5fff8c52ccf59e2b Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Tue, 16 Mar 2021 23:01:30 +
>Subject: [PATCH] hdbmint.h: add a type declaration to an empty parenthesis

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

diff --git a/hdbmint.h b/hdbmint.h
index afb3aaf..99a5a84 100644
--- a/hdbmint.h
+++ b/hdbmint.h
@@ -69,5 +69,6 @@ HASHTABLE {
 HASHENT   **ht_addr;   /* array of HASHENT pointers */
 unsignedht_size;
 unsigned char   ht_magic;
-unsigned(*ht_hash) ();
+/*unsigned(*ht_hash) (); original line */
+unsigned(*ht_hash) (HDBMDATUM);
 };
-- 
2.30.2



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

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

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#981586: Bullseye armhf kernel for Raspberry Pi 4b does not boot

[LinAdmin]

I just wonder why the famous experts maintaining this
extremely useful multi arch armhf kernel preferred to close
former errors with the lame excuse that for Pi4 one should
use arm64 which shows considerable lower throughput.

All it needs to get a kernel booting on Pi4 is changing
three switches in menuconfig:

CONFIG_PCIE_BRCMSTB=y

CONFIG_RESET_RASPERBERRY=y

RESET_BRCMSTB_RESCAL=y

The resulting kernel is a few KB bigger but does still boot
on the other relevant hardware I own: Banana Pi & exynos board.

LinAdmin

Bug#982262: vrrender: fails to start, missing directory

[Flavien Bridault]

Good evening Andreas,

I updated Sight to 20.3 and added a patch to fix this bug as well. 
VRRender launches well for me now.


Could you please upload the changes if everything looks ok for you ?

Thank you.

Kind regards,

Le 14/02/2021 à 10:25, Flavien Bridault a écrit :


Hi Andreas,

I'll have a look, thanks for notifying me.

Cheers,

Le 08/02/2021 à 09:52, Andreas Tille a écrit :

Hi Flavien,

I think the directory in question should be /usr/share/sight.

Could you please have a look?

Kind regards

  Andreas.

On Sun, Feb 07, 2021 at 10:49:15PM +0100, Andrea Borgia wrote:

Package: vrrender
Version: 20.2.0-1
Severity: normal

Dear Maintainer,

installing with "sudo apt install vrrender", it fails to start with this error:

[3][00:00:00.001253][warning] [RuntimeException.cpp:42] '/usr/lib/share/sight': 
not a directory.
[4][00:00:00.001322][warning] [RuntimeException.cpp:42] Error while adding 
modules. '/usr/lib/share/sight': not a directory.
terminate called after throwing an instance of 'fwRuntime::RuntimeException'
   what():  Error while adding modules. '/usr/lib/share/sight': not a directory.

note: /usr/share/sight exists, though.

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

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

Versions of packages vrrender depends on:
ii  libsight  20.2.0-1

vrrender recommends no packages.

vrrender suggests no packages.

-- no debconf information

___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

--
Flavien BRIDAULT-LOUCHEZ
*Dr. Flavien BRIDAULT*
Director of Software Development
IRCAD France & IRCAD Africa

flavien.brida...@ircad.fr 
Tél. : +33 (0)3 88 119 201
IRCAD France
http://www.ircad.fr/
http://www.ircad.africa/ 

Suivez l'IRCAD sur Facebook 



*IRCAD France*
Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg 
Cedex - FRANCE



--
Flavien BRIDAULT-LOUCHEZ
*Dr. Flavien BRIDAULT*
Director of Software Development
IRCAD France & IRCAD Africa

flavien.brida...@ircad.fr 
Tél. : +33 (0)3 88 119 201
IRCAD France
http://www.ircad.fr/
http://www.ircad.africa/ 

Suivez l'IRCAD sur Facebook 



*IRCAD France*
Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex 
- FRANCE




OpenPGP_signature
Description: OpenPGP digital signature

Bug#985339: nauty: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

On 16/03/2021 16.05, Andrius Merkys wrote:

symlink_to_dir /usr/share/doc/nauty libnauty2 2.7r1+ds-1~


That looks correct.


 From this I gather that upgrades of nauty <= 2.7r1+ds-1 to this new
version should trigger the replacement of a symlink with real directory
before placing the files inside. Or am I wrong?


In buster we have
  /usr/share/doc/nauty -> libnauty2
but in jessie we had
  /usr/share/doc/nauty -> /usr/share/doc/libnauty2

and that is not caught by the maintscript entry.

The following should catch both cases:

symlink_to_dir /usr/share/doc/nauty /usr/share/doc/libnauty2 2.7r1+ds-2~

I'll try to test that ...


Andreas

Bug#982929: systemd: upstream testsuite failures on armhf

[Ryutaroh Matsumoto]

Hi Michael,

Thanks again for your attention.

>> Architecture: arm64 (aarch64)
> Might be an issue of trying to execute armhf on a arm64 kernel.

It was an error in testsuites running on linux-image-armmp-lpae on
qemu-system-arm, so the above should not be the case.

> But I'm no expert on this and I don't have the necessary hardware to
> try this,

Since it happens on qemu-system-arm, in an ideal world, any Debian amd64
host should be able to reproduce this symptom... (we are not living in an
ideal world)

so could you please raise this upstream yourself and report
> back with the issue number?

I will do it after I return from my travel.

> It's likely that upstream has follow-up questions.

Best regards, Ryutaroh

Bug#985381: match.c: add a prototype for the function "regexec_cf()"

[Bjarni Ingi Gislason]

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

Dear Maintainer,

>From 93542a17c334bcdb6583b3d61203a5918a9b68c6 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Tue, 16 Mar 2021 03:17:17 +
>Subject: [PATCH] match.c: add a prototype for the function "regexec_cf()"

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

diff --git a/match.c b/match.c
index 6f1969b..22b7033 100644
--- a/match.c
+++ b/match.c
@@ -12,6 +12,7 @@
 
 /* prototypes */
 void   fold_string(register char *);
+intregexec_cf(register regexp *, char *);
 intregexec_fold(register regexp * , char *);
 intstrmatch(char *, register char *);
 intstrmatch_cf(char *, char *);
-- 
2.30.2



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

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

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#985380: unblock: dnsviz/0.9.3-1

[Robert Edmonds]

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

Hi,

I'd like to unblock the dnsviz package. The 0.9.3 upstream release
specifically targets the release of bullseye. Per the upstream author
(X-Debbugs-Cc'd):

"FYI, it looks like I'm going to need to push one more fix, as
version 0.9.3.  There was some backwards incompatibility introduced
in dnspython 2.0 that I didn't find until after 0.9.2.  Since
dnspython 2.0 is what is in bullseye, it will be important to have
that fix."

Further details are available at:

 * https://github.com/dnsviz/dnsviz/issues/74

 * 
https://github.com/dnsviz/dnsviz/commit/37864bba6a90aaa634a9f867c32ed553b2780b9c

The debdiff is attached. It is very similar to the diff between the
upstream tags v0.9.2 and v0.9.3:

 * https://github.com/dnsviz/dnsviz/compare/v0.9.2...v0.9.3

The bullseye freeze policy advises that,

"In most cases, it's not appropriate to upload a new upstream
release at this point. New upstream release usually contain
unrelated changes, which might be inappropriate or make review much
more difficult. Uploading a new upstream release is only appropriate
when the resulting debdiff doesn't contain changes that wouldn't be
in the debdiff of a targeted change."

In this case, the entirety of the changes in the new upstream release
contain the targeted fix (other than trivial changes due to the upstream
version number bump).

Thanks.

unblock dnsviz/0.9.3-1

-- 
Robert Edmonds
edmo...@debian.org
diff -Nru dnsviz-0.9.2/PKG-INFO dnsviz-0.9.3/PKG-INFO
--- dnsviz-0.9.2/PKG-INFO	2021-02-05 23:49:51.0 -0500
+++ dnsviz-0.9.3/PKG-INFO	2021-03-11 18:03:26.0 -0500
@@ -1,6 +1,6 @@
 Metadata-Version: 1.1
 Name: dnsviz
-Version: 0.9.2
+Version: 0.9.3
 Summary: DNS analysis and visualization tool suite
 Home-page: https://github.com/dnsviz/dnsviz/
 Author: Casey Deccio
diff -Nru dnsviz-0.9.2/contrib/dnsviz.spec dnsviz-0.9.3/contrib/dnsviz.spec
--- dnsviz-0.9.2/contrib/dnsviz.spec	2021-02-05 23:49:19.0 -0500
+++ dnsviz-0.9.3/contrib/dnsviz.spec	2021-03-11 18:03:07.0 -0500
@@ -1,5 +1,5 @@
 Name:   dnsviz
-Version:0.9.2
+Version:0.9.3
 Release:1%{?dist}
 Summary:Tools for analyzing and visualizing DNS and DNSSEC behavior
 
@@ -58,6 +58,8 @@
 %{_mandir}/man1/%{name}-query.1*
 
 %changelog
+* Thu Mar  11 2021 Casey Deccio
+  0.9.3 release
 * Fri Feb  5 2021 Casey Deccio
   0.9.2 release
 * Tue Jan  19 2021 Casey Deccio
diff -Nru dnsviz-0.9.2/debian/changelog dnsviz-0.9.3/debian/changelog
--- dnsviz-0.9.2/debian/changelog	2021-02-06 17:55:58.0 -0500
+++ dnsviz-0.9.3/debian/changelog	2021-03-16 16:46:46.0 -0400
@@ -1,3 +1,10 @@
+dnsviz (0.9.3-1) unstable; urgency=medium
+
+  * New upstream version 0.9.3
+- Targeted upstream fix for dnspython 2.0.0
+
+ -- Robert Edmonds   Tue, 16 Mar 2021 16:46:46 -0400
+
 dnsviz (0.9.2-1) unstable; urgency=medium
 
   * New upstream version 0.9.2
diff -Nru dnsviz-0.9.2/debian/patches/debian-changes dnsviz-0.9.3/debian/patches/debian-changes
--- dnsviz-0.9.2/debian/patches/debian-changes	2021-02-06 17:55:58.0 -0500
+++ dnsviz-0.9.3/debian/patches/debian-changes	2021-03-16 16:46:46.0 -0400
@@ -8,72 +8,72 @@
 
 For full commit history and separated commits, see the packaging Git
 repository.
 dnsviz-0.9.2.orig/bin/dnsviz
-+++ dnsviz-0.9.2/bin/dnsviz
+--- dnsviz-0.9.3.orig/bin/dnsviz
 dnsviz-0.9.3/bin/dnsviz
 @@ -1,4 +1,4 @@
 -#!/usr/bin/env python
 +#!/usr/bin/env python3
  #
  # This file is a part of DNSViz, a tool suite for DNS/DNSSEC monitoring,
  # analysis, and visualization.
 dnsviz-0.9.2.orig/contrib/digviz
-+++ dnsviz-0.9.2/contrib/digviz
+--- dnsviz-0.9.3.orig/contrib/digviz
 dnsviz-0.9.3/contrib/digviz
 @@ -1,4 +1,4 @@
 -#!/usr/bin/env python
 +#!/usr/bin/env python3
  #
  # This file is a part of DNSViz, a tool suite for DNS/DNSSEC monitoring,
  # analysis, and visualization.
 dnsviz-0.9.2.orig/contrib/dnsviz-lg.cgi
-+++ dnsviz-0.9.2/contrib/dnsviz-lg.cgi
+--- dnsviz-0.9.3.orig/contrib/dnsviz-lg.cgi
 dnsviz-0.9.3/contrib/dnsviz-lg.cgi
 @@ -1,4 +1,4 @@
 -#!/usr/bin/env python
 +#!/usr/bin/env python3
  #
  # This file is a part of DNSViz, a tool suite for DNS/DNSSEC monitoring,
  # analysis, and visualization.
 dnsviz-0.9.2.orig/dnsviz/commands/graph.py
-+++ dnsviz-0.9.2/dnsviz/commands/graph.py
+--- dnsviz-0.9.3.orig/dnsviz/commands/graph.py
 dnsviz-0.9.3/dnsviz/commands/graph.py
 @@ -1,4 +1,4 @@
 -#!/usr/bin/env python
 +#!/usr/bin/env python3
  #
  # This file is a part of DNSViz, a tool suite for DNS/DNSSEC monitoring,
  # analysis, and visualization.
 dnsviz-0.9.2.orig/dnsviz/commands/grok.py
-+++ dnsviz-0.9.2/dnsviz/commands/grok.py
+--- dnsviz-0.9.3.orig/dnsviz/commands/grok.py
 dnsviz-0.9.3/dnsviz/commands/grok.py
 @@ -1,4 +1,4 @@
 -#!/usr/bin/env python
 

Bug#985367: " w file" writes whole file; deleting last byte broken

[Philipp Marek]

Package: hexer
Version: 1.0.6-1
Severity: normal
X-Debbugs-Cc: phil...@marek.priv.at

When doing a visual selection in a file and trying to write it to disk 
(via pressing ":" (this inserts the range) and then " w /tmp/file"),
the whole source file is written with a name of "/tmp/file",
eg as "/tmp/font.ttf0x16a76,0x1b0b5".

Furthermore, with the cursor on the last byte "x" in normal mode doesn't 
delete the byte; similarly, a visual range including the last byte 
doesn't accept "x" to delete this range.

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

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

Versions of packages hexer depends on:
ii  libc6  2.31-9
ii  libtinfo6  6.2+20201114-2

hexer recommends no packages.

hexer suggests no packages.

-- no debconf information

Bug#985046: mc: cannot view zip file containing pdf

[Daniel Serpell]

Package: mc
Version: 3:4.8.26-1
Followup-For: Bug #985046

Hi,

The bad commit is this:
  
https://github.com/MidnightCommander/mc/commit/8857423e4ebb770b6f0ea3103abf5d35c85fcbe8

This also broke viewing ZIP files in which the first member is any image
(jpg, png, etc), as they are opened by imagemagic that can't handle ZIP
files, also if a ZIP file has multiple images, I don't want to see only
the first!

Error on pressing F3:
  identify-im6.q16: no decode delegate for this image format `ZIP' @ 
error/constitute.c/ReadImage/575.

Thanks,


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

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

Versions of packages mc depends on:
ii  libc6 2.31-9
ii  libext2fs21.46.2-1
ii  libglib2.0-0  2.66.7-2
ii  libgpm2   1.20.7-8
ii  libslang2 2.3.2-5
ii  libssh2-1 1.9.0-2
ii  mc-data   3:4.8.26-1

Versions of packages mc recommends:
ii  mime-support3.66
ii  perl5.32.1-3
ii  sensible-utils  0.0.14
ii  unzip   6.0-26

Versions of packages mc suggests:
pn  arj  
ii  bzip21.0.8-4
pn  dbview   
pn  djvulibre-bin
pn  epub-utils   
ii  evince [pdf-viewer]  3.38.2-1
ii  file 1:5.39-3
ii  genisoimage  9:1.1.11-3.2
pn  gv   
ii  imagemagick  8:6.9.11.60+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1
pn  libaspell-dev
pn  odt2txt  
ii  poppler-utils20.09.0-3.1
pn  python   
pn  python-boto  
pn  python-tz
ii  texlive-binaries 2020.20200327.54578-7
ii  unar 1.10.1-2+b6
ii  w3m  0.5.3+git20210102-6
ii  wimtools 1.13.3-1
ii  zip  3.0-12

-- no debconf information

Bug#787080: Bug#894119: libreoffice: Please add libreoffice-online to the debian repository.

[Adi Kriegisch]

Dear Rene,

thank you very much for the hard work you've put in packaging libreoffice
online. Starting from your salsa repo[1] I was able to successfully build
loolwsd and loleaflet packages with the libreoffice packages from
buster-backports. There were, however, some issues with the unit tests.
After trying to investigate some of the issues, I decided to skip the test
by adding an empty override_dh_auto_test target.

Is there any reason why you use loolwsd's init script to configure it
instead of setting the defaults in /etc/loolwsd/loolwsd.xml? With the
current init script this does not work.
May I suggest to use a simpler init script like this one:
8<-8<-8<-8<-8<-8<-8<-8<-
#!/bin/sh
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
### BEGIN INIT INFO
# Provides:  loolwsd
# Required-Start:$remote_fs 
# Required-Stop: $remote_fs 
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: libreoffice online server
# Description:   libreoffice online server
### END INIT INFO

DESC="libreoffice online server" 
DAEMON=/usr/bin/loolwsd
DAEMON_ARGS="--daemon"
START_ARGS="--chuid lool --user lool"
->8->8->8->8->8->8->8->8

I very much hope, you're going to continue your excellent work and
libreoffice online hits the debian archive any time in a not too distant
future! ;-)

best regards,
Adi Kriegisch

[1] https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-online/


signature.asc
Description: PGP signature

Bug#985379: podman: fails to run on freshly installed Bullseye, runtime "crun" not found: invalid argument

[Filippo Giunchedi]

Package: podman
Version: 3.0.1+dfsg1-1
Severity: important

This is the same as #971253. Specifically, 'runc' is installed as the first
Depend, however podman defaults to 'crun'. I think podman should depend on
'crun' first so it works out of the box (and with cgroups v2).

root@host1:~# podman images
Error: default OCI runtime "crun" not found: invalid argument
root@host1:~# ls -la /etc/containers/containers.conf
ls: cannot access '/etc/containers/containers.conf': No such file or directory


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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages podman depends on:
ii  conmon   2.0.25+ds1-1
ii  containernetworking-plugins  0.9.0-1+b2
ii  crun 0.17+dfsg-1
ii  golang-github-containers-common  0.33.4+ds1-1
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libgpgme11   1.14.0-1+b2
ii  libseccomp2  2.5.1-1
ii  runc 1.0.0~rc93+ds1-2+b1

Versions of packages podman recommends:
ii  buildah   1.19.6+dfsg1-1
ii  catatonit 0.1.5-2
ii  fuse-overlayfs1.4.0-1
ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b3
ii  slirp4netns   1.0.1-1
ii  tini  0.19.0-1
ii  uidmap1:4.8.1-1

Versions of packages podman suggests:
ii  containers-storage  1.24.8+dfsg1-1
pn  docker-compose  

-- no debconf information

Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)

[Samuel Thibault]

Paul Gevers, le mar. 16 mars 2021 22:08:51 +0100, a ecrit:
>  wrote:
> > So we'd rather make release-notes document using apt instead of
> > apt-get? I'm fine with that but we *ALSO* need to make sure that debian
> > developers actually *test* that path, and not the apt-get path.
> 
> Already the buster release notes talk about using apt instead of apt-get

Mmm, actually no, it tells to use "apt-get upgrade"

https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade

Possibly this should be turned to 

"apt upgrade --without-new-pkgs"

?

Otherwise people will continue replacing apt-get with apt in "apt-get
upgrade" without knowing that they are really different, and get
upgrading bugs that maintainers that use "apt-get upgrade" (expectedly)
do not get.

> and even has a note about the difference [1]. I'm not aware (but I don't
> follow user facing help channels) that this has lead to problems that
> would have been prevented with sticking to apt-get.

I did see some users getting upgrading issues when running
"apt upgrade", while "apt-get upgrade" first would have solved them.

Samuel

Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)

[Paul Gevers]

Control: tags -1 moreinfo

Hi Samuel,

On Tue, 15 Dec 2020 16:27:35 +0100 Samuel Thibault
 wrote:
> So we'd rather make release-notes document using apt instead of
> apt-get? I'm fine with that but we *ALSO* need to make sure that debian
> developers actually *test* that path, and not the apt-get path.

Already the buster release notes talk about using apt instead of apt-get
and even has a note about the difference [1]. I'm not aware (but I don't
follow user facing help channels) that this has lead to problems that
would have been prevented with sticking to apt-get.

I agree apt should be tested, but I don't know how to fix that. What do
you propose we change in the release notes?

Paul

[1]
https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html#upgradingpackages



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985150: systemd-udevd is trying read from unused module acpi-cpufreq

[Michael Biebl]

Am 16.03.21 um 22:01 schrieb Anonimno:

On Tue, 2021-03-16 at 21:05 +0100, Michael Biebl wrote:

Am 16.03.21 um 21:01 schrieb Anonimno:

Attached please find the boot log.
As you can probably see, the error msg is not there directly after
the
boot. It shows up some time later. Didn't figure out, if there is a
specific trigger e.g. suspend or similar.


Maybe you have laptop-mode-tools or something similar installed. l-m-
t
is known to do weird stuff.

Michael




I have TLP installed. This could be a trigger ... will take a look.
Now running for an hour or so, without suspend or similar. Nothing in
the logs until now.



Please uninstall tlp and see if that helps



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985369: Banana Pi Call Trace in sound/core/init.c:207 snd_card_new+0x430/0x480 [snd]

[Andrei POPESCU]

Control: reassign -1 src:linux 5.10.19-1

On Ma, 16 mar 21, 19:26:43, Tuxo wrote:
> Package: 5.10.0-4-armmp-lpae
> Version: Debian 5.10.19-1: armhf
> 
> Call Trace coming up:
> 
> [  +0.303626] [ cut here ]
> [  +0.008081] WARNING: CPU: 0 PID: 248 at sound/core/init.c:207
> snd_card_new+0x430/0x480 [snd]
> [  +0.007999] Modules linked in: sun4i_codec(E+) snd_soc_core(E)
> snd_pcm_dmaengine(E) snd_pcm(E) nvmem_sunxi_sid(E) sun4i_ts(E) sg(E)
> snd_timer(E) snd(E) sunxi_cir(E) soundcore(E) rc_core(E) sun4i_ss(E+)
> libdes(E) sunxi_wdt(E) sunxi_cedrus(CE) videobuf2_dma_contig(E)
> v4l2_mem2mem(E) videobuf2_memops(E) videobuf2_v4l2(E) videobuf2_common(E)
> leds_gpio(E) cpufreq_dt(E) fuse(E) configfs(E) sunrpc(E) ip_tables(E)
> x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) btrfs(E)
> blake2b_generic(E) xor(E) xor_neon(E) raid6_pq(E) libcrc32c(E)
> crc32c_generic(E) f2fs(E) crc32_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E)
> crct10dif_generic(E) crct10dif_common(E) axp20x_usb_power(E) industrialio(E)
> pinctrl_axp209(E) axp20x_regulator(E) realtek(E) sun4i_backend(E)
> dwmac_sunxi(E) stmmac_platform(E) stmmac(E) ohci_platform(E) pcs_xpcs(E)
> phylink(E) ahci_sunxi(E) ehci_platform(E) ohci_hcd(E) libahci_platform(E)
> ptp(E) libahci(E) sunxi(E) phy_generic(E) lima(E) libata(E) gpu_sched(E)
> musb_hdrc(E)
> [  +0.000354]  pps_core(E) ehci_hcd(E) udc_core(E) i2c_mv64xxx(E)
> scsi_mod(E) sun4i_drm_hdmi(E) usbcore(E) cec(E) spi_sun4i(E) sunxi_mmc(E)
> phy_sun4i_usb(E) sun4i_drm(E) sun4i_frontend(E) sun4i_tcon(E)
> sun8i_tcon_top(E) drm_kms_helper(E) display_connector(E) drm(E)
> [  +0.064237] CPU: 0 PID: 248 Comm: systemd-udevd Tainted: G C E
> 5.10.0-4-armmp-lpae #1 Debian 5.10.19-1
> [  +0.010143] Hardware name: Allwinner sun7i (A20) Family
> [  +0.010019] Backtrace:
> [  +0.009907] [] (dump_backtrace) from []
> (show_stack+0x20/0x24)
> [  +0.010172]  r7:00cf r6:600f0113 r5: r4:c16d04d0
> [  +0.010253] [] (show_stack) from []
> (dump_stack+0xc8/0xdc)
> [  +0.010012] [] (dump_stack) from []
> (__warn+0xfc/0x158)
> [  +0.010183]  r7:00cf r6:0009 r5:bf6e1604 r4:bf6eb01c
> [  +0.010016] [] (__warn) from []
> (warn_slowpath_fmt+0x70/0xe4)
> [  +0.010317]  r7:bf6e1604 r6:00cf r5:bf6eb01c r4:
> [  +0.010074] [] (warn_slowpath_fmt) from []
> (snd_card_new+0x430/0x480 [snd])
> [  +0.010305]  r8:c2e0f8c4 r7:c1a3ec10 r6: r5:c2ca3000 r4:
> [  +0.010210] [] (snd_card_new [snd]) from []
> (snd_soc_bind_card+0x3a8/0xa30 [snd_soc_core])
> [  +0.010262]  r10: r9:bf759d8c r8:c1a26e80 r7:0001 r6:0050
> r5:c2e0f840
> [  +0.010202]  r4:c2bc2d00
> [  +0.010557] [] (snd_soc_bind_card [snd_soc_core]) from
> [] (snd_soc_register_card+0xf8/0x108 [snd_soc_core])
> [  +0.010486]  r10:0024 r9:bf733170 r8:c1a26e80 r7:bf72e6f4 r6:c1a3ec10
> r5:c2bd4a00
> [  +0.010532]  r4:c2e0f840
> [  +0.010512] [] (snd_soc_register_card [snd_soc_core]) from
> [] (sun4i_codec_probe+0x230/0x468 [sun4i_codec])
> [  +0.011003]  r5:c2bd4a00 r4:0002
> [  +0.010799] [] (sun4i_codec_probe [sun4i_codec]) from
> [] (platform_drv_probe+0x58/0xa8)
> [  +0.011063]  r8: r7:c17f1de0 r6:bf733170 r5:c1a3ec10 r4:
> [  +0.011147] [] (platform_drv_probe) from []
> (really_probe+0x108/0x514)
> [  +0.011228]  r7:c17f1de0 r6: r5:c17f1dd8 r4:c1a3ec10
> [  +0.011134] [] (really_probe) from []
> (driver_probe_device+0x100/0x1d4)
> [  +0.16]  r10:bf733940 r9:c1604e00 r8:c2f15f30 r7:bf733170 r6:c1a3ec54
> r5:bf733170
> [  +0.06]  r4:c1a3ec10
> [  +0.15] [] (driver_probe_device) from []
> (device_driver_attach+0xb8/0xc0)
> [  +0.10]  r9:c1604e00 r8:c2f15f30 r7:bf733170 r6:c1a3ec54 r5:
> r4:c1a3ec10
> [  +0.12] [] (device_driver_attach) from []
> (__driver_attach+0x9c/0x150)
> [  +0.18]  r7:c17579a8 r6:c1a3ec10 r5:bf733170 r4:
> [  +0.079177] [] (__driver_attach) from []
> (bus_for_each_dev+0x84/0xd0)
> [  +0.16]  r7:c17579a8 r6:c0aac58c r5:bf733170 r4:
> [  +0.13] [] (bus_for_each_dev) from []
> (driver_attach+0x2c/0x30)
> [  +0.08]  r6: r5:c2f71780 r4:bf733170
> [  +0.11] [] (driver_attach) from []
> (bus_add_driver+0x120/0x20c)
> [  +0.13] [] (bus_add_driver) from []
> (driver_register+0x98/0x128)
> [  +0.08]  r7: r6:bf733a70 r5: r4:bf733170
> [  +0.13] [] (driver_register) from []
> (__platform_driver_register+0x50/0x58)
> [  +0.07]  r5:c2fbe300 r4:c17579a8
> [  +0.53] [] (__platform_driver_register) from []
> (sun4i_codec_driver_init+0x24/0x1000 [sun4i_codec])
> [  +0.06]  r5:c2fbe300 r4:bf704000
> [  +0.24] [] (sun4i_codec_driver_init [sun4i_codec]) from
> [] (do_one_initcall+0x50/0x27c)
> [  +0.14] [] (do_one_initcall) from []
> (do_init_module+0x70/0x2a4)
> [  +0.09]  r7:c2f15ea8 r6:bf733a70 r5:c2fbe300 r4:bf733940
> [  +0.10] [] (do_init_module) from []
> (load_module+0x2260/0x264c)
> [  +0.08]  r6:bf733a70 

Bug#985378: unblock: boost1.74/1.74.0-9

[Anton Gladky]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package boost1.74

boost1.74_1.74.0-9 fixes RC-bug #984838
Diff is attached.


unblock boost1.74/1.74.0-9

Thanks

Anton Gladky

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmBRF0IRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYT0g//YZuOhL9/699+0fNcMECh1UX/rtCGE7Ee
jlaU9j3fIbRLIDe/SDzGF4EOJmlR64I4h+tzde3ze4YCdvueVVXRcGLXX3aobROr
GYnGXiDvEWTL3ZUA65aGZVLNcy5ytjrUtC2Y3xLi4Ti4w0oxmih+F5hKE6OmU3BD
SRJBi8XPJ2AAiItydo3gR89l9jK5sau9yiM7IBNiCT5CWXpzWwrH+DyDuvvOqTAG
SGlkl0Ppl4i/bGe+VjrBw0uO2I7gBwie613ybRevFXEu8op00Ei30N/y2RqTyXqq
14W/Cql2iOHN3vyLzfZiyyWLk9JXslPzwEwWEL5KpeCYk3CA+Csdj1rRnnIKMNL+
lM+jEloYENhhu7+sM2E8su8slUsFKBauPc6U+jCUrWsBztkIzxTz+mrVMSqmkIBW
9ZyE1R0xrTtiQ+kjQMAsfnbOWNJ2XZ/1QeVaYcoLL8AbWSIXWZVJsBrb8dZMpENW
kV95pgn3wDbwtxpsXnxXfOjpdQuwfOM2u2D277reCf46KURTm8PO7lb2oqlK9DiN
32sIceQUnuQIYVSPzreRUbe3JV9cIyapLGZU1fn4McLE8x4ups2DNXFXMdpG3e5o
S1G1GY6zf+Ay1pICy4zLr6eEzDcOKoiM3Y67WNMzBtnZrrggc1dN916J7TuQP3vC
0KOP2eosxHA=
=Pwa4
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index 0d4a3cf10..98695eea4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+boost1.74 (1.74.0-9) unstable; urgency=medium
+
+  [ Andreas Beckmann ]
+  * libboost1.74-dev: Smoothen upgrades from buster by depending on
+libstdc++-${gxx:major}-dev using the build-time version of g++ instead of
+the virtual libstdc++-dev provided by multiple packages.
+(Closes: #984838)
+
+ -- Anton Gladky   Sat, 13 Mar 2021 09:21:38 +0100
+
 boost1.74 (1.74.0-8) unstable; urgency=medium
 
   * [85a2610] Fix compilation warnings. (Closes: #980497)
diff --git a/debian/control b/debian/control
index e730db2af..a9d12e62a 100644
--- a/debian/control
+++ b/debian/control
@@ -24,7 +24,7 @@ Package: libboost1.74-dev
 Architecture: any
 Multi-Arch: same
 Section: libdevel
-Depends: ${misc:Depends}, ${shlibs:Depends}, libstdc++-dev
+Depends: ${misc:Depends}, ${shlibs:Depends}, libstdc++-${gxx:major}-dev
 Suggests: libboost1.74-doc,
  libboost-atomic1.74-dev,
  libboost-chrono1.74-dev,
diff --git a/debian/rules b/debian/rules
index 025139a8c..da506a948 100755
--- a/debian/rules
+++ b/debian/rules
@@ -343,6 +343,9 @@ ifeq ($(BUILD_NUMPY), yes)
sed -i -r 's/^(libboost_numpy([0-9]{2}) \S+ (\S+).*)$$/\1, \3-py\2/' 
debian/libboost-numpy$(SOVERSION)/DEBIAN/shlibs
 endif
 
+override_dh_gencontrol:
+   dh_gencontrol -- -V'gxx:major=$(shell dpkg-query -f '$${version}' -W 
g++ | sed 's/.*://;s/\..*//')'
+
 $(b2):
cd tools/build && bison -y -d -o src/engine/jamgram.cpp 
src/engine/jamgram.y
./bootstrap.sh --with-icu=/usr --prefix=$(CURDIR)/debian/tmp/usr \

Bug#983620: python3-vedo: Segfault rendering example files

[Bernhard Übelacker]

Control: reassign -1 libvtk9 9.0.1+dfsg1-8
Control: affects -1 python3-vedo


Dear Maintainer,
I tried to reproduce this issue and got also a crash.

Digging further it looks like in FireTimers an iterator "timer"
of the map LocalToTimer currently points to the element
with id=1, which gets removed from the map in the backtrace
given in [1].

Therefore the iterator timer gets invalidated, but still
incremented afterwards in FireTimers in the for loop,
which leads to the crash [2].

I guess this seems to be an issue of vtk9, therefore I hope
it is ok to reassign this bug there.

Kind regards,
Bernhard


[1]
(rr) bt
#0  vtkXRenderWindowInteractorInternals::DestroyLocalTimer (id=1, 
this=0x25b42f0) at ./Rendering/UI/vtkXRenderWindowInteractor.cxx:75
#1  vtkXRenderWindowInteractor::InternalDestroyTimer (this=, 
platformTimerId=1) at ./Rendering/UI/vtkXRenderWindowInteractor.cxx:426
#2  0x7f19afcf5d62 in vtkRenderWindowInteractor::DestroyTimer 
(this=0x258d1f0, timerId=) at 
./Rendering/Core/vtkRenderWindowInteractor.cxx:906
#3  0x7f19ae550209 in vtkHoverWidget::HoverAction (w=0x25f8410) at 
./Interaction/Widgets/vtkHoverWidget.cxx:129
#4  0x7f19b1a4f039 in vtkCallbackCommand::Execute (this=0x25f7c10, caller=, event=, callData=) at 
./Common/Core/vtkCallbackCommand.cxx:41
#5  0x7f19b1b1e562 in vtkSubjectHelper::InvokeEvent (this=0x25c15f0, 
event=25, callData=0x7ffdb4961174, self=0x258d1f0) at 
./Common/Core/vtkObject.cxx:626
#6  0x7f19af67e75b in vtkXRenderWindowInteractorInternals::FireTimers 
(this=0x25b42f0, rwi=0x258d1f0) at 
./Rendering/UI/vtkXRenderWindowInteractor.cxx:112
#7  0x7f19af67d9a7 in vtkXRenderWindowInteractor::StartEventLoop 
(this=0x258d1f0) at ./Rendering/UI/vtkXRenderWindowInteractor.cxx:258
#8  0x7f19aff074dd in PyvtkRenderWindowInteractor_Start (self=, args=) at 
./debian/build/CMakeFiles/vtkRenderingCorePython/vtkRenderWindowInteractorPython.cxx:280
#9  0x0053f38a in cfunction_call (func=, 
args=, kwargs=) at ../Objects/methodobject.c:548
...
   (rr) print this->LocalToTimer
   $17 = std::map with 2 elements = {[1] = {duration = 150, lastFire = {tv_sec 
= 1615899318, tv_usec = 39132}}, [2] = {duration = 1, lastFire = {tv_sec = 
1615899318, tv_usec = 362830}}}


[2]
Thread 1 received signal SIGSEGV, Segmentation fault.
...
(rr) bt
#0  std::local_Rb_tree_increment (__x=0x2e68e70) at 
../../../../../src/libstdc++-v3/src/c++98/tree.cc:71
#1  std::local_Rb_tree_increment (__x=__x@entry=0x2e68e70) at 
../../../../../src/libstdc++-v3/src/c++98/tree.cc:60
#2  std::_Rb_tree_increment (__x=__x@entry=0x2e68e70) at 
../../../../../src/libstdc++-v3/src/c++98/tree.cc:85
#3  0x7f19af67e6fa in std::_Rb_tree_iterator >::operator++ (this=) at 
/usr/include/c++/10/bits/stl_tree.h:285
#4  vtkXRenderWindowInteractorInternals::FireTimers (this=0x25b42f0, 
rwi=0x258d1f0) at ./Rendering/UI/vtkXRenderWindowInteractor.cxx:105
#5  0x7f19af67d9a7 in vtkXRenderWindowInteractor::StartEventLoop 
(this=0x258d1f0) at ./Rendering/UI/vtkXRenderWindowInteractor.cxx:258
#6  0x7f19aff074dd in PyvtkRenderWindowInteractor_Start (self=, args=) at 
./debian/build/CMakeFiles/vtkRenderingCorePython/vtkRenderWindowInteractorPython.cxx:280
#7  0x0053f38a in cfunction_call (func=, 
args=, kwargs=) at ../Objects/methodobject.c:548
...

# Bullseye/testing amd64 qemu VM 2021-03-16

apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox mc gdb rr valgrind 
python3-vedo-examples \
python3-dbg python3-vtk9-dbgsym libvtk9-dbgsym libstdc++6-dbgsym
apt build-dep vtk9
apt build-dep gcc-10

export DISPLAY=:0
python3 /usr/share/doc/python3-vedo-examples/examples/basic/align1.py

coredumpctl list
coredumpctl gdb 10789

echo 1 > /proc/sys/kernel/perf_event_paranoid




mkdir /home/benutzer/source/vtk9/orig -p
cd/home/benutzer/source/vtk9/orig
apt source vtk9
cd

mkdir /home/benutzer/source/libstdc++6/orig -p
cd/home/benutzer/source/libstdc++6/orig
apt source libstdc++6
cd




benutzer@debian:~$ python3 
/usr/share/doc/python3-vedo-examples/examples/basic/align1.py
ave. squared distance = 43.20515185350062
Speicherzugriffsfehler (Speicherabzug geschrieben)

root@debian:~# journalctl -e
Mär 16 12:02:46 debian kernel: traps: python3[10789] general protection fault 
ip:7f71a04fbda3 sp:7ffcbedeb378 error:0 in 
libstdc++.so.6.0.28[7f71a04d6000+dc000]

root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2021-03-16 12:02:47 CET   10789  1000  1000  11 present   /usr/bin/python3.9

root@debian:~# coredumpctl gdb 10789
   PID: 10789 (python3)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Tue 2021-03-16 12:02:46 CET (1h 27min ago)
  Command Line: python3 
/usr/share/doc/python3-vedo-examples/examples/basic/align1.py
Executable: 

Bug#981268: marked as pending in lintian

[Timo Röhling]

Dear maintainer,

On Thu, 28 Jan 2021 17:48:19 + Felix Lechner  
wrote:

Bug #981268 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/-/commit/2e0f6dae25728b726bcb71aa5e198fec46b7f843


I believe there is still an edge case missing, as Python
applications may have private modules in /usr/share/PACKAGENAME
which also often need an egg-info/ folder.

I suggest the modified regex 


--- a/lib/Lintian/Check/Documentation.pm2021-03-16 21:05:15.187252857 
+0100
+++ b/lib/Lintian/Check/Documentation.pm2021-03-16 21:07:56.039250618 
+0100
@@ -153,7 +153,7 @@
   # see Bug#904852
   || $file->dirname =~ m{templates?(?:\.d)?/}
   || ( $file->basename =~ m{\.txt$}
-&& $file->dirname =~ m{^usr/lib/python3/.*\.egg-info/}s)
+&& $file->dirname =~ 
m{^usr/(?:lib/python3|share/$ppkg)/.*\.egg-info/}s)
   || ( $file->basename =~ m{^README}xi
 && $file->bytes =~ m{this directory}xi);
 }


Cheers
Timo



signature.asc
Description: PGP signature

Bug#924352: CVE-2018-16384

[Moritz Mühlenhoff]

Am Mon, Mar 11, 2019 at 10:52:51PM +0100 schrieb Moritz Muehlenhoff:
> Package: modsecurity-crs
> Severity: normal
> 
> Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16384
> 
> (It seems questionable to assign a CVE ID to modsecurity-crs for this from my 
> POV)

What's the status of this bug? Should we fix it for bullseye or is this
a non-issue, close it?

Cheers,`
 Moritz

Bug#977468: smuxi is marked for autoremoval from testing

[Moritz Mühlenhoff]

Am Mon, Jan 11, 2021 at 10:54:27AM +0800 schrieb Mirco Bauer:
> Thanks for your email and raised concern, Jeremy.
> 
> Full accessibility in Smuxi has been a high priority for me for a long
> time.
> 
> I looked into the vulnerability of the log4net library that Smuxi depends
> on. my assessment doesn't classify a XXE for local configuration file as
> release critical. An attacker would need to have write access to the
> configuration file to exploit it. It that point a XXE is pointless, he can
> just execute curl, wget, perl, python or write something to ~/.bashrc
> directly.
> Having identified the offending code the fix is a one line change on the
> other hand. I plan to upload a fixed version of log4net in the coming days.

What's the status of that upload? Patch is at
https://github.com/apache/logging-log4net/commit/d0b4b0157d4af36b23c24a23739c47925c3bd8d7

Cheers,
Moritz

Bug#985150: systemd-udevd is trying read from unused module acpi-cpufreq

[Michael Biebl]

Am 16.03.21 um 21:01 schrieb Anonimno:

Attached please find the boot log.
As you can probably see, the error msg is not there directly after the
boot. It shows up some time later. Didn't figure out, if there is a
specific trigger e.g. suspend or similar.


Ok, we need a journal log from when the problem shows up.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#985150: systemd-udevd is trying read from unused module acpi-cpufreq

[Michael Biebl]

Am 16.03.21 um 21:01 schrieb Anonimno:

Attached please find the boot log.
As you can probably see, the error msg is not there directly after the
boot. It shows up some time later. Didn't figure out, if there is a
specific trigger e.g. suspend or similar.


Maybe you have laptop-mode-tools or something similar installed. l-m-t 
is known to do weird stuff.


Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#985309: CVE-2021-21235

[kpcyrd]

hi,

the package is likely too old to have this bug, but since this package
is currently not used by anything and not meant to be used by any users,
I'd recommend to remove it from testing (we're eventually going to close
it by uploading the latest version to unstable).

cheers

Bug#985377: CVE-2020-13327

[Moritz Muehlenhoff]

Source: gitlab-ci-multi-runner
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

Please see
https://gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13327.json
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26833

There's also CVE-2020-13295, not sure if that also affects the version
in sid/bullseye:
https://gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13295.json
https://gitlab.com/gitlab-org/gitlab/-/issues/209096

Cheers,
Moritz

Bug#972716: mutter spams logs in default config with up to >10k log messages per second

[Simon McVittie]

On Tue, 16 Mar 2021 at 20:23:59 +0100, Thomas Viehmann wrote:
> I wonder if this bug (#972716) might be worth fixing before the release of
> bulleye.

You never said which version of gnome-shell or mutter is/was affected.
Which version is/was affected? It might be obvious to you, but it isn't
obvious to me whether you're talking about 3.38.x, 3.30.x or something
else.

If you are aware of an upstream commit or an upstream release that is
thought to fix it, which upstream commit or release is that?

You linked to https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2467
which mentions merge requests
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1116 and
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1676. If I'm reading
correctly, mutter!1676 was included in our mutter package since 3.38.3-2,
while gnome-shell!1116 has been included in our gnome-shell packages
since sometime around 3.36.1, so this is hopefully already fixed in
bullseye. If you are using bullseye/sid, please could you confirm whether
this is fixed, either in 3.38.3-3 (in bullseye as of today) or in 3.38.3-5
(due to migrate soon)?

Now that the much-delayed 3.38.4 upstream releases have happened, I'll
try to look at whether we can include them in buster, but our 3.38.3-x
packages are already quite close to upstream's 3.38.4.

smcv

Bug#980427: garbled message window after terminal resize

[Ryan Kavanagh]

Hi,

It has been two months since I submitted an upstream-provided patch.
This bug forces me to manually redraw my screen several times per hour.

I intend to NMU neomutt in fourteen days, and I will upload a package
generated from attached patch sequence to DELAYED/10. Please let me know
by then if you prefer that I not do so.

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A
From c87066355cc6aa5cb494eb066ffa0823d0e4267c Mon Sep 17 00:00:00 2001
From: Ryan Kavanagh 
Date: Tue, 16 Mar 2021 15:37:10 -0400
Subject: [PATCH 1/2] Clear the message window on SIGWINCH,
 redraw-on-sigwinch.patch (Closes: #980427)

---
 debian/patches/misc/redraw-on-sigwinch.patch | 43 
 debian/patches/series|  1 +
 2 files changed, 44 insertions(+)
 create mode 100644 debian/patches/misc/redraw-on-sigwinch.patch

diff --git a/debian/patches/misc/redraw-on-sigwinch.patch b/debian/patches/misc/redraw-on-sigwinch.patch
new file mode 100644
index 000..a09031b
--- /dev/null
+++ b/debian/patches/misc/redraw-on-sigwinch.patch
@@ -0,0 +1,43 @@
+From: Richard Russon 
+Date: Mon, 7 Dec 2020 14:21:45 +
+Subject: clear the message window on SIGWINCH (#2756)
+
+When the terminal is resized (or the font-size is changed),
+the screen must be redrawn.  This *used* to involve clearing the entire
+screen.  Soon, it will be delegated to individual windows to refresh
+themselves.
+
+In the mean time, forcibly clear the MessageWindow.
+
+Fixes: #2749
+
+Origin: https://github.com/neomutt/neomutt/commit/88f0b0572da9414550608054e960fd00b8d6b939
+---
+ index.c | 1 +
+ pager.c | 1 +
+ 2 files changed, 2 insertions(+)
+
+diff --git a/index.c b/index.c
+index c29ba8b..af3a18f 100644
+--- a/index.c
 b/index.c
+@@ -1368,6 +1368,7 @@ int mutt_index_menu(struct MuttWindow *dlg)
+ /* force a real complete redraw.  clrtobot() doesn't seem to be able
+  * to handle every case without this.  */
+ clearok(stdscr, true);
++mutt_window_clearline(MessageWindow, 0);
+ continue;
+   }
+ 
+diff --git a/pager.c b/pager.c
+index b08dda2..0e333c0 100644
+--- a/pager.c
 b/pager.c
+@@ -2473,6 +2473,7 @@ int mutt_pager(const char *banner, const char *fname, PagerFlags flags, struct P
+   SigWinch = 0;
+   mutt_resize_screen();
+   clearok(stdscr, true); /* force complete redraw */
++  mutt_window_clearline(MessageWindow, 0);
+ 
+   if (flags & MUTT_PAGER_RETWINCH)
+   {
diff --git a/debian/patches/series b/debian/patches/series
index 4bbbda3..49e6f2a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@ debian-specific/use_usr_bin_editor.patch
 debian-specific/document_debian_defaults.patch
 misc/smime.rc.patch
 upstream/981306-mime-forwarding.patch
+misc/redraw-on-sigwinch.patch
-- 
2.30.2

From 8f165cec619b20d895aa5700d4c4cf9337f9a30b Mon Sep 17 00:00:00 2001
From: Ryan Kavanagh 
Date: Tue, 16 Mar 2021 15:38:22 -0400
Subject: [PATCH 2/2] Changelog for 20201127+dfsg.1-1.1

---
 debian/changelog | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index c9a8bd3..213c8a4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+neomutt (20201127+dfsg.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Clear the message window on SIGWINCH, redraw-on-sigwinch.patch
+(Closes: #980427)
+
+ -- Ryan Kavanagh   Tue, 16 Mar 2021 15:37:31 -0400
+
 neomutt (20201127+dfsg.1-1) unstable; urgency=medium
 
   * New upstream release.
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#966701: Driverless printing in buster via ipp-usb

[Justin B Rye]

Brian Potkin wrote:
>> USB connected printers and driverless printing
>> --
>> 
>> The Release Notes for Debian 10 briefly describe the driverless printing
>> situation implemented via CUPS and cups-filters. [1] The changes apply to
>> modern printers connected by ethernet or wireless. [2]
>> 
>> The release of Debian 11 sees the inclusion of ipp-usb in the stable
>> archive. ipp-usb is recommended by cups-daemon and utilises the
>> vendor-neutral IPP-over-USB protocol that is supported by many modern
>> printers. ipp-usb allows a USB device to be seen and treated as a network
>> device. The outcome is that driverless printing is extended to include USB
>> connected printers. The specifics are outlined on the wiki. [3]
>> 
>> The systemd service file included in the ipp-usb package starts the
>> ipp-usb daemon when a printer is plugged in. A USB connected printer now
>> becomes available to print to, either by being auto-setup by cups-browsed,
>> which is the default technique, or being manually installed [4] with a
>> local driverless print queue.
>> 
>> The use of vendor printer drivers, free and non-free, becomes unnecessary
>> with networked and USB connected printers.
>> 
>> 
>> [1] 
>> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#driverless-printing
>> [2] https://wiki.debian.org/CUPSQuickPrintQueues
>> [3] https://wiki.debian.org/CUPSDriverlessPrinting.
>> [4] https://wiki.debian.org/SystemPrinting
> 
> Thinking on:
> 
>   The Release Notes for Debian 10 briefly describe...
> 
> should probably be
> 
>   The Release Notes for Debian 10 briefly describes...

Plural "notes", so I'd say that they "describe" the situation (and my
native en_GB tends if anything to be more tolerant than en_US of
mismatches).  But it might be worth shifting things round so that the
sentence has a different subject, since this would let it introduce
topics in a more natural order:

   Modern printers connected by ethernet or wireless [1] can use driverless
   printing, implemented via CUPS and cups-filters, as described in the
   Debian 10 "buster" Release Notes. [2]

[...]

   [1] https://wiki.debian.org/CUPSQuickPrintQueues
   [2] 
https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#driverless-printing

Oh, watch out, that /stable/ URL will point at the wrong thing soon!
We need 
   [2] 
https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#driverless-printing

> Having [3] as
> 
>   https://wiki.debian.org/CUPSDriverlessPrinting#debian
> 
> might be considered more targeted.

Calling that anchor "#debian" implies that the rest of the page is
about something other than Debian; and using the release name as a
section title will make things harder to follow once we're moving
towards Debian 12 "bookworm"!  Couldn't the section be titled
something like "IPP-over-USB: automatic setup"?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#985376: CVE-2020-35459

[Moritz Muehlenhoff]

Package: crmsh
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2020-35459:
https://www.openwall.com/lists/oss-security/2021/01/12/3

Bug#970478: ERROR: Renderer process crashed when using qtwebengine backend.

[felipe]

Hi!

> As we now have Qt WebEngine 5.15.2 in testing and sid, can we mark this
> bug as fixed?

As suggested before, I avoided qtwebengine version 5.15.1 first by downgrading 
to 5.15.0 and then upgrading to 5.15.2
when it did become available.

It worked without incidents on my 2 machines, so it was fixed for me.

Bug#985375: vmdb2: add option to 'apt' step for not installing recommends

[Andres Salomon]

Package: vmdb2
Version: 0.22-1
Severity: wishlist

I'm building a rock64 image using vmdb2, and I need to pull in
the u-boot-rockchip package for some prebuilt u-boot images. That
package has a Recommends on python3, which results in 300MB of bloat to
my install image AND python3-minimal is segfaulting.

Obviously the segfault is a separate problem, but the bloat is also an
issue. It would be nice if there was a way to tell vmdb2 not to install
recommends in the apt step.

Here's what I'm currently doing to work around it in the .yaml file:


  - apt: install
packages:
- ssh
- parted
- dosfstools
- linux-image-arm64
- grub-efi-arm64
#- u-boot-rockchip
tag: /
unless: rootfs_unpacked

  # u-boot-rockchip recommends python3, which bloats the image by 300MB
  # *and* causes a segfault in python3-minimal (something in
  # py3compile?).
  - chroot: /
shell: |
  apt-get install --no-install-recommends u-boot-rockchip
unless: rootfs_unpacked

Bug#985374: error: embedding is not possible - RAID+LVM+ext4

[Andrew Ruthven]

Package: grub-pc
Version: 2.04-16
Severity: important

Dear Maintainer,

grub-pc 2.04-16 is unable to embed core.img on my machine (I install on
two hard drives):

Setting up grub-pc (2.04-16) ...
Installing for i386-pc platform.
grub-install: warning: your core.img is unusually large.  It won't fit in the 
embedding area.
grub-install: error: embedding is not possible, but this is required for RAID 
and LVM install.
Installing for i386-pc platform.
grub-install: warning: your core.img is unusually large.  It won't fit in the 
embedding area.
grub-install: error: embedding is not possible, but this is required for RAID 
and LVM install.

   * What led up to the situation?

Running an apt upgrade that upgrades from version 2.04-15 to 2.04-16. 

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

To enable embedding of the core.img I have to downgrade to 2.04-15.

There are a number of these types of bug reports, but it appears that
different versions of grub-pc tend to trigger them, so I decided to submit
a new bug report. Please feel free to merge this one if that is an appropriate
action to take.

Cheers,
Andrew

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/md3 / ext3 rw,relatime,errors=remount-ro 0 0
/dev/VG/VG-usr /usr ext3 rw,relatime 0 0
/dev/mapper/VG-tmp /tmp ext2 rw,relatime 0 0
/dev/mapper/VG-srv /srv ext4 rw,relatime 0 0
/dev/md0 /boot ext2 rw,relatime 0 0
/dev/mapper/VG-VG--scratch /scratch ext3 rw,relatime 0 0
/dev/mapper/VG-VG--var /var ext3 rw,relatime 0 0
/dev/mapper/VG-VG--home /home ext3 rw,relatime 0 0
/dev/mapper/VG-VG--home 
/var/lib/schroot/union/underlay/sid-amd64-sbuild-1a304339-632f-4334-aadb-fe415d5e8910
 ext3 rw,relatime 0 0
/dev/mapper/VG-VG--var 
/run/schroot/mount/sid-amd64-sbuild-1a304339-632f-4334-aadb-fe415d5e8910/build 
ext3 rw,relatime 0 0
/dev/mapper/VG-VG--home 
/var/lib/schroot/union/underlay/sid-amd64-sbuild-20b67ce0-f23f-4f47-9247-fda7c0d92b13
 ext3 rw,relatime 0 0
/dev/mapper/VG-VG--var 
/run/schroot/mount/sid-amd64-sbuild-20b67ce0-f23f-4f47-9247-fda7c0d92b13/build 
ext3 rw,relatime 0 0
/dev/mapper/VG-VG--home 
/var/lib/schroot/union/underlay/sid-amd64-sbuild-9769b236-5aa6-4518-a77c-2d67f8c7c9d2
 ext3 rw,relatime 0 0
/dev/mapper/VG-VG--var 
/run/schroot/mount/sid-amd64-sbuild-9769b236-5aa6-4518-a77c-2d67f8c7c9d2/build 
ext3 rw,relatime 0 0
/dev/mapper/VG-VG--home 
/var/lib/schroot/union/underlay/sid-amd64-sbuild-e1eecccb-36e8-4691-82ab-2da987405a3c
 ext3 rw,relatime 0 0
/dev/mapper/VG-VG--var 
/run/schroot/mount/sid-amd64-sbuild-e1eecccb-36e8-4691-82ab-2da987405a3c/build 
ext3 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/raid-VG-VG--usr
(hd1)   /dev/disk/by-id/raid-VG-VG--var
(hd2)   /dev/disk/by-id/raid-VG-VG--home
(hd3)   /dev/disk/by-id/raid-VG-VG--scratch
(hd4)   /dev/disk/by-id/raid-VG-tmp
(hd5)   /dev/disk/by-id/raid-VG-vservers
(hd6)   /dev/disk/by-id/raid-VG-
(hd7)   /dev/disk/by-id/raid-VG-fai--test
(hd8)   /dev/disk/by-id/raid-VG-test--vm--0
(hd9)   /dev/disk/by-id/lvm-pv-uuid-OUObOt-SilW-Hg30-7J5H-uso3-Ychn-C2FVR2
(hd10)  /dev/disk/by-id/lvm-pv-uuid-YlRE7l-bTvN-38yC-ZTm2-innD-eBq8-RCY9qE
(hd11)  /dev/disk/by-id/lvm-pv-uuid-wzHKWm-0CjU-gYzN-RHR9-G2OK-sV5J-WXDId1
(hd12)  /dev/disk/by-id/ata-WDC_WD10EZEX-00WN4A0_WD-WMC6Y0F2J3F4
(hd13)  /dev/disk/by-id/ata-WDC_WD10EZEX-00WN4A0_WD-WMC6Y0F3KFHN
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod lvm
insmod ext2
set 
root='lvmid/uFGFNk-DXwp-6J4A-CrZO-FBZL-mty4-zuU4x7/ooLKhD-MI2u-ReeZ-1VAb-E3YV-gd6T-wuNt1t'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 

Bug#950514: Upstream issue opened

[Felix Lechner]

Hi,

Now there is also an upstream issue:

https://pagure.io/SSSD/ding-libs/issue/3190

Thanks to Robbie Harwood for filing!

Kind regards
Felix Lechner

Bug#972716: mutter spams logs in default config with up to >10k log messages per second

[Thomas Viehmann]

reassign 972716 mutter
thank you

Dear release team & GNOME maintainers,

thank you for making Debian!

I wonder if this bug (#972716) might be worth fixing before the release 
of bulleye. Upstream released a fixed version but a targeted backport 
would also help.
Given that it is quite easy to hit, this will not only render people's 
GNOME desktop unusable but I would consider it very likely to cause 
damage, too, either from exhausting storage or damaging the drives.


Best regards

Thomas

Bug#716058: [Mayhem] Bug report on hebcal: hebcal crashes with exit status 139

[Ambrose Li]

Hi,

I noticed this bug in upstream (https://github.com/hebcal/hebcal/issues/173)
but the original "full report" on forallsecure is now a 404. Does anyone
have a saved copy of the original crash report?

-- 
Ambrose Li  | Time zone: GMT-4 (Eastern)
ambroseli.ca

“Any organization which designs a system… will inevitably produce a
 design whose structure is a copy of the organization’s communication
 structure.” — Conway’s Law

Bug#983876: unblock: otrs2/6.0.32-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Patrick,

On 15-03-2021 15:12, Patrick Matthäi wrote:
> reopen #983876
> thanks
> 
> Am 02.03.21 um 19:38 schrieb Paul Gevers:
>> Hi Patrick,
>>
>> On 02-03-2021 16:58, Patrick Matthäi wrote:
>>> I just uploaded the otrs2 6.0.32 package to experimental.  Could I have 
>>> your ACK for bullseye? :-)
>> otrs2 is neither a key package [1], nor listed on the (build-)essential
>> list [1]. As long as you follow the soft freeze rules [3] and ensure
>> that the package migrates before the start of the hard freeze
>> (12-03-2021), there is nothing for us to unblock. I'm wondering if and
>> suspect that you are asking our permission to upload a new upstream
>> source. It's hardly doable for us to do that for all packages in Debian,
>> so we expect you honor the freeze rules and make the judgement yourself
>> if a new upstream version for your package is appropriate at this state.
>>
>> Paul
>>
>> [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
>> [2] https://release.debian.org/bullseye/essential-and-build-essential.txt
>> [3] https://release.debian.org/bullseye/freeze_policy.html#soft
>>
> Hi,
> 
> I uploaded the release to unstable just one hour after your mail and
> there were still 10 days for the package to migrate. But the migration
> process was not done before the freeze so now I need an unblock:
> 
>   * Migration status for otrs2 (6.0.30-2 to 6.0.32-2): BLOCKED: Needs an
> approval (either due to a freeze, the source suite or a manual hint)
>   * Too young, only 12 of 20 days old
> 
> Now it needs also 10 days more, but in two days 6.0.30 should be
> AUTORMed from testing :(
> 

The diff is not reviewable:

 5637 files changed, 151250 insertions(+), 29937 deletions(-)

If you think you can provide a diff that can be reviewed, please provide
one, but please show how you filtered the diff too.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#913027: Do you?

[Sarah Sung-Ho]

[image: image.png]

Bug#966701: Driverless printing in buster via ipp-usb

[Brian Potkin]

On Wed 23 Sep 2020 at 19:54:14 +0100, Brian Potkin wrote:

> I would like the following version to replace previous offering:
> 
> 
> USB connected printers and driverless printing
> --
> 
> The Release Notes for Debian 10 briefly describe the driverless printing
> situation implemented via CUPS and cups-filters. [1] The changes apply to
> modern printers connected by ethernet or wireless. [2]
> 
> The release of Debian 11 sees the inclusion of ipp-usb in the stable
> archive. ipp-usb is recommended by cups-daemon and utilises the
> vendor-neutral IPP-over-USB protocol that is supported by many modern
> printers. ipp-usb allows a USB device to be seen and treated as a network
> device. The outcome is that driverless printing is extended to include USB
> connected printers. The specifics are outlined on the wiki. [3]
> 
> The systemd service file included in the ipp-usb package starts the
> ipp-usb daemon when a printer is plugged in. A USB connected printer now
> becomes available to print to, either by being auto-setup by cups-browsed,
> which is the default technique, or being manually installed [4] with a
> local driverless print queue.
> 
> The use of vendor printer drivers, free and non-free, becomes unnecessary
> with networked and USB connected printers.
> 
> 
> [1] 
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#driverless-printing
> [2] https://wiki.debian.org/CUPSQuickPrintQueues
> [3] https://wiki.debian.org/CUPSDriverlessPrinting.
> [4] https://wiki.debian.org/SystemPrinting
> 
> Cheers,
> 
> Brian.

Thinking on:

  The Release Notes for Debian 10 briefly describe...

should probably be

  The Release Notes for Debian 10 briefly describes...

Having [3] as

  https://wiki.debian.org/CUPSDriverlessPrinting#debian

might be considered more targeted.

Cheers,

Brian.

Bug#983776: libvkd3d-dev 1.2-3 breaks multi-arch support

[Sveinar Søpler]

On 16.03.2021 13:32, Henri Verbeet wrote:

On 2021-03-03 15:38, Francois Gouget wrote:

Just asking. I don't actually know if the 32- and 64-bit vkd3d-compiler
produce identical files or if one produces 32-bit files and the other
64-bit ones.

The output produced by i386 and amd64 (or any other, for that matter) 
builds of vkd3d-compiler should be identical; if it isn't, that would 
be considered a bug. For the record, I would be inclined to agree that 
the -dev package is not the appropriate place for vkd3d-compiler.


How would vkd3d-compiler be identical regardless of arch? I might 
misunderstand what you are saying tho.. I dont really know how dpkg 
compares binary files when they are installed, but if they are not 
binary equal, they are not "the same" from dpkg's pov. How would 
vkd3d-compiler compiled for amd64 be binary the same as i386? (The 
physical file that is).


I mean, a "hello world" example compiled as i386 or amd64 "are the 
same", but they are not checksum-comparable the same file.




On the subject of Wine builds requiring both vkd3d-dev:amd64 and 
vkd3d-dev:i386, although somewhat tangential, note that Wine doesn't 
only use libvkd3d for its implementation of Direct3D 12, but also 
libvkd3d-shader for producing SPIR-V shaders for the Vulkan backend of 
its implementation of Direct3D 11 and earlier, where i386 applications 
are much more common.


Does that mean wine requires libvkd3d-shader for d3d11 with vulkan 
backend now?


Wine-dev compiled without vkd3d (as the case is for Debian10 ref. 
https://build.opensuse.org/build/Emulators:Wine:Debian/Debian_10/x86_64/wine-devel/_log 
) does not say anything about d3d11 vulkan backend not being supported? 
Should there be a note of that incase configure is missing/too old libvkd3d?


Sveinar

Bug#985149: debootstrap stumbles over tabs in include parameter

[Paul Tagliamonte]

>From a quick glance, it looks like `leftoverdebs` is initially a list of
packages, but in the suite/compoenent loop, leftoverdebs is assigned to the
package sizes.

...
leftoverdebs=$(printf "$leftoverdebs"|tr ' ' '\n'|sort -u|tr '\n' ' ')

leftoverdebs="$(get_package_sizes "$m1" "$pkgdest" $leftoverdebs)"

error 1 LEFTOVERDEBS "Couldn't find these debs: %s" "$leftoverdebs"

The output number appears to be the package sizes. Very confusing output
error message indeed!

  paultag

-- 
:wq

Bug#985228: unblock: petsc/3.14.5+dfsg1-2

[Drew Parsons]

Thanks Ivo, I'll prepare a filtered diff for consideration.

Drew

On 2021-03-16 17:32, Ivo De Decker wrote:

Control: tags -1 moreinfo


...

  [ ] attach debdiff against the package in testing


We ask these this for a reason. The current diff between the version in
testing and unstable is very large and unreviewable. It certainly isn't 
going
to get unblocked like this. If you can provide a filtered diff, with 
only the
'real' changes, and not the noise generated by the new upstream 
release,

there's at least a chance we could look at them. Note that this doesn't
guarantee it will be unblocked. There's still a decent chance that the 
changes

will be too big.

Bug#985284: [Debian-med-packaging] Bug#985284: hyphy-common: unhandled symlink to directory conversion: /usr/lib/hyphy -> ../share/hyphy

[Andreas Beckmann]

On 16/03/2021 20.01, Étienne Mollier wrote:

Do you have more details on the arb issue ?  I tried reproducing
problems with piuparts tests, but I haven't seen anything
outstanding on first sight.


It's just a piuparts test of arb failing due to hyphy. It will be 
resolved when hyphy gets fixed. I just want to get an "affected" bug 
mark next to the failing log so that I don't look into it...


Andreas

Bug#985373: mirror submission for debian.mirror.treudler.net

[Joshua Treudler]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.mirror.treudler.net
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Joshua Treudler 
Country: DE Germany




Trace Url: http://debian.mirror.treudler.net/debian/project/trace/
Trace Url: 
http://debian.mirror.treudler.net/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.mirror.treudler.net/debian/project/trace/debian.mirror.treudler.net

Bug#985284: [Debian-med-packaging] Bug#985284: hyphy-common: unhandled symlink to directory conversion: /usr/lib/hyphy -> ../share/hyphy

[Étienne Mollier]

Control: affects -1 + hyphy-pt
Control: tag -1 pending

Hi Andreas,

Andreas Beckmann, on 2021-03-16 11:30:11 +0100:
> This bug also affects hyphy-mpi:

Thanks for the notice, I spotted similar issues in hyphy-pt.
Remaining packages from hyphy source looked good.  I will upload
hyphy soon.

Do you have more details on the arb issue ?  I tried reproducing
problems with piuparts tests, but I haven't seen anything
outstanding on first sight.

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


signature.asc
Description: PGP signature

Bug#930759: mokutil(1) refers to non-existent "--enroll-validation"

[Steve McIntyre]

On Wed, Jun 19, 2019 at 10:07:44PM -0400, Antoine Beaupre wrote:
>Package: mokutil
>Version: 0.3.0+1538710437.fb6250f-1
>Severity: minor
>
>mokutil(1) has this to say about "validation":
>
>   mokutil [--disable-validation]
>   mokutil [--enable-validation]
>   
>   [...]
>   
>   --disable-validation
>  Disable the validation process in shim
>
>   --enrolled-validation
>  Enable the validation process in shim
>
>This seems like a contradiction: is it `enrolled` or `enable`? I tried
>`enable` and it worked, so maybe it's the first? In any case, it seems
>the manpage should be fixed.

It's definitely just a manpage bug, and it's been fixed
upstream. Should have that fix soon, I hope.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Bug#985372: libxcrypt FTCBFS: glibc version detection inspects build architecture libc

[Helmut Grohne]

Source: libxcrypt
Version: 1:4.4.18-1
User: helm...@debian.org
Usertags: rebootstrap
Tags: patch

libxcrypt's method of glibc version detection uses the build
architecture compiler. It actually query the CC environment variable,
but this happens to be unset. The relevant perl script is called from
configure.ac, which knows the right compiler to use, but does not pass
it. Please consider applying the attached patch.

Helmut
--- libxcrypt-4.4.18.orig/configure.ac
+++ libxcrypt-4.4.18/configure.ac
@@ -427,6 +427,7 @@
 if test $enable_obsolete_api = 1; then
   AC_MSG_CHECKING([minimum symbol version to use for compatibility symbols])
   SYMVER_FLOOR=$(
+export CC;
 $PERL ${srcdir}/build-aux/compute-symver-floor \
   ${srcdir}/lib/libcrypt.minver $host_os $host_cpu \
 2>_MESSAGE_LOG_FD

Bug#925223: mokutil: update to latest version

[Steve McIntyre]

Hey folks,

This specific bug (lack of --set-verbosity) was fixed in the last
upload, However, development has continued upstream and there are more
new features I'd like to see in the Debian version again. Of
particular interest is support for dumping SBAT data now...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.

Bug#981372: keepassxc: New upstream release 2.6.3

[arne anka]

Package: keepassxc
Version: 2.6.2+dfsg.1-1
Followup-For: Bug #981372

What about _SID_?
2.6.4 now.

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

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

Versions of packages keepassxc depends on:
ii  libargon2-10~20171227-0.2
ii  libc6  2.31-9
ii  libgcrypt201.8.7-3
ii  libqrencode4   4.1.1-1
ii  libqt5concurrent5  5.15.2+dfsg-5
ii  libqt5core5a   5.15.2+dfsg-5
ii  libqt5dbus55.15.2+dfsg-5
ii  libqt5gui5 5.15.2+dfsg-5
ii  libqt5network5 5.15.2+dfsg-5
ii  libqt5svg5 5.15.2-2
ii  libqt5widgets5 5.15.2+dfsg-5
ii  libqt5x11extras5   5.15.2-2
ii  libsodium231.0.18-1
ii  libstdc++6 10.2.1-6
ii  libx11-6   2:1.7.0-2
ii  libxi6 2:1.7.10-1
ii  libxtst6   2:1.2.3-1
ii  libykpers-1-1  1.20.0-3
ii  libzxcvbn0 2.4+dfsg-2
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages keepassxc recommends:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4

Versions of packages keepassxc suggests:
ii  webext-keepassxc-browser  1.7.4+repack1-2
ii  xclip 0.13-2

-- no debconf information

Bug#963025: firmware-iwlwifi: Microcode SW error detected / 9000-pu-b0-jf-b0-46.ucode

[maximilian attems]

> Some context:
> * the error occured right after laptop boot
> * My Wifi setup: AP was forced to use frequency of 5240GHz and offered
> 20/40/80MHz channel width. Moving AP to 5180GHz solve the issue.
> 
> My understanding:
> It *seems* that iwlwifi could have issues with DFS frequencies, not with
> channel width.
> My last report was also linked to DFS channels being used.
> Moving away from DFS channel solve the issue, at least for me.

Upstream says this should be fixed in unstable linux version with
latest 20210315 iwlwifi firmare. If not please let us know.

Bug#984650: update-initramfs fails when /etc/systemd/network/99-default.link is symlink to /dev/null

[Michael Biebl]

Control: tags -1 + help

On Sat, 6 Mar 2021 17:22:17 +0100 Frederik Lindenaar
 wrote:
> Hi Cyril,
> 
> Thank you for the quick reply
> 
> As Ben also pointed out, I probably have indeed mixed up /dev/zero
and /dev/null and had already fixed that by using an empty file.
Nevertheless the result was pretty odd (the disk filling up rapidly)
and very confusing so might still be useful to prevent this (if
possible).
> 
> Why not use a cp -aLt  {} instead to prevent this?
> 

This wouldn't produce the right result afaics. If you mask a file by
symlinking it to /dev/null, the current code produces a file with zero-
size (which is also acceptable for masking files).

If you dereference (-L), you instead copy a character device, which is
not the same as a zero-sized file.

We also have to keep in mind, that if a .link file in
/etc/system/network, pointing to some link elsewhere, we probably do
want to resolve that and not copy a dangling symlink.

The current code is already ugly as it is. I'm not sure, adding more
corner cases is a good idea. That said, I'm open to suggestions. The
code must

- make sure files with the same name in /etc/systemd/network take
precedence of files in /lib/systemd/network
- correctly handle masked .link files (i.e. files pointing at
/dev/null)
- correctly handle the case that /etc/systemd/network doesn't exist or
itself is a symlink

I'm happy to take a patch for that.

Regards,
Michael



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

Bug#985370: apache2: HEAD requests are empty when mod_ratelimit is enabled

[Jan Moskyto Matejka]

Package: apache2
Version: 2.4.38-3+deb10u4
Severity: normal

Dear Maintainer,

I have set up a site with mod_ratelimit enabled. Then HEAD requests sent
by curl are logged as sent (with some size), anyway curl reports

  url: (52) Empty reply from server

Disabling the rate limit (while keeping the mod loaded) makes HEAD
requests work OK.

-- Package-specific info:

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

Kernel: Linux 4.19.0-14-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apache2 depends on:
ii  apache2-bin2.4.38-3+deb10u4
ii  apache2-data   2.4.38-3+deb10u4
ii  apache2-utils  2.4.38-3+deb10u4
ii  dpkg   1.18.22
ii  lsb-base   9.20161125
ii  mime-support   3.60
pn  perl:any   
ii  procps 2:3.3.12-3+deb9u1

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.38

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  elinks [www-browser] 0.12~pre6-12
ii  firefox-esr [www-browser]78.8.0esr-1~deb10u1
ii  links [www-browser]  2.14-2
ii  w3m [www-browser]0.5.3-34

Versions of packages apache2-bin depends on:
ii  libapr1  1.6.5-1+b1
ii  libaprutil1  1.6.1-4
ii  libaprutil1-dbd-sqlite3  1.6.1-4
ii  libaprutil1-ldap 1.6.1-4
ii  libbrotli1   1.0.7-2+deb10u1
ii  libc62.28-10
ii  libcurl4 7.64.0-4+deb10u1
ii  libjansson4  2.12-1
ii  libldap-2.4-22.4.47+dfsg-3+deb10u6
ii  liblua5.2-0  5.2.4-1.1+b1
ii  libnghttp2-141.36.0-2+deb10u1
ii  libpcre3 2:8.39-2
ii  libssl1.11.1.1d-0+deb10u5
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
pn  perl:any 
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  elinks [www-browser] 0.12~pre6-12
ii  firefox-esr [www-browser]78.8.0esr-1~deb10u1
ii  links [www-browser]  2.14-2
ii  w3m [www-browser]0.5.3-34

Versions of packages apache2 is related to:
ii  apache2  2.4.38-3+deb10u4
ii  apache2-bin  2.4.38-3+deb10u4

-- no debconf information

Bug#979296: u-boot: Restructure the packaging

[Nicolas Boulenguez]

Source: u-boot
Followup-For: Bug #979296

The attached targets.py generates a slightly improved indentation than
the one in previous message.

Also, a redirection was wissing in
# python3 PATH/TO/ATTACHED/targets.py debian/targets > debian/targets.mk
Please use
# python3 PATH/TO/ATTACHED/targets.py < debian/targets > debian/targets.mk
instead.
#!/usr/bin/python3

# Convert debian/targets to a Makefile snippet included by
# debian/rules.

# python3 debian/targets.py < debian/targets > debian/targets.mk

qemu = {}
architectures = {}
maintainers = []

with open ('debian/targets') as i:
assert i.readline () == '# ARCH	subarch		platform	target\n'
assert i.readline () == '# \n'
for line in i:
if line == '\n':
maintainers = []
continue
if line.startswith('#'):
maintainers.append (line.rstrip ())
continue
fields = line.rstrip ().split ()
arch, subarch, platform = fields [:3]
targets = fields [3:]

if arch.startswith ('all'):
assert subarch == 'qemu'
qemu [platform] = (arch, targets)
else:
if arch not in architectures:
architectures [arch] = {}
packages = architectures [arch]

if subarch == '-':
package = 'u-boot'
else:
package = f'u-boot-{subarch}'
if package not in packages:
packages [package] = {}
platforms = packages [package]

platforms [platform] = (targets, maintainers)

print ('# Target architectures supported by u-boot in Debian.')
print ('# debian/rules includes this Makefile snippet.')

def format_targets (platform : str,
targets  : list):
s = f'  {platform}_targets :='
for t in sorted (targets):
if 75 < len (s) + len (t):
print (s + ' \\')
s = '   '
s += f' {t}'
print (s)

else_ifeq = False

for arch in sorted (architectures.keys ()):
print ('')
if else_ifeq:
print ('else ', end='')
else:
else_ifeq = True
print ('ifeq (${DEB_HOST_ARCH},' + arch + ')')

packages = architectures [arch]
for package in sorted (packages.keys ()):
print ('')
print (f'# {package}')
platforms = packages [package]
for platform in sorted (platforms.keys ()):
targets, maintainers = platforms [platform]
print ('')
for maintainer in maintainers:
print (f'  {maintainer}')
print (f'  {package}_platforms += {platform}')
if targets [0].startswith ('/usr/lib/arm-trusted-firmware/'):
print (f'  {platform}_assigns := BL31={targets.pop (0)}')
if platform != 'novena-rawsd':
targets.append ('uboot.elf')
format_targets (platform, targets)

print ('')
print ('endif')

print ('')
print ('# u-boot-qemu (Architecture: all)')
for platform in sorted (qemu.keys ()):
arch, targets = qemu [platform]
print ('')
print (f'  u-boot-qemu_platforms += {platform}')
gnu_type = arch[4:]
print (f'  {platform}_CROSS_COMPILE := {gnu_type}-')
targets.append ('uboot.elf')
format_targets (platform, targets)

Bug#985139: unblock: manpages-l10n/4.9.3-1

[Helge Kreutzmann]

retitle 985139 unblock: manpages-l10n/4.9.3-4
thanks

Hello Ivo,
On Sun, Mar 14, 2021 at 10:35:56PM +0100, Helge Kreutzmann wrote:
> retitle 985139 unblock: manpages-l10n/4.9.3-3
> tags 985139 - moreinfo
> thanks
> 
> Hello Ivo,
> On Sun, Mar 14, 2021 at 03:53:01PM +0100, Ivo De Decker wrote:
> > Control: tags -1 confirmed moreinfo
> > 
> > On Sat, Mar 13, 2021 at 04:02:43PM +0100, Helge Kreutzmann wrote:
> > > Please unblock package manpages-l10n
> > 
> > In General, I think this is ok, if the issues below can be fixed fairly 
> > soon.
> > 
> > [...]
> > 
> > > Furthermore, I finally managed to contact Javier Fernández-Sanguino
> > > Peña, and we agreed that the very outdated spanish man page
> > > translations are taken over by manpages-l10n, manpages-es-extra is
> > > asked for removal.
> > 
> > The current version has this in debian/control:
> > 
> > Replaces: manpages-es (<= 1.55-10), manpages-es-extraA
> > 
> > That's clearly a typo. Please fix this first. When that fix is in unstable,
> > please remove the moreinfo tag from this bug and retitle it as needed.
> > 
> > I assume you tested the upgrade scenario from manpages-es-extra to the
> > packages that currently contain the manpages?
> 
> I now tested the scenario, sorry for not doing this in the last
> upload. Thanks for spotting.

Sigh, I did not check all instances, where upstream claimed to remove
files, now done.

> > > I can prepare the debdiff, but it will contain lots of changes, since
> > > many man pages had updated (even if only due to po4a reformatting
> > > them).
> > 
> > Could you prepare a filtered debdiff between the version currently in 
> > testing
> > and the new upload to unstable, that doesn't contain the translation 
> > changes.
> > Also, please mention the command you used to do the filtering.
> 
> I used:
> debdiff --exclude "upstreambug" --exclude "upstream" --exclude "templates" 
> --exclude "po" --exclude copyright --exclude create-authors-file.sh --exclude 
> README.md ./4.9.1-7/manpages-l10n_4.9.1-7.dsc 
> ./4.9.3-3/manpages-l10n_4.9.3-3.dsc
> 
> The filtered debdiff is attached.

The updated filtered debdiff is attached, same filters.

> > > [ Other info ]
> > > If there is any open question regarding this unblock, I'm most happy
> > > to provide it.
> > > 
> > > In the changelog unfortunately there is a typo, the new upstream
> > > versio is indeed 4.9.3, *not* 4.9.1.
> > 
> > As a new upload is needed anyway, you can fix this too.
> 
> This is fixed as well (was already fixed in git).
> 
> unblock manpages-l10n/4.9.3-3

unblock manpages-l10n/4.9.3-4

Thanks

Helge


-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
diff -Nru --exclude upstreambug --exclude upstream --exclude templates 
--exclude po --exclude copyright --exclude create-authors-file.sh --exclude 
README.md manpages-l10n-4.9.1/aclocal.m4 manpages-l10n-4.9.3/aclocal.m4
--- manpages-l10n-4.9.1/aclocal.m4  2021-02-06 21:39:51.0 +0100
+++ manpages-l10n-4.9.3/aclocal.m4  2021-03-09 20:24:24.0 +0100
@@ -1,4 +1,4 @@
-# generated automatically by aclocal 1.16.2 -*- Autoconf -*-
+# generated automatically by aclocal 1.16.3 -*- Autoconf -*-
 
 # Copyright (C) 1996-2020 Free Software Foundation, Inc.
 
@@ -14,8 +14,8 @@
 m4_ifndef([AC_CONFIG_MACRO_DIRS], [m4_defun([_AM_CONFIG_MACRO_DIRS], 
[])m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS($@)])])
 m4_ifndef([AC_AUTOCONF_VERSION],
   [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
-m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.70],,
-[m4_warning([this file was generated for autoconf 2.70.
+m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.71],,
+[m4_warning([this file was generated for autoconf 2.71.
 You have another version of autoconf.  It may work, but is not guaranteed to.
 If you have problems, you may need to regenerate the build system entirely.
 To do so, use the procedure documented by the package, typically 
'autoreconf'.])])
@@ -35,7 +35,7 @@
 [am__api_version='1.16'
 dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
 dnl require some minimum version.  Point them to the right macro.
-m4_if([$1], [1.16.2], [],
+m4_if([$1], [1.16.3], [],
   [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
 ])
 
@@ -51,7 +51,7 @@
 # Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced.
 # This function is AC_REQUIREd by AM_INIT_AUTOMAKE.
 AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
-[AM_AUTOMAKE_VERSION([1.16.2])dnl
+[AM_AUTOMAKE_VERSION([1.16.3])dnl
 m4_ifndef([AC_AUTOCONF_VERSION],
   [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
 _AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))])
@@ -370,12 +370,7 @@
 [AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
 AC_REQUIRE_AUX_FILE([missing])dnl
 if 

Bug#985369: Banana Pi Call Trace in sound/core/init.c:207 snd_card_new+0x430/0x480 [snd]

[Tuxo]

Package: 5.10.0-4-armmp-lpae
Version: Debian 5.10.19-1: armhf

Call Trace coming up:

[  +0.303626] [ cut here ]
[  +0.008081] WARNING: CPU: 0 PID: 248 at sound/core/init.c:207 
snd_card_new+0x430/0x480 [snd]
[  +0.007999] Modules linked in: sun4i_codec(E+) snd_soc_core(E) 
snd_pcm_dmaengine(E) snd_pcm(E) nvmem_sunxi_sid(E) sun4i_ts(E) sg(E) 
snd_timer(E) snd(E) sunxi_cir(E) soundcore(E) rc_core(E) sun4i_ss(E+) 
libdes(E) sunxi_wdt(E) sunxi_cedrus(CE) videobuf2_dma_contig(E) 
v4l2_mem2mem(E) videobuf2_memops(E) videobuf2_v4l2(E) 
videobuf2_common(E) leds_gpio(E) cpufreq_dt(E) fuse(E) configfs(E) 
sunrpc(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) 
mbcache(E) jbd2(E) btrfs(E) blake2b_generic(E) xor(E) xor_neon(E) 
raid6_pq(E) libcrc32c(E) crc32c_generic(E) f2fs(E) crc32_generic(E) 
sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) 
crct10dif_common(E) axp20x_usb_power(E) industrialio(E) 
pinctrl_axp209(E) axp20x_regulator(E) realtek(E) sun4i_backend(E) 
dwmac_sunxi(E) stmmac_platform(E) stmmac(E) ohci_platform(E) pcs_xpcs(E) 
phylink(E) ahci_sunxi(E) ehci_platform(E) ohci_hcd(E) 
libahci_platform(E) ptp(E) libahci(E) sunxi(E) phy_generic(E) lima(E) 
libata(E) gpu_sched(E) musb_hdrc(E)
[  +0.000354]  pps_core(E) ehci_hcd(E) udc_core(E) i2c_mv64xxx(E) 
scsi_mod(E) sun4i_drm_hdmi(E) usbcore(E) cec(E) spi_sun4i(E) 
sunxi_mmc(E) phy_sun4i_usb(E) sun4i_drm(E) sun4i_frontend(E) 
sun4i_tcon(E) sun8i_tcon_top(E) drm_kms_helper(E) display_connector(E) 
drm(E)
[  +0.064237] CPU: 0 PID: 248 Comm: systemd-udevd Tainted: G C 
E 5.10.0-4-armmp-lpae #1 Debian 5.10.19-1

[  +0.010143] Hardware name: Allwinner sun7i (A20) Family
[  +0.010019] Backtrace:
[  +0.009907] [] (dump_backtrace) from [] 
(show_stack+0x20/0x24)

[  +0.010172]  r7:00cf r6:600f0113 r5: r4:c16d04d0
[  +0.010253] [] (show_stack) from [] 
(dump_stack+0xc8/0xdc)
[  +0.010012] [] (dump_stack) from [] 
(__warn+0xfc/0x158)

[  +0.010183]  r7:00cf r6:0009 r5:bf6e1604 r4:bf6eb01c
[  +0.010016] [] (__warn) from [] 
(warn_slowpath_fmt+0x70/0xe4)

[  +0.010317]  r7:bf6e1604 r6:00cf r5:bf6eb01c r4:
[  +0.010074] [] (warn_slowpath_fmt) from [] 
(snd_card_new+0x430/0x480 [snd])

[  +0.010305]  r8:c2e0f8c4 r7:c1a3ec10 r6: r5:c2ca3000 r4:
[  +0.010210] [] (snd_card_new [snd]) from [] 
(snd_soc_bind_card+0x3a8/0xa30 [snd_soc_core])
[  +0.010262]  r10: r9:bf759d8c r8:c1a26e80 r7:0001 
r6:0050 r5:c2e0f840

[  +0.010202]  r4:c2bc2d00
[  +0.010557] [] (snd_soc_bind_card [snd_soc_core]) from 
[] (snd_soc_register_card+0xf8/0x108 [snd_soc_core])
[  +0.010486]  r10:0024 r9:bf733170 r8:c1a26e80 r7:bf72e6f4 
r6:c1a3ec10 r5:c2bd4a00

[  +0.010532]  r4:c2e0f840
[  +0.010512] [] (snd_soc_register_card [snd_soc_core]) from 
[] (sun4i_codec_probe+0x230/0x468 [sun4i_codec])

[  +0.011003]  r5:c2bd4a00 r4:0002
[  +0.010799] [] (sun4i_codec_probe [sun4i_codec]) from 
[] (platform_drv_probe+0x58/0xa8)

[  +0.011063]  r8: r7:c17f1de0 r6:bf733170 r5:c1a3ec10 r4:
[  +0.011147] [] (platform_drv_probe) from [] 
(really_probe+0x108/0x514)

[  +0.011228]  r7:c17f1de0 r6: r5:c17f1dd8 r4:c1a3ec10
[  +0.011134] [] (really_probe) from [] 
(driver_probe_device+0x100/0x1d4)
[  +0.16]  r10:bf733940 r9:c1604e00 r8:c2f15f30 r7:bf733170 
r6:c1a3ec54 r5:bf733170

[  +0.06]  r4:c1a3ec10
[  +0.15] [] (driver_probe_device) from [] 
(device_driver_attach+0xb8/0xc0)
[  +0.10]  r9:c1604e00 r8:c2f15f30 r7:bf733170 r6:c1a3ec54 
r5: r4:c1a3ec10
[  +0.12] [] (device_driver_attach) from [] 
(__driver_attach+0x9c/0x150)

[  +0.18]  r7:c17579a8 r6:c1a3ec10 r5:bf733170 r4:
[  +0.079177] [] (__driver_attach) from [] 
(bus_for_each_dev+0x84/0xd0)

[  +0.16]  r7:c17579a8 r6:c0aac58c r5:bf733170 r4:
[  +0.13] [] (bus_for_each_dev) from [] 
(driver_attach+0x2c/0x30)

[  +0.08]  r6: r5:c2f71780 r4:bf733170
[  +0.11] [] (driver_attach) from [] 
(bus_add_driver+0x120/0x20c)
[  +0.13] [] (bus_add_driver) from [] 
(driver_register+0x98/0x128)

[  +0.08]  r7: r6:bf733a70 r5: r4:bf733170
[  +0.13] [] (driver_register) from [] 
(__platform_driver_register+0x50/0x58)

[  +0.07]  r5:c2fbe300 r4:c17579a8
[  +0.53] [] (__platform_driver_register) from 
[] (sun4i_codec_driver_init+0x24/0x1000 [sun4i_codec])

[  +0.06]  r5:c2fbe300 r4:bf704000
[  +0.24] [] (sun4i_codec_driver_init [sun4i_codec]) from 
[] (do_one_initcall+0x50/0x27c)
[  +0.14] [] (do_one_initcall) from [] 
(do_init_module+0x70/0x2a4)

[  +0.09]  r7:c2f15ea8 r6:bf733a70 r5:c2fbe300 r4:bf733940
[  +0.10] [] (do_init_module) from [] 
(load_module+0x2260/0x264c)

[  +0.08]  r6:bf733a70 r5:bf73394c r4:
[  +0.10] [] (load_module) from [] 
(sys_finit_module+0xc8/0x12c)
[  +0.12]  r10:017b r9:c2f14000 r8:c04002c4 r7:017b 
r6:b6f60504 r5:0014

[  +0.05]  r4:
[  

Bug#964503: okular: typewriter annotation ignores configured font family

[Kristofer Bitner]

I am having the same issue in Ubuntu 20.04 using the latest stable snap
version.  The issue seems to exist in the Windows version as well.

--
Kristofer Bitner

Bug#985368: unblock: sphinx/3.4.3-2

[Dmitry Shachnev]

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

Dear Release team,

Please unblock package sphinx.

[ Reason ]
It fixes bug #983858 which prevented use of dh_sphinxdoc with "singlehtml"
build format (when everything is built into a single HTML page).

dh_sphinxdoc is a helper tool that takes care of symlinking static JS
files, adding the needed dependencies and doing sanity checks.

[ Impact ]
Some packages that want to use singlehtml format (e.g. python3-defaults)
will have to either do things manually, or ship unsymlinked copies of Sphinx
JS code.

[ Tests ]
It is easy to test this manually. Here is a simple test case based on
mathjax-docs package:

- Add "-b singlehtml" to the sphinx-build invokation in debian/rules.
- Build the package.
- Look at dh_sphinxdoc output.

Without this fix, you get "dh_sphinxdoc: warning: Sphinx documentation not
found". And then lots of Lintian embedded-javascript-library and
package-contains-python-doctree-file warnings.

With the fix, all is fine (except a couple of harmless warnings about unknown
JavaScript code that dh_sphinxdoc cannot symlink).

[ Risks ]
Sphinx is a key package but the fix is very trivial.

[ 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 ]
The fix is adjusting the regex to not require type="text/javascript"
attribute. Sphinx does not add that attribute since version 2.4.0:
https://github.com/sphinx-doc/sphinx/pull/6925.

dh_sphinxdoc will still allow that attribute to be present, which may be
needed for packages or themes using their own templates.

unblock sphinx/3.4.3-2

--
Dmitry Shachnev
diff -Nru sphinx-3.4.3/debian/changelog sphinx-3.4.3/debian/changelog
--- sphinx-3.4.3/debian/changelog	2021-01-08 20:11:19.0 +0300
+++ sphinx-3.4.3/debian/changelog	2021-03-08 21:40:25.0 +0300
@@ -1,3 +1,10 @@
+sphinx (3.4.3-2) unstable; urgency=medium
+
+  * dh_sphinxdoc: Fix the script tag regex used in singlehtml detection
+(closes: #983858).
+
+ -- Dmitry Shachnev   Mon, 08 Mar 2021 21:40:25 +0300
+
 sphinx (3.4.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru sphinx-3.4.3/debian/dh-sphinxdoc/dh_sphinxdoc sphinx-3.4.3/debian/dh-sphinxdoc/dh_sphinxdoc
--- sphinx-3.4.3/debian/dh-sphinxdoc/dh_sphinxdoc	2021-01-08 20:11:19.0 +0300
+++ sphinx-3.4.3/debian/dh-sphinxdoc/dh_sphinxdoc	2021-03-08 21:40:25.0 +0300
@@ -211,7 +211,7 @@
 open(my $fh, '<', $html_file) or error("cannot open $html_file");
 while (my $line = <$fh>)
 {
-if ($line =~ 

Bug#979206: still fails with 6.1.18-dfsg-3

[Claudio Laurita]

Build still fails with 6.1.18-dfsg-3

Bug#985366: thunderbird: Incorrect StartupWMClass in desktop file

[Colomban Wendling]

Package: thunderbird
Version: 1:78.8.0-1
Severity: normal
Tags: patch

Dear Maintainer,

The thunderbird.desktop file contains `StartupWMClass=Thunderbird`.
This is incorrect as the Thunderbird window has the WM classes
`Mail` and `thunderbird` (lowercase):

$ grep StartupWMClass /usr/share/applications/thunderbird.desktop 
StartupWMClass=Thunderbird
$ xprop WM_CLASS
[click on the Thunderbird main window]
WM_CLASS(STRING) = "Mail", "thunderbird"

This impacts some startup detection logic, and most noticeably
bamfdeamon which then fails to match windows to the right app.

Note that there *is* apparently a Thunderbird window which includes the
"Thunderbird" WM class, but that's not the main window, and it kind of
looks like a ghost window (other details are funky, including
WM_NORMAL_HINTS specifying a 10x10 window, no icons, etc.):

$ xprop -name Thunderbird WM_CLASS
WM_CLASS(STRING) = "thunderbird", "Thunderbird"

In any case, this window also includes the lowercase class, so would be
matched just as well by it.

Attached is a simple patch that lowercases the StartupWMClass in the
desktop file, which fixes bamfdeamon window matching and doesn't seem
to otherwise cause issues.
This affects e.g. mate-dock-applet as it is a bamfdeamon client.

Regards,
Colomban


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

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

Versions of packages thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libbotan-2-172.17.3+dfsg-3
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-4
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.20-1
ii  libdbus-glib-1-2 0.110-5
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-5
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.2+dfsg-4
ii  libgcc-s110.2.1-1
ii  libgdk-pixbuf-2.0-0  2.40.0+dfsg-10
ii  libglib2.0-0 2.66.2-1
ii  libgtk-3-0   3.24.23-2
ii  libicu67 67.1-4
ii  libjson-c5   0.15-1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.60-1
ii  libpango-1.0-0   1.46.2-1
ii  libstdc++6   10.2.1-1
ii  libvpx6  1.8.2-1
ii  libx11-6 2:1.7.0-2
ii  libx11-xcb1  2:1.7.0-2
ii  libxcb-shm0  1.14-2
ii  libxcb1  1.14-2
ii  libxext6 2:1.3.3-1+b2
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.3-1
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1
ii  myspell-fr-gut [myspell-dictionary]   1:1.0-32

Versions of packages thunderbird suggests:
ii  apparmor  2.13.5-1+b2
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.17-10
ii  libgtk2.0-0   2.24.32-4

-- no debconf information
Fix the StartupWMClass to actually match what Thunderbird sets as WM_CLASS

--- a/debian/thunderbird.desktop
+++ b/debian/thunderbird.desktop
@@ -10,7 +10,7 @@ Version=1.0
 Icon=thunderbird
 Categories=Network;Email;News;GTK;
 MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/x-vcard;
-StartupWMClass=Thunderbird
+StartupWMClass=thunderbird
 StartupNotify=true
 Name[ast]=Veceru de corréu Thunderbird
 Name[ca]=Client de correu Thunderbird

Bug#982929: systemd: upstream testsuite failures on armhf

[Michael Biebl]

Control: tags -1 + moreinfo

On Wed, 17 Feb 2021 03:02:23 +0900 Ryutaroh Matsumoto 

> Salsa latest version of autopkgtest adds support of armhf qemu
testbed.
> autopkgtest-virt-qemu --dpkg-architecture=armhf on systemd fails at
> root-unit-test and upstream.
> Both failures are caused by the assertion failure of
safe_personality().
> The relevant parts of log are as follows.
> I am not sure it is a problem in systemd testsuite, or kernel, or
> elsewhere...
> 
> root-unittests-stderr:28315:Assertion '(unsigned long)
safe_personality(current) == current' failed at src/test/test-
seccomp.c:837, function test_lock_personality(). Aborting.
> upstream-stdout:4788:Assertion '(unsigned long)
safe_personality(current) == current' failed at src/test/test-
seccomp.c:837, function test_lock_personality(). Aborting.
> 

...

> Architecture: arm64 (aarch64)

Might be an issue of trying to execute armhf on a arm64 kernel.
But I'm no expert on this and I don't have the necessary hardware to
try this, so could you please raise this upstream yourself and report
back with the issue number?
It's likely that upstream has follow-up questions.

Thanks,
Michael


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

Bug#985315: gnome-flashback: bluetooth icon no longer shown in the notification area

[Dmitry Shachnev]

Hi Sandro!

On Mon, Mar 15, 2021 at 04:45:34PM -0400, Sandro Tosi wrote:
> Hello,
> i recently upgraded to 3.38.0 for the flashback settings, but now the
> bluetooth icon is no longer shown in the notification area, even if
> bluetooth is enabled (and also when disabled/enabled, just in case it
> needs some convincing).

Can you please check if you have the “System Indicators” applet in your
panel?

E.g. you can check if the following list has system-indicators:

$ gsettings get org.gnome.gnome-panel.layout object-id-list

If not, Alt+right click on the panel, click “Add to Panel…” and select
“System Indicators” (in org.gnome.gnome-flashback.system-indicators group).
The same applet also provides keyboard layout, volume and power indicators.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#985365: ITP: rstcheck -- Validator for reStructuredText documents with code blocks

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org, t...@gaussglocke.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rstcheck
  Version : 3.3.1
  Upstream Author : Steven Myint
* URL : https://github.com/myint/rstcheck
* License : MIT
  Programming Lang: Python
  Description : Validator for reStructuredText documents with code blocks

rstcheck validates the syntax of reStructuredText documents. Unlike other
validators, it will also verify syntax correctness in nested code blocks
for a variety of languages:

  * Bash shell scripts
  * Doctest
  * C (C99)
  * C++ (C++11)
  * JSON
  * XML
  * Python
  * reStructuredText

rstcheck can also validate Sphinx documentation files if Sphinx is installed.

-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmBQ7RsACgkQ+C8H+466
LVmWhQwA4CCVLg3YGWgGV02Tu+1R4HY/p0hJI4GhZNjhwzld0ohO1vCNfRaj2WHA
+DvsPDFILGnLe5zL5Wl/Wrckr3IdvNvfet4oQozKOBI09kytJMp4Zaty2tryPodQ
85T0St9APxHzd2IDNcyvbbKAP6RuigxklGHc1+VfS1mBc2EixTl83/oW8XTMTQy2
0OL/8ue7r6mKy6caCC/el4xkwNwE6tH+K0k6rQFfXmTqU5SponIuGOwQ+u5XMiAt
5I/JyfJyq7M+2YdLcAitn0/Z7e86/46mASD3o7uMevHVM146UNkNFFgbX3eXhcwj
fC+ketgoGL2z/a1sMiHoYcim9mkC4onfrlwxzauzJ/uyexBV4smtYyZ4LOxItPib
L+n0MKkn1+tvbCKEsIlnDMOjW+tX245wIVAF8IdvVmalS3jiopiCpAx4LzXx91XJ
cKrxWJOkACwgO4uFeRHOz9YY5VJ1FpXok2Y8nzxHlCCLdPau1fBSgOaAgZ+xzNc7
XAVG208G
=cRuM
-END PGP SIGNATURE-

Bug#985364: Aborted (core dumped) drawing a simple GRIB file

[Enrico Zini]

Package: python3-magics++
Version: 2:1.5.5-1
Severity: important

Hello,

thank you for maintaining Magics in Debian!

I'm attaching a test case which causes Magics to abort on current
bullseye:

$ python3 magics-crash.py 
ecCodes assertion failed: `h' in ./src/grib_query.c:572
Aborted (core dumped)

grib_dump seems to open the GRIB file just fine.


Enrico


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

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

Versions of packages python3-magics++ depends on:
ii  libmagplus3v5   3.3.1-1
ii  python3 3.7.3-1
ii  python3-jinja2  2.10-2
ii  python3-numpy [python3-numpy-abi9]  1:1.16.2-1
ii  python3-simplejson  3.16.0-1

python3-magics++ recommends no packages.

python3-magics++ suggests no packages.

-- no debconf information


magics-crash.tar.xz
Description: application/xz

Bug#983366: linphone-desktop: Settings popup menu

[Dennis Filder]

On Mon, Mar 15, 2021 at 11:06:38PM -0300, David Pirotte wrote:

> GNOME desktop - 3.38-4
> Yes, Wayland, no idea about X 'only'
>
>   but, worth mentioning that that the upstream appimage works
>   fine, I mean running under the (exact) same
>   'conditions'/desktop env

Okay, that's important information.  The goal is now to find out what
the appimage does differently.  I suspect the culprit to be this
library:

> /usr/lib/x86_64-linux-gnu/qt5/plugins/platformthemes/libqgtk3.so

Try running linphone like this from a shell:

GDK_BACKEND=x11 linphone

Alternatively like this:

QT_QPA_PLATFORMTHEME=qt5ct linphone

If that doesn't fix it you need to compare the output of the above
command to the output of the same command with the appimage linphone
running.  Also you should compare for both versions the output of

tr '\0' '\n' < /proc/$(pidof linphone)/environ | \
grep -v '^[[:space:]]\+'|sort

Provide the outputs if you want me to take a look.

Bug#985363: unblock: cross-toolchain-base/53

[plugwash]

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

Please unblock package cross-toolchain-base

cross-toolchain-base 52 has overzelous conflicts between multilib
libc packages which make the build-dependencies of gcc-10-cross and
gcc-9-cross unsatisfiable.

  package: gcc-10-cross
  version: 15
  architecture: all,arm64,i386,ppc64el,x32,amd64,ppc64
  type: src
  status: broken
  reasons:
   -
conflict:
 pkg1:
  package: libc6-x32-i386-cross
  version: 2.31-9cross3
  architecture: all
  unsat-conflict: libc6-x32-amd64-cross:amd64
 pkg2:
  package: libc6-x32-amd64-cross
  version: 2.31-9cross3
  architecture: all

This is fixed in cross-toolchain-base 53.

unblock cross-toolchain-base/53
diff -Nru cross-toolchain-base-52/debian/changelog 
cross-toolchain-base-53/debian/changelog
--- cross-toolchain-base-52/debian/changelog2021-02-21 08:30:19.0 
+
+++ cross-toolchain-base-53/debian/changelog2021-03-03 11:54:20.0 
+
@@ -1,3 +1,9 @@
+cross-toolchain-base (53) unstable; urgency=medium
+
+  * Don't let the libc*-cross multilib packages conflict with each other.
+
+ -- Matthias Klose   Wed, 03 Mar 2021 12:54:20 +0100
+
 cross-toolchain-base (52) unstable; urgency=medium
 
   * Build using linux 5.10.13.
diff -Nru cross-toolchain-base-52/debian/rules 
cross-toolchain-base-53/debian/rules
--- cross-toolchain-base-52/debian/rules2021-02-21 08:30:19.0 
+
+++ cross-toolchain-base-53/debian/rules2021-03-03 11:54:20.0 
+
@@ -923,6 +923,11 @@
grep -q '^Multi-Arch:' $$tmp/DEBIAN/control \
  || echo 'Multi-Arch: foreign' >> $$tmp/DEBIAN/control; \
esac; \
+   case "$$pkgname" in \
+ libc*-dev*-cross) ;; \
+ libc*-cross) \
+   sed -i -E '/^Conflicts:/s/ libc[^,]*(,|$$)//g;/^Conflicts: *$$/d' 
$$tmp/DEBIAN/control; \
+   esac; \
newdeb=`echo $$deb|sed -e 
"s/\(.*\)_\(.*\)_\(.*\)/\1_\2$(CROSS_EXT)_\3/g"`; \
NO_PKG_MANGLE=1 PKG_IGNORE_CURRENTLY_BUILDING=1 dpkg-deb -b $$tmp/ 
../$$newdeb; \
rm -rf $$tmp

Bug#982381: AttributeError: lowlevel due to trio usage in s3ql/block_cache.py

[Andrey Rahmatullin]

On Thu, Feb 18, 2021 at 03:28:36PM +0100, Francesco P. Lovergine wrote:
> I'm pretty sure this release should depend on >= 0.15,
> even due to #981906. Unfortunately, it is not expressed in the package
From setup.py:

 # Need trio.lowlevel
 'trio >= 0.15',

So it's expressed upstream but ignored in the Debian package, because
dh_python3 ignores version reqs by default.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#985149: debootstrap stumbles over tabs in include parameter

[Christian Lamparter]

Hello Steve,

On 16/03/2021 15:12, Steve McIntyre wrote:

On Sat, Mar 13, 2021 at 05:56:26PM +0100, Christian Lamparter wrote:

Package: debootstrap
Version: 1.0.123
Severity: normal

Dear Maintainer,

I ran into an issue when I was using debootstrap in order to setup a chroot-
environment.

I: Retrieving InRelease
I: Checking Release signature
I: Valid Release signature (key id 6D33866EDD8FFA41C0143AEDDCC9EFBF77E11517)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://deb.debian.org/debian...
E: Couldn't find these debs: 48477576

I was surprised to see that "48477576". I expected to get the
name of the package that was causing this, instead of a number.
I dug deeper to see what's causing this and I was surprised
when I found out that the parameter '--include=package'
that was passed to debootstrap was causing this.

Here's a reproducer (can be copied into bash). It fetches the
current debian stable for amd64 with "gzip" as an extra package.
(that $(printf \\t) is in this example, here so the "tab" won't
get lost when copying)


Ummm. Why are you expecting debootstrap to deal with whitespace here?
I'm not convinced this is a bug...


What threw me off is that "E: Couldn't find these debs: 48477576".
48477576 is not a package, right?.

Well, the backstory is: I came across this, because I needed some
extra, but sensible packages in my basic image for it to be useful.

this script look(ed) like this (a mailer with tab support is needed
for proper alignment)

---
PACKAGE="initramfs-tools,gzip,u-boot-tools,device-tree-compiler,\
 debian-keyring-archive,bzip2, ca-certificates,wget,\
 ..."

debootstrap --include="$PACKAGE" ...
---

But it bugged and I had no idea it was because I was using tabs to
align the extra PACKAGE in the next lines because they wouldn't fit
due to 80 cols limit.

Once I figured out that the use of tabs are the issue, I replaced
them with spaces. Then I went on to write a proper bug-report with
a testcase and PoC-patch, in case someone (like future me) stumbles
over this as well: "Check your include/excludes with a fine comb".


But back to the business at hand... Because I would need to know
why you think that a Error message like
"E: Couldn't find these debs: 48477576"
doesn't trigger a "yeah, this 48477576 looks buggy"?

Is there a deeper meaning to the numbers like 48477576?...
or:
 - 29976556? 
()
 - 91369800? 
()
 - 0? ()

that I don't get?

Cheers,
Christian

Bug#983776: libvkd3d-dev 1.2-3 breaks multi-arch support

[Henri Verbeet]

On 2021-03-03 15:38, Francois Gouget wrote:

Just asking. I don't actually know if the 32- and 64-bit vkd3d-compiler
produce identical files or if one produces 32-bit files and the other
64-bit ones.

The output produced by i386 and amd64 (or any other, for that matter) 
builds of vkd3d-compiler should be identical; if it isn't, that would be 
considered a bug. For the record, I would be inclined to agree that the 
-dev package is not the appropriate place for vkd3d-compiler.


On the subject of Wine builds requiring both vkd3d-dev:amd64 and 
vkd3d-dev:i386, although somewhat tangential, note that Wine doesn't 
only use libvkd3d for its implementation of Direct3D 12, but also 
libvkd3d-shader for producing SPIR-V shaders for the Vulkan backend of 
its implementation of Direct3D 11 and earlier, where i386 applications 
are much more common.

Bug#985358: pitivi: A/V out of sync in rendered videos

[Antonio Terceiro]

On Tue, Mar 16, 2021 at 04:45:39PM +0200, Sebastian Dröge wrote:
> On Tue, 2021-03-16 at 11:16 -0300, Antonio Terceiro wrote:
> 
> Dear Maintainer,
> 
> The version of pitivi in bullseye is affected by the bug listed above:
> rendered videos have A/V out of sync by a few seconds, while they sound
> just find in the preview.
> 
> I'm attaching the upstream patch that fixed the issue, already
> backported to the current Debian package. I rebuilt pitivi locally with
> this patch, and confirmed that it does fix the issue.
> 
> Yeah I'm aware of this and various other issues in the version
> currently in Debian, and which are fixed in the latest releases.
> 
> Due to Debian release freeze policies the latest release is not
> uploaded yet and I don't know how useful it is to just patch some of
> the issues.
> 
> In the end what we'd really want is the latest release.

As a user, I don't even know about all the stuff that could be better;
pitivi worked ok for me as an amateur video editor. It just failed at
the end of the process, rendering the video. So from my PoV, the version
in bullseye is fine once this is fixed.

Of course the latest and greatest if always better, but that's
incompatible with a stable release. We just have to cut it at some
point.


signature.asc
Description: PGP signature

Bug#984952: fixed in freecad 0.19.1+dfsg1-1

[Gianfranco Costamagna]

control: notfixed -1 0.19.1+dfsg1-1
control: reopen -1

Hello, not fixed due to an extra space in the patch.

Will fix and reupload shortly

G.

On Tue, 16 Mar 2021 02:33:32 + Debian FTP Masters 
 wrote:
> Source: freecad
> Source-Version: 0.19.1+dfsg1-1
> Done: Kurt Kremitzki 
> 
> We believe that the bug you reported is fixed in the latest version of
> freecad, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 984...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Kurt Kremitzki  (supplier of updated freecad package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Mon, 15 Mar 2021 21:00:32 -0500
> Source: freecad
> Architecture: source
> Version: 0.19.1+dfsg1-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Science Maintainers 
> 
> Changed-By: Kurt Kremitzki 
> Closes: 984952
> Changes:
>  freecad (0.19.1+dfsg1-1) unstable; urgency=medium
>  .
>[ Christian Ehrhardt ]
>* [fbc90b2] skip self test open_de9b3fb438 on s390x as it goes OOM
>  (LP: #1918474)(Closes: #984952)
>  .
>[ Kurt Kremitzki ]
>* [3ae55a4] New upstream version 0.19.1+dfsg1
>* [bc2242e] Drop fix-fem-crash.patch, included in 0.19.1
> Checksums-Sha1:
>  087cbe53d2e1b7a3ac673d0cfeb68274037649a6 3348 freecad_0.19.1+dfsg1-1.dsc
>  89a06b08061884f5c17cea81feff2466e47078c0 34522364 
> freecad_0.19.1+dfsg1.orig.tar.xz
>  9091af0465eb2856ca29ab5d5e842d38e2cf2f30 27860 
> freecad_0.19.1+dfsg1-1.debian.tar.xz
>  43ac3ac4543d7fcbea71c98361f450133e599673 31613 
> freecad_0.19.1+dfsg1-1_source.buildinfo
> Checksums-Sha256:
>  f826931a60c7a13e9ac2b36f64eabb94297d49ba4142063a97314888305bcdd8 3348 
> freecad_0.19.1+dfsg1-1.dsc
>  6f2c62def05afc720de33567ccbd5d53ee48a138d6978450c2f180c18a50d185 34522364 
> freecad_0.19.1+dfsg1.orig.tar.xz
>  1663b2d422b44ee8c294706e0a8ac0e346164d4963516d969eca1603409f30ba 27860 
> freecad_0.19.1+dfsg1-1.debian.tar.xz
>  ec38c05eee2430565c4471d2d498760fcd2cc69fe9e1e185af444ba38c540b5f 31613 
> freecad_0.19.1+dfsg1-1_source.buildinfo
> Files:
>  a99a4190707a67af13e6375e06cad49b 3348 science optional 
> freecad_0.19.1+dfsg1-1.dsc
>  989a7907ff223ca6887e4e8a99de3618 34522364 science optional 
> freecad_0.19.1+dfsg1.orig.tar.xz
>  72f4578d014da1525c7108a9565071ad 27860 science optional 
> freecad_0.19.1+dfsg1-1.debian.tar.xz

Bug#985228: unblock: petsc/3.14.5+dfsg1-2

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Sun, Mar 14, 2021 at 09:01:26PM +0100, Drew Parsons wrote:
> upstream released petsc 3.14.5 with bug fixes only.
> This will help improve the stability of the package over the lifetime
> of the bullseye release.

I'm not convinced this complies with the freeze policy (but see below).

> This update also fixes Bug#983892, fixing orphaned alternatives after
> removal of libpetsc64-complex3.14-dev,
> 
> [ Impact ]
> 
> If this release is not permitted into stable then some users may
> encounter the issues addressed by the patch, especially when running
> under MPI parallelization.  A range of bugs have been addressed:
> - MatBAIJ: Fix specialization for size 9
> - Do not use MPI_Bcast() on a single rank.
> - PCHPDDM: fix for KSPLSQR
> - DMPlexVTKWriteAll_VTU: a couple of bugfixes
> - handling error conditions in PetscOptions
> - handling NULL objects in Fortran interface
> - bugfix for MatMatMultSymbolic_MPIAIJ_MPIDense() 
> - CPARDISO: stick to OpenMPI BLACS when needed
> - minor Documentation fixes

> If the release is not allowed into stable then
> libpetsc64-complex3.14-dev will leave dangling alternatives links when
> removed.

This specific issue could be fixed without switching to a new upstream version
(as was done initially in 3.14.4+dfsg1-2).


> [ Tests ]
> 
> debian/tests autopkgtest is enabled.
> petsc debci tests have passed in unstable.
> 
> debci tests in client packages are also passing successfully in unstable
> (petsc4py, slepc, slep4py, deal.ii, dolfin, mshr, dolfinx)
> 
> sundials continues to build successfully.
> 
> [ Risks ]
> 
> The patch fixes a range of bugs, it is not a simple one-line patch.

> [ Checklist ]
>   [-] all changes are documented in the d/changelog
>   - documented as "New upstream release (bugfixes)"
>   [x] I reviewed all changes and I approve them
>   [ ] attach debdiff against the package in testing

We ask these this for a reason. The current diff between the version in
testing and unstable is very large and unreviewable. It certainly isn't going
to get unblocked like this. If you can provide a filtered diff, with only the
'real' changes, and not the noise generated by the new upstream release,
there's at least a chance we could look at them. Note that this doesn't
guarantee it will be unblocked. There's still a decent chance that the changes
will be too big.

Thanks,

Ivo

Bug#985362: mumble: Unhide after Minimize to tray flashes rapidly

[Jonathan Rubenstein]

Package: mumble
Version: 1.3.4-1
Severity: normal
X-Debbugs-Cc: jrub...@gmail.com

Dear Maintainer,

On KDE Plasma 5.20.5, when I use mumble's Hide in tray when minimized
feature, after clicking on the tray icon to show mumble again, the
client will rapidly display and hide until I click the icon again.
Sometimes this does not occur, and the client will display properly,
but it is more often than not it will flash.

Earlier last year, this flashing was a soft-lock to my input on the
machine, and I was not able to terminate mumble normally without
switching to a tty console, or even using SSH from my mobile phone.
This behavior has since improved, and is not as severe, so I am able
to stop mumble when this happens.

Is this really a KDE bug? I'm not sure. Let me know if I can provide
any more information.


Best Regards,

Jonathan Rubenstein
jrub...@gmail.com

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

Kernel: Linux 5.10.0-4-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE=fi:en_US

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

Versions of packages mumble depends on:
ii  libasound21.2.4-1.1
ii  libavahi-compat-libdnssd1 0.8-5
ii  libc6 2.31-9
ii  libgcc-s1 10.2.1-6
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  libprotobuf23 3.12.4-1
ii  libpulse0 14.2-2
ii  libqt5core5a  5.15.2+dfsg-5
ii  libqt5dbus5   5.15.2+dfsg-5
ii  libqt5gui55.15.2+dfsg-5
ii  libqt5network55.15.2+dfsg-5
ii  libqt5sql55.15.2+dfsg-5
ii  libqt5sql5-sqlite 5.15.2+dfsg-5
ii  libqt5svg55.15.2-2
ii  libqt5widgets55.15.2+dfsg-5
ii  libqt5xml55.15.2+dfsg-5
ii  libsndfile1   1.0.31-1
ii  libspeechd2   0.10.2-2
ii  libspeex1 1.2~rc1.2-1.1
ii  libspeexdsp1  1.2~rc1.2-1.1
ii  libssl1.1 1.1.1j-1
ii  libstdc++610.2.1-6
ii  libx11-6  2:1.7.0-2
ii  libxi62:1.7.10-1
ii  lsb-release   11.1.0

mumble recommends no packages.

Versions of packages mumble suggests:
ii  mumble-server  1.3.4-1
ii  speech-dispatcher  0.10.2-2

-- no debconf information

Bug#985361: unblock: pam/1.4.0-7

[Sam Hartman]

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

Please unblock package pam


[ Reason ]

Most of the changes are updated debconf translations for templates
introduced in the last release.  We knew we'd be getting those.

In testing the fix for 982530, we discovered that the regexp for
checking that pam_tally didn't end up in the final configuration
doesn't cover pam configs with a dash in them such as common-auth or
common-password.  Normally the profile-targeted test will handle the
common-* files, but this test does need to cover common-* in case the
user has added overrides explicitly.  So added dash to the character
class in the regexp.

Code review for #982295 discovered a couple of bugs.  The code happens
to work correctly, but for example I create a function that takes a
parameter and never uses it, instead accidentally using a global
variable of the same name.  If this was a long-standing bug, I'd not
ask for an unblock, but I think there ought to be a bit of a window to
fix errors found for RC fixes that were just introduced rather than
leaving foot-pointing-guns around.



[ Impact ]

Translations are obvious.

Without the regexp fix, situations that may leave a system impossible
to authenticate to will not be detected.

The change to libpam0g.postinst prevents us from surprising (and
hurting) ourselves if we need to make later changes.

[ Tests ] (What automated or
manual tests cover the affected code?)

I performed manual testing to confirm that the libpam-modules and
libpam0g maintainer scripts work as expected, adding a new manual test
for the common-auth pam_tally case.

[ Risks ]

Both changes are easy to review.
The postinst change also only affects the sysvinit code path which is a 
non-default code path.  The systemd code path is the same as 1.4.0-6

[ 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 ]
(Anything else the release team should know.)

unblock pam/1.4.0-7

diff --git a/debian/changelog b/debian/changelog
index 9c894a4f..03358422 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,34 @@
+pam (1.4.0-7) unstable; urgency=medium
+
+  * Updated portuguese debconf translation, thanks Pedro Ribeiro, Closes:
+#983594
+  * Updated Simplified Chinese Translations, thanks Boyuan Yang
+  * Updated Bulgarian Translation, Thanks Damyan Ivanov
+  * Updated translation from the Slovak team, thanks Ladislav Michnovič,
+Closes: #984891
+  * Updated Catalan translation, thanks Alex Muntada, Closes: #984568
+  * Updated Brazilian Portuguese translation, Thanks  Adriano Rafael Gomes,
+Closes: #984656
+  * French Debconf translations, thanks  Jean-Pierre Giraud, Closes:
+#984910
+  * Updated russian Debconf translations, thanks Алексей Шилин, Closes:
+#984878
+  * Updated Dutch debconf templates, Thanks Frans Spiesschaert, Closes:
+#984823
+  * Updated German Debconf translations, Thanks Sven Joachim
+  * Code review fixes for the fix to #982295, thanks Mark Hindley
+- Actually set service to $1 rather than happening to use a variable
+  of the same name in enclosing scope
+- Remove dead code setting idl when not used
+  * Code review fixes to the fix for #982530, thanks Martin Schurz
+- Include '-' in the file matching regexp so we search
+/etc/pam.d/common-* for uses of pam_tally.  The profile check will
+  catch this unless the user has overwridden the configuration
+- Fix capitalization of pam_Tally in debconf description
+
+
+ -- Sam Hartman   Mon, 15 Mar 2021 15:01:55 -0400
+
 pam (1.4.0-6) unstable; urgency=medium
 
   * Clearly it's been too long since I've done debconf; run
diff --git a/debian/libpam-modules.preinst b/debian/libpam-modules.preinst
index cbc66932..fe0d6eb9 100644
--- a/debian/libpam-modules.preinst
+++ b/debian/libpam-modules.preinst
@@ -43,7 +43,7 @@ if dpkg --compare-versions "$2" lt-nl 1.4.0-5; then
 # recommend a replacement
 # /dev/null reference is to make sure we don't grep stdin if
 # somehow ls returns empty
-if grep -qe '^[^#]*pam_tally' $(ls -1d /etc/pam.d/* | grep -e 
'^/etc/pam.d/[0-9a-zA-Z/]*$' ) /dev/null ; then
+if grep -qe '^[^#]*pam_tally' $(ls -1d /etc/pam.d/* | grep -e 
'^/etc/pam.d/[0-9a-zA-Z/-]*$' ) /dev/null ; then
 db_input critical libpam-modules/deprecate-tally ||true
 db_go ||true
 exit 2
diff --git a/debian/libpam-modules.templates b/debian/libpam-modules.templates
index fcc9e2d6..83f5d6e5 100644
--- a/debian/libpam-modules.templates
+++ b/debian/libpam-modules.templates
@@ -18,7 +18,7 @@ _Description: PAM Profiles with Deprecated Modules Disabled
 
 Template: libpam-modules/deprecate-tally
 Type: error
-_Description: you are using pam_Tally or pam_tally2 in your configuration
+_Description: 

Bug#959735: Ship a default range for systemd-sysusers which follows adduser defaults

[Michael Biebl]

Hi Moritz

On Mon, 04 May 2020 19:53:26 +0200 Moritz Muehlenhoff 
wrote:
> Package: systemd
> Severity: wishlist
> 
> The default config in adduser configures
> 
> FIRST_SYSTEM_UID=100
> LAST_SYSTEM_UID=999
> FIRST_SYSTEM_GID=100
> LAST_SYSTEM_GID=999
> 
> I'm wondering if systemd by default should ship
> 
> r -    100-999
> 
> somewhere in /usr/lib/sysusers.d to mimic that default as well. (The
upper
> bound is already implicitly defined as a compile-time default by
means
> of passing -DSystemd-[ug]id-max=999 in debian/rules)


So, the current builtin defaults are

['system-alloc-uid-min', 'SYS_UID_MIN', 1],   
['system-uid-max',   'SYS_UID_MAX', 999],
['system-alloc-gid-min', 'SYS_GID_MIN', 1],
['system-gid-max',   'SYS_GID_MAX', 999]]

They can be set via:

option('system-alloc-uid-min', type : 'integer', value : '-1',
   description : 'minimum system UID used when allocating')
option('system-alloc-gid-min', type : 'integer', value : '-1',
   description : 'minimum system GID used when allocating')
option('system-uid-max', type : 'integer', value : '-1',
   description : 'maximum system UID')
option('system-gid-max', type : 'integer', value : '-1',
   description : 'maximum system GID')

The upper bound is already 999, so wouldn't need to be changed.
The lower bound could be changed via 

-Dsystem-alloc-uid-min=100
-Dsystem-allow-gid-min=100

to match the debian/adduser default.

systemd-sysusers would still behave slightly different to adduser
though.
It starts with 999 and works its way down.

This is kinda nice in some way, as you can more easily distinguish
statically allocated system groups/users (via base-passwd) from
dynamically alloced system groups/users.

I.e. I probably wouldn't change that aspect of systemd-sysusers, as I
kinda like it.

Regards,
Michael


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

Bug#985360: zfs-linux: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: zfs-linux 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of zfs-linux debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#950514: Rename bug to "Please update sources"

[Felix Lechner]

Control: retitle -1 ding-libs: Please cherry-pick be9ca3a2 from upstream

Hi,

As described here [1] and also earlier in this bug, the version
0.6.1-2 in unstable spams logs with bogus messages from gssproxy.
Please cherry-pick commit be9ca3a2 (or package master) for the reasons
mentioned in the link. Thanks!

Kind regards
Felix Lechner

[1] https://github.com/gssapi/gssproxy/issues/31

Bug#984707: systemd-networkd: DHCP-assigned IPv6 address lost after router restart, backport of bd7d6cec

[Tiziano Müller]

Hi Michael,

thank you very much for the reminder, I will try to build the package 
with the patch as fast as I can and see whether I can verify that it 
fixes the issue.


Best regards,
Tiziano

On 3/16/21 4:34 PM, Michael Biebl wrote:

Hello Tiziano,

the next stable point release 10.9 will be Saturday
March 27th. Processing of new uploads into buster-proposed-updates will
be frozen during the preceding weekend.

Since I lack the setup to verify the fix, I have to rely on you.
If you want to see this fixed in stable, it would be great to have a 
confirmation really soon, that this commit really fixes the issue you 
are seeing.


Regards,
Michael

Am 08.03.21 um 16:36 schrieb Michael Biebl:

Control: fixed -1 243-1
Control: user pkg-systemd-maintain...@lists.alioth.debian.org
Control: usertag -1 + buster-backport

Hello Tiziano

Am 07.03.21 um 15:12 schrieb Tiziano Müller:


my NAS running Armbian Buster is losing its DHCPv6 assigned IPv6 address
upon restart of the router. A restart of the NAS is required to fix it.
I believe this to be the upstream issue 
https://github.com/systemd/systemd/issues/2365

which was fixed in systemd v243+. Since installation of the systemd
package from backports would break OpenMediaVault, I would like to ask
whether it is possible to backport the necessary fix to stable instead:
https://github.com/systemd/systemd/commit/bd7d6cec331a00fed29d00c2498f04e83d70b19c 



The context of the patch changed slightly, so it won't apply cleanly out
of the box. I can provide the adapted patch if that helps.


Would be great to have a tested patch, i.e. a confirmation that the 
issue is actually fixed by bd7d6cec331a00fed29d00c2498f04e83d70b19c


The change itself looks small enough, so should be suitable for an 
inclusion in a stable update (user tagging accordingly).


Regards,
Michael

Bug#985346: RFS: nspark/1.7.8B2+git+20190713-3 [ITP] -- Decompressor for SparkFS and ArcFS archive files

[Dave Lambley]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: nspark
   Version : nspark/1.7.8B2+git+20190713-3
   Upstream Author : James Woodcock 
 * URL : https://github.com/mjwoodcock/nspark
 * License : custom, see debian/copyright
 * Vcs : https://repo.or.cz/debian-nspark.git
   Section : non-free/utils

It builds those binary packages:

  nspark - Decompressor for SparkFS and ArcFS archives, originating from
   RISC OS.

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/non-free/n/nspark/nspark_1.7.8B2+git+20190713-2.dsc

Changes since the last upload:

 nspark (1.7.8B2+git+20190713-2) unstable; urgency=medium
 .
   * Tidy copyright.

Best regards,
-- 
Dave Lambley

Bug#985317: libgegl

[Ivan Sergio Borgonovo]

Culprit seems to be

[UPGRADE] libgegl-0.4-0:amd64 1:0.4.26-2 -> 1:0.4.28-1
[UPGRADE] libgegl-common:amd64 1:0.4.26-2 -> 1:0.4.28-1

Same problem with 1:0.4.28-2

this seems to be related

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971812

BTW I'm running a mix of testing/unstable and libc6 is at 2.31-9

downgrading fixed the problem.

thanks

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

Bug#985270: Resignation + Call for votes for new Chair

[Christoph Berg]

Re: To 985...@bugs.debian.org
>   A > B = C = D = E = F = G > H

I vote

  A = F > B = C = D = E = G > H

Christoph


signature.asc
Description: PGP signature

Bug#984707: systemd-networkd: DHCP-assigned IPv6 address lost after router restart, backport of bd7d6cec

[Michael Biebl]

Hello Tiziano,

the next stable point release 10.9 will be Saturday
March 27th. Processing of new uploads into buster-proposed-updates will
be frozen during the preceding weekend.

Since I lack the setup to verify the fix, I have to rely on you.
If you want to see this fixed in stable, it would be great to have a 
confirmation really soon, that this commit really fixes the issue you 
are seeing.


Regards,
Michael

Am 08.03.21 um 16:36 schrieb Michael Biebl:

Control: fixed -1 243-1
Control: user pkg-systemd-maintain...@lists.alioth.debian.org
Control: usertag -1 + buster-backport

Hello Tiziano

Am 07.03.21 um 15:12 schrieb Tiziano Müller:


my NAS running Armbian Buster is losing its DHCPv6 assigned IPv6 address
upon restart of the router. A restart of the NAS is required to fix it.
I believe this to be the upstream issue 
https://github.com/systemd/systemd/issues/2365

which was fixed in systemd v243+. Since installation of the systemd
package from backports would break OpenMediaVault, I would like to ask
whether it is possible to backport the necessary fix to stable instead:
https://github.com/systemd/systemd/commit/bd7d6cec331a00fed29d00c2498f04e83d70b19c 



The context of the patch changed slightly, so it won't apply cleanly out
of the box. I can provide the adapted patch if that helps.


Would be great to have a tested patch, i.e. a confirmation that the 
issue is actually fixed by bd7d6cec331a00fed29d00c2498f04e83d70b19c


The change itself looks small enough, so should be suitable for an 
inclusion in a stable update (user tagging accordingly).


Regards,
Michael






OpenPGP_signature
Description: OpenPGP digital signature

Bug#985339: nauty: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andrius Merkys]

Hello,

On 2021-03-16 12:39, Andreas Beckmann wrote:
> 1m40.0s ERROR: FAIL: silently overwrites files via directory symlinks:
>   /usr/share/doc/nauty/changelog.Debian.gz (nauty) != 
> /usr/share/doc/libnauty2/changelog.Debian.gz (libnauty2:amd64)
> /usr/share/doc/nauty -> /usr/share/doc/libnauty2
>   /usr/share/doc/nauty/changelog.gz (nauty) != 
> /usr/share/doc/libnauty2/changelog.gz (libnauty2:amd64)
> /usr/share/doc/nauty -> /usr/share/doc/libnauty2
>   /usr/share/doc/nauty/changes24-27.txt.gz (nauty) != 
> /usr/share/doc/libnauty2/changes24-27.txt.gz (libnauty2:amd64)
> /usr/share/doc/nauty -> /usr/share/doc/libnauty2
>   /usr/share/doc/nauty/copyright (nauty) != 
> /usr/share/doc/libnauty2/copyright (libnauty2:amd64)
> /usr/share/doc/nauty -> /usr/share/doc/libnauty2

I am trying to debug the issue, however, unsuccessfully. From the
attached log I gather that the break happens upon upgrading from buster
(2.6r10+ds-1) to bullseye (2.7r1+ds-1):

1m38.6s DUMP:
  PIUPARTS_DISTRIBUTION_PREV=buster
  PIUPARTS_DISTRIBUTION=bullseye

Affected binary packages are nauty and libnauty. The former has recently
(in 2.7r1+ds-1) switched from shipping a directory symlink to a real
directory, and this is accommodated in debian/nauty.maintscript:

symlink_to_dir /usr/share/doc/nauty libnauty2 2.7r1+ds-1~

>From this I gather that upgrades of nauty <= 2.7r1+ds-1 to this new
version should trigger the replacement of a symlink with real directory
before placing the files inside. Or am I wrong?

Best,
Andrius

Bug#985116: libgrokj2k: FTBFS on i386

[Aaron Boxer]

s/Ivor/Ivo/ :)

On Tue, Mar 16, 2021 at 11:04 AM Aaron Boxer  wrote:

> Thanks, Ivor. How would you recommend I test on i386?
>
> On Fri, Mar 12, 2021 at 6:33 PM Ivo De Decker  wrote:
>
>> package: src:libgrokj2k
>> version: 7.6.6-2
>> severity: serious
>> tags: ftbfs
>>
>> Hi,
>>
>> The latest upload of libgrokj2k to unstable fails on i386:
>>
>> https://buildd.debian.org/status/package.php?p=libgrokj2k
>>
>> Cheers,
>>
>> Ivo
>>
>

Bug#985116: libgrokj2k: FTBFS on i386

[Aaron Boxer]

Thanks, Ivor. How would you recommend I test on i386?

On Fri, Mar 12, 2021 at 6:33 PM Ivo De Decker  wrote:

> package: src:libgrokj2k
> version: 7.6.6-2
> severity: serious
> tags: ftbfs
>
> Hi,
>
> The latest upload of libgrokj2k to unstable fails on i386:
>
> https://buildd.debian.org/status/package.php?p=libgrokj2k
>
> Cheers,
>
> Ivo
>

Bug#985352: libuim-data: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Followup-For: Bug #985352
Control: tag -1 patch pending

buster-pu request including patch: https://bugs.debian.org/985359

Andreas

Bug#985358: pitivi: A/V out of sync in rendered videos

[Sebastian Dröge]

On Tue, 2021-03-16 at 11:16 -0300, Antonio Terceiro wrote:

Dear Maintainer,

The version of pitivi in bullseye is affected by the bug listed above:
rendered videos have A/V out of sync by a few seconds, while they sound
just find in the preview.

I'm attaching the upstream patch that fixed the issue, already
backported to the current Debian package. I rebuilt pitivi locally with
this patch, and confirmed that it does fix the issue.

Yeah I'm aware of this and various other issues in the version
currently in Debian, and which are fixed in the latest releases.

Due to Debian release freeze policies the latest release is not
uploaded yet and I don't know how useful it is to just patch some of
the issues.

In the end what we'd really want is the latest release.


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