Bug#946648: crash report log

[Peter Newey]

Running for 80 minutes ok then another crash :

peter@peter-mate:~$ chromium
[30442:30442:1214/051955.275889:ERROR:vaapi_wrapper.cc(417)] vaInitialize 
failed: unknown libva error
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
[32194:1:1214/052005.144949:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32194:1:1214/052005.146052:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32194:1:1214/052005.156409:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32194:1:1214/052005.159326:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32167:1:1214/052006.052325:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32167:1:1214/052006.065720:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32167:1:1214/052006.078173:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32167:1:1214/052006.080282:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32167:1:1214/052006.143199:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32167:1:1214/052006.144240:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
[32167:1:1214/052006.634797:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32167:1:1214/052006.636714:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32221:1:1214/052008.174953:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32221:1:1214/052008.177207:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32221:1:1214/052008.180813:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32221:1:1214/052008.182072:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32221:1:1214/052008.183491:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32221:1:1214/052008.184835:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32221:1:1214/052008.186613:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32221:1:1214/052008.187528:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32221:1:1214/052008.189257:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[32221:1:1214/052008.190141:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
Fontconfig error: Cannot load default config file

Bug#946706: ITS: heimdall-flash

[Nicholas D Steeves]

Source: heimdall-flash
Severity: important
Control: owner -1 !

Following up on Bug #872788, where I sent an email with the following:

  Subject: heimdall-flash: package appears to be a salvaging candidate
  Date: Wed, 24 Jul 2019 19:31:32 -0400

and received an ACK "go ahead" from Moritz, I have begun work on this
package and intend to salvage it.

Best,
Nicholas

Bug#946704: stretch-pu: package php-horde/5.2.13+debian0-1+deb9u1

[Roberto C. Sanchez]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Please find attached a proposed debdiff for php-horde.  The change fixes
CVE-2019-12095, which the security team has classified as ,
deeming it a minor issue which can be fixed via a point release.  May I
have permission to upload to stretch-proposed-updates?

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

Kernel: Linux 4.19.0-6-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)
diff -Nru php-horde-5.2.13+debian0/debian/changelog 
php-horde-5.2.13+debian0/debian/changelog
--- php-horde-5.2.13+debian0/debian/changelog   2016-12-18 16:01:07.0 
-0500
+++ php-horde-5.2.13+debian0/debian/changelog   2019-12-13 21:10:06.0 
-0500
@@ -1,3 +1,9 @@
+php-horde (5.2.13+debian0-1+deb9u1) stretch; urgency=high
+
+  * Fix CVE-2019-12095: Stored XSS vuln in the Horde Cloud Block.
+
+ -- Roberto C. Sanchez   Fri, 13 Dec 2019 21:10:06 -0500
+
 php-horde (5.2.13+debian0-1) unstable; urgency=medium
 
   * New upstream version 5.2.13+debian0
diff -Nru 
php-horde-5.2.13+debian0/debian/patches/0002-CVE-2019-12095-Fix-XSS-vuln-in-the-Horde-Cloud-Block.patch
 
php-horde-5.2.13+debian0/debian/patches/0002-CVE-2019-12095-Fix-XSS-vuln-in-the-Horde-Cloud-Block.patch
--- 
php-horde-5.2.13+debian0/debian/patches/0002-CVE-2019-12095-Fix-XSS-vuln-in-the-Horde-Cloud-Block.patch
 1969-12-31 19:00:00.0 -0500
+++ 
php-horde-5.2.13+debian0/debian/patches/0002-CVE-2019-12095-Fix-XSS-vuln-in-the-Horde-Cloud-Block.patch
 2019-12-13 21:10:06.0 -0500
@@ -0,0 +1,50 @@
+From 81a7b53973506856db67e7f0b0263be29528aa75 Mon Sep 17 00:00:00 2001
+From: Michael J Rubinsky 
+Date: Sat, 20 Apr 2019 17:34:41 -0400
+Subject: [PATCH] Fix XSS vuln in the Horde Cloud Block.
+
+---
+ horde-5.2.13/lib/Block/Cloud.php  | 6 +-
+ horde-5.2.13/services/portal/cloud_search.php | 2 +-
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/horde-5.2.13/lib/Block/Cloud.php 
b/horde-5.2.13/lib/Block/Cloud.php
+index 92a44255..9df5bf3c 100644
+--- a/horde-5.2.13/lib/Block/Cloud.php
 b/horde-5.2.13/lib/Block/Cloud.php
+@@ -13,6 +13,10 @@ class Horde_Block_Cloud extends Horde_Core_Block
+ $this->_name = _("Tag Cloud");
+ }
+ 
++protected function _escapeJs($string)
++{
++return str_replace("\n", '\n', str_replace('"', '\"', 
addcslashes(str_replace("\r", '', (string)$string), "\0..\37'\\")));
++}
+ /**
+  */
+ protected function _content()
+@@ -21,7 +25,7 @@ class Horde_Block_Cloud extends Horde_Core_Block
+ foreach ($this->_getTags() as $tag) {
+ $cloud->addElement(
+ $tag['tag_name'], '#', $tag['count'], null,
+-'doSearch(\'' . $tag['tag_name'] . '\'); return false;');
++'doSearch(\'' . 
htmlspecialchars($this->_escapeJs($tag['tag_name'])) . '\'); return false;');
+ }
+ 
+ Horde::startBuffer();
+diff --git a/horde-5.2.13/services/portal/cloud_search.php 
b/horde-5.2.13/services/portal/cloud_search.php
+index d72da96e..0d44b5a5 100644
+--- a/horde-5.2.13/services/portal/cloud_search.php
 b/horde-5.2.13/services/portal/cloud_search.php
+@@ -43,7 +43,7 @@ foreach ($results as $result) {
+ echo ' ' .
+  (empty($result['icon']) ? 
Horde_Themes_Image::tag(Horde_Themes::img($result['app'] . '.png', array('app' 
=> $result['app'])), array('alt' => $result['app'])) : '') .
+  Horde::link($result['view_url'], '', '', '', '', '', '', 
array('style' => 'margin:4px')) .
+- (empty($result['icon']) ? $result['title'] : '') .
++ (empty($result['icon']) ? htmlspecialchars($result['title']) : '') .
+  '' . 
$result['desc'] . '';
+ }
+ echo '';
+-- 
+2.20.1
+
diff -Nru php-horde-5.2.13+debian0/debian/patches/series 
php-horde-5.2.13+debian0/debian/patches/series
--- php-horde-5.2.13+debian0/debian/patches/series  2016-12-18 
16:01:07.0 -0500
+++ php-horde-5.2.13+debian0/debian/patches/series  2019-12-13 
21:10:06.0 -0500
@@ -1 +1,2 @@
 0001-Fix-rewrite-base.patch
+0002-CVE-2019-12095-Fix-XSS-vuln-in-the-Horde-Cloud-Block.patch

Bug#946705: buster-pu: package php-horde/5.2.20+debian0-1+deb10u1

[Roberto C. Sanchez]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please find attached a proposed debdiff for php-horde.  The change fixes
CVE-2019-12095, which the security team has classified as ,
deeming it a minor issue which can be fixed via a point release.  May I
have permission to upload to buster-proposed-updates?

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

Kernel: Linux 4.19.0-6-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)

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAl30XTYACgkQldFmTdL1
kULRBQ/+OSNVNYn6ChtrTCHDwNqI1R1HP2LnfQOZNiANcE6IcXrHkDsRqzA8jgsX
8mXAgd2EWyW2t3BrNqP2lK1v7Aw4XBp2YMDXtIG/iQMbTOZn7OaW3UnGaaUUJQmO
F8seqyVcqfufbveEvMAWOlf717ef1DPtxJQ/hOl3a//AEzvuOnU8VnmtnSHTjyOI
l1Dcw8CcIR1gI6vunDzzOY2bRAiHOyLaTXj0NKmLpZY1a51B9YTGLQP0hhBb27I2
4sApY1+6DnjiCW+8x7X/L+CTjtkorbP3yAUK4cdn7dosxs5Xb8Eb251HVKhfuk8X
dFPoWI0edKfJ8YIV0rFeRDhuB9PEs97fDX1o8pGfam55yNsQGXlQ/7oj/OtVC+g3
oZ62xDSGkdNkjgFygftkDT4VbmfN09g9BkthCUiqYfEPLRZYx5myngpzXOKGGkAd
Ea4fqZCN4P6N/CGwITYZn5jcNguYzGOluLbXjAVc2r+r4tBwLkLjCvLvBKlYepwb
yYi/lxi3xUJJdl86YZ8YehRJccXXqsfgWXXRB6U4iognWd0Cu3Q7p3MrAkzF1bKw
xh04NfhyGfHJ35opVTP56TQldA8UtJHN9Db/OPaTK6nJ9sVhvhf1pgQraiJYUSyZ
qoIGatMpqwG6KDCIXEXAKw9gLFRT5Y3pou3aYDuNhXizUwSGJmg=
=lu3y
-END PGP SIGNATURE-
diff -Nru php-horde-5.2.20+debian0/debian/changelog 
php-horde-5.2.20+debian0/debian/changelog
--- php-horde-5.2.20+debian0/debian/changelog   2018-10-25 15:08:21.0 
-0400
+++ php-horde-5.2.20+debian0/debian/changelog   2019-12-13 21:13:53.0 
-0500
@@ -1,3 +1,9 @@
+php-horde (5.2.20+debian0-1+deb10u1) buster; urgency=high
+
+  * Fix CVE-2019-12095: Stored XSS vuln in the Horde Cloud Block.
+
+ -- Roberto C. Sanchez   Fri, 13 Dec 2019 21:13:53 -0500
+
 php-horde (5.2.20+debian0-1) unstable; urgency=medium
 
   * New upstream version 5.2.20+debian0
diff -Nru 
php-horde-5.2.20+debian0/debian/patches/0002-CVE-2019-12095-Fix-XSS-vuln-in-the-Horde-Cloud-Block.patch
 
php-horde-5.2.20+debian0/debian/patches/0002-CVE-2019-12095-Fix-XSS-vuln-in-the-Horde-Cloud-Block.patch
--- 
php-horde-5.2.20+debian0/debian/patches/0002-CVE-2019-12095-Fix-XSS-vuln-in-the-Horde-Cloud-Block.patch
 1969-12-31 19:00:00.0 -0500
+++ 
php-horde-5.2.20+debian0/debian/patches/0002-CVE-2019-12095-Fix-XSS-vuln-in-the-Horde-Cloud-Block.patch
 2019-12-13 21:13:53.0 -0500
@@ -0,0 +1,50 @@
+From 81a7b53973506856db67e7f0b0263be29528aa75 Mon Sep 17 00:00:00 2001
+From: Michael J Rubinsky 
+Date: Sat, 20 Apr 2019 17:34:41 -0400
+Subject: [PATCH] Fix XSS vuln in the Horde Cloud Block.
+
+---
+ horde-5.2.20/lib/Block/Cloud.php  | 6 +-
+ horde-5.2.20/services/portal/cloud_search.php | 2 +-
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/horde-5.2.20/lib/Block/Cloud.php 
b/horde-5.2.20/lib/Block/Cloud.php
+index 92a44255..9df5bf3c 100644
+--- a/horde-5.2.20/lib/Block/Cloud.php
 b/horde-5.2.20/lib/Block/Cloud.php
+@@ -13,6 +13,10 @@ class Horde_Block_Cloud extends Horde_Core_Block
+ $this->_name = _("Tag Cloud");
+ }
+ 
++protected function _escapeJs($string)
++{
++return str_replace("\n", '\n', str_replace('"', '\"', 
addcslashes(str_replace("\r", '', (string)$string), "\0..\37'\\")));
++}
+ /**
+  */
+ protected function _content()
+@@ -21,7 +25,7 @@ class Horde_Block_Cloud extends Horde_Core_Block
+ foreach ($this->_getTags() as $tag) {
+ $cloud->addElement(
+ $tag['tag_name'], '#', $tag['count'], null,
+-'doSearch(\'' . $tag['tag_name'] . '\'); return false;');
++'doSearch(\'' . 
htmlspecialchars($this->_escapeJs($tag['tag_name'])) . '\'); return false;');
+ }
+ 
+ Horde::startBuffer();
+diff --git a/horde-5.2.20/services/portal/cloud_search.php 
b/horde-5.2.20/services/portal/cloud_search.php
+index d72da96e..0d44b5a5 100644
+--- a/horde-5.2.20/services/portal/cloud_search.php
 b/horde-5.2.20/services/portal/cloud_search.php
+@@ -43,7 +43,7 @@ foreach ($results as $result) {
+ echo ' ' .
+  (empty($result['icon']) ? 
Horde_Themes_Image::tag(Horde_Themes::img($result['app'] . '.png', array('app' 
=> $result['app'])), array('alt' => $result['app'])) : '') .
+  Horde::link($result['view_url'], '', '', '', '', '', '', 
array('style' => 'margin:4px')) .
+- (empty($result['icon']) ? $result['title'] : '') .
++ (empty($result['icon']) ? htmlspecialchars($result['title']) : '') .
+  '' . 
$result['desc'] . '';
+ }
+ echo '';
+-- 
+2.20.1
+
diff -Nru 

Bug#913220: Avoid log spamming

[Daniel Echeverry]

forwarded 913220 https://github.com/Guake/guake/issues/1694
thanks

-- 
Daniel Echeverry
Debian Developer
https://wiki.debian.org/DanielEcheverry
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#922259: python-libnacl: FTBFS (ValueError: byte must be in range(0, 256))

[Colin Watson]

Control: forwarded -1 https://github.com/saltstack/libnacl/pull/115

On Wed, Apr 03, 2019 at 11:06:24PM +0200, Santiago Vila wrote:
> > ==
> > ERROR: test_verify32 (unit.test_verify.TestVerify)
> > --
> > Traceback (most recent call last):
> >   File 
> > "/<>/.pybuild/cpython3_3.7_libnacl/build/tests/unit/test_verify.py",
> >  line 30, in test_verify32
> > v32x[libnacl.randombytes_random() & 31] += 1
> > ValueError: byte must be in range(0, 256)
> 
> Hi. This is still happening (randomly) on reproducible-builds.
> 
> I could offer ssh access to a machine where this randomness is
> reproducible, but I believe the randomness is intrisic to the
> (wrongly designed) test and maybe it happens on any machine
> as far as you try enough times.
> 
> Can you execute test_verify32 in a loop and report if it fails
> randomly or not for you? (Or tell me the way to do it).

Indeed, it's easy to reproduce that way.  I tracked this down and
proposed a fix upstream:

  https://github.com/saltstack/libnacl/pull/115

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#946703: New upstream homepage

[Joao Eriberto Mota Filho]

Package: unhide
Version: 20130526-4
Severity: normal

Hi folks,

There is a new upstream homepage[1], created by original upstream, however
without releases[2] yet.

[1] https://github.com/YJesus/Unhide
[2] https://github.com/YJesus/Unhide/issues/2

Regards,

Eriberto

Bug#946702: Haphazard man page SEE ALSOs and footers

[積丹尼 Dan Jacobson]

Package: wireless-tools
Version: 30~pre9-13+b1

$ dlocate -man wireless-tools | COLUMNS=80 xargs -n 2 man | col -b | grep -A 3 
SEE | egrep -v SEE\|^$
   iwconfig(8), iwlist(8), iwspy(8), iwpriv(8), iwevent(8).
wireless-tools   4 March 2004  WIRELESS(7)
--
   ifconfig(8), iwspy(8), iwlist(8), iwevent(8), iwpriv(8), wireless(7).
wireless-tools   30 March 2006 IWCONFIG(8)
--
   iwconfig(8), iwlist(8), iwspy(8), iwpriv(8), wireless(7).
net-tools23 June 2004   IWEVENT(8)
--
   iwconfig(8), ifconfig(8), iwspy(8), iwpriv(8).
wireless-tools 02 December 2003 IWGETID(8) 
<<< I never knew this man page existed! That's because it is missing from the 
SEE ALSO of the others!
--
   iwconfig(8), iwspy(8).  iwevent(8), iwpriv(8), wireless(7).   <<<"." 
should be ","
wireless-tools   13 April 2006   IWLIST(8)
--
   iwconfig(8), iwlist(8), iwevent(8), iwspy(8), wireless(7).
net-tools   31 October 1996  IWPRIV(8)
--
   iwconfig(8), iwlist(8), iwevent(8), iwpriv(8), wireless(7).
net-tools   31 October 1996   IWSPY(8)

Some list more, some less, not due to relevance, but instead accident.
Please just make sure each lists all the others!

By the wqy, half of the above say "net-tools", but that is a different package!
$ dlocate -man net-tools
5 ethers
8 arp
8 ifconfig
8 iptunnel
8 mii-tool
8 nameif
8 netstat
8 plipconfig
8 rarp
8 route
8 slattach

Maybe long ago they were born that way, but now it is wrong.

Bug#946701: ITP: libsyntax-keyword-dynamically-perl -- module to dynamically change the value of a variable

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libsyntax-keyword-dynamically-perl
  Version : 0.01
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Syntax-Keyword-Dynamically
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to dynamically change the value of a variable

Syntax::Keyword::Dynamically provides a syntax plugin that implements a
single keyword, dynamically, which alters the behaviour of a scalar
assignment operation. Syntactically and semantically it is similar to the
built-in perl keyword local, but is implemented somewhat differently to give
two key advantages over regular local:

 - You can dynamically assign to lvalue functions and accessors.
 - You can dynamically assign to regular lexical variables.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#946665: mediawiki: autopkgtests may fail due to stderr messages

[Kunal Mehta]

Hi Mathieu,

Thanks for filing the bug. In the past (c.f. #911829), failing on stderr
has identified problems in MediaWiki when a new PHP version is released,
so I would like to keep the current behavior if possible.

Do you have any ideas or suggestions on other ways we could avoid this
problem? Would `sudo ... 2>&1` for all invocations be good enough?

Thanks,
-- Kunal

On 2019-12-12 17:59, Mathieu Trudel-Lapierre wrote:
> Package: mediawiki
> Version: 1:1.31.5-3
> Severity: minor
> 
> Dear Maintainer,
> 
> mediawiki autopkgtests may fail with sudo 1.8.29.
> 
> The new sudo version handles setting limits differently (actually honours 
> pam_limits),
> and as such you'd get an Operation not supported error when it tries to set 
> RLIMIT_CORE
> on some architectures, depending on the infrastructure being used.
> 
> This is the only message showing in stderr, and thus fails the tests because 
> of stderr.
> 
> I suggest adding allow-stderr to all the tests in debian/tests/control except 
> for lint
> to allow the presence of messages on stderr while running the tests.
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers focal
>   APT policy: (500, 'focal')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.3.0-23-generic (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=fr_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_CA:fr (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages mediawiki depends on:
> pn  apache2 | httpd
> pn  mediawiki-classes  
> ii  mime-support   3.64ubuntu1
> pn  php
> pn  php-common 
> pn  php-mbstring   
> pn  php-mysql | php-pgsql | php-sqlite3 | php-mysqlnd  
> pn  php-xml
> 
> Versions of packages mediawiki recommends:
> pn  default-mysql-server | virtual-mysql-server | postgresql-co  
> pn  php-apcu 
> pn  php-cli  
> pn  php-curl 
> pn  php-intl 
> pn  php-wikidiff2
> ii  python3  
> 3.7.5-1ubuntu1
> 
> Versions of packages mediawiki suggests:
> pn  clamav
> pn  imagemagick | php-gd  
> pn  memcached 
> 



signature.asc
Description: OpenPGP digital signature

Bug#946491: unattended-upgrades: 100% of at least one CPU core consumed until killed daily via debian

[Colin Williams]

ps -p 4017 -o %cpu,cmd
%CPU CMD
92.9 /usr/bin/python3 /usr/bin/unattended-upgrade --download-only

Bug#946700: apt-listchanges: mail notifying of changes has (MIME-?) garbled Subject line

[The Wanderer]

Package: apt-listchanges
Version: 3.21
Severity: minor


(I have a vague memory that I have reported this once before, but I am
not having any luck finding any record of such a report, so I'm filing
this again.)


Dear Maintainer,

First, for background:

When I install package updates via apt-get (which is usually at least
once a week, on average), apt-listchanges sends a mail to root
containing the changelogs which were displayed prior to the final
confirmation prompt for that upgrade session.

For reasons which make sense but which I have not bothered to track
down, when mail is sent to root, it shows up in the pending local mail
queue for my non-root local account, which is named wanderer.

Whenever a new message has arrived in that queue, every time a command I
initiate from a console or terminal exits, that terminal reports a
message along the lines of "You have new mail.". This happens once per
terminal, meaning that if I don't clear the pending mail, I get that
notification repeatedly. In order to prevent that, I habitually read the
mail (thus transferring it from that queue into ~/.mbox) immediately
after confirming the update session.

The only mail client which I have configured to read from this local
mail queue is the one invoked by the command 'mail', which in my (AFAIK,
default) configuration is bsd-mailx, which is installed at version
8.1.2-0.20180807cvs-1+b1.

All of the above is normal and expected, and I do not consider it a
problem.


The actual problem I'm reporting is that when I do this, the Subject
line of the mail which is sent by apt-listchanges appears in a garbled
form. For example (and I'm not entirely positive this won't be
line-wrapped):

---8<---
$ mail
Mail version 8.1.2 01/15/2001.  Type ? for help.
"/var/mail/wanderer": 1 message 1 new
>N  1 r...@apologia.fra  Fri Dec 13 18:40  318/10860
=?utf-8?q?apt-listchanges=3A_changelogs_for_apologia?=
&
---8<---

If I'm understanding matters correctly, this garbling is actually MIME
character encoding.

This was not always the case. Back in the day, these mails would have
un-garbled Subject lines, more along the lines of 'apt-listchanges:
changelogs for apologia'. This is the behavior I would have preferred to
see continue, and would like to see return.

The final mail I have in my archive with this older, non-garbled form is
dated 2016-08-21, and includes the NEWS entry for installing
apt-listchanges version 3.3. The changes summarized in that entry
include migrating the package to python3; I suspect, but am not certain,
that this may be the relevant change.

The first mail I have with this garbled form is dated 2016-08-26.

I did not report this initially because I assumed that it would be
noticed and corrected in short order. After that, I more or less got
used to ignoring the issue, but as it's still suboptimal I'm now finally
reporting it.


If mail clients are not expected to be able to consume this format and
present correctly-formatted Subject lines for user viewing, then
apt-listchanges should not be emitting this format, but should emit the
bare-text Subject line just as was apparently done prior to the 3.x
version series.

If mail clients are expected to be able to consume this format and
present correctly-formatted Subject lines for user viewing, then the
fact that the apparently-default local-queue mail client in a Debian
environment presents this 'garbled' form would seem to be a bug either
in that client or in the choice of default local-queue mail client, and
this bug should be reassigned appropriately.


Although I do not have immediate access to confirm this, I believe that
I have seen this behavior happen on at least two machines (with at least
slightly different configurations), so I don't think it's likely to be a
purely local problem.

If there's anything I can do to help track this down and get this
behavior corrected, please let me know. In particular, if knowing
everything that was upgraded in that upgrade session would be helpful, I
can provide a copy of the exact changelog mail from that upgrade session.


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_WARN
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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages apt-listchanges depends on:
ii  apt1.8.4
ii  debconf [debconf-2.0]  1.5.73
ii  python33.7.5-1
ii  python3-apt1.8.4+b1
ii  python3-debconf1.5.73
ii  sensible-utils 0.0.12+nmu1
ii  ucf3.0038+nmu1

apt-listchanges recommends no packages.

Versions of packages apt-listchanges suggests:
ii  chromium [www-browser] 

Bug#946699: wine: Lotus Notes 6.5 font drop down list corrupt after upgrade to buster

[Santiago Vila]

reassign 946699 wine
thanks

I hope this is correct.

Bug#946699: wine: Lotus Notes 6.5 font drop down list corrupt after upgrade to buster

[Wolfgang Rosner]

Package: hello
Version: 4.0-2 

I accidentially upgraded my system from squeeze to buster - including
wine
I use an old Lotus Notes 6.5 client which worked fine under wine in
squeeze.

After upgrade, the drop down list for the fonts is corrupt.

Example (no guarantee for the spelling of the bullshit)
-8<--
d
ddress Book
d-?
d+NäUiBioIFTdZ|
DD||-N
Default MultiLingu|  &
Default Sans Serif
Default Serif
Domain
ol@
e
ed
ersion >>. 2|
-8<--


the correct list I can remember as
-8<--
Default MultiLingual
Default Mono
Default Sans Serif
Default Serif
-8<--

So as it looks, some of the correct entries are still there, some are
missing or damaged, and a lot of bullshit is mixed in.
Everything is sorted in alphabetical order.

The error is the same in the edit area, in the property window and in
the default font configuration menue.
So it's not a GUI thing related to some widgeet, but an error in
retrieving the font list, I think.

For the subset of fonts that are correct, I can select them and
properly format text. If I select errorneous font, I get a message 
"Specified font is not configured in system."

I add a screenshot for clarity.
Part of the bullshit looks like sensible notes information.
May that hint to sth like a buffer overrun?

I tried to pin down the cause by using different wine versions from
WineHQ repo and from PlayLinux, but no difference.

I tried different font lists with winetricks - no difference.

I installed a new empty wine prefix with winetricks and installed a
fresh notes within to exclude corrupt data - same picture.

I have a visio and a LTspice in different wineprefixes where I could
not find a similiar error.

I suspect that Notes is using some specific menue call to get its font
list from down the OS library cascade that somewhere got broke.

Any help is appreciated,
Im glad to supply test data upon instruction.


regards

Wolfgang Rosner

Bug#945263: f2py3.8 fails with "Entry point not found" exception

[Andreas Beckmann]

Followup-For: Bug #945263
Control: found -1 1:1.17.4-4

This change caused the arch:all build to fail:
https://buildd.debian.org/status/fetch.php?pkg=numpy=all=1%3A1.17.4-4=1576093048=0

[...]
# tweak the entry_points list to include all supported versions
for v in 3.8 3.7; do \
if ! grep $v ; \
then \
echo "f2py$v = numpy.f2py.f2py2e:main" >>  ; \
fi; \
done
/bin/sh: 4: Syntax error: ";" unexpected
make[1]: *** [debian/rules:51: override_dh_python3] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:15: binary-indep] Error 2


Andreas

Bug#946698: libopenblas-dev: openblas.pc is not detected by plkg-config (nor by locate, BTW).

[Emmanuel Charpentier]

Package: libopenblas-dev
Version: 0.3.7+ds-5
Severity: normal

The installation of libopenblas and libopenblas-dev does not seem to allow the
normal use of openblasin a sn autotools-based source program.

A detailed example is documented in https://trac.sagemath.org/ticket/27870
starting at comment 28 ; a configure script running on a machine having pkg-
config, libopenblas and libopenblas-dev is unable to fing the openblas.pc file
installed in the "normal" locationgiven at installation. See the above ticked
for details.

I also note that the locate command is unable to find this file.



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

Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=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 libopenblas-dev depends on:
ii  libopenblas-pthread-dev  0.3.7+ds-5
ii  libopenblas0 0.3.7+ds-5

libopenblas-dev recommends no packages.

libopenblas-dev suggests no packages.

-- no debconf information

Bug#946697: libjs-openlayers: Newer version availiable since 2014

[Jack Underwood]

Package: libjs-openlayers
Version: 2.13.1+ds2-6
Severity: wishlist

Dear Maintainer,

According to the openlayers website (https://openlayers.org/) about previous 
versions v2: v2.13.1 (July 2013 i.e. really old),
the first stable release of v3 came out on the 29th Aug 2014, with v6.1.1 out 
now I was wondering why we have such an old
version of the libs in our repository.

I have just started using this package and so haven't noticed too many problems 
apart from an old API and a warning in firefox:
.controllers/Controllers is deprecated. Do not use it for UA detection.

Maybe I will find more problems as I continue working with this package but for 
now I was just wondering why this package hasn't
had a new version uploaded for so long.

Best,
Jack

Bug#945055: linux: CPU runs at considerably higher temperatures

[Christoph Anton Mitterer]

btw: 5.3.15-1 seems to be still affected.


While I see mostly "normal" temperatures right after boot (and when
everything has settled)... after some point in time, tmeperatures get
up and remain at high levels, e.g. :
  Package id 0:  +81.0°C  (high = +100.0°C, crit = +100.0°C)
  Core 0:+75.0°C  (high = +100.0°C, crit = +100.0°C)
  Core 1:+74.0°C  (high = +100.0°C, crit = +100.0°C)
even though top shows an effectively idle system.


Cheers,
Chris.

Bug#945055: linux: CPU runs at considerably higher temperatures

[Christoph Anton Mitterer]

Control: reassign -1 linux
Control: retitle -1 linux: CPU runs at considerably higher temperatures

Reassigning to the kernel, since the problem is likely there.

Bug#926922: kodi: Please package new upstream release

[Olly Betts]

On Fri, Apr 12, 2019 at 11:13:51AM +0200, Bálint Réczey wrote:
> The 18.1 version is out and the package is in the works:
> https://salsa.debian.org/multimedia-team/kodi
> 
> I can't upload it yet even to experimental because flatbuffers is not
> in the archive yet.

Just to note that's no longer a blocker, as of about a week ago:

https://tracker.debian.org/pkg/flatbuffers

(It needs a source-only upload to migrate to testing, but it's available
in unstable).

Cheers,
Olly

Bug#946696: RFS: python-blosc/1.8.1+ds1-1 [RC] [QA] -- Python 3 bindings for the Blosc meta-compressor

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "python-blosc"

* Package name : python-blosc
Version : 1.8.1+ds1-1
Upstream Author : Francesc Alted franc...@blosc.org
* URL : https://github.com/Blosc/python-blosc
* License : BSD-3-clause
* Vcs : https://salsa.debian.org/python-team/modules/python-blosc
Section : python

It builds those binary packages:

python3-blosc - Python 3 bindings for the Blosc meta-compressor
python-blosc-doc - Python bindings for the Blosc meta-compressor (docs)

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-blosc/python-blosc_1.8.1+ds1-1.dsc


Changes since the last upload:

* QA upload
* New upstream version 1.8.1+ds1
* Create 0002-platform-linux_distribution-is-gone-in-python-3.8.patch
closes: #944320
* Added minimum version on libblosc-dev in b-d
* Bump dh to 12
* Remove python2 package under recommends, for doc package.
* Change copyright from Expat to BSD-3 for upstream files.



This package is part of the ongoing testing transition to python 3.8. 
The current version ftbfs.


Regards,
Håvard

Bug#942108: ufw: enabling ufw is breaking the INPUT chain

[Jamie Strandboge]

On Thu, 10 Oct 2019, Jonathan Dowland wrote:

> Package: ufw
> Version: 0.36-1
> Severity: important
> 
> Dear Maintainer,
> 
> Post-buster upgrade, and ufw is no longer functioning correctly. I'm using
> ip(6)tables-legacy, rather than the newer xtables stuff, for interoperability
> with docker. My ufw ruleset has several ALLOWs, e.g.
> 
> # ufw status | grep 22
> 22 ALLOW   Anywhere
> 
> (taken when ufw is "running").
> 
> However upon first starting ufw ("ufw enable"), all incoming traffic to the
> host is dropped. Via the console I can see that this is because the INPUT
> chain policy has been set to DENY, and the ufw tables are not hooked in
> properly. Excerpts from "iptables-save" after "ufw enable":
> 
> *filter
> :INPUT DROP [2943:317505]
> :FORWARD DROP [0:0]
> :OUTPUT ACCEPT [80:9298]
> …
> -A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
> …
> 
> So great, my rules are encoded into the ufw-user-input table fine, but that
> table is not hooked into INPUT : iptables-save | grep "^-A INPUT" is empty.
> 

I cannot reproduce on an up to date buster system:

$ sudo update-alternatives --config iptables
There are 2 choices for the alternative iptables (providing
/usr/sbin/iptables).

  SelectionPath   Priority   Status

* 0/usr/sbin/iptables-nft  20auto mode
  1/usr/sbin/iptables-legacy   10manual mode
  2/usr/sbin/iptables-nft  20manual mode

Press  to keep the current choice[*], or type selection number: 1
update-alternatives: using /usr/sbin/iptables-legacy to provide
/usr/sbin/iptables (iptables) in manual mode


$ sudo ufw allow 22
$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

$ sudo iptables-save |grep '\-A INPUT'
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input

(note the user chains are added to the end of the before chains with '-A
ufw-before-input -j ufw-user-input')

So everything is working ok. Do you have other firewall software
installed? Eg, iptables-persistent or similar?

Is it possible that you have software that is using the nft backend and
not legacy? Is something calling iptables-legacy* directly but
alternatives aren't setup correctly?

-- 
Email: ja...@strandboge.com
IRC:   jdstrand

Bug#946561: Bug #946561

[Brian Potkin]

On Wed 11 Dec 2019 at 21:04:58 +0100, Stefano Fabri wrote:

> Try to apt-get install hplip when you have in the system python >=3.8
> (https://packages.debian.org/experimental/python3).
> 
> In this status hplip is not installable.

That's better; I can do something now instead of guessing.

After installing python3 from experimental:

root@test:~# apt install hplip -s
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 hplip : Depends: python3 (< 3.8) but 3.8.0-2 is to be installed
 Recommends: printer-driver-postscript-hp but it is not going to be 
installed
E: Unable to correct problems, you have held broken packages.
root@test:~#

Cheers,

Brian.

Bug#946289: ufw: fails to start with iptables 1.8.4

[Jamie Strandboge]

On Fri, 06 Dec 2019, Antonio Terceiro wrote:

> Package: ufw
> Version: 0.36-1
> Severity: grave
> Justification: renders package unusable
> 
> This started since the latest upgrade of iptables (1.8.4). Reverting to
> 1.8.3 (testing) makes it work again.
> 
> This is the contents of the journal for ufw.service:
> 
> -- Logs begin at Thu 2019-12-05 14:15:18 -03, end at Fri 2019-12-06 13:45:35 
> -03. --
> dez 05 14:15:18 lemur ufw-init[455]: Bad argument `DROP'
> dez 05 14:15:18 lemur ufw-init[455]: Error occurred at line: 4
> dez 05 14:15:18 lemur ufw-init[455]: Try `iptables-restore -h' or 
> 'iptables-restore --help' for more information.

I can confirm this. It looks like iptables-restore and iptables6-restore
in 1.8.4 has broken -n behavior with the nft varieties.

Create some simple policy:

$ cat /tmp/pol
*filter
# builtin chains
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

With 1.8.2-4 on buster:

$ cat /tmp/pol | sudo /usr/sbin/iptables-legacy-restore -n
$ cat /tmp/pol | sudo /usr/sbin/iptables-nft-restore -n
$

With 1.8.4-1 on sid:
$ cat /tmp/pol | sudo /usr/sbin/iptables-legacy-restore -n
$ cat /tmp/pol | sudo /usr/sbin/iptables-nft-restore -n
Bad argument `ACCEPT'
Error occurred at line: 4
Try `iptables-nft-restore -h' or 'iptables-nft-restore --help' for more 
information.

-- 
Email: ja...@strandboge.com
IRC:   jdstrand

Bug#946694: systemd: 'ControlGroupAttribute=memory.swappiness 0' does nothing

[Charles Samuels]

Package: systemd
Version: 241-7~deb10u2
Severity: normal

Dear Maintainer,

I have a service with:
[Service]
ControlGroupAttribute=memory.swappiness 0

But when I look at the process's entry in
/sys/fs/cgroup/memory/system.slice/servicename.service/memory.swappiness
I see it has the default swappiness of 60.
 
What's more is that I can't do this:
ExecStartPost=/bin/sh -c "echo 0 > /sys/fs/cgroup/memory/system.slice/
servicename.service/memory.swappiness"

because ExecStartPost is apparently run before the cgroup is established.
This is really awful behavior because I can't spawn essential services that 
rely on not getting swapped out on my very busy server. This deeply affects 
performance of my servers.

Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
   
Kernel: Linux 4.19.0-6-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_SOFTLOCKUP
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 systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5+deb10u2
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-7~deb10u2
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-1
ii  libpam-systemd  241-7~deb10u2

Versions of packages systemd suggests:
pn  policykit-1
ii  systemd-container  241-7~deb10u2

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133+deb10u1
ii  udev 241-7~deb10u2

-- no debconf information

Bug#946693: RM: gextractwinicons -- RoQA; depends on pygtk2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove gextractwinicons. It depends on pygtk2, which is going away, is 
dead
upstream and unmaintained (last maintainer upload in 2010).

Cheers,
Moritz

Bug#946692: RM: smart -- RoQA; depends on pygtk2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove smart. It depends on Python 2 and pygtk, which are going away,
is dead upstream (last release from 2011) and unmaintained.

Cheers,
Moritz
  

Bug#946691: emacs25-common: expired GNU ELPA gpg key

[Thomas Sanders]

Package: emacs25-common
Version: 25.1+1-4+deb9u1
Severity: normal
File: /usr/share/emacs/25.1/etc/package-keyring.gpg

Dear Maintainer (Rob Browning?),

This problem in emacs 25 (in Debian old-stable) is the same as the
problem that was fixed in Debian current stable (buster) emacs 26
with this changelog message:
https://metadata.ftp-master.debian.org/changelogs//main/e/emacs/emacs_26.1+1-3.2+deb10u1_changelog
[START-QUOTATON]
emacs (1:26.1+1-3.2+deb10u1) buster; urgency=high

  * Update the EPLA packaging key (previous key expires 2019-09-23) via
the upstream commit f16785d361097df9fddfcc0b60ae6f0d92e7e911.  Add the
old and new keyrings to debian/ and debian/source/include-binaries
since debian/patches/ can't handle git binary diffs.  Thanks to Stefan
Monnier for reporting the problem and providing the patch.

 -- Rob Browning   Wed, 04 Sep 2019 21:35:24 -0500
[END-QUOTATION]

File package-keyring.gpg holds the public key that emacs uses to
verify packages from the gnu emacs lisp package archive (ELPA) to be
used by emacs: see http://elpa.gnu.org

That key expired on 2019-09-23.

The gnu emacs package archive maintainer has created a new key and
used it to sign the package archive.

Adding the new key to the package-keyring.gpg fixes the problem.
(I've done that manually on one of the machines I use.)

Upstream GNU emacs added the new public key in maintenance release
26.3 (released almost a month before the old key expired).
http://www.gnu.org/software/emacs/

* Symptoms at present are:

** Cannot fetch/update the list of available packages

Running the "list-packages" command in emacs causes in the
following messages (visible in the *Messages" buffer):

Importing package-keyring.gpg...done
error in process filter: package--check-signature-content: Failed to
verify signature: "archive-contents.sig"
error in process filter: Failed to verify signature: "archive-contents.sig"

Likewise, the "package-refresh-contents" command causes

Importing package-keyring.gpg...done
Contacting host: elpa.gnu.org:80 [2 times]
Failed to download ‘gnu’ archive.

** Cannot install packages from the gnu archive
E.g.

Failed to verify signature ace-window-0.9.0.el.sig:
No public key for 066DAFCB81E42C40 created at 2019-09-21T18:55:08+0100 using RSA
Command output:
gpg: Signature made Sat 21 Sep 2019 18:55:08 BST
gpg:using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
gpg: Can't check signature: No public key

* More diagnostic details

I've checked the Debian package details, changelog, and bug tracker;
I see that this hasn't been fixed and there's no existing bug.

Examining the contents of the keyring (on Ubuntu 18.04 LTS which
inherits the file from Debian) shows the expired key:

gpg --list-keys -v --no-default-keyring --keyring \
/usr/share/emacs/25.2/etc/package-keyring.gpg
gpg: using pgp trust model
/usr/share/emacs/25.2/etc/package-keyring.gpg
-
pub   dsa2048 2014-09-24 [SC] [expired: 2019-09-23]
  CA442C00F91774F17F59D9B0474F05837FBDEF9B
uid   [ expired] GNU ELPA Signing Agent 

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

Kernel: Linux 4.15.0-72-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs25-common depends on:
ii  emacsen-common  2.0.8
ii  install-info6.5.0.dfsg.1-2

Versions of packages emacs25-common recommends:
ii  emacs25-el  25.2+1-6

Versions of packages emacs25-common suggests:
ii  emacs25-common-non-dfsg  25.2+1-1
pn  ncurses-term 

-- no debconf information

Bug#946687: libpkgconf do not provide shared library

[Alex Syrnikov]

I have done all changes You asked. Splitted libpkgconf for two packages
(shared libs and -dev files), changed package name.

Changes commeted to my salsa repo and You can see it in previous merge
request.

Please review it and merge.

Alex Syrnikov

On 13.12.2019 23:39, Andrej Shadura wrote:
> Control: tag -1 - upstream
>
> Hi,
>
> On Fri, 13 Dec 2019, 21:27 Alex Syrnikov,  > wrote:
>
> On 13.12.2019 23:18, Andrej Shadura wrote:
> > Could you please get this done upstream?
>
> Do not understand about upstream. I just ask You in package build
> rules
> to run configure without --disable-shared.
>
>
> Sorry, I didn't realise they already supported it. In that case you
> named the binary package incorrectly. Since you named it libpkgconf, I
> assumed they only provided unversioned library for the internal use,
> but if it actually has a version, you need to reflect that in the
> package name: it has to match the soname (libpkgconf3), and there
> needs to be a separate package for the development files (libpkgconf-dev).
>
> Please do the necessary changes and let me know so that I can review them.
>
> Thanks.
>
> -- 
> Cheers,
>   Andrej
>


signature.asc
Description: OpenPGP digital signature

Bug#946686: apt should accept ASCII-armored OpenPGP certificates for signed-by: entries, even if the file name has a .gpg suffix

[David Kalnischkies]

On Fri, Dec 13, 2019 at 01:42:48PM -0500, Daniel Kahn Gillmor wrote:
> If apt fails in this way, it might be nice to just peek at the first
> handful of bytes of /srv/foo.gpg to see whether it begins with:

Something like that needs to be implemented in shell, specifically in
is_supported_keyring in cmdline/apt-key.in – which incidently does a bit
of peeking already for gpg files to detect binary keyring formats, so
what could be done is removing the gpg/asc filename detection here and
just handle all files the same (+ detecting asc properly here).
See also dearmor_keyring and dearmor_filename which deal with massaging
files enough to make them usable for further processing by apt-key and
do asc detection for things like import via stdin.
It might make sense to use the same code for all these cases.


The usual caveat applies: What is working in a new enough apt version has
a strange error case in all older ones, which is especially sad for
simple data packages like keyring packages admins and users alike
relatively reasonably assume to be able to backport into oblivion.

Personally I don't see much problem in naming a file correctly given
that it isn't a very common or much repeated task and the extension is
only a very tiny part of it all, but oh well.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#937262: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye)

[Andrey Rahmatullin]

On Fri, Dec 13, 2019 at 10:10:03PM +0100, Andreas Tille wrote:
> i$ pdb2pqr
> Traceback (most recent call last):
>   File "/usr/bin/pdb2pqr", line 52, in 
> from main import mainCommand
>   File "/usr/share/pdb2pqr/main.py", line 77, in 
> import extensions
>   File "/usr/share/pdb2pqr/extensions/__init__.py", line 56, in 
> extDict[extName] = __import__(extName,globals(),locals(),[], -1)
> ValueError: level must be >= 0

"""
level specifies whether to use absolute or relative imports. The default
is -1 which indicates both absolute and relative imports will be
attempted. 0 means only perform absolute imports.  Positive values for
level indicate the number of parent directories to search relative to the
directory of the module calling __import__().
"""
https://docs.python.org/2.7/library/functions.html#__import__

-1 was removed in 3.3 as implicit relative import are not supported in
3.x. As this code seems to use relative imports you need to change -1 to
1.

> So I tried:
> 
> --- a/extensions/__init__.py
> +++ b/extensions/__init__.py
> @@ -53,7 +53,7 @@ _extList = [name for _, name, _ in 
> pkgutil.iter_modules(__path__)]
>  extDict = {}
>  
>  for extName in _extList:
> -extDict[extName] = __import__(extName,globals(),locals(),[], -1)
> +extDict[extName] = __import__(extName,globals(),locals(),[], 0)^M

Mindlessly changing the code is almost always a bad idea...

>   File "/usr/share/pdb2pqr/extensions/__init__.py", line 57, in 
> extDict[extName] = __import__(extName,globals(),locals(),[], 0)
> ModuleNotFoundError: No module named 'chi'
This is expected as it now tries to do "import chi". With 1 it should try
"from . import chi". This fails later, as the source also has implicit
relative imports that needs to be fixed, for example "from aconf import"
in src/utilities.py.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#946543: [Python-modules-team] Bug#946543: Bug#946543: Add the ability to open a Jupyter notebook (.ipynb file) directly from file manager

[Emmanuel Arias]

Thanks Yaroslav, I did not understand.

I will investigate it

Thanks

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El vie., 13 de dic. de 2019 a la(s) 18:14, Yaroslav Halchenko
(deb...@onerussian.com) escribió:
>
>
> On Fri, 13 Dec 2019, Emmanuel Arias wrote:
>
> > Hi,
>
> > If I understand you correctly, you should contact to jupyter
> > (upstream) maintainers.
>
> > Here is just for jupyter debian packaging
>
> FWIW
>
> I think it might actually be more appropriate for debian package
> (although adopted upstream as well), to provide .desktop file which
> would define that.  See
> https://askubuntu.com/questions/162612/how-can-i-add-an-application-to-the-list-of-open-with-applications
>
> the problem would be that mimetype of .ipynb is not specific enough
>
> $> file --mime  /usr/share/doc/python-statsmodels/examples/notebooks/ols.ipynb
> /usr/share/doc/python-statsmodels/examples/notebooks/ols.ipynb: text/plain; 
> charset=us-ascii
>
> $> file --mime --extension 
> /usr/share/doc/python-statsmodels/examples/notebooks/ols.ipynb
> /usr/share/doc/python-statsmodels/examples/notebooks/ols.ipynb: 
> application/octet-stream; charset=us-ascii
>
> and I didn't research if .desktop could also limit by extension...
>
> and found
>
> https://github.com/jupyter/notebook/issues/1922
>
> --
> Yaroslav O. Halchenko
> Center for Open Neuroscience http://centerforopenneuroscience.org
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
> WWW:   http://www.linkedin.com/in/yarik

Bug#946543: [Python-modules-team] Bug#946543: Bug#946543: Add the ability to open a Jupyter notebook (.ipynb file) directly from file manager

[Yaroslav Halchenko]

On Fri, 13 Dec 2019, Emmanuel Arias wrote:

> Hi,

> If I understand you correctly, you should contact to jupyter
> (upstream) maintainers.

> Here is just for jupyter debian packaging

FWIW

I think it might actually be more appropriate for debian package
(although adopted upstream as well), to provide .desktop file which
would define that.  See
https://askubuntu.com/questions/162612/how-can-i-add-an-application-to-the-list-of-open-with-applications

the problem would be that mimetype of .ipynb is not specific enough

$> file --mime  /usr/share/doc/python-statsmodels/examples/notebooks/ols.ipynb  
   
/usr/share/doc/python-statsmodels/examples/notebooks/ols.ipynb: text/plain; 
charset=us-ascii

$> file --mime --extension 
/usr/share/doc/python-statsmodels/examples/notebooks/ols.ipynb
/usr/share/doc/python-statsmodels/examples/notebooks/ols.ipynb: 
application/octet-stream; charset=us-ascii

and I didn't research if .desktop could also limit by extension...

and found

https://github.com/jupyter/notebook/issues/1922

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#937262: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye)

[Andreas Tille]

On Fri, Dec 13, 2019 at 10:49:45PM +0500, Andrey Rahmatullin wrote:
> > I think at least this is solved now:
> > 
> >
> > https://salsa.debian.org/med-team/pdb2pqr/commit/1f4ee901456641140ef18ca8e91e4701e1175410
> 
> Nice catch, "env.Append(LIBS=[python_lib])" where "python_lib = 'python' +
> gcv('VERSION')" is definitely the cause.

Yes.  I've now a state where the package builds and installs.  However,
just calling pdb2pqr fails with

i$ pdb2pqr
Traceback (most recent call last):
  File "/usr/bin/pdb2pqr", line 52, in 
from main import mainCommand
  File "/usr/share/pdb2pqr/main.py", line 77, in 
import extensions
  File "/usr/share/pdb2pqr/extensions/__init__.py", line 56, in 
extDict[extName] = __import__(extName,globals(),locals(),[], -1)
ValueError: level must be >= 0


So I tried:

--- a/extensions/__init__.py
+++ b/extensions/__init__.py
@@ -53,7 +53,7 @@ _extList = [name for _, name, _ in 
pkgutil.iter_modules(__path__)]
 extDict = {}
 
 for extName in _extList:
-extDict[extName] = __import__(extName,globals(),locals(),[], -1)
+extDict[extName] = __import__(extName,globals(),locals(),[], 0)^M
 
 def setupExtensionsOptions(parser):
 """


which leads to:

$ pdb2pqr
Traceback (most recent call last):
  File "/usr/bin/pdb2pqr", line 52, in 
from main import mainCommand
  File "/usr/share/pdb2pqr/main.py", line 77, in 
import extensions
  File "/usr/share/pdb2pqr/extensions/__init__.py", line 57, in 
extDict[extName] = __import__(extName,globals(),locals(),[], 0)
ModuleNotFoundError: No module named 'chi'


I admit I have no clue whether my change was valid nor what to try next.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#946690: aptitude configuration always generates a full line even though I have put a single line in config

[shirish शिरीष]

Package: aptitude
Version: 0.8.12-1
Severity: normal

Dear Maintainer,
It seems aptitude config file makes 3 lines instead of 1 which all is
needed to make the aptitude easter egg work at the highest level. This
is the output in -

~/.aptitude/$ cat config
Aptitude "";
Aptitude::CmdLine "";
Aptitude::CmdLine::Verbose "5";

This is when I have repeatedly have deleted it twice already
using/following Axel's advice.

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.12
Compiler: g++ 9.2.1 20190821
Compiled against:
  apt version 5.0.2
  NCurses version 6.1
  libsigc++ version: 2.10.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.1.20191019
  cwidget version: 0.5.18
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7ffe8b11)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
(0x7f27ffd93000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f27ffd58000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f27ffd29000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x7f27ffd2)
libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4
(0x7f27ffc1a000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7f27ffaf5000)
libboost_iostreams.so.1.67.0 =>
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0
(0x7f27ffad5000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30
(0x7f27ff8bc000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f27ff89b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f27ff6c2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f27ff57d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f27ff563000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f27ff3a1000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f27ff389000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f27ff36c000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f27ff359000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f27ff33)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f27ff30e000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7f27ff262000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f27ff237000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f27ff18f000)
/lib64/ld-linux-x86-64.so.2 (0x7f28003f3000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f27ff18a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f27ff17f000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f27ff174000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f27ff057000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
(0x7f27ff034000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.12-1
ii  libapt-pkg5.0 1.8.4
ii  libboost-iostreams1.67.0  1.67.0-13+b1
ii  libc6 2.29-3
ii  libcwidget4   0.5.18-5
ii  libgcc1   1:9.2.1-21
ii  libncursesw6  6.1+20191019-1
ii  libsigc++-2.0-0v5 2.10.2-1
ii  libsqlite3-0  3.30.1-1
ii  libstdc++69.2.1-21
ii  libtinfo6 6.1+20191019-1
ii  libxapian30   1.4.12-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-13
ii  sensible-utils 0.0.12+nmu1

Versions of packages aptitude suggests:
ii  apt-xapian-index0.50
ii  aptitude-doc-en [aptitude-doc]  0.8.12-1
ii  debtags 2.1.5
ii  tasksel 3.55

-- no debconf information
-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#946265: New version available fixing build with python 3.8

[Emmanuel Arias]

Hi I upload to salsa the new upstream version.

I will need sponsorship for upload, please :)


Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

Bug#946658:

[Franko I]

I've tried upgrade of kernel on 5.4.3 (stable), also a downgrade on
5.2.0-3,  or on 4.19.0-5, but same problem, adapter tries to connect and
not successful.
No idea what to do next.
Best regards,

-- 
*Franko I*

Bug#946689: munin-node: cidr_allow directive is sensitive to order when mixing IPv4 and IPv6

[Raphaël Hertzog]

Package: munin-node
Version: 2.0.33-1
Severity: normal

I recently migrated my munin server and thus I updated my munin-node
configuration to allow connections from 2 servers (on IPv4 and on IPv6)
with a config like this:

# Old server
cidr_allow 212.83.177.246/32
cidr_allow 2a01:e0b:21e3:3::1/128
# New server
cidr_allow 163.172.191.75/32
cidr_allow 2001:bc8:47c0:11f::1/128

It turns out that the new server would not manage to connect to the munin
nodes. The logs were showing a message like this:
2019/12/13-21:10:02 CONNECT TCP Peer: "[:::163.172.191.75]:49184" Local: 
"[:::212.83.178.2]:4949"
Invalid netblock: 42.1.14.11.33.227.0.3.0.0.0.0.0.0.0.1-163.172.191.75 at 
/usr/share/perl5/Net/Server.pm line 600.

This made no sense to me. After a lot of tweaking, I noticed that
all the "cidr_allow" for the IPv4 addresses have to be before the first
cidr_allow for an IPv6 address. So just sorting the rules differently
like this makes it work as expected (at least when connecting over IPv4):

# Old and new, with IPv4 first and IPv6 after
cidr_allow 212.83.177.246/32
cidr_allow 163.172.191.75/32
cidr_allow 2a01:e0b:21e3:3::1/128
cidr_allow 2001:bc8:47c0:11f::1/128

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=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 munin-node depends on:
ii  adduser  3.118
ii  gawk 1:5.0.1+dfsg-1
ii  init-system-helpers  1.57
pn  libmunin-node-perl   
pn  libnet-server-perl   
ii  lsb-base 11.1.0
pn  munin-common 
pn  munin-plugins-core   
ii  netbase  5.8
ii  perl 5.30.0-9
ii  procps   2:3.3.15-2+b1

Versions of packages munin-node recommends:
ii  gawk 1:5.0.1+dfsg-1
pn  libnet-snmp-perl 
pn  munin-plugins-core   
pn  munin-plugins-extra  
ii  procps   2:3.3.15-2+b1

Versions of packages munin-node suggests:
pn  acpi | lm-sensors 
pn  default-mysql-client  
ii  ethtool   1:4.19-1
ii  hdparm9.58+ds-4
pn  libcache-cache-perl   
ii  libcrypt-ssleay-perl  0.73.06-1+b2
pn  libdbd-mysql-perl 
ii  libdbd-pg-perl3.10.0-2
pn  liblwp-useragent-determined-perl  
pn  libnet-irc-perl   
ii  libtext-csv-xs-perl   1.40-1
ii  libwww-perl   6.43-1
ii  libxml-simple-perl2.25-1
pn  logtail   
pn  munin 
pn  munin-plugins-extra   
pn  munin-plugins-http
pn  munin-plugins-java
pn  munin-plugins-pgsql   
pn  munin-plugins-snmp
pn  mysql-client  
ii  net-tools 1.60+git20180626.aebd88e-1
ii  python2.7.17-2
ii  ruby  1:2.5.2
pn  smartmontools 

Bug#925061: apache2: Cannot disabled old TLS Versions (prior to TLS1.2)

[t...@timkwh.de]

Hi,

I had the same issue and found a solution on Launchpad:
https://bugs.launchpad.net/debian/+source/apache2/+bug/1665151

If the default Virtualhost doesn't contain old TLSv1.0 all Virtualhosts 
affected.
I created a dummy on the 000-default-ssl.conf without cipher and 
SSLProtocol config and TLSv1.0 disapeared on all my other virtualhosts.


Best Regards,
Tim

Bug#946687: libpkgconf do not provide shared library

[Andrej Shadura]

Control: tag -1 - upstream

Hi,

On Fri, 13 Dec 2019, 21:27 Alex Syrnikov,  wrote:

> On 13.12.2019 23:18, Andrej Shadura wrote:
> > Could you please get this done upstream?
>
> Do not understand about upstream. I just ask You in package build rules
> to run configure without --disable-shared.
>

Sorry, I didn't realise they already supported it. In that case you named
the binary package incorrectly. Since you named it libpkgconf, I assumed
they only provided unversioned library for the internal use, but if it
actually has a version, you need to reflect that in the package name: it
has to match the soname (libpkgconf3), and there needs to be a separate
package for the development files (libpkgconf-dev).

Please do the necessary changes and let me know so that I can review them.

Thanks.

-- 
Cheers,
  Andrej

>

Bug#946688: hyperlink to bugs.debian.org/java-common is incorrect in https://www.debian.org/doc/manuals/debian-java-faq/ch1.en.html#s-bugs

[shirish शिरीष]

Package: java-common
Version: 0.72
Severity: normal

Dear Maintainer,

The hyperlink given on
https://www.debian.org/doc/manuals/debian-java-faq/ch1.en.html#s-bugs
is incorrect. It should be hyperlinked to
https://bugs.debian.org/java-common instead of
https://www.debian.org/doc/manuals/debian-java-faq/bugs.debian.org/java-common
which is pointed or linked to java-common's list of reported bugs
which needs nowhere. Please fix the same.

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

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

java-common depends on no packages.

java-common recommends no packages.

Versions of packages java-common suggests:
ii  default-jre  2:1.11-72

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#946687: libpkgconf do not provide shared library

[Alex Syrnikov]

Hi

On 13.12.2019 23:18, Andrej Shadura wrote:
> Could you please get this done upstream?

Do not understand about upstream. I just ask You in package build rules
to run configure without --disable-shared.

Alex Syrnikov




signature.asc
Description: OpenPGP digital signature

Bug#929429: New Lintian check for upstream signatures

[Felix Lechner]

Control: tags 929434 + pending
Control: tags 929435 + pending

Hi,

All these bugs were closed via


https://salsa.debian.org/lintian/lintian/commit/242fc066cbe5fdce6642aad134cdd1503073ceb3

and


https://salsa.debian.org/lintian/lintian/commit/b6b7c15bb0e45537226f52eca358cef2ec18829e

Please note that the tag about spurious fields has the severity
wishlist. You may need to pass lintian the option -I to see it.

For some reason, the Salsa bot did not mark two of the bugs as pending.

Kind regards
Felix Lechner

Bug#946543: [Python-modules-team] Bug#946543: Add the ability to open a Jupyter notebook (.ipynb file) directly from file manager

[Emmanuel Arias]

Hi,

If I understand you correctly, you should contact to jupyter
(upstream) maintainers.

Here is just for jupyter debian packaging


Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El mar., 10 de dic. de 2019 a la(s) 14:39, Amr Ibrahim
(amribrahim1...@hotmail.com) escribió:
>
> Package: jupyter-notebook
> Version: 5.2.2-1
>
> Is there a possibility to open a Jupyter notebook directly from the file 
> manager? I wish I could just double-click on a Jupyter notebook or 
> right-click and select "Open with Jupyter Notebook".
>
> Opening a notebook from the file manager could be analogous to doing this in 
> a terminal:
>
> $ jupyter-notebook file-name.ipynb
>
> Thanks a lot!
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#946687: libpkgconf do not provide shared library

[Andrej Shadura]

Control: tag -1 upstream

Hi,

On Fri, 13 Dec 2019 at 21:15, Alex Syrnikov  wrote:
> I need to build shared library, which use libpkgconf, but currently
> there is only static libpkgconf library, which can't be used in my shared lib.
> My lib just do not compile. I made merge request for pkgconf to build shared 
> lib.
>
> https://salsa.debian.org/debian/pkgconf/merge_requests/9
>
> Please, merge it or make You own solution, so I can link my shared library 
> with
> shared libpkgconf.so.

Could you please get this done upstream?

Thanks.

-- 
Cheers,
  Andrej

Bug#946641: stops: Mark stops as 'Multi-Arch: foreign'

[Olivier Humbert]

Le 2019-12-13 09:29, Fabian Greffrath a écrit :

Am 12.12.2019 18:27, schrieb Daniel James:

The package 'stops' contains binary instrument data, which as far as I
know, is uniquely created by the undocumented and well-hidden
instrument editor feature in aeolus (hold down Ctrl then
left-mouse-click on any stop in the aeolus GUI to open the instrument
editor).


These two sentences should probably be added to the package
description, or at least README.Debian.

 - Fabian


I just did (after reworking these) there: 
https://salsa.debian.org/multimedia-team/stops/commit/437295d30fd719f14fa21b7b4c423c5393d3d528


Feel free to amend.

Olivier

Bug#946687: libpkgconf do not provide shared library

[Alex Syrnikov]

Package: libpkgconf
Version: 1.6.3-4
Severity: normal

Dear Maintainer,

I need to build shared library, which use libpkgconf, but currently
there is only static libpkgconf library, which can't be used in my shared lib.
My lib just do not compile. I made merge request for pkgconf to build shared 
lib.

https://salsa.debian.org/debian/pkgconf/merge_requests/9

Please, merge it or make You own solution, so I can link my shared library with
shared libpkgconf.so.

Alex Syrnikov

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

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

-- no debconf information

Bug#946671: [debian-mysql] Bug#946671: mariadb-server-10.3: mysqlhotcopy and transaction_registry table

[Paul Szabo]

Dear Otto,

> Since that patch is not about Debian packaging, I suggest you
> submit it upstream at https://github.com/mariadb/server branch 10.3
> (or latest 10.5).

Done: created
https://jira.mariadb.org/browse/MDEV-21317

Cheers, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

I support NTEU members taking a stand for workplace rights in the face of
poorly-run change management. Visit www.nteu.org.au/sydney to learn more.

Bug#945560: debcargo autopkgtests are broken for many packages with multiple features

[Daniel Kahn Gillmor]

On Tue 2019-11-26 18:33:53 -0500, Daniel Kahn Gillmor wrote:
> i'm starting to see a pattern of autopkgtest failures for crates with
> multiple features.  rust-bindgen and rust-buffered-reader both show this
> kind of failure in their autopkgtest suite.

I've just marked rust-bindgen's per-feature tests as flakey to try to
work around this:

https://salsa.debian.org/rust-team/debcargo-conf/commit/cfe138930591f19695feca7944ccf185dc31ec49

--dkg


signature.asc
Description: PGP signature

Bug#946661: closed by Adam Borowski (Re: Bug#946661: RFS: c-blosc/1.17.1+ds1-1 [QA] -- high performance meta-compressor optimized for binary data (development files))

[Håvard Flaget Aasen]

Thanks for the fast sponsoring!

I can't push to the master branch

...
remote: GitLab: You are not allowed to push code to protected branches 
on this project.

To salsa.debian.org:debian/c-blosc.git
 ! [remote rejected] debian/master -> debian/master (pre-receive hook 
declined)

error: failed to push some refs to 'g...@salsa.debian.org:debian/c-blosc.git'
...

Can you increase my privilege?
Or if you have some other idea?

Thanks,
Håvard


On 13.12.2019 03:15, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the sponsorship-requests package:

#946661: RFS: c-blosc/1.17.1+ds1-1 [QA] -- high performance meta-compressor 
optimized for binary data (development files)

It has been closed by Adam Borowski .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Adam Borowski 
 by
replying to this email.

Bug#946648: chromium 79.0.3945.79-1 suddenly crashes after a few minutes.

[Jürgen Göricke]

Package: chromium
Version: 79.0.3945.79-1

Dear Maintainer,

chromium crashes after a few minutes.
Especially on websites with active media content.

Please fix this bug.

[2538263:2538263:1213/195431.226626:ERROR:vaapi_wrapper.cc(417)] vaInitialize 
failed: unknown libva error
[2538263:2538263:1213/195431.795728:ERROR:sandbox_linux.cc(372)] 
InitializeSandbox() called with multiple threads in process gpu-process.
[2538263:2538263:1213/195431.846543:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[2538263:2538263:1213/195812.970619:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[2539174:136:1213/195816.972398:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2539174:136:1213/195816.973049:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2539174:136:1213/195816.973841:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2539174:136:1213/195816.974314:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
Fontconfig error: Cannot load default config file
[2539174:136:1213/195817.863397:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2538229:2538267:1213/195827.275373:ERROR:object_proxy.cc(632)] Failed to call 
method: org.freedesktop.ScreenSaver.Inhibit: object_path= 
/org/freedesktop/ScreenSaver: org.freedesktop.DBus.Error.ServiceUnknown: The 
name
org.freedesktop.ScreenSaver was not provided by any .service files 
[2538229:2538267:1213/195827.275403:ERROR:power_save_blocker_x11.cc(330)] No 
response to Inhibit() request!
[2538229:2538267:1213/200128.274852:ERROR:object_proxy.cc(632)] Failed to call 
method: org.freedesktop.ScreenSaver.UnInhibit: object_path= 
/org/freedesktop/ScreenSaver: org.freedesktop.DBus.Error.ServiceUnknown: The 
name
org.freedesktop.ScreenSaver was not provided by any .service files 
[2538229:2538267:1213/200128.274875:ERROR:power_save_blocker_x11.cc(403)] No 
response to Uninhibit() request!
[2539174:136:1213/200128.307197:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2539174:136:1213/200128.307742:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2538263:2538263:1213/200149.192602:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[2538263:2538263:1213/200326.570765:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[2538263:2538263:1213/200535.195688:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[2538263:2538263:1213/200618.499126:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[2540318:263:1213/200621.080811:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2540318:263:1213/200621.081308:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2540318:263:1213/200621.082233:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2540318:263:1213/200621.082715:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2540318:263:1213/200621.083550:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2540318:263:1213/200621.084002:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2540318:263:1213/200621.128401:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2540318:263:1213/200621.128906:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2540318:263:1213/200621.158951:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[2540318:263:1213/200621.159471:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name 

Bug#946648: crashes within a few minutes

[Harald Dunkel]

metoo

Bug#929131: gnunet: GNUnet 0.11.4 has been released, the Debian package is outdated. Please package 0.11.4.

[Marcos Marado]

In order to document this on the page for #929131 :

Work on packaging gnunet 0.11.6 was done (and is almost concluded) on
salsa[1], and no compilation problems exist anymore.
I actually concluded the 0.11.6 work[2], but the changes are minimal
and I didn't think at the time that it would be useful to submit those
patches.

In the meantime, GNUnet is already at 0.11.8[3].

[1] https://salsa.debian.org/debian/gnunet
[2] https://github.com/marado/debian-gnunet
[3] https://gnunet.org/en/news/2019-0.11.8.html

Best regards,
-- 
Marcos Marado

Bug#938301: pywavelets: diff for NMU version 0.5.1-1.2

[Sandro Tosi]

Control: tags 938301 + patch


Dear maintainer,

I've prepared an NMU for pywavelets (versioned as 0.5.1-1.2). The diff
is attached to this message.

Regards.

diff -Nru pywavelets-0.5.1/debian/changelog pywavelets-0.5.1/debian/changelog
--- pywavelets-0.5.1/debian/changelog	2017-03-27 03:42:33.0 -0400
+++ pywavelets-0.5.1/debian/changelog	2019-12-13 13:37:57.0 -0500
@@ -1,3 +1,10 @@
+pywavelets (0.5.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938301
+
+ -- Sandro Tosi   Fri, 13 Dec 2019 13:37:57 -0500
+
 pywavelets (0.5.1-1.1) unstable; urgency=medium
 
   [ Balint Reczey ]
diff -Nru pywavelets-0.5.1/debian/control pywavelets-0.5.1/debian/control
--- pywavelets-0.5.1/debian/control	2016-12-22 18:28:30.0 -0500
+++ pywavelets-0.5.1/debian/control	2019-12-13 13:36:16.0 -0500
@@ -4,15 +4,11 @@
 Section: python
 Priority: optional
 Build-Depends:
- cython (>=0.16),
+ cython3 (>=0.16),
  debhelper (>= 9),
  dh-python,
- python-all-dev (>=2.6.6-3),
- python-nose,
- python-numpy (>= 1:0.9.8-2),
- python-numpydoc,
- python-setuptools (>= 0.6b3-1~),
- python-sphinx (>= 1.0.7+dfsg),
+ python3-numpydoc,
+ python3-sphinx (>= 1.0.7+dfsg),
  python3-all-dev,
  python3-nose,
  python3-numpy,
@@ -24,19 +20,6 @@
 Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/pywavelets.git
 Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/pywavelets.git
 
-Package: python-pywt
-Architecture: any
-Depends:
- ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends},
- python-numpy (>= 1:0.9.8-2)
-Description: Python extension implementing of wavelet transformations
- PyWavelets implements the discrete wavelet transform (DWT) popular in
- numerical harmonic analysis for numerous families of wavelets, including
- Haar, Daubechies, Symlet, Coiflet, biorthogonal wavelets in one and two
- dimensions.
-
 Package: python3-pywt
 Architecture: any
 Depends:
diff -Nru pywavelets-0.5.1/debian/rules pywavelets-0.5.1/debian/rules
--- pywavelets-0.5.1/debian/rules	2017-03-27 03:42:33.0 -0400
+++ pywavelets-0.5.1/debian/rules	2019-12-13 13:37:28.0 -0500
@@ -11,7 +11,7 @@
 SPHINXOPTS := -D html_last_updated_fmt="$(BUILD_DATE)"
 
 %:
-	dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+	dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 
 override_dh_auto_clean:
@@ -23,7 +23,7 @@
 
 override_dh_auto_build:
 	dh_auto_build
-	PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build $(SPHINXOPTS) -N -bhtml doc/source doc/build/html
+	PYTHONPATH=. http_proxy='127.0.0.1:9' python3 -m sphinx $(SPHINXOPTS) -N -bhtml doc/source doc/build/html
 
 override_dh_auto_install:
 	dh_auto_install

Bug#946686: apt should accept ASCII-armored OpenPGP certificates for signed-by: entries, even if the file name has a .gpg suffix

[Daniel Kahn Gillmor]

Package: apt
Version: 1.8.4

I notice that if i have an ASCII-armored OpenPGP certificate (a.k.a. RFC
4880 "Transferable Public Key") in a file named /srv/foo.asc, and i have
a sources.list line with a "[signed-by=/srv/foo.asc]" option, apt can
happily use it just fine.

but if the same file is named "/srv/foo.gpg" then apt fails to verify
the InRelease file, with error messages like:

   W: An error occurred during the signature verification. The
   repository is not updated and the previous index files will be
   used. GPG error: … InRelease: The following signatures couldn't be
   verified because the public key is not available: NO_PUBKEY …

   W: Failed to fetch …  The following signatures couldn't be verified
   because the public key is not available: NO_PUBKEY …

If apt fails in this way, it might be nice to just peek at the first
handful of bytes of /srv/foo.gpg to see whether it begins with:


-BEGIN PGP PUBLIC KEY BLOCK-

and if it does, then treat it the same way it treats an *.asc file.

That would certainly be more user-friendly.

Thanks for your work on apt!

   --dkg


signature.asc
Description: PGP signature

Bug#897040: fontconfig: .uuid files in font directories not removed during purge

[Valerio Passini]

Followup-For: Bug #897040

Package: fontconfig

Version: 2.13.1-2+b1


Dear Maintainer,


Today on removing fonts-noto-extra I've noticed that the package could not
be

purged, the reason is the persistence of a .uuid file inside the

/usr/share/fonts/truetype/noto/ directory.

Then I tried to remove the .uuid file manually and reinstall/remove the

package

again to reproduce and yes, the file is still there.



~$ sudo apt install fonts-noto-extra

Lettura elenco dei pacchetti... Fatto

Generazione albero delle dipendenze

Lettura informazioni sullo stato... Fatto

I seguenti pacchetti NUOVI saranno installati:

fonts-noto-extra

0 aggiornati, 1 installati, 0 da rimuovere e 0 non aggiornati.

è necessario scaricare 59,1 MB di archivi.

Dopo quest'operazione, verranno occupati 277 MB di spazio su disco.

Scaricamento di:1 http://debian.mirror.garr.it/debian bullseye/main amd64

fonts-noto-extra all 20181227-1 [59,1 MB]

Recuperati 59,1 MB in 48s (1.227 kB/s)

Selezionato il pacchetto fonts-noto-extra non precedentemente selezionato.

(Lettura del database... 434019 file e directory attualmente installati.)

Preparativi per estrarre .../fonts-noto-extra_20181227-1_all.deb...

Estrazione di fonts-noto-extra (20181227-1)...

Configurazione di fonts-noto-extra (20181227-1)...

Elaborazione dei trigger per fontconfig (2.13.1-2+b1)...


~$ sudo apt purge fonts-noto-extra

Lettura elenco dei pacchetti... Fatto

Generazione albero delle dipendenze

Lettura informazioni sullo stato... Fatto

I seguenti pacchetti saranno RIMOSSI:

fonts-noto-extra*

0 aggiornati, 0 installati, 1 da rimuovere e 0 non aggiornati.

Dopo quest'operazione, verranno liberati 277 MB di spazio su disco.

Continuare? [S/n]

(Lettura del database... 435253 file e directory attualmente installati.)

Rimozione di fonts-noto-extra (20181227-1)...

dpkg: attenzione: nel rimuovere fonts-noto-extra, la directory

"/usr/share/fonts/truetype/noto" è risultata non vuota e non viene
rimossa

Elaborazione dei trigger per fontconfig (2.13.1-2+b1)...




-- System Information:

Debian Release: bullseye/sid

APT prefers unstable

APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')

Architecture: amd64 (x86_64)


Kernel: Linux 5.4.2-hpomen (SMP w/12 CPU cores; PREEMPT)

Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,

TAINT_UNSIGNED_MODULE

Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),

LANGUAGE=en_US:it (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash

Init: systemd (via /run/systemd/system)


Versions of packages fontconfig depends on:

ii fontconfig-config 2.13.1-2

ii libc6 2.29-6

ii libfontconfig1 2.13.1-2+b1

ii libfreetype6 2.10.1-2


fontconfig recommends no packages.


fontconfig suggests no packages.


-- no debconf information

Bug#946629: tilix: Same here

[EdiD]

Package: tilix
Version: 1.9.3-3
Followup-For: Bug #946629

I am wondering why such packages are not tested at all ?

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

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

Versions of packages tilix depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  libc62.29-3
ii  libgtkd-3-0  3.9.0-3+b1
ii  libphobos2-ldc-shared88  1:1.18.0-2
ii  libunwind8   1.2.1-9
ii  libvted-3-0  3.9.0-3+b1
ii  libx11-6 2:1.6.8-1
ii  tilix-common 1.9.3-3

tilix recommends no packages.

Versions of packages tilix suggests:
pn  python-nautilus  

-- no debconf information

Bug#946685: meshlab: Most current upstream builds without modification on Buster, re-packaging started but need help

[Ryan Pavlik]

Package: meshlab
Severity: important
Tags: patch

Dear Maintainer,

I saw that meshlab was removed due to build issues. I have done some work on it
upstream recently, including incorporating patches/functionality from the
debian package. It now builds easily with fewer patches - and my PR to add a
CMake build system (instead of qmake) was just accepted and will probably be in
a snapshot release https://github.com/cnr-isti-vclab/meshlab/releases tomorrow
or early next week.

I've tried to update the package - however, since the previous package, they've
split meshlab and vcglib so we're in a "multiple upstream tarballs" scenario
which I'm not very familiar with packaging. My work-in-progress (based on a
snapshot release of a few days ago) is here: https://salsa.debian.org/rpavlik-
guest/meshlab/tree/rp/update but I'd strongly recommend going with a version
that includes my CMake build system since it makes the dependency handling
smoother and more reliable.

I also tried to fix the issue in the most recent package that kept it from
being migrated - the desktop OpenGL usage isn't compatible with armel or armhf,
so I disabled those architectures the best I know how.

There is interest from users at upstream in using MeshLab in Debian, so
hopefully this package can be revived. I'm happy to help - I'm now pretty
familiar with the code structure and build system, and upstream has been
accepting my patches pretty readily recently.

Thanks,

Ryan

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

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

Versions of packages meshlab depends on:
ii  lib3ds-1-3  1.3.0-9+b1
ii  libbz2-1.0  1.0.6-9.2~deb10u1
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgl1  1.1.0-1
ii  libglew2.1  2.1.0-4
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libmuparser2v5  2.2.6.1+dfsg-1
ii  libopenctm1 1.0.3+dfsg1-2+b1
ii  libqhull7   2015.2-4
ii  libqt4-network  4:4.8.7+dfsg-18
ii  libqt4-opengl   4:4.8.7+dfsg-18
ii  libqt4-script   4:4.8.7+dfsg-18
ii  libqt4-xml  4:4.8.7+dfsg-18
ii  libqt4-xmlpatterns  4:4.8.7+dfsg-18
ii  libqtcore4  4:4.8.7+dfsg-18
ii  libqtgui4   4:4.8.7+dfsg-18
ii  libstdc++6  8.3.0-6

Versions of packages meshlab recommends:
ii  chemical-mime-data  0.1.94-7

meshlab suggests no packages.

Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected

[Celejar]

On Fri, 13 Dec 2019 15:29:23 +1030
Andrew Bettison  wrote:

> On Sun, 08 Sep 2019 23:43:04 -0400 Celejar  wrote:
> 
>  > Package: firmware-iwlwifi
>  > Version: 20190717-2
>  > Followup-For: Bug #934781
>  >
>  > I did some further digging - in my case, at least, the problem seems to
>  > be triggered by some relatively recent kernel change. I combed through
>  > the system journal for the last few months, and the problem first starts
>  > appearing in the logs a few days after I began running kernel 5.2.x
>  > (from 5.2.7 through 5.2.9). Previously, while running 4.19.x, the
>  > problem never appears.
>  >
>  > I haven't done a bisection, but it seems pretty clear at this point that
>  > there's a microcode bug that has begun to be triggered by something in
>  > newer kernels.

> As an experiment, I downloaded the tarball from 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tag/?h=20190815
>  
> (as recommended in 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939262 ), and manually 
> copied its intel/* and iwlwifi-* files into /lib/firmware (overwriting 
> the ones installed by the firmware-iwlwifi package).
> 
> After rebooting kernel 5.3.0-2 (amd64) I still get "iwlwifi: Microcode 
> SW error" messages accompanied by "ieee80211 phy0: Hardware restart was 
> requested" during periods of high Wi-Fi throughput, but they do not 
> cause the Wi-Fi to hang.  So the newer firmware appears to rectify the 
> worst part of the problem (Wi-Fi freeze) but does not fully resolve the 
> problem.

On my system, the problem last appeared on Sep. 17 (with a Debian
kernel version 5.2.9-2). Since then, I have not seen any "Microcode SW"
errors. I've been running 4.19.72 (self-built), 5.2.17-1, 5.3.7-1,
5.3.9 (-1, -2, -3), and 5.3.15-1 (Debian).

[I examined the boot logs with:

~# journalctl -S 2019-06-01 | grep "Linux ver\|Microcode SW"
]

Celejar

Bug#946684: ITP: elpa-evil-magit -- Evil keys for Magit

[David Krauser]

Package: wnpp
Severity: wishlist
Owner: David Krauser 

* Package name: elpa-evil-magit
  Version : 0.4.2
  Upstream Author : Justin Burkett 
* URL : https://github.com/emacs-evil/evil-magit
* License : GPL
  Programming Lang: ELisp
  Description : Evil keys for Magit

This library configures Magit and Evil to play well with each other.

Why is this package useful/relevant?

Magit and Evil are both popular Emacs packages. Magit is an interactive 
interface into the git version control system. Evil is a major mode that 
emulates the main features (and keybindings) of Vim.

Out of the box, Magit does not play nicely with Evil keybindings. This package 
enables Evil style keybindings in Magit.

How do you plan to maintain it?

I plan to mantain this package in conjunction with the Debian Emacsen team.

Bug#905963: unbound: The patch in #903963 upstream

[Svante Signell]

FYI:

The patch hurd.diff in 903963 is now submitted upstream:
https://github.com/NLnetLabs/unbound/issues/131

Thanks!

Bug#905961: 905961: Updated patches for unbound 1.9.4-2

[Svante Signell]

found 905961 1.9.4-2
thanks

Hello,

Updated patch for debian/rules is attached. The patch for debian/control is
added for your convenience.

Thanks!


--- a/debian/control.orig	2017-07-03 22:30:17.0 +0200
+++ b/debian/control	2017-07-14 11:21:44.0 +0200
@@ -20,7 +20,7 @@
  libfstrm-dev ,
  libprotobuf-c-dev ,
  libssl-dev ,
- libsystemd-dev ,
+ libsystemd-dev [linux-any] ,
  libtool,
  nettle-dev,
  pkg-config,
--- a/debian/rules	2019-12-13 12:56:07.0 +0100
+++ b/debian/rules	2019-12-13 12:57:48.0 +0100
@@ -7,7 +7,9 @@
 CONFIGURE_ARGS = --disable-flto
 endif
 
-ifneq ($(DEB_HOST_ARCH_OS), linux)
+ifeq ($(DEB_HOST_ARCH_OS), linux)
+CONFIGURE_ARGS = --enable-systemd
+else
 CONFIGURE_ARGS = --with-libbsd
 endif
 
@@ -44,7 +46,6 @@
 		--with-pythonmodule \
 		--enable-subnet \
 		--enable-dnstap \
-		--enable-systemd \
 		--with-chroot-dir="" \
 		--with-dnstap-socket-path=/run/dnstap.sock \
 		--libdir=/usr/lib \

Bug#946683: Update to version 2 required to package htmlproofer 3.15.0

[Daniel Leidert]

Package: ruby-nokogumbo
Version: 1.4.2+ds-1+b5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The latest release of ruby-html-proofer changed from nokogiri to nokogumbo and
requires version 2 of the latter. So I'd like to request an update.

There are three packages depending on ruby-nokogumbo. One of them is
ruby-sanitize 4.x. Its .gemspec declares a dependency on nokogumbo ~> 1.4, which
conflicts with my request. So this must be resolved first.

Regards, Daniel


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

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

Versions of packages ruby-nokogumbo depends on:
ii  libc6  2.29-6
ii  libgmp10   2:6.1.2+dfsg-4
ii  libgumbo1  0.10.1+dfsg-2.4
ii  libruby2.5 2.5.7-1
ii  libxml22.9.4+dfsg1-8
ii  ruby   1:2.5.2
ii  ruby-nokogiri  1.10.4+dfsg1-1

ruby-nokogumbo recommends no packages.

ruby-nokogumbo suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl3zwqwACgkQS80FZ8KW
0F3LhRAAwyMCCVB5zn0vO14TQ+8nSH0sL/a/pgdbyGZo+d9+UUWOs/AOjL/3Fsek
Hjn1NCh4KQM6l9HrnrvYuLGNP2hFyddpF0lpV3d62u+N8zPt3eU3xdk2LvlCMXU4
dncpA5ttrvYPX8+AOJso7RpiC9Mann0D2n+EWGPdvg1fLDm6HE1GuH1XEa/+18YO
40MyNl7QpWDhy0TPWuWBeGCu7UUTOSXK/usESiFweNAAPSxTdv/8TzsXI9vaFMHV
kRtr5lTywpR23eDF455a9lgRVuC0WELc3Py2jM/M9wNH5GAcve5jBdEJ5AZxjbEt
bElEcap74cTl2WlBjs/fseT+flRXl2PugFptpDIE2sdjJHCaJRvWAZlpr3QQeBd0
Oei66d/ZJhrd3gPksMgllAE4wH1S4UGtf+K7jZ0JsdDRQLR3B/vQ7W+nV+/g+SZg
xBoUWOXXNAoXyL8rByCW5pjDO+NgrLXWePeXeNn72nVK1p53nZCFQS/oDq8CRYOj
pDZvTRYp96ZY07T/+WTmqgFUCeFSa4c6hQzYCUW6FspvN6a3F9VI7ji5hFx2tBKA
1qBEHTOxlnopeTkVihRqLsvEW/DwQeG/+OTT4PcUlOiID6Wzjm7XFmXe+RGYJd2u
aC8su3nvYer771tAkoKqIi/bANtVMSG148IpH75HvByuFnYPjDA=
=7jsD
-END PGP SIGNATURE-

Bug#945035: gnat-gps: Please build-depend on python-gi in addition to python-gi-dev

[Simon McVittie]

Control: severity -1 serious

On Mon, 18 Nov 2019 at 18:08:36 +, Simon McVittie wrote:
> At the moment, python-gi-dev Depends on both python-gi and python3-gi.
> The GNOME team would like to drop the python-gi dependency, to make the
> status of Python 2 removal easier to track.
...
> This bug's severity will be increased to serious if it is still open
> when python-gi-dev's dependency on python-gi is removed in unstable.

gnat-gps appears to be the last package that will be broken by this, and
it already has an unrelated release-critical bug, so I'm escalating this
bug to RC and no longer considering it to block upload of the pygobject
source package.

smcv

Bug#946682: debian-installer: Discard transmission by LVM

[Frederic MASSOT]

Package: debian-installer
Severity: wishlist
Tags: d-i

Dear Maintainer,

Following a discussion on the list of Proxmox users, I understood that only LVM 
Thin transmits discard commands to SSD.

https://pve.proxmox.com/pipermail/pve-user/2019-December/171187.html

https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_hard_disk_discard

When creating logical volumes with the Debian installer, they are not of the 
LVM Thin type.

Can you add to the Debian Installer the ability to create logical volume with 
thin provisioning?


Regards.


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

Kernel: Linux 5.3.0-2-amd64 (SMP w/8 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

Bug#921566: Reopen Bug#921566 closed by Andreas Tille (Bug#921566: fixed in deepnano 0.0+git20170813.e8a621e-3)

[Andreas Tille]

Hi Paul,

in our advent bug squashing party I wanted to have another look into
this.

On Sat, Feb 09, 2019 at 01:23:22PM +0100, Paul Gevers wrote:
> > I admit I see no better solution than to deactivate the autopkgtest.
> 
> That would really be a shame. There is really a regression in you
> package, as the test used to finish in within two minutes and now times
> out after 2:47 hours. So something broke it, albeit maybe not in your
> setup. If you remove the autopkgtest to "fix" this bug, I suggest to not
> close this bug, but retitle it to something like "deepnano is not
> finishing properly and/or in time in some environments" and leave it
> open until the issue is resolved (by deepnano, or by the (indirect)
> dependency that caused this issue). It's clear caused by something
> outside of deepnano, maybe
> https://ci.debian.net/data/packages/unstable/amd64/d/deepnano/1680359.log has
> a hint for you?

However, even

 https://ci.debian.net/packages/p/deepnano

does not exist any more.  Am I missing something?

Kind regards

  Andreas.


-- 
http://fam-tille.de

Bug#946681: jool: Fix FTBFS with kernel >= 5.4

[Paolo Pisati]

Package: jool
Version: 4.0.6-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Linux 5.4 compatibility (LP: #1856185)


Thanks for considering the patch.


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

Kernel: Linux 4.15.0-73-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru jool-4.0.6/debian/jool-dkms.dkms jool-4.0.6/debian/jool-dkms.dkms
--- jool-4.0.6/debian/jool-dkms.dkms2019-11-11 17:28:43.0 +0100
+++ jool-4.0.6/debian/jool-dkms.dkms2019-12-13 11:40:45.0 +0100
@@ -2,9 +2,9 @@
 PACKAGE_VERSION="#MODULE_VERSION#"
 AUTOINSTALL="yes"
 
-MAKE[0]="make -C ${kernel_source_dir} 
SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/src/mod/common 
modules \
-  && make -C ${kernel_source_dir} 
SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/src/mod/nat64 
modules \
-  && make -C ${kernel_source_dir} 
SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/src/mod/siit 
modules"
+MAKE[0]="make -C ${kernel_source_dir} 
M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/src/mod/common modules \
+  && make -C ${kernel_source_dir} 
M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/src/mod/nat64 modules \
+  && make -C ${kernel_source_dir} 
M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/src/mod/siit modules"

 CLEAN="make -C ${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/src/mod 
clean"
 

Bug#946561: Bug #946561

[Stefano F.]

Just to simplify your check try:
piuparts --docker-image debian:experimental -d experimental -a hplip python3
It fails cause: "The following packages have unmet dependencies:
hplip : Depends: python3 (< 3.8) but 3.8.0-2 is to be installed"

Then if you just try to rebuild in this context with debuild -b -uc -us:
It fails to build cause hplip used improper way of checking python
usability which worked  until python38 - start to include python in
spec file.

See [1] cause we had the same include upstream issues.

[1]https://bugzilla.redhat.com/show_bug.cgi?id=1706233

Il giorno ven 13 dic 2019 alle ore 16:50 Didier 'OdyX' Raboud
 ha scritto:
>
> Control: severity -1 important
> Control: tags -1 +moreinfo
>
> Le mercredi, 11 décembre 2019, 21.04:58 h CET Stefano Fabri a écrit :
> > Try to apt-get install hplip when you have in the system python >=3.8
> > (https://packages.debian.org/experimental/python3).
> >
> > In this status hplip is not installable.
>
> Well. Your bugreport still is not actionable for me as maintainer. What do you
> see on-screen when you do this installation combination (ideally in a
> terminal)? When you say "not installable", what exactly do you mean?
>
> OdyX

Bug#944249: [Pkg-emacsen-addons] Bug#944249: marked as done (gnuplot-mode does not work with emacs26)

[David Bremner]

"Debian Bug Tracking System"  writes:
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>

Do you plan to do a stable update? It seems not great that the package
is pretty broken in stable.

d

Bug#946680: [hdf5] FTBS with openmpi 4.0.2-4+b1

[Christophe Trophime]

Package: hdf5
Version: 1.10.4+repack
Severity: normal

--- System information. ---
Architecture:
Kernel:   Linux 5.3.0-2-amd64

Debian Release: bullseye/sid
  500 testing ftp.fr.debian.org

When compiling with openmpi 4:

.../../../src/H5Smpio.c:1503:9: error: call to 'MPI_Type_extent' declared
with attribute error: MPI_Type_extent was removed in MPI-3.0.  Use
MPI_Type_get_extent instead.
 1503 | MPI_Type_extent (old_type, _extent);
  | ^~~
../../../src/H5Smpio.c: In function 'H5S_mpio_hyper_type':
../../../src/H5Smpio.c:882:13: error: call to 'MPI_Type_extent' declared
with attribute error: MPI_Type_extent was removed in MPI-3.0.  Use
MPI_Type_get_extent instead.
  882 | MPI_Type_extent (inner_type, _extent);
  | ^~~
make[2]: *** [Makefile:1603: H5Smpio.lo] Error 1
make[2]: Leaving directory
'/build/hdf5-1.10.4+repack/debian/build-openmpi/src'
make[1]: *** [Makefile:1160: all] Error 2
make[1]: Leaving directory
'/build/hdf5-1.10.4+repack/debian/build-openmpi/src'

Best
c

Bug#946588: thunderbird's dowgrade prevention is being triggered after upgrade from stretch

[Carsten Schoenert]

Hello Emilio,

Am 13.12.19 um 14:06 schrieb Emilio Pozuelo Monfort:
> Pushed to branch debian/sid. That should fix this error during the build:
> 
>  0:01.29 ./buildid.h.stub
>  0:01.41 Ignoring invalid MOZ_BUILD_DATE: 1575912135
> 
> And consequently the timestamp in the build id header of the application.ini
> file will be that one of the changelog. This also should make that part of the
> build reproducible.

cool! Thank you very much!
And that's on top also perfect in time as I wanted to start right now to
work on 68.3.0 for buster and stretch.

But isn't a build for buster or stretch taking the time for
SOURCE_DATE_EPOCH from the changelog entry for buster resp. stretch?
Than we would need to add some magic to grep the date from the
corresponding changelog entry from unstable. That's fragile ... :-(

We could use the timestamp from the file ./sourcestamp.txt instead,
that's a unique stamp for every new upstream version.

> $ head -n1 ./sourcestamp.txt 
> 20191129091924

-- 
Regards
Carsten

Bug#946679: cdrskin in Debian 10 cannot burn usual Audio CD sessions but spoils CD-R

[Thomas Schmitt]

Package: cdrskin
Version: 1.5.0-1
Severity: important
Tags: upstream

Dear Release Team,

due to a hapless bug fix before upstream release of cdrkin-1.5.0 the program
lost its ability to burn multiple tracks in one session. Multiple tracks
are the most expectable situation with burning Audio CDs.
Regrettably this is the version in current "stable".

The offending upstream commit is very simple:
  
https://dev.lovelyhq.com/libburnia/libburn/commit/84fad99ebaa8cb9e16a8939bb2449073038924c1
It was supposed to fix a rare bug, but created a common one.

The symptoms are
- If the first track is smaller than the fifo buffer (default 4 MiB), then
  the burn run hangs with waiting for the fifo to get full.
- If the first track can fill the fifo completely, then it gets written
  very slowly. Burning hangs forever at the end of the first track.
  The affected medium is not blank any more. In case of CD-R it is used up
  afterwards.

To reproduce the problem, i booted  debian-live-10.0.0-amd64-xfce.iso  and
did

  # Install
  sudo apt-get update
  sudo apt-get install cdrskin

  # Create dummy input files (CD-DA sector size is 2352 bytes)
  dd if=/dev/zero bs=2352 count=5000 of=dummy_track1
  dd if=/dev/zero bs=2352 count=6000 of=dummy_track2
  dd if=/dev/zero bs=2352 count=7000 of=dummy_track3

  # Let cdrskin misburn a CD-RW, "blank=as_needed" will erase it before burn
  cdrskin -v dev=/dev/sr0 blank=as_needed -eject -audio dummy_track[1-3]

The cdrskin run has finally to be interrupted by Ctrl+C.
After about 30 to 60 seconds, the drive is released and cdrskin ends.

The older releases of Debian are not affected, because the bug was introduced
after upstream version 1.4.6, which is in Debian 9.

The freshly uploaded version 1.5.2 got a last-minute patch to fix the problem:
  
https://salsa.debian.org/optical-media-team/libburn/raw/master/debian/patches/01-ban-o_direct-to-fix-cdrskin-multi-track.patch
It reverts the bad change and forcefully disables the exotic configuration
of using O_DIRECT in libburn, which that change was meant to fix.
Meanwhile it migrated to testing.

The O_DIRECT configuration of libburn does not happen in the production of
Debian binary package libburn4.
So my proposal for a patch in stable is even more sparse than in testing
and avoids any change in libburn4, which is in use with Xfburn, Brasero,
and xorriso.

I created a patched cdrskin_1.5.0-2+deb10u1_amd64.deb (by debuild -S and
debuild -b) and tested on Debian 10 Live by above procedure, plus
  sudo dpkg -i cdrskin_1.5.0-2+deb10u1_amd64.deb
that it burns multiple tracks with the expectable speed and result.

==
$ debdiff libburn_1.5.0-1.dsc libburn_1.5.0-2+deb10u1.dsc
diff -Nru libburn-1.5.0/debian/changelog libburn-1.5.0/debian/changelog
--- libburn-1.5.0/debian/changelog  2018-09-24 10:48:38.0 +0200
+++ libburn-1.5.0/debian/changelog  2019-11-27 16:17:00.0 +0100
@@ -1,3 +1,14 @@
+libburn (1.5.0-2+deb10u1) UNRELEASED; urgency=low
+  * Patch taken from upstream development
++ cdrskin multi-track burning was slow and stalled after track 1.
+  Regression introduced in version 1.5.0 by commit 84fad99, 2018.02.05,
+  which should fix a bug with O_DIRECT track reading.
+  Debian never enabled O_DIRECT, so 84fad99 was never desirable.
+  The patch reverts the upstream commit to bring the fifo code of cdrskin
+  back to the state in Debian 9 and Debian 8.
+
+ -- Thomas Schmitt   Wed, 27 Nov 2019 16:17:00 +0100
+
 libburn (1.5.0-1) UNRELEASED; urgency=low

   * New upstream release
diff -Nru libburn-1.5.0/debian/patches/01-fix-cdrskin-multi-track.patch libburn-
1.5.0/debian/patches/01-fix-cdrskin-multi-track.patch
--- libburn-1.5.0/debian/patches/01-fix-cdrskin-multi-track.patch   1970-01-
01 01:00:00.0 +0100
+++ libburn-1.5.0/debian/patches/01-fix-cdrskin-multi-track.patch   2019-11-
27 16:17:00.0 +0100
@@ -0,0 +1,18 @@
+Description: Bug fix: cdrskin multi-track burning was slow and stalled
+ after track 1.
+ Regression introduced in version 1.5.0 by commit 84fad99, 2018.02.05,
+ which should fix a bug with O_DIRECT track reading.
+ This patch reverts the upstream commit to bring the fifo code of cdrskin back
+ to the state of cdrskin-1.4.6 in Debian 9 and cdrskin-1.3.2 in Debian 8.
+Author: Thomas Schmitt 
+
+--- a/cdrskin/cdrfifo.c
 b/cdrskin/cdrfifo.c
+@@ -28,7 +28,6 @@
+ #ifndef Cdrfifo_standalonE
+ /* for burn_os_alloc_buffer() */
+ #include "../libburn/libburn.h"
+-#define Libburn_has_open_trac_srC 1
+ #endif
+
+ #include "cdrfifo.h"
diff -Nru libburn-1.5.0/debian/patches/series 
libburn-1.5.0/debian/patches/series
--- libburn-1.5.0/debian/patches/series 2018-04-03 19:59:27.0 +0200
+++ libburn-1.5.0/debian/patches/series 2019-11-27 16:17:00.0 +0100
@@ -0,0 +1,2 @@
+01-fix-cdrskin-multi-track.patch
+
==

-- 

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

[Thorsten Glaser]

On Fri, 13 Dec 2019, Marco d'Itri wrote:

> Can you report this from your dpkg.log?
> 
> root@TMP19396:~# egrep '(libc6|libcrypt)' /var/log/dpkg.log 

Comments inline:

- from the dist-upgrade attempt -

2019-12-11 17:03:21 upgrade libc6:x32 2.29-3 2.29-6
2019-12-11 17:03:21 status half-configured libc6:x32 2.29-3
2019-12-11 17:03:21 status unpacked libc6:x32 2.29-3
2019-12-11 17:03:21 status half-configured libc6:i386 2.29-3
2019-12-11 17:03:21 status half-configured libc6:amd64 2.29-3
2019-12-11 17:03:21 status half-installed libc6:x32 2.29-3
2019-12-11 17:03:25 status unpacked libc6:x32 2.29-6
2019-12-11 17:03:35 upgrade libc6:amd64 2.29-3 2.29-6
2019-12-11 17:03:35 status unpacked libc6:amd64 2.29-3
2019-12-11 17:03:35 status half-installed libc6:amd64 2.29-3
2019-12-11 17:03:36 status unpacked libc6:amd64 2.29-3
2019-12-11 17:03:36 status installed libc6:amd64 2.29-3
2019-12-11 17:03:37 upgrade libc6:i386 2.29-3 2.29-6
2019-12-11 17:03:37 status unpacked libc6:i386 2.29-3
2019-12-11 17:03:37 status half-configured libc6:amd64 2.29-3
2019-12-11 17:03:38 status half-installed libc6:i386 2.29-3
2019-12-11 17:03:38 status unpacked libc6:i386 2.29-3
2019-12-11 17:03:38 status installed libc6:amd64 2.29-3
2019-12-11 17:03:38 status installed libc6:i386 2.29-3

- manual recovery -

2019-12-11 17:37:48 install libcrypt1:amd64  1:4.4.10-5
2019-12-11 17:37:48 status half-installed libcrypt1:amd64 1:4.4.10-5
2019-12-11 17:37:49 status unpacked libcrypt1:amd64 1:4.4.10-5
2019-12-11 17:37:49 install libcrypt1:i386  1:4.4.10-5
2019-12-11 17:37:49 status half-installed libcrypt1:i386 1:4.4.10-5
2019-12-11 17:37:49 status unpacked libcrypt1:i386 1:4.4.10-5
2019-12-11 17:37:49 install libcrypt1:x32  1:4.4.10-5
2019-12-11 17:37:49 status half-installed libcrypt1:x32 1:4.4.10-5
2019-12-11 17:37:50 status unpacked libcrypt1:x32 1:4.4.10-5
2019-12-11 17:37:50 configure libcrypt1:amd64 1:4.4.10-5 1:4.4.10-5
2019-12-11 17:37:50 status half-configured libcrypt1:amd64 1:4.4.10-5
2019-12-11 17:37:50 status installed libcrypt1:amd64 1:4.4.10-5
2019-12-11 17:37:50 configure libcrypt1:i386 1:4.4.10-5 1:4.4.10-5
2019-12-11 17:37:50 status half-configured libcrypt1:i386 1:4.4.10-5
2019-12-11 17:37:50 status installed libcrypt1:i386 1:4.4.10-5

- dpkg -i lib{c6,crypt1}_*.deb again, just to be sure -

2019-12-11 17:38:04 upgrade libc6:amd64 2.29-3 2.29-6
2019-12-11 17:38:04 status half-configured libc6:amd64 2.29-3
2019-12-11 17:38:04 status unpacked libc6:amd64 2.29-3
2019-12-11 17:38:04 status half-configured libc6:i386 2.29-3
2019-12-11 17:38:04 status half-installed libc6:amd64 2.29-3
2019-12-11 17:38:06 status unpacked libc6:amd64 2.29-6
2019-12-11 17:38:07 upgrade libc6:i386 2.29-3 2.29-6
2019-12-11 17:38:07 status unpacked libc6:i386 2.29-3
2019-12-11 17:38:07 status half-installed libc6:i386 2.29-3
2019-12-11 17:38:09 status unpacked libc6:i386 2.29-6
2019-12-11 17:38:09 upgrade libc6:x32 2.29-6 2.29-6
2019-12-11 17:38:09 status half-installed libc6:x32 2.29-6
2019-12-11 17:38:11 status unpacked libc6:x32 2.29-6
2019-12-11 17:38:11 configure libc6:amd64 2.29-6 2.29-6
2019-12-11 17:38:11 status half-configured libc6:amd64 2.29-6
2019-12-11 17:38:13 status installed libc6:amd64 2.29-6
2019-12-11 17:38:13 configure libc6:i386 2.29-6 2.29-6
2019-12-11 17:38:13 status half-configured libc6:i386 2.29-6
2019-12-11 17:38:15 status installed libc6:i386 2.29-6
2019-12-11 17:38:15 configure libcrypt1:x32 1:4.4.10-5 
2019-12-11 17:38:15 status unpacked libcrypt1:x32 1:4.4.10-5
2019-12-11 17:38:15 status half-configured libcrypt1:x32 1:4.4.10-5
2019-12-11 17:38:15 status installed libcrypt1:x32 1:4.4.10-5
2019-12-11 17:38:16 configure libc6:x32 2.29-6 2.29-6
2019-12-11 17:38:16 status half-configured libc6:x32 2.29-6
2019-12-11 17:38:18 status installed libc6:x32 2.29-6
2019-12-11 17:38:23 upgrade libcrypt1:amd64 1:4.4.10-5 1:4.4.10-5
2019-12-11 17:38:23 status half-configured libcrypt1:amd64 1:4.4.10-5
2019-12-11 17:38:23 status unpacked libcrypt1:amd64 1:4.4.10-5
2019-12-11 17:38:23 status half-installed libcrypt1:amd64 1:4.4.10-5
2019-12-11 17:38:23 status unpacked libcrypt1:amd64 1:4.4.10-5
2019-12-11 17:38:24 upgrade libcrypt1:i386 1:4.4.10-5 1:4.4.10-5
2019-12-11 17:38:24 status half-configured libcrypt1:i386 1:4.4.10-5
2019-12-11 17:38:24 status unpacked libcrypt1:i386 1:4.4.10-5
2019-12-11 17:38:24 status half-installed libcrypt1:i386 1:4.4.10-5
2019-12-11 17:38:24 status unpacked libcrypt1:i386 1:4.4.10-5
2019-12-11 17:38:25 upgrade libcrypt1:x32 1:4.4.10-5 1:4.4.10-5
2019-12-11 17:38:25 status half-configured libcrypt1:x32 1:4.4.10-5
2019-12-11 17:38:25 status unpacked libcrypt1:x32 1:4.4.10-5
2019-12-11 17:38:25 status half-installed libcrypt1:x32 1:4.4.10-5
2019-12-11 17:38:25 status unpacked libcrypt1:x32 1:4.4.10-5
2019-12-11 17:38:25 configure libcrypt1:amd64 1:4.4.10-5 1:4.4.10-5
2019-12-11 17:38:25 status half-configured libcrypt1:amd64 1:4.4.10-5
2019-12-11 17:38:25 status installed libcrypt1:amd64 1:4.4.10-5
2019-12-11 

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

[Marco d'Itri]

On Dec 12, Thorsten Glaser  wrote:

> I did a dist-upgrade, and apt uses a different resolver than apt-get,
> but… perhaps the apt maintainers can help trying to figure this out?
I have tried "apt-get --purge dist-upgrade" too and it still does not 
fail on my system.

Can you report this from your dpkg.log?

root@TMP19396:~# egrep '(libc6|libcrypt)' /var/log/dpkg.log 
2019-12-12 18:28:46 install libc6:amd64  2.28-10
2019-12-12 18:28:46 status half-installed libc6:amd64 2.28-10
2019-12-12 18:28:47 status unpacked libc6:amd64 2.28-10
2019-12-12 18:28:47 configure libc6:amd64 2.28-10 2.28-10
2019-12-12 18:28:47 status half-configured libc6:amd64 2.28-10
2019-12-12 18:28:48 status installed libc6:amd64 2.28-10
2019-12-12 18:28:57 upgrade libc6:amd64 2.28-10 2.28-10
2019-12-12 18:28:57 status half-configured libc6:amd64 2.28-10
2019-12-12 18:28:57 status unpacked libc6:amd64 2.28-10
2019-12-12 18:28:57 status half-installed libc6:amd64 2.28-10
2019-12-12 18:28:58 status unpacked libc6:amd64 2.28-10
2019-12-12 18:29:11 configure libc6:amd64 2.28-10 
2019-12-12 18:29:11 status unpacked libc6:amd64 2.28-10
2019-12-12 18:29:11 status half-configured libc6:amd64 2.28-10
2019-12-12 18:29:11 status installed libc6:amd64 2.28-10
2019-12-12 18:29:30 install libc6-dev:amd64  2.28-10
2019-12-12 18:29:30 status half-installed libc6-dev:amd64 2.28-10
2019-12-12 18:29:30 status unpacked libc6-dev:amd64 2.28-10
2019-12-12 18:29:37 configure libc6-dev:amd64 2.28-10 
2019-12-12 18:29:37 status unpacked libc6-dev:amd64 2.28-10
2019-12-12 18:29:37 status half-configured libc6-dev:amd64 2.28-10
2019-12-12 18:29:37 status installed libc6-dev:amd64 2.28-10
2019-12-12 19:31:43 install libc6:i386  2.28-10
2019-12-12 19:31:43 status half-installed libc6:i386 2.28-10
2019-12-12 19:31:44 status unpacked libc6:i386 2.28-10
2019-12-12 19:31:44 configure libc6:i386 2.28-10 
2019-12-12 19:31:44 status unpacked libc6:i386 2.28-10
2019-12-12 19:31:44 status half-configured libc6:i386 2.28-10
2019-12-12 19:31:46 status installed libc6:i386 2.28-10
2019-12-13 16:52:18 upgrade libc6:i386 2.28-10 2.29-6
2019-12-13 16:52:18 status half-configured libc6:i386 2.28-10
2019-12-13 16:52:18 status unpacked libc6:i386 2.28-10
2019-12-13 16:52:18 status half-configured libc6:amd64 2.28-10
2019-12-13 16:52:18 status half-installed libc6:i386 2.28-10
2019-12-13 16:52:19 status unpacked libc6:i386 2.29-6
2019-12-13 16:52:19 upgrade libc6:amd64 2.28-10 2.29-6
2019-12-13 16:52:19 status unpacked libc6:amd64 2.28-10
2019-12-13 16:52:19 status half-installed libc6:amd64 2.28-10
2019-12-13 16:52:20 status unpacked libc6:amd64 2.29-6
2019-12-13 16:52:20 install libcrypt1:amd64  1:4.4.10-5
2019-12-13 16:52:20 status half-installed libcrypt1:amd64 1:4.4.10-5
2019-12-13 16:52:20 status unpacked libcrypt1:amd64 1:4.4.10-5
2019-12-13 16:52:20 install libcrypt1:i386  1:4.4.10-5
2019-12-13 16:52:20 status half-installed libcrypt1:i386 1:4.4.10-5
2019-12-13 16:52:20 status unpacked libcrypt1:i386 1:4.4.10-5
2019-12-13 16:52:20 configure libcrypt1:amd64 1:4.4.10-5 
2019-12-13 16:52:20 status unpacked libcrypt1:amd64 1:4.4.10-5
2019-12-13 16:52:20 status half-configured libcrypt1:amd64 1:4.4.10-5
2019-12-13 16:52:20 status installed libcrypt1:amd64 1:4.4.10-5
2019-12-13 16:52:20 configure libc6:amd64 2.29-6 
2019-12-13 16:52:20 status unpacked libc6:amd64 2.29-6
2019-12-13 16:52:20 status half-configured libc6:amd64 2.29-6
2019-12-13 16:52:21 status installed libc6:amd64 2.29-6
2019-12-13 16:52:21 configure libcrypt1:i386 1:4.4.10-5 
2019-12-13 16:52:21 status unpacked libcrypt1:i386 1:4.4.10-5
2019-12-13 16:52:21 status half-configured libcrypt1:i386 1:4.4.10-5
2019-12-13 16:52:21 status installed libcrypt1:i386 1:4.4.10-5
2019-12-13 16:52:21 configure libc6:i386 2.29-6 
2019-12-13 16:52:21 status unpacked libc6:i386 2.29-6
2019-12-13 16:52:21 status half-configured libc6:i386 2.29-6
2019-12-13 16:52:23 status installed libc6:i386 2.29-6
2019-12-13 16:52:23 upgrade libc6-dev:amd64 2.28-10 2.29-6
2019-12-13 16:52:23 status half-configured libc6-dev:amd64 2.28-10
2019-12-13 16:52:23 status unpacked libc6-dev:amd64 2.28-10
2019-12-13 16:52:23 status half-installed libc6-dev:amd64 2.28-10
2019-12-13 16:52:23 status unpacked libc6-dev:amd64 2.29-6
2019-12-13 16:52:23 install libcrypt1-dev:amd64  1:4.4.10-5
2019-12-13 16:52:23 status half-installed libcrypt1-dev:amd64 1:4.4.10-5
2019-12-13 16:52:23 status unpacked libcrypt1-dev:amd64 1:4.4.10-5
2019-12-13 15:52:47 configure libcrypt1-dev:amd64 1:4.4.10-5 
2019-12-13 15:52:47 status unpacked libcrypt1-dev:amd64 1:4.4.10-5
2019-12-13 15:52:47 status half-configured libcrypt1-dev:amd64 1:4.4.10-5
2019-12-13 15:52:47 status installed libcrypt1-dev:amd64 1:4.4.10-5
2019-12-13 15:52:48 configure libc6-dev:amd64 2.29-6 
2019-12-13 15:52:48 status unpacked libc6-dev:amd64 2.29-6
2019-12-13 15:52:48 status half-configured libc6-dev:amd64 2.29-6
2019-12-13 15:52:48 status installed libc6-dev:amd64 2.29-6
root@TMP19396:~#

-- 
ciao,
Marco

Bug#946561: Bug #946561

[Didier 'OdyX' Raboud]

Control: severity -1 important
Control: tags -1 +moreinfo

Le mercredi, 11 décembre 2019, 21.04:58 h CET Stefano Fabri a écrit :
> Try to apt-get install hplip when you have in the system python >=3.8
> (https://packages.debian.org/experimental/python3).
> 
> In this status hplip is not installable.

Well. Your bugreport still is not actionable for me as maintainer. What do you 
see on-screen when you do this installation combination (ideally in a 
terminal)? When you say "not installable", what exactly do you mean?

OdyX

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

Bug#946678: [cpp-9] Cannot compile inline asm statement with -m32

[Giovanni Mascellani]

Package: cpp-9
Version: 9.2.1-21
Severity: normal

Hi,

current gcc 9.2 cannot compile this program with -m32:

int main() {
asm volatile ("mov %%eax, %%eax\n" : : "i" ("A string"));
return 0;
}

Result is:

$ gcc -m32 test.c
test.c: In function ‘main’:
test.c:3:5: warning: asm operand 0 probably doesn’t match constraints
3 | asm volatile ("mov %%eax, %%eax\n" : : "i" ("A string"));
  | ^~~
test.c:3:5: error: impossible constraint in ‘asm’

I believe that the program is valid, though. The same program compiles
on Compiler Explorer[1], it compiles with clang, and it compiles with a
vanilla gcc 9.2 compiled from upstream distributed sources. It also
compiles with Debian's gcc 9.2 without -m32.

 [1] https://godbolt.org/z/f87U62

I use an up-to-date Debian sid, with this gcc:

> $ gcc -v
> 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-21' 
> --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 --with-build-config=bootstrap-lto-lean 
> --enable-link-mutex
> Thread model: posix
> gcc version 9.2.1 20191130 (Debian 9.2.1-21) 

The vanilla gcc 9.2 that manages to compile is:

> $ /tmp/gcc/bin/gcc -v
> Using built-in specs.
> COLLECT_GCC=/tmp/gcc/bin/gcc
> COLLECT_LTO_WRAPPER=/tmp/gcc/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ./configure --enable-languages=c --prefix=/tmp/gcc
> Thread model: posix
> gcc version 9.2.0 (GCC) 

Although apparently the same problem appears on Arch[2].

 [2]
https://lists.nongnu.org/archive/html/tinycc-devel/2019-12/msg00075.html

Thanks, Giovanni.


--- System information. ---
Architecture: Kernel:   Linux 5.2.0-3-amd64

Debian Release: bullseye/sid
  500 xenial  updates.signal.org   500 unstable-debug
debug.mirrors.debian.org   500 unstabledeb.debian.org   500
testing deb.debian.org   500 stable  repo.skype.com
500 stable  dl.google.com 1 experimentaldeb.debian.org
--- Package information. ---
Depends(Version) | Installed
-+-==
gcc-9-base  (= 9.2.1-21) | libc6  (>= 2.14) | libgmp10
 (>= 2:5.0.1~) | libisl22   (>= 0.15) | libmpc3
 | libmpfr6  (>= 3.1.3) | zlib1g  (>= 1:1.1.4) |

Package's Recommends field is empty.

Suggests   (Version) | Installed
-+-===
gcc-9-locales (>= 8) |
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#880556: parse upstream metadata files like package.json or .gemspec files

[Andrej Shadura]

Hi,

On Sun, 05 Nov 2017 11:49:29 +0100 Dominique Dumont  wrote:
> On Thursday, 2 November 2017 14:28:12 CET you wrote:
> > Most ruby gems have the license information in .gemspec file and
> > similarly most nodejs modules have this information in package.json file
> > (likely for similar files for other languages). It would be good to
> > parse it and use that information.
> 
> Yes, good idea. I'm thinking also to parse the content of META.yml to 
> retrieve 
> the same kind of information.
> 
> Do you have examples of one ruby and one nodejs package that could be used as 
> a reference ?
> 
> Then I just need to find time to do this...

Please find attached proof of concept scanner for Rust Cargo.toml files.
I’m not fluent in Perl, and I wasn’t sure where exactly to put this
piece of code, but this is something you probably can polish up a bit.

Thanks for considering this.

-- 
Cheers,
  Andrej
>From 7ddbb0ac66bd50145a0d6e11d9c574a78e396389 Mon Sep 17 00:00:00 2001
From: Andrej Shadura 
Date: Fri, 13 Dec 2019 16:07:46 +0100
Subject: [PATCH] WIP: Scan Rust source code getting the defaults from
 Cargo.toml

---
 lib/Dpkg/Copyright/Scanner.pm | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/lib/Dpkg/Copyright/Scanner.pm b/lib/Dpkg/Copyright/Scanner.pm
index 453825a3..3d2bc46f 100644
--- a/lib/Dpkg/Copyright/Scanner.pm
+++ b/lib/Dpkg/Copyright/Scanner.pm
@@ -9,6 +9,7 @@ use Exporter::Lite;
 use Array::IntSpan;
 use Path::Tiny;
 use Carp;
+use TOML;
 use YAML::Tiny;
 
 use feature qw/postderef signatures/;
@@ -132,6 +133,7 @@ $default{check} = << 'EOR2' ;
|sh
|php
|py(|x)
+   |rs   # rust
|rb
|java
|js
@@ -683,6 +685,27 @@ sub __load_fill_blank_data ($current_dir) {
 }
 }
 
+my $cargotoml = $current_dir->child('Cargo.toml');
+if ($cargotoml->is_file) {
+my $toml = $cargotoml->slurp_utf8;
+my $data = TOML::from_toml($toml);
+my $l = $data->{'package'}{'license'};
+my $c = $data->{'package'}{'authors'};
+if (!$fill_blanks{'.*'}) {
+if (defined $l) {
+# Cargo.toml spells AND and OR in capitals
+# and allows / as a synonym to OR
+$l =~ s! AND ! and !g;
+$l =~ s! OR ! or !g;
+$l =~ s!/! or !g;
+$fill_blanks{'.*'}->{license} = $l;
+}
+if (defined $c) {
+$fill_blanks{'.*'}->{copyright} = join("\n ", @$c);
+}
+}
+}
+
 return \%fill_blanks;
 }
 
-- 
2.20.1

Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

[Andreas Tille]

On Fri, Dec 13, 2019 at 03:16:32PM +0100, Andreas Tille wrote:
> 
> ...
> g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
> -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib 
> -lpython3.7m -lpython3.7
> /usr/bin/ld: cannot find -lpython3.7
> collect2: error: ld returned 1 exit status
> ...
> 
> AAArgh, now we just need to get rid of the unwanted stuff.  Any scons
> expert around?

I think at least this is solved now:

   
https://salsa.debian.org/med-team/pdb2pqr/commit/1f4ee901456641140ef18ca8e91e4701e1175410

I might come back with other issues

 Andreas.

-- 
http://fam-tille.de

Bug#946677: cdbs: always expects debian/compat, even if using debhelper-compat in b-d

[Sandro Tosi]

> Hello,
> many packages are now migrating to use debhelper-compat (= VERSION) in their
> biuld-depends, but it looks like cdbs still expects to find a debian/compat 
> file
> to define the compatibility and if missing, it creates one with default value 
> of
> 5.
>
> This leads to FTBFS with
>
> ```
> dh_clean -k
> dh_clean: Please specify the debhelper compat level exactly once.
> dh_clean:  * debian/compat requests compat 5.
> dh_clean:  * debian/control requests compat 9 via "debhelper-compat (= 9)"
> dh_clean: debhelper compat level specified both in debian/compat and via 
> build-dependency on debhelper-compat
> make: *** [/usr/share/cdbs/1/rules/debhelper.mk:214: 
> common-install-prehook-impl] Error 255
> ```
>
> please update cdbs to support debhelper-compat

https://salsa.debian.org/build-common-team/cdbs/blob/master/1/rules/debhelper.mk.in#L85-88

not even `export DH_COMPAT=VERSION` in debian/rules helps, as packages
still FTBFS with

dh_prep: Please specify the debhelper compat level exactly once.
dh_prep:  * debian/compat requests compat 9.
dh_prep:  * debian/control requests compat 9 via "debhelper-compat (= 9)"
dh_prep: debhelper compat level specified both in debian/compat and
via build-dependency on debhelper-compat


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#946677: cdbs: always expects debian/compat, even if using debhelper-compat in b-d

[Sandro Tosi]

Package: cdbs
Version: 0.4.159
Severity: important

Hello,
many packages are now migrating to use debhelper-compat (= VERSION) in their
biuld-depends, but it looks like cdbs still expects to find a debian/compat file
to define the compatibility and if missing, it creates one with default value of
5.

This leads to FTBFS with

```
dh_clean -k 
dh_clean: Please specify the debhelper compat level exactly once.
dh_clean:  * debian/compat requests compat 5.
dh_clean:  * debian/control requests compat 9 via "debhelper-compat (= 9)"
dh_clean: debhelper compat level specified both in debian/compat and via 
build-dependency on debhelper-compat
make: *** [/usr/share/cdbs/1/rules/debhelper.mk:214: 
common-install-prehook-impl] Error 255
```

please update cdbs to support debhelper-compat


Regards,
Sandro

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

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

cdbs depends on no packages.

Versions of packages cdbs recommends:
ii  autotools-dev  20180224.1

Versions of packages cdbs suggests:
ii  devscripts  2.19.5

-- no debconf information

Bug#946676: Acknowledgement (Build autopkgtest improvements)

[Sebastien Bacher]

Updated patch, setting '-eu' mode so the test fails if one of the
command errors out
diff -Nru libhandy-0.0.12/debian/changelog libhandy-0.0.12/debian/changelog
--- libhandy-0.0.12/debian/changelog2019-12-12 09:49:04.0 +0100
+++ libhandy-0.0.12/debian/changelog2019-12-13 15:07:06.0 +0100
@@ -1,3 +1,14 @@
+libhandy (0.0.12-2) UNRELEASED; urgency=medium
+
+  * debian/tests:
+update the build test to closer from other GNOME ones
+and fix some issues/the current test failing
+- don't use a deprecated function
+- handle cross build autopkgtest environment
+- include a runtime test as well
+
+ -- Sebastien Bacher   Fri, 13 Dec 2019 13:17:01 +0100
+
 libhandy (0.0.12-1) unstable; urgency=medium
 
   * New upstream version 0.0.12
diff -Nru libhandy-0.0.12/debian/tests/build-test 
libhandy-0.0.12/debian/tests/build-test
--- libhandy-0.0.12/debian/tests/build-test 2019-04-23 12:40:50.0 
+0200
+++ libhandy-0.0.12/debian/tests/build-test 2019-12-13 15:17:15.0 
+0100
@@ -1,9 +1,29 @@
-#!/usr/bin/make -f
+#!/bin/sh
+set -eu
 
-CFLAGS=$(shell pkg-config --cflags libhandy-0.0)
-LIBS=$(shell pkg-config --libs libhandy-0.0)
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
 
-a.out: debian/tests/build-test.c
-   gcc $(CFLAGS) $< $(LIBS)
-   @echo "Build test of $< succeeded"
-   @rm -f a.out
+cd "$AUTOPKGTEST_TMP"
+
+cat < handytest.c
+#include 
+#define HANDY_USE_UNSTABLE_API
+#include 
+
+int
+main (intargc,
+  char **argv)
+{
+   hdy_init(, );
+}
+EOF
+
+${CROSS_COMPILE}gcc -o handytest handytest.c $(${CROSS_COMPILE}pkg-config 
--cflags --libs libhandy-0.0)
+echo "build ok"
+[ -x handytest ]
+xvfb-run -a -s "-screen 0 1024x768x24" ./handytest
+echo "starts ok"
diff -Nru libhandy-0.0.12/debian/tests/build-test.c 
libhandy-0.0.12/debian/tests/build-test.c
--- libhandy-0.0.12/debian/tests/build-test.c   2019-10-25 21:01:06.0 
+0200
+++ libhandy-0.0.12/debian/tests/build-test.c   1970-01-01 01:00:00.0 
+0100
@@ -1,10 +0,0 @@
-#include 
-#define HANDY_USE_UNSTABLE_API
-#include 
-
-int
-main (intargc,
-  char **argv)
-{
-   hdy_dialer_new ();  
-}
diff -Nru libhandy-0.0.12/debian/tests/control 
libhandy-0.0.12/debian/tests/control
--- libhandy-0.0.12/debian/tests/control2019-10-25 21:01:06.0 
+0200
+++ libhandy-0.0.12/debian/tests/control2019-12-13 14:59:16.0 
+0100
@@ -1,5 +1,5 @@
 Tests: build-test
-Depends: libhandy-0.0-dev, build-essential, pkg-config
+Depends: libhandy-0.0-dev, build-essential, pkg-config, xauth, xvfb
 Restrictions: allow-stderr
 
 Tests: python-gi-test

Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

[Andreas Tille]

On Fri, Dec 13, 2019 at 05:46:42PM +0500, Andrey Rahmatullin wrote:
> > 
> > Thanks for that additional hint.  I can confirm that I checked whether
> > pkgconfig can be used before I was asking here.  But we seem to agree
> > that this is not the case.  I admit I have no real clue how to convince
> > scons to link to the correct library name. :-(
> I have no idea either. It seems that it just uses the scons compilation
> code by creating an env.LoadableModule.

I tried a patch to use pkg-config which **partly** works:

...
g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
-Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib 
-lpython3.7m -lpython3.7
/usr/bin/ld: cannot find -lpython3.7
collect2: error: ld returned 1 exit status
...

AAArgh, now we just need to get rid of the unwanted stuff.  Any scons
expert around?

Kind regards, Andreas.


[1] 
https://salsa.debian.org/med-team/pdb2pqr/commit/dbee7b96cdb8cad7b60e8c6acffea068664ebe7c

-- 
http://fam-tille.de

Bug#946676: Build autopkgtest improvements

[Sebastien Bacher]

Package: libhandy
Version: 0.0.12-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

The new version is failing the build autopkgtest
https://ci.debian.net/data/autopkgtest/testing/amd64/libh/libhandy/3651396/log.gz



The attached patch fixes the issue and update the build test to be
closer from what other GNOME components are doing

- update the test to be cross-test friendly (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946303 for
details/another example of such changes already done in Debian)

- convert to use one sh script including the source and compiling in the
tmpdir, basically copying the format used by other GNOME Debian packages

- add a runtime basic command

Cheers,

diff -Nru libhandy-0.0.12/debian/changelog libhandy-0.0.12/debian/changelog
--- libhandy-0.0.12/debian/changelog2019-12-12 09:49:04.0 +0100
+++ libhandy-0.0.12/debian/changelog2019-12-13 15:07:06.0 +0100
@@ -1,3 +1,14 @@
+libhandy (0.0.12-2) UNRELEASED; urgency=medium
+
+  * debian/tests:
+update the build test to closer from other GNOME ones
+and fix some issues/the current test failing
+- don't use a deprecated function
+- handle cross build autopkgtest environment
+- include a runtime test as well
+
+ -- Sebastien Bacher   Fri, 13 Dec 2019 13:17:01 +0100
+
 libhandy (0.0.12-1) unstable; urgency=medium
 
   * New upstream version 0.0.12
diff -Nru libhandy-0.0.12/debian/tests/build-test 
libhandy-0.0.12/debian/tests/build-test
--- libhandy-0.0.12/debian/tests/build-test 2019-04-23 12:40:50.0 
+0200
+++ libhandy-0.0.12/debian/tests/build-test 2019-12-13 15:09:37.0 
+0100
@@ -1,9 +1,28 @@
-#!/usr/bin/make -f
+#!/bin/sh
 
-CFLAGS=$(shell pkg-config --cflags libhandy-0.0)
-LIBS=$(shell pkg-config --libs libhandy-0.0)
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
 
-a.out: debian/tests/build-test.c
-   gcc $(CFLAGS) $< $(LIBS)
-   @echo "Build test of $< succeeded"
-   @rm -f a.out
+cd "$AUTOPKGTEST_TMP"
+
+cat < handytest.c
+#include 
+#define HANDY_USE_UNSTABLE_API
+#include 
+
+int
+main (intargc,
+  char **argv)
+{
+   hdy_init(, );
+}
+EOF
+
+${CROSS_COMPILE}gcc -o handytest handytest.c $(${CROSS_COMPILE}pkg-config 
--cflags --libs libhandy-0.0)
+echo "build ok"
+[ -x handytest ]
+xvfb-run -a -s "-screen 0 1024x768x24" ./handytest
+echo "starts ok"
diff -Nru libhandy-0.0.12/debian/tests/build-test.c 
libhandy-0.0.12/debian/tests/build-test.c
--- libhandy-0.0.12/debian/tests/build-test.c   2019-10-25 21:01:06.0 
+0200
+++ libhandy-0.0.12/debian/tests/build-test.c   1970-01-01 01:00:00.0 
+0100
@@ -1,10 +0,0 @@
-#include 
-#define HANDY_USE_UNSTABLE_API
-#include 
-
-int
-main (intargc,
-  char **argv)
-{
-   hdy_dialer_new ();  
-}
diff -Nru libhandy-0.0.12/debian/tests/control 
libhandy-0.0.12/debian/tests/control
--- libhandy-0.0.12/debian/tests/control2019-10-25 21:01:06.0 
+0200
+++ libhandy-0.0.12/debian/tests/control2019-12-13 14:59:16.0 
+0100
@@ -1,5 +1,5 @@
 Tests: build-test
-Depends: libhandy-0.0-dev, build-essential, pkg-config
+Depends: libhandy-0.0-dev, build-essential, pkg-config, xauth, xvfb
 Restrictions: allow-stderr
 
 Tests: python-gi-test

Bug#946667: Proposing patch to fix the bug

[DarthDragon]

Hi,

I dive into the problem and I thing the attached patch (generated with
quilt) should fix the problems.
I installed it on my mercurial server, and I can't see any problem yet.
I didn't find any test suite to validate I didn't break anything.

BR,
Jeremy
fix: repo.changectx method has been removed from the API
fix: repo.join method has been removed from the API
Index: mercurial-server-1.2/src/mercurialserver/changes.py
===
--- mercurial-server-1.2.orig/src/mercurialserver/changes.py	2011-09-06 12:40:10.0 +0200
+++ mercurial-server-1.2/src/mercurialserver/changes.py	2019-12-13 14:48:13.712436790 +0100
@@ -3,10 +3,10 @@
 """
 
 def changes(repo, node):
-start = repo.changectx(node).rev()
+start = repo[node].rev()
 try:
 end = len(repo.changelog)
 except:
 end = repo.changelog.count()
 for rev in xrange(start, end):
-yield repo.changectx(rev)
+yield repo[repo.changelog.node(rev)]
Index: mercurial-server-1.2/src/mercurialserver/servelog.py
===
--- mercurial-server-1.2.orig/src/mercurialserver/servelog.py	2011-09-06 12:40:10.0 +0200
+++ mercurial-server-1.2/src/mercurialserver/servelog.py	2019-12-13 14:48:13.720436800 +0100
@@ -26,7 +26,7 @@
 else:
 raise mercurial.util.Abort(_('servelog installed as wrong hook type,'
 ' must be changegroup or outgoing but is %s') % hooktype)
-log = open(repo.join("mercurial-server.log"), "a+")
+log = open(os.path.join(repo.path, "mercurial-server.log"), "a+")
 try:
 fcntl.flock(log.fileno(), fcntl.LOCK_EX)
 log.seek(0, os.SEEK_END)

Bug#946675: scan-copyrights: try to avoid dumping binary junk into the output

[Andrej Shadura]

Package: src:libconfig-model-dpkg-perl
Version: 2.127
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I wrote a patch to reduce the amount of junk being output when
scanning binary files by cutting off the worst offenders.

Please see 
https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/merge_requests/1
for more details.

Thanks.

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iJUEARYIAD0WIQT/pgwAncVK7KA57JwlJunrgoqPNQUCXfOZVR8cYW5kcmV3LnNo
YWR1cmFAY29sbGFib3JhLmNvLnVrAAoJECUm6euCio81megA/3VEdLaIT5BMGu1U
FAVJ74pmdcmJ7vFEAS57oLocTimKAQCJJzp4fg0Xb1IrrAiFa/WOpzKf5cwmY5gb
xsU8qb48Cg==
=v7/e
-END PGP SIGNATURE-

Bug#880368: YAML::XS::Load expects utf8 octets, not perl's encoding; use slurp_raw

[Andrej Shadura]

On Sun, 05 Nov 2017 18:32:48 +0100 Dominique Dumont  wrote:
> On Monday, 30 October 2017 15:27:32 CET you wrote:
> > YAML::XS::Load (and *hopefully* the other implementations of
> > YAML::Any::Load?) expect utf8 octets on input, not perl's internal
> > encoding.
> 
> Uh ? I thought I had gotten rid of YAML::Any... Well, after checking, it 
> turns 
> out that I've updated Config;:Model::Backend::Yaml, but I forgot to update 
> Dpkg::Scanner.
> 
> Anyway, using YAML::Any has several problems:
> - it's deprecated
> - it may load YAML or YAML::XS which have some security issues [1]
> 
> > Thus, slurp_raw should be used instead of slurp_utf8. [Though really,
> > YAML::XS::Load should probably do the right thing if is_utf8 is on,
> > anyway.]
> 
> Unfortunately, the strings returned by YAML::XS is not tagged as utf-8, which 
> leads to writing mojibake when cme is used to update debian/copyright.
>
> Given the security issues of YAML and YAML::XS, I'm not going to tweak the 
> structure returned by YAML::XS to fix the utf8 flag of each scalar contained 
> the structure (and may be all hash keys ..)
> 
> Instead, I'm going to replace YAML::Any with YAML::Tiny (which is more than 
> enough in this case).

Unfortunately, YAML::Tiny disallows some valid YAML markup, in
particular what pyyaml generates by default and which is very difficult
to change without in-depth hacking of it:

".*":
  "license": |-
GPL-2
"debian/":
  "copyright": "A B \n B C \n C\
\ D \n D E \n E F\
\ \n F G \n G H "
  "license": |-
GPL-2+

As a temporary workaround, I patched the locally used version to use
YAML::XS, but as I see you won’t accept this patch upstream. Is there a
solution that would satisfy both conditions of how having security
issues and supporting proper YAML? By the way, what are those security
issues and how serious and relevant to scan-copyrights are they?

> Thanks for the report . This helps me improve dpkg model for cme (and led to 
> the release of Config::Model::Tester 3.003 which did not handle utf-8 
> correctly while checking file content).


-- 
Cheers,
  Andrej

Bug#946588: thunderbird's dowgrade prevention is being triggered after upgrade from stretch

[Emilio Pozuelo Monfort]

On 12/12/2019 13:58, Carsten Schoenert wrote:
> Hi Emilio,
> 
> Am 12.12.19 um 13:13 schrieb Emilio Pozuelo Monfort:
> 
>> We should be able to fix this by setting the build id to the timestamp from 
>> the
>> changelog, then making sure we use slightly older timestamps in older 
>> releases,
>> so that jessie < stretch < buster < sid. From looking at the code and 
>> d/rules,
>> that was already the intention, but it's currently broken. I'm testing a 
>> patch
>> to fix it, will send it later after verifying it.
> 
> really appreciated!
> Feel free to push this directly to Salsa.

Pushed to branch debian/sid. That should fix this error during the build:

 0:01.29 ./buildid.h.stub
 0:01.41 Ignoring invalid MOZ_BUILD_DATE: 1575912135

And consequently the timestamp in the build id header of the application.ini
file will be that one of the changelog. This also should make that part of the
build reproducible.

The change can be backported to buster and stretch. jessie needs an adapted fix
because SOURCE_DATE_EPOCH is not available with its dpkg but I will take care of
that.

Cheers,
Emilio

Bug#936270: closed by Norbert Preining (Bug#936270: fixed in calibre 4.4.0+dfsg-1)

[Norbert Preining]

reopen 936270
found 936270
thanks

Hi Dmitry,

On Fri, 13 Dec 2019, Dmitry Shachnev wrote:
> >* drop cherrypi deps (Closes: #936270)
> 
> Why did you close this bug in 4.4.0+dfsg-1? As I can see, calibre still
> uses Python 2 in sid, and only the experimental package uses Python 3.

Indeed this was complete rubbish, sorry. I somehow lost track of the
long email thread and saw the last emails about cherrypi only, and
thought the bug was about that.

Already reopened - and you don't need to ask for such an obvious error
of mine, just reopen it!

Thanks a lot!

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

[Andrey Rahmatullin]

On Fri, Dec 13, 2019 at 01:40:34PM +0100, Andreas Tille wrote:
> > > g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
> > > -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os 
> > > -L/usr/lib -lpython3.7
> > > /usr/bin/ld: cannot find -lpython3.7
> > Actually, it's a different problem, sorry.
> > There is no -lpython3.7, only -lpython3.7m. If the build system used
> > pkgconfig it would know that. I guess the library name is hardcoded
> > instead? I see that it got -I/usr/include/python3.7m from somewhere, so
> > it's not completely broken.
> 
> Thanks for that additional hint.  I can confirm that I checked whether
> pkgconfig can be used before I was asking here.  But we seem to agree
> that this is not the case.  I admit I have no real clue how to convince
> scons to link to the correct library name. :-(
I have no idea either. It seems that it just uses the scons compilation
code by creating an env.LoadableModule.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

[Andreas Tille]

Hi Andrey,

On Fri, Dec 13, 2019 at 05:18:45PM +0500, Andrey Rahmatullin wrote:
> On Fri, Dec 13, 2019 at 09:49:47AM +0100, Andreas Tille wrote:
> > g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
> > -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib 
> > -lpython3.7
> > /usr/bin/ld: cannot find -lpython3.7
> Actually, it's a different problem, sorry.
> There is no -lpython3.7, only -lpython3.7m. If the build system used
> pkgconfig it would know that. I guess the library name is hardcoded
> instead? I see that it got -I/usr/include/python3.7m from somewhere, so
> it's not completely broken.

Thanks for that additional hint.  I can confirm that I checked whether
pkgconfig can be used before I was asking here.  But we seem to agree
that this is not the case.  I admit I have no real clue how to convince
scons to link to the correct library name. :-(

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#892490: libpaper leaks file descriptor when /etc/papersize is empty

[Dusan Stloukal]

Hi,

this bug hit us when calling ghostscript from PHP code. We are running
PHP fastcgi process manager (php-fpm). It means PHP workers are not
killed after the request is answered to the client and it means
/etc/papersize file descriptors remains alive and the number increases
with each client request.

There are some workarounds like kill PHP worker after few client
requests are answered or using the ghostscript parameter 
"-sDEFAULTPAPERSIZE=".

But it would be also nice (at least to system resources) to have this
bug resolved.

Thank you in advance!


Dusan

Bug#946671: [debian-mysql] Bug#946671: mariadb-server-10.3: mysqlhotcopy and transaction_registry table

[Otto Kekäläinen]

Hello!

Thanks for reporting and the patch!

Since that patch is not about Debian packaging, I suggest you submit it
upstream at https://github.com/mariadb/server branch 10.3 (or latest 10.5).

Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

[Andrey Rahmatullin]

On Fri, Dec 13, 2019 at 09:49:47AM +0100, Andreas Tille wrote:
> g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
> -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib 
> -lpython3.7
> /usr/bin/ld: cannot find -lpython3.7
Actually, it's a different problem, sorry.
There is no -lpython3.7, only -lpython3.7m. If the build system used
pkgconfig it would know that. I guess the library name is hardcoded
instead? I see that it got -I/usr/include/python3.7m from somewhere, so
it's not completely broken.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#946670: ITP: tcl9.0 -- Tcl (the Tool Command Language) v9.0

[Sergei Golovan]

Hi YunQiang,

On Fri, Dec 13, 2019 at 3:05 PM YunQiang Su  wrote:
>
> Sergei Golovan  于2019年12月13日周五 下午6:30写道：
> >
> > Package: wnpp
> > Severity: wishlist
> > Owner: Sergei Golovan 
> >
> > * Package name: tcl9.0
> >   Version : 9.0a1
>
> I guess the version should be 9.0~a1

For the Debian package it will be. It's an upstream version.

Cheers!
-- 
Sergei Golovan

Bug#946670: ITP: tcl9.0 -- Tcl (the Tool Command Language) v9.0

[YunQiang Su]

Sergei Golovan  于2019年12月13日周五 下午6:30写道：
>
> Package: wnpp
> Severity: wishlist
> Owner: Sergei Golovan 
>
> * Package name: tcl9.0
>   Version : 9.0a1

I guess the version should be 9.0~a1

>   Upstream Author : Tcl Core Team
> * URL : http://www.tcl.tk/
> * License : (BSD)
>   Programming Lang: (C, Tcl)
>   Description : Tcl (the Tool Command Language) v9.0
>
> Tcl is a powerful, easy-to-use, embeddable, cross-platform interpreted
> scripting language.
>
> It's a new upstream release with major incompatibilities with the
> earlier ones (8.X), so it has to be packaged separately.
>
> The package will be maintained under the Debian Tcl/Tk team.
>
> Version 9.0 is in alpha stage yet, so I intend to upload it to
> experimental at the moment.
>


-- 
YunQiang Su

Bug#946674: ITP: x2gothinclient -- X2Go Thin Client Environment

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: x2gothinclient
  Version : 1.5.0.1
  Upstream Author : X2Go Developers (x2go-...@lists.x2go.org>
* URL : https://code.x2go.org/gitweb?p=x2gothinclient.git;a=summary
* License : GPL-2+ (mostly)
  Programming Lang: C++, Bash, Perl
  Description : X2Go Thin Client Environment

 X2Go is a server based computing environment with
- session resuming
- low bandwidth support
- session broker support
- client-side mass storage mounting support
- client-side printing support
- audio support
- authentication by smartcard and USB stick
 .
 The x2gothinclient src:package comes with various bin:packages that
 facilitate setting up a thin client environment (TCE) targetting
 various server environments (X2Go, XDMCP, MS RDP, xRDP, etc.).
 .
 The thin client packages are designed to work on top of LTSP images and
 can be used as a replacement for the deprecated LTSP Display Manager.
 .
 The packages will be maintained by the Debian Remote Maintainers Team.

Bug#928814: package-update-indicator

[Bernd Scheinbeth]

Dear Maintainer,

I have send you a debug.txt. That was all, what came up in 15 Minutes.

Bernd

Bug#946673: mercurial: zstd decompressor error: Unknown frame descriptor

[Marc Glisse]

Package: mercurial
Version: 5.2.1-1
Severity: normal

Dear Maintainer,

I don't know when exactly this started, but it can't be too long ago. Today I 
see

$ hg clone https://gmplib.org/repo/gmp
destination directory: gmp
requesting all changes
** unknown exception encountered, please report by visiting
** https://mercurial-scm.org/wiki/BugTracker
** Python 2.7.17 (default, Oct 19 2019, 23:36:22) [GCC 9.2.1 20191008]
** Mercurial Distributed SCM (version 5.2.1)
** Extensions loaded: extdiff, pager
Traceback (most recent call last):
  File "/usr/bin/hg", line 36, in 
dispatch.run()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 111, in 
run
status = dispatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 250, in 
dispatch
ret = _runcatch(req) or 0
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 424, in 
_runcatch
return _callcatch(ui, _runcatchfunc)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 433, in 
_callcatch
return scmutil.callcatch(ui, func)
  File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line 177, in 
callcatch
return func()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 414, in 
_runcatchfunc
return _dispatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 1174, in 
_dispatch
lui, repo, cmd, fullargs, ui, options, d, cmdpats, cmdoptions
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 862, in 
runcommand
ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib/python2.7/dist-packages/hgext/pager.py", line 76, in pagecmd
return orig(ui, options, cmd, cmdfunc)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 1185, in 
_runcommand
return cmdfunc()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 1171, in 

d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1845, in check
return func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/mercurial/commands.py", line 1925, in 
clone
depth=opts.get(b'depth') or None,
  File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 901, in clone
depth=depth,
  File "/usr/lib/python2.7/dist-packages/mercurial/exchange.py", line 1780, in 
pull
_fullpullbundle2(repo, pullop)
  File "/usr/lib/python2.7/dist-packages/mercurial/exchange.py", line 1673, in 
_fullpullbundle2
_pullbundle2(pullop)
  File "/usr/lib/python2.7/dist-packages/mercurial/exchange.py", line 1976, in 
_pullbundle2
bundle = e.callcommand(b'getbundle', args).result()
  File 
"/usr/lib/python2.7/dist-packages/mercurial/thirdparty/concurrent/futures/_base.py",
 line 457, in result
return self.__get_result()
  File "/usr/lib/python2.7/dist-packages/mercurial/wireprotov1peer.py", line 
227, in sendcommands
result = fn(**pycompat.strkwargs(args))
  File "/usr/lib/python2.7/dist-packages/mercurial/wireprotov1peer.py", line 
472, in getbundle
return bundle2.getunbundler(self.ui, f)
  File "/usr/lib/python2.7/dist-packages/mercurial/bundle2.py", line 769, in 
getunbundler
magicstring = changegroup.readexactly(fp, 4)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 3585, in 
readexactly
s = stream.read(n)
  File "/usr/lib/python2.7/dist-packages/mercurial/utils/compression.py", line 
378, in read
self._decompress(chunk)
  File "/usr/lib/python2.7/dist-packages/mercurial/utils/compression.py", line 
438, in _decompress
newbuf = self._decompobj.decompress(chunk)
zstd.ZstdError: zstd decompressor error: Unknown frame descriptor

while this still works on a stretch system I have access to. Downgrading 
mercurial to the version from stable does not help, so the issue likely 
appeared with the upgrade of some dependency. Removing ~/.hgrc does not 
help.


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

Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.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 mercurial depends on:
ii  libc6 2.29-3
ii  mercurial-common  5.2.1-1
ii  python2.7.17-2
ii  python2   2.7.17-2
ii  ucf   3.0038+nmu1

Versions of packages mercurial recommends:
ii  openssh-client  1:8.1p1-1

Versions of packages mercurial suggests:
ii  kdiff3 1.8.01-1+b1
ii  kdiff3-qt  1.8.01-1
pn  qct

-- no debconf information

Bug#946672: on install, password query is missing

[Chris Heinze]

Package: otrs2
Version: 6.0.12-1~bpo9+1

on installation, i'm asked:
dbconfig-common? y
hostname? localhost
port? default
database? otrs2
db-path? /var/lib/otrs/db
username? otrs@localhost

next is a prompt labeled "password confirmation". no matter what's input here, 
it is (ofc) wrong. seems like querying the password-to-be-confirmed is missing.
fwiw, identical behaviour with 5.0.16-1+deb9u6

-- 

Mit freundlichen Grüßen / Kind regards,

Chris Heinze
*Network-/System-/DevOps-Engineer*

*PreciBake GmbH*
Gollierstr. 70
80339 München
Deutschland / Germany
*P:* +49-(0)-89-2154895-30 <+49.89.2154895.30>
*F:* +49-(0)-89-2154895-99
*E:* c.hei...@precibake.com
*W:* www.precibake.com



Handelsregister / Commercial Register:
Amtsgericht München, HRB 206356
Steuer-Nr. / Tax-ID143/172/11644
Umsatzsteuer-ID / VAT registration number: DE290040302
Geschäftsführer / Managing Director: Dr. Ingo Stork-Wersborg

Der Inhalt dieser E-Mail ist ausschliesslich fuer den/die bezeichneten 
Empfaenger bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder 
dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der 
Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts 
dieser E-Mail unzulaessig ist. Wir bitten Sie, sich in diesem Fall mit dem 
Absender der E-Mail in Verbindung zu setzen. Wir moechten Sie ausserdem darauf 
hinweisen, dass die Kommunikation per E-Mail ueber das Internet unsicher ist, 
da fuer unberechtigte Dritte grundsaetzlich die Moeglichkeit der Kenntnisnahme 
und Manipulation besteht.
The information contained in this email is intended solely for the 
recipient(s). Access to this email by anyone else is unauthorized. If you are 
not the intended recipient, any form of disclosure, reproduction, distribution 
or any action taken or refrained from in reliance on it, is prohibited. Please 
notify the sender of this email immediately. We also like to inform you that 
communication via email over the internet is insecure because third parties may 
have the possibility to access and manipulate emails.

Bug#946671: mariadb-server-10.3: mysqlhotcopy and transaction_registry table

[Paul Szabo]

Package: mariadb-server-10.3
Version: 10.3.18-0+deb10u1
Severity: normal
Tags: patch

Using mysqlhotcopy, I received the error:

  DBD::mysql::db do failed: You can't use locks with log tables at 
/usr/bin/mysqlhotcopy line 545.

(Your line number may differ: I use my "own" mysqlhotcopy, as per
http://bugs.debian.org/735014 .)

This seems related to the new transaction_registry table
as suggested in
  https://mariadb.com/kb/en/library/mysqldump/
that says:
  mysqldump in MariaDB 10.3 includes logic to cater for the
  mysql.transaction_registry table. ...

My patch for this issue, below.

Cheers, Paul


--- /usr/bin/mysqlhotcopy.OLD   2017-12-26 09:11:27.0 +1100
+++ /usr/bin/mysqlhotcopy   2019-12-13 21:10:34.225611502 +1100
@@ -317,8 +317,24 @@
 ## keep in sync with mysqldump.
 if ($db =~ m/^mysql$/i)
 {
+#
+#  @dbh_base_tables = grep 
+#{ !/^(apply_status|schema|general_log|slow_log)$/ } @dbh_base_tables
+#
+# PSz 13 Dec 2019
+# Skip transaction_registry also.
+# See also:
+#   https://bugs.mysql.com/bug.php?id=43594
+#   https://bugs.debian.org/574514
+# and see
+#   https://mariadb.com/kb/en/library/mysqldump/
+# that says:
+#   mysqldump in MariaDB 10.3 includes logic to cater for the 
mysql.transaction_registry table. ...
+# but I guess they forgot about mysqlhotcopy.
+#
   @dbh_base_tables = grep 
-{ !/^(apply_status|schema|general_log|slow_log)$/ } @dbh_base_tables
+{ !/^(apply_status|schema|general_log|slow_log|transaction_registry)$/ 
} @dbh_base_tables
+#
 }
 
 ## generate regex for tables/files


-- 
Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia