date:20210415

Control: retitle -1 IPAccounting=yes does not work for systemd-run --user

A real inconvenience of 986905 is that IPAccounting does not work for
any process under systemd --user by non-root. For example,

ryutaroh@raspi4b8gb:~$ systemd-run --user --scope --unit=test -p 
"IPAccounting=yes" sh -c 'wget -O /dev/null http://www.debian.org/ ; sleep 100; 
exit 0' &
[1] 1821
Running scope as unit: test.scope
ryutaroh@raspi4b8gb:~$ systemctl --user status test.scope
● test.scope - /bin/sh -c wget -O /dev/null http://www.debian.org/ ; sleep 100; 
exit 0
 Loaded: loaded (/run/user/1000/systemd/transient/test.scope; transient)
  Transient: yes
 Active: active (running) since Fri 2021-04-16 13:00:05 JST; 21s ago
 IP: 0B in, 0B out
 IO: 696.0K read, 0B written
  Tasks: 2 (limit: 9028)
 Memory: 1.2M
CPU: 123ms
 CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/test.scope
 ├─1821 /bin/sh -c wget -O /dev/null http://www.debian.org/ ; sleep 
100; exit 0
 └─1831 sleep 100

IP Accounting information is clearly incorrect above.
Is it expected to work???

Best regards, Ryutaroh

Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed

Control: retitle -1 systemd user instance: Attaching egress BPF program to 
cgroup failed with Invalid argument

> Currently, to trigger this issue, I need task-xfce-desktop (on every arch.).
> I believe that this can be reproduced without task-xfce-desktop,
> and will try to find a reproduction procedure with CUI in a weekend...

A minimal reproduction procedure of 986905 is as follows:
1. Install dbus-user-session, pulseaudio and libpam-systemd.
2. Add "DefaultIPAccounting=yes" to /etc/systemd/user.conf (reload systemd if 
necessary)
3. Login as a non-root user of UID >= 1000.
4. journalctl -b -g BPF as root.

Best regards, Ryutaroh

Bug#987037: ITP: vim-toml -- Vim support for TOML language

2021-04-15 Thread Marco Villegas

Package: wnpp
Severity: wishlist
Owner: Marco Villegas 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: vim-toml
  Version: 3c5face8e8944a217af45bc5bb708ff7dfcf1a54
  Upstream Author: Caleb Spare 
* URL : https://github.com/cespare/vim-toml
* License: Expat
  Programming Lang: Vim scripting
  Description: Vim support for TOML language

Adds syntax support for Tom's Obvious Minimal Language, TOML, on Vim.

Initial codebase available at https://salsa.debian.org/vim-team/vim-toml

-Marco


pgpZD3YlNN7k6.pgp
Description: Firma digital OpenPGP

Bug#987036: libdebuginfod-common: package description should discuss the Debian debug info server

2021-04-15 Thread Paul Wise

Package: libdebuginfod-common
Version: 0.183-7
Severity: normal

The libdebuginfod-common package is just a copy of the libdebuginfo1
package with "common files" tacked on:

   Description: library to interact with debuginfod (common files)
The libdebuginfo1 package provides a library with an interface to interact
with debuginfod.
.
This package contains the common files for libdebuginfod.

I would suggest something like this instead:

   Description: optionally enable use of the Debian debug info server
This package asks if it should enable use of the Debian debug info
server with debugging tools that use libdebuginfo such as GDB.
.
When this is allowed by the sysadmin, a snippet will be added to the
shell configuration. You will need to restart your shell after
installing this package before the snippet will work.
.
The Debian debug info server will be contacted every time debugging
tools attempt to look up debug info for binaries or libraries but the
server does not log requests for debug info.
.
The Debian debug info server uses https to securely transfer debugging
files but does not offer OpenPGP signing of debug info.

I also wonder if it is perhaps incorrectly named and should be named
something like libdebuginfod-server-debian. It could also be renamed to
libdebuginfod-servers and include other servers like the Fedora one, in
case Debian users are doing remote debugging of non-Debian systems.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#987035: bash: checkwinsize does not need to be enabled in /etc/skel/.bashrc because it is enabled by default

2021-04-15 Thread John Karahalis

Package: bash
Version: 5.0-6ubuntu2
Severity: minor
Tags: patch

I do not believe checkwinsize needs to be manually enabled in /etc/skel/.bashrc
because it is enabled by default, at least in the latest version of bash.



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

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

Versions of packages bash depends on:
ii  base-files   11ubuntu14
ii  debianutils  4.11.2
ii  libc62.32-0ubuntu3
ii  libtinfo66.2-1

Versions of packages bash recommends:
ii  bash-completion  1:2.11-2ubuntu1

Versions of packages bash suggests:
pn  bash-doc  
--- /etc/skel/.bashrc   2020-02-25 07:03:22.0 -0500
+++ /etc/skel/.bashrc.modified  2021-04-15 21:30:42.684118890 -0400
@@ -19,10 +19,6 @@
 HISTSIZE=1000
 HISTFILESIZE=2000
 
-# check the window size after each command and, if necessary,
-# update the values of LINES and COLUMNS.
-shopt -s checkwinsize
-
 # If set, the pattern "**" used in a pathname expansion context will
 # match all files and zero or more directories and subdirectories.
 #shopt -s globstar

Bug#986964: geeqie: View in new window, new window black until zoom in/out

2021-04-15 Thread Andreas Ronnquist

On Wed, 14 Apr 2021 09:47:07 -0700
Dean Hamstead  wrote:

>Package: geeqie
>Version: 1:1.6-8
>Severity: normal
>
>Dear Maintainer,
>
>When an image is opened in a new window, the new window content are
>black. Zooming in or out the image appears.
>
>Not certain how to debug.
>

Thanks for your report.

Are you on wayland? (You can find out by running

echo $XDG_SESSION_TYPE

in a terminal).

Also, I see something similar if I run without "GPU acceleration via
Clutter library" - see preferences under "Image", "Use GPU acceleration
via Clutter library" - is that checked for you?

If I select to run without clutter, I see something similar to what you
see.

(I will forward this to upstream, but this could possibly be at least a
temporary workaround).

/Andreas Rönnquist
gus...@debian.org

Bug#545142: coreutils: ls -v sorts foo.z before foo.x-y

2021-04-15 Thread Bill Zaumen

I ran into a similar issue with coreutils 8.32-3ubuntu1 amd64:
In a directory containing test cases, I typed

ls test4*.esp | cat | sort

and got the following:

test4a.esp
test4b.esp
test4c.esp
test4d.esp
test4e.esp
test4.esp
test4f.esp
test4g1.esp
test4g2.esp
test4g.esp
test4gL.esp
test4h.esp
test4i.esp
test4j.esp
test4k.esp

Note that test4e.esp appears before test4.esp, which appears before
test4h.esp, and no reasonable lexical ordering would do that.

ls test4*.esp | cat | sort -d

behaves the same way as does

ls test4*.esp | cat

so the issue is most likely in a sort function used by both ls and
sort.  I'm submitting this to add what I hope will be a useful test
case.



On Sat, 5 Sep 2009 12:05:07 +0200 Piotr Engelking  wrote:
> Package: coreutils
> Version: 7.4-2
> Severity: normal
> 
> 'ls -v' sorts some names in a weird order:
> 
> $ cd $(mktemp -d)
> $ touch foo.{x,x-y,z}
> $ ls -1
> foo.x
> foo.x-y
> foo.z
> $ ls -v1
> foo.x
> foo.z
> foo.x-y
> $ locale | grep ^LC_COLLATE
> LC_COLLATE="POSIX"
> $
> 
> If I understand the documentation correctly, ls should sort names not
> containing numerical components in the same order with and without the '-v'
> option, which isn't the case.
> 
> The bug is also present in coreutils 7.5-1.
> 
> 
> -- System Information:
> Debian Release: squeeze/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (400, 'unstable'), (300, 'experimental')
> Architecture: i386 (x86_64)
> 
> Kernel: Linux 2.6.30 (SMP w/2 CPU cores)
> Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages coreutils depends on:
> ii  libacl1   2.2.48-1   Access control list shared 
> library
> ii  libattr1  1:2.4.44-1 Extended attribute shared library
> ii  libc6 2.9-25 GNU C Library: Shared libraries
> ii  libselinux1   2.0.85-2   SELinux shared libraries
> 
> coreutils recommends no packages.
> 
> coreutils suggests no packages.
> 
> -- no debconf information
> 
> 
>

Bug#987034: display github page in Homepage tag

2021-04-15 Thread Brian Sammon

Package: atomicparsley
Version: 0.9.6-2

I'm basing this bug report primarily on the information seen at
https://packages.debian.org/sid/atomicparsley

That debian page says the homepage for atomicparsley is at 
http://atomicparsley.sourceforge.net/
but it would be better to point at 
https://github.com/wez/atomicparsley/releases, I think, especially considering 
that that is where you get the upstream for the dpkg.
Best would be to point at both pages, but if you can only point at one, I think 
the github would be better.

Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed,Re: Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed

> So you enabled "DefaultIPAccounting=yes" for the systemd --user
> instances (i.e. in user.conf) and only those systemd --user instances
> trigger that error?

Yes (on amd64, arm64 and armhf).

I do not see the error in the systemd PID 1
except on an armhf kernel with CONFIG_BPF_JIT_ALWAYS_ON=y.
But we do not need to consider the issue on the armhf kernel here.

> If you remove "DefaultIPAccounting=yes" from user.conf, are the error
> messages gone?

Yes.

This seems something like "Permission denied" or "Operation not permitted",
but the error is "Invalid argument", which seems strange.

Currently, to trigger this issue, I need task-xfce-desktop (on every arch.).
I believe that this can be reproduced without task-xfce-desktop,
and will try to find a reproduction procedure with CUI in a weekend...

Best regards, Ryutaroh

Bug#987033: dmidecode --dump/-u produces Segmentation fault

2021-04-15 Thread Blade Coates

Package: dmidecode
Version: 3.3-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: bl...@coates.life

Dear Maintainer,

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

   * What led up to the situation?

Trying to dump dmidecode information via the -u/--dump switch into a bin file.
Running dmidecode -t 1 -u produces a segmentation fault

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

Segmentation fault.

   * What outcome did you expect instead?

The ability to pipe the output to a file for use later. Segmentation fault
causes the command to exit before the output redirect is performed.

This appears to be fixed in commit 11e134e54d15e67a64c39a623f492a28df922517
upstream.

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


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

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

Versions of packages dmidecode depends on:
ii  libc6  2.31-11

dmidecode recommends no packages.

dmidecode suggests no packages.

Bug#987025: dangling symlink /usr/share/doc/python3.9/python-policy.html

Package: python3
Version: 3.9.2-1

Hi.  This package create a dangling symlink:
/usr/share/doc/python3.9/python-policy.html

Maybe the python-policy.html symlink could be removed?  It is probably
sufficient to have the document in one format.

/Simon

root@kalv:~# ls -la /usr/share/doc/python3.9/python-policy.html 
lrwxrwxrwx 1 root root 29 Mar  2 19:55 
/usr/share/doc/python3.9/python-policy.html -> ../python3/python-policy.html
root@kalv:~# dpkg -S /usr/share/doc/python3.9/python-policy.html 
python3: /usr/share/doc/python3.9/python-policy.html
root@kalv:~# ls -la /usr/share/doc/python3/
total 72
drwxr-xr-x   2 root root  4096 Apr 15 19:57 .
drwxr-xr-x 395 root root 20480 Apr 15 20:04 ..
-rw-r--r--   1 root root 15138 Mar  2 19:55 changelog.Debian.gz
-rw-r--r--   1 root root 16122 Mar  2 19:55 copyright
-rw-r--r--   1 root root 11687 Mar  2 19:55 python-policy.txt.gz
-rw-r--r--   1 root root   462 Mar  2 19:55 README.Debian
root@kalv:~# 


signature.asc
Description: PGP signature

Bug#986997: O: netkit-telnet -- basic telnet client

Chris Hofstaedtler  writes:

> * Simon Josefsson  [210415 19:06]:
>> Hi!  Upstream is not maintained either -- at least the download URL in
>> netkit-telnet's debian/copyright file does not work.  How about dropping
>> netkit-telnet from Debian?
>
> In #982253 I've expressed that I for one would find that to be a
> good idea. But quite clearly it is work that needs to be a) done and
> b) well coordinated.

I'm happy to work on replacing netkit-based tools with inetutils once
bullseye is out, although Guillem have to agree since he maintains
inetutils in Debian.  If something needs to be modified in inetutils to
be more compatible with netkit, I will help to arrange that.  Starting
with telnet+telnetd seems like a good idea.  As far as I can tell,
telnet is not installed by default on buster nor bullseye which is good.

Btw, the suggestion to symlink telnet to netcat is not a good one:
telnet is a complex protocol, netcat doesn't support any of it as far as
I know.

/Simon

signature.asc
Description: PGP signature

Bug#986742: unblock: ruby2.7/2.7.3-1

2021-04-15 Thread Antonio Terceiro

On Sun, 11 Apr 2021 03:04:42 +0530 Utkarsh Gupta  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: debian-r...@lists.debian.org
> 
> Hello,
> 
> Upstream has recently released a bug-fix only release after a
> vulnerability, CVE-2021-28965, was discovered.
> 
> Upstream release note:
> https://www.ruby-lang.org/en/news/2021/04/05/ruby-2-7-3-released/
> Upstream git logs b/w 2.7.2 and 2.7.3:
> https://github.com/ruby/ruby/compare/v2_7_2...v2_7_3
> 
> This is clearly a bug-fix only release and it'd be *really great* to
> have this included in Bullseye. (I'd be sad not to but..) I understand
> it's your call to make after analyzing so attaching the debdiff for
> your reference and help (snipping ChangeLog entries for noise
> reduction).
> 
> Hopefully, it'd be OK to get this included and have an even nicer
> ruby2.7 for Bullseye. Thanks.

 99 files changed, 39552 insertions(+), 23134 deletions(-)

The debian diff looks very big because of 3 generated files: ChangeLog,
parse.c, and ext/ripper/ripper.c (the last two being bison/yacc
generated parsers). If you filter those out, the result is a lot more
palatable:

 96 files changed, 3761 insertions(+), 886 deletions(-)

Roughtly 1/3 of the insertions are test cases:

 32 files changed, 1150 insertions(+), 97 deletions(-)

I have reviewed the upstream patches and compared the upstream diff with
the debian diff, and indeed all the changes are bug fixes.

There was one marked as a "Feature" in the commit message, but it was
really a follwup to fix an inconsistency in a feature that has been
added in the 2.7 series already. It will cause formerly invalid syntax
to be valid, but won't break any currently working code.

I think the risk with this update is low, and releasing with the latest
available ruby bugfix release will make it easier to provide stable
support in bullseye.

Full disclosure: I am trying to get ruby into new hands, but I'm still a
comaintainer and care a lot about it, so I'm not an uninterested party
here.

signature.asc
Description: PGP signature

Bug#986929: unblock/tpu: nheko/0.7.2-3+deb11u1

2021-04-15 Thread Hubert Chathi

Andreas, thank you for preparing the patch.

As mentioned in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986519#47 I have an
alternative patch that removes the code that caused the ICE by removing
the dependency on tweeny.  This patch comes from upstream and is part of
their latest release.  This change is quite a bit bigger than Andreas'
patch, but I hope that it is considered "minimal" enough to be applied.
If not, then I have no objections to Andreas' patch being used instead.

Again, this needs to go through tpu since sid has a newer version (which
was blocked from migrating to testing when it was uploaded due to the
ICE).

Alternatively, I could upload the latest upstream version of nheko to
sid, which as I mentioned removes the code that causes the ICE.  But I
suppose that would be asking for too much. ;)

Thanks

commit a3100e993bc526e365d3f6fab3d07b159ed5b6a6
Author: Hubert Chathi 
Date:   Thu Apr 15 17:45:24 2021 -0400

apply upstream patch to not use tweeny

diff --git a/debian/changelog b/debian/changelog
index 3530c57f..b46c707c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+nheko (0.7.2-3+deb11u1) bullseye; urgency=medium
+
+  * debian/control, patches/no_tweeny:
+* Don't use tweeny, to avoid a compiler error in gcc-10. (Closes: #986519)
+
+ -- Hubert Chathi   Thu, 15 Apr 2021 17:10:18 -0400
+
 nheko (0.7.2-3) unstable; urgency=medium
 
   * debian/control:
diff --git a/debian/control b/debian/control
index 0121dc83..ad7f9d47 100644
--- a/debian/control
+++ b/debian/control
@@ -22,7 +22,6 @@ Build-Depends: cmake (>= 3.15)
  , libspdlog-dev (>= 1.5.0+ds-4)
  , libsodium-dev
  , libssl-dev
- , libtweeny-dev
  , nlohmann-json3-dev (>= 3.7.0-2~)
  , qtbase5-dev (>= 5.10)
  , qtdeclarative5-dev
diff --git a/debian/patches/no_find_tweeny b/debian/patches/no_find_tweeny
deleted file mode 100644
index ac7f8cdc..
--- a/debian/patches/no_find_tweeny
+++ /dev/null
@@ -1,18 +0,0 @@
-Description: Don't use cmake to find tweeny
- Hardcode the path to tweeny.
-Author: Hubert Chathi 
-
-Last-Update: 2020-04-22
-
 nheko-0.7.0.orig/CMakeLists.txt
