Bug#954350: Please upgrade to new upstream version

[Laurent Bigonville]

Source: colord-gtk
Version: 0.1.26-2
Severity: wishlist

Hi,

Looks like there is a new upstream release of colord-gtk:

Version 0.2.0
~
Released: 2019-06-20

New Features:
 - Migrate to gettext (Martin Blanchard)
 - Port to DocBook 5 (Martin Blanchard)
 - Port to the Meson build system (Martin Blanchard)

Bugfixes:
 - Do not leak plug_name (Roman Lebedev)
 - Fix gtk-doc build when srcdir != builddir (Ting-Wei Lan)

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#954312: systemd: FTBFS on riscv64: test-seccomp fails: Assertion 'name' failed at src/test/test-seccomp.c:49

[Aurelien Jarno]

On 2020-03-20 08:47, Aurelien Jarno wrote:
> On 2020-03-20 01:35, Michael Biebl wrote:
> > Am 20.03.20 um 01:32 schrieb Michael Biebl:
> > > Have you tested, that seccomp is working on riscv64 with 5.5?
> > > Something like this should lead to a blocked ping:
> > 
> 
> Indeed that test doesn't work, I mean seccomp is ineffective and the
> ping succeed. It looks like that I should also update the patch you
> pointed, I'll work on that and keep you updated.

So you were right that there are way more things to change than my
initial patch. I came up with the attached patch. With it I confirm that
the test ping service you send fails correctly when running with a 5.5
kernel:

| # systemctl status test
| * test.service - test seccomp filter
|  Loaded: loaded (/etc/systemd/system/test.service; static; vendor preset: 
enabled)
|  Active: failed (Result: signal) since Fri 2020-03-20 17:45:38 CET; 6s ago
| Process: 771 ExecStart=/bin/ping -c 1 www.debian.org (code=killed, 
signal=SYS)
|Main PID: 771 (code=killed, signal=SYS)
| 
| Mar 20 17:45:38 riscv64 systemd[1]: Started test seccomp filter.
| Mar 20 17:45:38 riscv64 systemd[1]: test.service: Main process exited, 
code=killed, status=31/SYS
| Mar 20 17:45:38 riscv64 systemd[1]: test.service: Failed with result 'signal'.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
From 9bf8b4f3ce9582170c610e57d9dd341ca84ad881 Mon Sep 17 00:00:00 2001
From: Aurelien Jarno 
Date: Fri, 20 Mar 2020 17:41:42 +0100
Subject: [PATCH] seccomp: add support for riscv64

This patch adds seccomp support to the riscv64 architecture. seccomp
support is available in the riscv64 kernel since version 5.5, and it
has just been added to the libseccomp library.

riscv64 uses generic syscalls like aarch64, so I used that architecture
as a reference to find which code has to be modified.

With this patch, the testsuite passes successfully, including the
test-seccomp test. The system boots and works fine with kernel 5.4 (i.e.
without seccomp support) and kernel 5.5 (i.e. with seccomp support). I
have also verified that the "SystemCallFilter=~socket" option prevents a
service to use the ping utility when running on kernel 5.5.
---
 src/nspawn/nspawn-oci.c   |  1 +
 src/shared/seccomp-util.c | 16 
 src/test/test-seccomp.c   |  1 +
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/nspawn/nspawn-oci.c b/src/nspawn/nspawn-oci.c
index 782c03c539..e0d42eb6e7 100644
--- a/src/nspawn/nspawn-oci.c
+++ b/src/nspawn/nspawn-oci.c
@@ -1694,6 +1694,7 @@ static int oci_seccomp_arch_from_string(const char *name, uint32_t *ret) {
 { "SCMP_ARCH_PPC", SCMP_ARCH_PPC },
 { "SCMP_ARCH_PPC64",   SCMP_ARCH_PPC64   },
 { "SCMP_ARCH_PPC64LE", SCMP_ARCH_PPC64LE },
+{ "SCMP_ARCH_RISCV64", SCMP_ARCH_RISCV64 },
 { "SCMP_ARCH_S390",SCMP_ARCH_S390},
 { "SCMP_ARCH_S390X",   SCMP_ARCH_S390X   },
 { "SCMP_ARCH_X32", SCMP_ARCH_X32 },
diff --git a/src/shared/seccomp-util.c b/src/shared/seccomp-util.c
index eeca17f341..da7e46ac5b 100644
--- a/src/shared/seccomp-util.c
+++ b/src/shared/seccomp-util.c
@@ -85,6 +85,8 @@ const uint32_t seccomp_local_archs[] = {
 SCMP_ARCH_PPC64LE, /* native */
 #elif defined(__powerpc__)
 SCMP_ARCH_PPC,
+#elif defined(__riscv) && __riscv_xlen == 64
+SCMP_ARCH_RISCV64,
 #elif defined(__s390x__)
 SCMP_ARCH_S390,
 SCMP_ARCH_S390X,  /* native */
@@ -131,6 +133,8 @@ const char* seccomp_arch_to_string(uint32_t c) {
 return "ppc64";
 case SCMP_ARCH_PPC64LE:
 return "ppc64-le";
+case SCMP_ARCH_RISCV64:
+return "riscv64";
 case SCMP_ARCH_S390:
 return "s390";
 case SCMP_ARCH_S390X:
@@ -176,6 +180,8 @@ int seccomp_arch_from_string(const char *n, uint32_t *ret) {
 *ret = SCMP_ARCH_PPC64;
 else if (streq(n, "ppc64-le"))
 *ret = SCMP_ARCH_PPC64LE;
+else if (streq(n, "riscv64"))
+*ret = SCMP_ARCH_RISCV64;
 else if (streq(n, "s390"))
 *ret = SCMP_ARCH_S390;
 else if (streq(n, "s390x"))
@@ -1253,7 +1259,7 @@ int seccomp_protect_sysctl(void) {
 
 log_debug("Operating on architecture: %s", seccomp_arch_to_string(arch));
 
-if (IN_SET(arch, SCMP_ARCH_X32, SCMP_ARCH_AARCH64))
+if (IN_SET(arch, SCMP_ARCH_X32, SCMP_ARCH_AARCH64, SCMP_ARCH_RISCV64))
 /* No _sysctl syscall */
 continue;
 
@@ -1337,6 +1343,7 @@ int seccomp_restrict_address_families(Set *address_families, bool whitelist) {
 case SCMP_ARCH_MIPS64N32:
  

Bug#954345: grisbi: Save (Ctrl+S) still saves even when escaping confirmation dialog

[Roberto C . Sánchez]

tags 954345 + fixed-upstream
thanks

On Fri, Mar 20, 2020 at 05:30:10PM +0100, Ludovic Rousseau wrote:
> Le 20/03/2020 à 16:40, Roberto C. Sanchez a écrit :
> > Package: grisbi
> > Version: 1.2.2-1
> > Severity: important
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > It seems that when choosing "Save" (for example, with Ctrl+S) that the
> > presented dialog does not function correctly.  Speceifically, the dialog
> > contains two options: "Cancel" and "Save".  Pressing the "Escape" key
> > seems like it should be equivalent to a "Cancel" selection.  However,
> > when I attempt this (pressing "Escape" to not have the changes saved),
> > Grisbi still saves the changes.  This seems to make it not possible to
> > discard changes in the expected way.
> 
> Exact.
> I fixed the problem in Grisbi upstream at 
> https://github.com/grisbi/grisbi/commit/76c4dbb62bae791129b509b297800c98b2b0cd96
> 
> Do you think it is important enough that I need to make a new Debian version 
> of Grisbi just to fix this issue?
> 
I don't think a special release is needed for this.  I am glad that it
is fixed already :-)

I've tagged this bug fixed-upstream to ensure that others who may
encounter it know that a fix will come with a future upstream release.

Regards,

-Roberto

-- 
Roberto C. Sánchez


signature.asc
Description: PGP signature

Bug#954349: RFS: swapspace/1.16.1-1 -- dynamic swap space manager

[Jacob Adams]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "swapspace"

 * Package name: swapspace
   Version : 1.16.1-1
   Upstream Author : Jacob Adams 
 * URL : https://github.com/Tookmund/Swapspace
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/tookmund-guest/swapspace-deb
   Section : admin

It builds those binary packages:

  swapspace - dynamic swap space manager

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/swapspace/swapspace_1.16.1-1.dsc

Changes since the last upload:

   * New upstream version
   * Add support for BTRFS
   * Enforce correct permissions on swapfile directory
   * Bumped debhelper compat to 12
   * Bumped 'Standards-Version' to 4.5.0 (No changes required)
   * Add NEWS file to docs

Regards,
Jacob



signature.asc
Description: OpenPGP digital signature

Bug#954266: qemu-system-x86: graphical-mode monitor doesn't work

[Bernhard Übelacker]

Hello,
tried to collect some more details.
Found that the failure started with the migration
of these packages into testing:

  libvte-2.91-0 libvte-2.91-common (0.60.0-2)

The monitor worked before with 0.58.3-1.

Kind regards,
Bernhard


# Bullseye/testing amd64 qemu VM 2020-03-20

apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox xterm qemu-system


export DISPLAY=:0
qemu-system-x86_64

(qemu,outside) sendkey ctrl-alt-2



# dpkg -l | grep 1:4.2-3
ii  qemu-system-common   1:4.2-3 amd64  
  QEMU full system emulation binaries (common files)
ii  qemu-system-data 1:4.2-3 all
  QEMU full system emulation (data files)
ii  qemu-system-gui  1:4.2-3 amd64  
  QEMU full system emulation binaries (user interface and audio support)
ii  qemu-system-misc 1:4.2-3 amd64  
  QEMU full system emulation binaries (miscellaneous)
ii  qemu-system-x86  1:4.2-3 amd64  
  QEMU full system emulation binaries (x86)
ii  qemu-utils   1:4.2-3 amd64  
  QEMU utilities




wget 
https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-common_4.1-1%2Bb4_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190827T150849Z/pool/main/q/qemu/qemu-system-data_4.1-1_all.deb
wget 
https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-gui_4.1-1%2Bb4_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-misc_4.1-1%2Bb4_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-system-x86_4.1-1%2Bb4_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20191026T211939Z/pool/main/q/qemu/qemu-utils_4.1-1%2Bb4_amd64.deb
apt install libbluetooth3
dpkg -i *.deb

-> already here




wget 
https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-common_3.1%2Bdfsg-8_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190528T101728Z/pool/main/q/qemu/qemu-system-data_3.1%2Bdfsg-8_all.deb
wget 
https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-gui_3.1%2Bdfsg-8_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-misc_3.1%2Bdfsg-8_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-system-x86_3.1%2Bdfsg-8_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190528T165330Z/pool/main/q/qemu/qemu-utils_3.1%2Bdfsg-8_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190831T031850Z/pool/main/n/nettle/libnettle6_3.5.1%2Breally3.4.1-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190924T204643Z/pool/main/b/brltty/libbrlapi0.6_5.6-11%2Bb1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20190109T223525Z/pool/main/v/virglrenderer/libvirglrenderer0_0.7.0-2_amd64.deb
dpkg -i *.deb

-> already here --> maybe caused by dependency ?




#



Buster/stable amd64 qemu VM 2020-03-20



sources.list
# snapshot
deb [check-valid-until=no] 
http://192.168.178.25:/debian-11-bullseye-snapshot.debian.org/ testing main
#deb-src [check-valid-until=no] 
http://192.168.178.25:/debian-11-bullseye-snapshot.debian.org/ testing main
#deb [check-valid-until=no] 
http://192.168.178.25:/debian-11-bullseye-debug-snapshot.debian.org/ 
testing-debug main


approx:
debian-11-bullseye-snapshot.debian.org  
https://snapshot.debian.org/archive/debian/20190801T00Z/


apt update
apt dist-upgrade
apt install systemd-coredump sddm xserver-xorg openbox xterm qemu-system
reboot



20190801T00Z -> testing still works (qemu 1:3.1+dfsg-8)
20190901T00Z -> testing still works (qemu 1:3.1+dfsg-8)
20191001T00Z -> testing still works (qemu 1:4.1-1)
20191101T00Z -> testing still works (qemu 1:4.1-1+b2)
20191201T00Z -> testing still works (qemu 1:4.1-1+b4)
20200101T00Z -> testing still works (qemu 1:4.1-3)
20200201T00Z -> testing still works (qemu 1:4.2-1)
20200215T00Z -> testing still works (qemu 1:4.2-1)
20200301T00Z -> testing still works (qemu 1:4.2-3)
20200303T00Z -> testing still works (qemu 1:4.2-3)
20200305T00Z -> testing still works (qemu 1:4.2-3)
20200307T00Z -> testing still works (qemu 1:4.2-3)
20200309T00Z -> testing still works (qemu 1:4.2-3)
20200311T00Z -> testing still works (qemu 1:4.2-3)
20200313T00Z -> testing still works (qemu 1:4.2-3)
20200315T00Z -> testing still works (qemu 1:4.2-3)
20200316T00Z -> testing still works (qemu 1:4.2-3)

apt install dconf-gsettings-backend dconf-service gpgv libdconf1 libicu63 
libnspr4 logrotate ovmf python3-idna python3-pycurl 

Bug#954345: grisbi: Save (Ctrl+S) still saves even when escaping confirmation dialog

[Ludovic Rousseau]

Le 20/03/2020 à 16:40, Roberto C. Sanchez a écrit :

Package: grisbi
Version: 1.2.2-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It seems that when choosing "Save" (for example, with Ctrl+S) that the
presented dialog does not function correctly.  Speceifically, the dialog
contains two options: "Cancel" and "Save".  Pressing the "Escape" key
seems like it should be equivalent to a "Cancel" selection.  However,
when I attempt this (pressing "Escape" to not have the changes saved),
Grisbi still saves the changes.  This seems to make it not possible to
discard changes in the expected way.


Exact.
I fixed the problem in Grisbi upstream at 
https://github.com/grisbi/grisbi/commit/76c4dbb62bae791129b509b297800c98b2b0cd96

Do you think it is important enough that I need to make a new Debian version of 
Grisbi just to fix this issue?

Regards

--
Dr. Ludovic Rousseau

Bug#954134: [d-i bullseye alpha2] installing grub fails

[Steve McIntyre]

Hey Holger!

On Fri, Mar 20, 2020 at 01:35:24PM +0100, Holger Wansing wrote:
>Steve McIntyre  wrote:
>> 
>> Hmmm. Can you try wiping the partition table in between tests?
>
>I already tried that on wednesday, with no success.
>
>However, today it does the trick! Success!
>Curious, but installation completed fine.
>
>Will see, if I can reproduce it again...

ACK. I'm struggling to understand this otherwise.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

Bug#954348: git: FTBFS on hppa - run_with_limited_stack tests fail

[John David Anglin]

Package: git
Version: 1:2.25.1-1
Severity: normal

Dear Maintainer,

Your git package fails to build on hppa because the run_with_limited_stack
tests fail (68 and 69).

See for example:
https://buildd.debian.org/status/fetch.php?pkg=git=hppa=1%3A2.26.0%7Erc2-1=1584677337=0

Please increase the run_with_limited_stack stack size on hppa or xfail
these two tests.

On hppa, the stack grows upward and the runtime needs a somewhat larger
stack allocation than needed on architectures like x86.

Thanks,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Versions of packages git depends on:
ii  git-man  1:2.25.1-1
ii  libc62.30-1
ii  libcurl3-gnutls  7.68.0-1
ii  liberror-perl0.17029-1
ii  libexpat12.2.9-1
ii  libpcre2-8-0 10.34-7
ii  perl 5.30.0-9
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages git recommends:
ii  ca-certificates  20190110
ii  less 551-1
ii  openssh-client [ssh-client]  1:8.2p1-4
ii  patch2.7.6-6

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-4
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
ii  git-doc   1:2.26.0~rc2-1
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information

Bug#954347: ITP: gnome-pass-search-provider -- GNOME Shell search provider for the pass password manager

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: gnome-pass-search-provider
  Version : 0.0~20191115+da2db41
  Upstream Author : Jonathan Lestrelin 
* URL : https://github.com/jle64/gnome-pass-search-provider
* License : GPL-3
  Programming Lang: Python
  Description : GNOME Shell search provider for the pass password manager

This GNOME search provider integrates the pass utility into GNOME Shell.  It
can search password entries and copy passwords as well as arbitrary fields
(username, pin, etc.) from the GNOME Shell search frontend.  It also
supports the OTP extension (from the pass-extension-otp package).

-BEGIN PGP SIGNATURE-

iQJ+BAEBCgBoFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAl506DYxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxgcbmF0dXJl
c2hhZG93QGRlYmlhbi5vcmcACgkQt5o8FqDE8pZbVQ//Xj7scSXO8kEnG04BIrRg
6ji6ypk1Cwln02pZCc4WDtxoIDSfxWmIIl09RIazWQIT3ZVvqr0r1o+fbI27J1S5
IOQJicOG9f5y+t9go1c2OxX+pTQ8Da6WczqIlPGWke9XN+bYbcp+4vZrxxZ9M1Lt
jNusO2AZUSdVTknRnME+UtalyQqSLG9coUOSOlxIQIPAr+ckXy438py8KHif3Li5
UGIZvf0BADSSa04pAOMPhYvPxN2YFTzirrsvQUHNWeO0E7JHpVqD9mM6WiyIxbvA
Wr6MblGwnbfaUHN5M4LtnnID9/3j58J5JfkiCSEOGZd0qZCh3ZUsewCmkF3MDnkv
u56+vHuNVyRocLgClLDK5C+xugGVvfwSAK8ahqPKQlx/Q2T/RRF6/FIQqWVD5DLk
KNHwkZ9Xnf3p/ryK7CFWgQWBrQEGvGch7nCTRR9bWkVmgrIPUXgYHtf/ZQwnCCN/
En1z4ywcelHEN5ACXQJH4pJnCn+2ChLA9Tz5dTAxdWGN1YYCPi2BZF/+uZ/6Dg5d
QynF1PsdRCbg4cDttk3Ur5Ssp/baOBXWViMI1k8PoNr65vE3f9T/YSG89+HiULvC
jPiRF4nWIFHpbVnp8XOE8NoFnI/SXcDkp7jGcEiMARmnUK+gyRSPTyclYpi0zxlL
L2opoZlvsDxI2wOkFmiTOsQ=
=5BpP
-END PGP SIGNATURE-

Bug#584398: update 03/20/2020

[ktm]

There is estate in your name under our custody.For further details,kindly 
respond immediately.

Bug#954172:

[Damon Lynch]

Hi Tobias,

Coincidentally I noticed that bug myself. The fix is this:

At or about line 228 in setup.py see the two lines starting with 'if
not' that tests for the path:

class raphodo_sdist(sdist):
def run(self):
if not os.path.isdir('build'):
os.mkdir('build')
self.run_command('build_man_page')
self.run_command('build_icons')
self.run_command('build_translations')
sdist.run(self)

Please let me know if it's unclear. The next release will fix this problem.

Best,
Damon

On Fri, Mar 20, 2020 at 11:23 AM Dr. Tobias Quathamer  wrote:
>
> Am 18.03.20 um 05:29 schrieb Damon Lynch:
> > Sorry, I didn't notice that there is a bug in the setup.py file:
> >
> > The end of line 268 is missing a comma. Lines 268 & 269 should be:
> >
> > 'PyGObject',
> > 'PyQt5',
> >
> > I have no idea if this bug in setup.py actually pops up in the Debian
> > build process (I never noticed it when building it). If it does,
> > please let me know and I will make a new release with the bug fix.
> >
> > Damon
>
> Hi Damon,
>
> thanks for filing this bug. I've prepared a new package with the latest
> release, but unfortunately, if fails to build. It has nothing to do with
> the bug you've mentioned above, I've fixed that locally.
>
> The build process stops at the stage "build_man_page"
> (error: [Errno 2] No such file or directory: 'build/doc'),
> I've attached the build log. I have no idea right now what causes the
> error, if you're able to give a hint, please do.
>
> Regards,
> Tobias



-- 
http://www.damonlynch.net

Bug#954346: libcgal-dev: does not depend on the runtime library

[Pierre Gruet]

Package: libcgal-dev
Version: 5.0.2-3
Severity: normal

Dear Maintainer,

According to 8.5 in Debian Policy, this development package should depend on 
the runtime package, as was the case e.g. in version 4.13-1. Else, packages 
depending on libcgal-dev cannot build. This is the case for rheolef, for 
instance.
In current version, dependency holds only for architectures x32 and powerpcspe.

Moreover, it would be suitable (8.4 in Debian Policy) that the development 
package includes a symlink for the shared library libCGAL without a version 
number. This symlink is needed by ld when compiling binaries using the library.

Thanks for reading,

Cheers,
Pierre

Bug#954341: lintian: What's going on with "field-too-long Installed-Build-Depends"?

[Felix Lechner]

Hi,

On Fri, Mar 20, 2020 at 8:03 AM Mattia Rizzolo  wrote:
>
> field-too-long was added to prevent silliness in the archive.  As such, it 
> only makes sense for binary control fields and .dsc, nothing else.

Why should fields in buildinfo and changes files be treated
differently from fields elsewhere?

> ie. "sub binary" → "sub always" ?

I could have used 'sub installable' to examine only deb and udeb, but
I think it makes sense to examine fields everywhere. Fields that are
allowed to be long can be exempt.

The broader issue of duplicate tags across group components, which is
related to the true issue here, will be addressed when tags are
filtered and prioritized for printing. At that point, tags that point
to the origin of something will suppress tags that merely received a
value by copying.

> E: pkg-perl-tools buildinfo: field-too-long Installed-Build-Depends (11190 
> chars > 5000)

I will disable the tag for this particular buildinfo field in the near future.

Kind regards

Felix Lechner

Bug#954345: grisbi: Save (Ctrl+S) still saves even when escaping confirmation dialog

[Roberto C. Sanchez]

Package: grisbi
Version: 1.2.2-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It seems that when choosing "Save" (for example, with Ctrl+S) that the
presented dialog does not function correctly.  Speceifically, the dialog
contains two options: "Cancel" and "Save".  Pressing the "Escape" key
seems like it should be equivalent to a "Cancel" selection.  However,
when I attempt this (pressing "Escape" to not have the changes saved),
Grisbi still saves the changes.  This seems to make it not possible to
discard changes in the expected way.

Regards,

- -Roberto

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

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

Versions of packages grisbi depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  grisbi-common1.2.2-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgoffice-0.10-10   0.10.44-1
ii  libgtk-3-0   3.24.5-1
ii  libofx7  1:0.9.14-1+deb10u1
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libssl1.11.1.1d-0+deb10u2
ii  libxml2  2.9.4+dfsg1-7+b3
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

grisbi recommends no packages.

Versions of packages grisbi suggests:
ii  chromium [www-browser]  79.0.3945.130-1~deb10u1
ii  elinks [www-browser]0.13~20190125-3
ii  firefox-esr [www-browser]   68.5.0esr-1~deb10u1
ii  google-chrome-stable [www-browser]  80.0.3987.132-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAl504+cACgkQldFmTdL1
kUK1Wg//Yb1OaVCjpXicZL339ovBo2CroWZvT0opC+/fLWRKPAzXVNVvkdT1fs3C
L48lBRp9UyV0a7QskYDBZiqkNPtW4W+7KXaGro4dBt2gZGNxRCQTJyrGiv5MmAKh
2CGt/1iSmw6G3GkitQIl+txybrN75t1zxngz+gT8RpISvN5AIFmxXB/SgRZD2Z73
V+uexUfidXBvMxk/FzO7DXv2QMX0brY0OG+7mOiTifGMIr558H0K3Nbpwar9IFin
G5czpu9av14nmo/6RAaT6vxppb8VAAgQ2jorxMMTy7rAQK/7x/m6v07GieJ3Mn/R
Gq76L0WYPoRksWXz52sVaa9AsB3GwykUGvCDxt8alTx9rh4Kcustc/HAHz6qw6L8
mwhA5hYnV/5/Y5MqtDka2NDZBWO2R0UesuGNLmuTH6ZbUZARrx9Ev094R+7ex/sl
FKGxTC7Z2xaXBEvVGoq+lBxY94Q96GEqCdubTdgy+7k1xUhWY3sIGzCIJT0GicXh
so4+2EYj0pB5B8PgS9XLO0OvQ55kWpMe3f6jmBBFjNfBrX2OApZsJldPDtxAPGjR
qjsNjhBbhK8nYyPw9dMhhsiFDY4fjd2Ig87AoBHCKLRnEjVAagyUdTOnnraFAGsC
wmUf6rDCEGwpY02Mvq7VsACUcgfHgnuMBmqYy31q6Zd+dtlYrFI=
=GMq3
-END PGP SIGNATURE-

Bug#952845: transition: proj

[Emilio Pozuelo Monfort]

On 20/03/2020 14:14, Sebastiaan Couwenberg wrote:
> On 3/18/20 8:21 PM, Emilio Pozuelo Monfort wrote:
>> On 18/03/2020 20:08, Sebastiaan Couwenberg wrote:
>>> Please also binNMU the affected packages in experimental:
>>>
>>>  Dependency level 1
>>>
>>>   * gnudatalanguage  (1.0.0~rc.1+dfsg-3)
>>>   * postgis  (3.1.0~alpha1+dfsg-1~exp2)
>>>   * python-cartopy   (0.18.0~b1+dfsg-1~exp2)
>>>   * spatialite   (5.0.0~beta0-1~exp4)
>>
>> Done those for now.
> 
> It's going to take a while for spatialite to build on all arm* & mips*
> architectures in experimental.
> 
> Can you schedule the binNMUs for spatialite-tools & spatialite-gui in
> experimental with an extra depends on spatialite 5.0.0~beta0-1~exp4+b1?

Scheduled.

Emilio

Bug#954315: rastertopwg segfault

[Bernhard Übelacker]

Hello Till,
I am not the initial reporter of the issue and I cannot reproduce it,
therefore cannot test the suggested change.
Just tried to share my results.

Kind regards,
Bernhard

Bug#954172:

[Dr. Tobias Quathamer]

Am 18.03.20 um 05:29 schrieb Damon Lynch:
> Sorry, I didn't notice that there is a bug in the setup.py file:
> 
> The end of line 268 is missing a comma. Lines 268 & 269 should be:
> 
> 'PyGObject',
> 'PyQt5',
> 
> I have no idea if this bug in setup.py actually pops up in the Debian
> build process (I never noticed it when building it). If it does,
> please let me know and I will make a new release with the bug fix.
> 
> Damon

Hi Damon,

thanks for filing this bug. I've prepared a new package with the latest
release, but unfortunately, if fails to build. It has nothing to do with
the bug you've mentioned above, I've fixed that locally.

The build process stops at the stage "build_man_page"
(error: [Errno 2] No such file or directory: 'build/doc'),
I've attached the build log. I have no idea right now what causes the
error, if you're able to give a hint, please do.

Regards,
Tobias
dpkg-checkbuilddeps: error: Unmet build dependencies: python3-all 
python3-mediainfodll
W: Unmet build-dependency in source
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 11-no-version-check.patch
dpkg-source: info: applying 20-fix-syntax-error-in-setup.patch
dh clean --with python3 --buildsystem=pybuild
   debian/rules override_dh_auto_clean
make[1]: Entering directory 
'/home/toddy/debian/salsa/rapid-photo-downloader/rapid-photo-downloader'
rm -f rapid-photo-downloader.1
rm -f analyze-pv-structure.1
rm -rf build/
dh_auto_clean
I: pybuild base:217: python3.8 setup.py clean 
running clean
removing 
'/home/toddy/debian/salsa/rapid-photo-downloader/rapid-photo-downloader/.pybuild/cpython3_3.8/build'
 (and everything under it)
'build/bdist.linux-amd64' does not exist -- can't clean it
'build/scripts-3.8' does not exist -- can't clean it
I: pybuild base:217: python3.7 setup.py clean 
running clean
removing 
'/home/toddy/debian/salsa/rapid-photo-downloader/rapid-photo-downloader/.pybuild/cpython3_3.7/build'
 (and everything under it)
'build/bdist.linux-amd64' does not exist -- can't clean it
'build/scripts-3.7' does not exist -- can't clean it
make[1]: Leaving directory 
'/home/toddy/debian/salsa/rapid-photo-downloader/rapid-photo-downloader'
   dh_autoreconf_clean -O--buildsystem=pybuild
   dh_clean -O--buildsystem=pybuild
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building rapid-photo-downloader using existing 
./rapid-photo-downloader_0.9.19.orig.tar.gz
dpkg-source: info: building rapid-photo-downloader using existing 
./rapid-photo-downloader_0.9.19.orig.tar.gz.asc
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building rapid-photo-downloader in 
rapid-photo-downloader_0.9.19-1.debian.tar.xz
dpkg-source: info: building rapid-photo-downloader in 
rapid-photo-downloader_0.9.19-1.dsc
I: Generated dsc will be overwritten by build result; not generating 
changes file
dpkg-source: info: unapplying 20-fix-syntax-error-in-setup.patch
dpkg-source: info: unapplying 11-no-version-check.patch
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.32870
I: forking: cp -al /var/cache/pbuilder/base-sid-amd64.cow 
/var/cache/pbuilder/build/cow.32870
I: removed stale ilistfile /var/cache/pbuilder/build/cow.32870/.ilist
I: forking: chroot /var/cache/pbuilder/build/cow.32870 
cowdancer-ilistcreate /.ilist 'find . -xdev -path ./home -prune -o \( \( -type 
l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ''
I: Invoking pbuilder
I: forking: pbuilder build --debbuildopts  --debbuildopts  
--source-only-changes --buildplace /var/cache/pbuilder/build/cow.32870 
--buildresult /home/toddy/debian/salsa/rapid-photo-downloader --mirror 
http://deb.debian.org/debian/ --architecture amd64 --distribution sid 
--no-targz --internal-chrootexec 'chroot /var/cache/pbuilder/build/cow.32870 
cow-shell' 
/home/toddy/debian/salsa/rapid-photo-downloader/rapid-photo-downloader_0.9.19-1.dsc
I: Running in no-targz mode
I: pbuilder: network access will be disabled during build
I: Current time: Fri Mar 20 16:19:51 CET 2020
I: pbuilder-time-stamp: 1584717591
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage 
for details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying 
[/home/toddy/debian/salsa/rapid-photo-downloader/rapid-photo-downloader_0.9.19-1.dsc]
I: copying 
[/home/toddy/debian/salsa/rapid-photo-downloader/rapid-photo-downloader_0.9.19.orig.tar.gz]
I: copying 

Bug#954315: rastertopwg segfault

[Till Kamppeter]

First, this is definitely a CUPS upstream bug, so please report it on 
the CUPS GitHub, also supplying all the information which you have 
gathered and attaching the files which I had asked for.


https://github.com/apple/cups/issues/

Probably it can be solved by adding a simple NULL check.

At line 273 of rastertopwg.c replace

  if (pwg_media)
strlcpy(outheader.cupsPageSizeName, pwg_media->pwg,
sizeof(outheader.cupsPageSizeName));

by

  if (pwg_media && pwg_media->pwg)
strlcpy(outheader.cupsPageSizeName, pwg_media->pwg,
sizeof(outheader.cupsPageSizeName));

Please try it if you are familiar with source code and compiling. Tell 
your result here and also in the upstream bug you are reporting.


   Till

Bug#942910: automake-1.15: Python2 removal in sid/bullseye

[Scott Kitterman]

On Tue, 17 Mar 2020 17:34:06 -0400 Scott Kitterman  
wrote:
...
> As I mentioned in the automake-1.16 bug, these are the last two packages 
that 
> use python-virutalenv, so I'd really like to see them updated to unblock 
other 
> work.
> 
> Thanks.
> 
> Scott K

It's now become clear that due to other changes in the python ecosystem in 
Debian, python-virtualenv has to go sooner rather than later (once the cruft 
python-pip is removed it will stop working).  It's tests are already failing.

As a result, I'm bumping this to serious because it needs to be resolved ~now.  
Please let me know if you don't want an NMU.

Scott K

Bug#942928: automake-1.16: Python2 removal in sid/bullseye

[Scott Kitterman]

On Tue, 17 Mar 2020 17:24:25 -0400 Scott Kitterman  
wrote:
...> Automake-1.15 and automake-1.16 are the last two packages using python-
> virtualenv in Debian Testing.  We would like to move forward with the 
removal 
> soon as it blocks other work.  As a result, I'm going to bump this bug to 
> important.
> 
> Please see the attached patch.  I've run the autopkgtest using the attached 
> and it passes.  If you would prefer me to NMU to save you the near-term 
effort, 
> please let me know.
> 
> Scott K

It's now become clear that due to other changes in the python ecosystem in 
Debian, python-virtualenv has to go sooner rather than later (once the cruft 
python-pip is removed it will stop working).  It's tests are already failing.

As a result, I'm bumping this to serious because it needs to be resolved ~now.  
Please let me know if you don't want an NMU.

Scott K

Bug#954341: lintian: What's going on with "field-too-long Installed-Build-Depends"?

[Chris Lamb]

Hi all,

> Totally lintian is wrong here, imho

I think this was a regression in:

  
https://salsa.debian.org/lintian/lintian/commit/14fa5a80bbbf9e8b691bd9b61382d15b33e98b3d

ie. "sub binary" → "sub always" ?


Best wishes,

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

Bug#954341: lintian: What's going on with "field-too-long Installed-Build-Depends"?

[Mattia Rizzolo]

Totally lintian is wrong here, imho.

field-too-long was added to prevent silliness in the archive.  As such, it
only makes sense for binary control fields and .dsc, nothing else.

On Fri, 20 Mar 2020, 3:21 pm gregor herrmann,  wrote:

> Package: lintian
> Version: 2.58.0
> Severity: minor
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> With lintian 2.58.0 I got, for the first time, this error:
>
> E: pkg-perl-tools buildinfo: field-too-long Installed-Build-Depends (11190
> chars > 5000)
>
> I have no idea what to do with this information, and I've never seen
> this tag before. Either lintian has changed and is right, then Some
> Other Tool™ needs a fix, or lintian has changed and is wrong, or
> something else :)
>
>
> Cheers,
> gregor
>
>
> For reference, the .buildinfo file has:
>
> Installed-Build-Depends:
>  autoconf (= 2.69-11.1),
>  automake (= 1:1.16.1-4),
>  autopoint (= 0.19.8.1-10),
>  autotools-dev (= 20180224.1),
>  base-files (= 11),
>  base-passwd (= 3.5.47),
>  bash (= 5.0-6),
>  binutils (= 2.34-5),
>  binutils-common (= 2.34-5),
>  binutils-x86-64-linux-gnu (= 2.34-5),
>  bsdmainutils (= 11.1.2+b1),
>  bsdutils (= 1:2.34-0.1),
>  build-essential (= 12.8),
>  bzip2 (= 1.0.8-2),
>  ca-certificates (= 20190110),
>  coreutils (= 8.30-3+b1),
>  cpp (= 4:9.2.1-3.1),
>  cpp-9 (= 9.3.0-3),
>  dash (= 0.5.10.2-6),
>  debconf (= 1.5.73),
>  debhelper (= 12.9),
>  debianutils (= 4.9.1),
>  dh-autoreconf (= 19),
>  dh-strip-nondeterminism (= 1.6.3-2),
>  dictionaries-common (= 1.28.1),
>  diffstat (= 1.63-1),
>  diffutils (= 1:3.7-3),
>  dpkg (= 1.19.7),
>  dpkg-dev (= 1.19.7),
>  dwz (= 0.13-5),
>  emacsen-common (= 3.0.4),
>  fdisk (= 2.34-0.1),
>  file (= 1:5.38-4),
>  findutils (= 4.7.0-1),
>  g++ (= 4:9.2.1-3.1),
>  g++-9 (= 9.3.0-3),
>  gcc (= 4:9.2.1-3.1),
>  gcc-10-base (= 10-20200312-2),
>  gcc-9 (= 9.3.0-3),
>  gcc-9-base (= 9.3.0-3),
>  gettext (= 0.19.8.1-10),
>  gettext-base (= 0.19.8.1-10),
>  git (= 1:2.26.0~rc2-1),
>  git-man (= 1:2.26.0~rc2-1),
>  gpg (= 2.2.19-3),
>  gpgconf (= 2.2.19-3),
>  grep (= 3.4-1),
>  groff-base (= 1.22.4-4),
>  gzip (= 1.10-2),
>  hostname (= 3.23),
>  iamerican (= 3.4.00-8),
>  ienglish-common (= 3.4.00-8),
>  init-system-helpers (= 1.57),
>  intltool-debian (= 0.35.0+20060710.5),
>  ispell (= 3.4.00-8),
>  libacl1 (= 2.2.53-6),
>  libalgorithm-c3-perl (= 0.10-1),
>  libalgorithm-diff-perl (= 1.19.03-2),
>  libapt-pkg-perl (= 0.1.36+b3),
>  libapt-pkg6.0 (= 2.0.0),
>  libarchive-zip-perl (= 1.68-1),
>  libasan5 (= 9.3.0-3),
>  libassuan0 (= 2.5.3-7),
>  libatomic1 (= 10-20200312-2),
>  libattr1 (= 1:2.4.48-5),
>  libaudit-common (= 1:2.8.5-2),
>  libaudit1 (= 1:2.8.5-2+b1),
>  libb-hooks-endofscope-perl (= 0.24-1),
>  libb-hooks-op-check-perl (= 0.22-1+b2),
>  libbinutils (= 2.34-5),
>  libblkid1 (= 2.34-0.1),
>  libboolean-perl (= 0.46-1),
>  libbrotli1 (= 1.0.7-6),
>  libbsd0 (= 0.10.0-1),
>  libbz2-1.0 (= 1.0.8-2),
>  libc-bin (= 2.30-2),
>  libc-dev-bin (= 2.30-2),
>  libc6 (= 2.30-2),
>  libc6-dev (= 2.30-2),
>  libcache-lru-perl (= 0.04-1),
>  libcap-ng0 (= 0.7.9-2.1+b2),
>  libcapture-tiny-perl (= 0.48-1),
>  libcarp-assert-more-perl (= 1.20-1),
>  libcarp-assert-perl (= 0.21-1),
>  libcc1-0 (= 10-20200312-2),
>  libcgi-pm-perl (= 4.46-1),
>  libclass-c3-perl (= 0.34-1),
>  libclass-data-inheritable-perl (= 0.08-3),
>  libclass-inspector-perl (= 1.36-1),
>  libclass-method-modifiers-perl (= 2.13-1),
>  libclass-singleton-perl (= 1.5-1),
>  libclass-tiny-perl (= 1.006-1),
>  libclass-xsaccessor-perl (= 1.19-3+b3),
>  libclone-choose-perl (= 0.010-1),
>  libclone-perl (= 0.43-2),
>  libcom-err2 (= 1.45.5-2),
>  libcommon-sense-perl (= 3.74-2+b8),
>  libconfig-model-perl (= 2.138-2),
>  libconst-fast-perl (= 0.014-1),
>  libcontextual-return-perl (= 0.004014-2),
>  libconvert-binhex-perl (= 1.125-1),
>  libcroco3 (= 0.6.13-1),
>  libcrypt-dev (= 1:4.4.15-1),
>  libcrypt1 (= 1:4.4.15-1),
>  libctf-nobfd0 (= 2.34-5),
>  libctf0 (= 2.34-5),
>  libcurl3-gnutls (= 7.68.0-1),
>  libdata-optlist-perl (= 0.110-1),
>  libdatetime-format-dateparse-perl (= 0.05-2),
>  libdatetime-locale-perl (= 1:1.25-1),
>  libdatetime-perl (= 2:1.52-1),
>  libdatetime-timezone-perl (= 1:2.38-1+2019c),
>  libdb5.3 (= 5.3.28+dfsg1-0.6),
>  libdebconfclient0 (= 0.251),
>  libdebhelper-perl (= 12.9),
>  libdevel-callchecker-perl (= 0.008-1+b1),
>  libdevel-size-perl (= 0.83-1+b1),
>  libdevel-stacktrace-perl (= 2.0400-1),
>  libdigest-hmac-perl (= 1.03+dfsg-2),
>  libdpkg-perl (= 1.19.7),
>  libdynaloader-functions-perl (= 0.003-1),
>  libelf1 (= 0.176-1.1),
>  libemail-date-format-perl (= 1.005-1),
>  libemail-valid-perl (= 1.202-1),
>  libencode-locale-perl (= 1.05-1),
>  liberror-perl (= 0.17029-1),
>  libeval-closure-perl (= 0.14-1),
>  libexception-class-perl (= 1.44-1),
>  libexpat1 (= 2.2.9-1),
>  libexporter-tiny-perl (= 1.002001-1),
>  libfcgi-perl (= 0.79-1),
>  libfdisk1 (= 2.34-0.1),
>  libffi7 (= 3.3-3),
>  libfile-basedir-perl (= 0.08-1),
>  

Bug#954344: debian installer don't sets PermitRootLogin to yes in ssh config when no regular user are created

[Илья Пащук]

Package: d-i.debian.org

Version: 10


when I install debian without creating a regular user, only with root, 
and check "ssh server" in software list, the PermitRootLogin option in 
sshd configs are not enabled automaticly, so there are no ways to 
connect to the installed system, this is especially important in 
headless installations.


I think that the installer in sutch situations should enable this option 
by default or prompt about that because it can be very important in some 
scenarios.

Bug#954343: Error message 'Unable to parse package file (1)' unhelpful

[Julian Andres Klode]

On Fri, Mar 20, 2020 at 03:41:06PM +0100, Andras Korn wrote:
> Package: apt
> Version: 2.0.0
> Severity: normal
> 
> Hi,
> 
> with the sources.list entry:
> 
> deb http://winswitch.org/beta/ buster main
> 
> apt-get as of 2.0 update prints the unhelpful error message:
> 
> E: Unable to parse package file  (1)
> 
> apt 1.8.4 has no problem with this repository.
> 
> I could only find out which sources.list entry was causing the issue by way 
> of successive elimination.
> 
> I would suggest the following:
> 
> 1. identify the type of file in the message (e.g. Packages file, Release 
> file, whatever); 'package file' is vague.

It's supposed to print the path, but apparently the path is empty.


> 
> 2. in the message, identify the sources.list entry the problematic file is 
> related to.
> 
> 3. the message should say why the file in question could not be parsed; at 
> the very least, print the number of the line where the problem was 
> encountered.

Those two are not going to happen. Well, 3 might be possible at a later
time, but we don't have information for 2.

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

Bug#954343: Error message 'Unable to parse package file (1)' unhelpful

[Andras Korn]

Package: apt
Version: 2.0.0
Severity: normal

Hi,

with the sources.list entry:

deb http://winswitch.org/beta/ buster main

apt-get as of 2.0 update prints the unhelpful error message:

E: Unable to parse package file  (1)

apt 1.8.4 has no problem with this repository.

I could only find out which sources.list entry was causing the issue by way of 
successive elimination.

I would suggest the following:

1. identify the type of file in the message (e.g. Packages file, Release file, 
whatever); 'package file' is vague.

2. in the message, identify the sources.list entry the problematic file is 
related to.

3. the message should say why the file in question could not be parsed; at the 
very least, print the number of the line where the problem was encountered.

Thanks!

András

-- 
There will be a rain dance Friday, weather permitting.

-- System Information:
Debian Release: bullseye/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)

Bug#954342: aqbanking-tools: README.aqhbci-tool missing

[Jan Braun]

Package: aqbanking-tools
Version: 6.0.1-2
Severity: normal

Dear Maintainer,

The manpage for aqhbci-tool4(1) mentions:
| The README file[1] contains the README which describes some setup
| scenarios in detail. [...]
| 1. The README file
|file:///usr/share/doc/aqbanking-tools/README.aqhbci-tool.gz

That file doesn't exist.

I couldn't find detailed setup instructions in the /usr/share/doc/*
folders of the various related packages either.

Please ship that file, if it still exists upstream (I didn't check).

Otherwise, or additionally, you might want to mention
https://www.aquamaniac.de/rdm/projects/aqbanking/wiki
( or plain https://www.aquamaniac.de/ )
as a source for further info.

Thank you for maintaining aqbanking.
regards,
Jan


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages aqbanking-tools depends on:
ii  libaqbanking44   6.0.1-2
ii  libc62.30-2
ii  libgwenhywfar79  5.2.0-2

aqbanking-tools recommends no packages.

Versions of packages aqbanking-tools suggests:
ii  gwenhywfar-tools  5.2.0-2

-- no debconf information


signature.asc
Description: PGP signature

Bug#954341: lintian: What's going on with "field-too-long Installed-Build-Depends"?

[gregor herrmann]

Package: lintian
Version: 2.58.0
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

With lintian 2.58.0 I got, for the first time, this error:

E: pkg-perl-tools buildinfo: field-too-long Installed-Build-Depends (11190 
chars > 5000)

I have no idea what to do with this information, and I've never seen
this tag before. Either lintian has changed and is right, then Some
Other Tool™ needs a fix, or lintian has changed and is wrong, or
something else :)


Cheers,
gregor


For reference, the .buildinfo file has:

Installed-Build-Depends:
 autoconf (= 2.69-11.1),
 automake (= 1:1.16.1-4),
 autopoint (= 0.19.8.1-10),
 autotools-dev (= 20180224.1),
 base-files (= 11),
 base-passwd (= 3.5.47),
 bash (= 5.0-6),
 binutils (= 2.34-5),
 binutils-common (= 2.34-5),
 binutils-x86-64-linux-gnu (= 2.34-5),
 bsdmainutils (= 11.1.2+b1),
 bsdutils (= 1:2.34-0.1),
 build-essential (= 12.8),
 bzip2 (= 1.0.8-2),
 ca-certificates (= 20190110),
 coreutils (= 8.30-3+b1),
 cpp (= 4:9.2.1-3.1),
 cpp-9 (= 9.3.0-3),
 dash (= 0.5.10.2-6),
 debconf (= 1.5.73),
 debhelper (= 12.9),
 debianutils (= 4.9.1),
 dh-autoreconf (= 19),
 dh-strip-nondeterminism (= 1.6.3-2),
 dictionaries-common (= 1.28.1),
 diffstat (= 1.63-1),
 diffutils (= 1:3.7-3),
 dpkg (= 1.19.7),
 dpkg-dev (= 1.19.7),
 dwz (= 0.13-5),
 emacsen-common (= 3.0.4),
 fdisk (= 2.34-0.1),
 file (= 1:5.38-4),
 findutils (= 4.7.0-1),
 g++ (= 4:9.2.1-3.1),
 g++-9 (= 9.3.0-3),
 gcc (= 4:9.2.1-3.1),
 gcc-10-base (= 10-20200312-2),
 gcc-9 (= 9.3.0-3),
 gcc-9-base (= 9.3.0-3),
 gettext (= 0.19.8.1-10),
 gettext-base (= 0.19.8.1-10),
 git (= 1:2.26.0~rc2-1),
 git-man (= 1:2.26.0~rc2-1),
 gpg (= 2.2.19-3),
 gpgconf (= 2.2.19-3),
 grep (= 3.4-1),
 groff-base (= 1.22.4-4),
 gzip (= 1.10-2),
 hostname (= 3.23),
 iamerican (= 3.4.00-8),
 ienglish-common (= 3.4.00-8),
 init-system-helpers (= 1.57),
 intltool-debian (= 0.35.0+20060710.5),
 ispell (= 3.4.00-8),
 libacl1 (= 2.2.53-6),
 libalgorithm-c3-perl (= 0.10-1),
 libalgorithm-diff-perl (= 1.19.03-2),
 libapt-pkg-perl (= 0.1.36+b3),
 libapt-pkg6.0 (= 2.0.0),
 libarchive-zip-perl (= 1.68-1),
 libasan5 (= 9.3.0-3),
 libassuan0 (= 2.5.3-7),
 libatomic1 (= 10-20200312-2),
 libattr1 (= 1:2.4.48-5),
 libaudit-common (= 1:2.8.5-2),
 libaudit1 (= 1:2.8.5-2+b1),
 libb-hooks-endofscope-perl (= 0.24-1),
 libb-hooks-op-check-perl (= 0.22-1+b2),
 libbinutils (= 2.34-5),
 libblkid1 (= 2.34-0.1),
 libboolean-perl (= 0.46-1),
 libbrotli1 (= 1.0.7-6),
 libbsd0 (= 0.10.0-1),
 libbz2-1.0 (= 1.0.8-2),
 libc-bin (= 2.30-2),
 libc-dev-bin (= 2.30-2),
 libc6 (= 2.30-2),
 libc6-dev (= 2.30-2),
 libcache-lru-perl (= 0.04-1),
 libcap-ng0 (= 0.7.9-2.1+b2),
 libcapture-tiny-perl (= 0.48-1),
 libcarp-assert-more-perl (= 1.20-1),
 libcarp-assert-perl (= 0.21-1),
 libcc1-0 (= 10-20200312-2),
 libcgi-pm-perl (= 4.46-1),
 libclass-c3-perl (= 0.34-1),
 libclass-data-inheritable-perl (= 0.08-3),
 libclass-inspector-perl (= 1.36-1),
 libclass-method-modifiers-perl (= 2.13-1),
 libclass-singleton-perl (= 1.5-1),
 libclass-tiny-perl (= 1.006-1),
 libclass-xsaccessor-perl (= 1.19-3+b3),
 libclone-choose-perl (= 0.010-1),
 libclone-perl (= 0.43-2),
 libcom-err2 (= 1.45.5-2),
 libcommon-sense-perl (= 3.74-2+b8),
 libconfig-model-perl (= 2.138-2),
 libconst-fast-perl (= 0.014-1),
 libcontextual-return-perl (= 0.004014-2),
 libconvert-binhex-perl (= 1.125-1),
 libcroco3 (= 0.6.13-1),
 libcrypt-dev (= 1:4.4.15-1),
 libcrypt1 (= 1:4.4.15-1),
 libctf-nobfd0 (= 2.34-5),
 libctf0 (= 2.34-5),
 libcurl3-gnutls (= 7.68.0-1),
 libdata-optlist-perl (= 0.110-1),
 libdatetime-format-dateparse-perl (= 0.05-2),
 libdatetime-locale-perl (= 1:1.25-1),
 libdatetime-perl (= 2:1.52-1),
 libdatetime-timezone-perl (= 1:2.38-1+2019c),
 libdb5.3 (= 5.3.28+dfsg1-0.6),
 libdebconfclient0 (= 0.251),
 libdebhelper-perl (= 12.9),
 libdevel-callchecker-perl (= 0.008-1+b1),
 libdevel-size-perl (= 0.83-1+b1),
 libdevel-stacktrace-perl (= 2.0400-1),
 libdigest-hmac-perl (= 1.03+dfsg-2),
 libdpkg-perl (= 1.19.7),
 libdynaloader-functions-perl (= 0.003-1),
 libelf1 (= 0.176-1.1),
 libemail-date-format-perl (= 1.005-1),
 libemail-valid-perl (= 1.202-1),
 libencode-locale-perl (= 1.05-1),
 liberror-perl (= 0.17029-1),
 libeval-closure-perl (= 0.14-1),
 libexception-class-perl (= 1.44-1),
 libexpat1 (= 2.2.9-1),
 libexporter-tiny-perl (= 1.002001-1),
 libfcgi-perl (= 0.79-1),
 libfdisk1 (= 2.34-0.1),
 libffi7 (= 3.3-3),
 libfile-basedir-perl (= 0.08-1),
 libfile-find-rule-perl (= 0.34-1),
 libfile-homedir-perl (= 1.004-1),
 libfile-listing-perl (= 6.04-1),
 libfile-sharedir-perl (= 1.116-2),
 libfile-slurp-perl (= .29-1),
 libfile-stripnondeterminism-perl (= 1.6.3-2),
 libfile-which-perl (= 1.23-1),
 libfont-ttf-perl (= 1.06-1),
 libfuture-perl (= 0.43-1),
 libgcc-9-dev (= 9.3.0-3),
 libgcc-s1 (= 10-20200312-2),
 libgcc1 (= 1:10-20200312-2),
 libgcrypt20 (= 1.8.5-5),
 libgdbm-compat4 (= 1.18.1-5),
 libgdbm6 (= 1.18.1-5),
 libgit-repository-perl (= 1.324-1),
 libgit-version-compare-perl (= 1.004-1),
 

Bug#954315: rastertopwg segfault

[Bernhard Übelacker]

Hello,
the stack trace should look like this with line numbers, if it helps:

0x7...671 in __strlen_avx2 at 
../sysdeps/x86_64/multiarch/strlen-avx2.S:65
0x7...2f4 in _cups_strlcpy at string.c:739
0x5...a31 in main at rastertopwg.c:274
0x7...e09 in __libc_start_main at ../csu/libc-start.c:308
0x5...1a4 <_start+36>

https://sources.debian.org/src/cups/2.3.1-11/cups/string.c/#L739
https://sources.debian.org/src/cups/2.3.1-11/filter/rastertopwg.c/#L274

Kind regards,
Bernhard


# From submitter:
Stack trace of thread 31898:
#0  0x7f7a61751671 
__strlen_avx2 (libc.so.6 + 0x15e671)
#1  0x7f7a618032f9 
_cups_strlcpy (libcups.so.2 + 0x4d2f9)
#2  0x55a058ca1a36 main 
(rastertopwg + 0x1a36)
#3  0x7f7a61619e0b 
__libc_start_main (libc.so.6 + 0x26e0b)
#4  0x55a058ca21aa _start 
(rastertopwg + 0x21aa)


###


# Unstable amd64 qemu VM 2020-03-20


apt update
apt dist-upgrade


apt install systemd-coredump gdb cups cups-dbgsym libcups2-dbgsym

reboot



# dpkg -l | grep cups
ii  cups  2.3.1-11   amd64
Common UNIX Printing System(tm) - PPD/driver support, web interface
ii  cups-browsed  1.27.2-1   amd64
OpenPrinting CUPS Filters - cups-browsed
ii  cups-client   2.3.1-11   amd64
Common UNIX Printing System(tm) - client programs (SysV)
ii  cups-common   2.3.1-11   all  
Common UNIX Printing System(tm) - common files
ii  cups-core-drivers 2.3.1-11   amd64
Common UNIX Printing System(tm) - driverless printing
ii  cups-daemon   2.3.1-11   amd64
Common UNIX Printing System(tm) - daemon
ii  cups-dbgsym   2.3.1-11   amd64
debug symbols for cups
ii  cups-filters  1.27.2-1   amd64
OpenPrinting CUPS Filters - Main Package
ii  cups-filters-core-drivers 1.27.2-1   amd64
OpenPrinting CUPS Filters - Driverless printing
ii  cups-ipp-utils2.3.1-11   amd64
Common UNIX Printing System(tm) - IPP developer/admin utilities
ii  cups-ppdc 2.3.1-11   amd64
Common UNIX Printing System(tm) - PPD manipulation utilities
ii  cups-server-common2.3.1-11   all  
Common UNIX Printing System(tm) - server common files
ii  libcups2:amd642.3.1-11   amd64
Common UNIX Printing System(tm) - Core library
ii  libcups2-dbgsym:amd64 2.3.1-11   amd64
debug symbols for libcups2
ii  libcupsfilters1:amd64 1.27.2-1   amd64
OpenPrinting CUPS Filters - Shared library




gdb -q

set width 0
set pagination off
file /usr/lib/cups/filter/rastertopwg
b main
run
dele 1
generate-core-file /tmp/core
kill
y
q


gdb -q

set width 0
set pagination off
file /usr/lib/cups/filter/rastertopwg
core /tmp/core

disassemble _start
b *0x61a4

disassemble __libc_start_main
b *0x77d8ee09

disassemble main
b *0x5a31

disassemble _cups_strlcpy
b *0x77f782f4

disassemble __strlen_avx2
b *0x77ec6671

info b





0x77ec6671 in __strlen_avx2 at 
../sysdeps/x86_64/multiarch/strlen-avx2.S:65
0x77f782f4 in _cups_strlcpy at string.c:739
0x5a31 in main at rastertopwg.c:274
0x77d8ee09 in __libc_start_main at ../csu/libc-start.c:308
0x61a4 <_start+36>


0x7...671 in __strlen_avx2 at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
0x7...2f4 in _cups_strlcpy at string.c:739
0x5...a31 in main at rastertopwg.c:274
0x7...e09 in __libc_start_main at ../csu/libc-start.c:308
0x5...1a4 <_start+36>




https://sources.debian.org/src/cups/2.3.1-11/cups/string.c/#L739
https://sources.debian.org/src/cups/2.3.1-11/filter/rastertopwg.c/#L274

Bug#947356: realtek-firmware: missing rtl8125a-3.fw

[Sedat Dilek]

Hi,

with linux-image-5.4.0-4-amd64 version 5.4.19-1 from Debian/testing
AMD64 I can confirm this.

I did this to fix it:

root# cd /lib/firmware/rtl_nic
root# wget 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/rtl_nic/rtl8125a-3.fw

NOTE: Might need to do `update-initramfs` for people having the hardware.

For details see commit "rtl_nic: add firmware rtl8125a-3" [1] saying:

This adds firmware rtl8125a-3 for Realtek's 2.5Gbps chip RTL8125.

Thanks.

Regards,
- Sedat -

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/rtl_nic?id=f667c005600bd4fe24a0a439b7a3f3eadcce753a

Bug#954118: munin-plugins-core: apt_all is all broken

[devel]

Hello Cyril,

thank you for your report!


Am Tue, 17 Mar 2020 04:00:18 +0100
schrieb Cyril Brulebois :

> Problem 1: This is not reproducible.
> 
> sub guess_releases() {
> …
> return keys %release_names;
> }
> 
> as the various known suites will not be returned in the same order.
> Switching to “sort keys” fixes this issue.

Good catch! I will do this.


> Problem 2: This doesn't do what it should.
> 
> sub print_state() {
> …
> while (my $line = ) {
> foreach my $release (@releases) {
> my $release_cleaned = clean_fieldname($release);
> # print only lines that are exected for the currently 
> requested releases
> print $line if ($line =~ 
> /^(hold|pending)_$release_cleaned\.(value|extinfo)/);
> last;
> }
> }
> close STATE;
> }
> 
> One could see the “last;” as an optimization: if a line matches, don't
> bother checking the other release. But it's not inside the matching
> conditional! Meaning whatever result the first line gets (match or no
> match), one gets out of the loop…
> 
> Dropping the “last;” fixes this issue. (One could optimize a little by
> using a regular if() form, and putting the “last;” inside.)

Indeed this was fixed and released by upstream meanwhile (commit 9a792a331b).


> Problem 3: This plugin doesn't report security updates!
> 
> # try to determine the currently available distributions by inspecting 
> the repository URLs
> sub guess_releases() {
> open(my $fh, "-|", "apt-get update --print-uris")
> or die("Failed to determine distribution releases via 'apt-get 
> update --print-uris");
> my %release_names;
> my $line;
> while ( ! eof($fh) ) {
> defined( $line = readline $fh ) or die "Failed to read line from 
> output of 'apt-get': $!";
> # example line:
> # 'http://ftp.debian.org/debian/dists/stable/InRelease' 
> ftp.debian.org_debian_dists_stable_InRelease 0
> if ($line =~ m'^.*/dists/([^/]+)/.*$') {
> $release_names{$1} = 1;
> }
> }
> return keys %release_names;
> }
> 
> The m'^.*/dists/([^/]+)/.*$' pattern doesn't allow for distribution
> names with slashes, meaning no luck for buster/updates.
> 
> Switching to m'^.*/dists/(.+)/(?:In)?Release.*$' would fix the suite
> detection, but then the plugin wouldn't work properly anyway:
> 
> E: The value 'buster/updates' is invalid for APT::Default-Release as such 
> a release is not available in the sources

Thank you for your analysis and recommendations.

I verified, that the packages available via "buster/updates" are assigned to
the "buster" distribution. Thus the issue can be solved by removing "/updates"
from distribution names.

I just pushed the corrsponding changes upstream.

Attached you find the three relevant upstream commits (including the fix for
the "last" condition above).
I would be happy, if you could test the attached patches and report back,
whether these work for you.

Thank you!

Cheers,
Lars
commit 435d2c6ca24b253d49323c0b122ad5f7f9869e18
Author: Lars Kruse 
Date:   Fri Mar 20 14:35:31 2020 +0100

Plugin apt_all: enforce stable order of fields

Previously the order of releases (and thus: fields) was random.

Thanks, Cyril Brulebois.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954118

diff --git a/plugins/node.d.linux/apt_all.in b/plugins/node.d.linux/apt_all.in
index fd3c373d..cdfc21fe 100644
--- a/plugins/node.d.linux/apt_all.in
+++ b/plugins/node.d.linux/apt_all.in
@@ -83,7 +83,7 @@ sub guess_releases() {
 $release_names{$1} = 1;
 }
 }
-return keys %release_names;
+return sort keys %release_names;
 }
 
 
commit b8d366dc7c0a89b63a0bc5f288dc46b9c6e1c763
Author: Lars Kruse 
Date:   Fri Mar 20 14:41:30 2020 +0100

Plugin apt_all: include release names with slashes (e.g. buster/updates)

Previously security updates were ignored due to the additional slash in
the release name.

Thanks, Cyril Brulebois.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954118

diff --git a/plugins/node.d.linux/apt_all.in b/plugins/node.d.linux/apt_all.in
index cdfc21fe..fddcfacf 100644
--- a/plugins/node.d.linux/apt_all.in
+++ b/plugins/node.d.linux/apt_all.in
@@ -79,8 +79,12 @@ sub guess_releases() {
 defined( $line = readline $fh ) or die "Failed to read line from output of 'apt-get': $!";
 # example line:
 # 'http://ftp.debian.org/debian/dists/stable/InRelease' ftp.debian.org_debian_dists_stable_InRelease 0
-if ($line =~ m'^.*/dists/([^/]+)/.*$') {
-$release_names{$1} = 1;
+if ($line =~ m#^.*/dists/([^']+)/[^/]+/[^/]+/Packages#) {
+my $release_name = $1;
+# The security updates are named like "buster/updates". The first part (before the
+# slash) 

Bug#954340: debarchiver: gpg now needs extra option for signing the Release file

[Jörgen Hägg]

Package: debarchiver
Version: 0.11.3
Severity: important
Tags: patch

It seems as if gnupg needs an extra option (--pinentry-mode loopback) to
be able to run in batch mode. I discovered this when I upgraded the
archive server from stretch to buster.

/jh


--- /usr/bin/debarchiver.org2020-03-20 14:12:17.0 +0100
+++ /usr/bin/debarchiver2020-03-20 14:13:27.0 +0100
@@ -1301,7 +1301,7 @@
 unlink("$path/Release.gpg");
if ($gpgpassfile) {
cmdaction("cat $gpgpassfile | gpg --batch --no-tty -a -b -s -u 
$gpgkey " .
- "--passphrase-fd 0 -o $path/Release.gpg $path/Release",
+ "--pinentry-mode loopback --passphrase-fd 0 -o 
$path/Release.gpg $path/Release",
  "Sign Release file for $path with key '$gpgkey'",
  3);
}



-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-8-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debarchiver depends on:
ii  adduser3.118
ii  apt-utils  1.8.2
ii  dpkg-dev   1.19.7
ii  opalmod0.2.2

Versions of packages debarchiver recommends:
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1
ii  mailx1:20071201-3
ii  sendmail-bin [mail-transport-agent]  8.15.2-14~deb10u1

Versions of packages debarchiver suggests:
ii  devscripts  2.19.5+deb10u1
ii  gnupg   2.2.19-2~bpo10+1

-- no debconf information

Bug#954338: lintian: Remove some '' annotations

[gregor herrmann]

Source: lintian
Version: 2.58.0
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

lintian fails to build with (DEB_BUILD_OPTIONS=nocheck and)
DEB_BUILD_PROFILES=nocheck because some packages marked as
'' in Build-Depends are actually needed for building.

Trivial patch:

#v+
- --- a/debian/control
+++ b/debian/control
@@ -39,7 +39,7 @@ Build-Depends:
  libdigest-sha-perl ,
  libdpkg-perl ,
  libemail-valid-perl ,
- - libfile-basedir-perl ,
+ libfile-basedir-perl,
  libfile-find-rule-perl ,
  libfont-ttf-perl ,
  libhtml-parser-perl ,
@@ -52,7 +52,7 @@ Build-Depends:
  libmoo-perl ,
  libmoox-aliases-perl ,
  libnamespace-clean-perl ,
- - libpath-tiny-perl ,
+ libpath-tiny-perl,
  libpod-coverage-trustpod-perl ,
  libsereal-decoder-perl ,
  libsereal-encoder-perl ,
#v-

Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl50yUxfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZclRAAh2M99Kw+3cDskOFhJ7dtFFu/8XSfC/U1vcPsqbZTqhE/IorBq7hc1SSQ
+/1TO0viYAIqyfkarZjQdiIYww/eX1xqbuK3Lh4YiLMNxlDHU1CGyJCv6JvNjuYP
fruez74kDS9+NFsooW3g7W11tPPYrrb3Zx0EEC6CQqzECXWdfFD76Z+TqMZ+1sEw
b8JXGBFeWNZOg92ClINFvmvASVb7LpBRoNQOpkB4DEhcLLgABz8gRZ6vwhekz7Db
kMFvs7DmeL5bzXgHGPwBggF/BfpjHYyV4OXfT2fQYGC89WN7PbuqFw7Z4cE6mJVb
/jsF4Isf8CYqLRkZfvBdi8sPZzYnNOYzAP1N7TnezjQRwLq0m2+cb2y7IJs+9ugT
ni6l9NStqt81c2JXaSKrBAsucPnaEdBxQgcWPljxCihRFhNeS5/3spijh4W0j9JI
SUQCAF56qYU3ad9eZV+0WZfrOWNQJTH1aOu0AbIR16zvQffSkrIFtRdpQjIBYd3f
YZOniKadPvoKLcds27t4S/KzMpd0Mx7xYj3URt3lzw8GKskpeTc7xvJKyVH09pDD
NUuba7woNzIqbTm5zVUcG+5M+e91hD441PBpekW8l9EqT4fpP378rOLm3v3xEFpD
xhua8RgPp/LBtwGDjRBX4GSfnEAa65Ys+5vm9+ZTv/wwGYIbeek=
=tvPo
-END PGP SIGNATURE-

Bug#954339: linux-image-5.4.0-0.bpo.3-amd64: snd-usb-audio broken for 06f8:b000 since 4.9.189-3+deb9u2

[Alexander Chalikiopoulos]

Package: src:linux
Version: 5.4.13-1~bpo10+1
Severity: normal

Dear Maintainer,


This week I tried to use a usb-audio card on my new buster system and 
encountered some odd behaviour. The device appears in aplay -L but not in aplay 
-l. The controls are available in amixer/alsamixer, but changing settings does 
not have any effects. The devices does not seem to be available to any other 
programs on the system.

Since the device had worked perfectly for many years on my old system (laptop 
with stretch) I tested it there. On the current stretch kernel (4.9.210-1) it 
exhibits the same behaviour. Luckily I could boot to an older kernel 
(4.9.189-3+deb9u2) and here the device does work properly. It seems there has 
been a regression since this release.

Because current buster is using 4.19+105+deb10u3 I tried switching to the 5.4.x 
kernel from backports to see if there has been a fix, obviously this is not the 
case.

Maybe some specific snd-usb-audio tricks are needed, but I am not aware of 
anything I could try (help here is welcome).


regards,
Alexander


-- Package-specific info:
** Version:
Linux version 5.4.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.4.13-1~bpo10+1 (2020-02-07)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.4.0-0.bpo.3-amd64 
root=UUID=66fda637-590b-4ee8-ac32-21dea91a78f0 ro quiet

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[ 9139.690858] microcode: CPU6: patch_level=0x08701013
[ 9139.693267] Spectre V2 : Update user space SMT mitigation: STIBP always-on
[ 9139.693279] CPU6 is up
[ 9139.693308] smpboot: Booting Node 0 Processor 7 APIC 0x3
[ 9139.693419] microcode: CPU7: patch_level=0x08701013
[ 9139.695805] CPU7 is up
[ 9139.695816] smpboot: Booting Node 0 Processor 8 APIC 0x5
[ 9139.695927] microcode: CPU8: patch_level=0x08701013
[ 9139.698336] CPU8 is up
[ 9139.698347] smpboot: Booting Node 0 Processor 9 APIC 0x9
[ 9139.698485] microcode: CPU9: patch_level=0x08701013
[ 9139.700902] CPU9 is up
[ 9139.700913] smpboot: Booting Node 0 Processor 10 APIC 0xb
[ 9139.701058] microcode: CPU10: patch_level=0x08701013
[ 9139.703485] CPU10 is up
[ 9139.703496] smpboot: Booting Node 0 Processor 11 APIC 0xd
[ 9139.703641] microcode: CPU11: patch_level=0x08701013
[ 9139.706080] CPU11 is up
[ 9139.706810] ACPI: Waking up from system sleep state S3
[ 9139.775893] snd_hda_intel :0b:00.1: spurious response 0x8001:0x0, 
last cmd=0x5f2f06
[ 9139.775894] snd_hda_intel :0b:00.1: spurious response 0x8000:0x0, 
last cmd=0x5f2f06
[ 9139.775895] snd_hda_intel :0b:00.1: spurious response 0x8004:0x0, 
last cmd=0x5f2f06
[ 9139.775896] snd_hda_intel :0b:00.1: spurious response 0x8000:0x0, 
last cmd=0x5f2f06
[ 9139.775896] snd_hda_intel :0b:00.1: spurious response 0x8000:0x0, 
last cmd=0x5f2f06
[ 9139.775897] snd_hda_intel :0b:00.1: spurious response 0x8000:0x0, 
last cmd=0x5f2f06
[ 9139.775897] snd_hda_intel :0b:00.1: spurious response 0x8000:0x0, 
last cmd=0x5f2f06
[ 9139.775898] snd_hda_intel :0b:00.1: spurious response 0x8000:0x0, 
last cmd=0x5f2f06
[ 9139.775899] snd_hda_intel :0b:00.1: spurious response 0x8000:0x0, 
last cmd=0x5f2f06
[ 9139.775899] snd_hda_intel :0b:00.1: spurious response 0x8009:0x0, 
last cmd=0x5f2f06
[ 9139.784945] usb usb1: root hub lost power or was reset
[ 9139.784948] usb usb2: root hub lost power or was reset
[ 9139.785422] serial 00:05: activated
[ 9139.887949] r8169 :09:00.0 enp9s0: Link is Down
[ 9139.958370] nvme nvme1: Shutdown timeout set to 10 seconds
[ 9139.958797] nvme nvme0: Shutdown timeout set to 10 seconds
[ 9139.959145] nvme nvme1: 8/0/0 default/read/poll queues
[ 9139.959457] nvme nvme0: 8/0/0 default/read/poll queues
[ 9140.098022] ata11: SATA link down (SStatus 0 SControl 300)
[ 9140.098023] ata12: SATA link down (SStatus 0 SControl 300)
[ 9140.098031] ata9: SATA link down (SStatus 0 SControl 300)
[ 9140.098056] ata2: SATA link down (SStatus 0 SControl 330)
[ 9140.098080] ata1: SATA link down (SStatus 0 SControl 330)
[ 9140.098090] ata10: SATA link down (SStatus 0 SControl 300)
[ 9140.098101] ata5: SATA link down (SStatus 0 SControl 330)
[ 9140.143922] nvme nvme0: ctrl returned bogus length: 16 for NVME_NIDT_EUI64
[ 9140.144008] nvme nvme1: ctrl returned bogus length: 16 for NVME_NIDT_EUI64
[ 9140.196044] usb 1-4: reset full-speed USB device number 2 using xhci_hcd
[ 9140.493614] usb usb3: root hub lost power or was reset
[ 9140.493616] usb usb4: root hub lost power or was reset
[ 9140.692013] usb 1-7: reset low-speed USB device number 3 using xhci_hcd
[ 9140.824305] ata6: failed to resume link (SControl 0)
[ 9140.824321] ata6: SATA link down (SStatus 0 SControl 0)
[ 9141.332079] usb 1-10: reset low-speed USB device number 4 using xhci_hcd
[ 9141.435905] snd_hda_codec_hdmi hdaudioC0D0: HDMI: invalid ELD data byte 

Bug#954330: GIMP 2 .10 crash

[Bernhard Übelacker]

Hello Valentin,
this looks similar to bug #953794, #953854 or #953880.

Kind regards,
Bernhard

Bug#954315: rastertopwg segfault

[Till Kamppeter]

We need a way to reproduce the bug and also a backtrace with line 
numbers of the source files.


So please attach the PDF input file which leads to the crash. Also 
attach your printer's PPD file, from the /etc/cups/ppd/ directory, named 
by the name of your print queue.


Please also try to reproduce the crash with the "cupsfilter" command:

cupsfilter -p /etc/cups/ppd/QUEUE.ppd -i application/pdf -m 
printer/QUEUE -e FILE.pdf > out


Running only a part of the filter chain you can get the data which is 
fed into rastertopwg:


cupsfilter -p /etc/cups/ppd/QUEUE.ppd -i application/pdf -m 
application/vnd.cups-raster -e FILE.pdf > out.raster


Now you can run rastertopwg isolated:

ulimit -c unlimited
cat out.raster | PPD=/etc/cups/ppd/QUEUE.ppd 
/usr/lib/cups/filter/rastertopwg 1 1 1 1 "" > out


and get a backtrace:

gdb -c core /usr/lib/cups/filter/rastertopwg

Use the "bt" command at the prompt of gdb. Please post the backtrace here.

   Till

Bug#954337: sddm: Users with UID > 999999 not shown

[Matteo Calorio]

Package: sddm
Version: 0.18.1-1
Severity: important

Hello,

In SDDM login page I can't see active directory users that authenticate
through SSSD and that have a high UID (~16).

I set MaximumUid=17, but in "KDE System Settings" I see the
number cut at sixth cypher (17), so I'm wondering if also for the
check it could be the same.

Now I changed SDDM theme and I can login with my AD user manually
putting it into "Other users" page, but it's just a workaround.

Thanks,
  Matteo

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en (charmap=locale: Cannot set LC_MESSAGES to
default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sddm depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.73
ii  libc6   2.30-2
ii  libgcc-s1   10-20200312-2
ii  libpam0g1.3.1-5
ii  libqt5core5a5.12.5+dfsg-9
ii  libqt5dbus5 5.12.5+dfsg-9
ii  libqt5gui5  5.12.5+dfsg-9
ii  libqt5network5  5.12.5+dfsg-9
ii  libqt5qml5  5.12.5-5
ii  libqt5quick55.12.5-5
ii  libstdc++6  10-20200312-2
ii  libsystemd0 244.3-1
ii  libxcb-xkb1 1.13.1-5
ii  libxcb1 1.13.1-5
ii  qml-module-qtquick2 5.12.5-5
ii  x11-common  1:7.7+20
ii  xauth   1:1.0.10-1
ii  xserver-xorg [xserver]  1:7.7+20

Versions of packages sddm recommends:
ii  haveged  1.9.8-4
ii  libpam-systemd   244.3-1
ii  sddm-theme-debian-maui [sddm-theme]  0.18.1-1


Versions of packages sddm suggests:
ii  libpam-kwallet5   5.17.5-2
pn  qtvirtualkeyboard-plugin  

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "it_IT.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
* shared/default-x-display-manager: sddm
  sddm/daemon_name: /usr/bin/sddm


This email and any files transmitted with it are intended solely for the use of 
the individual or entity to whom they are addressed. They are confidential and 
may be subject to legal privilege. If you are not the intended recipient you 
should not peruse, disseminate or distribute this message. If you have received 
this message in error please notify the sender immediately, destroy any copies 
taken and delete the original from your system. Computer viruses can be 
transmitted by email. Recipients should check this message for the presence of 
viruses. ORS srl and members of the ORS Group accept no liability for damage 
caused by any viruses transmitted by this email.

Bug#940536: dhex: hangs on keyboard config screen

[nabijaczleweli]

Hello,

I'm attaching an updated cpu-load patch, based on 0.69-1; it enables
nodelay() for the duration of keyboardsetup() only – keyboard setup
still takes 100% CPU but at least it works, and normal view behaves as
with the current patch.

Regards,
nabijaczleweli
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 dhex (0.69-1) unstable; urgency=medium
 .
   * New upstream version.
   * debian/control: drop Vcs fields.
   * Bump standards version to 4.2.1.
   * debian/copyright: updated years.
   * debian/install and manpages: added.
   * debian/rules: disabled install target.
Author: Gürkan Myczko 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2020-03-20

--- dhex-0.69.orig/main.c
+++ dhex-0.69/main.c
@@ -530,8 +530,12 @@ int main(int argc,char** argv)
output->win=initscr();
pairsinit(output);
noecho();
-   nodelay(output->win,1);
-   if (keyboardsetupreq) keyboardsetup(output,configfile);
+   if (keyboardsetupreq)
+   {
+   nodelay(output->win,1);
+   keyboardsetup(output,configfile);
+   nodelay(output->win,0);
+   }
if (bhexcalc)
{
hexcalc(output,hHexCalc);


signature.asc
Description: PGP signature

Bug#954335: lintian confuses Fortran and Modula-2 modules

[Matthias Klose]

On 3/20/20 2:15 PM, Felix Lechner wrote:
> Hi Matthias,
> 
> On Fri, Mar 20, 2020 at 5:57 AM Matthias Klose  wrote:
>>
>> so please differentiate between Fortran and Modula-2 modules.
> 
> I have had some issues differentiating gfortran modules (#948033). In
> which folders do they usually reside, please?
> 
> Also, why are they not all named md.gz, as in libcoarrays-dev?

CCing Alastair. He's behind the Fortran policies.

Currently Modula-2 modules can only be found in the lib*gm2 packages. Nothing
else is packaged using Modula-2.

Bug#952845: transition: proj

[Sebastiaan Couwenberg]

On 3/18/20 8:21 PM, Emilio Pozuelo Monfort wrote:
> On 18/03/2020 20:08, Sebastiaan Couwenberg wrote:
>> Please also binNMU the affected packages in experimental:
>>
>>  Dependency level 1
>>
>>   * gnudatalanguage  (1.0.0~rc.1+dfsg-3)
>>   * postgis  (3.1.0~alpha1+dfsg-1~exp2)
>>   * python-cartopy   (0.18.0~b1+dfsg-1~exp2)
>>   * spatialite   (5.0.0~beta0-1~exp4)
> 
> Done those for now.

It's going to take a while for spatialite to build on all arm* & mips*
architectures in experimental.

Can you schedule the binNMUs for spatialite-tools & spatialite-gui in
experimental with an extra depends on spatialite 5.0.0~beta0-1~exp4+b1?

Kind Regards,

Bas

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

Bug#954335: lintian confuses Fortran and Modula-2 modules

[Felix Lechner]

Hi Matthias,

On Fri, Mar 20, 2020 at 5:57 AM Matthias Klose  wrote:
>
> so please differentiate between Fortran and Modula-2 modules.

I have had some issues differentiating gfortran modules (#948033). In
which folders do they usually reside, please?

Also, why are they not all named md.gz, as in libcoarrays-dev?

Kind regards
Felix Lechner

Bug#954335: lintian confuses Fortran and Modula-2 modules

[Matthias Klose]

Package: lintian

running lintian on a gcc-10 build, I see

gzip: stdout: Broken pipe

gzip:
/tmp/temp-lintian-lab-i1Mvu3Lp4j/pool/g/gcc-10/libgm2-10-dev_10-20200320-1_amd64_binary/unpacked/usr/lib/gcc/x86_64-linux-gnu/10/m2/m2cor/Debug.mod:
not in gzip format


and then continues with:

libgm2-10-dev:
ESC]8;;https://lintian.debian.org/tags/gfortran-module-does-not-declare-version.htmlESC\gfortran-module-does-not-declare-versionESC]8;;ESC
\ usr/lib/gcc/x86_64-linux-gnu/10/m2/m2cor/Debug.mod

so please differentiate between Fortran and Modula-2 modules.

Bug#954334: gnome-music: Gnome music crashes at launch

[Aurelien Jacobs]

Package: gnome-music
Version: 3.36.0-1
Severity: normal

I'm on unstable and gnome-music crashes at launch with the following traceback
:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gnomemusic/window.py", line 215, in 
_on_songs_available
self._switch_to_player_view()
  File "/usr/lib/python3/dist-packages/gnomemusic/window.py", line 261, in 
_switch_to_player_view
self.views[View.SONG] = SongsView(self._app)
  File "/usr/lib/python3/dist-packages/gnomemusic/views/songsview.py", line 54, 
in __init__
self._add_list_renderers()
  File "/usr/lib/python3/dist-packages/gnomemusic/views/songsview.py", line 
121, in _add_list_renderers
attrs.insert(Pango.AttrFontFeatures.new("tnum=1"))
AttributeError: type object 'AttrFontFeatures' has no attribute 'new'

It seems to be due to libpango-1.0-0 1.42.4-8.
I was able to fix the issue by upgrading libpango-1.0-0 to experimental
1.44.7-2.



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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-music depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  gir1.2-dazzle-1.03.36.0-1
ii  gir1.2-glib-2.0  1.62.0-5+b1
ii  gir1.2-goa-1.0   3.36.0-1
ii  gir1.2-grilo-0.3 0.3.12-1
ii  gir1.2-gst-plugins-base-1.0  1.16.2-2
ii  gir1.2-gstreamer-1.0 1.16.2-2
ii  gir1.2-gtk-3.0   3.24.14-1
ii  gir1.2-mediaart-2.0  1.9.4-2
ii  gir1.2-soup-2.4  2.70.0-1
ii  gir1.2-totemplparser-1.0 3.26.5-1
ii  gir1.2-tracker-2.0   2.3.4-1
ii  gnome-settings-daemon3.36.0-1
ii  grilo-plugins-0.30.3.11-1
ii  libc62.30-2
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-3
ii  libglib2.0-0 2.64.1-1
ii  libgtk-3-0   3.24.14-1
ii  libpango-1.0-0   1.44.7-2
ii  libpangocairo-1.0-0  1.44.7-2
ii  python3  3.8.2-1
ii  python3-gi   3.36.0-1
ii  python3-gi-cairo 3.36.0-1
ii  python3-requests 2.22.0-2
ii  tracker  2.3.4-1

gnome-music recommends no packages.

gnome-music suggests no packages.

-- no debconf information

Bug#954134: [d-i bullseye alpha2] installing grub fails

[Holger Wansing]

Hi,

Steve McIntyre  wrote:
> On Thu, Mar 19, 2020 at 12:42:48PM +0100, Holger Wansing wrote:
> >Hi,
> >
> >Steve McIntyre  wrote:
> >> On Thu, Mar 19, 2020 at 09:26:25AM +0100, Holger Wansing wrote:
> >> >Hi,
> >> >
> >> >Steve McIntyre  wrote:
> >> >> One silly question: what media are you using with the Thinkpad? Is it
> >> >> the same USB stick (or whatever) every time? Can you verify it's
> >> >> written OK?
> >> >
> >> >I used the same USB stick for alpha1 and alpha2, re-flashing it over and
> >> >over again.
> >> >And I have checked installation media integrity with alpha2, it reports
> >> >no error, "image is valid".
> >> 
> >> Hmmm, OK. Wondering what's causing this then. I'll try another
> >> installation test on a physical machine and get back to you.
> >
> >I noticed a difference between a alpha1 and alpha2 install on the Thinkpad:
> >in alpha1 I get the message that the new Debian seems to be the only OS
> >on the machine. However, on alpha2 install I did not get that message.
> >
> >But I see no relevant changing in os-prober between alpha1 and 2 which
> >would explain that ...
> >
> >I wonder if it's a kernel issue somehow?
> 
> Hmmm. Can you try wiping the partition table in between tests?

I already tried that on wednesday, with no success.

However, today it does the trick! Success!
Curious, but installation completed fine.

Will see, if I can reproduce it again...


Holger


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

Bug#954331: Please adjust tag severities

[Felix Lechner]

Control: reassign -1 pkg-perl-tools

Hi,

> Jonas Smedegaard wrote:
>
> Upgrading to version 2.58.0 of lintian renders it totally unusable:

That is not correct. Lintian just fails to work with pkg-perl-tools.

> Lintian::Tag::Info::original_severity(Lintian::Tag::Info=HASH(0x565295307a18),
>  "minor") called at /usr/share/perl5/Lintian/Tag/Info.pm line 182
> Lintian::Tag::Info::load(Lintian::Tag::Info=HASH(0x565295307a18), 
> "/usr/share/lintian/tags/pkg-perl/nonteam-testsuite-header.desc") called at 
> /usr/share
>
> Lintian::Tag::Info::original_severity(Lintian::Tag::Info=HASH(0x55627b1c2e28),
>  "minor") called at /usr/share/perl5/Lintian/Tag/Info.pm line 182
> Lintian::Tag::Info::load(Lintian::Tag::Info=HASH(0x55627b1c2e28), 
> "/usr/share/lintian/tags/pkg-perl/nonteam-testsuite-header.desc") called at 
> /usr/share

The meaning of the Severity field in tag declarations has changed.
Please modify the tags in pkg-perl-tools accordingly. For details,
please see #935706 or this and the surrounding commits:


https://salsa.debian.org/lintian/lintian/-/commit/e1e12f7f4190ab5718e2317dd7e466d8b56d6043

Kind regards
Felix Lechner

Bug#954333: RM: ga nwchem [armel mipsel] -- RoQA; new build-deps of ga not available on armel, mipsel

[Juhani Numminen]

Package: ftp.debian.org
Severity: normal
X-debbugs-cc: mba...@debian.org

Dear FTP masters,

Because some build-deps of ga are not available on armel and mipsel,
ga and nwchem are blocked from migrating to testing. Please remove
ga and nwchem binaries of architectures armel and mipsel.


Thanks,
Juhani

Bug#326081: Hallo

[Rebekah Issah]

Hallo

Bitte ist es in Ordnung, auf Englisch zu kommunizieren? Ich habe Google 
Übersetzer verwendet, um Englisch zum besseren Verständnis in Ihre Sprache zu 
übersetzen.

Ich bin Frau Rebekah Issah, eine Jemenfrau. Ich möchte wegen der anhaltenden 
Unruhen / Kriege im Jemen sowie der täglichen lebensbedrohlichen Angriffe von 
Al-Qaida-Kämpfern nach Deutschland umziehen. Ich habe meine Familie, meinen 
Mann, meinen Sohn und meine Tochter bereits während eines Angriffs auf unser 
Haus am 23. März 2019 an die kalten Hände des Todes verloren, um unsere Familie 
zu beenden. Ich war während des Kreuzfeuers nicht da. Ich war zur Untersuchung 
im Krankenhaus, als sie unser Haus angriffen, meinen geliebten Ehemann, Sohn 
und meine Tochter töteten und das Haus in Brand steckten. Ich bin in Tränen, 
wenn ich dir diese Mail schreibe. Er (mein verstorbener Ehemann) war ein sehr 
erfolgreicher Bauunternehmer in der Ölstadt Jemen und beschäftigte sich vor 
seinem frühen Tod privat mit Goldstaub und Goldbarren. Erwartungsgemäß hat er 
einen angemessenen Geldbetrag zurückgelassen, den ich in den Immobiliensektor, 
Reisen & Tourismus, Hotelmanagement und andere interessante Sektoren in 
Deutschland investieren möchte.

Wie Sie vielleicht wissen oder nicht wissen, haben die von den Vereinigten 
Staaten und der Europäischen Union verhängten Sanktionen es nahezu unmöglich 
gemacht, hier im Jemen irgendeine Art von Investition erfolgreich durchzuführen 
oder sogar Geld von hier in andere Teile der Welt zu überweisen. Aus diesem 
Grund kontaktiere ich Sie sehr zuversichtlich mit der Hoffnung, dass Sie mir 
helfen können, dieses Geld für Investitionszwecke nach Deutschland zu bringen:

Bitte ich würde gerne wissen, wie bequem es für Sie sein könnte, mir auf diese 
Weise zu helfen. Das gesamte mir zur Verfügung stehende Kapital beträgt neun 
Millionen Euro. Ich habe das Geld heimlich in einem Kofferraum eingesperrt und 
beim Roten Kreuz hier in Sanaa deponiert. Ich möchte Sie aufrichtig schriftlich 
bitten, die Sparbüchse freundlich anzunehmen. Dies liegt daran, dass wir nach 
dem Krieg von hier aus keine Banküberweisungen mehr durchführen können. Dies 
sind die Hauptprobleme, die mich jetzt beschäftigen. Ich werde Ihnen 20% des 
Gesamtgeldes als Vorteil für Ihre Hilfe geben.

Ich muss diese Chance nutzen, weil ich keine andere Alternative habe, als 
jemandem zu vertrauen. Ich kann mein Leben hier nicht riskieren, um ein Ende 
meiner Familienlinie zu vermeiden. Als Frau ist mein Mann, mein Sohn und meine 
Tochter tot. Ich verdiene ein anständiges Leben in einer friedlichen Umgebung. 
Ich werde nach Deutschland ziehen und das Geld in Übereinstimmung mit dem 
Gesetz, Ihrem Rat und Ihrer Unterstützung investieren. wir können 
zusammenarbeiten und erreichen.

Ich erwarte Ihre positive Antwort und werde Ihnen nach Erhalt Ihrer 
Informationen weitere Einzelheiten mitteilen.

Hochachtungsvoll,

Rebekah Issah.

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Bug#954330: GIMP 2 .10 crash

[Valentin CAHAGNE]

Package: gimp
Version: 2.10.10-209

When i launch gimp this message appears instantly, i updated my
packages today on March 20, 2020.

```
GNU Image Manipulation Program version 2.10.12
git-describe: GIMP_2_10_10-209-g3d8535b55f
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
9.2.1-14' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --
enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --
prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --
program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-
id --libexecdir=/usr/lib --without-included-gettext --enable-
threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --
enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-
time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-
vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-
multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-
list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-
offload-targets=nvptx-none,hsa --without-cuda-driver --enable-
checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --
target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191025 (Debian 9.2.1-14) 

using GEGL version 0.4.16 (compiled against version 0.4.16)
using GLib version 2.64.1 (compiled against version 2.62.2)
using GdkPixbuf version 2.40.0 (compiled against version 2.40.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Erreur de segmentation

Stack trace:
```
/usr/lib/libgimpbase-
2.0.so.0(gimp_stack_trace_print+0x398)[0x7f0e3293a358]
gimp-2.10(+0xd4810)[0x556f5944b810]
gimp-2.10(+0xd4c38)[0x556f5944bc38]
gimp-2.10(+0xd52a9)[0x556f5944c2a9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14110)[0x7f0e31e36110]
gimp-2.10(gimp_param_spec_layer_id+0x64)[0x556f597ccf04]
gimp-2.10(gimp_pdb_compat_param_spec+0x1c7)[0x556f596e7a67]
gimp-2.10(gimp_plug_in_handle_message+0x1197)[0x556f596f4487]
gimp-2.10(gimp_plug_in_manager_call_query+0x191)[0x556f59702a91]
gimp-2.10(gimp_plug_in_manager_restore+0x796)[0x556f596faa26]
gimp-2.10(+0x3a163d)[0x556f5971863d]
/usr/lib/x86_64-linux-gnu/libgobject-
2.0.so.0(g_closure_invoke+0x1a2)[0x7f0e320c7fd2]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x26f06)[0x7f0e320daf06]
/usr/lib/x86_64-linux-gnu/libgobject-
2.0.so.0(g_signal_emit_valist+0xbdf)[0x7f0e320e654f]
/usr/lib/x86_64-linux-gnu/libgobject-
2.0.so.0(g_signal_emit+0x8f)[0x7f0e320e6edf]
gimp-2.10(gimp_restore+0x102)[0x556f59717bc2]
gimp-2.10(app_run+0x4ab)[0x556f5944b14b]
gimp-2.10(main+0x37e)[0x556f5944a8de]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f0e31c83e0b]
gimp-2.10(_start+0x2a)[0x556f5944aa6a]

```

Bug#954332: RFS: nsd/4.3.0-1 -- authoritative domain name server

[Markus Schade]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "nsd"

 * Package name: nsd
   Version : 4.3.0-1
   Upstream Author : nsd-us...@nlnetlabs.nl
 * URL : https://www.nlnetlabs.nl/projects/nsd/about/
 * License : NSD-BSD-like
 * Vcs : https://salsa.debian.org/dns-team/nsd
   Section : net

It builds those binary packages:

  nsd - authoritative domain name server

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/n/nsd/nsd_4.3.0-1.dsc

or from git:

 https://salsa.debian.org/dns-team/nsd

Changes since the last upload:

   * New upstream version 4.3.0
   * Update standards version to 4.5.0
   * Correct typo (mount/@mount) in nsd.service SystemCallFilter list
   * Add upstream patch to include missing headers file to fix FTBFS

Regards,

--
  Markus Schade

Bug#954331: lintian: coercion for "original_severity" failed: Unknown tag severity minor

[Jonas Smedegaard]

Package: lintian
Version: 2.58.0
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upgrading to version 2.58.0 of lintian renders it totally unusable:

$ lintian *_amd64.changes --no-tag-display-limit
coercion for "original_severity" failed: Unknown tag severity minor
Lintian::Tag::Info::__ANON__("minor") called at (eval 123) line 28
eval {...} called at (eval 123) line 27

Lintian::Tag::Info::original_severity(Lintian::Tag::Info=HASH(0x565295307a18), 
"minor") called at /usr/share/perl5/Lintian/Tag/Info.pm line 182
Lintian::Tag::Info::load(Lintian::Tag::Info=HASH(0x565295307a18), 
"/usr/share/lintian/tags/pkg-perl/nonteam-testsuite-header.desc") called at 
/usr/share/perl5/Lintian/Profile.pm line 224
Lintian::Profile::load(Lintian::Profile=HASH(0x565294d47398), undef, 
ARRAY(0x5652925edde0), HASH(0x565292972ec0)) called at /usr/bin/lintian line 217
dplint::load_profile(undef) called at 
/usr/share/lintian/commands/lintian.pm line 712
eval {...} called at /usr/share/lintian/commands/lintian.pm line 712
main::main() called at /usr/bin/lintian line 46
eval {...} called at /usr/bin/lintian line 46
main::__ANON__("/usr/share/lintian/commands/lintian.pm") called at 
/usr/bin/lintian line 115
dplint::run_tool("/usr/bin/lintian", "lintian") called at /usr/bin/lintian 
line 294
dplint::main() called at /usr/bin/lintian line 378

jonas@auryn:~/public_debian/pool-sid/OFFICIAL/monero$ lintian *_amd64.changes 
--no-tag-display-limit
coercion for "original_severity" failed: Unknown tag severity minor
Lintian::Tag::Info::__ANON__("minor") called at (eval 123) line 28
eval {...} called at (eval 123) line 27

Lintian::Tag::Info::original_severity(Lintian::Tag::Info=HASH(0x55627b1c2e28), 
"minor") called at /usr/share/perl5/Lintian/Tag/Info.pm line 182
Lintian::Tag::Info::load(Lintian::Tag::Info=HASH(0x55627b1c2e28), 
"/usr/share/lintian/tags/pkg-perl/nonteam-testsuite-header.desc") called at 
/usr/share/perl5/Lintian/Profile.pm line 224
Lintian::Profile::load(Lintian::Profile=HASH(0x55627ad428b8), undef, 
ARRAY(0x5562785e8de0), HASH(0x55627896e290)) called at /usr/bin/lintian line 217
dplint::load_profile(undef) called at 
/usr/share/lintian/commands/lintian.pm line 712
eval {...} called at /usr/share/lintian/commands/lintian.pm line 712
main::main() called at /usr/bin/lintian line 46
eval {...} called at /usr/bin/lintian line 46
main::__ANON__("/usr/share/lintian/commands/lintian.pm") called at 
/usr/bin/lintian line 115
dplint::run_tool("/usr/bin/lintian", "lintian") called at /usr/bin/lintian 
line 294
dplint::main() called at /usr/bin/lintian line 378

NB! Below was computed after I downgraded to 2.57.0.

 - Jonas

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

Kernel: Linux 5.5.0-rc5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_DIE, TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=da_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils 2.34-5
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.19-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.68-1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.46-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libdevel-size-perl   0.83-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  libjson-maybexs-perl 1.004000-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libsereal-decoder-perl   4.011+ds-1
ii  libsereal-encoder-perl   4.011+ds-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3200-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.008001-2
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   

Bug#473092: Defective orig sources

[Felix Lechner]

Hi,

The orig sources in the archive, e3_2.71.orig.tar.gz, do not match the
sources available here

https://sites.google.com/site/e3editor/Home/e3-2.7.1.tar.gz

Most significantly, the version in the archive untars with errors,
while the tarball above lists or extracts without errors.

The site above also shows a newer version 2.8.2 from late 2016.

Kind regards
Felix Lechner

Bug#498241: no ?action(forbid-version)

[Yuri D'Elia]

Package: aptitude
Version: 0.8.12-3
Followup-For: Bug #498241

I encountered this problem today. I'm trying to match all packages which
will upgraded on the next run, but turns out to be non-trivial.

'~U' includes packages with holds and forbids (and according to the
description: "packages that can be upgraded" would be fine).

'~aupgrade' still includes forbids though.

I understand "forbid" is not an action, but a flag in the package state.
We have a search term for the 'auto' flag (~M), why not introduce a
search term that can be used to match packages with it?

Bug#953440: libvtk7.1 does not include xdmf3 libraries

[Alastair McKinstry]

Debian already ships xdmf3 librariesm currently from git snapshot:
3.0+git20190531

What can we use to test compatability ?

Alastair


On 09/03/2020 19:57, Ruben Di Battista wrote:
> Package: libvtk7.1
> Version: 7.1.1+dfsg1-12
>
> I’m posting after suggestion from the Ubuntu team
> (https://answers.launchpad.net/ubuntu/+source/vtk7/+question/689223). 
>  recently switched to using xdmf3 instead of xdmf in a library I’m
> working on, and I started to get this error with libvtk7.1 package: 
>
> ```
> CMake Error at /usr/lib/cmake/vtk-7.1/vtkModuleAPI.cmake:120 (message):
>    Requested modules not available:
> vtkIOXdmf3
> ```
>
> In my opinion the package should also ship the xdmf3 libraries, since
> they’re available
> upstream: https://github.com/Kitware/VTK/tree/v7.1.1/ThirdParty/xdmf3
>
> Some diagnostics: 
>
> ```
>
> uname -a:
> Linux c7e29d71ba78 4.4.0-174-generic #204-Ubuntu SMP Wed Jan 29 06:41:01
> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
>
> lsb_release -crid:
> Distributor ID: Ubuntu
> Description: Ubuntu 18.04.4 LTS
> Release: 18.04
> Codename: bionic
>
> apt-cache policy vtk7 libvtk7-dev:
> vtk7:
>   Installed: 7.1.1+dfsg1-2
>   Candidate: 7.1.1+dfsg1-2
>   Version table:
>  *** 7.1.1+dfsg1-2 500
> 500 http://archive.ubuntu.com/ubuntu
>  bionic/universe amd64 Packages
> 100 /var/lib/dpkg/status
> libvtk7-dev:
>   Installed: 7.1.1+dfsg1-2
>   Candidate: 7.1.1+dfsg1-2
>   Version table:
>  *** 7.1.1+dfsg1-2 500
> 500 http://archive.ubuntu.com/ubuntu
>  bionic/universe amd64 Packages
> 100 /var/lib/dpkg/status
>
> ```
>
>
>
> |_ -. .´ | ', ; |∞∞ ˜˜ |∞ RdB ,., |∞∞ .' '. |
> -' `’ https://rdb.is |
>
-- 
Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, 
phone: 087-6847928
Green Party Councillor, Galway County Council 

Bug#954329: paraview: opacity incorrectly handled by the debian bullseye(testing) package paraview-5.7

[Pierre Saramito]

Package: paraview 
Version: 5.7.0-4+b2 
Severity: normal 

Dear Maintainer, 

The opacity is not handled correctly by paraview-5.7 binary, 
as packaged on bullseye(testing) distrib. 
Here is a unix command that reproduces the bug: 

paraview --script=paraview-opacity-bug.py 

where the paraview-opacity-bug.py python script coulbe be downloaded at 

https://www-ljk.imag.fr/membres/Pierre.Saramito/tmp/paraview-opacity-bug.py 

This problem is specific to the debian package: the upstream paraview-5.7 
version is problem-free when I use the raw binary distributed by kitware: 

https://www.paraview.org/download/ 
https://www.paraview.org/paraview-downloads/download.php?submit=Download=v5.7=binary=Linux=ParaView-5.7.0-osmesa-MPI-Linux-Python3.7-64bit.tar.gz
 

This opacity problem could perhaps be due to the mesa/opengl library, 
as packaged by debian bullseye(testing) ? 

Best whishes, 

Pierre 

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

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

Versions of packages paraview depends on: 
ii libavcodec58 7:4.2.2-1+b1 
ii libavformat58 7:4.2.2-1+b1 
ii libavutil56 7:4.2.2-1+b1 
ii libc6 2.30-2 
ii libdouble-conversion3 3.1.5-5 
ii libexpat1 2.2.9-1 
ii libfreetype6 2.10.1-2 
ii libgcc-s1 [libgcc1] 10-20200312-2 
ii libgcc1 1:10-20200312-2 
ii libgdal26 3.0.4+dfsg-1 
ii libgl1 1.3.1-1 
ii libglew2.1 2.1.0-4+b1 
ii libhdf5-103 1.10.4+repack-11 
ii libjpeg62-turbo 1:1.5.2-2+b1 
ii liblz4-1 1.9.2-2 
ii liblzma5 5.2.4-1+b1 
ii libopenmpi3 4.0.2-5 
ii libpdal-base9 2.0.1+ds-1+b1 
ii libpng16-16 1.6.37-2 
ii libpython3.7 3.7.7-1 
ii libqt5core5a 5.12.5+dfsg-9 
ii libqt5gui5 5.12.5+dfsg-9 
ii libqt5help5 5.12.5-2+b2 
ii libqt5network5 5.12.5+dfsg-9 
ii libqt5widgets5 5.12.5+dfsg-9 
ii libqt5x11extras5 5.12.5-1 
ii libstdc++6 10-20200312-2 
ii libswscale5 7:4.2.2-1+b1 
ii libtiff5 4.1.0+git191117-2 
ii libx11-6 2:1.6.9-2 
ii libxml2 2.9.10+dfsg-4 
ii libxt6 1:1.1.5-1+b3 
ii python3-autobahn 17.10.1+dfsg1-6 
ii python3-matplotlib 3.1.2-2 
ii python3-mpi4py 3.0.3-4 
ii python3-six 1.14.0-2 
ii python3-twisted 18.9.0-6 
ii tcl [tclsh] 8.6.9+1+b1 
ii zlib1g 1:1.2.11.dfsg-2 

Versions of packages paraview recommends: 
ii mpi-default-bin 1.13 
ii paraview-doc 5.7.0-4 
pn paraview-python  

Versions of packages paraview suggests: 
pn h5utils  
ii hdf5-tools 1.10.4+repack-11 

-- no debconf information 

-- 
pierre.saram...@imag.fr 
Directeur de Recherche CNRS 
Laboratoire Jean Kuntzmann, Grenoble, France 
http://ljk.imag.fr/membres/Pierre.Saramito 

Bug#954328: linphone loops sending REGISTER because it doesn't believe the SIP OK matches the SIP register

[John Hughes]

Package: linphone
Version: 3.12.0-3.1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Trying to work from home due to covid-19 :(

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

Set up linphone to talk to our existing asterisk setup.

   * What was the outcome of this action?

Everything works but linphone takes about 20% cpu when idle

   * What outcome did you expect instead?

Lower CPU usage when calls not in progress.

Details:

I've configured linphone to send calls to our asterisk and asterisk to be able
to call linphone as an extension.  This works but I see linphone using a
constant ~20% of cpu.  In the linphone debug window I see that linphone
doesn't believe that the SIP OK in reply to the SIP register matches, so
linphone (or, more exactly belle-sip) resends the REGISTER endlessly.

For example:

message: 2020-03-19 08:58:37:816 channel [0x5652c055ea30]: message sent to 
[UDP://masked.masked.com:5060], size: [728] bytes
REGISTER sip:masked.masked.com SIP/2.0
Via: SIP/2.0/UDP 10.27.128.3:5060;branch=z9hG4bK.Xy81vVGP5;rport
From: ;tag=kiyGbhQuT
To: sip:j...@masked.masked.com
CSeq: 15003 REGISTER
Call-ID: -jz0iptAjY
Max-Forwards: 70
Supported: replaces, outbound
Accept: application/sdp
Accept: text/plain
Accept: application/vnd.gsma.rcs-ft-http+xml
Contact: 
;+sip.instance=""
Expires: 3600
User-Agent: Linphone/3.12.0 (belle-sip/1.6.3)
Authorization:  Digest realm="asterisk", nonce="7a074ecd", algorithm=MD5, 
username="john",  uri="sip:masked.masked.com", 
response="27e6d621c10672a7a553e82addb894cc"


message: 2020-03-19 08:58:37:844 channel [0x5652c05ba260]: received [553] new 
bytes from [UDP://:::10.27.128.1:5060]:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
10.27.128.3:5060;branch=z9hG4bK.Xy81vVGP5;received=10.27.128.3;rport=5060
From: ;tag=kiyGbhQuT
To: sip:j...@masked.masked.com;tag=as33ad5d3a
Call-ID: -jz0iptAjY
CSeq: 15003 REGISTER
Server: Asterisk PBX 13.14.1~dfsg-2+deb9u4
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 3600
Contact: ;expires=3600
Date: Thu, 19 Mar 2020 07:58:37 GMT
Content-Length: 0


message: 2020-03-19 08:58:37:846 channel [0x5652c05ba260] [553] bytes parsed
message: 2020-03-19 08:58:37:846 Found transaction matching response.
message: 2020-03-19 08:58:37:846 Changing [client] [REGISTER] transaction 
[0x5652c0bdac10], from state [TRYING] to [COMPLETED]
message: 2020-03-19 08:58:37:847 Refresher [0x5652c039da00]: contact address 
[10.27.128.3:5060] does not match channel address[(null):0] on channel 
[0x5652c055ea30]
message: 2020-03-19 08:58:37:847 belle_sip_refresher_start(): refresher 
[0x5652c039da00] is resubmitting request because contact sent was not correct 
in original request.

The message "contact address ... does not match channel address" is in
belle-sip src/refresher.c function is_contact_request_accurate:

if (channel_public_port == contact_port
&& channel_public_ip && contact_ip
&& strcmp(channel_public_ip,contact_ip) == 0) {
/*nothing to do contact is accurate*/
belle_sip_header_contact_set_unknown(contact,FALSE);
return TRUE;
} else {
belle_sip_message("Refresher [%p]: contact address 
[%s:%i] does not match channel address[%s:%i] on channel [%p]"   ,refresher
,contact_ip
,contact_port
,channel_public_ip
,channel_public_port
,refresher->transaction->base.channel);
return FALSE;
}

It seems that when we get here refresher->transaction->base.channel->public_ip
is NULL.

Here is the part of my .linphonerc where the proxy is defined:

[proxy_0]
reg_proxy=sip:masked.masked.com
reg_identity=sip:j...@masked.masked.com
quality_reporting_enabled=0
quality_reporting_interval=0
reg_expires=3600
reg_sendregister=1
publish=1
avpf=0
avpf_rr_interval=5
dial_escape_plus=0
privacy=32768
publish_expires=-1

I made a simple hack to refresher.c to accept OK replies if "public_ip" was
NULL, which drops the CPU time and seems to have no bad effects but is almost
certainly the wrong "fix".


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

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

Versions of packages linphone depends on:
ii  libatk1.0-0  2.34.1-1
ii  

Bug#936667: fixed in grpc 1.24.3-1

[Emilio Pozuelo Monfort]

Control: reopen -1

On Fri, 20 Mar 2020 11:31:17 +0300 Dmitry Shachnev  wrote:
> Control: severity -1 serious
> 
> On Fri, Mar 13, 2020 at 09:24:45PM -0400, Sandro Tosi wrote:
> > Hey Laszlo,
> >
> > > Format: 1.8
> > > Date: Wed, 23 Oct 2019 05:45:37 +
> > > Source: grpc
> > > Binary: libgrpc++-dev libgrpc++1 libgrpc-dev libgrpc8 
> > > protobuf-compiler-grpc protobuf-compiler-grpc-dbgsym python3-grpcio 
> > > python3-grpcio-dbgsym ruby-grpc ruby-grpc-dbgsym ruby-grpc-tools
> > > Architecture: source amd64 all
> > > Version: 1.24.3-1
> > > Distribution: experimental
> >
> > could you please upload this package to unstable? grpc is the last
> > reverse dependency of python-sphinx-rtd-theme, so once this his sid,
> > we can remove that package.
> 
> python-sphinx-rtd-theme is now removed from unstable, so I am bumping the
> severity to RC.

And reopening.

Laszlo, note that grpc still build-depends on python-sphinx-rtd-theme which no
longer exists, making this package unbuildable atm:

https://buildd.debian.org/status/package.php?p=grpc=sid

Cheers,
Emilio

Bug#954327: RFS: cava/0.6.1-1 [ITP] -- Console-based Audio Visualizer for Alsa

[Lasse Flygenring-Harrsen]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "cava"

 * Package name: cava
   Version : 0.6.1-1
   Upstream Author : [fill in name and email of upstream]
 * URL : http://karlstav.github.io/cava/
 * License : MIT
 * Vcs : https://github.com/karlstav/cava
   Section : sound

It builds those binary packages:

  cava - Console-based Audio Visualizer for Alsa

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/c/cava/cava_0.6.1-1.dsc


Changes since the last upload:

   * Initial release Closes: #954325

Regards,

--
  Lasse Flygenring-Harrsen

Bug#954326: libmumps-ptscotch-dev: segfault on buster(stable): mumps recompilation nedded

[Pierre Saramito]

Package: libmumps-ptscotch-dev 
Version: 5.1.2-4+b2 
Severity: important 

Dear Maintainers, 

The library SEGFAULT on the buster(stable) package libmumps-ptscotch-dev 
5.1.2-4+b2 for the amd64 architecture. 
I used some well-known medium-sized sparse matrix as tests. 
This problem could be fixed on buster by a simple recompilation of the package: 

apt-get source mumps 
cd mumps-5.1.2 
dpkg-buildpackage -us -uc -sa -j1 
dpkg -i libmumps-5.1.2-4_amd64.deb libmumps-dev-4_amd64.deb 
libmumps-scotch-5.1.2-4_amd64.deb libmumps-scotch-dev-4_amd64.deb 
libmumps-ptscotch-5.1.2-4_amd64.deb libmumps-ptscotch-dev-4_amd64.deb 

On the bullseye (testing) distrib, there is no problem at all. 

So, perhaps a binanry dependency has change for mumps on buster(stable), 
and (I dont known why) the package has not been yet recompiled ? 

Best wishes, 

Pierre 

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

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

Versions of packages libmumps-ptscotch-dev depends on: 
ii libmumps-dev 5.1.2-4+b2 
ii libmumps-ptscotch-5.1.2 5.1.2-4+b2 

libmumps-ptscotch-dev recommends no packages. 

libmumps-ptscotch-dev suggests no packages. 

-- no debconf information 

-- 
pierre.saram...@imag.fr 
Directeur de Recherche CNRS 
Laboratoire Jean Kuntzmann, Grenoble, France 
http://ljk.imag.fr/membres/Pierre.Saramito 

Bug#953883: Please backport version 20 for buster

[Enrico Zini]

On Sat, Mar 14, 2020 at 02:42:42PM +0100, Enrico Zini wrote:

> thank you for maintaining gunicorn.
> 
> gunicorn version 19 has issues with the version of tornado currently in
> buster: https://github.com/benoitc/gunicorn/issues/2119
> 
> Could you please backport version 20, which claims to have fixed them?

Thanks for the backport, indeed it fixes the issue, and restarting
gunicorn+tornado services now does not incur in some minutes of
downtime.

I guess this bug could be closed. I noticed that while upgrading to
gunicorn 20, one has to fiddle a bit with packages: I was using
gunicorn3, which is now replaced with gunicorn, and I had to spend some
times figuring out why `apt -t buster-backports install gunicorn3` would
not find the package, while rmadison insisted gunicorn 20 was
backported.

Maybe gunicorn now misses some conflicts/provides/replaces voodoo
towards gunicorn3?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Bug#954325: ITP: cava -- Console-based Audio Visualizer for Alsa

[Lasse Flygenring-Harrsen]

Package: wnpp
Severity: wishlist
Owner: Lasse Flygenring-Harrsen 

* Package name: cava
  Version : 0.6.1
  Upstream Author : Karl Stava 
* URL : http://karlstav.github.io/cava/
* License : GPL
  Programming Lang: C
  Description : Console-based Audio Visualizer for Alsa

C.A.V.A. is a bar spectrum audio visualizer for the Linux terminal using ALSA,
pulseaudio or fifo buffer for input. This program is not intended for
scientific use. It's written to look responsive and aesthetic when used to
visualize music.

Cava would supplement other audio monitoring tools already in Debian quite
nicely. It provides an easy way of monitoring audio output of various Linux
audio solutions including Pulseaudio and ALSA. I am hoping to maintain the
package myself through a sponsor.

Bug#954323: libreoffice-common: Update to 1:6.4.2-1 renders libreoffice-writer unusable

[rene . engelhard]

severity 954323 serious
retitle 954323 libreoffice-common 6.4.2 breaks older versions
found 954323 1:6.4.2~rc1-1
thanks

Am 20. März 2020 09:17:51 MEZ schrieb Ara Keary :
>Package: libreoffice-common
>Version: 1:6.4.2-1
>Severity: grave
>Justification: renders package unusable

Sigh.

>. or the document opens, but no menu is available, icons are scattered.

That is expected, all .ui Files moved to the respective packages.

>Note that in the last debian update, many other packages were upgraded
>to
>1:6.4.2-1 .

Which? As at the time of your report the amd64 binaries now containing the UI 
Files were not in the archive proper?

>Versions of packages libreoffice-common depends on:
>ii  libnumbertext-data 1.0.5-3
>ii  libreoffice-style-colibre  1:6.4.2-1
>ii  libreoffice-style-tango1:6.4.2-1

Here we see the arch-indep packages at 6.4.2...

>ii  ure1:6.4.1-1+b1

And as expected the arch-dep packages at 6.4.1.
I would guess libreoffice-writer and -core etc are also at 6.4.1..

>ii  libreoffice-core 1:6.4.1-1+b1

As guessed.

And -core does depend on a 6.4.2 package, but indeed -common misses a Breaks: 
to 6.4.1 packages..

(This could not have happened some time ago because common also had a versioned 
dependency on core but people don't like circular dependencies...)

In any case, upgrade with the amd64 binaries and it should work.

Will add the Breaks: of course..

Regards

Rene

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#954311: libgl1-mesa-dri: Makes KDE konsole unusable

[Timo Aaltonen]

On 20.3.2020 10.18, Stefan Fritsch wrote:
> Package: libgl1-mesa-dri
> Version: 20.0.2-1
> Followup-For: Bug #954311
> 
> 
> With this mesa version, there are severe drawing artifacts with the kde
> konsole terminal emulator that makes it unusable. I also see problems
> when marking text in thunderbird.
> 
> Downgrading the following packages to 19.3.3-1 fixes the problem:
> 
>  libegl-mesa0
>  libglapi-mesa
>  libgbm1
>  libgl1-mesa-dri
>  libosmesa6
>  libgbm-dev
>  libglx-mesa0
> 
> Cheers,
> Stefan

Please file it upstream, this is caused by the new 'iris' driver. In the
meantime, you can force the previous driver with this in a ~/.drirc:


  

  



Or run the app with the driver to verify it actually helps:

dri_driver=i965 ./app




-- 
t

Bug#938249: python-virtualenv: Python2 removal in sid/bullseye

[Scott Kitterman]

I know this is marked py2keep, but I don't think we can.  Our virtualenv is 5 
years old and really needs updated.  The brings in a requirement for pip in 
the base virtualenv which then needs a wheel for ipaddr (which is already out 
of testing) and python-pip, which has already been dropped.

I think it needs to go.

Scott K

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

Bug#954291: [Pkg-libvirt-maintainers] Bug#954291: libvirt-daemon-system-sysv: upgrading kills VMs

[Guido Günther]

Hi,
On Thu, Mar 19, 2020 at 08:18:04PM +0100, Thorsten Glaser wrote:
> Package: libvirt-daemon-system-sysv
> Version: 6.0.0-3
> Severity: critical
> Justification: causes serious data loss
> 
> Just a regular dist-upgrade doing this:
> 
> 
> Unpacking libvirt-daemon-system-sysv (6.0.0-3) over (6.0.0-1) ...
> […]
> Setting up libvirt-daemon-system-sysv (6.0.0-3) ...
> Restarting libvirt logging daemon: /usr/sbin/virtlogd.
> Restarting libvirt management daemon: /usr/sbin/libvirtd.
> 
> Running guests on default URI: MirBSD
> Shutting down guests on default URI...
> Starting shutdown on guest: MirBSD
> Waiting for guest MirBSD to shut down, 300 seconds left

Looks like a regression from the sysv split since this worked before,
could you check if this fixes it:

   
https://salsa.debian.org/libvirt-team/libvirt/-/commit/d7df842ce8649d88c9b242b9f4866c43016554b7

Cheers,
 -- Guido

> […]
> 
> 
> It’s inacceptable for a regular package upgrade to shut down
> any running VMs without warning. The VMs may be necessary, or
> might need to be shut down manually (qemu’s guest agent still
> doesn’t work without native virtio in the guest even though a
> serial (IIRC) control channel is specified), and killing such
> a VM will introduce guest filesystem corruption.
> 
> At least issue a debconf thing like glibc does when you want
> to upgrade from 2.29 to 2.30, which offers me some time to
> shut down the VM manually or abort the upgrade.
> 
> 
> To add insult to injury, it didn’t even shut it down cleanly:
> 
> tglase@tglase:~ $ virsh -c qemu:///system list
>  Id   Name State
> 
>  3MirBSD   in shutdown
> 
> 
> “virsh destroy 3” to the “rescue”…
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unreleased
>   APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 
> 'unstable'), (100, 'experimental')
> Architecture: x32 (x86_64)
> Foreign Architectures: i386, amd64
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/lksh
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages libvirt-daemon-system-sysv depends on:
> ii  init-system-helpers  1.57
> ii  lsb-base 11.1.0
> 
> libvirt-daemon-system-sysv recommends no packages.
> 
> libvirt-daemon-system-sysv suggests no packages.
> 
> -- no debconf information
> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers

Bug#954321: in the Debian AWS-images cloud-init network fails if ipv6 is disabled

[Bastian Blank]

Control: reassign -1 debian-cloud-images
Control: severity -1 minor
Control: tags -1 ipv6,help

Hi Bas

On Fri, Mar 20, 2020 at 09:00:08AM +0100, Bas Zoetekouw wrote:
> On these machines, ipv6 is disabled by setting
> /proc/sys/net/ipv6/conf/all/disable_ipv6 to 1. This causes the network
> to fail:

No, our AWS images don't use disable_ipv6.  If you modify this setting,
you of course need to adopt the network config to cope with it.

Please provide a patch if you think we can do better.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown

Bug#954324: ITP: node-mermaid -- Javascript based diagramming and charting tool

[Nilesh Patra]

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

* Package name: node-mermaid
  Version : 8.4.8
  Upstream Author : Knut Sveidqvist
* URL : https://github.com/knsv/mermaid
* License : Expat
  Programming Lang: JavaScript
  Description : Javascript based diagramming and charting tool

Markdownish syntax for generating flowcharts,
sequence diagrams, class diagrams, gantt charts and git graphs.
.
It can help visualize flowcharts, diagrams, ganttcharts and git charts can
be
scripted in a markdown syntax, with a varitety of different symbols and
chart
types available. Since the diagram source is text based,
it can be part of production scipts.
.
Automates the diagram generation instead of making it manually.
.
Node.js is an event-based server-side JavaScript engine.

I take the responsibility to maintain this package.

Bug#936667: fixed in grpc 1.24.3-1

[Dmitry Shachnev]

Control: severity -1 serious

On Fri, Mar 13, 2020 at 09:24:45PM -0400, Sandro Tosi wrote:
> Hey Laszlo,
>
> > Format: 1.8
> > Date: Wed, 23 Oct 2019 05:45:37 +
> > Source: grpc
> > Binary: libgrpc++-dev libgrpc++1 libgrpc-dev libgrpc8 
> > protobuf-compiler-grpc protobuf-compiler-grpc-dbgsym python3-grpcio 
> > python3-grpcio-dbgsym ruby-grpc ruby-grpc-dbgsym ruby-grpc-tools
> > Architecture: source amd64 all
> > Version: 1.24.3-1
> > Distribution: experimental
>
> could you please upload this package to unstable? grpc is the last
> reverse dependency of python-sphinx-rtd-theme, so once this his sid,
> we can remove that package.

python-sphinx-rtd-theme is now removed from unstable, so I am bumping the
severity to RC.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#954322: llvm-9: Should build-depend on libxml2-dev

[Mike Hommey]

Package: llvm-9
Version: 1:9.0.1-9
Severity: wishlist

Dear Maintainer,

Using /usr/lib/llvm-9/bin/llvm-mt with XML manifests fails with:

  llvm-mt: error: no libxml2
 
This happens when LLVM is not built against libxml2.

Simply adding a build dependency on libxml2-dev should make LLVM's build
system pick it and enable the necessary code.

Mike

Bug#954323: libreoffice-common: Update to 1:6.4.2-1 renders libreoffice-writer unusable

[Ara Keary]

Package: libreoffice-common
Version: 1:6.4.2-1
Severity: grave
Justification: renders package unusable

Dear maintainers,

updating libreoffice-common to 1:6.4.2-1 renders libreoffice-writer unusable:
when opening an existing file
. either the document is declared as to be restored, but restoration fails,
. or the document opens, but no menu is available, icons are scattered.

In either case, it is impossible to edit the file in proper conditions.

Downgrading libreoffice-common to 1:6.4.1-1 solves the problem.

Note that in the last debian update, many other packages were upgraded to
1:6.4.2-1 .
Keeping these packages in version 1:6.4.2-1 while downgrading the only package
"libreoffice-common" to 1:6.4.1-1 solves the problem.

Cheers,

Ara



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

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

Versions of packages libreoffice-common depends on:
ii  libnumbertext-data 1.0.5-3
ii  libreoffice-style-colibre  1:6.4.2-1
ii  libreoffice-style-tango1:6.4.2-1
ii  ure1:6.4.1-1+b1

Versions of packages libreoffice-common recommends:
ii  apparmor   2.13.3-7
pn  fonts-liberation2 | ttf-mscorefonts-installer  
ii  libexttextcat-data 3.4.5-1
ii  python3-uno1:6.4.1-1+b1
ii  xdg-utils  1.1.3-2

Versions of packages libreoffice-common suggests:
ii  libreoffice-style-breeze [libreoffice-style]   1:6.4.2-1
ii  libreoffice-style-colibre [libreoffice-style]  1:6.4.2-1
ii  libreoffice-style-tango [libreoffice-style]1:6.4.2-1

Versions of packages python3-uno depends on:
ii  libc62.30-2
ii  libgcc-s110-20200312-2
ii  libpython3.8 3.8.2-1
ii  libreoffice-core 1:6.4.1-1+b1
ii  libstdc++6   10-20200312-2
ii  libuno-cppu3 1:6.4.1-1+b1
ii  libuno-cppuhelpergcc3-3  1:6.4.1-1+b1
ii  libuno-sal3  1:6.4.1-1+b1
ii  libuno-salhelpergcc3-3   1:6.4.1-1+b1
ii  python3  3.8.2-1
ii  python3.83.8.2-1
ii  uno-libs-private 1:6.4.1-1+b1
ii  ure  1:6.4.1-1+b1

-- no debconf information

Bug#954321: in the Debian AWS-images cloud-init network fails if ipv6 is disabled

[Bas Zoetekouw]

package: cloud.debian.org

(I previously reported this bug again cloud-init, see
https://bugs.launchpad.net/cloud-init/+bug/1863773, but it seems it is
instead an issue with the Debian images themselves).

I'm using cloud-init on a Debian machien in AWS using the official
Debian buster images
(https://wiki.debian.org/Cloud/AmazonEC2Image/Buster
)

On these machines, ipv6 is disabled by setting
/proc/sys/net/ipv6/conf/all/disable_ipv6 to 1. This causes the network
to fail:

bas@machine:/etc/network$ sudo ifup ens5
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/


Listening on LPF/ens5/02:45:ca:0d:93:76
Sending on LPF/ens5/02:45:ca:0d:93:76
Sending on Socket/fallback
DHCPREQUEST for 10.0.16.20 on ens5 to 255.255.255.255 port 67
DHCPACK of 10.0.16.20 from 10.0.16.1
RTNETLINK answers: File exists
bound to 10.0.16.20 -- renewal in 1796 seconds.

Could not get a link-local address
run-parts: /etc/network/if-pre-up.d/cloud_inet6 exited with return code 1
ifup: failed to bring up ens5

Even worse, on boot the machines do get a proper ipv4 address, but
(apparently because setting up the network fails), the dhcp (v4) daemon
is stopped, and the machines "mysteriously" drop off the net after the
lease ends.

Bug#885813: bumping severity of xfce4-notes-plugin's use of libunique to Serious

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2020-03-19 at 18:39 +0100, Andreas Henriksson wrote:
> There doesn't seem to have been any movement since your comment on the
> upstream bug report. The xfce4-notes-plugin is now the only remaining
> package in unstable that still depends on libunique, so it looks to me
> like it might be time to make the final call on this. What do you think?
> I'd really like to finally be able to remove libunique.

Hi Andreas, yes unfortunately upstream doesn't seem really active right now.
> 
> If your decision is we need to drop xfce4-notes-plugin then it seems
> xfce4-goodies metapackage will need its dependency removed, then we can
> request the other removals!

Yup, I guess that's the right solution for now, hopefully we'll be able to
reintroduce it later.
> 
> I'm happy to send salsa merge-request and/or do NMU if you are busy.

Thanks, I'll try to do it in the following days. If I didn't act in a 1-2
weeks time feel free to send a MR and NMU.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl50eZ0ACgkQ3rYcyPpX
RFsyPwgA1ZEdDYAZmBs45zW+iUjYpH8xzy+RlWcKx2QwUrBa9UYxFrAlwo3WjJha
fLjB0vWFPSUjB9+KXynnpjPCu56rTTCOUJwgphGdIRqYpdtJ9m2r4fjQ8/ondn9d
0/MKgD9pCS/F+vYo6zZrfsf9FeOHypkV8jFJ9N4/ES6SBFHt8VFu+qylsC1L8HmF
K9vY4vtpuEOvfh1h/RaH9dmt8uHe1ZP0PiPDbHJR7UXdbRIRzI5RPIfnsN9Ep1vH
w7qgqUbpBXN738A9Wk7+JSfdbv7CK30hHlCnBAE+T+G95GmTRe8/W2Tw/gwA8Num
NE7bJeAiEVIHS9/lrie7KgeyDC4BKQ==
=ytNx
-END PGP SIGNATURE-

Bug#623004: 10 Twoich wiadomości przychodzących zostało zawieszonych

[Bonfanti, Federica]

NOTATKA ZGŁOSZENIOWA MICROSOFT


10 Twoich wiadomości przychodzących zostało zawieszonych, a Twoje konto 
skrzynki e-mailowej wkrótce zostanie również zawieszone, ponieważ Twoje konto 
skrzynki pocztowej nie zostało zweryfikowane w tym roku. kliknij przycisk 
Sprawdź teraz poniżej, aby zweryfikować konto skrzynki e-mail



SPRAWDŹ TERAZ







Dziękuję za Twoje zrozumienie







Zespół weryfikacyjny Microsoft






Microsoft Outlook Copyright (c) 2020 .Inc. Wszelkie prawa 
zastrzeżone.


?

Bug#954320: initialization check failed: GLib version too old (micro mismatch)

[Jörg Frings-Fürst]

Package: libgtk-3-0
Version: 3.24.14-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

on apt update I get:

[quote]
Trigger für libglib2.0-0:amd64 (2.62.5-1) werden verarbeitet ...
Trigger für libgtk-3-0:amd64 (3.24.14-1) werden verarbeitet ...
Cannot load module /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-
ibus.so: GModule (/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-ibus.so)
initialization check failed: GLib version too old (micro mismatch)
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-ibus.so does not export
GTK+ IM module API: GModule (/usr/lib/x86_64-linux-
gnu/gtk-3.0/3.0.0/immodules/im-ibus.so) initialization check failed: GLib
version too old (micro mismatch)
Trigger für libgtk2.0-0:amd64 (2.24.32-4) werden verarbeitet ...
Cannot load module /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-
ibus.so: GModule (/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-
ibus.so) initialization check failed: GLib version too old (micro mismatch)
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-ibus.so does not export
GTK+ IM module API: GModule (/usr/lib/x86_64-linux-
gnu/gtk-2.0/2.10.0/immodules/im-ibus.so) initialization check failed: GLib
version too old (micro mismatch)
[/quote]


CU
Jörg



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

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

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.36.0-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.34.1-2
ii  libatk1.0-0  2.34.1-1
ii  libc62.30-2
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcolord2   1.4.3-4
ii  libcups2 2.3.1-11
ii  libepoxy01.5.4-1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libfribidi0  1.0.8-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-3
ii  libglib2.0-0 2.62.5-1
ii  libgtk-3-common  3.24.14-1
ii  libharfbuzz0b2.6.4-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpango-1.0-0   1.42.4-8
ii  libpangocairo-1.0-0  1.42.4-8
ii  libpangoft2-1.0-01.42.4-8
ii  librest-0.7-00.8.1-1+b1
ii  libwayland-client0   1.18.0-1
ii  libwayland-cursor0   1.18.0-1
ii  libwayland-egl1  1.18.0-1
ii  libx11-6 2:1.6.9-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon00.10.0-1
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 1.10-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.24.14-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.44.0-1
ii  librsvg2-common  2.46.4-1

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
ii  gtk3-engines-xfce 3.2.0-4
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
ii  ibus-gtk3 1.5.22-1
pn  imhangul-gtk3 
ii  libcanberra-gtk3-module   0.30-7
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAl50d7kACgkQCfifPIyh
0l2uohAAzDTU2DKlCGbPQyofUF8/K2KIya16tnPdN8BePaJzpdxmfvAVEfxA8dDz
JQnEhwFLWqYyVFVFrOm6eKx1PCyrUHiwbQgLnoRflksVfeUhPyAbOeQ7K8O6G1ak
C7U6Mvxj9I9qjsPdV9+V0HI8rNd+HVG2bAaQxoIrR5l120P/kak0eAYDB0RSEuSc
DLTU1vGbT4lAgWSENy+A3IWm/3x+JiM9xG1UTuSl8e3Gfd4vwoFMYhEppkU5l2CE
+zT5rQmDv0kRmBX7k08Pllc8iup/qgNillrgM2kKLRmm8TCIehmKxlgt7Tu6XzsL
yBFnwmC+nm4uFrV+D+YVhpFP2H+pkZL2qZ+3qCwZ0kyVat/QJvVJnre6Uju2I0Bw
wBZJOW1/3JvE9ZN/sArbFxDinAxPF7LvGUR5yITWjsgnqJumBPwNlwjnYEUpUsvg
b6wdnefmr6Hy3pdKhb/1sMyVEZuKJQOUQQYmIf1LObnU2+GgNohEtjYYo7znyJTn
yjXaq1Qibrul96ZVy00FCXI4/vdkEoIWBofQC5CgWa3qs2nFRQpTdqjWGQWMlRar
rgu9567IkDZH+2m2LXEGt/YyTQAnX1PEBn9kJFiEnHuuYc+HLLj350kdjxhcCxb1
EPLBpSUu1w4iMTBofOZ3q5XghfNyTl9iEvow9ViYf4OF09nHP1A=
=Q6An
-END PGP SIGNATURE-

Bug#954312: systemd: FTBFS on riscv64: test-seccomp fails: Assertion 'name' failed at src/test/test-seccomp.c:49

[Aurelien Jarno]

On 2020-03-20 01:35, Michael Biebl wrote:
> Am 20.03.20 um 01:32 schrieb Michael Biebl:
> > Have you tested, that seccomp is working on riscv64 with 5.5?
> > Something like this should lead to a blocked ping:
> 

Indeed that test doesn't work, I mean seccomp is ineffective and the
ping succeed. It looks like that I should also update the patch you
pointed, I'll work on that and keep you updated.

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#954234: /etc/init.d/munin has two broken function definitions

[Craig Sanders]

On Thu, Mar 19, 2020 at 04:59:46PM +0100, de...@sumpfralle.de wrote:
> After taking a closer look at the man pages of both shell implementations, 
> this
> seems to be in line with their respective documentations:
> 
> 1) dash
> Syntax: name () command
> Thus *any* command is allowed (including "true").
> 
> 2) bash
> Syntax: name () compound-command
> Here "compound-command" means any non-trivial command, e.g. surrounded by
> braces or "if ...; fi" and so on. A single command ("true") is not explicitly
> mentioned and obviously is rejected.

interesting. i didn't realise dash allowed that.  looks like ksh and ash do too.

> Thus I assume, that you are using bash as your "sh" implementation?

yep. on this particular machine, /bin/sh has been a symlink to /bin/bash since
1994 or so, i've never had any compelling reason to change it (and i really
don't care about a few seconds difference in boot time as i only reboot it
once or twice a year).

i think most of my machines are using bash - but they only have munin-node
installed, and not the munin package.

> I will fix this issue in the next packaging update. Thank you!

thanks.

The "foo() {true;}" version works for bash and dash.

craig

--
craig sanders 

Bug#953982: wine-development: wine in Debian fails to start "Uru", but upstream wine works fine (regression)

[Diafero]

Hi,

> On Thu, Mar 19, 2020 at 8:28 AM Diafero wrote:
>> Version 5.0-3 also seems affected.
> 
> Was the version that worked 4.21-1 or 4.21-2?

It was 4.21-2.

Kind regards
diafero

Bug#954319: libreoffice: reorder libreoffice-core-nogui dependency in -nogui variants

[Jochen Sprickerhof]

Source: libreoffice
Version: 1:6.4.2-1
Severity: wishlist

When installing libreoffice-writer-nogui, libreoffice-core is selected:

# apt-get install --dry-run --no-install-recommends libreoffice-writer-nogui | 
grep libreoffice-core
  libreoffice-common libreoffice-core libreoffice-style-colibre
  libreoffice-common libreoffice-core libreoffice-style-colibre
Inst libreoffice-core (1:6.4.1-1+b1 Debian:unstable [amd64])
Conf libreoffice-core (1:6.4.1-1+b1 Debian:unstable [amd64])

because it's dependency is preferred:

# apt-cache show libreoffice-writer-nogui | grep libreoffice-core
Depends: libreoffice-base-core (= 1:6.4.2-1), libreoffice-core (= 1:6.4.2-1) | 
libreoffice-core-nogui (= 1:6.4.2-1), [..]

Reordering this to libreoffice-core-nogui | libreoffice-core should use
the -nogui variant by default.

I can provide a patch if needed.

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

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

Bug#954318: libreoffice-impress-nogui: depend on libreoffice-draw-nogui (in addition/instead of libreoffice-draw)

[Jochen Sprickerhof]

Package: libreoffice-impress-nogui
Version: 1:6.4.2-1
Severity: normal

As subject says and discussed in #debian-devel.

Thanks!

Jochen

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

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

Versions of packages libreoffice-impress-nogui depends on:
ii  libc62.30-2
ii  libetonyek-0.1-1 0.1.9-3
ii  libgcc-s110-20200312-2
ii  libmwaw-0.3-30.3.15-2
ii  libodfgen-0.1-1  0.1.7-1
ii  libreoffice-core-nogui   1:6.4.2-1
ii  libreoffice-draw 1:6.4.2-1
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.6-1
ii  libstdc++6   10-20200312-2
ii  libuno-cppu3 1:6.4.2-1
ii  libuno-cppuhelpergcc3-3  1:6.4.2-1
ii  libuno-sal3  1:6.4.2-1
ii  libuno-salhelpergcc3-3   1:6.4.2-1
ii  uno-libs-private 1:6.4.2-1
ii  ure  1:6.4.2-1

libreoffice-impress-nogui recommends no packages.

Versions of packages libreoffice-impress-nogui suggests:
pn  bluez  

Versions of packages libreoffice-draw depends on:
ii  libavahi-client3 0.7-5
ii  libavahi-common3 0.7-5
ii  libc62.30-2
ii  libcdr-0.1-1 0.1.6-1
ii  libdbus-1-3  1.12.16-2
ii  libfreehand-0.1-10.1.2-2
ii  libgcc-s110-20200312-2
ii  libglib2.0-0 2.64.1-1
ii  libmspub-0.1-1   0.1.4-1+b2
ii  libmwaw-0.3-30.3.15-2
ii  libodfgen-0.1-1  0.1.7-1
ii  libpagemaker-0.0-0   0.0.4-1
ii  libqxp-0.0-0 0.0.2-1
ii  libreoffice-core-nogui   1:6.4.2-1
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.6-1
ii  libstdc++6   10-20200312-2
ii  libuno-cppu3 1:6.4.2-1
ii  libuno-cppuhelpergcc3-3  1:6.4.2-1
ii  libuno-sal3  1:6.4.2-1
ii  libuno-salhelpergcc3-3   1:6.4.2-1
ii  libvisio-0.1-1   0.1.7-1
ii  libwpg-0.3-3 0.3.3-1
ii  libxml2  2.9.10+dfsg-4
ii  libzmf-0.0-0 0.0.2-1+b2
ii  uno-libs-private 1:6.4.2-1
ii  ure  1:6.4.2-1
ii  zlib1g   1:1.2.11.dfsg-2

-- debconf-show failed

Bug#954317: RM: orthanc [s390x] -- RoM; ANAIS

[Sébastien Jodogne]

Package: ftp.debian.org
Severity: normal

One unit test fails on s390x architecture:
https://buildd.debian.org/status/fetch.php?pkg=orthanc=s390x=1.6.0%2Bdfsg-1=1584552281=0

[ RUN  ] ParsedDicomFile.ToJsonFlags2
/<>/UnitTestsSources/FromDcmtkTests.cpp:732: Failure
Expected equality of these values:
  "Pixels"
  v["7fe0,0010"].asString()
Which is: "iPexsl"
[  FAILED  ] ParsedDicomFile.ToJsonFlags2 (0 ms)

The "iPexsl" value indicates a problem related to endianness in
Orthanc. As the upstream package has not access to a Big-endian
computer, we cannot reproduce this issue.

Bug#944352: scummvm: screen gets black and/or flickering in full screen mode using X11 sessions

[Thorsten Ehlers]

Dear maintainer,

mesa 20.0.2-1 update released today fixed the problem for me so this bug
report can be closed.

Thanks to all Debian maintainers! :)

Thorsten

Bug#561919: 親愛的，我需要你的幫助。

[Rebekah Issah]

你好，

可以用英語交流嗎？我使用Google翻譯器將英語翻譯成您的語言，以便您更好地理解。

我是也門婦女麗貝卡·伊薩（Rebekah
Issah）夫人。我希望由於也門長時間的內亂/戰爭以及基地組織武裝分子的日常生活威脅而遷移到貴國。在2018年3月23日針對我們的家庭的襲擊中，我已經失去了家人，丈夫，兒子和女兒的死亡之手，以結束我們的家庭。在十字路口時，我不在附近。當襲擊襲擊了我們的房屋，殺死了我心愛的丈夫，兒子和女兒並燒毀房屋時，我正在醫院接受檢查。這封信給我流淚。他（我的已故丈夫）是在也門石油城非常成功的承包商，在他過早去世之前，他曾私下經營金粉和金條。可以預料的是，他留下了一些合理的錢，我希望將這些錢投資到您所在國家的房地產，旅遊業，酒店管理和其他有趣的領域。

您可能知道，也可能不知道，美國和歐盟實施的製裁幾乎不可能在也門成功進行任何類型的投資，甚至將資金從這裡轉移到世界其他地方。因此，我非常有信心地與您聯繫，希望您能幫助我將這筆錢用於您的國家進行投資：

請我想知道以這種方式為我提供幫助的方便程度。我可動用的全部資本為九百萬美元。我把錢偷偷地鎖在行李箱裡，然後把錢存放在薩那的紅十字會上。我寫給您的真誠意圖是懇請您接受存錢罐。這是因為戰後我們無法從這裡進行任何銀行轉帳。這些是我現在關注的主要問題。我會給您總金額的20％，作為您幫助我的好處。

我必須抓住這次機會，因為除了信任別人，我別無選擇。為了避免家庭血統的終結，我無法冒著生命危險。自從我丈夫，兒子和女兒去世以來，作為一個女人。我應該在和平的環境中過上體面的生活，我將搬遷到您的國家，並根據法律，您的建議和支持投資這筆錢；我們可以共同努力並實現。

我們期待您的積極回應，並在收到您的信息後為您提供更多詳細信息。

您忠誠的，

麗貝卡一世