-+++ nheko-0.7.0/CMakeLists.txt
-@@ -418,7 +418,8 @@ if(USE_BUNDLED_TWEENY)
- 		)
- 	FetchContent_MakeAvailable(Tweeny)
- else()
--	find_package(Tweeny REQUIRED)
-+	add_library(tweeny INTERFACE)
-+	target_include_directories(tweeny INTERFACE /usr/include/tweeny)
- endif()
- 
- # single instance functionality
diff --git a/debian/patches/no_tweeny b/debian/patches/no_tweeny
new file mode 100644
index ..004c5b97
--- /dev/null
+++ b/debian/patches/no_tweeny
@@ -0,0 +1,167 @@
+Description: Remove tweeny
+Author: Nicolas Werner 
+
+---
+Origin: upstream
+Bug-Debian: https://bugs.debian.org/986519
+Forwarded: not-needed
+Last-Update: 2021-04-15
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 1a4c4b70..42a2b387 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -39,8 +39,6 @@ option(USE_BUNDLED_LMDB "Use the bundled version of lmdb."
+ 	${HUNTER_ENABLED})
+ option(USE_BUNDLED_LMDBXX "Use the bundled version of lmdb++."
+ 	${HUNTER_ENABLED})
+-option(USE_BUNDLED_TWEENY "Use the bundled version of tweeny."
+-	${HUNTER_ENABLED})
+ 
+ list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake")
+ 
+@@ -446,18 +444,6 @@ else()
+ 	add_library(lmdbxx::lmdbxx ALIAS lmdbxx)
+ endif()
+ 
+-if(USE_BUNDLED_TWEENY)
+-	include(FetchContent)
+-	FetchContent_Declare(
+-		Tweeny
+-		GIT_REPOSITORY https://github.com/mobius3/tweeny.git
+-		GIT_TAG6a5033372fe53c4c731c66c8a2d56261746cd85c #v3 <- v3 has unfixed warnings
+-		)
+-	FetchContent_MakeAvailable(Tweeny)
+-else()
+-	find_package(Tweeny REQUIRED)
+-endif()
+-
+ # single instance functionality
+ set(QAPPLICATION_CLASS QApplication CACHE STRING "Inheritance class for SingleApplication")
+ add_subdirectory(third_party/SingleApplication-3.1.3.1/)
+@@ -643,7 +629,6 @@ target_link_libraries(nheko PRIVATE
+ 	nlohmann_json::nlohmann_json
+ 	lmdbxx::lmdbxx
+ 	liblmdb::lmdb
+-	tweeny
+ 	SingleApplication::SingleApplication)
+ 
+ if(${CMAKE_VERSION} VERSION_GREATER_EQUAL "3.16.0")
+diff --git a/src/ui/SnackBar.cpp b/src/ui/SnackBar.cpp
+index 03609802..2453369d 100644
+--- a/src/ui/SnackBar.cpp
 b/src/ui/SnackBar.cpp
+@@ -1,7 +1,5 @@
+ #include 
+ 
+-#include 
+-
+ #include "SnackBar.h"
+ 
+ constexpr int STARTING_OFFSET = 1;
+@@ -16,6 +14,7 @@ constexpr double MIN_WIDTH_PERCENTAGE = 0.3;
+ 
+ SnackBar::SnackBar(QWidget *parent)
+   : OverlayWidget(parent)
++  , offset_anim(this, "offset", this)
+ {
+ QFont font;
+ font.setPointSizeF(font.pointSizeF() * 1.2);
+@@ -28,17 +27,16 @@ SnackBar::SnackBar(QWidget *parent)
+ 
+ hideTimer_.setSingleShot(true);
+ 
+-auto offset_anim = tweeny::from(1.0f).to(0.0f).during(100).via(tweeny::easing::cubicOut);
+-connect(_, ::timeout, this, [this, offset_anim]() mutable {
+-if (offset_anim.progress() < 1.0f) {
+-offset_ = offset_anim.step(0.07f);
++

Bug#986523: odb: FTBFS: i386.h:2500:10: fatal error: common/config/i386/i386-cpuinfo.h: No such file or directory

2021-04-15 Thread GCS

On Wed, Apr 14, 2021 at 9:18 PM Andreas Beckmann  wrote:
> On Wed, 7 Apr 2021 08:32:20 +0200 Lucas Nussbaum  wrote:
> > > /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386.h:2500:10:
> > >  fatal error: common/config/i386/i386-cpuinfo.h: No such file or directory
>
> This is fixed in gcc-10 10.3 in experimental, according to doko the
> workaround is to build with g++-9 for bullseye. (#986519)
 Meaning GCC 10 is still broken on amd64, its gcc-10-plugin-dev has a
regression for Bullseye over GCC 9.
But OK, not my business. Will build odb with GCC 9.

Regards,
Laszlo/GCS

Bug#977410: rmlint: diff for NMU version 2.9.0-2.3

2021-04-15 Thread Timo Röhling


Control: tags 977410 + patch
Control: tags 977410 + pending

Dear maintainer,

I've prepared an NMU for rmlint (versioned as 2.9.0-2.3). The diff
is attached to this message.

I require a sponsor to have it uploaded.

Regards.


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff -Nru rmlint-2.9.0/debian/changelog rmlint-2.9.0/debian/changelog
--- rmlint-2.9.0/debian/changelog	2020-12-01 21:37:43.0 +0100
+++ rmlint-2.9.0/debian/changelog	2021-04-15 23:03:37.0 +0200
@@ -1,3 +1,11 @@
+rmlint (2.9.0-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix data loss caused by faulty check in generated scripts (Closes: #977410)
+- Use upstream patch
+
+ -- Timo Röhling   Thu, 15 Apr 2021 23:03:37 +0200
+
 rmlint (2.9.0-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rmlint-2.9.0/debian/patches/0010-apply-upstream-fix-for-data-loss-bug.patch rmlint-2.9.0/debian/patches/0010-apply-upstream-fix-for-data-loss-bug.patch
--- rmlint-2.9.0/debian/patches/0010-apply-upstream-fix-for-data-loss-bug.patch	1970-01-01 01:00:00.0 +0100
+++ rmlint-2.9.0/debian/patches/0010-apply-upstream-fix-for-data-loss-bug.patch	2021-04-15 23:03:37.0 +0200
@@ -0,0 +1,31 @@
+From: =?utf-8?q?Timo_R=C3=B6hling?= 
+Date: Fri, 19 Mar 2021 16:37:27 +0100
+Subject: apply upstream fix for data loss bug
+
+This is upstream commit b9d328be2041e42813119d060c86893853b8e250 that
+also includes a cosmetic fix (which I reused unchanged)
+---
+ lib/formats/sh.sh | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/lib/formats/sh.sh b/lib/formats/sh.sh
+index 966f659..6db8d3b 100644
+--- a/lib/formats/sh.sh
 b/lib/formats/sh.sh
+@@ -150,7 +150,7 @@ original_check() {
+ 
+ # Check they are not the exact same file (hardlinks allowed):
+ if [ "$1" = "$2" ]; then
+-echo "${COL_RED}^^ Error: original and duplicate point to the *same* path - cancelling.{COL_RESET}"
++echo "${COL_RED}^^ Error: original and duplicate point to the *same* path - cancelling.${COL_RESET}"
+ return 1
+ fi
+ 
+@@ -160,6 +160,7 @@ original_check() {
+ else
+ if [ "$(check_for_equality "$1" "$2")" -ne "0" ]; then
+ echo "${COL_RED}^^ Error: files no longer identical - cancelling.${COL_RESET}"
++			return 1
+ fi
+ fi
+ }
diff -Nru rmlint-2.9.0/debian/patches/series rmlint-2.9.0/debian/patches/series
--- rmlint-2.9.0/debian/patches/series	2020-12-01 21:37:43.0 +0100
+++ rmlint-2.9.0/debian/patches/series	2021-04-15 23:03:37.0 +0200
@@ -7,3 +7,4 @@
 python3.8.patch
 glib-2_62.patch
 0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
+0010-apply-upstream-fix-for-data-loss-bug.patch


signature.asc
Description: PGP signature

Bug#987032: cqrlog: Importing ADIF-logs results in 0 byte logs

2021-04-15 Thread Eike Lantzsch ZP6CGE

Package: cqrlog
Version: 2.5.1-1
Severity: important

Dear Maintainer,

On a fresh install of CQRLOG 2.5.1-1 it is impossible to import ADIF-files
because
0-bytes are imported. I made sure that the files are OK and comply with the
rules.
Import from Klog into xlog works but import from Klog into CQRLog does not.

Show QSO-List
File
Import
chose log-file.adi
Import completes immediately with 0 bytes imported.

This seems to be an upstream bug which is worked around in version 2.5.2.

I cite from
https://cqrlog.com/download

"Recent version of CQRLOG Version 2.5.2"
"workaround for 'TRegExpr exec: empty input string' error in fpc compiler"

Unfortunately cqrlog is unusable for me if I cannot import my formerly
logged QSOs from other logging-programs.

I really would like to have cqrlog version 2.5.2 included in Debian Bullseye.

Thank you for all your hard work
Eike ZP6CGE

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

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

Versions of packages cqrlog depends on:
ii  cqrlog-data   2.5.1-1
ii  default-mysql-client-core 1.0.7
ii  default-mysql-server-core 1.0.7
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.31-11
ii  libcairo2 1.16.0-5
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.8-1
ii  libgtk2.0-0   2.24.33-1
ii  libhamlib-utils   4.0-4
ii  libhamlib44.0-4
ii  libmariadb-dev-compat 1:10.5.9-1
ii  libpango-1.0-01.46.2-3
ii  libx11-6  2:1.7.0-2
ii  mariadb-client-core-10.5 [virtual-mysql-client-core]  1:10.5.9-1
ii  mariadb-server-core-10.5 [virtual-mysql-server-core]  1:10.5.9-1

Versions of packages cqrlog recommends:
ii  default-mysql-server  1.0.7
ii  xplanet   1.3.0-5.1

cqrlog suggests no packages.

Bug#982758: webext-browserpass: Failed to install on upgrade to bullseye

2021-04-15 Thread Antoine Beaupré

I have had the same, completely crashes the apt run too, neat. :)

dpkg: error processing archive 
/var/cache/apt/archives/webext-browserpass_3.7.2-1+b1_amd64.deb (--unpack):
 unable to open 
'/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserp...@maximbaz.com/icon.png.dpkg-new':
 No such file or directory
Reinstalling 
/etc/chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json that 
was moved away
Errors were encountered while processing:
 /var/cache/apt/archives/webext-browserpass_3.7.2-1+b1_amd64.deb

I bumped the severity because it completely fails to upgrade.

Workaround: apt purge webext-browserpass && apt install webext-browserpass

-- 
Twenty years from now you will be more disappointed by the things that
you didn't do than by the ones you did do. So throw off the bowlines.
Sail away from the safe harbor. Catch the trade winds in your sails.
Explore. Dream. Discover.  - Mark Twain

Bug#987031: mustang-plug: Homepage link is dead

2021-04-15 Thread Harri Haataja

Package: mustang-plug
Severity: minor
X-Debbugs-Cc: x...@iki.fi

Dear Maintainer,

the link to https://bitbucket.org/piorekf/plug leads to an error page.
(The upstream has disappeared?)


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

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

Versions of packages mustang-plug depends on:
ii  libc62.31-11
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libgcc1  1:8.3.0-6
ii  libqt5core5a 5.15.2+dfsg-5
ii  libqt5gui5   5.15.2+dfsg-5
ii  libqt5network5   5.15.2+dfsg-5
ii  libqt5widgets5   5.15.2+dfsg-5
ii  libstdc++6   10.2.1-6
ii  libusb-1.0-0 2:1.0.24-3

mustang-plug recommends no packages.

mustang-plug suggests no packages.

Bug#987017: recommends 3 different ways to find obsolete packages, pick one

2021-04-15 Thread Antoine Beaupré

On 2021-04-15 21:08:27, Justin B Rye wrote:
> Antoine Beaupre wrote:
>> The release notes, in sections 4.2.2 and 4.8, actually suggest *three*
>> *different* ways of finding what are essential orphaned packages:
>
> I don't think you mean "orphan" in either of the senses known to
> "https://wiki.debian.org/Glossary#orphan;.

I should have said "obsolete", I think.

>> aptitude search '~o'
>
> This is nice and simple, but frankly as an aptitude user I wouldn't
> bother.  Instead I'd do what the text just above mentions - launch
> aptitude, notice that there was a category for "Obsolete and Locally
> Created Packages" (which would tell me I'd somehow lost track of my
> kernel packages), and purge everything in that category from the
> full-screen interface, without going back to the commandline.

I think the point here is that you can do:

aptitude purge '~o'

... to avoid loading the GUI.

>> aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
>
> This one (apparently an improvement on the '~i(!~ODebian)' search that
> was recommended for buster, though the logic is too subtle for me to
> remember) is looking for a slightly different thing at a different
> stage in the upgrade process: it's part of the section about getting
> rid of "non-Debian packages" *before* the upgrade.  The '~o' and
> '!~ODebian' searches find different kinds of "unwanted" package.

Maybe it would be worth clarifying that distinction then?

It might help if the former `~o` is expanded to `?obsolete` in the text,
to make it clearer how it compares with the latter.

>> apt-forktracer | sort
>
> I've never quite been able to understand how it is that anybody
> could get themselves into the situation of *needing* this specialised
> package installed to work around the weirdness of their setup, but
> still need to be told what it is that's unusual about their system.

I actually find the output of apt-forktracer to be quite handy.

>> Then I also know of those:
>> 
>> apt-show-versions | grep -v /bullseye
>
> This is another package I've never needed to install on my stable
> desktop precisely because it's my stable desktop.  If I had a reason
> to install it, presumably I'd already know about the reason, and step
> one in the bullseye upgrade process should be to get rid of that.

Yeah, although I guess that's the point of those commands: figure out if
there's a mess in there.

I find apt-show-versions to be comparable to apt-forktracer, but a bit
more flexible.

>> aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
>
> Yes, that's the one you listed above.

Ah yes, sorry for the dupe.

>> aptitude search 
>> '?narrow(?not(?archive("^[^n][^o][^w].*$")),?version(CURRENT))'
>
> Does that do something similar to the above, but less intelligibly, or
> something different?

I frankly have no idea anymore.

>> I frankly don't quite know where I stand with all this anymore, but I
>> am getting the strong feeling we're sending an incoherent message
>> here. :)
>
> It's two different messages in two different parts of the release
> notes.  The first message is roughly "before the upgrade, look at what
> you've got installed.  If it's a mix of complex pins and PPA packages
> and nonsense like that, start by getting rid of all the crazy stuff".
> Unfortunately, this relies on the reader to apply some common sense,
> so we've fallen into the trap of replacing "subjective" advice with
> "objective" diagnostic commandlines.

I see. Maybe a quick oneliner explanation before the command could help
alleviate that confusion then...

> The second message is "after the upgrade, throw out all the stuff
> that isn't supported any longer".  This really is trivially easy to
> automate, as long as you don't confuse it with the previous task.

Same here, I guess.

>> In my personal documentation, I've settled on `apt-forktracer`,
>
> I'd be interested to know what you find it useful for.

I like that it shows the related versions in the archive, and that it
has very terse output.

>> but I
>> suspect we might want to stick with `aptitude search '~obsolete'`
>> because that matches other documentation in the release notes (and
>> allows for easy purging).
>
> But it isn't looking for the same thing.

Okay, so just stick to aptitude in both cases then, and don't introduce
apt-forktracer. :)

>> Is there any reason why we have all that diversity?
>> 
>> What's the right way to do what we actually want here?
>
>  [---suture---]
>> I actually forgot that bullseye itself introduces yet another one:
>>
>> apt list ~obsolete
>
> And indeed for section 4.8, which is dealing with tidying up *after*
> the upgrade, it might make sense to recommend the use of apt instead
> of aptitude here.

Yeah, and then we get rid of aptitude in the docs in bullseye +1 :)

So, TL;DR: we should have this before, to find and cleanup foreign
packages:

aptitude search '?narrow(?installed, ?not(?origin(Debian)))'

Presumably `apt list`

Bug#987030: linux-image-5.10.0-6-amd64 - Fans speed maximum - CPU load < 1%

2021-04-15 Thread klak

Package:linux-image-5.10.0-6-amd64
Version:5.10.28-1

Hello Maintainer,

every few minutes the fans turn to maximum for a few seconds. The CPU
load is less than 1 %, but the fans are turning maximum. The problen
starts with version 5.9. I didn't see anything conspicuous in the
syslog. The machine is a KVM host and the problem also occurs when it
is idle.

Board + CPU :
=
DMI: Intel Corporation S5520HC/S5520HC, BIOS
S5500.86B.01.00.0064.050520141428 05/05/2014

smpboot: CPU0: Intel(R) Xeon(R) CPU   L5640  @ 2.27GHz (family:
0x6, model: 0x2c, stepping: 0x2)

Performance Events: PEBS fmt1+, Westmere events, 16-deep LBR, Intel PMU
driver.
DMAR: Intel(R) Virtualization Technology for Directed I/O


Greets klak

Bug#987017: recommends 3 different ways to find obsolete packages, pick one

2021-04-15 Thread Justin B Rye

Antoine Beaupre wrote:
> The release notes, in sections 4.2.2 and 4.8, actually suggest *three*
> *different* ways of finding what are essential orphaned packages:

I don't think you mean "orphan" in either of the senses known to
"https://wiki.debian.org/Glossary#orphan;.

> aptitude search '~o'

This is nice and simple, but frankly as an aptitude user I wouldn't
bother.  Instead I'd do what the text just above mentions - launch
aptitude, notice that there was a category for "Obsolete and Locally
Created Packages" (which would tell me I'd somehow lost track of my
kernel packages), and purge everything in that category from the
full-screen interface, without going back to the commandline.

> aptitude search '?narrow(?installed, ?not(?origin(Debian)))'

This one (apparently an improvement on the '~i(!~ODebian)' search that
was recommended for buster, though the logic is too subtle for me to
remember) is looking for a slightly different thing at a different
stage in the upgrade process: it's part of the section about getting
rid of "non-Debian packages" *before* the upgrade.  The '~o' and
'!~ODebian' searches find different kinds of "unwanted" package.

> apt-forktracer | sort

I've never quite been able to understand how it is that anybody
could get themselves into the situation of *needing* this specialised
package installed to work around the weirdness of their setup, but
still need to be told what it is that's unusual about their system.

> Then I also know of those:
> 
> apt-show-versions | grep -v /bullseye

This is another package I've never needed to install on my stable
desktop precisely because it's my stable desktop.  If I had a reason
to install it, presumably I'd already know about the reason, and step
one in the bullseye upgrade process should be to get rid of that.

> aptitude search '?narrow(?installed, ?not(?origin(Debian)))'

Yes, that's the one you listed above.

> aptitude search 
> '?narrow(?not(?archive("^[^n][^o][^w].*$")),?version(CURRENT))'

Does that do something similar to the above, but less intelligibly, or
something different?

> I frankly don't quite know where I stand with all this anymore, but I
> am getting the strong feeling we're sending an incoherent message
> here. :)

It's two different messages in two different parts of the release
notes.  The first message is roughly "before the upgrade, look at what
you've got installed.  If it's a mix of complex pins and PPA packages
and nonsense like that, start by getting rid of all the crazy stuff".
Unfortunately, this relies on the reader to apply some common sense,
so we've fallen into the trap of replacing "subjective" advice with
"objective" diagnostic commandlines.

The second message is "after the upgrade, throw out all the stuff
that isn't supported any longer".  This really is trivially easy to
automate, as long as you don't confuse it with the previous task.

> In my personal documentation, I've settled on `apt-forktracer`,

I'd be interested to know what you find it useful for.

> but I
> suspect we might want to stick with `aptitude search '~obsolete'`
> because that matches other documentation in the release notes (and
> allows for easy purging).

But it isn't looking for the same thing.

> Is there any reason why we have all that diversity?
> 
> What's the right way to do what we actually want here?

 [---suture---]
> I actually forgot that bullseye itself introduces yet another one:
>
> apt list ~obsolete

And indeed for section 4.8, which is dealing with tidying up *after*
the upgrade, it might make sense to recommend the use of apt instead
of aptitude here.

> Apparently, those are also a thing:
>
>  comm -23 <(dpkg-query -W -f '${db:Status-Abbrev}\t${Package}\n' | grep 
> '^.[^nc]' | cut -f2 | sort) <(apt-cache dumpavail | sed -rn 's/^Package: 
> (.*)/\1/p' | sort -u)
>  apt list --installed | awk -F/ '/\[installed,local\]/{print $1}'

If they're not getting shorter, you're going the wrong way.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#986968: GNOME extension crashes on startup and disables all other extensions

2021-04-15 Thread Sébastien Villemot

Hi François,

Le mercredi 14 avril 2021 à 12:20 -0700, Francois Marier a écrit :
> On 2021-04-14 at 10:47:46, Sébastien Villemot (sebast...@debian.org)
> wrote:
> > I really think that this issue should be fixed for bullseye,
> > because it makes
> > workrave mostly unusable on our default desktop environment. Please
> > let me know
> > if you plan to fix it yourself, or if you prefer me to NMU.
> 
> Given the freeze and the time-sensitive nature of this fix, I will
> gladly
> accept your help. Please go ahead with the NMU and unblock request.

I made the upload, pushed the changes to salsa, and requested an
unblock.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#987029: gnome-books: Starts, but does not work, UI fail

2021-04-15 Thread Harri Haataja

Package: gnome-books
Version: 3.34.0-4
Severity: important
X-Debbugs-Cc: x...@iki.fi

Dear Maintainer,

I noticed gnome-books and decided to test it. Apt install and start lead to a 
partial blank
window. Top menu exists, but there is nothing in the books window. Also no 
decoration (title
bar, x).

Selecting quit from window leads to a few messages:

Apr 15 23:01:31 bastet gnome-books[36296]: Attempting to call back into JSAPI 
during the sweeping phase of GC. This is most likely caused by not destroying a 
Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be 
caused by using the destroy(), dispose(), or remove() vfuncs. Because it would 
crash the application, it has been blocked and the JS callback not invoked.
Apr 15 23:01:31 bastet gnome-books[36296]: The offending signal was destroy on 
Gjs_SelectionToolbar 0x564c6fae1590.
Apr 15 23:01:31 bastet org.gnome.Books[36296]: == Stack trace for context 
0x564c6f09b1a0 ==

Books appears to be unusable on this machine. No idea where the problem would 
be. Nothing is
printed after that stack trace message.

https://gitlab.gnome.org/GNOME/gnome-books/-/issues/44 This looks like a 
similar issue.


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

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

Versions of packages gnome-books depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-evince-3.03.38.2-1
ii  gir1.2-gdkpixbuf-2.0 2.42.2+dfsg-1
ii  gir1.2-gepub-0.6 0.6.0-2
ii  gir1.2-gnomedesktop-3.0  3.38.4-1
ii  gir1.2-gtk-3.0   3.24.24-3
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-tracker-2.0   2.3.6-2
ii  gir1.2-webkit2-4.0   2.30.6-1
ii  gjs  1.66.2-1
ii  gnome-online-miners  3.34.0-2
ii  libc62.31-11
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libevdocument3-4 3.38.2-1
ii  libevview3-3 3.38.2-1
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.8-1
ii  libgnome-desktop-3-193.38.4-1
ii  libgtk-3-0   3.24.24-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  tracker  2.3.6-2
ii  tracker-extract  2.3.5-2

Versions of packages gnome-books recommends:
pn  gir1.2-lokdocview-0.1  
pn  gnome-user-docs
pn  libgsf-bin 
ii  unoconv0.7-2

gnome-books suggests no packages.

-- no debconf information

Bug#987028: unblock: workrave/1.10.44-7.1

2021-04-15 Thread Sébastien Villemot

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

Dear Release Team,

Please unblock package workrave.

The version currently in unstable fixes important bug #986968.

This bug makes workrave mostly unusable on GNOME, which is our default desktop
environment. The package remains usable on other desktop environments, hence
the non-RC severity.

The fix is a backport of an upstream commit (as documented in the DEP-3 headers
of the patch), so the risk of regression should be limited. Also, this is a
non-key leaf package.

The debdiff is attached.

unblock workrave/1.10.44-7.1

Thanks,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org
diff -Nru workrave-1.10.44/debian/changelog workrave-1.10.44/debian/changelog
--- workrave-1.10.44/debian/changelog   2021-01-19 09:09:17.0 +0100
+++ workrave-1.10.44/debian/changelog   2021-04-15 21:29:48.0 +0200
@@ -1,3 +1,11 @@
+workrave (1.10.44-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * fix-gnome-extension-crash.patch: new patch, fixes GNOME extension crash at
+Shell startup. (Closes: #986968)
+
+ -- Sébastien Villemot   Thu, 15 Apr 2021 21:29:48 +0200
+
 workrave (1.10.44-7) unstable; urgency=medium
 
   * Bump copyright years in debian/copyright.
diff -Nru workrave-1.10.44/debian/patches/fix-gnome-extension-crash.patch 
workrave-1.10.44/debian/patches/fix-gnome-extension-crash.patch
--- workrave-1.10.44/debian/patches/fix-gnome-extension-crash.patch 
1970-01-01 01:00:00.0 +0100
+++ workrave-1.10.44/debian/patches/fix-gnome-extension-crash.patch 
2021-04-15 21:28:31.0 +0200
@@ -0,0 +1,183 @@
+Description: Fix crash in GNOME Shell extension
+ On GNOME Shell startup, the extension crashes and disables all other
+ extensions.
+Origin: backport, 
https://github.com/rcaelers/workrave/commit/56af818cd3e148069134551aacc7b06043d8541a
+Bug: https://github.com/rcaelers/workrave/issues/281
+Bug-Debian: https://bugs.debian.org/986968
+Last-Update: 2021-04-14
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/frontend/applets/common/src/timebar.c
 b/frontend/applets/common/src/timebar.c
+@@ -25,7 +25,7 @@
+ static void workrave_timebar_class_init(WorkraveTimebarClass *klass);
+ static void workrave_timebar_init(WorkraveTimebar *self);
+ 
+-static void workrave_timebar_init_ui(WorkraveTimebar *self);
++static void workrave_timebar_init_ui(WorkraveTimebar *self, cairo_t *c);
+ static void workrave_timebar_draw_filled_box(WorkraveTimebar *self, cairo_t 
*cr, int x, int y, int width, int height);
+ static void workrave_timebar_draw_frame(WorkraveTimebar *self, cairo_t *cr, 
int width, int height);
+ static void workrave_timebar_compute_bar_dimensions(WorkraveTimebar *self, 
int *bar_width, int *sbar_width, int *bar_height);
+@@ -48,8 +48,6 @@ enum
+ 
+ struct _WorkraveTimebarPrivate
+ {
+-  gchar *name;
+-
+   //! Color of the time-bar.
+   WorkraveColorId bar_color;
+ 
+@@ -77,9 +75,6 @@ struct _WorkraveTimebarPrivate
+   int width;
+   int height;
+ 
+-#ifndef USE_GTK2
+-  GtkStyleContext *style_context;
+-#endif
+   PangoContext *pango_context;
+   PangoLayout *pango_layout;
+ };
+@@ -127,8 +122,10 @@ workrave_timebar_init(WorkraveTimebar *s
+   priv->secondary_bar_value = 100;
+   priv->secondary_bar_max_value = 600;
+   priv->bar_text = g_strdup("");
+-
+-  workrave_timebar_init_ui(self);
++  priv->width = 0;
++  priv->height = 0;
++  priv->pango_context = NULL;
++  priv->pango_layout = NULL;
+ }
+ 
+ 
+@@ -249,80 +246,54 @@ workrave_timebar_draw_text(WorkraveTimeb
+ }
+ 
+ 
+-#ifndef USE_GTK2
+-static void
+-workrave_timebar_init_ui(WorkraveTimebar *self)
+-{
+-  WorkraveTimebarPrivate *priv = workrave_timebar_get_instance_private(self);
+-
+-  priv->style_context = gtk_style_context_new();
+-
+-  GtkWidgetPath *path = gtk_widget_path_new();
+-  gtk_widget_path_append_type(path, GTK_TYPE_BUTTON);
+-  gtk_style_context_set_path(priv->style_context, path);
+-  gtk_style_context_add_class(priv->style_context, GTK_STYLE_CLASS_TROUGH);
+-
+-  GdkScreen *screen = gdk_screen_get_default();
+-  priv->pango_context = gdk_pango_context_get_for_screen(screen);
+-
+-  PangoFontDescription *font_desc = NULL;
+-  gtk_style_context_get (priv->style_context, GTK_STATE_FLAG_ACTIVE, "font", 
_desc, NULL);
+-
+-  pango_context_set_language(priv->pango_context, gtk_get_default_language());
+-  pango_context_set_font_description(priv->pango_context, font_desc);
+-
+-  priv->pango_layout = pango_layout_new(priv->pango_context);
+-  pango_layout_set_text(priv->pango_layout, "-9:59:59", -1);
+-
+-  pango_layout_get_pixel_size(priv->pango_layout, >width, 
>height);
+-
+-  priv->width = MAX(priv->width + 2 * MARGINX, MIN_HORIZONTAL_BAR_WIDTH);
+-  priv->height = MAX(priv->height + 2 * MARGINY, MIN_HORIZONTAL_BAR_HEIGHT);
+-
+-

Bug#987027: unblock: biosig/2.1.2-4

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Alois Schlögl , 
debian-med-packag...@lists.alioth.debian.org

Please unblock package biosig

[ Reason ]
Upstream wrote:  under certain circumstances, save2gdf from biosig-tools 
crashes, because of
memory corruption.
Because this bug could be a security issue, it would be great if we could
manage to fix this rather sooner than later.

see 
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2021-April/091120.html

[ Impact ]
biosig might become an intrusion vector due to the security issue

[ Tests ]
Unfortunately the package has only superficial tests

[ Risks ]
The package is basically a leaf package and the risk
to break anything by the attached patch is low.

[ 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 ]
There was no actual bug filed by upstream who simply has sent
a patch via private mail which I forwarded to the maintainer list.


unblock biosig/2.1.2-4
diff -Nru biosig-2.1.2/debian/changelog biosig-2.1.2/debian/changelog
--- biosig-2.1.2/debian/changelog   2021-01-26 21:47:42.0 +0100
+++ biosig-2.1.2/debian/changelog   2021-04-15 21:04:32.0 +0200
@@ -1,3 +1,11 @@
+biosig (2.1.2-4) unstable; urgency=medium
+
+  * libbiosig: cherry pick some patches from upstream
+- fix EDF-to-GDF conversion for certain files
+- fix JSON export when SampleRate is undefined (e.g. Infinity)
+
+ -- Alois Schlögl   Thu, 15 Apr 2021 21:04:32 +0200
+
 biosig (2.1.2-3) unstable; urgency=medium
 
   [ Alois Schlögl ]
diff -Nru biosig-2.1.2/debian/patches/fix-edf2gdf-and-json-export.patch 
biosig-2.1.2/debian/patches/fix-edf2gdf-and-json-export.patch
--- biosig-2.1.2/debian/patches/fix-edf2gdf-and-json-export.patch   
1970-01-01 01:00:00.0 +0100
+++ biosig-2.1.2/debian/patches/fix-edf2gdf-and-json-export.patch   
2021-04-15 21:04:32.0 +0200
@@ -0,0 +1,155 @@
+Date: Thu, 15 Apr 2021 16:11:34 +0200
+From: Alois Schlögl 
+Description: add missing sanity check on nmemb in fread(..,..,nmemb,..) - this 
can avoid memory errors in certain files
+ under certain circumstances, save2gdf from biosig-tools crashes, because of
+ memory corruption.
+ Because this bug could be a security issue, it would be great if we could
+ manage to fix this rather sooner than later.
+
+diff --git a/biosig4c++/biosig.c b/biosig4c++/biosig.c
+index aea7260f..526a8a9b 100644
+--- a/biosig4c++/biosig.c
 b/biosig4c++/biosig.c
+@@ -4142,7 +4142,8 @@ else if (!strncmp(MODE,"r",1)) {
+   hdr->CHANNEL = (CHANNEL_TYPE*) realloc(hdr->CHANNEL, hdr->NS * 
sizeof(CHANNEL_TYPE));
+   hdr->AS.Header = (uint8_t*) realloc(Header1,hdr->HeadLen);
+   char *Header2 = (char*)hdr->AS.Header+256;
+-  count  += ifread(hdr->AS.Header+count, 1, hdr->HeadLen-count, 
hdr);
++  if (hdr->HeadLen > count)
++  count  += ifread(hdr->AS.Header+count, 1, 
hdr->HeadLen-count, hdr);
+ 
+ if (count < hdr->HeadLen) {
+ biosigERROR(hdr, B4C_INCOMPLETE_FILE, "reading 
BDF/EDF variable header failed");
+@@ -4275,7 +4276,7 @@ else if (!strncmp(MODE,"r",1)) {
+   if (Dur==0.0 && FLAG_BUGGY_NEUROLOGGER_EDF) Dur = 
hdr->SPR/496.0;
+   hdr->SampleRate = hdr->SPR/Dur;
+ 
+-  if (VERBOSE_LEVEL>8) fprintf(stdout,"[EDF 220] #=%i 
SPR=%i\n",(int)iftell(hdr),(int)hdr->SPR);
++  if (VERBOSE_LEVEL>8) fprintf(stdout,"[EDF 220] #=%i SPR=%i 
Dur=%g\n",(int)iftell(hdr),(int)hdr->SPR, Dur);
+ 
+   if (hdr->NRec <= 0) {
+   struct stat FileBuf;
+@@ -4547,7 +4548,8 @@ if (VERBOSE_LEVEL>7) fprintf(stdout,"EDF+ 
event\n\ts1:\t<%s>\n\ts2:\t<%s>\n\ts3:
+   hdr->HeadLen  += 4;
+   // read header up to nLenght and nID of foreign data section
+   hdr->AS.Header = (uint8_t*) realloc(hdr->AS.Header, 
hdr->HeadLen);
+-  count += ifread(Header1+count, 1, hdr->HeadLen-count, 
hdr);
++  if (hdr->HeadLen > count)
++  count += ifread(Header1+count, 1, hdr->HeadLen-count, 
hdr);
+   uint32_t POS   = hdr->HeadLen;
+   // read "foreign data section" and "per channel data types 
section"
+   hdr->HeadLen  += leu16p(hdr->AS.Header + hdr->HeadLen-4) - 4;
+@@ -4555,7 +4557,8 @@ if (VERBOSE_LEVEL>7) fprintf(stdout,"EDF+ 
event\n\ts1:\t<%s>\n\ts2:\t<%s>\n\ts3:
+   // read "foreign data section" and "per channel data types 
section"
+   hdr->HeadLen  += 4*hdr->NS;
+   hdr->AS.Header = (uint8_t*)realloc(Header1, hdr->HeadLen+8);
+-  count += ifread(Header1+POS, 1, hdr->HeadLen-POS, hdr);
++  if (hdr->HeadLen > POS)
++

Bug#986928: autopkgtest-virt-qemu fails with stderr: Generating grub configuration file

2021-04-15 Thread Santiago R.R.

Control: notfound -1 0.42.2-1

El 14/04/21 a las 16:18, Simon McVittie escribió:
> Control: reassign -1 src:libcgroup 0.42.2-1
> 
> On Wed, 14 Apr 2021 at 15:43:42 +0200, Santiago R.R. wrote:
> > autopkgtest [15:15:46]: test tools-cgroupv1:  - - - - - - - - - - results - 
> > - - - - - - - - -
> > tools-cgroupv1   FAIL stderr: Generating grub configuration file ...
> 
> Part of the autopkgtest specification[1] is that by default, a test
> is considered to have failed if it either exits with a nonzero status,
> *or prints anything to stderr*. Your test is exiting 0, but it prints
> (harmless) messages to stderr, so the specification says it has
> failed. autopkgtest is reporting this correctly.
> 
> I believe the intention was that checking stderr like this would make
> warnings and other suspicious things fatal by default. With hindsight,
> this was probably not the right default, but we're stuck with it now.
> 
> If this is not what you want, either mark the test with
> "Restrictions: needs-root, isolation-machine, allow-stderr", or run
> update-grub like "update-grub 2>&1" so that its diagnostic messages go to
> stdout.
...

Mmm, thanks. I think I misunderstood the behaviour of the qemu virt. I
wrongly thought it was something related with grub and autopkgtest.

Thank you, and sorry for the noise,

 -- Santiago


signature.asc
Description: PGP signature

Bug#986628: unblock: r-cran-rcdklibs/2.3+dfsg-6

Hi Paul,

On Thu, Apr 15, 2021 at 09:19:48PM +0200, Paul Gevers wrote:
> > No.  The majority of packages r-cran-* packages has "real" tests that
> > are manually crafted in addition to autopkgtest-pkg-r.
> 
> Great. Loving it.

:-)
 
> > I think that's OK since as I said most of the packages have manual
> > tests.  So skipping pkg-r-autopkgtest will not really influence the 
> > tests of the packages in practice.
> 
> Because you use the word "skipping" here, I think you misunderstood my
> intentions. What I mean is that pkg-r-autopkgtest is run, but if it
> determines that it hasn't done any substantial testing, it can exit with
> exit code 77 which, with the skippable restriction, will result in a
> NEUTRAL autopkgtest result which is exactly the same as a successful
> superficial test.

May be I was a bit sloppy in my wording here.  I wanted to express:
Whatever the (non-failing) pkg-r-autopkgtest result might be the
manually crafted test will beat it with a sensible and working test.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#987026: bordeaux-threads: flaky test regularly times out

Source: bordeaux-threads
Version: 0.8.8-4
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: timeout

Dear Common Lisp Team, Sébastien,

Your package has an autopkgtest great. Unfortunately, one of your tests
is not so reliable, so you marked it as flaky. Marking tests flaky is a
good way to have tests run, but not have them influence migration.
However, in this case the flaky test regularly times out on our
infrastructure (after 2:47 hours) while a successful run is in the order
of one minute. Because the test doesn't influence migration anyways, I
am kindly asking you disabled the test until it's fixed instead to not
stress our infrastructure for the very little gain.

Paul

0.8.8-4 always times out
https://ci.debian.net/packages/b/bordeaux-threads/testing/i386/
mostly times out
https://ci.debian.net/packages/b/bordeaux-threads/testing/ppc64el/
always fails, but not much tested yet:
https://ci.debian.net/packages/b/bordeaux-threads/testing/s390x/
half of the runs time out
https://ci.debian.net/packages/b/bordeaux-threads/testing/arm64/
half of the runs time out
https://ci.debian.net/packages/b/bordeaux-threads/testing/amd64/



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987024: RFS: python-docker/4.1.0-1.2~bpo10 1 [NMU] [RC] -- Python 3 wrapper to access docker.io's control socket

2021-04-15 Thread Shane Frasier

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: python-docker
   Version : 4.1.0-1.2~bpo10+1
   Upstream Author : Docker, Inc.
 * URL : https://github.com/docker/docker-py
 * License : Apache-2.0
 * Vcs :
https://salsa.debian.org/docker-compose-team/python-docker
   Section : python

I created this backport because I need it in order to create a backport for
docker-compose.  I want to create a backport for docker-compose because my
project requires a more recent version of docker-compose than is currently
available in Buster.

It builds those binary packages:

  python3-docker - Python 3 wrapper to access docker.io's control socket

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-docker/python-docker_4.1.0-1.2~bpo10+1.dsc

Changes since the last upload:

 python-docker (4.1.0-1.2~bpo10+1) buster-backports; urgency=medium
 .
   * Rebuild for buster-backports.
 .
 python-docker (4.1.0-1.2) unstable; urgency=medium
 .
   * Uploading source-only.
 .
 python-docker (4.1.0-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add python3-distutils runtime depends. (Closes: #958577)
 .
 python-docker (4.1.0-1) unstable; urgency=medium
 .
   * New upstream version 4.1.0
 - Refresh patches
   * Use secure copyright file specification URI.
   * Set upstream metadata fields: Repository.
   * Bump debhelper from old 10 to 12.
   * Bump Standards Version
   * Drop Python3-Version field.
 Minimum required version is shipped in oldstable
 .
 python-docker (3.4.1-4.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Drop python2 support; Closes: #937714

Regards,
Shane Frasier

Bug#986727: (no subject)

2021-04-15 Thread Gordon Ball

Just to update, I applied for an unblock (#986915) for 4.8.0-2, which

* runs the tests against installed code (instead of the source tree)
* blacklists the remaining known flaky tests (appears to match the list
  Lukas provided)

The changes are in git but I haven't uploaded yet (pending approval) -
if I haven't heard by 2021-04-16 I will probably upload anyway, as I'll be
offline for a week after that, and I _hope_ the changes are fairly
uncontriversial.

I didn't include all of Lukas' changes - race condition, I'd already
made the unblock request before checking this bug again, but I'll try
and merge the ubuntu diff after the release.

Bug#986628: unblock: r-cran-rcdklibs/2.3+dfsg-6

Hi Andreas,

On 15-04-2021 21:13, Andreas Tille wrote:
> On Fri, Apr 09, 2021 at 06:32:40PM +0200, Paul Gevers wrote:
>>> We are working on it makeing them non-superficial.  Its the case for
>>> r-bioc-* currently[1] and the plan is to do this for all R packages.
>>
>> Aha, so non r-bioc-* packages are superficial at this moment.
> 
> Not really.

Sorry, then I misunderstood.

>>> However, this is for the next release.  Marking those packages
>>> superficial that do not come with a proper test can be done as well,
>>> but not in the current freeze period.
>>
>> I'll think about what this means for the Release Team. Normally when I
>> learn of packages that try to migrate to testing with superficial tests
>> not marked as such I would add a manual block. Maybe I'll see if I can
>> generate such a list for all autopkgtest-pkg-r using packages (without
>> bioc in the name).
> 
> No.  The majority of packages r-cran-* packages has "real" tests that
> are manually crafted in addition to autopkgtest-pkg-r.

Great. Loving it.

>> Thanks for letting us know. And yes, please fix this. While typing this,
>> I have one suggestion, we should make autopkgtest-pkg-r skippable and
>> pkg-r-autopkgtest should exit 77 if there's no hook nor any tests to run
>> (and without bioc currently). The overall result of skipped tests is
>> equal to successful tests marked as superficial. I believe we
>> can/could/should very well do that now in the freeze, after we fix
>> autodep8. What do you think?
> 
> I think that's OK since as I said most of the packages have manual
> tests.  So skipping pkg-r-autopkgtest will not really influence the 
> tests of the packages in practice.

Because you use the word "skipping" here, I think you misunderstood my
intentions. What I mean is that pkg-r-autopkgtest is run, but if it
determines that it hasn't done any substantial testing, it can exit with
exit code 77 which, with the skippable restriction, will result in a
NEUTRAL autopkgtest result which is exactly the same as a successful
superficial test.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986220: fonts-font-awesome: unhandled directory to symlink conversion: /usr/share/fonts-font-awesome/scss -> ../sass/font-awesome

2021-04-15 Thread Andreas Beckmann

Followup-For: Bug #986220
Control: tag -1 patch

A patch fixing this issue is attached.


Andreas
diff -Nru fonts-font-awesome-5.0.10+really4.7.0~dfsg/debian/changelog 
fonts-font-awesome-5.0.10+really4.7.0~dfsg/debian/changelog
--- fonts-font-awesome-5.0.10+really4.7.0~dfsg/debian/changelog 2020-12-13 
16:10:30.0 +0100
+++ fonts-font-awesome-5.0.10+really4.7.0~dfsg/debian/changelog 2021-04-15 
20:34:13.0 +0200
@@ -1,3 +1,10 @@
+fonts-font-awesome (5.0.10+really4.7.0~dfsg-5) UNRELEASED; urgency=medium
+
+  * Use dpkg-maintscript-helper for the directory-to-symlink conversion of
+/usr/share/fonts-font-awesome/scss.  (Closes: #986220)
+
+ -- Andreas Beckmann   Thu, 15 Apr 2021 20:34:13 +0200
+
 fonts-font-awesome (5.0.10+really4.7.0~dfsg-4) unstable; urgency=medium
 
   * prepend Nodejs version
diff -Nru 
fonts-font-awesome-5.0.10+really4.7.0~dfsg/debian/fonts-font-awesome.maintscript
 
fonts-font-awesome-5.0.10+really4.7.0~dfsg/debian/fonts-font-awesome.maintscript
--- 
fonts-font-awesome-5.0.10+really4.7.0~dfsg/debian/fonts-font-awesome.maintscript
1970-01-01 01:00:00.0 +0100
+++ 
fonts-font-awesome-5.0.10+really4.7.0~dfsg/debian/fonts-font-awesome.maintscript
2021-04-15 20:34:13.0 +0200
@@ -0,0 +1 @@
+dir_to_symlink /usr/share/fonts-font-awesome/scss ../sass/font-awesome 
5.0.10+really4.7.0~dfsg-5~

Bug#987019: (no subject)

2021-04-15 Thread Vincent Blut

Hi Josua,

Le 2021-04-15 20:22, Josua Mayer a écrit :
> Dear Maintainers,
> 
> I have found a configuration change that makes the microSD port function
> again, verified by rebuilding 5.10.0-6:
> diff --git a/debian/config/armhf/config b/debian/config/armhf/config
> index bdf0fa118db1..7c39d00d7aae 100644
> --- a/debian/config/armhf/config
> +++ b/debian/config/armhf/config
> @@ -343,6 +343,7 @@ CONFIG_GPIO_DA9052=m
>  CONFIG_GPIO_PALMAS=y
>  CONFIG_GPIO_TWL4030=y
>  CONFIG_GPIO_TWL6040=y
> +CONFIG_GPIO_MXC=y
> 
>  ##
>  ## file: drivers/gpu/drm/Kconfig

Would compiling it as a module lead to the same result?

> Yours sincerely
> Josua Mayer

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#986628: unblock: r-cran-rcdklibs/2.3+dfsg-6

Hi Paul,

On Fri, Apr 09, 2021 at 06:32:40PM +0200, Paul Gevers wrote:
> > We are working on it makeing them non-superficial.  Its the case for
> > r-bioc-* currently[1] and the plan is to do this for all R packages.
> 
> Aha, so non r-bioc-* packages are superficial at this moment.

Not really.
 
> > However, this is for the next release.  Marking those packages
> > superficial that do not come with a proper test can be done as well,
> > but not in the current freeze period.
> 
> I'll think about what this means for the Release Team. Normally when I
> learn of packages that try to migrate to testing with superficial tests
> not marked as such I would add a manual block. Maybe I'll see if I can
> generate such a list for all autopkgtest-pkg-r using packages (without
> bioc in the name).

No.  The majority of packages r-cran-* packages has "real" tests that
are manually crafted in addition to autopkgtest-pkg-r.
 
> Thanks for letting us know. And yes, please fix this. While typing this,
> I have one suggestion, we should make autopkgtest-pkg-r skippable and
> pkg-r-autopkgtest should exit 77 if there's no hook nor any tests to run
> (and without bioc currently). The overall result of skipped tests is
> equal to successful tests marked as superficial. I believe we
> can/could/should very well do that now in the freeze, after we fix
> autodep8. What do you think?

I think that's OK since as I said most of the packages have manual
tests.  So skipping pkg-r-autopkgtest will not really influence the 
tests of the packages in practice.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#987023: bamtools: autopkgtest failure: times out on armhf and s390x

Source: bamtools
Version: 2.5.1+dfsg-8
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always timeout

Dear maintainers,

Recently, you fixed bug #953939 and I enabled bamtools again on all
architectures. It doesn't fail anymore on arm64, which that bug was
about, however, it fails on armhf and 390x, both due to timeout after
2:47 hours. I copied some of the output at the bottom of this report.

These kind of timeouts are bad for our infrastructure. I'll add your
package to our ignore-list on armhf and s390x.

Paul

https://ci.debian.net/packages/b/bamtools/unstable/s390x/
https://ci.debian.net/packages/b/bamtools/testing/s390x/
https://ci.debian.net/packages/b/bamtools/testing/armhf/

https://ci.debian.net/data/autopkgtest/testing/armhf/b/bamtools/11394850/log.gz

autopkgtest [03:47:57]: test run-unit-test: [---
6
autopkgtest [06:34:37]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.hgxsggc7/downtmp/build.Doz/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.hgxsggc7/downtmp/run-unit-test-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.hgxsggc7/downtmp/run-unit-test-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.hgxsggc7/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.hgxsggc7/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=32; unset
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.hgxsggc7/downtmp/build.Doz/src/debian/tests/run-unit-test;
touch /tmp/autopkgtest-lxc.hgxsggc7/downtmp/run-unit-test-stdout
/tmp/autopkgtest-lxc.hgxsggc7/downtmp/run-unit-test-stderr;
/tmp/autopkgtest-lxc.hgxsggc7/downtmp/build.Doz/src/debian/tests/run-unit-test
2> >(tee -a /tmp/autopkgtest-lxc.hgxsggc7/downtmp/run-unit-test-stderr
>&2) > >(tee -a
/tmp/autopkgtest-lxc.hgxsggc7/downtmp/run-unit-test-stdout);" (kind: test)
autopkgtest [06:34:37]: test run-unit-test: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982253: Bug#986997: O: netkit-telnet -- basic telnet client

2021-04-15 Thread Chris Hofstaedtler

* Simon Josefsson  [210415 19:06]:
> Hi!  Upstream is not maintained either -- at least the download URL in
> netkit-telnet's debian/copyright file does not work.  How about dropping
> netkit-telnet from Debian?

In #982253 I've expressed that I for one would find that to be a
good idea. But quite clearly it is work that needs to be a) done and
b) well coordinated.

Good luck!
Chris

Bug#987022: unblock: spamassassin/3.4.5~pre1-4

2021-04-15 Thread Noah Meyerhans

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

(I sent a similar message to debian-release recently, but am opening a
bug under the expectation that the post will get lost in the noise.)

There are a few issues in spamassassin that need to be addressed prior to
the bullseye release, and I'd like to discuss the best path forward.

Bullseye currently contains version 3.4.5~pre1-3, which is based on a
pre-release of the 3.4.5 upstream release.  Upstream released 3.4.5 during
the bullseye freeze, and followed up immediately with a 3.4.6 to fix two
regressions [1] [2] that were not caught in testing.  The regressions are
already present in 3.4.5~pre-3, so we'll need some form of an update.

I'd also like to include the fix for [3], which breaks installation in some
(uncommon) scenarios.  The fix is small and should be low-risk.

These are all pretty clearly issues that need to get fixed.  What I'm
specifically interested in discussing, though, is the various upstream
commits between the 3.4.5-pre1 release and 3.4.5-final.  There are 37
commits in this set, involved in fixing 10 upstream bugs.  As most of these
bugs involve miscategorization of processed email, leaving them unfixed can
potentially lead to data loss.

I've compiled a list of the upstream bugs fixed in their 3.4 branch at [4].

Most of the rest of the changes have to do with release administrivia
and housekeeping (svn branch management, updating the Apache logo,
updating version strings, spelling corrections, etc).

If it was completely up to me, I'd want 3.4.6-1 released with bullseye.
It will be better supported by upstream and contains all the relevant
bug fixes.  IMO it's less likely to introduce any new regressions than a
3.4.5-pre1-4 with relevant changes pulled back from upstream's svn.
However, it's late in the freeze and I fully understand the policy wrt
to new upstream releases.

The alternative is that we update to a 3.4.5~pre1-4 that cherry-picks
only the specific commits targeting the bugs I'd like to fix.  This
will definitely result in a smaller debdiff, but would still carry a
comparable level of risk due to the cherry-picked changes being most
of the actual code changes introduced upstream.

The debdiff for 3.4.6-1 is at [5].  The debdiff for 3.4.5~pre1-4 is at
[6].

Let me know how you'd like to proceed.

Thanks
noah

1. https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7897
2. https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7892
3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977957
4. https://people.debian.org/~noahm/sa-bugs.html
5. https://people.debian.org/~noahm/spamassassin_3.4.6-1.debdiff
6. https://people.debian.org/~noahm/spamassassin_3.4.5~pre1-4.debdiff

unblock spamassassin/3.4.5~pre1-4

Bug#987012: gsettings-desktop-schemas: Can you update to 40.0 version?

2021-04-15 Thread Scorpion2185

Package: gsettings-desktop-schemas
Version: 3.28.1-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

I can see on https://tracker.debian.org/pkg/gsettings-desktop-schemas:
"action needed
A new upstream version is available: 40.rc
Standards version of the package is outdated."

Now there is also the 40.0 version, the one after 40.rc.

Can you update it to 40.0 version?
On experimental maybe or whatever repository is best.



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

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

Versions of packages gsettings-desktop-schemas depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2

gsettings-desktop-schemas recommends no packages.

gsettings-desktop-schemas suggests no packages.

-- no debconf information

Bug#987021: mosh: should use /usr/bin/perl #! line

2021-04-15 Thread Benjamin Barenblat

Package: mosh
Version: 1.3.2-2.1+b1
Severity: minor

/usr/bin/mosh starts with

#!/usr/bin/env perl

for portability. On Debian, however, Perl is always installed at
/usr/bin/perl; mosh should be patched to use the correct #! line.


signature.asc
Description: PGP signature

Bug#987020: gpac: CVE-2021-28300

2021-04-15 Thread Salvatore Bonaccorso

Source: gpac
Version: 1.0.1+dfsg1-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/gpac/gpac/issues/1702
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.5.2-426-gc5ad4e4+dfsg5-5

Hi,

The following vulnerability was published for gpac.

CVE-2021-28300[0]:
| NULL Pointer Dereference in the "isomedia/track.c" module's
| "MergeTrack()" function of GPAC v0.5.2 allows attackers to execute
| arbitrary code or cause a Denial-of-Service (DoS) by uploading a
| malicious MP4 file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-28300
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28300
[1] https://github.com/gpac/gpac/issues/1702

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed

2021-04-15 Thread Michael Biebl


Am 15.04.21 um 19:46 schrieb Michael Biebl:

Am 15.04.21 um 08:57 schrieb Ryutaroh Matsumoto:

* In the VM as root  echo "DefaultIPAccounting=yes" 
>>/etc/systemd/user.conf


in your initial email you said /etc/systemd/system.conf?




So you enabled "DefaultIPAccounting=yes" for the systemd --user 
instances (i.e. in user.conf) and only those systemd --user instances 
trigger that error?


If you remove "DefaultIPAccounting=yes" from user.conf, are the error 
messages gone?




Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987019: (no subject)

2021-04-15 Thread Josua Mayer


Dear Maintainers,

I have found a configuration change that makes the microSD port function 
again, verified by rebuilding 5.10.0-6:

diff --git a/debian/config/armhf/config b/debian/config/armhf/config
index bdf0fa118db1..7c39d00d7aae 100644
--- a/debian/config/armhf/config
+++ b/debian/config/armhf/config
@@ -343,6 +343,7 @@ CONFIG_GPIO_DA9052=m
 CONFIG_GPIO_PALMAS=y
 CONFIG_GPIO_TWL4030=y
 CONFIG_GPIO_TWL6040=y
+CONFIG_GPIO_MXC=y

 ##
 ## file: drivers/gpu/drm/Kconfig

Yours sincerely
Josua Mayer

Bug#941160: valgrind: Support multiarch consintallability

2021-04-15 Thread Witold Baryluk

Package: valgrind
Version: 1:3.16.1-1
Followup-For: Bug #941160
X-Debbugs-Cc: witold.bary...@gmail.com

Any comments on this? It is still not working, and recently libdrm
2.4.105 pkgconfing requirement on valgrind, made it hard to cross-compile
mesa from amd64 to amd64 + i386, with hacks.

Regards,
Witold

Bug#987019: linux-image-5.10.0-6-armmp: microSD not recognized on i.MX6 HummingBoard

2021-04-15 Thread Josua Mayer

Package: src:linux
Version: 5.10.28-1
Severity: important
X-Debbugs-Cc: josua.maye...@gmail.com

Dear Maintainer,

Since the 5.10.0-5-armmp kernel package, microSD does no longer function on the 
i.MX6 Hummingboard Pro.
The last known-working version is: 5.9.0-0.bpo.5-armmp

Judging from a diff of the .config files between the 2 versions, the likely 
cause is removal of the GPIO driver for i.MX SoCs via CONFIG_GPIO_MXC.
I will b reporting if re-enabling of that setting fixes the problem.

Yours sincerely
Josua Mayer

** Model information
Hardware: Freescale i.MX6 Quad/DualLite (Device Tree)
Revision: 
Device Tree model: SolidRun HummingBoard Dual/Quad

** PCI devices:
00:00.0 PCI bridge [0604]: Synopsys, Inc. DWC_usb3 / PCIe bridge [16c3:abcd] 
(rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport


** USB devices:
Bus 002 Device 002: ID 04b4:6570 Cypress Semiconductor Corp. Unprogrammed 
CY7C65632/34 hub HX2VL
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


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

Kernel: Linux 5.9.0-0.bpo.5-armmp (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-5.10.0-6-armmp depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-6-armmp recommends:
pn  apparmor 
pn  firmware-linux-free  

Versions of packages linux-image-5.10.0-6-armmp suggests:
pn  debian-kernel-handbook  
pn  linux-doc-5.10  

Versions of packages linux-image-5.10.0-6-armmp is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20210315-2
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
ii  firmware-ti-connectivity  20210315-2
pn  xen-hypervisor

-- no debconf information

Bug#953562: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

2021-04-15 Thread Niko Tyni

On Wed, Apr 14, 2021 at 08:50:46PM +0200, Paul Gevers wrote:
> Hi Ivo, Marco,
> 
> On 06-04-2021 22:10, Ivo De Decker wrote:
> > I ran a number of (partial and full) upgrade tests, and they all seem to 
> > work
> > fine. In all cases, libcrypt1 is installed before libc6, and there is no
> > intermediate situations where libcrypt.so.1 is missing.
> 
> The patch looks sensible after reading the discussion in these bugs. Can
> we have an upload soon to have exposure?

Hi, thanks for your work on this and sorry I'm chiming in so late.

I'm concerned that AFAICS no change in src:libxcrypt can make sure that
the new libc6 is never unpacked before libcrypt1.

  (buster-amd64)# dpkg --unpack libc6_2.31-11_amd64.deb 
  (Reading database ... 12224 files and directories currently installed.)
  Preparing to unpack libc6_2.31-11_amd64.deb ...
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Unpacking libc6:amd64 (2.31-11) over (2.28-10) ...
  (buster-amd64)# perl
  perl: error while loading shared libraries: libcrypt.so.1: cannot open shared 
object file: No such file or directory

It may well be enough to make this improbable enough in practice. Ivo's
testing certainly seems to indicate so. It still makes me a bit uneasy.

I'm happy to be proved wrong of course. Do the Important or Protected
fields in the patch affect apt's behaviour in this, for instance?

The solution Aurelien mentioned of copying the old libcrypt in
libc6.preinst and cleaning up in libc6.postinst would eliminate this
failure mode totally. But I can see it's not very desirable and may be
hard to make robust.

Just wanted to bring this up explicitly. Not objecting if we deem the
risk of remaining corner case issues small enough that it's worth taking.
-- 
Niko

Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed

2021-04-15 Thread Michael Biebl


Am 15.04.21 um 08:57 schrieb Ryutaroh Matsumoto:


* In the VM as root  echo "DefaultIPAccounting=yes" >>/etc/systemd/user.conf


in your initial email you said /etc/systemd/system.conf?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#987017: recommends 3 different ways to find obsolete packages, pick one

2021-04-15 Thread Antoine Beaupré

I actually forgot that bullseye itself introduces yet another one:

apt list ~obsolete

Apparently, those are also a thing:

 comm -23 <(dpkg-query -W -f '${db:Status-Abbrev}\t${Package}\n' | grep 
'^.[^nc]' | cut -f2 | sort) <(apt-cache dumpavail | sed -rn 's/^Package: 
(.*)/\1/p' | sort -u)
 apt list --installed | awk -F/ '/\[installed,local\]/{print $1}'

-- 
I've got to design so you can put it together out of garbage cans. In
part because that's what I started from, but mostly because I don’t
trust the industrial structure—they might decide to suppress us
weirdos and try to deny us the parts we need.
   - Lee Felsenstein

Bug#986821: freecad: Garbled menu makes freecad unusable

2021-04-15 Thread Tobias Frost

On Thu, Apr 15, 2021 at 04:44:12PM +0200, Michael Jarosch wrote:
> Am 13.04.21 um 15:18 schrieb Tobias Frost:
> > On Mon, Apr 12, 2021 at 11:48:26PM +0200, Michael Jarosch wrote:
> > > Am 12.04.21 um 15:52 schrieb Tobias Frost:
> > > So, I guess, it's my 'special' Ironlake GPU, again.
> > Ok, Let me downgrade the bug serverity then…
> 
> Hello!
> 
> Sorry, I have to revert my conclusion: Tried another Thinkpad-machine, a
> T530 with an Intel Core i7-3520M-CPU, which does not carry an Ironlake-GPU,
> anymore, but an HD-4000 ("Ivy-Bridge"). So, the problem seems to be bigger
> than just affecting a single GPU-generation(, if this is a GPU problem, at
> all).

mmm. strange.. but unfortunatly I cant reproduce it:

I've tested freecad also on different machines, one being a Tuxedo Infinity Book
with a Intel i7-8550U, and its fine.

My third machine, a rusty Thinkpad E130 powered by an i3-3227-U.. Also works…

(The first machine is a Ryzen with a nvidia gpu, so not really comparable,
where I use freecad almost daily and was mentioned in an early reply to this
bug report)

What you can try:
- check what over packages have been updated that could bring the breakage
  (maybe some kernel or intel gfx thingy?)
- temporarily rename ~/.FreeCAD to something else, to rule out that there is
  something in the config.
- Can you ensure that all freecad packages are updated... (I think a versioned
  depdency is missing, possibly #980474) I tried manually to get to an invalid 
combination,
  but the only "solution" was package freecad at 0.19 and freecad-common at
  0.18, which makes freecad stop working, but with an different error (no python
  module named freecad, completly empty main window)
 
Cheers,
-- 
tobi

Bug#987018: gnome-shell: segfault in meta_display_list_windows at core/display.c:860

2021-04-15 Thread Jaime Casanova

Package: gnome-shell
Version: 3.30.2-11~deb10u2
Severity: important
Tags: upstream

Dear Maintainer,

I got several crashes from gnome-shell, while I normally doesn't note it until
I look at /var/log/messages.

Last one was:

"""
Apr 15 10:52:18 ahch-to firefox-esr.desktop[1158]: ###!!! [Parent][RunMessage]
Error: Channel closing: too late to send/recv, messages will be lost
Apr 15 10:53:28 ahch-to gsd-print-notif[1268]: Source ID 2 was not found when
attempting to remove it
Apr 15 10:53:28 ahch-to gnome-shell[1158]: JS ERROR: TypeError:
this._trackedWindows.get(...) is
undefined#012_onWindowActorRemoved@resource:///org/gnome/shell/ui/panel.js:843:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Apr 15 10:53:28 ahch-to kernel: [45977.024092] show_signal_msg: 13 callbacks
suppressed
Apr 15 10:53:28 ahch-to kernel: [45977.024095] gnome-shell[1158]: segfault at 1
ip 7f752047bc59 sp 7fffbee42bd0 error 4 in
libmutter-3.so.0.0.0[7f752043+db000]
Apr 15 10:53:28 ahch-to kernel: [45977.024105] Code: 00 4c 89 e2 48 89 ee 48 89
df e8 62 ab fb ff 85 c0 74 5e 4c 8b 7c 24 18 e8 24 af fb ff 4d 85 ff 74 df 49
8b 0f 48 85 c9 74 05 <48> 39 01 74 0f 48 89 c6 4c 89 ff e8 97 cb fb ff 85 c0 74
c3 41 f6
"""



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1+deb10u1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-1+deb10u1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-4~deb10u1
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-ibus-1.0  1.5.19-4+deb10u1
ii  gir1.2-mutter-3  3.30.2-9~deb10u1
ii  gir1.2-nm-1.01.14.6-2+deb10u1
ii  gir1.2-nma-1.0   1.8.20-1.1
ii  gir1.2-pango-1.0 1.42.4-8~deb10u1
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-2.1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-upowerglib-1.00.99.10-1
ii  gjs  1.54.3-1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell-common   3.30.2-11~deb10u2
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4+deb10u1
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libcroco30.6.12-3
ii  libecal-1.2-19   3.30.5-1+deb10u1
ii  libedataserver-1.2-233.30.5-1+deb10u1
ii  libgcr-base-3-1  3.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libglib2.0-bin   2.58.3-2+deb10u2
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.5-1
ii  libical3 3.0.4-3
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-9~deb10u1
ii  libnm0   1.14.6-2+deb10u1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpolkit-agent-1-0  0.105-25
ii  libpolkit-gobject-1-00.105-25
ii

Bug#986721: live-boot: Failed to unmount /run/live/medium: Device or resource busy - which might corrupt live USB sticks

2021-04-15 Thread Marcel Partap


[…]

The key problem is the deletion of the original root ramdisk in its init 
scripts. This needs to be avoided so there is a valid root (and upper mount) to 
switch back to on shutdown.

My attempts of getting the mount chain to untangle without changing that were 
fruitless xD
( https://github.com/systemd/systemd/issues/17988 )

[…]

On 10/04/2021 09:51, Steven Shiau wrote:

  Failed to unmount /run/live/medium: Device or resource busy
Is any workaround we can try to avoid this?

Bug#987016: unblock: arduino/2:1.8.13+dfsg1-2

2021-04-15 Thread Carsten Schoenert

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

Please unblock package arduino

After the release of the arduino version 2:1.8.13+dfsg1-1 Andreas
Beckmann reported an issue about a broken linkage from a specific
library the arduino package sometime needs.
This issue wasn't visible before as probably nobody used one ore more
functions from the Arduino IDE which would be require the availability
of the file bcprov.jar.


[ Reason ]
The main reason for the -2 version is a fix up of a wrong linking of
the required Java library /usr/share/java/bcprov.jar.
This was reported in #985506. To prevent similar bug reports it would be
nice if 2:1.8.13+dfsg1-2 could be accepted for migration into bullseye.

There are some adjustments made which are only have effect inside the
debian/ folder and mostly kind of documentation.

Update of README.Debian about how the Arduino reference can be made
available due manual action by the user.

Update of README.source to reflect the currect package workflow with
git-buildpackage.

Small typo fix in the changelog file.

Re-add the option 'pgpsigurlmangle' within the watch file.

Adding Rules-Requires-Root: no to the control file.


[ Impact ]
There is no impact except the Arduino IDE is now able to use functions
from the Java library bcprov.jar as the linking is now pointing to the
correct file.


[ Tests ]
Unfortunately the arduino package has no autopkgtests right now as the
setup of such tests is currently to complex and time consuming.
So the functionality of the IDE is tested manually after package build.

Build of various sketch files and upload of these to the classical
Arduino Uno and to a newer model Arduino Nano.
Testing of the internal update function for used libraries.
Testing of various menu function to ensure they are working the same way
as on a local installed upstream Arduino package.


[ Risks ]
I see no risk as the change on the user side is really small and fixing
a potential issue.


[ 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

Regards
Carsten

diff -Nru arduino-1.8.13+dfsg1/debian/arduino.links 
arduino-1.8.13+dfsg1/debian/arduino.links
--- arduino-1.8.13+dfsg1/debian/arduino.links   2021-01-08 12:42:36.0 
+0100
+++ arduino-1.8.13+dfsg1/debian/arduino.links   2021-03-20 16:47:01.0 
+0100
@@ -22,7 +22,7 @@
 # From libbcpg-java (upstream is using bcpg-jdk15on)
 usr/share/java/bcpg.jar usr/share/arduino/lib/bcpg.jar
 # From libbcprov-java (upstream is using bcprov-jdk15on)
-bcprov-jdk15on-152.jar  usr/share/arduino/lib/bcprov.jar
+usr/share/java/bcprov.jar   usr/share/arduino/lib/bcprov.jar
 # From libcommons-codec-java
 usr/share/java/commons-codec.jarusr/share/arduino/lib/commons-codec.jar
 # From libcommons-compress-java
diff -Nru arduino-1.8.13+dfsg1/debian/arduino.lintian-overrides 
arduino-1.8.13+dfsg1/debian/arduino.lintian-overrides
--- arduino-1.8.13+dfsg1/debian/arduino.lintian-overrides   2021-01-08 
10:21:40.0 +0100
+++ arduino-1.8.13+dfsg1/debian/arduino.lintian-overrides   2021-03-20 
16:47:01.0 +0100
@@ -4,3 +4,5 @@
 arduino: package-contains-documentation-outside-usr-share-doc 
usr/share/arduino/tools/howto.txt
 # We've rebuild one PDF file, not worth a doc base registration.
 arduino: possible-documentation-but-no-doc-base-registration
+# That's intented that way by upstream.
+arduino: duplicate-files usr/share/doc/arduino/examples/* *
diff -Nru arduino-1.8.13+dfsg1/debian/arduino.README.Debian 
arduino-1.8.13+dfsg1/debian/arduino.README.Debian
--- arduino-1.8.13+dfsg1/debian/arduino.README.Debian   2021-01-08 
10:21:40.0 +0100
+++ arduino-1.8.13+dfsg1/debian/arduino.README.Debian   2021-03-20 
16:47:01.0 +0100
@@ -12,9 +12,6 @@
 --Scott Howard , Dec 12, 2011
 
 
-
-
-
 Note for non-reparenting window manager users
 -
 
@@ -32,3 +29,43 @@
 
 You can automate these tasks by writing them to your ~/.xsessionrc:
 $ echo export _JAVA_AWT_WM_NONREPARENTING=true >> ~/.xsessionrc
+
+
+Make the Arduino reference locally available
+
+
+The Arduino Language reference isn't currently packaged within the arduino
+package, thus you will see a error message if you try open it from the menu
+Help -> Reference.
+The HTML files of the reference using a lot of references and resources to 
other
+sides (like fonts, CSS or Javascript) on the internet these are all privacy
+breaches from a POV of Debian.
+
+In order to make the Arduino Language reference callable from the IDE you can
+do the following steps that will download an archived version of the reference,
+extract the content and move that in place. You will need to have root access
+or sudo rights for the move of the extracted content!

Bug#987017: recommends 3 different ways to find obsolete packages, pick one

2021-04-15 Thread Antoine Beaupre

Package: release-notes
Severity: minor

The release notes, in sections 4.2.2 and 4.8, actually suggest *three*
*different* ways of finding what are essential orphaned packages:

aptitude search '~o'
aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
apt-forktracer | sort

Then I also know of those:

apt-show-versions | grep -v /bullseye
aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
aptitude search 
'?narrow(?not(?archive("^[^n][^o][^w].*$")),?version(CURRENT))'

I frankly don't quite know where I stand with all this anymore, but I
am getting the strong feeling we're sending an incoherent message
here. :)

In my personal documentation, I've settled on `apt-forktracer`, but I
suspect we might want to stick with `aptitude search '~obsolete'`
because that matches other documentation in the release notes (and
allows for easy purging).

Is there any reason why we have all that diversity?

What's the right way to do what we actually want here?

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

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

Bug#987015: [pre-approval] unblock: python-apt/2.2.0

2021-04-15 Thread Julian Andres Klode

On Thu, Apr 15, 2021 at 06:28:49PM +0200, Julian Andres Klode wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: j...@debian.org
> 
> Please unblock package python-apt
> 
> [ Reason ]
> 
> Want to bump version number to stable series versioning, mostly,
> update the mirror list, and remove invalid PIE disablement which
> triggers build failures in downstreams (it fails with LTO; I think
> it's a no-op without LTO either way, or at least supposed to be,
> given that we link with -fPIC).
> 
> Don't really care much about the build dependency !nocheck
> annotations, but they were already queued. Could revert
> them if needed.
> 
> [ Impact ]
> 
> Mirror selection in tools will be from December 2020.
> 
> [ Tests ]
> 
> We have unit tests run at build time, but there are no
> code changes, just metadata and build flags.
> 
> [ Risks ]
> 
> I'm not sure the PIE change does much really, the code is linked with
> -fPIC, the annotations could trigger bootstrapping issues, but it's
> not working right now anyway so meh.
> 
> [ 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

Oops.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en
diff -Nru python-apt-2.1.7/data/templates/Debian.mirrors python-apt-2.2.0/data/templates/Debian.mirrors
--- python-apt-2.1.7/data/templates/Debian.mirrors	2020-12-10 15:35:32.0 +0100
+++ python-apt-2.2.0/data/templates/Debian.mirrors	2021-04-15 18:15:22.0 +0200
@@ -6,7 +6,6 @@
 http://mirror.sitsa.com.ar/debian/
 #LOC:AT
 http://debian.anexia.at/debian/
-http://debian.inode.at/debian/
 http://debian.lagis.at/debian/
 http://debian.mur.at/debian/
 http://debian.sil.at/debian/
@@ -28,13 +27,14 @@
 http://ftp.belnet.be/debian/
 http://mirror.as35701.net/debian/
 #LOC:BG
+http://debian.a1.bg/debian/
 http://debian.ipacct.com/debian/
 http://debian.ludost.net/debian/
 http://debian.mnet.bg/debian/
-http://debian.mobiltel.bg/debian/
 http://debian.telecoms.bg/debian/
 http://ftp.bg.debian.org/debian/
 http://ftp.uni-sofia.bg/debian/
+http://mirror.telepoint.bg/debian/
 http://mirrors.netix.net/debian/
 #LOC:BR
 http://alcateia.ufscar.br/debian/
@@ -63,6 +63,8 @@
 http://mirror.init7.net/debian/
 http://mirror.iway.ch/debian/
 http://mirror.sinavps.ch/debian/
+http://mirror1.infomaniak.com/debian/
+http://mirror2.infomaniak.com/debian/
 http://pkg.adfinis-sygroup.ch/debian/
 #LOC:CL
 http://debian.netlinux.cl/debian/
@@ -74,9 +76,11 @@
 http://ftp.cn.debian.org/debian/
 http://ftp2.cn.debian.org/debian/
 http://mirror.lzu.edu.cn/debian/
+http://mirror.sjtu.edu.cn/debian/
 http://mirrors.163.com/debian/
 http://mirrors.bfsu.edu.cn/debian/
 http://mirrors.huaweicloud.com/debian/
+http://mirrors.nju.edu.cn/debian/
 http://mirrors.tuna.tsinghua.edu.cn/debian/
 http://mirrors.ustc.edu.cn/debian/
 #LOC:CR
@@ -119,6 +123,7 @@
 http://ftp.uni-kl.de/debian/
 http://ftp.uni-mainz.de/debian/
 http://ftp.uni-stuttgart.de/debian/
+http://ftp.wrz.de/debian/
 http://ftp2.de.debian.org/debian/
 http://mirror.23media.de/debian/
 http://mirror.de.leaseweb.net/debian/
@@ -292,7 +297,6 @@
 http://ftp.debian.org/debian/
 http://ftp.debian.xs4all.net/debian/
 http://ftp.nl.debian.org/debian/
-http://ftp.nluug.nl/debian/
 http://mirror.dataone.nl/debian/
 http://mirror.duocast.net/debian/
 http://mirror.i3d.net/debian/
@@ -331,6 +335,8 @@
 #LOC:RE
 http://depot-debian.univ-reunion.fr/debian/
 #LOC:RO
+http://mirror.linux.ro/debian/
+http://mirrors.hostico.ro/debian/
 http://mirrors.nav.ro/debian/
 http://mirrors.nxthost.com/debian/
 http://mirrors.pidginhost.com/debian/
@@ -344,6 +350,7 @@
 http://mirror.corbina.net/debian/
 http://mirror.docker.ru/debian/
 http://mirror.mephi.ru/debian/
+http://mirror.surf/debian/
 http://mirror.truenetwork.ru/debian/
 http://mirrors.powernet.com.ru/debian/
 #LOC:SE
@@ -378,6 +385,7 @@
 http://ftp.tr.debian.org/debian/
 #LOC:TW
 http://debian.cs.nctu.edu.tw/debian/
+http://debian.csie.ncku.edu.tw/debian/
 http://debian.csie.ntu.edu.tw/debian/
 http://ftp.ntou.edu.tw/debian/
 http://ftp.tku.edu.tw/debian/
diff -Nru python-apt-2.1.7/data/templates/Ubuntu.mirrors python-apt-2.2.0/data/templates/Ubuntu.mirrors
--- python-apt-2.1.7/data/templates/Ubuntu.mirrors	2020-12-10 15:35:32.0 +0100
+++ python-apt-2.2.0/data/templates/Ubuntu.mirrors	2021-04-15 18:15:22.0 +0200
@@ -8,11 +8,8 @@
 http://ubuntu.unc.edu.ar/ubuntu/
 #LOC:AT
 http://mirror.easyname.at/ubuntu-archive/
-http://mirror.reismil.ch/ubuntu/
 http://ubuntu.anexia.at/ubuntu/
-http://ubuntu.inode.at/ubuntu/
 http://ubuntu.lagis.at/ubuntu/
-http://ubuntu.uni-klu.ac.at/ubuntu/
 https://mirror.kumi.systems/ubuntu-ports/
 https://mirror.kumi.systems/ubuntu/
 #LOC:AU
@@ -45,18 +42,18 @@

Bug#984924: Please provide debug information

2021-04-15 Thread Benjamin Berg

Hi,

could you please add g_message() lines into the is_noise vfs0050.c to
print line->noise_hash_1 and line->noise_hash_2.

I don't know what is going on, but maybe it would be enough to just
lower the noise threshold definition. But, to do that, we kind of need
to know more about what is going on here.

Benjamin


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

Bug#986991: xnee: incorrect URL in homepage

2021-04-15 Thread Paul Wise

On Thu, 2021-04-15 at 15:55 +0200, Henrik Sandklef wrote:

> First of all, thanks for looking in to this.

Oh, I didn't expect you to be subscribed, thanks for that.

> My name is Henrik Sandklef and I (poorly) maintain GNU Xnee.

Thanks for that too.

> Not enough to make a new release I am afraid.
> So, those plans are moved to /dev/null.

No problem.

> https://github.com/hesa/gnu-xnee
> https://github.com/hesa/gnu-xnee/commit/233d0a3e45b2ad86319d3372916ddd61b26cb5f6
> https://cvs.savannah.gnu.org/viewvc/xnee/xnee/NEWS?r1=1.110=1.111

If you have time, I would suggest a few potential actions:

Try to re-do the conversion from CVS to git using reposurgeon, since it
produces a better conversion. I wrote the attached draft cvs2git script
that uses reposurgeon and then does some cleanup on the repository with
git and git-filter-repo. It is fairly complete. In particular it drops
bogus log messages, adds git style authors and converts CVS tags and
branches to git tags and branches. Please review the script and the
resulting git repository before using it though.

http://www.catb.org/esr/reposurgeon/
https://github.com/newren/git-filter-repo

Delete and recreate the GitHub repository.

Push the new git conversion to GitHub.

Enable git in the Savannah project and push to the repository.

Remove the CVS repository for the code from the Savannah project.

Decide on whether you want GitHub or Savannah or both for hosting.

> Re-added "/xnee" to sandklef.com.

Thanks.

> [1] cert only valid for sandklef.com (not www.sandklef.com). If
> problematic, can we change the homepage to "sandklef.com/xnee"

If you control the server, it should be fairly easy to add both domains
to the Lets Encrypt certificate config. Of course changing the Homepage
to the working domain or to xnee.wordpress.com is fine too.

PS: I note the GNU link on https://sandklef.com/ is broken too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

cvs2git
Description: application/shellscript

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

Bug#986997: O: netkit-telnet -- basic telnet client

Mattia Rizzolo  writes:

> Hi!
>
> On Thu, Apr 15, 2021 at 12:50:13PM +0200, Simon Josefsson wrote:
>> Hi!  Upstream is not maintained either -- at least the download URL in
>> netkit-telnet's debian/copyright file does not work.  How about dropping
>> netkit-telnet from Debian?  GNU InetUtils provides telnet+telnetd and
>> appears to be actively maintained both in Debian and upstream, and could
>> provide the packages going forward.
>
> Considering how popular telent is, this is a migration that needs to be
> taken with care.
> I have no stake on netkit-telnet myself, and I honestly do not care as
> long as a working `telent` is available.  But since this is the default
> `telnet` it needs to be properly evaluated.

Indeed -- a source code comparison would be great.  I believe InetUtils
sources share the same origin as NetKit, but diverged at some point.
Maybe it is sufficient to compare command line parameters and its
stdin/stdout behaviour (prompting etc).

> For sure any such takeover can only happen in a few months after
> bullseye is released.

That would give plenty of testing time before bullseye+1.

>> Cc'ing Debian maintainer of inetutils too, do
>> you have any comments Guillem?
>
> Overall, with netkit-telnet orphaned, I think the final opinion rests on
> Guillem.  If he believes this is the way forward, I encourage him to
> simply build a transitional package from src:inetutils.

I'm happy to help upstream to make this smoother.

/Simon


signature.asc
Description: PGP signature

Bug#987015: [pre-approval] unblock: python-apt/2.2.0

2021-04-15 Thread Julian Andres Klode

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

Please unblock package python-apt

[ Reason ]

Want to bump version number to stable series versioning, mostly,
update the mirror list, and remove invalid PIE disablement which
triggers build failures in downstreams (it fails with LTO; I think
it's a no-op without LTO either way, or at least supposed to be,
given that we link with -fPIC).

Don't really care much about the build dependency !nocheck
annotations, but they were already queued. Could revert
them if needed.

[ Impact ]

Mirror selection in tools will be from December 2020.

[ Tests ]

We have unit tests run at build time, but there are no
code changes, just metadata and build flags.

[ Risks ]

I'm not sure the PIE change does much really, the code is linked with
-fPIC, the annotations could trigger bootstrapping issues, but it's
not working right now anyway so meh.

[ 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 python-apt/2.2.0

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

Bug#982902: fprintd: Enroll not authorized

2021-04-15 Thread Marco Trevisan

Hi,

On Tue, 16 Feb 2021 08:47:33 +0200 Martin Paljak
 wrote:
> Package: fprintd
> Version: 1.90.9-1
> Severity: important
>
> Dear Maintainer,
>
> After upgrading from version 0.8, flushing print database as requested by 
> NEWS,
> I can not enroll fresh prints, due to missing permissions

This is an expected behavior if you don't have permissions.

> $ fprintd-enroll
> Using device /net/reactivated/Fprint/Device/0
> Enrolling right-index-finger finger.
> EnrollStart failed: 
> GDBus.Error:net.reactivated.Fprint.Error.PermissionDenied: Not Authorized: 
> net.reactivated.fprint.device.enroll

> Enrolling works for root (but I don't use fingerprints with root)

If you don't have the polkit daemon running, you can still use root
passing the user you want enroll for to fprintd-enroll as argument

  # fprintd-enroll user

Should work.

As per the polkit detection it's under the fprintd scope, sorry. it's
expected to be around in any UI-based setup.

> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers stable
>   APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.16 (SMP w/32 CPU threads)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages fprintd depends on:
> ii  dbus   1.12.20-1
> ii  libc6  2.31-9
> ii  libfprint-2-2  1:1.90.7-2
> ii  libglib2.0-0   2.66.6-2
> ii  libpolkit-gobject-1-0  0.105-30
> ii  policykit-10.105-30
>
> fprintd recommends no packages.
>
> fprintd suggests no packages.
>
> -- no debconf information
>
>

Bug#987014: grml-debootstrap: dosfstools 4.2-1 breaks EFI partition setup

2021-04-15 Thread Michael Prokop

Package: grml-debootstrap
Version: 0.95
Severity: important

Hi,

forwarding this from https://github.com/grml/grml-debootstrap/issues/168:

dosfstools >=4.2-1 no longer supports setting "EFI System Partition"
as partition label:

| root@grml ~ # mkfs.fat -F32 -n "EFI System Partition" /dev/...
| mkfs.fat 4.2 (2021-01-31)
| mkfs.fat: Label can be no longer than 11 characters

This used to work fine up to and including dosfstools version 4.1.

Since this dosfstools change breaks grml-debootstrap with EFI
setups, we need to get this fixed for the upcoming bullseye release.

regards
-mika-

Bug#987013: Release goal proposal: Remove Berkeley DB

2021-04-15 Thread Bastian Blank

Package: release.debian.org
Severity: wishlist

Hi

I would like to propose a release goal:

Remove Berkeley DB (finally)

Berkeley DB was relicensed to AGPLv3 almost eight years ago.  Since
then, Debian stayed with the last version before the license change.
The license change means, we can't take upstream patches, so security
support is only provided by other distributions with in the same state.

After this time we really should try to get rid of this package, which
even is NMU maintained since three years.

Affected source packages to remove:
- db-defaults
- db5.3

Bastian

Bug#986821: freecad: Garbled menu makes freecad unusable

2021-04-15 Thread Michael Jarosch


Tried another 2 things:

1) Attached an 27-inch monitor to my T410 with 2560x1440 resolution. 
Still garbled, so, it's not related to low(er) resolution. (The 27-inch 
is that one that is attached to my core-i3-8100-machine. Standard 
resolution on my Thinkpad T410 is 1440x900, the T530's reso is 1920x1080.)


2) 0.19.1 App-Image from freecadweb.org works with no (graphical) 
problem, so far.


Greets!

Bug#986997: O: netkit-telnet -- basic telnet client

Mattia Rizzolo  writes:

> Package: wnpp
>
> The current maintainer of netkit-telnet, Mats Erik Andersson
> , is apparently not active anymore.
> Therefore, this package has been orphaned
>
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.
>
> If you want to be the new maintainer, please see
> https://www.debian.org/devel/wnpp/#howto-o for detailed
> instructions how to adopt a package properly.

Hi!  Upstream is not maintained either -- at least the download URL in
netkit-telnet's debian/copyright file does not work.  How about dropping
netkit-telnet from Debian?  GNU InetUtils provides telnet+telnetd and
appears to be actively maintained both in Debian and upstream, and could
provide the packages going forward.  If there is anything missing in
InetUtils compared to netkit-telnet(d), I'm happy to assist from the GNU
InetUtils upstream side.  Cc'ing Debian maintainer of inetutils too, do
you have any comments Guillem?

/Simon

> Some information about this package:
>
> Package: netkit-telnet
> Binary: telnet, telnetd
> Version: 0.17-42
> Maintainer: Debian QA Group 
> Build-Depends: debhelper (>= 10~), libncurses-dev, cmake
> Architecture: any
> Standards-Version: 3.9.8
> Format: 3.0 (quilt)
> Files:
>  5f3c09666f11b4e4ea5b0b4bd4c8e668 1792 netkit-telnet_0.17-42.dsc
>  d6beabaaf53fe6e382c42ce3faa05a36 133749 netkit-telnet_0.17.orig.tar.gz
>  eb4fbbdc55a3b53f7f2ebdc1f857b0cc 36068 netkit-telnet_0.17-42.debian.tar.xz
> Checksums-Sha256:
>  9bfc63c4817be1b1664940b1a85b938822c476f75a537edc8ff025baba9e29cf 1792
> netkit-telnet_0.17-42.dsc
>  9c80d5c7838361a328fb6b60016d503def9ce53ad3c589f3b08ff71a2bb88e00
> 133749 netkit-telnet_0.17.orig.tar.gz
>  1653561178542c85adfba865ec492dd9c4f35bae624f4692c7d55729da679db4
> 36068 netkit-telnet_0.17-42.debian.tar.xz
> Package-List: 
>  telnet deb net standard arch=any
>  telnetd deb net optional arch=any
> Directory: pool/main/n/netkit-telnet
> Priority: source
> Section: net


signature.asc
Description: PGP signature

Bug#985956: Merge request submittted to initramfs-tools

2021-04-15 Thread Samuel Thibault

Hello,

Pete Batard, le jeu. 15 avril 2021 16:11:02 +0100, a ecrit:
> Quite a few people are negatively affected by this bug, and one can expect a
> lot more to be if Debian 11 goes to release without the inclusion of
> mdio-bcm-unimac.ko in the netinst ARM64 ISOs.
> 
> I have created an initramfs-tools merge request to attempt to fix the
> problem, which can be found at:
> https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46

AIUI initramfs-tools rules are not used to build the nic-modules
udeb, it'd rather be happening in the linux package, in
debian/installer/modules/nic-modules, which indeed doesn't include
drivers/net/mdio/.

Linux maintainers, do you know more on this issue?

Samuel

Bug#987009: courier-authlib: the purported fix for #984810 breaks maildrop "delivery mode"

2021-04-15 Thread Flavio Stanchina


On 15/04/21 16:40, Markus Wanner wrote:

Control: tags -1 + moreinfo

On 15.04.21 16:20, Flavio Stanchina wrote:
The fix for #984810 breaks maildrop "delivery mode" because maildrop is 
no longer able to look up user details after dropping privileges (or at 
least this is what I think is happening, from my understanding of how 
"delivery mode" works).


Hm.. shouldn't the user running maildrop be part of the 'courier' group? I 
don't think that's sufficient justification for making the information 
world-readable.


Ah, I didn't consider that; or rather, I thought it was but I forgot that 
dspam is running as its own user/group. However, after adding user "dspam" 
to group "courier" it's still not working:


Apr 15 17:01:29 stanchina dspam[6766]: Delivery agent returned exit code 
67: /usr/bin/maildrop -d delivery-test
Apr 15 17:01:29 stanchina courierlocal: 
id=00025C3C.60785549.1A68,from=,addr=: 
ERR: authdaemon: s_connect() failed: Permission denied
Apr 15 17:01:29 stanchina courierlocal: 
id=00025C3C.60785549.1A68,from=,addr=: 
Invalid user specified.
Apr 15 17:01:29 stanchina courierlocal: 
id=00025C3C.60785549.1A68,from=,addr=,status: 
deferred


I guess either dspam or maildrop are dropping privileges *before* querying 
the userdb.


I need to test by removing dspam from the equation and having Courier call 
maildrop directly, as per the standard Courier configuration, but that's 
not something I can do at my pleasure on the involved servers. I'll need to 
set up a test installation.


However, I question why this needs to be done in this way; when I saw the 
changelog entry and the bug report, I knew it would break something. While 
I agree that showing the password hash (and the cleartext password, if 
present) to normal users is not good, the rest of the info obtained through 
authtest is on the same level of sensitivity as "getent passwd" and that's 
available to normal users (I think it needs to). Also, as touched upon in 
#984810, I firmly believe this needs to be assessed in cooperation with 
upstream to evaluate pros and cons before implementing a fix.


--
Ciao, Flavio

Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer

Bug#985956: Merge request submittted to initramfs-tools

2021-04-15 Thread Pete Batard

Note that this is a rather critical regression (since it used to work 
fine with previous bullseye ISOs), that is currently preventing 
installation of Debian on the Raspberry Pi 4, i.e. by far the most 
widespread ARM64 platform out there.


Quite a few people are negatively affected by this bug, and one can 
expect a lot more to be if Debian 11 goes to release without the 
inclusion of mdio-bcm-unimac.ko in the netinst ARM64 ISOs.


I have created an initramfs-tools merge request to attempt to fix the 
problem, which can be found at:

https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46

However, since I am not entirely familiar with how netinst ISO kernel 
modules are generated and picked, I can't vouch that the proposed fix, 
which consists of referencing the mdio/ subdirectory for inclusion, is 
the proper way to go...

Bug#986821: freecad: Garbled menu makes freecad unusable

2021-04-15 Thread Michael Jarosch


Am 13.04.21 um 15:18 schrieb Tobias Frost:

On Mon, Apr 12, 2021 at 11:48:26PM +0200, Michael Jarosch wrote:

Am 12.04.21 um 15:52 schrieb Tobias Frost:
So, I guess, it's my 'special' Ironlake GPU, again.

Ok, Let me downgrade the bug serverity then…


Hello!

Sorry, I have to revert my conclusion: Tried another Thinkpad-machine, a 
T530 with an Intel Core i7-3520M-CPU, which does not carry an 
Ironlake-GPU, anymore, but an HD-4000 ("Ivy-Bridge"). So, the problem 
seems to be bigger than just affecting a single GPU-generation(, if this 
is a GPU problem, at all).


Greets!
Mitsch

Bug#953562: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

2021-04-15 Thread Ivo De Decker

Hi Marco,

On Thu, Apr 15, 2021 at 02:27:10PM +0200, Marco d'Itri wrote:
> On Apr 14, Paul Gevers  wrote:
> 
> > The patch looks sensible after reading the discussion in these bugs. Can
> > we have an upload soon to have exposure?
> Unless there are any objections I will do a libxcrypt upload in a couple 
> of days.

OK, thanks!

> I think that I can leave the udeb library in /usr/lib/.

Yes. There is no upgrade issue there, and making sure the udeb doesn't change
avoids potential issues with the installer.

Ivo

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

2021-04-15 Thread Ivo De Decker


Hi Mattia,

On 4/14/21 8:18 PM, Mattia Rizzolo wrote:

On Wed, Apr 14, 2021 at 02:22:54PM +0200, Ivo De Decker wrote:

So, if that's what you think, should I upload an inkscape with a manual
dependency on libpoppler-glib8 >= 20.09.0?


Yes, that would be useful.


I've just uploaded a new inkscape with this as its only change.
https://salsa.debian.org/multimedia-team/inkscape/-/commit/0a6972eebee178f90109c96e568cdce51b7b0276
And I've confirmed with a binary debdiff that the final Depends line in
the .deb is as expected.


Thanks!


It's probably a good idea if you could age the upload so it doesn't wait
20 days, and unblock it (since it's a key package).


I added a hint.

Ivo

Bug#986590: dbus-test-runner: flaky ppc64el autopkgtest: FAIL test-libdbustest-mock-test (exit status: 1)

2021-04-15 Thread Mike Gabriel

Hi Paul,

Am Donnerstag, 15. April 2021 schrieb Paul Gevers:
> Hi Mike,
> 
> On 14-04-2021 21:41, Mike Gabriel wrote:
> > Can you re-run those autopkgtests multiple times on ppc64el and check if
> > the flakiness has now vanished with debhelper compat level bumped to
> > version 13? Thanks.
> 
> I scheduled the job 21 times. It doesn't look good:
> 
> https://ci.debian.net/user/elb...@debian.org/jobs?package=dbus-test-runner[]=unstable[]=ppc64el
> 
> Paul

I haven't looked at the build logs (am working outside...). The URL does not 
look like you used the experimental version, does it?

Mike
-- 
Sent from my Fairphone powered by SailfishOS

Bug#987011: missing certd binary

2021-04-15 Thread Lee Musgrave

package: pure-ftpd-common
Version: 1.0.49-4 all

noticed on ubuntu 20.04, i don't have a debian install, so can't give
specific details for that, but in the initial question (linked below) one
answer says the package was copied from debian without ubuntu specific
modifications and the same issue exists in the debian version.

https://answers.launchpad.net/ubuntu/+source/pure-ftpd/+question/696585
https://bugs.launchpad.net/ubuntu/+source/pure-ftpd/+bug/1924570

Bug#987009: courier-authlib: the purported fix for #984810 breaks maildrop "delivery mode"

2021-04-15 Thread Markus Wanner


Control: tags -1 + moreinfo

On 15.04.21 16:20, Flavio Stanchina wrote:
The fix for #984810 breaks maildrop "delivery mode" because maildrop is 
no longer able to look up user details after dropping privileges (or at 
least this is what I think is happening, from my understanding of how 
"delivery mode" works).


Hm.. shouldn't the user running maildrop be part of the 'courier' group? 
 I don't think that's sufficient justification for making the 
information world-readable.


Regards

Markus

Bug#987010: ITP: libemf2svg -- MS EMF (Enhanced Metafile) to SVG conversion library

2021-04-15 Thread Andrius Merkys

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block -1 by 987002

* Package name: libemf2svg
  Version : 1.1.0
  Upstream Author : Carpentier Pierre-Francois 
* URL : https://github.com/kakwa/libemf2svg
* License : GPL-2
  Programming Lang: C
  Description : MS EMF (Enhanced Metafile) to SVG conversion library

By themselves, EMF/EMF+ files are rare in the wild. However, they are
frequently embedded inside other MS file formats.

This project was started to properly convert Visio stencils (.VSS) to
svg and be able to reuse public stencils
in other environments than MS Visio (see libvisio2svg).

However this project could be use beyond its original motivations to
handle emf blobs in any MS formats.

I find this tool useful to convert EMF to more open vector formats. I
will maintain this package myself until I find an appropriate
team to transfer it to.

Best,
Andrius

Bug#987009: courier-authlib: the purported fix for #984810 breaks maildrop "delivery mode"

2021-04-15 Thread Flavio Stanchina


Package: courier-authlib
Version: 0.66.4-9+deb9u1
Severity: critical

The fix for #984810 breaks maildrop "delivery mode" because maildrop is no 
longer able to look up user details after dropping privileges (or at least 
this is what I think is happening, from my understanding of how "delivery 
mode" works).


This is *really serious* as it completely breaks mail delivery on 
previously working system -- a production mail server, in my case.


Apr 15 14:59:18 stanchina dspam[13818]: Delivery agent returned exit code 
67: /usr/bin/maildrop -d delivery-test
Apr 15 14:59:18 stanchina courierlocal: 
id=00025C27.6078377A.3214,from=,addr=: 
ERR: authdaemon: s_connect() failed: Permission denied
Apr 15 14:59:18 stanchina courierlocal: 
id=00025C27.6078377A.3214,from=,addr=: 
Invalid user specified.
Apr 15 14:59:18 stanchina courierlocal: 
id=00025C27.6078377A.3214,from=,addr=,status: 
deferred


Best regards,
Flavio Stanchina

Bug#986949: Linux 4.19 staging driver mt7621-mmc has problematic license

2021-04-15 Thread Salvatore Bonaccorso

Hi,

On Wed, Apr 14, 2021 at 08:29:48PM +0200, Gernot Hillier wrote:
> Oops, sorry, the path of the example in initial bug description is
> incomplete - the cited problematic licensing terms are from
> drivers/staging/mt7621-mmc/sd.c.
> 
> However, please refer to kernel commit 441bf7332 linked in the initial bug
> description for a list of files that should be removed.

For 4.19.y it is now queued up upstream to be dropped, cf.
https://lore.kernel.org/stable/YHghlaftXxH49lUy@sashalap/ .

Regards,
Salvatore

Bug#986991: xnee: incorrect URL in homepage

2021-04-15 Thread Henrik Sandklef

Hi

First of all, thanks for looking in to this.

My name is Henrik Sandklef and I (poorly) maintain GNU Xnee.

On 2021-04-15 09:24, Paul Wise wrote:
> On Thu, 15 Apr 2021 15:10:47 +0800 Paul Wise wrote:
> 
>> the code seems to remain on GNU Savannah though.
> 
> I subsequently found the author has also published the code on their
> GitHub account, but without any tags for releases. There is also a
> commit from 2018 saying that version 3.20 is being prepared. This
> commit also appears on the GNU Savannah CVS repository though. It might
> be worth asking the author what their plans are for project hosting.

Not enough to make a new release I am afraid. So, those plans are moved
to /dev/null.

> https://github.com/hesa/gnu-xnee
> https://github.com/hesa/gnu-xnee/commit/233d0a3e45b2ad86319d3372916ddd61b26cb5f6
> https://cvs.savannah.gnu.org/viewvc/xnee/xnee/NEWS?r1=1.110=1.111

Re-added "/xnee" to sandklef.com. Tested the following:

$ apt-cache show xnee | grep Homepage
Homepage: http://www.sandklef.com/xnee/

$ curl -sL http://www.sandklef.com/xnee >/dev/null; echo $?
0

$ curl -sL https://www.sandklef.com/xnee >/dev/null; echo $?
60
Uh oh .. note https[1]


/h

[1] cert only valid for sandklef.com (not www.sandklef.com). If
problematic, can we change the homepage to "sandklef.com/xnee"

Bug#987007: release-notes: Release notes for Bullseye by Debian Med team

Hi Justin,

On Thu, Apr 15, 2021 at 02:43:39PM +0100, Justin B Rye wrote:
> > the Debian Med team proposes the following text for the Bullseye release 
> > notes:
> > 
> > News from Debian Med Blend
> > 
> > The Debian Med team was involved into the fight against COVID-19
> 
> I'd recommend
>   
> The Debian Med team has been taking part in the fight against COVID-19

Fixed in Git.
 
> > by packaging software to research the virus on sequence level as well
> > as fighting the pandemic with tools that are used in epidemiology.
> 
> Is this
> 
>   by packaging software for researching the virus on the sequence level,
>   and by fighting the pandemic with the tools used in epidemiology.
> 
> or
>   by packaging software for researching the virus on the sequence level
>   and for fighting the pandemic with the tools used in epidemiology.

The latter - fixed in Git.

> > The effort will be continued in the next release cycle with focus on
> > machine learning tools that are used in both fields.
> > 
> > Besides adding new packages in the field of life sciences and medicine
> > more and more existing packages received Continuous Integration support.
> 
> The existing packages aren't adding new packages; we need something like
> 
>   Besides the addition of new packages in the field of life sciences and 
> medicine,
>   more and more existing packages have gained Continuous Integration 
> support.

Fixed in Git.
 
> > 
> > A range of performance critical applications now benefit from
> > https://wiki.debian.org/SIMDEverywhere;>SIMD 
> > Everywhere.
> > This library allows packages to be available on more hardware platforms
> > supported by Debian, notably on arm64, while maintaining the performance
>  ^ ^
> This sentence gets a bit sprawling.  Maybe turn the parenthetical
> commas into em-dashes?  Or actual parentheses?
> 
>   This library allows packages to be available on more hardware platforms
>   supported by Debian (notably on arm64), while maintaining the 
> performance

Fixed in Git.
 
> > benefit brought by processors supporting vector extensions, such as AVX 
> > on
> > amd64, or NEON on arm64.
> > 
> > To install packages maintained by the Debian Med team, install the
> > metapackages named med-*, which are at version 3.6.x for Debian 
> > Bullseye.
>   ^

Fixed in Git.

> > Feel free to visit the
> > http://blends.debian.org/med/tasks;>Debian Med tasks 
> > pages
>   ^

Fixed in Git.

> > to see the full range of biological and medical software available in 
> > Debian.
> > 
> 
> This all looks good to me except that we're lowercasing "bullseye".
> 
> Oh, and httpsify that URL.

I'm fine with all your corrections (and updated Git accordingly).

Thanks a lot for the review

 Andreas.

-- 
http://fam-tille.de

Bug#987008: Grub fails to find LVM volume after previous LV rename

2021-04-15 Thread Hoyer, David

Package: grub2
Version: 2.02+dfsg1-20+deb10u4

-- System Information:
Debian Release: 10.8
Architecture: amd64 (x86_64)

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

lvm2 version: 2.03.02-3
libc6 version: 2.28-10

Dear Maintainer,

We are seeing a problem with the latest buster version of grub2 with finding 
our LVM volume to boot from.
Our host has a single VG (named 'system'), with around 10 LVs.   One of the LVs 
is system-root.active which 
is what we boot from.   It contains both the /boot volume as well as the rest 
of the OS.   Also we are
using legacy boot on this host.

We are finding that if you rename an LV (not the LV we boot from), that on a 
reboot, we sometimes cannot
find the boot LV and end up at grub rescue prompt:

error: disk `lvm/system-root.active' not found. 

Entering rescue mode... 

grub rescue>

For a test, we have a LV which is not in use and we rename it to something else 
and then reboot.   After about 220
iterations of this, we run into this problem.   We are able to boot these hosts 
through a PXE server so that we
can get access to the drive which contains this VG.  When we do this sort of 
boot, we are not actually using the VG.
When we do this and then simply rename that unused LV again and then reboot, 
suddenly it will boot up again.

We reverted back to grub version 2.02+dfsg1-20+deb10u3 and the problem went 
away.

As part of our investigation of this matter, I have been running 
grub-bios-setup command after PXE booting.  I chroot
into the LV system-root.active and run the grub-bios-setup command with 
appropriate parameters and verbose enabled
as we have seen this to also fail due to the same problem.   Below is the 
output from that command when we fail:


grub-bios-setup: info: adding `hd0' -> `/dev/sda' from device.map.
grub-bios-setup: info: /dev/sda is present.
grub-bios-setup: info: Looking for /dev/sda.
grub-bios-setup: info: /dev/sda is a parent of /dev/sda.
grub-bios-setup: info: /dev/sda is present.
grub-bios-setup: info: Looking for /dev/sda.
grub-bios-setup: info: /dev/sda is a parent of /dev/sda.
grub-bios-setup: info: transformed OS device `/dev/sda' into GRUB device `hd0'.
grub-bios-setup: info: reading /boot/grub/i386-pc/boot.img.
grub-bios-setup: info: reading /boot/grub/i386-pc/core.img.
grub-bios-setup: info: root is `(null)', dest is `hd0'.
grub-bios-setup: info: Opening dest.
grub-bios-setup: info: drive = 0.
grub-bios-setup: info: the size of hd0 is 62533296.
grub-bios-setup: info: changing current directory to /dev/mapper.
grub-bios-setup: info: /dev/mapper/system-root.active is not present.
grub-bios-setup: info: changing current directory to /dev.
grub-bios-setup: info: changing current directory to system.
grub-bios-setup: info: changing current directory to mapper.
grub-bios-setup: info: changing current directory to disk.
grub-bios-setup: info: changing current directory to by-label.
grub-bios-setup: info: changing current directory to by-uuid.
grub-bios-setup: info: changing current directory to by-partuuid.
grub-bios-setup: info: changing current directory to by-id.
grub-bios-setup: info: changing current directory to by-path.
grub-bios-setup: info: changing current directory to block.
grub-bios-setup: info: /dev/sda1 is present.
grub-bios-setup: info: Looking for /dev/sda1.
grub-bios-setup: info: /dev/sda is a parent of /dev/sda1.
grub-bios-setup: info: /dev/sda1 starts from 2048.
grub-bios-setup: info: opening the device hd0.
grub-bios-setup: info: drive = 0.
grub-bios-setup: info: the size of hd0 is 62533296.
grub-bios-setup: info: drive = 0.
grub-bios-setup: info: the size of hd0 is 62533296.
grub-bios-setup: info: Scanning for DISKFILTER devices on disk hd0.
grub-bios-setup: info: Scanning for mdraid1x devices on disk hd0.
grub-bios-setup: info: Scanning for mdraid09 devices on disk hd0.
grub-bios-setup: info: Scanning for mdraid09_be devices on disk hd0.
grub-bios-setup: info: Scanning for dmraid_nv devices on disk hd0.
grub-bios-setup: info: Scanning for ldm devices on disk hd0.
grub-bios-setup: info: scanning hd0 for LDM.
grub-bios-setup: info: no LDM signature found.
grub-bios-setup: info: Scanning for lvm devices on disk hd0.
grub-bios-setup: info: no LVM signature found.
grub-bios-setup: info: Scanning for DISKFILTER devices on disk hd0.
grub-bios-setup: info: Scanning for mdraid1x devices on disk hd0.
grub-bios-setup: info: Scanning for mdraid09 devices on disk hd0.
grub-bios-setup: info: Scanning for mdraid09_be devices on disk hd0.
grub-bios-setup: info: Scanning for dmraid_nv devices on disk hd0.
grub-bios-setup: info: Scanning for ldm devices on disk hd0.
grub-bios-setup: info: scanning hd0 for LDM.

Bug#986691: smarty3: PHP syntax error in /usr/share/php/smarty3/sysplugins/smarty_security.php

2021-04-15 Thread Abhijith PA

Hello, 

Thanks for reporting. I will work on a regression update soon.


--abhijith

Bug#986749: Bad file descriptor / failed to move stale items / storage error / hash mismatch and other

2021-04-15 Thread FUSTE Emmanuel

Hello,

I have similar problems exacerbated by tree level of "forcemanaged=1" of 
apt cacher servers behind a blucoat proxy.
Somes are VM, somes are physical. All machines / OS are ok.
My conf use VfileUseRangeOps:-1 and ResuseConnections:0
Trashing all the caches on all the servers even does not completely cure 
the problem which reappear shortly.
Client concurrency activity worsen/trigguer the problem very very fast. 
Smell like treading problems.
Will activate Debug: 7 and report here if I see something interesting.

Emmanuel.

Bug#986672: golang-k8s-sigs-yaml: tests fail on armhf

Control: tag -1 patch

On Fri, 09 Apr 2021 12:01:00 +0200 Andrej Shadura 
wrote:
> # sigs.k8s.io/yaml [sigs.k8s.io/yaml.test]
> src/sigs.k8s.io/yaml/yaml_test.go:28:26: constant 9223372036854775807 
> overflows int
> FAIL  sigs.k8s.io/yaml [build failed]
> dh_auto_test: cd obj-arm-linux-gnueabihf && go test -vet=off -v -p 3 
> sigs.k8s.io/yaml returned exit code 2
> make: *** [debian/rules:4: binary] Error 2
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> status 2

Please see
https://salsa.debian.org/go-team/packages/golang-k8s-sigs-yaml/-/merge_requests/2.

-- 
Cheers,
  Andrej

Bug#987007: release-notes: Release notes for Bullseye by Debian Med team

2021-04-15 Thread Justin B Rye

Andreas Tille wrote:
> the Debian Med team proposes the following text for the Bullseye release 
> notes:
> 
> News from Debian Med Blend
> 
> The Debian Med team was involved into the fight against COVID-19

I'd recommend
  
The Debian Med team has been taking part in the fight against COVID-19

> by packaging software to research the virus on sequence level as well
> as fighting the pandemic with tools that are used in epidemiology.

Is this

  by packaging software for researching the virus on the sequence level,
  and by fighting the pandemic with the tools used in epidemiology.

or
  by packaging software for researching the virus on the sequence level
  and for fighting the pandemic with the tools used in epidemiology.

> The effort will be continued in the next release cycle with focus on
> machine learning tools that are used in both fields.
> 
> Besides adding new packages in the field of life sciences and medicine
> more and more existing packages received Continuous Integration support.

The existing packages aren't adding new packages; we need something like

  Besides the addition of new packages in the field of life sciences and 
medicine,
  more and more existing packages have gained Continuous Integration 
support.

> 
> A range of performance critical applications now benefit from
> https://wiki.debian.org/SIMDEverywhere;>SIMD 
> Everywhere.
> This library allows packages to be available on more hardware platforms
> supported by Debian, notably on arm64, while maintaining the performance
 ^ ^
This sentence gets a bit sprawling.  Maybe turn the parenthetical
commas into em-dashes?  Or actual parentheses?

  This library allows packages to be available on more hardware platforms
  supported by Debian (notably on arm64), while maintaining the performance


> benefit brought by processors supporting vector extensions, such as AVX on
> amd64, or NEON on arm64.
> 
> To install packages maintained by the Debian Med team, install the
> metapackages named med-*, which are at version 3.6.x for Debian Bullseye.
  ^
> Feel free to visit the
> http://blends.debian.org/med/tasks;>Debian Med tasks 
> pages
  ^
> to see the full range of biological and medical software available in 
> Debian.
> 

This all looks good to me except that we're lowercasing "bullseye".

Oh, and httpsify that URL.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#987005: golang-gopkg-yaml.v3: tests fail on armhf

Hi,

On Thu, 15 Apr 2021 14:57:22 +0200 Andrej Shadura 
wrote:
>   cd obj-arm-linux-gnueabihf && go test -vet=off -v -p 3 gopkg.in/yaml.v3
> # gopkg.in/yaml.v3_test [gopkg.in/yaml.v3.test]
> src/gopkg.in/yaml.v3/decode_test.go:180:26: constant -9223372036854775808 
> overflows int
> FAIL  gopkg.in/yaml.v3 [build failed]
> FAIL
> dh_auto_test: error: cd obj-arm-linux-gnueabihf && go test -vet=off -v -p 
> 3 gopkg.in/yaml.v3 returned exit code 2
> make: *** [debian/rules:6: binary] Error 25
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> status 2

I have submitted a merge request to ignore this failure on 32-bit
architectures:

https://salsa.debian.org/go-team/packages/golang-gopkg-yaml.v3/-/merge_requests/1

-- 
Cheers,
  Andrej

Bug#987007: release-notes: Release notes for Bullseye by Debian Med team

Package: release-notes
Severity: normal
Tags: patch
X-Debbugs-Cc: debian-...@lists.debian.org

Hi,

the Debian Med team proposes the following text for the Bullseye release notes:

News from Debian Med Blend

The Debian Med team was involved into the fight against COVID-19
by packaging software to research the virus on sequence level as well
as fighting the pandemic with tools that are used in epidemiology.
The effort will be continued in the next release cycle with focus on
machine learning tools that are used in both fields.

Besides adding new packages in the field of life sciences and medicine
more and more existing packages received Continuous Integration support.

A range of performance critical applications now benefit from
https://wiki.debian.org/SIMDEverywhere;>SIMD Everywhere.
This library allows packages to be available on more hardware platforms
supported by Debian, notably on arm64, while maintaining the performance
benefit brought by processors supporting vector extensions, such as AVX on
amd64, or NEON on arm64.

To install packages maintained by the Debian Med team, install the
metapackages named med-*, which are at version 3.6.x for Debian Bullseye.
Feel free to visit the
http://blends.debian.org/med/tasks;>Debian Med tasks
pages
to see the full range of biological and medical software available in
Debian.

Please feel free to discuss / enhance this text (which is also available in
Git[1]).

Kind regards and thanks for working on the Debian release

Andreas.

[1]
https://salsa.debian.org/med-team/community/communication/-/blob/master/releasenotes/bullseye/release-notes.patch

Bug#987006: unblock: openstack-debian-images/1.59

2021-04-15 Thread Thomas Goirand

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

Please unblock package openstack-debian-images

Background:
openstack-debian-images isn't only used for creating cloud images as
in cdimage.debian.org, it is also used by openstack-cluster-installer
to install servers with a bgp-to-the-host setup. In this setup, there
is no IP address assigned to physical interfaces, the IP is just bound
to the loopback, and advertized through BGP (here, using FRR).

Problem:
The version 1.58 has a wrong FRR setup (wrong directives), leading to
no connectivity of hosts after reboot.

Fix:
The simple fix is attached. It's simply restoring sanity in the frr.conf
which was somehow working in Buster, but not in Bullseye. Maybe FRR
version 7.5 (bullseye) is more strict that 6.0 (buster).

Tests:
I've tested the install under a Bullseye cluster, and it worked well.

Risks:
Not much... :)

Additionally, I've added a small "sleep 5" after the FSCK of the
installed OS, as I noticed that sometimes, the install crashes at
the end of the script. With it, it never happens. Yes, that's a race
condition, and a sleep command isn't ideal, but at this time, I have
no solution, and it's probably a bit too late to investigate. I hope
you're ok with this.

Please unblock openstack-debian-images/1.59,

Cheers,

Thomas Goirand (zigo)
diff -Nru openstack-debian-images-1.58/build-openstack-debian-image 
openstack-debian-images-1.59/build-openstack-debian-image
--- openstack-debian-images-1.58/build-openstack-debian-image   2021-03-23 
16:35:01.0 +0100
+++ openstack-debian-images-1.59/build-openstack-debian-image   2021-04-15 
11:35:32.0 +0200
@@ -1686,26 +1686,27 @@
echo " !
  address-family ipv4 unicast
   redistribute connected route-map map-redistribute
-   neighbor pg-leaf route-map map-leaf-in out
-   neighbor pg-leaf route-map map-leaf-out out
   neighbor pg-leaf soft-reconfiguration inbound
+  neighbor pg-leaf route-map map-leaf-in in
+  neighbor pg-leaf route-map map-leaf-out out
  exit-address-family
  !
  address-family ipv6 unicast
   redistribute connected route-map map-redistribute
-   neighbor pg-leaf route-map map-leaf-in out
-   neighbor pg-leaf route-map map-leaf-out out
   neighbor pg-leaf activate
   neighbor pg-leaf soft-reconfiguration inbound
+  neighbor pg-leaf route-map map-leaf-in in
+  neighbor pg-leaf route-map map-leaf-out out
  exit-address-family
 !
 route-map map-redistribute permit 10
  match interface lo
-route-map map-map-leaf-in permit 10
 !
 route-map map-leaf-out permit 10
  match interface lo
 !
+route-map map-leaf-in permit 10
+!
 " >>${MOUNT_DIR}/etc/frr/frr.conf
 fi
 
@@ -2002,6 +2003,8 @@
 fi
 
 sync
+sleep 5
+
 if [ "${REAL_HARDWARE}" = "no" ] ; then
kpartx -d ${RAW_NAME}
 fi
diff -Nru openstack-debian-images-1.58/debian/changelog 
openstack-debian-images-1.59/debian/changelog
--- openstack-debian-images-1.58/debian/changelog   2021-03-23 
16:35:01.0 +0100
+++ openstack-debian-images-1.59/debian/changelog   2021-04-15 
11:35:32.0 +0200
@@ -1,3 +1,14 @@
+openstack-debian-images (1.59) unstable; urgency=medium
+
+  * Wait 5 seconds after fsck before removing the loop device.
+  * Fixed BGP-2-the-host setup:
+- Remove "route-map map-map-leaf-in permit 10" when writing the frr.conf,
+  as this breaks the return route with FRR >= 7.
+- Fix s/route-map map-leaf-in out/route-map map-leaf-in in/.
+- Add a lasting "route-map map-leaf-in permit 10".
+
+ -- Thomas Goirand   Thu, 15 Apr 2021 11:35:32 +0200
+
 openstack-debian-images (1.58) unstable; urgency=medium
 
   * Add cgroupv1 compatibility options on the kernel command line:

Bug#987005: golang-gopkg-yaml.v3: tests fail on armhf

Source: golang-gopkg-yaml.v3
Version: 3.0.0~git20200121.a6ecf24-2
Severity: serious

Dear Maintainer,

Tests in this package fail on armhf, causing a failure to build from the
source:

regexp
internal/poll
internal/fmtsort
encoding/binary
os
encoding/base64
fmt
gopkg.in/yaml.v3
   dh_auto_test -O--buildsystem=golang
cd obj-arm-linux-gnueabihf && go test -vet=off -v -p 3 gopkg.in/yaml.v3
# gopkg.in/yaml.v3_test [gopkg.in/yaml.v3.test]
src/gopkg.in/yaml.v3/decode_test.go:180:26: constant -9223372036854775808 
overflows int
FAILgopkg.in/yaml.v3 [build failed]
FAIL
dh_auto_test: error: cd obj-arm-linux-gnueabihf && go test -vet=off -v -p 3 
gopkg.in/yaml.v3 returned exit code 2
make: *** [debian/rules:6: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2

-- 
Cheers,
  Andrej

Bug#953562: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

2021-04-15 Thread Marco d'Itri

On Apr 14, Paul Gevers  wrote:

> The patch looks sensible after reading the discussion in these bugs. Can
> we have an upload soon to have exposure?
Unless there are any objections I will do a libxcrypt upload in a couple 
of days.

I think that I can leave the udeb library in /usr/lib/.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#987004: RFP: capirca -- Multi-platform ACL generation system

2021-04-15 Thread Arturo Borrero Gonzalez

Package: wnpp
Severity: wishlist

* Package name: capirca
  Version : 2.0.3
  Upstream Author : Google
* URL : https://github.com/google/capirca
* License : Apache 2.0
  Programming Lang: Python
  Description : Multi-platform ACL generation system

Capirca is a designed to utilize common definitions of networks, services and 
high-level policy
files to facilitate the development and manipulation of network access control 
lists (ACLs) for
various platforms. It was developed by Google for internal use, and is now open 
source.

Capirca consists of capirca Python package and the accompanying aclgen tool.

Bug#986997: O: netkit-telnet -- basic telnet client

2021-04-15 Thread Mattia Rizzolo

Hi!

On Thu, Apr 15, 2021 at 12:50:13PM +0200, Simon Josefsson wrote:
> Hi!  Upstream is not maintained either -- at least the download URL in
> netkit-telnet's debian/copyright file does not work.  How about dropping
> netkit-telnet from Debian?  GNU InetUtils provides telnet+telnetd and
> appears to be actively maintained both in Debian and upstream, and could
> provide the packages going forward.

Considering how popular telent is, this is a migration that needs to be
taken with care.
I have no stake on netkit-telnet myself, and I honestly do not care as
long as a working `telent` is available.  But since this is the default
`telnet` it needs to be properly evaluated.

For sure any such takeover can only happen in a few months after
bullseye is released.

> Cc'ing Debian maintainer of inetutils too, do
> you have any comments Guillem?

Overall, with netkit-telnet orphaned, I think the final opinion rests on
Guillem.  If he believes this is the way forward, I encourage him to
simply build a transitional package from src:inetutils.

-- 
regards,
Mattia Rizzolo

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

signature.asc
Description: PGP signature

Bug#987003: Newer upstream 0.39

2021-04-15 Thread Yuri D'Elia

Package: libell-dev
Version: 0.36-1
Severity: wishlist

Upstream released ell 0.39


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

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

Versions of packages libell-dev:amd64 depends on:
ii  libell0  0.36-1

libell-dev:amd64 recommends no packages.

libell-dev:amd64 suggests no packages.

Bug#986590: dbus-test-runner: flaky ppc64el autopkgtest: FAIL test-libdbustest-mock-test (exit status: 1)

Hi Mike,

On 15-04-2021 12:24, Mike Gabriel wrote:
> Hi Paul,
> 
> Am Donnerstag, 15. April 2021 schrieb Paul Gevers:
>> Hi Mike,
>>
>> On 14-04-2021 21:41, Mike Gabriel wrote:
>>> Can you re-run those autopkgtests multiple times on ppc64el and check 
if
>>> the flakiness has now vanished with debhelper compat level bumped to
>>> version 13? Thanks.
>>
>> I scheduled the job 21 times. It doesn't look good:
>>
>> https://ci.debian.net/user/elb...@debian.org/jobs?package=dbus-test-runner[]=unstable[]=ppc64el
>>
>> Paul
> 
> I haven't looked at the build logs (am working outside...). The URL does not 
> look like you used the experimental version, does it?

Yes, it does. I used dbus-test-runner *from* experimental *in* unstable.
ci.d.n doesn't have experimental as stand-alone suite. This is also the
default way that the release team tests packages, i.e. take the package
from the source suite and run it in the target suite.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987002: ITP: libuemf -- Read/write EMF, EMF+, WMF files

2021-04-15 Thread Andrius Merkys

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: libuemf
  Version : 0.2.8+ds
  Upstream Author : , David Mathog  and California
Institute of Technology (Caltech)
* URL : https://sourceforge.net/projects/libuemf/
* License : GPL-2
  Programming Lang: C
  Description : Read/write EMF, EMF+, WMF files (development files)
 libUEMF is a portable C99 implementation for reading/writing Enhanced
Metafile
 (EMF), Enhanced Metafile Format Plus (PMF), and Windows Metafile (WMF)
files.
 libUEMF avoids collisions with Microsoft defined functions and values, so
 portable programs which use it and have a Windows version, do not
require any
 conditional logic to separate the native GDI support from the WMF/EMF/PMF
 support proviced by libUEMF. To accomplish this libUEMF does not
implement GDI
 calls. Instead, for each WMR/EMR/PMR record type, and each object type
 incorporated into such a record, it provides corresponding *_set,
*_print, and
 *_swap functions. For PMF and WMF there are also *_get functions, see
below.
 For example, for the U_EMRBITBLT record there are corresponding functions:
 U_EMRBITBLT_set, U_EMRBITBLT_print, and U_EMRBITBLT_swap. A few additional
 functions are provided for assembling the EMF in memory, debugging, and
 converting the EMF file to/from Little Endian representation. (EMF files'
 internal data representation is always Little Endian.)

libuemf is a dependency for libemf2svg which I intend to eventually package.

I will maintain this package myself at [1] until I find an appropriate
team to transfer it to.

[1] https://salsa.debian.org/debian/libuemf

Best,
Andrius

Bug#987000: ITP: gi-docgen -- source code documentation tool using GObject-Introspection

2021-04-15 Thread Simon McVittie

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org

* Package name: gi-docgen
  Version : 2021.2 or git snapshot
  Upstream Author : Emmanuele Bassi
* URL : https://gitlab.gnome.org/GNOME/gi-docgen
* License : Apache-2.0 OR GPL-3.0-or-later
  Programming Lang: Python
  Description : source code documentation tool using GObject-Introspection

GI-DocGen is a document generator for GObject-based libraries. GObject
is the base type system of the GNOME project. GI-Docgen reuses the
introspection data generated by GObject-based libraries to generate
the API reference of these libraries, as well as other ancillary
documentation.

GI-DocGen is not a general purpose documentation tool for C libraries:
while GI-DocGen can be used to generate API references for most GObject/C
libraries that expose introspection data, its main goal is to generate
the reference for GTK and its immediate dependencies.

GI-DocGen is still in development. The upstream-recommended use of
GI-DocGen is to add it as a sub-project to a Meson build system, and
vendor it when releasing dist archives. Until GI-DocGen becomes stable,
Debian packages that use it for their documentation should use a vendored
copy (as allowed by Policy §4.13), and should not have a Build-Depends
on gi-docgen.

---

We should probably package this in experimental even though
build-depending on it isn't useful yet, so that updates to to GTK-related
packages don't get stalled by the NEW queue or unforeseen packaging issues
when it's declared stable and stops being vendored by dependent packages.

Bug#987001: O: git-phab -- Git subcommand to integrate with Phabricator.

Package: wnpp
Severity: normal
Control: affects -1 src:git-phab

I intend to orphan the git-phab package.

I no longer use this package, so I’m not the right person to maintain
it. It also seems to be abandoned upstream, who also seem to no longer
use Phabricator for code reviews.

The package description is:
 Tool to help out pushing Git changes into Phabricator Differential.

-- 
Cheers,
  Andrej

Bug#986999: RFP: fonts-red-hat -- Red Hat type family

2021-04-15 Thread Simon McVittie

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-fo...@lists.debian.org, debian-gtk-gn...@lists.debian.org

* Package name: fonts-red-hat
  Version : 4.0.0
  Upstream Author : Jeremy Mickel
* URL : https://github.com/RedHatOfficial/RedHatFont
* License : SIL OFL 1.1, with Reserved Font Name Red Hat
  Programming Lang: n/a
  Description : Red Hat type family

The font family used in Red Hat branding.

This font is used in the default template for the gi-docgen tool, which
some of the lower-level GNOME-related libraries such as GTK and Pango
are starting to adopt as a replacement for gtk-doc.

At the moment I'm intending to patch out the font selection and exclude
the fonts themselves in the interests of having less to review for the
d/copyright of the packages that bundle gi-docgen (it is not yet stable,
so the intended use is for individual projects to bundle a known-good
copy rather than it being packaged distro-wide), but it would be nice
if someone with more font knowledge could package this properly.

smcv

Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed