Bug#983004: marked as done (bind9: CVE-2020-8625)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Thu, 18 Feb 2021 07:48:35 +
with message-id 
and subject line Bug#983004: fixed in bind9 1:9.16.12-1
has caused the Debian Bug report #983004,
regarding bind9: CVE-2020-8625
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
983004: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983004
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: bind9
Version: 1:9.16.11-2
Severity: grave
Tags: security upstream fixed-upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:9.11.5.P4+dfsg-5.1+deb10u2
Control: found -1 1:9.11.5.P4+dfsg-5.1
Control: fixed -1 1:9.11.5.P4+dfsg-5.1+deb10u3

Hi,

The following vulnerability was published for bind9.

CVE-2020-8625[0]:
| BIND servers are vulnerable if they are running an affected version
| and are configured to use GSS-TSIG features. In a configuration which
| uses BIND's default settings the vulnerable code path is not exposed,
| but a server can be rendered vulnerable by explicitly setting valid
| values for the tkey-gssapi-keytab or tkey-gssapi-
| credentialconfiguration options. Although the default configuration is
| not vulnerable, GSS-TSIG is frequently used in networks where BIND is
| integrated with Samba, as well as in mixed-server environments that
| combine BIND servers with Active Directory domain controllers. The
| most likely outcome of a successful exploitation of the vulnerability
| is a crash of the named process. However, remote code execution, while
| unproven, is theoretically possible. Affects: BIND 9.5.0 -
| 9.11.27, 9.12.0 - 9.16.11, and versions BIND 9.11.3-S1 -
| 9.11.27-S1 and 9.16.8-S1 - 9.16.11-S1 of BIND Supported Preview
| Edition. Also release versions 9.17.0 - 9.17.1 of the BIND 9.17
| development branch


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-8625
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8625
[1] https://kb.isc.org/v1/docs/cve-2020-8625
[2] 
https://gitlab.isc.org/isc-projects/bind9/commit/b04cb88462863d762093760ffcfe1946200e30f5

Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Source: bind9
Source-Version: 1:9.16.12-1
Done: Ondřej Surý 

We believe that the bug you reported is fixed in the latest version of
bind9, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 983...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ondřej Surý  (supplier of updated bind9 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 18 Feb 2021 08:13:58 +0100
Source: bind9
Architecture: source
Version: 1:9.16.12-1
Distribution: unstable
Urgency: high
Maintainer: Debian DNS Team 
Changed-By: Ondřej Surý 
Closes: 983004
Changes:
 bind9 (1:9.16.12-1) unstable; urgency=high
 .
   * New upstream version 9.16.12
+ [CVE-2020-8625]: Fix off-by-one bug in ISC SPNEGO implementation.
  (Closes: #983004)
   * Adjust the bind9-libs and bind9-dev packages for new upstream library
 names
Checksums-Sha1:
 ac3527eb770a08a7f974ee095362f4e8e5beecaf 2992 bind9_9.16.12-1.dsc
 4e75a4c9ffb905d7eaa389464f0f3418c94cb2e7 5017756 bind9_9.16.12.orig.tar.xz
 e7261896ff97242c06698da6bf9abb19e61c9dc6 77340 bind9_9.16.12-1.debian.tar.xz
 9ad3cf9d40daebd3aa7313cde3a9e9c0ad6a7107 15113 bind9_9.16.12-1_amd64.buildinfo
Checksums-Sha256:
 40bc601f6ca701f9ad293f0c9f8db7952dedd773c03c5bbcf629348324d165e6 2992 
bind9_9.16.12-1.dsc
 9914af9311fd349cab441097898d94fb28d0bfd9bf6ed04fe1f97f042644da7f 5017756 
bind9_9.16.12.orig.tar.xz
 e3a255242047d649bce8dfcf956ce79dd7d34ddd1ae429e942045135f3258160 77340 
bind9_9.16.12-1.debian.tar.xz
 420043b76dd1d42928e4bdb92bec4653b944dbbba24e7a0ddd4f5ac248396a1c 15113 
bind9_9.16.12-1_amd64.buildinfo
Files:
 631e74530f08e56dcfb4c3d9c69c5958 2992 net optional bind9_9.16.12-1.dsc
 61c545db393628152e5b2c957e8bf712 5017756 net optional bind9_9.16.12.orig.tar.xz
 f265e99a81e5a8ef0920e0853bcf4f95 77340 net optional 
bind9_9.16.12-1.debian.tar.xz
 

Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary

2021-02-17 Thread Limonciello, Mario
Paul,

I don't have the power to manually run it. So there is nothing I can do. With 
the new 1.5.6-1 upload someone will need to manually run it again.

Get Outlook for Android


From: Paul Gevers 
Sent: Thursday, February 18, 2021, 00:09
To: 973...@bugs.debian.org
Subject: Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd 
update results in segfaulting binary

Hi Mario,

LOn Mon, 16 Nov 2020 16:01:34 + "Limonciello, Mario"
 wrote:
> As @Steve McIntyre mentions, it's a manual process to kick off the re-signing.
> It needs to be done when 1.5.1-2 is ready to migrate.

There's users of unstable too. In my opinion, if you can't relax the
constraints, you'll have to kick it off as soon as it's needed in
unstable, not when it's ready to migrate.

Paul




Processed: notfixed 982992 in node-regjsparser/4.7.1-2

2021-02-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> notfixed 982992 node-regjsparser/4.7.1-2
Bug #982992 [src:node-regjsparser, src:node-regexpu-core] node-regjsparser 
breaks node-regexpu-core autopkgtest: Missing expected exception (Error).
The source node-regjsparser and version 4.7.1-2 do not appear to match any 
binary packages
No longer marked as fixed in versions node-regjsparser/4.7.1-2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
982992: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982992
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#983017: 9base: flaky autopkgtest on i386: stack smashing detected

2021-02-17 Thread Paul Gevers
Source: 9base
Version: 1:6-10
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

shoogle has an autopkgtest, great. However, on i386 it fails more often
than it passes [1].

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

On top of that stack smashing seems a serious issue on it's own.

I copied the output at the bottom of this report. Can you please look
into it and make the test more robust (against network issues). If you
keep the test that requires internet, you should add the needs-internet
restriction too.

Paul

[1] https://ci.debian.net/packages/9/9base/testing/i386/

https://ci.debian.net/data/autopkgtest/testing/i386/9/9base/10243149/log.gz

autopkgtest [18:26:16]: test command14: RP=/usr/lib/plan9/bin;
$RP/fortune debian/tests/lorem.txt | $RP/sha1sum
autopkgtest [18:26:16]: test command14: [---
*** stack smashing detected ***: terminated
bash: line 1:  3091 Done$RP/fortune
debian/tests/lorem.txt
  3092 Aborted | $RP/sha1sum
autopkgtest [18:26:16]: test command14: ---]



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983014: manpages-de: Fails to upgrade from 4.2.0-1 to 4.9.1-5: This installation run will require temporarily removing the essential package manpages-de:amd64 due to a Conflicts/Pre-Depends loop.

2021-02-17 Thread Axel Beckert
Package: manpages-de
Version: 4.9.1-5
Severity: serious

On several of my systems, manpages-de fails to upgrade from 4.2.0-1 to
4.9.1-5 as follows:

Get:1 https://debian.ethz.ch/debian sid/main amd64 manpages-de all 4.9.1-5 
[2750 kB]
Fetched 2750 kB in 0s (12.8 MB/s)
E: This installation run will require temporarily removing the essential 
package manpages-de:amd64 due to a Conflicts/Pre-Depends loop. This is often 
bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
E: Internal Error, Could not early remove manpages-de:amd64 (2)

I though have no idea why apt regards manpages-de as
essential. X-Debbugs-Cc'ing the APT developers at
de...@lists.debian.org.

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

manpages-de depends on no packages.

manpages-de recommends no packages.

Versions of packages manpages-de suggests:
ii  man-db [man-browser]  2.9.4-1
ii  manpages  5.10-1

-- no debconf information



Bug#983013: m2crypto: autopkgtest needs update for new version of openssl: M2Crypto.RSA.RSAError: sslv3 rollback attack

2021-02-17 Thread Paul Gevers
Source: m2crypto
Version: 0.37.1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, open...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:openssl

Dear maintainer(s),

With a recent upload of openssl the autopkgtest of m2crypto fails in
testing when that autopkgtest is run with the binary packages of openssl
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
opensslfrom testing1.1.1j-1
m2crypto   from testing0.37.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.  I *think*
this may be related to CVE-2020-25657 "bleichenbacher timing attacks in
the RSA decryption API" against m2crypto, hence I file this bug against
m2crypto.

Currently this regression is blocking the migration of openssl to
testing [1]. Of course, openssl shouldn't just break your autopkgtest
(or even worse, your package), but it seems to me that the change in
openssl was intended and your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from openssl should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=openssl

https://ci.debian.net/data/autopkgtest/testing/amd64/m/m2crypto/10541025/log.gz

=== FAILURES
===
___ RSATestCase.test_public_encrypt


self = 

@unittest.skipIf(m2.OPENSSL_VERSION_NUMBER < 0x1010103f,
 'Relies on fix which happened only in OpenSSL 1.1.1c')
def test_public_encrypt(self):
priv = RSA.load_key(self.privkey)
# pkcs1_padding, pkcs1_oaep_padding
for padding in self.e_padding_ok:
p = getattr(RSA, padding)
ctxt = priv.public_encrypt(self.data, p)
ptxt = priv.private_decrypt(ctxt, p)
self.assertEqual(ptxt, self.data)

# sslv23_padding
ctxt = priv.public_encrypt(self.data, RSA.sslv23_padding)
>   res = priv.private_decrypt(ctxt, RSA.sslv23_padding)

tests/test_rsa.py:129:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
data =
b'wf\xdc\xa5\xdf\xca\x95\xc7;\xa4\xdfEWUm/\xa1m\xd8\xa1\x14s&\x1bid\xf4c\\\xbcI\x90[<\x8dE\x89\x1f\xbf\xe9y=\xef\xa9z\...2\xb7\xaaO\x89\x88\xf7P\xee\x9f\xaf\x19B?\x1f\n\xe5\x18Q9\x186\x97gj\x0e)0mg@\xed\xe4~\xf3\xc4\xbe\x1dK#\x9f/\r"N%\x8d'
padding = 2

def private_decrypt(self, data, padding):
# type: (bytes, int) -> bytes
assert self.check_key(), 'key is not initialised'
>   return m2.rsa_private_decrypt(self.rsa, data, padding)
E   M2Crypto.RSA.RSAError: sslv3 rollback attack

/usr/lib/python3/dist-packages/M2Crypto/RSA.py:82: RSAError



OpenPGP_signature
Description: OpenPGP digital signature


Processed: m2crypto: autopkgtest needs update for new version of openssl: M2Crypto.RSA.RSAError: sslv3 rollback attack

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> affects -1 src:openssl
Bug #983013 [src:m2crypto] m2crypto: autopkgtest needs update for new version 
of openssl: M2Crypto.RSA.RSAError: sslv3 rollback attack
Added indication that 983013 affects src:openssl

-- 
983013: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983013
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#983010: mdocml breaks debiman autopkgtest: different output

2021-02-17 Thread Paul Gevers
Source: mdocml, debiman
Control: found -1 mdocml/1.14.5-1
Control: found -1 debiman/0.0~git20200217.fc82521-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of mdocml the autopkgtest of debiman fails in
testing when that autopkgtest is run with the binary packages of mdocml
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
mdocml from testing1.14.5-1
debimanfrom testing0.0~git20200217.fc82521-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. Normally I
would assign this bug to debiman as it captures the output of a
different program (so it seems to me) in the test. However, we're in the
freeze and this is a new upstream release (which we request to be
reluctant with), so please *align* quickly how to best move forward.

Currently this regression is blocking the migration of mdocml to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=mdocml

https://ci.debian.net/data/autopkgtest/testing/amd64/d/debiman/10541019/log.gz

=== CONT  TestToHTML/i3lock
2021/02/18 04:13:33 mandocd not found, falling back to fork+exec for
each manpage
=== CONT  TestToHTML/refs
2021/02/18 04:13:33 mandocd not found, falling back to fork+exec for
each manpage
=== CONT  TestToHTML/i3lock
convert_test.go:92: unexpected conversion result: (diff from want →
got):
--- /tmp/debiman-849248825  2021-02-18 04:13:33.034473409 +
+++ /tmp/debiman-376692162  2021-02-18 04:13:33.034473409 +
@@ -7,67 +7,76 @@
   
 
 
-
-
+
+
+
 NAME¶
 i3lock - improved screen locker
-
+
+
+
 SYNOPSIS¶
 i3lock [-v] [-c color]
-
+
+
+
 DESCRIPTION¶
 i3lock is a simple screen locker like slock. After
starting it, you will
   see a white screen (you can configure the color/an image).
You can return to
   your screen by entering your password.
-
+
+
+
 IMPROVEMENTS¶
 
   •
   i3lock forks, so you can combine it with an alias to
suspend to RAM (run
   i3lock  echo mem 
/sys/power/state to get a
   locked screen after waking up your computer from suspend
to RAM)
-
-
   •
   You can specify either a background color or a PNG image
which will be
   displayed while your screen is locked.
-
-
   •
   You can specify whether i3lock should bell upon a wrong
password.
-
-
   •
   i3lock uses PAM and therefore is compatible with LDAP, etc.
-
-
+
+
   
 
+
+
 OPTIONS¶
 
   -v, --version
   Display the version of your i3lock
-
+
   
-
-
   -c rrggbb,
--color=rrggbb
   Turn the screen into the given color instead of white.
Color must be given
   in 3-byte format: rrggbb (i.e. ff is red).
-
+
   
 
+
+
 DPMS¶
 The -d (--dpms) option.
-
+
   verbatim
 
-
+
+
+
 SEE ALSO¶
 xautolock(1) - use i3lock as your screen saver
-
+
+
+
 AUTHOR¶
-Michael Stapelberg michael+i3lock@example.invalid
+Michael Stapelberg michael+i3lock@example.invalid
+
+
 
   
 JANUARY 2012

=== CONT  TestToHTML/refs
convert_test.go:92: unexpected conversion result: (diff from want →
got):
--- /tmp/debiman-144560851  2021-02-18 04:13:33.034473409 +
+++ /tmp/debiman-918139460  2021-02-18 04:13:33.034473409 +
@@ -7,22 +7,26 @@
   
 
 
+
 NAME¶
 refs - test file
-
+
+
+
 SEE ALSO¶
 http://w3m.sourceforge.net;>project website
-
-More details can be found in the i3lock(1) or refs(1) man pages.
-
-References to i3-msg(1)
might cause trouble when matching on word boundaries.
-
-References 

Processed: mdocml breaks debiman autopkgtest: different output

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> found -1 mdocml/1.14.5-1
Bug #983010 [src:mdocml, src:debiman] mdocml breaks debiman autopkgtest: 
different output
Marked as found in versions mdocml/1.14.5-1.
> found -1 debiman/0.0~git20200217.fc82521-1
Bug #983010 [src:mdocml, src:debiman] mdocml breaks debiman autopkgtest: 
different output
Marked as found in versions debiman/0.0~git20200217.fc82521-1.

-- 
983010: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983010
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#983008: silver-platter: autopkgtest regression: cannot import name 'debcommit' from 'breezy.plugins.debian.changelog'

2021-02-17 Thread Paul Gevers
Source: silver-platter
Version: 0.4.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of silver-platter the autopkgtest of silver-platter
fails in testing when that autopkgtest is run with the binary packages
of silver-platter from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
silver-platter from testing0.4.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=silver-platter

https://ci.debian.net/data/autopkgtest/testing/amd64/s/silver-platter/10539975/log.gz

==
ERROR: test_debian_upstream (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_debian_upstream
Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/loader.py", line 154, in
loadTestsFromName
module = __import__(module_name)
  File
"/tmp/autopkgtest-lxc.k6jl00if/downtmp/build.OAF/src/silver_platter/tests/test_debian_upstream.py",
line 21, in 
from ..debian.upstream import (
  File
"/tmp/autopkgtest-lxc.k6jl00if/downtmp/build.OAF/src/silver_platter/debian/upstream.py",
line 73, in 
from breezy.plugins.debian.changelog import debcommit
ImportError: cannot import name 'debcommit' from
'breezy.plugins.debian.changelog'
(/usr/lib/python3/dist-packages/breezy/plugins/debian/changelog.py)



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983007: tqdm breaks backblaze-b2 autopkgtest: The wheel package is not available.

2021-02-17 Thread Paul Gevers
Source: tqdm, backblaze-b2
Control: found -1 tqdm/4.56.2-1
Control: found -1 backblaze-b2/1.3.8-4
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of tqdm the autopkgtest of backblaze-b2 fails in
testing when that autopkgtest is run with the binary packages of tqdm
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
tqdm   from testing4.56.2-1
backblaze-b2   from testing1.3.8-4
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of tqdm to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=tqdm

https://ci.debian.net/data/autopkgtest/testing/amd64/b/backblaze-b2/10523984/log.gz

[*] testing on python3.9:
running nosetests
running egg_info
creating b2.egg-info
writing b2.egg-info/PKG-INFO
writing dependency_links to b2.egg-info/dependency_links.txt
writing entry points to b2.egg-info/entry_points.txt
writing requirements to b2.egg-info/requires.txt
writing top-level names to b2.egg-info/top_level.txt
writing manifest file 'b2.egg-info/SOURCES.txt'
reading manifest file 'b2.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'b2.egg-info/SOURCES.txt'
WARNING: The wheel package is not available.
/usr/bin/python3.9: No module named pip
error: Command '['/usr/bin/python3.9', '-m', 'pip',
'--disable-pip-version-check', 'wheel', '--no-deps', '-w',
'/tmp/tmp7u77k0jh', '--quiet', 'tqdm>=4.5.0']' returned non-zero exit
status 1.



OpenPGP_signature
Description: OpenPGP digital signature


Processed: tqdm breaks backblaze-b2 autopkgtest: The wheel package is not available.

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> found -1 tqdm/4.56.2-1
Bug #983007 [src:tqdm, src:backblaze-b2] tqdm breaks backblaze-b2 autopkgtest: 
The wheel package is not available.
Marked as found in versions tqdm/4.56.2-1.
> found -1 backblaze-b2/1.3.8-4
Bug #983007 [src:tqdm, src:backblaze-b2] tqdm breaks backblaze-b2 autopkgtest: 
The wheel package is not available.
Marked as found in versions backblaze-b2/1.3.8-4.

-- 
983007: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983007
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary

2021-02-17 Thread Paul Gevers
Hi Mario,

LOn Mon, 16 Nov 2020 16:01:34 + "Limonciello, Mario"
 wrote:
> As @Steve McIntyre mentions, it's a manual process to kick off the re-signing.
> It needs to be done when 1.5.1-2 is ready to migrate.

There's users of unstable too. In my opinion, if you can't relax the
constraints, you'll have to kick it off as soon as it's needed in
unstable, not when it's ready to migrate.

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983004: bind9: CVE-2020-8625

2021-02-17 Thread Salvatore Bonaccorso
Source: bind9
Version: 1:9.16.11-2
Severity: grave
Tags: security upstream fixed-upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:9.11.5.P4+dfsg-5.1+deb10u2
Control: found -1 1:9.11.5.P4+dfsg-5.1
Control: fixed -1 1:9.11.5.P4+dfsg-5.1+deb10u3

Hi,

The following vulnerability was published for bind9.

CVE-2020-8625[0]:
| BIND servers are vulnerable if they are running an affected version
| and are configured to use GSS-TSIG features. In a configuration which
| uses BIND's default settings the vulnerable code path is not exposed,
| but a server can be rendered vulnerable by explicitly setting valid
| values for the tkey-gssapi-keytab or tkey-gssapi-
| credentialconfiguration options. Although the default configuration is
| not vulnerable, GSS-TSIG is frequently used in networks where BIND is
| integrated with Samba, as well as in mixed-server environments that
| combine BIND servers with Active Directory domain controllers. The
| most likely outcome of a successful exploitation of the vulnerability
| is a crash of the named process. However, remote code execution, while
| unproven, is theoretically possible. Affects: BIND 9.5.0 -
| 9.11.27, 9.12.0 - 9.16.11, and versions BIND 9.11.3-S1 -
| 9.11.27-S1 and 9.16.8-S1 - 9.16.11-S1 of BIND Supported Preview
| Edition. Also release versions 9.17.0 - 9.17.1 of the BIND 9.17
| development branch


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-8625
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8625
[1] https://kb.isc.org/v1/docs/cve-2020-8625
[2] 
https://gitlab.isc.org/isc-projects/bind9/commit/b04cb88462863d762093760ffcfe1946200e30f5

Regards,
Salvatore



Processed: bind9: CVE-2020-8625

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> found -1 1:9.11.5.P4+dfsg-5.1+deb10u2
Bug #983004 [src:bind9] bind9: CVE-2020-8625
Marked as found in versions bind9/1:9.11.5.P4+dfsg-5.1+deb10u2.
> found -1 1:9.11.5.P4+dfsg-5.1
Bug #983004 [src:bind9] bind9: CVE-2020-8625
Marked as found in versions bind9/1:9.11.5.P4+dfsg-5.1.
> fixed -1 1:9.11.5.P4+dfsg-5.1+deb10u3
Bug #983004 [src:bind9] bind9: CVE-2020-8625
The source 'bind9' and version '1:9.11.5.P4+dfsg-5.1+deb10u3' do not appear to 
match any binary packages
Marked as fixed in versions bind9/1:9.11.5.P4+dfsg-5.1+deb10u3.

-- 
983004: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983004
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#982519: zstd: Race condition allows attacker to access world-readable destination file

2021-02-17 Thread Salvatore Bonaccorso
On Thu, Feb 11, 2021 at 08:33:58AM +0100, Sebastien Delafond wrote:
> Package: zstd
> Version: 1.4.8+dfsg-1
> Severity: grave
> Tags: security
> X-Debbugs-Cc: t...@security.debian.org
> 
> The recently applied patch still creates the file with the default
> umask[0], before chmod'ing down to 0600, so an attacker could still open
> it in the meantime.

FTR, this has been fixed upstream.

https://github.com/facebook/zstd/commit/a774c5797399040af62db21d8a9b9769e005430e

Regards,
Salvatore



Processed: fixed 982992 in 4.7.1-2

2021-02-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> fixed 982992 4.7.1-2
Bug #982992 [src:node-regjsparser, src:node-regexpu-core] node-regjsparser 
breaks node-regexpu-core autopkgtest: Missing expected exception (Error).
The source 'node-regjsparser' and version '4.7.1-2' do not appear to match any 
binary packages
Marked as fixed in versions node-regjsparser/4.7.1-2 and 
node-regexpu-core/4.7.1-2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
982992: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982992
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#982684: marked as done (subversion: frequent FTBFS due to flaky test)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Thu, 18 Feb 2021 03:18:29 +
with message-id 
and subject line Bug#982684: fixed in subversion 1.14.1-3
has caused the Debian Bug report #982684,
regarding subversion: frequent FTBFS due to flaky test
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982684: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982684
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
package: src:subversion
version: 1.14.1-1
severity: serious
tags: ftbfs

Hi,

The latest upload of subversion to unstable fails on armhf and mips64el:

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

On the first try, it failed on mipsel as well. Maybe the failing test is
unreliable?


Cheers,

Ivo
--- End Message ---
--- Begin Message ---
Source: subversion
Source-Version: 1.14.1-3
Done: James McCoy 

We believe that the bug you reported is fixed in the latest version of
subversion, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 982...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
James McCoy  (supplier of updated subversion package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 17 Feb 2021 21:52:03 -0500
Source: subversion
Architecture: source
Version: 1.14.1-3
Distribution: unstable
Urgency: medium
Maintainer: James McCoy 
Changed-By: James McCoy 
Closes: 982684
Changes:
 subversion (1.14.1-3) unstable; urgency=medium
 .
   * Correctly disable testCrash_RequestChannel_nativeRead_AfterException
 (Closes: #982684)
Checksums-Sha1:
 fddcc0776ffd7867170a58f848efb4d012a41d6e 3807 subversion_1.14.1-3.dsc
 736b1831ff0a0c3f9c5e2a48e4d2abe03cf52c2e 430084 
subversion_1.14.1-3.debian.tar.xz
Checksums-Sha256:
 caf86f3c500a4ffce464fd93aa68ae5ddf2373dda10a5d1a3d2cafe857520bd3 3807 
subversion_1.14.1-3.dsc
 a309677ab7ca24948e033dcac6c327561ab3cf933547cdeea1d2114b8acbfd5d 430084 
subversion_1.14.1-3.debian.tar.xz
Files:
 a247ba3192d05cdc5b69b791b0edaf39 3807 vcs optional subversion_1.14.1-3.dsc
 3f333ca6e1cea1cfe2d37e9deeaf2e39 430084 vcs optional 
subversion_1.14.1-3.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQKoBAEBCgCSFiEEkb+/TWlWvV33ty0j3+aRrjMbo9sFAmAt1ytfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDkx
QkZCRjRENjk1NkJENURGN0I3MkQyM0RGRTY5MUFFMzMxQkEzREIUHGphbWVzc2Fu
QGRlYmlhbi5vcmcACgkQ3+aRrjMbo9vgIA//ReqTObGArp6ck6GE0gxXhGB5VQRk
KAC1W2P0nDINEmt5fWppP42jOxXCmdE+cfSnmZljUCfxRAm6CzN9QKJhMU1fAF+s
LLRTS4NswDZBfrgtQspoko/ZqUlvLxGGBSw3SYoLfWpBFFF0eqYTETFDs09QGBDL
rfRv223enrgbX9hE4K5Jdhlcv3rJtivNw8JGKuLe+eG1BDbXT9OxkG15f5bgpKU8
5uQ/VgnhHc/RpWIhjR/v7zrX3+EekcQXMIoGGL3+sz4pV5ycuX+v+Q8+EZ7/iq/H
AQ6sm8oYJCj37uMcJrz3wp2vIPayqPApQdQlCNI191HFMR4Q2dBNs3f6k4ScXVcE
grZwOLrAM8gqkKjU1L20bfx+90JXu4rOszs+Tx+ttcyA4rG60ZaAIR0l46SezGK+
qZFeFZasMAKlA2hq93xTcXWATu45BXmHC4tqDJCTM9jQeDG3vlivAED0D60xeRW9
MqQc7vVrv4WKm/LkjsV2uxCyoW+jXdkUVuu8000NN4a1stfdfu78oJLjyqBC45a+
DGXLbFExc6DtXU3Hy1wEmVm98N1CSswFig5ORSk4LwZWWil6RFQQ98n+ceVfVbKt
nEBnpO68ePCqI+o0SxFzEW4wBlT7kubu8VQdEid+jzDTZaaJwW8y6bNzThTRVR6x
00xQQpAC6y9Imic=
=lQPd
-END PGP SIGNATURE End Message ---


Bug#981009: Charybdis abandoned upstream, do not ship in bullseye

2021-02-17 Thread Sadie Powell
Charybdis' development was terminated due to (among other reasons) threats by a 
former maintainer. It probably won't be revived.

It's successor is probably Solanum (https://github.com/solanum-ircd/solanum) 
which is a fork that is led by freenode and OFTC people some of whom were 
contributors to Charybdis. It might be a good idea to package that instead when 
it gets a release?

~ Sadie



Processed: found 982684 in 1.14.1-2

2021-02-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> # @Ignore did not work as expected
> found 982684 1.14.1-2
Bug #982684 {Done: James McCoy } [src:subversion] 
subversion: frequent FTBFS due to flaky test
Marked as found in versions subversion/1.14.1-2; no longer marked as fixed in 
versions subversion/1.14.1-2 and reopened.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
982684: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982684
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#982994: marked as done (lintian-brush breaks silver-platter autopkgtest: cannot import name 'guess_upstream_metadata' from 'lintian_brush.upstream_metadata')

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 23:03:30 +
with message-id 
and subject line Bug#982994: fixed in silver-platter 0.4.1-1
has caused the Debian Bug report #982994,
regarding lintian-brush breaks silver-platter autopkgtest: cannot import name 
'guess_upstream_metadata' from 'lintian_brush.upstream_metadata'
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982994: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982994
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: lintian-brush, silver-platter
Control: found -1 lintian-brush/0.96
Control: found -1 silver-platter/0.4.0-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of lintian-brush the autopkgtest of silver-platter
fails in testing when that autopkgtest is run with the binary packages
of lintian-brush from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
lintian-brush  from testing0.96
silver-platter from testing0.4.0-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of lintian-brush to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
lintian-brush/0.96. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=lintian-brush

https://ci.debian.net/data/autopkgtest/testing/amd64/s/silver-platter/10520217/log.gz

autopkgtest [05:11:28]: test testsuite: [---
failed to open trace file: [Errno 13] Permission denied:
'/you-should-use-TestCaseInTempDir-if-you-need-a-log-file'
.xE.../usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_changes/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_indep/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_indep/work/proposal/.git/objects/pack/pack-a5b46f750283ac9120774bd37f5f4690fd133ff5.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_no_new_commits/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_no_op_commits/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
.
==
ERROR: 

Bug#982321: marked as done (libcdparanoia-dev: overly generic header name: /usr/include/utils.h)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 21:48:25 +
with message-id 
and subject line Bug#982321: fixed in cdparanoia 3.10.2+debian-13.1
has caused the Debian Bug report #982321,
regarding libcdparanoia-dev: overly generic header name: /usr/include/utils.h
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982321: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982321
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libcdparanoia-dev
Version: 3.10.2+debian-13
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package uses a very generic
header file name that now clashes with other packages:

/usr/include/utils.h


Andreas
--- End Message ---
--- Begin Message ---
Source: cdparanoia
Source-Version: 3.10.2+debian-13.1
Done: Sebastian Ramacher 

We believe that the bug you reported is fixed in the latest version of
cdparanoia, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 982...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sebastian Ramacher  (supplier of updated cdparanoia 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 15 Feb 2021 22:37:56 +0100
Source: cdparanoia
Architecture: source
Version: 3.10.2+debian-13.1
Distribution: unstable
Urgency: medium
Maintainer: Optical Media Tools Team 

Changed-By: Sebastian Ramacher 
Closes: 982321
Changes:
 cdparanoia (3.10.2+debian-13.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * debian/libcdparanoia-dev.install: Do not install unused utils.h (Closes:
 #982321)
Checksums-Sha1:
 cf48c72417af7fb8b7b44a9b99e6e385c70fde2a 2203 cdparanoia_3.10.2+debian-13.1.dsc
 6326f2425c2f0adbf51f2e0d5750b11d1720206f 61252 
cdparanoia_3.10.2+debian-13.1.debian.tar.xz
Checksums-Sha256:
 827e412ded15914f618b297115ff9d3473336825693fb951ec44f60c71b395e7 2203 
cdparanoia_3.10.2+debian-13.1.dsc
 c22b3094be6c026eef64091fdd3b33b0d8530fcb2d9fd445a0cadf7624b51a0b 61252 
cdparanoia_3.10.2+debian-13.1.debian.tar.xz
Files:
 44425f6900115590a5b33649ede53dc9 2203 sound optional 
cdparanoia_3.10.2+debian-13.1.dsc
 494963e39104793822d2128b54563e2b 61252 sound optional 
cdparanoia_3.10.2+debian-13.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE94y6B4F7sUmhHTOQafL8UW6nGZMFAmAq6f8ACgkQafL8UW6n
GZPq2g//d5uNTGioaQcIhOrwRu67Am6H9twcncdXO6IZ5Q37hRCNLEbehqasTKBD
r9M25m/hB+6m/Csnq26+QAGW9vaEH2+pjG0MlO34sKHgrEYUkqTrSXmXUyXBwg+2
gW1CHODMV0v0rBL3AGElAvWfTedh00xU4ycWgYiyQvxwEiwEVrUpLmhJiglpE8gA
Ket0+BlXTuKrfvAjUxo4KlAh1wF5jv89XSnvBh7DnX6ReQ/5BgfC+ry6ERjGW724
2C9IWIvPVjyw01bxtWCDn7shtgfM4gxufiEy5MvbkbH67T+0eL05C3hOfr4+oO+i
bADOi4BMJY5PXB0R8xu4Jei0/iwN2RjFtT43vln+9ZCjhCGRCKw2Z371fL6TcmZU
MGjcTm0XEH1IaAVsqoPJqyVIbHHxNKu0V5H30b0fjH1unlTvSKPfc7CNEvgcSw4y
SjHKJ0HxKmPHbd08n0I5djKTQ+VLY15pZ4YlOiLZbI9svGtQYgRUqHzTSCgGFPOe
ZNJ9p8jMHbLEGyUDfbWQ1ZnS8dzvgSUGzEJInUAU0SJz737iE2OVuGiBC0BhoPmQ
+wwD4Y/Sfl8jQfQbE6hdpYhy4F0kWC/rSTKM45jHELXPTzXrRNQyHLvWOfiRU1Q8
Kib/RV4gYuRRxXt7jV37oDvbGPoCxYoQIyrNW3QEe9EaNcB4v2A=
=xiKv
-END PGP SIGNATURE End Message ---


Bug#982994: lintian-brush breaks silver-platter autopkgtest: cannot import name 'guess_upstream_metadata' from 'lintian_brush.upstream_metadata'

2021-02-17 Thread Paul Gevers
Source: lintian-brush, silver-platter
Control: found -1 lintian-brush/0.96
Control: found -1 silver-platter/0.4.0-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of lintian-brush the autopkgtest of silver-platter
fails in testing when that autopkgtest is run with the binary packages
of lintian-brush from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
lintian-brush  from testing0.96
silver-platter from testing0.4.0-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of lintian-brush to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
lintian-brush/0.96. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=lintian-brush

https://ci.debian.net/data/autopkgtest/testing/amd64/s/silver-platter/10520217/log.gz

autopkgtest [05:11:28]: test testsuite: [---
failed to open trace file: [Errno 13] Permission denied:
'/you-should-use-TestCaseInTempDir-if-you-need-a-log-file'
.xE.../usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_changes/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_indep/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_indep/work/proposal/.git/objects/pack/pack-a5b46f750283ac9120774bd37f5f4690fd133ff5.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_no_new_commits/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_no_op_commits/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
.
==
ERROR: test_debian_upstream (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_debian_upstream
Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/loader.py", line 154, in
loadTestsFromName
module = __import__(module_name)
  File
"/tmp/autopkgtest-lxc.1xg43ak_/downtmp/build.7XC/src/silver_platter/tests/test_debian_upstream.py",
line 21, in 
from ..debian.upstream import (
  File
"/tmp/autopkgtest-lxc.1xg43ak_/downtmp/build.7XC/src/silver_platter/debian/upstream.py",
line 129, in 
from lintian_brush.upstream_metadata import (
ImportError: cannot import name 'guess_upstream_metadata' from
'lintian_brush.upstream_metadata'
(/usr/lib/python3/dist-packages/lintian_brush/upstream_metadata.py)


--
Ran 43 tests in 3.141s

FAILED 

Processed: lintian-brush breaks silver-platter autopkgtest: cannot import name 'guess_upstream_metadata' from 'lintian_brush.upstream_metadata'

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> found -1 lintian-brush/0.96
Bug #982994 [src:lintian-brush, src:silver-platter] lintian-brush breaks 
silver-platter autopkgtest: cannot import name 'guess_upstream_metadata' from 
'lintian_brush.upstream_metadata'
Marked as found in versions lintian-brush/0.96.
> found -1 silver-platter/0.4.0-1
Bug #982994 [src:lintian-brush, src:silver-platter] lintian-brush breaks 
silver-platter autopkgtest: cannot import name 'guess_upstream_metadata' from 
'lintian_brush.upstream_metadata'
Marked as found in versions silver-platter/0.4.0-1.

-- 
982994: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982994
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: python-aiohttp breaks python-molotov autopkgtest: result changed

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> found -1 python-aiohttp/3.7.3-1
Bug #982993 [src:python-aiohttp, src:python-molotov] python-aiohttp breaks 
python-molotov autopkgtest: result changed
Marked as found in versions python-aiohttp/3.7.3-1.
> found -1 python-molotov/2.1-1
Bug #982993 [src:python-aiohttp, src:python-molotov] python-aiohttp breaks 
python-molotov autopkgtest: result changed
Marked as found in versions python-molotov/2.1-1.

-- 
982993: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982993
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#982993: python-aiohttp breaks python-molotov autopkgtest: result changed

2021-02-17 Thread Paul Gevers
Source: python-aiohttp, python-molotov
Control: found -1 python-aiohttp/3.7.3-1
Control: found -1 python-molotov/2.1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of python-aiohttp the autopkgtest of python-molotov
fails in testing when that autopkgtest is run with the binary packages
of python-aiohttp from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
python-aiohttp from testing3.7.3-1
python-molotov from testing2.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python-aiohttp to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-aiohttp

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-molotov/10531551/log.gz

=== FAILURES
===
 TestRunner.test_delay
_

self = 

@dedicatedloop
def test_delay(self):
with catch_sleep() as delay:

@scenario(weight=10, delay=0.1)
async def here_three(session):
_RES.append(3)

stdout, stderr, rc = self._test_molotov(
"--delay",
".6",
"--console-update",
"0",
"-cx",
"--max-runs",
"2",
"-s",
"here_three",
"molotov.tests.test_run",
)
wanted = "SUCCESSES: 2"
self.assertTrue(wanted in stdout, stdout)
>   self.assertEqual(delay, [1, 0.1, 1, 0.6, 1, 0.1, 1, 0.6, 1])
E   AssertionError: Lists differ: [1, 0.1, 1, 0.6, 1, 0.1, 1,
0.6, 1, 1] != [1, 0.1, 1, 0.6, 1, 0.1, 1, 0.6, 1]
E
E   First list contains 1 additional elements.
E   First extra element 9:
E   1
E
E   - [1, 0.1, 1, 0.6, 1, 0.1, 1, 0.6, 1, 1]
E   ?  ---
E
E   + [1, 0.1, 1, 0.6, 1, 0.1, 1, 0.6, 1]



OpenPGP_signature
Description: OpenPGP digital signature


Bug#982992: node-regjsparser breaks node-regexpu-core autopkgtest: Missing expected exception (Error).

2021-02-17 Thread Paul Gevers
Source: node-regjsparser, node-regexpu-core
Control: found -1 node-regjsparser/0.6.6+ds-1
Control: found -1 node-regexpu-core/4.7.1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of node-regjsparser the autopkgtest of
node-regexpu-core fails in testing when that autopkgtest is run with the
binary packages of node-regjsparser from unstable. It passes when run
with only packages from testing. In tabular form:

   passfail
node-regjsparser   from testing0.6.6+ds-1
node-regexpu-core  from testing4.7.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of node-regjsparser
to testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=node-regjsparser

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-regexpu-core/10530585/log.gz

  718 passing (816ms)
  1 failing

  1) unicodePropertyEscapes
   throws without the `u` flag:
 AssertionError [ERR_ASSERTION]: Missing expected exception (Error).
  at Context. (tests/tests.js:592:10)
  at callFn (/usr/share/nodejs/mocha/lib/runnable.js:364:21)
  at Test.Runnable.run (/usr/share/nodejs/mocha/lib/runnable.js:352:5)
  at Runner.runTest (/usr/share/nodejs/mocha/lib/runner.js:677:10)
  at /usr/share/nodejs/mocha/lib/runner.js:801:12
  at next (/usr/share/nodejs/mocha/lib/runner.js:594:14)
  at /usr/share/nodejs/mocha/lib/runner.js:604:7
  at next (/usr/share/nodejs/mocha/lib/runner.js:486:14)
  at Immediate._onImmediate
(/usr/share/nodejs/mocha/lib/runner.js:572:5)
  at processImmediate (internal/timers.js:461:21)



OpenPGP_signature
Description: OpenPGP digital signature


Processed: node-regjsparser breaks node-regexpu-core autopkgtest: Missing expected exception (Error).

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> found -1 node-regjsparser/0.6.6+ds-1
Bug #982992 [src:node-regjsparser, src:node-regexpu-core] node-regjsparser 
breaks node-regexpu-core autopkgtest: Missing expected exception (Error).
Marked as found in versions node-regjsparser/0.6.6+ds-1.
> found -1 node-regexpu-core/4.7.1-1
Bug #982992 [src:node-regjsparser, src:node-regexpu-core] node-regjsparser 
breaks node-regexpu-core autopkgtest: Missing expected exception (Error).
Marked as found in versions node-regexpu-core/4.7.1-1.

-- 
982992: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982992
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#971806: marked as done (python-hdf5storage's autopkg tests fail in unstable)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 21:03:22 +
with message-id 
and subject line Bug#971806: fixed in python-hdf5storage 
0.1.15+git20200608.09dfc5f-2
has caused the Debian Bug report #971806,
regarding python-hdf5storage's autopkg tests fail in unstable
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
971806: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971806
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:python-hdf5storage
Version: 0.1.15+git20200608.09dfc5f-1
Severity: serious
Tags: sid bullseye

seen, when triggered by the setuptools upload, only used as a build time tool by
python-hdf5storage.

blocking the setuptools migration to testing.

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-hdf5storage/7325816/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/p/python-hdf5storage/7326442/log.gz

==
ERROR:
test_write_readback.TestMatlabFormat.test_dtype_structured_with_offsets_titles
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File
"/tmp/autopkgtest-lxc.bkohktuu/downtmp/autopkgtest_tmp/tests/test_write_readback.py",
line 862, in test_dtype_structured_with_offsets_titles
np.dtype(desc).itemsize + random.randint(1, 100)
ValueError: name already used as a name or title

--
Ran 1513 tests in 28.846s

FAILED (SKIP=4, errors=1)
--- End Message ---
--- Begin Message ---
Source: python-hdf5storage
Source-Version: 0.1.15+git20200608.09dfc5f-2
Done: Drew Parsons 

We believe that the bug you reported is fixed in the latest version of
python-hdf5storage, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 971...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Drew Parsons  (supplier of updated python-hdf5storage 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 17 Feb 2021 21:33:33 +0100
Source: python-hdf5storage
Architecture: source
Version: 0.1.15+git20200608.09dfc5f-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Drew Parsons 
Closes: 971806
Changes:
 python-hdf5storage (0.1.15+git20200608.09dfc5f-2) unstable; urgency=medium
 .
   * Team upload.
   * debian patch fix_dtype_random_title_1444936.patch applies
 upstream commit #1444936 to fix random dtype titles used in tests.
 Closes: #971806.
   * Standards-Version: 4.5.1
Checksums-Sha1:
 908fa495cf9cac22ef7b763dc23d766e1a7bf52c 2580 
python-hdf5storage_0.1.15+git20200608.09dfc5f-2.dsc
 1f8fd9c39dc38a71bc2de7be7deae2fac8abf41f 4684 
python-hdf5storage_0.1.15+git20200608.09dfc5f-2.debian.tar.xz
Checksums-Sha256:
 b1c4443600bcbc2e98ff6a99e51c50eb73be9f3c1550750944b6d468670afdf6 2580 
python-hdf5storage_0.1.15+git20200608.09dfc5f-2.dsc
 5cc20c8a8e9075e6b1aa291dbe73dbc6c2a192b94191cce636614e101c5ef487 4684 
python-hdf5storage_0.1.15+git20200608.09dfc5f-2.debian.tar.xz
Files:
 74cec158efd1a5621e7969cdea049a66 2580 python optional 
python-hdf5storage_0.1.15+git20200608.09dfc5f-2.dsc
 f329822491fb3b310b93c2c38155ee84 4684 python optional 
python-hdf5storage_0.1.15+git20200608.09dfc5f-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEI8mpPlhYGekSbQo2Vz7x5L1aAfoFAmAtf/EACgkQVz7x5L1a
AfpfrA/9HpJYt4mqwG2bX7uI0BdgbrJfKo7lCtyTI2qi2e8Oz92ahMtss4uJugJf
XECtuQA2qzWQ4XYWeOBm2qyN/w+8CBNkQWXEjao7Qp9VKItKcpwUiqcMcbnPfxlG
pJaCiowSTVfH5X3iy0VmhyZ393u3EbPcvcqMRrziLcoiLHR+kcLKR2nORzR3A0Vu
962NTvoFKXvBVK4rCYQeWTkBW1K3uQmXK/l6WEsP2+zCoXPl61jmy5KDuYGG+ZCQ
V51d2t4LbGQBHORuUO3Zn4WhYULKPpX9H6rmL/ISzEH/dqb0S0XAM/YFCz7EcoiZ
p6391AKIgJXBTrtbkfypP4OaChUHEqcN8S/mLdCd+SV+LdFRsc4Jn98RPCySMdIt
4kljCswI9TSFz60sej155Tz+9ctVNO9keuO3/l1CyN7t3BpJN7dNuRKyWHQRB0L0
oVM083+6cWN8chBVSuQd1O7dpJH+q8vrNq2wwp242+vJOSd+bi6bJPCQGfTLiDO+
G8IFclVlXM9sWv1/8T8icsbcrR3kuZ83w8Fu29cPOefPLtakkVAUysjCVD6AxZZ+
DhuzfE+JFF+oEi1+/wMGOIfPy16AWsqdgHIzguGo4T1sZqjjp758CANxYbX1+BlP

Bug#977990: os-autoinst: FTBFS on i386: 3/3 Test #3: test-perl-testsuite ..............***Failed 332.81 sec

2021-02-17 Thread Paul Gevers
Hi Frédéric,

On 15-02-2021 10:39, Frédéric Bonnard wrote:
> indeed Paul, the test is flaky, probably a timing issue. I had already
> changed some related parameter that made the tests pass reliably on
> my i386 builder, but saw afterward that it still failed on debian's
> builder and couldn't reproduce it :
> https://salsa.debian.org/debian/os-autoinst/-/commit/38b2f4aefafbdf7ab59ce223ef208c540409a001
> I guess, we could increase CI related timeouts here and there but that's
> what I tried to avoid when changing CI variable, and I was happy to see
> things work.. but not on all i386 builders :)
> May we close that bug for now ?
If the forth time worked because of sheer luck, then please no, keep the
bug open until the build is less flaky. We need packages to be build
without failure [1]. Having to baby-sit flaky is not really an option as
there are too many packages in the Debian archive.

Also, your commit message suggests that the upstream change that's
needed isn't in Debian yet?

Paul

[1] https://release.debian.org/bullseye/rc_policy.txt 4



OpenPGP_signature
Description: OpenPGP digital signature


Processed: severity of 982924 is wishlist, tagging 982924

2021-02-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> severity 982924 wishlist
Bug #982924 [src:what-is-python] what-is-python: The python-is-python3 and 
python-dev-is-python3 packages should not exist
Severity set to 'wishlist' from 'critical'
> tags 982924 + wontfix
Bug #982924 [src:what-is-python] what-is-python: The python-is-python3 and 
python-dev-is-python3 packages should not exist
Added tag(s) wontfix.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
982924: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982924
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#982924: what-is-python: The python-is-python3 and python-dev-is-python3 packages should not exist

2021-02-17 Thread Dimitri John Ledkov
In Bullseye release file:/usr/bin/python is not reserved, but
intentionally unused.
In Bullseye release neither deb:python2 nor deb:python3 packages own
/usr/bin/python.
This is a Bullseye Release Goal with consensus from all
cpythons/pypys/etc interpreter maintainers, modules maintainers, and
app maintainers.
Specifically cpython2.7 is still around to allow for re-bootstrapping
of pypy* ecosystem on existing or new architectures.
No packages in Bullseye may depend, or build-depend on neither
deb:python, nor deb:python-is-python* packages.
Thus it is a leaf package without any dependencies. By definition not
impacting any unrelated software.
It is intended for this package, and all of its binaries to be removed
in some future Debian release after the next one.
I hope you notice the irony in the package name src:what-is-python, it
is meant for local admins to deploy as compatibility with their
respective venvs and other estates only.
It is intended for nobody to use "/usr/bin/python" outside of venv for
now. And for them to change their scripts to use either python3 or
python2 explicitly.

I want to say this bug report is "bullseye-ignore" or "wontfix".



Bug#982833: marked as done (man2html,man2html-base,manpages-it: manpage conflicts: man2html.1, hman.1)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 19:03:30 +
with message-id 
and subject line Bug#982833: fixed in manpages-l10n 4.9.1-5
has caused the Debian Bug report #982833,
regarding man2html,man2html-base,manpages-it: manpage conflicts: man2html.1, 
hman.1
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982833: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982833
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: man2html,man2html-base,manpages-it
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: found -1 1.6g-14
Control: found -1 4.9.1-2

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../manpages-it_4.9.1-2_all.deb ...
  Unpacking manpages-it (4.9.1-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/manpages-it_4.9.1-2_all.deb (--unpack):
   trying to overwrite '/usr/share/man/it/man1/hman.1.gz', which is also in 
package man2html 1.6g-14
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/manpages-it_4.9.1-2_all.deb

  Preparing to unpack .../manpages-it_4.9.1-2_all.deb ...
  Unpacking manpages-it (4.9.1-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/manpages-it_4.9.1-2_all.deb (--unpack):
   trying to overwrite '/usr/share/man/it/man1/man2html.1.gz', which is also in 
package man2html-base 1.6g-14
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/manpages-it_4.9.1-2_all.deb


cheers,

Andreas


man2html=1.6g-14_manpages-it=4.9.1-2.log.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: manpages-l10n
Source-Version: 4.9.1-5
Done: Helge Kreutzmann 

We believe that the bug you reported is fixed in the latest version of
manpages-l10n, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 982...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Helge Kreutzmann  (supplier of updated manpages-l10n 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 17 Feb 2021 17:42:23 +0100
Source: manpages-l10n
Architecture: source
Version: 4.9.1-5
Distribution: unstable
Urgency: medium
Maintainer: Dr. Tobias Quathamer 
Changed-By: Helge Kreutzmann 
Closes: 982814 982833
Changes:
 manpages-l10n (4.9.1-5) unstable; urgency=medium
 .
   * Remove man pages conflicting with man2html{-base}. Closes: #982833.
   * Add bug closure to previous changelog entry.
   * Some manpages where move to -it-dev, add correct Breaks and Replaces.
 Closes: #982814.
Checksums-Sha1:
 2065af54d8f7e94f32e26ca9860818e8c77a4304 2773 manpages-l10n_4.9.1-5.dsc
 d1cc1f87388f4f68a6d93a63b5108fb7d3e7d758 46276 
manpages-l10n_4.9.1-5.debian.tar.xz
 a3a4f2598b44c1c8f9e3920a5b5bdce18b0e9a39 9263 
manpages-l10n_4.9.1-5_amd64.buildinfo
Checksums-Sha256:
 4e70a6126d7ccedb63493ae250e1672645a66f488c8166feaad3fbca39e6fcaf 2773 
manpages-l10n_4.9.1-5.dsc
 f228a4e631cedf9fec3ed1e74601b43948b0cdb6e9f9856948bbc7995cd43a2a 46276 
manpages-l10n_4.9.1-5.debian.tar.xz
 74f6c660a25a69bb6f81dcd83101855e7067471c0d5802d76d966a8612ae3079 9263 
manpages-l10n_4.9.1-5_amd64.buildinfo
Files:
 ebbbc788135c2734b660be25479dc72a 2773 doc optional manpages-l10n_4.9.1-5.dsc
 4e201a361c46bf618c7407a91d1b045f 46276 doc optional 
manpages-l10n_4.9.1-5.debian.tar.xz
 80326b5425cb6571f3d1f924e802d910 9263 doc optional 
manpages-l10n_4.9.1-5_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEbZZfteMW0gNUynuwQbqlJmgq5nAFAmAtZUQACgkQQbqlJmgq
5nDKGw/+O68uZX5pFVzozn+NIt/QDoBbnto/b1iDkSEG/FTbapK1xaeEm+8Uzmdt
cCndRQaPqxHfKE7Pj6+BAMKP0jvYa3dj/qBnwzxRxkdleCEdarmt7UMK6mgQFBWR
KoMzGmnKLDgKesaOP9W776+u5OVjWAkdDcXtqhKuQRQF+N+ZnkcDd7f8cd+RxEYX
DYP39YExMjiFUdWs1KWgsL+a5vUm9TktfM94HqfuV/0VhTF7aI55zuLT3N66bU8o
B91mEQKiFrgaAZ+lzFnHx9cvmJJ5DKN3iXQ4VZpXEFZ16ivNt6m0S+XMpuy8xnbR
MK5HEmfeVIElW/ZsgbB9u71pq8lwPGTgIZO+cKV6bNd4P8ZZJOMgM8Hy8JCAS5iF

Bug#982814: marked as done (manpages-it-dev: missing Breaks+Replaces: manpages-it (<< 4.9.1))

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 19:03:30 +
with message-id 
and subject line Bug#982814: fixed in manpages-l10n 4.9.1-5
has caused the Debian Bug report #982814,
regarding manpages-it-dev: missing Breaks+Replaces: manpages-it (<< 4.9.1)
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982814: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982814
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: manpages-it-dev
Version: 4.9.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../manpages-it-dev_4.9.1-2_all.deb ...
  Unpacking manpages-it-dev (4.9.1-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/manpages-it-dev_4.9.1-2_all.deb (--unpack):
   trying to overwrite '/usr/share/man/it/man2/_syscall.2.gz', which is also in 
package manpages-it 3.73-2.1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/manpages-it-dev_4.9.1-2_all.deb

The following manpages were moved to the new -it-dev package:

usr/share/man/it/man2/_syscall.2.gz
usr/share/man/it/man2/adjtimex.2.gz
usr/share/man/it/man2/fork.2.gz
usr/share/man/it/man2/mount.2.gz
usr/share/man/it/man2/readv.2.gz
usr/share/man/it/man2/swapoff.2.gz
usr/share/man/it/man2/swapon.2.gz
usr/share/man/it/man2/symlink.2.gz
usr/share/man/it/man2/symlinkat.2.gz
usr/share/man/it/man2/sync.2.gz
usr/share/man/it/man2/sysfs.2.gz
usr/share/man/it/man2/sysinfo.2.gz
usr/share/man/it/man2/umask.2.gz
usr/share/man/it/man2/umount.2.gz
usr/share/man/it/man2/umount2.2.gz
usr/share/man/it/man2/uname.2.gz
usr/share/man/it/man2/unimplemented.2.gz
usr/share/man/it/man2/unlink.2.gz
usr/share/man/it/man2/unlinkat.2.gz
usr/share/man/it/man2/uselib.2.gz
usr/share/man/it/man2/ustat.2.gz
usr/share/man/it/man2/utime.2.gz
usr/share/man/it/man2/utimes.2.gz
usr/share/man/it/man2/vfork.2.gz
usr/share/man/it/man2/vhangup.2.gz
usr/share/man/it/man2/vm86.2.gz
usr/share/man/it/man2/wait.2.gz
usr/share/man/it/man2/wait3.2.gz
usr/share/man/it/man2/wait4.2.gz
usr/share/man/it/man2/waitpid.2.gz
usr/share/man/it/man2/write.2.gz
usr/share/man/it/man2/writev.2.gz
usr/share/man/it/man3/adjtime.3.gz
usr/share/man/it/man3/daemon.3.gz
usr/share/man/it/man3/err.3.gz
usr/share/man/it/man3/exit.3.gz
usr/share/man/it/man3/undocumented.3.gz


cheers,

Andreas


manpages-it=3.73-2.1_manpages-it-dev=4.9.1-2.log.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: manpages-l10n
Source-Version: 4.9.1-5
Done: Helge Kreutzmann 

We believe that the bug you reported is fixed in the latest version of
manpages-l10n, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 982...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Helge Kreutzmann  (supplier of updated manpages-l10n 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 17 Feb 2021 17:42:23 +0100
Source: manpages-l10n
Architecture: source
Version: 4.9.1-5
Distribution: unstable
Urgency: medium
Maintainer: Dr. Tobias Quathamer 
Changed-By: Helge Kreutzmann 
Closes: 982814 982833
Changes:
 manpages-l10n (4.9.1-5) unstable; urgency=medium
 .
   * Remove man pages conflicting with man2html{-base}. Closes: #982833.
   * Add bug closure to previous changelog entry.
   * Some manpages where move to -it-dev, add correct Breaks and Replaces.
 Closes: #982814.
Checksums-Sha1:
 2065af54d8f7e94f32e26ca9860818e8c77a4304 2773 manpages-l10n_4.9.1-5.dsc
 d1cc1f87388f4f68a6d93a63b5108fb7d3e7d758 46276 
manpages-l10n_4.9.1-5.debian.tar.xz
 a3a4f2598b44c1c8f9e3920a5b5bdce18b0e9a39 9263 
manpages-l10n_4.9.1-5_amd64.buildinfo
Checksums-Sha256:
 

Processed: Re: Bug#960153: ca-certificates-java: Failed to install ca-certificates-java on Beagle Bone Black

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> reassign -1 openjdk-11-jre-headless 11.0.7+10-3~deb10u1
Bug #960153 [ca-certificates-java] ca-certificates-java: Failed to install 
ca-certificates-java on Beagle Bone Black
Bug reassigned from package 'ca-certificates-java' to 'openjdk-11-jre-headless'.
No longer marked as found in versions ca-certificates-java/20190405.
Ignoring request to alter fixed versions of bug #960153 to the same values 
previously set
Bug #960153 [openjdk-11-jre-headless] ca-certificates-java: Failed to install 
ca-certificates-java on Beagle Bone Black
Marked as found in versions openjdk-11/11.0.7+10-3~deb10u1.
> severity -1 serious
Bug #960153 [openjdk-11-jre-headless] ca-certificates-java: Failed to install 
ca-certificates-java on Beagle Bone Black
Severity set to 'serious' from 'grave'

-- 
960153: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960153
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#960153: ca-certificates-java: Failed to install ca-certificates-java on Beagle Bone Black

2021-02-17 Thread Paul Gevers
control: reassign -1 openjdk-11-jre-headless 11.0.7+10-3~deb10u1
control: severity -1 serious

On Sun, 7 Feb 2021 19:24:46 +0100 Chris Hofstaedtler 
wrote:
> * Robert Nelson  [210207 18:23]:
> > I fixed this locally in our BeagleBoard.org Debian Repo with this quick 
> > patch:
> 
> > -java -Xmx64m -jar $JAR -storepass "$storepass"
> > +java -Xmx64m -XX:-AssumeMP -jar $JAR -storepass "$storepass"
> 
> If this helps, someone please explain why this is not a bug in the
> used JRE/JDK?
> I fail to see how this is a bug in ca-certificates-java.

So, then let's reassign to openjdk-11-jre-headless to ask for the
maintainers opinion.

Also, it would be great if it could be confirmed to still happen in
bullseye. Robert, are you in the position to do that?

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

2021-02-17 Thread Dirk Eddelbuettel


On 17 February 2021 at 16:58, Graham Inggs wrote:
| Hi Dirk
| 
| On Wed, 17 Feb 2021 at 15:10, Dirk Eddelbuettel  wrote:
| > Graham:  What does that bigendian box say for   Sys.info()[["machine"]]   ?
| 
| The other big-endian box I tested was perotto.debian.net [*], it says:
| 
| > Sys.info()[["machine"]]
| [1] "ppc64"
| 
| > Should we test for endianness instead?  And then maybe try to roll up to the
| > cause of the difference?
| 
| I've just tested on 32-bit big-endian and the glmmTMB problem does not
| occur there, so at this stage I would say test for big-endian **and**
| 64 bits.
| 
| Just to be clear, is the fix you are proposing in Matrix going to fix
| the glmmTMB error?

No. That may well be something else.

| If a bug shows up on 64-bit big-endian, but not on little-endian or
| 32-bit big-endian, then it's usually a sign that somewhere a 64-bit
| variable is incorrectly being read or written to as a 32-bit variable.

CRAN uses a Solaris machine for some endianness variability but I believe
that machine runs only 32bit.

Dirk
 
| Regards
| Graham
| 
| 
| [*] https://db.debian.org/machines.cgi?sortby=purpose=dcs

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Processed: Re: Bug#953289: ABI change in libsoxr 0.1.3

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> reassign -1 mpd 0.22.4-1
Bug #953289 [libsoxr0] ABI change in libsoxr 0.1.3
Bug reassigned from package 'libsoxr0' to 'mpd'.
No longer marked as found in versions libsoxr/0.1.3-1 and libsoxr/0.1.3-2.
Ignoring request to alter fixed versions of bug #953289 to the same values 
previously set
Bug #953289 [mpd] ABI change in libsoxr 0.1.3
Marked as found in versions mpd/0.22.4-1.
> forwarded -1 https://github.com/MusicPlayerDaemon/MPD/issues/773
Bug #953289 [mpd] ABI change in libsoxr 0.1.3
Changed Bug forwarded-to-address to 
'https://github.com/MusicPlayerDaemon/MPD/issues/773' from 
'gene...@discussion.soxr.p.re.sourceforge.net'.
> severity -1 normal
Bug #953289 [mpd] ABI change in libsoxr 0.1.3
Severity set to 'normal' from 'serious'

-- 
953289: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953289
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#953289: ABI change in libsoxr 0.1.3

2021-02-17 Thread Sebastian Ramacher
Control: reassign -1 mpd 0.22.4-1
Control: forwarded -1 https://github.com/MusicPlayerDaemon/MPD/issues/773
Control: severity -1 normal

On 2021-01-15 22:44:37 +0100, Paul Gevers wrote:
> Hi all,
> 
> On Sat, 7 Mar 2020 09:57:02 +0100 Max Kellermann  wrote:
> > Package: libsoxr0
> > Version: 0.1.3-2
> > 
> > In version 0.1.3, libsoxr has made an undocumented ABI change which
> > causes MPD (Music Player Daemon) to crash:
> > 
> >  https://github.com/MusicPlayerDaemon/MPD/issues/773
> > 
> > The commit which changed the ABI was:
> >  
> > https://sourceforge.net/p/soxr/code/ci/52888cd410ae356bf3aa26d8fa106754b8fd8990
> 
> Any progress here? The transition freeze already started. How do you
> propose we solve this issue?

I've now reread the upstream bug report once again, and it appears as if
mpd is missing a call to soxr_clear before reusing a context. Hence,
I'm reassigning this bug to mpd.

Also lowering the severity as no ABI breakage seems to be involved.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#980793: [PATCH] bsdowl: piuparts failure

2021-02-17 Thread Dennis Filder
Control: tag -1 + patch

The attached patch fixes this.

Whoever takes care of this should also take care of #982711.


bsdowl-fix-980793-piuparts.patch.gz
Description: application/gzip


Bug#982717: udfclient: FTBFS: bmake[1]: no target to make.

2021-02-17 Thread Dennis Filder
On Wed, Feb 17, 2021 at 12:49:25PM +0100, Pali Rohár wrote:

> Hello Dennis! Thank you for investigation and the patch. Will you update
> also the package? Or should I do it? Note that I do not have Debian
> Developer permissions so I can update new version of package only to
> mentors server (which takes a long to appear in Debian archive...).

I have no upload permission anywhere, so you'll have to do it.  If you
feel like the normal process will take too long you could either ask
around on IRC, set the help tag, ask the release team for advice, or
as a last resort, contact a mentor/DD directly.  If you mention that
it's a small change and include a debdiff they're probably glad to
help.

Regards,
Dennis.



Processed: [PATCH] bsdowl: piuparts failure

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 + patch
Bug #980793 [bsdowl] bsdowl: piuparts failure
Added tag(s) patch.

-- 
980793: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980793
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: [PATCH] bsdowl: FTBFS: bmake[2]: don't know how to make distclean. Stop

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 + patch
Bug #982711 [src:bsdowl] bsdowl: FTBFS: bmake[2]: don't know how to make 
distclean. Stop
Added tag(s) patch.

-- 
982711: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982711
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#982711: [PATCH] bsdowl: FTBFS: bmake[2]: don't know how to make distclean. Stop

2021-02-17 Thread Dennis Filder
Control: tag -1 + patch

I suspect this issue is due to the same changes that caused #982717.
Also whoever wrote d/rules was apparently unaware that debhelper
supports bmake.  The patch reworks that and applies the same override
as the one for #982717.  After building with this patch debdiff showed
no differences in the file list, so I guess it works alright.

Whoever takes care of this should also take care of #980793.  Though
with a popcon of 5, apparently nothing build-depending on it, and the
maintainer unresponsive maybe this shouldn't be shipped anymore.

Regards,
Dennis.


bsdowl-fix-982711.patch.gz
Description: application/gzip


Bug#981718: marked as done (haskell-basement: ftbfs probably in document generation)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 16:33:55 +
with message-id 
and subject line Bug#981718: fixed in haskell-basement 0.0.11-1.1
has caused the Debian Bug report #981718,
regarding haskell-basement: ftbfs probably in document generation
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
981718: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981718
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: haskell-basement
Version: 0.0.11-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The package fails to build in Bullseye. The same is also reflected in
the Reproducible build status

Incomplete build failure snippet

```
Warning: 'unsafeIndexer' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
   0% (  0 / 27) in 'Basement.Sized.UVect'
  Missing documentation for:
Module header
UVect (Basement/Sized/UVect.hs:47)
MUVect (Basement/Sized/UVect.hs:48)
unUVect (Basement/Sized/UVect.hs:47)
toUVect (Basement/Sized/UVect.hs:50)
empty (Basement/Sized/UVect.hs:57)
singleton (Basement/Sized/UVect.hs:60)
replicate (Basement/Sized/UVect.hs:68)
thaw (Basement/Sized/UVect.hs:71)
freeze (Basement/Sized/UVect.hs:74)
index (Basement/Sized/UVect.hs:86)
map (Basement/Sized/UVect.hs:89)
foldl' (Basement/Sized/UVect.hs:92)
foldr (Basement/Sized/UVect.hs:95)
cons (Basement/Sized/UVect.hs:98)
snoc (Basement/Sized/UVect.hs:101)
elem (Basement/Sized/UVect.hs:134)
sub (Basement/Sized/UVect.hs:104)
uncons (Basement/Sized/UVect.hs:117)
unsnoc (Basement/Sized/UVect.hs:122)
splitAt (Basement/Sized/UVect.hs:129)
all (Basement/Sized/UVect.hs:137)
any (Basement/Sized/UVect.hs:140)
find (Basement/Sized/UVect.hs:143)
reverse (Basement/Sized/UVect.hs:146)
sortBy (Basement/Sized/UVect.hs:149)
intersperse (Basement/Sized/UVect.hs:152)
Warning: 'A' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'haddock: internal error: : commitBuffer: invalid argument 
(invalid character)
Haddock failed (no modules?), refusing to create empty documentation package.
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:173: build-haddock-stamp] Error 1
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package
I: unmounting dev/ptmx filesystem
I: unmounting dev/pts filesystem
I: unmounting dev/shm filesystem
I: unmounting proc filesystem
```

Full build log:
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/haskell-basement.html


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

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
Source: haskell-basement
Source-Version: 0.0.11-1.1
Done: Ritesh Raj Sarraf 

We believe that the bug you reported is fixed in the latest version of
haskell-basement, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 981...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ritesh Raj Sarraf  (supplier of updated haskell-basement 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 17 Feb 2021 21:48:15 +0530
Source: haskell-basement
Architecture: source
Version: 0.0.11-1.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Haskell Group 

Changed-By: Ritesh Raj Sarraf 
Closes: 981718
Changes:
 haskell-basement (0.0.11-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Explicitly set LANG to utf8 to workaround a build bug (Closes: #981718)
Checksums-Sha1:
 545791f082f008f77f46bef36332da3251f26b76 2330 

Processed: haskell-basement: diff for NMU version 0.0.11-1.1

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> tags 981718 + patch
Bug #981718 [src:haskell-basement] haskell-basement: ftbfs probably in document 
generation
Added tag(s) patch.
> tags 981718 + pending
Bug #981718 [src:haskell-basement] haskell-basement: ftbfs probably in document 
generation
Added tag(s) pending.

-- 
981718: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981718
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#981718: haskell-basement: diff for NMU version 0.0.11-1.1

2021-02-17 Thread Ritesh Raj Sarraf
Control: tags 981718 + patch
Control: tags 981718 + pending

Dear maintainer,

I've prepared an NMU for haskell-basement (versioned as 0.0.11-1.1) and
uploaded it to DELAYED/07. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru haskell-basement-0.0.11/debian/changelog 
haskell-basement-0.0.11/debian/changelog
--- haskell-basement-0.0.11/debian/changelog2020-05-26 22:07:56.0 
+0530
+++ haskell-basement-0.0.11/debian/changelog2021-02-17 21:48:15.0 
+0530
@@ -1,3 +1,10 @@
+haskell-basement (0.0.11-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Explicitly set LANG to utf8 to workaround a build bug (Closes: #981718) 
+
+ -- Ritesh Raj Sarraf   Wed, 17 Feb 2021 21:48:15 +0530
+
 haskell-basement (0.0.11-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru haskell-basement-0.0.11/debian/rules 
haskell-basement-0.0.11/debian/rules
--- haskell-basement-0.0.11/debian/rules2020-02-08 07:28:07.0 
+0530
+++ haskell-basement-0.0.11/debian/rules2021-02-17 21:48:11.0 
+0530
@@ -4,5 +4,6 @@
 DEB_CABAL_PACKAGE = basement
 DEB_DEFAULT_COMPILER = ghc
 
+export LC_ALL=C.UTF-8
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/hlibrary.mk



Bug#982253: netkit telnetd: ship with bullseye with open security problems?

2021-02-17 Thread Andreas Henriksson
Control: severity -1 important

Hi again,

FYI I just uploaded netkit-telnet with two changes:
- orphan package
- include patch to fix crash on nessus scan

On Mon, Feb 15, 2021 at 02:21:04AM +0100, Chris Hofstaedtler wrote:
> I was hoping someone would jump in here and say "I'm using a telnet
> server in 2021, and want to maintain it". But... not happening
> apparently.

Still hoping for Christoph Biedl to take it, but the package is
now orphaned since he did not respond (yet) to my previous mail.

> 
> Personally I would favor keeping netkit-telnet, but turning off
> telnetd. As Salvatore said, this might have to wait for bookworm.

IMO netcat is a better telnet client. We could possibly have
a telnet package that just symlinks telnet to netcat for
easier discoverability by users who hear telnet and are not
familiar with netcat. (That could possibly also help my problem
which is remembering which netcat implementation is the saner one.)

If the telnet daemon is removed, I think you could just as well
RM src:netkit-telnet entirely 

I'm personally also aware of people writing new telnet client/server
code right now (even in 2021!). Their code is likely not less buggy,
but what do I know. I'd rather see them use existing implementation
and improve on those if needed, but my argumentation gets harder if
those are removed from the archives.

(I don't have a problem with people using telnet technology if
used/contained on trusted premises or accessible only via some transport
layer security like a VPN.)

Right now we offer several implementations and to me they all seem
equally bad and un(der)maintained from a quick glance, but maybe we
should just find one implementation that we promote usage of and get rid
of the others.
I noticed that busybox also has a telnetd applet that is currently
disabled. Maybe it would be something to investigate if that's a better
option to enable as hopefully busybox is a good active upstream (but I
don't know how they view or care about their own telnet implementation).

> 
> Maybe upload the patch now (closing both bugs), and I'll see if I
> remember to remove telnetd for bookworm? :-)

I think reopening this discussion early in bookworm is much better.
In general if we remove stuff early, we have a good chance to see if
people miss it and alot of time to try to convince people to try other
solutions and if that fails still have time to re-introduce things
before freeze happens
For now I'm lowering the severity below RC (maybe we should just close
this bug report. Feel free to do so as far as I'm concerned atleast).

And as said, if you go for removal please just remove the entire source.

Regards,
Andreas Henriksson



Processed: Re: Bug#982253: netkit telnetd: ship with bullseye with open security problems?

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> severity -1 important
Bug #982253 [telnetd] netkit telnetd: ship with bullseye with open security 
problems?
Severity set to 'important' from 'serious'

-- 
982253: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982253
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#982974: FTBFS: fails to compile translation files

2021-02-17 Thread Ritesh Raj Sarraf
Source: swt4-gtk
Version: 4.17.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

During a rebuild of the package on a Bullseye based derivate, it is
found that the package fails to build. From the build failure log, it
seems the issue is related to non-ascii characters. Snippet below. Also
to mention that the same build failure is also seen on the Reproducible
Builds setup.

```
[  353s] dh binary --buildsystem=makefile --with maven-repo-helper --with 
javahelper
[  353s]dh_update_autotools_config -O--buildsystem=makefile
[  353s]dh_autoreconf -O--buildsystem=makefile
[  353s]dh_auto_configure -O--buildsystem=makefile
[  354s]jh_linkjars -O--buildsystem=makefile
[  354s]debian/rules override_dh_auto_build
[  354s] make[1]: Entering directory '/usr/src/packages/BUILD'
[  354s] cd bundles/org.eclipse.swt && ant -f buildFragment.xml build.jars 
-Dswt.ws=gtk -Dplugindir=.
[  355s] Buildfile: 
/usr/src/packages/BUILD/bundles/org.eclipse.swt/buildFragment.xml
[  356s]
[  356s] properties:
[  356s]
[  356s] init:
[  356s] [mkdir] Created dir: 
/usr/src/packages/BUILD/bundles/org.eclipse.swt/target
[  356s]
[  356s] build.jars:
[  356s]
[  356s] properties:
[  356s]
[  356s] init:
[  356s]
[  356s] @dot:
[  356s] [mkdir] Created dir: 
/usr/src/packages/BUILD/bundles/org.eclipse.swt/temp.folder/@dot.bin
[  356s]
[  356s] copy.gtk.src:
[  357s]  [copy] Copying 512 files to 
/usr/src/packages/BUILD/bundles/org.eclipse.swt/temp.folder/@dot.src
[  357s]
[  357s] copy.translationfiles:
[  358s] [javac] Compiling 436 source files to 
/usr/src/packages/BUILD/bundles/org.eclipse.swt/temp.folder/@dot.bin
[  360s] [javac] 
/usr/src/packages/BUILD/bundles/org.eclipse.swt/temp.folder/@dot.src/org/eclipse/swt/layout/FillLayout.java:13:
 error: unmappable character (0xC3) for encoding US-ASCII
[  360s] [javac]  * Christoph L??ubrich - Bug 513185
[  360s] [javac]   ^
[  360s] [javac] 
/usr/src/packages/BUILD/bundles/org.eclipse.swt/temp.folder/@dot.src/org/eclipse/swt/layout/FillLayout.java:13:
 error: unmappable character (0xA4) for encoding US-ASCII
[  360s] [javac]  * Christoph L??ubrich - Bug 513185
[  360s] [javac]^
[  361s] [javac] 2 errors
[  361s]
[  361s] BUILD FAILED
[  361s] /usr/src/packages/BUILD/bundles/org.eclipse.swt/buildFragment.xml:88: 
The following error occurred while executing this line:
[  361s] /usr/src/packages/BUILD/bundles/org.eclipse.swt/buildFragment.xml:61: 
Compile failed; see the compiler error output for details.
[  361s]
[  361s] Total time: 5 seconds
[  361s] make[1]: *** [debian/rules:30: override_dh_auto_build] Error 1
[  361s] make[1]: Leaving directory '/usr/src/packages/BUILD'
[  361s] make: *** [debian/rules:27: binary] Error 2
[  361s] dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2
```


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

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



Bug#982973: qtmultimedia-opensource-src: FTBFS in test: tst_QVideoFrame::image(64x64 NV12) Received a fatal error

2021-02-17 Thread Ritesh Raj Sarraf
Source: qtmultimedia-opensource-src
Version: 5.15.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

During a rebuild of the package on a Bullseye derivative, it was seen
that the package fails to build from source. It fails in one of the
tests, for which the failure snippet is mentioned below. Please also
note that the same failure (and full build log) is also available on the
Reproducible Builds.

```
[ 1877s] Config: Using QtTest library 5.15.2, Qt 5.15.2 
(x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 10.2.1 
20210110), debian unknown
[ 1877s] PASS   : tst_QVideoFrame::initTestCase()
[ 1877s] PASS   : tst_QVideoFrame::create(64x64 ARGB32)
[ 1877s] PASS   : tst_QVideoFrame::create(32x256 YUV420P)
[ 1877s] PASS   : tst_QVideoFrame::createInvalid(64x64 ARGB32 0 size)
[ 1877s] PASS   : tst_QVideoFrame::createInvalid(32x256 YUV420P negative size)
[ 1877s] PASS   : tst_QVideoFrame::createFromBuffer(64x64 ARGB32 no handle)
[ 1877s] PASS   : tst_QVideoFrame::createFromBuffer(64x64 ARGB32 gl handle)
[ 1877s] PASS   : tst_QVideoFrame::createFromBuffer(64x64 ARGB32 user handle)
[ 1877s] PASS   : tst_QVideoFrame::createFromImage(64x64 RGB32)
[ 1877s] PASS   : tst_QVideoFrame::createFromImage(12x45 RGB16)
[ 1877s] PASS   : tst_QVideoFrame::createFromImage(19x46 ARGB32_Premultiplied)
[ 1877s] PASS   : tst_QVideoFrame::createFromIncompatibleImage()
[ 1877s] PASS   : tst_QVideoFrame::createNull()
[ 1877s] PASS   : tst_QVideoFrame::destructor()
[ 1877s] PASS   : tst_QVideoFrame::copy(64x64 ARGB32)
[ 1877s] PASS   : tst_QVideoFrame::copy(64x64 ARGB32)
[ 1877s] PASS   : tst_QVideoFrame::copy(32x256 YUV420P)
[ 1877s] PASS   : tst_QVideoFrame::copy(1052x756 ARGB32)
[ 1877s] PASS   : tst_QVideoFrame::copy(32x256 YUV420P)
[ 1877s] PASS   : tst_QVideoFrame::assign(64x64 ARGB32)
[ 1877s] PASS   : tst_QVideoFrame::assign(32x256 YUV420P)
[ 1877s] PASS   : tst_QVideoFrame::map(read-only)
[ 1877s] PASS   : tst_QVideoFrame::map(write-only)
[ 1877s] PASS   : tst_QVideoFrame::map(read-write)
[ 1877s] PASS   : tst_QVideoFrame::mapImage(read-only)
[ 1877s] PASS   : tst_QVideoFrame::mapImage(write-only)
[ 1877s] PASS   : tst_QVideoFrame::mapImage(read-write)
[ 1877s] PASS   : tst_QVideoFrame::mapPlanes(Planar)
[ 1877s] PASS   : tst_QVideoFrame::mapPlanes(Format_YUV420P)
[ 1877s] PASS   : tst_QVideoFrame::mapPlanes(Format_YV12)
[ 1877s] PASS   : tst_QVideoFrame::mapPlanes(Format_NV12)
[ 1877s] PASS   : tst_QVideoFrame::mapPlanes(Format_NV21)
[ 1877s] PASS   : tst_QVideoFrame::mapPlanes(Format_IMC2)
[ 1877s] PASS   : tst_QVideoFrame::mapPlanes(Format_IMC4)
[ 1877s] PASS   : tst_QVideoFrame::mapPlanes(Format_IMC1)
[ 1877s] PASS   : tst_QVideoFrame::mapPlanes(Format_IMC3)
[ 1877s] PASS   : tst_QVideoFrame::mapPlanes(Format_ARGB32)
[ 1877s] PASS   : tst_QVideoFrame::imageDetach()
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QImage::Format_RGB32 | 
QVideoFrame::Format_RGB32)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QImage::Format_ARGB32 | 
QVideoFrame::Format_ARGB32)
[ 1877s] PASS   : 
tst_QVideoFrame::formatConversion(QImage::Format_ARGB32_Premultiplied | 
QVideoFrame::Format_ARGB32_Premultiplied)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QImage::Format_RGB16 | 
QVideoFrame::Format_RGB565)
[ 1877s] PASS   : 
tst_QVideoFrame::formatConversion(QImage::Format_ARGB8565_Premultiplied | 
QVideoFrame::Format_ARGB8565_Premultiplied)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QImage::Format_RGB555 | 
QVideoFrame::Format_RGB555)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QImage::Format_RGB888 | 
QVideoFrame::Format_RGB24)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QImage::Format_MonoLSB)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QImage::Format_Indexed8)
[ 1877s] PASS   : 
tst_QVideoFrame::formatConversion(QImage::Format_ARGB_Premultiplied)
[ 1877s] PASS   : 
tst_QVideoFrame::formatConversion(QImage::Format_ARGB8555_Premultiplied)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QImage::Format_RGB666)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QImage::Format_RGB444)
[ 1877s] PASS   : 
tst_QVideoFrame::formatConversion(QImage::Format_ARGB_Premultiplied)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QVideoFrame::Format_BGRA32)
[ 1877s] PASS   : 
tst_QVideoFrame::formatConversion(QVideoFrame::Format_BGRA32_Premultiplied)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QVideoFrame::Format_BGR32)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QVideoFrame::Format_BGR24)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QVideoFrame::Format_BGR565)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QVideoFrame::Format_BGR555)
[ 1877s] PASS   : 
tst_QVideoFrame::formatConversion(QVideoFrame::Format_BGRA5658_Premultiplied)
[ 1877s] PASS   : tst_QVideoFrame::formatConversion(QVideoFrame::Format_AYUV444)
[ 1877s] PASS   : 

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

2021-02-17 Thread Graham Inggs
Hi Dirk

On Wed, 17 Feb 2021 at 15:10, Dirk Eddelbuettel  wrote:
> Graham:  What does that bigendian box say for   Sys.info()[["machine"]]   ?

The other big-endian box I tested was perotto.debian.net [*], it says:

> Sys.info()[["machine"]]
[1] "ppc64"

> Should we test for endianness instead?  And then maybe try to roll up to the
> cause of the difference?

I've just tested on 32-bit big-endian and the glmmTMB problem does not
occur there, so at this stage I would say test for big-endian **and**
64 bits.

Just to be clear, is the fix you are proposing in Matrix going to fix
the glmmTMB error?

If a bug shows up on 64-bit big-endian, but not on little-endian or
32-bit big-endian, then it's usually a sign that somewhere a 64-bit
variable is incorrectly being read or written to as a 32-bit variable.

Regards
Graham


[*] https://db.debian.org/machines.cgi?sortby=purpose=dsc



Bug#974428: marked as done (in.telnetd crashes on running Nessus security scan)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 14:48:48 +
with message-id 
and subject line Bug#974428: fixed in netkit-telnet 0.17-42
has caused the Debian Bug report #974428,
regarding in.telnetd crashes on running Nessus security scan
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
974428: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974428
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: telnetd
Version: 0.17-41
Severity: serious


Problem Statement:

The in.telnetd process is seen to crash on running Nessus security scan.

in.telnetd version:
telnetd_0.17-41_amd64.deb (Debian stretch image)

/etc/inetd.conf:
telnet  stream  tcp6   nowait  telnetd /usr/sbin/tcpd  /usr/sbin/in.telnetd

Possible root cause:

The telnetd process invokes netflush() to flush() data

root@OS10:# #154080 0x7f681f34a8d9 in _IO_new_do_write (fp=,
data=, to_do=1350) at fileops.c:502
root@OS10:# #154081 0x7f681f348978 in _IO_new_file_sync
(fp=0x55a7d9b45150) at fileops.c:882
root@OS10:# #154082 0x7f681f33e03c in __GI__IO_fflush
(fp=0x55a7d9b45150) at iofflush.c:40
root@OS10:# #154083 0x55a7d97f95a0 in netflush () at utility.c:325
root@OS10:# #154084 0x55a7d97f95d6 in ttloop () at utility.c:81
root@OS10:# #154085 0x55a7d97f5c55 in getterminaltype
(name=0x7ffe09676c70 "") at telnetd.c:484
root@OS10:# #154086 doit (who_len=16, who=0x7ffe09676bf0) at telnetd.c:722
root@OS10:# #154087 main (argc=, argv=, env=) at telnetd.c:402

2)Error is encountered while flushing.This results in invocation of
cleanup function

oot@OS10:# #154071 0x7f681f34c4cc in _IO_flush_all_lockp
(do_lock=do_lock@entry=0) at genops.c:792
root@OS10:# #154072 0x7f681f34c695 in _IO_cleanup () at genops.c:957
root@OS10:# #154073 0x7f681f30c8e3 in __run_exit_handlers
(status=0, listp=, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:96
root@OS10:# #154074 0x7f681f30c99a in __GI_exit (status=) at exit.c:105
root@OS10:# #154075 0x55a7d97f8fd2 in cleanup (sig=sig@entry=0) at
sys_term.c:736
root@OS10:# #154076 0x55a7d97f92d0 in netwritebuf () at utility.c:288
root@OS10:~# #154077 0x55a7d97f94be in netwrite (cookie=,

3)The cleanup function invokes exit(0), which in turn trigger flushing
again. The flushing encounters the error again ,resulting in
continuous loop.

root@OS10:# #154070 0x7f681f34a8d9 in _IO_new_do_write (fp=,
data=, to_do=1350) at fileops.c:502
root@OS10:# #154071 0x7f681f34c4cc in _IO_flush_all_lockp
(do_lock=do_lock@entry=0) at genops.c:792
root@OS10:# #154072 0x7f681f34c695 in _IO_cleanup () at genops.c:957
root@OS10:# #154073 0x7f681f30c8e3 in __run_exit_handlers
(status=0, listp=, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:96
root@OS10:# #154074 0x7f681f30c99a in __GI_exit (status=) at exit.c:105
root@OS10:# #154075 0x55a7d97f8fd2 in cleanup (sig=sig@entry=0) at
sys_term.c:736

Back trace

Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/in.telnetd...Reading symbols from
/usr/lib/debug/.build-id/f7/8762784cef671474d6d52981133d7b47d721a9.debug...done.
done.
[New LWP 14372]
Core was generated by `in.telnetd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 getutline_r_file (line=0x7ffd5faa11d0, buffer=0x7ffd5faa1350,
result=0x7ffd5faa11b8) at ../login/utmp_file.c:344
344 ../login/utmp_file.c: No such file or directory.
(gdb) bt
#0 getutline_r_file (line=0x7ffd5faa11d0, buffer=0x7ffd5faa1350,
result=0x7ffd5faa11b8) at ../login/utmp_file.c:344
#1 0x7f3154c310e9 in __getutline_r
(line=line@entry=0x7ffd5faa11d0, buffer=buffer@entry=0x7ffd5faa1350,
result=result@entry=0x7ffd5faa11b8) at getutline_r.c:39
#2 0x7f3154eb42b0 in logout (line=line@entry=0x563f3af744a5
"pts/3") at logout.c:45
#3 0x563f39db1fb5 in cleanup (sig=sig@entry=0) at sys_term.c:734
#4 0x563f39db22d0 in netwritebuf () at utility.c:288
#5 0x563f39db24be in netwrite (cookie=,
buf=0x563f3af768f0

Bug#796536: criu: package not yet ready for stable release / fast moving (blocking bug)

2021-02-17 Thread Shengjing Zhu
On Wed, Apr 22, 2020 at 04:27:54PM +0200, Salvatore Bonaccorso wrote:
> I got contacted by the LXC maintainers, specifically due to
> potentially enabling the lxc-checkpoint tool, but only if we lift this
> blocking bug and allow criu to be released in bullseye.
> 
> This is a valid request, and will look into if #796536 is still too
> overcautious and we should actually move on and include criu in the
> next stable release.
> 

It misses bullseye. Could you update the status quo? It's not a fast moving
upstream currently.



Bug#982946: marked as done (python3-pyudev: pyudev.glib import crashes in Python 3)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 14:24:51 +
with message-id 
and subject line Bug#982946: fixed in pyudev 0.22.0-2
has caused the Debian Bug report #982946,
regarding python3-pyudev: pyudev.glib import crashes in Python 3
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982946: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982946
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: python3-pyudev
Version: 0.22.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The source code in the package does not include fixes for Python 3 compat.

It was fixed in the main branch of github repository long time ago:

https://github.com/pyudev/pyudev/blob/master/src/pyudev/glib.py

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

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

Versions of packages python3-pyudev depends on:
ii  libudev1 247.3-1
ii  python3  3.9.1-1
ii  python3-six  1.15.0-2

python3-pyudev recommends no packages.

python3-pyudev suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: pyudev
Source-Version: 0.22.0-2
Done: Andreas Henriksson 

We believe that the bug you reported is fixed in the latest version of
pyudev, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 982...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Henriksson  (supplier of updated pyudev package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 17 Feb 2021 14:00:23 +0100
Source: pyudev
Architecture: source
Version: 0.22.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Team 
Changed-By: Andreas Henriksson 
Closes: 982946
Changes:
 pyudev (0.22.0-2) unstable; urgency=medium
 .
   * Team upload.
   * Cherry-pick upstream commits fixing pyudev.glib module (Closes: #982946)
   * Recommends gir packages needed by pyudev.glib
   * Configure debian branch name in debian/gbp.conf
Checksums-Sha1:
 acbb2803a89fb32d502af4df5600b7fc7760b588 2143 pyudev_0.22.0-2.dsc
 9fa458b1b55d002c2190c879cc5e09bfe34f4030 6352 pyudev_0.22.0-2.debian.tar.xz
 2ab9b470113b01b4917325adfe4b58061f45b348 6858 pyudev_0.22.0-2_amd64.buildinfo
Checksums-Sha256:
 ef0b29e3d9907357d46106fdfe2b9c64617bac991b2dcfc5316494567233d57f 2143 
pyudev_0.22.0-2.dsc
 2aece5900d05e6b1f641eb8efba18f1561cc33b2eef923ca298d58521e072963 6352 
pyudev_0.22.0-2.debian.tar.xz
 3c44338d7c22fc99410f4ce31ef5f7377244f18195521eb343c1b4414376b3d6 6858 
pyudev_0.22.0-2_amd64.buildinfo
Files:
 c0024950c4f0c0cf0c3346b1cc6cc100 2143 python optional pyudev_0.22.0-2.dsc
 d46b9f17093728ad6590f0ce38a04fa6 6352 python optional 
pyudev_0.22.0-2.debian.tar.xz
 ced77714f9498fe509662f183b400dac 6858 python optional 
pyudev_0.22.0-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE+uHltkZSvnmOJ4zCC8R9xk0TUwYFAmAtHk4RHGFuZHJlYXNA
ZmF0YWwuc2UACgkQC8R9xk0TUwa1tBAAlGq50B29ulN1KxHRIqOvOpW6rPenEdUL
InSdMUZre8BpsEqEXMeFbZgVvmph5w/iIB1zpZCaVmfWO+QGvAuHBSwZIlykQgz5
/adTHH8pMAocEnLlswlxuQDj+cjoIE2lKy4IP+mhZQKN1DDOrx2Bbyhz9voYJuPf
La4YUXR7/CL62yuewuZMYBM/KTaGSbFFyYFer09kiK0ITD3pGWTOvS5tiE+BTrHc
5vN+mkaMVenE8wk03zD48gkj15AT3u6UUzA69EoHXk70lQiDnjFBcCKkCk8p39de
ek0129FB+HpYlwN3ytGpMdaIPUIRdT0x32xhM3DO118ZALK7LFUb1N0TASqjUnHB
l9kKGS115j3OxNL+V5X4sTOYj44up6NrbE0edS2kmWmzOVY5JJtpChwmc8aDBj8k
jsGfZ7vtiq1mxgCRN2CplOHdVvXyrX5D13f8aWpgFBhZudfZSyjwLVOvGhfUqvR3
Q/mMtQc8EvZqvKW9+UPw1FppI7RuxHJ7Kni1rQ5SNOg2q7IZ5wF60mPhdkxYn+Oh
EnLuzRl+IpUoENy99LWX6A/lEfsSr28qysWbwGDgDXbjODbBz/dPLX3/tVWwWzX+
QYDePhyl7LYLbluXkBtXKSore8tL8XFL+/So6lAtpJkRQQTJYRy5BzEInNOlzlvC
HgsNE63Oyh8=
=Qqy6
-END PGP SIGNATURE End Message ---


Bug#982967: marked as done (FTBFS: unsat-dependency: golang-github-rsc-letsencrypt-dev:amd64)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 22:14:55 +0800
with message-id 

and subject line Re: Bug#982967: FTBFS: unsat-dependency: 
golang-github-rsc-letsencrypt-dev:amd64
has caused the Debian Bug report #982967,
regarding FTBFS: unsat-dependency: golang-github-rsc-letsencrypt-dev:amd64
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982967: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982967
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: docker.io
Version: 19.03.4+dfsg2-2
Severity: serious
Justification: FTBFS

During a test rebuild of the docker.io package, I noticed that it declares a
build-depends relationship on a non-existing package:

,
| Install main build dependencies (apt-based resolver)
| 
| 
| Installing build dependencies
| Reading package lists...
| Building dependency tree...
| Reading state information...
| 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:
|  sbuild-build-depends-main-dummy : Depends: golang-github-rsc-letsencrypt-dev 
but it is not installable
| E: Unable to correct problems, you have held broken packages.
| apt-get failed.
| E: Package installation failed
| Not removing build depends: cloned chroot in use
`


It appears this package has been removed as part of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956744
--- End Message ---
--- Begin Message ---
Version: 19.03.5+dfsg1-2

On Wed, Feb 17, 2021 at 9:54 PM Reinhard Tartler  wrote:
>
> Source: docker.io
> Version: 19.03.4+dfsg2-2
^^^

There's no need to report a bug that has been fixed.

docker.io (19.03.5+dfsg1-2) unstable; urgency=medium

 [ Dmitry Smirnov ]
 * Removed unused "golang-github-rsc-letsencrypt-dev" from Build-Depends.

-- 
Shengjing Zhu--- End Message ---


Bug#982969: emacs: expects working network in tests

2021-02-17 Thread Ritesh Raj Sarraf
Package: emacs
Version: 1:27.1+1-3
Severity: serious
Tags: ftbfs

Dear Maintainer,

During a rebuild of the package on a Bullseye derivative, it is seen
that the package fails to build from source. It is failing in the tests,
where it seeks to access the internet, which by policy is disabled in
the build environments. The same build failures can also be seen in the
Reproducible Builds efforts.

Below is just a snippet of the failures.

```
Test lookup-unicode-domains condition:
(ert-test-failed
 ((should
   (network-lookup-address-info
(puny-encode-domain "faß.de")))
  :form
  (network-lookup-address-info "xn--fa-hia.de")
  :value nil))
   FAILED   3/18  lookup-unicode-domains (0.000616 sec)


Test unibyte-domain-name condition:
(ert-test-failed
 ((should
   (network-lookup-address-info
(string-to-unibyte "google.com")))
  :form
  (network-lookup-address-info "google.com")
  :value nil))
   FAILED  18/18  unibyte-domain-name (0.000981 sec)

Ran 18 tests, 13 results as expected, 4 unexpected, 1 skipped (2022-03-21 
01:59:54-1200, 1.713005 sec)

4 unexpected results:
   FAILED  lookup-family-specification
   FAILED  lookup-google
   FAILED  lookup-unicode-domains
   FAILED  unibyte-domain-name

1 skipped results:
  SKIPPED  make-process-w32-debug-spawn-error

```


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

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

Versions of packages emacs depends on:
pn  emacs-gtk | emacs-lucid | emacs-nox  

emacs recommends no packages.

emacs suggests no packages.


Bug#982766: [Pkg-javascript-devel] Bug#982766: Bug#982766: node-webpack: remove dependency on node-uglifyjs-webpack-plugin

2021-02-17 Thread Julian Gilbey
On Sun, Feb 14, 2021 at 02:26:30PM +0100, Jonas Smedegaard wrote:
> Quoting Pirate Praveen (2021-02-14 13:32:36)
> > On 2021, ഫെബ്രുവരി 14 2:55:33 PM IST, Jonas Smedegaard  
> > wrote:
> > >Quoting Pirate Praveen (2021-02-14 08:32:08)
> > >No, we should not hide the true severity of issues in our packages: 
> > >The issue _is_ serious and has been for some time.
> [...]
> > It also just a wrapper for calling uglify-js or terser directly from 
> > webpack.
> 
> Sorry, I now realize that we are talking about bug#977311 - I thought we 
> were talking about bug#952367
> 
> I still recommend to request release team to ignore for this release 
> instead of lowering sverity, but don't care anough about this particular 
> mess to discuss further...

Has the release team been contacted yet?  Once it is dropped from
testing, it will not be reaccepted for bullseye.

Best wishes,

   Julian



Bug#982967: FTBFS: unsat-dependency: golang-github-rsc-letsencrypt-dev:amd64

2021-02-17 Thread Reinhard Tartler
Source: docker.io
Version: 19.03.4+dfsg2-2
Severity: serious
Justification: FTBFS

During a test rebuild of the docker.io package, I noticed that it declares a
build-depends relationship on a non-existing package:

,
| Install main build dependencies (apt-based resolver)
| 
| 
| Installing build dependencies
| Reading package lists...
| Building dependency tree...
| Reading state information...
| 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:
|  sbuild-build-depends-main-dummy : Depends: golang-github-rsc-letsencrypt-dev 
but it is not installable
| E: Unable to correct problems, you have held broken packages.
| apt-get failed.
| E: Package installation failed
| Not removing build depends: cloned chroot in use
`


It appears this package has been removed as part of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956744



Bug#972852: marked as done (gdm3: Gdm3 comes to invoke gdm-x-session at the beginning of the user session)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 14:22:29 +0100
with message-id <20210217132229.irzeg2iz5n4sk...@fatal.se>
and subject line Re: gdm3: Gdm3 comes to  invoke gdm-x-session  at the 
beginning of the user session
has caused the Debian Bug report #972852,
regarding gdm3: Gdm3 comes to  invoke gdm-x-session  at the beginning of the  
user session
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
972852: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972852
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: gdm3
Version: 3.38.1-2
Severity: grave

Dear Maintainer,
 After I upgraded my Debian box using the command of "apt upgrade" on
17th Oct 2020, I always get an "Oops! A problem occurred!" screen after
login.

 According to system logs, I seem gdm3 come to invoke gdm-x-session
always at the beginning of the user session, even though gdm3 is
running in Wayland on the login screen. Therefore gnome-shell of the
user session seems to fail.

 Does anyone fix this problem?

Thanks,
Takahide Nojima

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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.55-3
ii  adduser   3.118
ii  dbus  1.12.20-1
ii  dconf-cli 0.38.0-1
ii  dconf-gsettings-backend   0.38.0-1
ii  debconf [debconf-2.0] 1.5.74
ii  gir1.2-gdm-1.03.38.1-2
ii  gnome-session-bin 3.38.0-2
ii  gnome-session-common  3.38.0-2
ii  gnome-settings-daemon 3.38.0-2
ii  gnome-shell   3.38.1-1
ii  gnome-terminal [x-terminal-emulator]  3.38.0-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  libaccountsservice0   0.6.55-3
ii  libaudit1 1:2.8.5-3.1
ii  libc6 2.31-4
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libgdm1   3.38.1-2
ii  libglib2.0-0  2.66.1-2
ii  libglib2.0-bin2.66.1-2
ii  libgtk-3-03.24.23-2
ii  libkeyutils1  1.6.1-2
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd246.6-2
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.50.1+dfsg-1
ii  libselinux1   3.1-2+b1
ii  libsystemd0   246.6-2
ii  libx11-6  2:1.6.12-1
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.14-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  11.1.0
ii  policykit-1   0.105-29
ii  procps2:3.3.16-5
ii  ucf   3.0043
ii  x11-common1:7.7+21
ii  x11-xserver-utils 7.7+8

Versions of packages gdm3 recommends:
ii  at-spi2-core2.38.0-2
ii  desktop-base10.0.3
ii  x11-xkb-utils   7.7+5
ii  xserver-xephyr  2:1.20.9-2
ii  xserver-xorg1:7.7+21
ii  zenity  3.32.0-6

Versions of packages gdm3 suggests:
ii  gnome-orca3.38.0-1
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.36.0-1

-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3
--- End Message ---
--- Begin Message ---
Hello,

On Sun, Oct 25, 2020 at 05:32:41PM +0900, nozzy123no...@gmail.com wrote:
> Package: gdm3
> Version: 3.38.1-2
> Severity: grave
> 
> Dear Maintainer,
>  After I upgraded my Debian box using the command of "apt upgrade" on
> 17th Oct 2020, I always get an "Oops! A problem occurred!" screen after
> login.

Thats bad!

> 
>  According to system logs, I seem gdm3 come to invoke gdm-x-session
> always at the beginning of the user session, even though gdm3 is
> running in Wayland on the login 

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

2021-02-17 Thread Dirk Eddelbuettel


Hi Martin,

On 17 February 2021 at 10:43, Martin Maechler wrote:
| Dear Dirk,
| I'm in vacations right now ...

Ah, nice.
 
| 1)  I think I might simply disable the check  *on* that platform .. or
| platforms with similar characteristics.

Sounds good to me.

| Can you send me the outputs of  so I can take some of the entries to
| determine I'm on the platform?
| 
| sessionInfo()

> sessionInfo()
R version 4.0.3 (2020-10-10)
Platform: s390x-ibm-linux-gnu (64-bit)
Running under: Debian GNU/Linux bullseye/sid

Matrix products: default
BLAS:   /usr/lib/s390x-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/s390x-linux-gnu/lapack/liblapack.so.3.9.0

locale:
[1] C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 

loaded via a namespace (and not attached):
[1] compiler_4.0.3
> 

| str(.Machine, digits=10)

>  str(.Machine, digits=10)
List of 28
 $ double.eps   : num 2.220446049e-16
 $ double.neg.eps   : num 1.110223025e-16
 $ double.xmin  : num 2.225073859e-308
 $ double.xmax  : num 1.797693135e+308
 $ double.base  : int 2
 $ double.digits: int 53
 $ double.rounding  : int 5
 $ double.guard : int 0
 $ double.ulp.digits: int -52
 $ double.neg.ulp.digits: int -53
 $ double.exponent  : int 11
 $ double.min.exp   : int -1022
 $ double.max.exp   : int 1024
 $ integer.max  : int 2147483647
 $ sizeof.long  : int 8
 $ sizeof.longlong  : int 8
 $ sizeof.longdouble: int 16
 $ sizeof.pointer   : int 8
 $ longdouble.eps   : num 1.925929944e-34
 $ longdouble.neg.eps   : num 9.629649722e-35
 $ longdouble.digits: int 113
 $ longdouble.rounding  : int 5
 $ longdouble.guard : int 0
 $ longdouble.ulp.digits: int -112
 $ longdouble.neg.ulp.digits: int -113
 $ longdouble.exponent  : int 15
 $ longdouble.min.exp   : int -16382
 $ longdouble.max.exp   : int 16384
> 

| capabilities()

> capabilities()
   jpeg pngtiff   tcltk X11aqua 
   TRUETRUETRUETRUE   FALSE   FALSE 
   http/ftp sockets  libxmlfifo  cledit   iconv 
   TRUETRUETRUETRUETRUETRUE 
NLS profmem   cairo ICU long.double libcurl 
   TRUETRUETRUETRUETRUETRUE 
> 

| .Platform

> str(.Platform)
List of 8
 $ OS.type   : chr "unix"
 $ file.sep  : chr "/"
 $ dynlib.ext: chr ".so"
 $ GUI   : chr "X11"
 $ endian: chr "big"
 $ pkgType   : chr "source"
 $ path.sep  : chr ":"
 $ r_arch: chr ""
> 
 
| 2)  Can you send me the  result of rankMatrix(Z, method="qr")
| i.e.  `rnkZ.`  from the above example ?

> library(Matrix)
> Z. <- readRDS(system.file("external", "Z_NA_rnk.rds", package="Matrix"))
> rnkZ. <- rankMatrix(Z., method = "qr")
> rnkZ.
[1] 724
attr(,"method")
[1] "qr.R"
attr(,"useGrad")
[1] FALSE
attr(,"tol")
[1] 3.126388e-13
> 

Graham (in subsequent message) makes a good point about big endian. Maybe we
need a slightly wider net.

It could, as always, of course be something else but related. I could replace
the default BLAS with OpenBLAS etc but ex ante the default BLAS should work :-/

But as you hinted, if we skip that one test on this one architecture it
passes. I used a very minimal diff (below) and quickly rebuilt (by skipping
vignettes as I currently do not have texlive installed on the s390x (but
could add  it)).

(sid_s390x-dchroot)edd@zelenka:/tmp/downloaded_packages$ diff -u 
Matrix{,.orig}/tests/factorizing.R 
--- Matrix/tests/factorizing.R  2021-02-17 13:01:06.511757335 +
+++ Matrix.orig/tests/factorizing.R 2021-01-04 20:32:35.0 +
@@ -472,7 +472,6 @@
 })
 options(oo)
 
-if (Sys.info()[["machine"]] != "s390x") {
 ## problematic rank deficient rankMatrix() case -- only seen in large cases ??
 Z. <- readRDS(system.file("external", "Z_NA_rnk.rds", package="Matrix"))
 tools::assertWarning(rnkZ. <- rankMatrix(Z., method = "qr")) # gave errors
@@ -482,7 +481,6 @@
 oo <- options(warn=2)# no warnings allowed from here
 di <- diag(qrZ.@R)
 stopifnot(is.na(rnkZ.), is(qrZ, "sparseQR"), is.na(rnk2), anyNA(di))
-}
 
 ## The above bug fix was partly wrongly extended to  dense matrices for "qr.R":
 x <- cbind(1, rep(0:9, 18))
(sid_s390x-dchroot)edd@zelenka:/tmp/downloaded_packages$ 



(Obviously the if above could be indentented and all that.)

Graham:  What does that bigendian box say for   Sys.info()[["machine"]]   ?
Should we test for endianness instead?  And then maybe try to roll up to the
cause of the difference?

Dirk


| Best, Martin
| 
| On Mon, Feb 15, 2021 at 5:12 PM Dirk Eddelbuettel  wrote:
| >
| >
| > Martin,
| >
| > I have this long-running bug report against Matrix, triggered by glmmTMB on
| > s390x.  Graham has been chasing this patiently and we 

Bug#982684: marked as done (subversion: frequent FTBFS due to flaky test)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 13:03:42 +
with message-id 
and subject line Bug#982684: fixed in subversion 1.14.1-2
has caused the Debian Bug report #982684,
regarding subversion: frequent FTBFS due to flaky test
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982684: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982684
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
package: src:subversion
version: 1.14.1-1
severity: serious
tags: ftbfs

Hi,

The latest upload of subversion to unstable fails on armhf and mips64el:

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

On the first try, it failed on mipsel as well. Maybe the failing test is
unreliable?


Cheers,

Ivo
--- End Message ---
--- Begin Message ---
Source: subversion
Source-Version: 1.14.1-2
Done: James McCoy 

We believe that the bug you reported is fixed in the latest version of
subversion, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 982...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
James McCoy  (supplier of updated subversion package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 17 Feb 2021 07:46:16 -0500
Source: subversion
Architecture: source
Version: 1.14.1-2
Distribution: unstable
Urgency: medium
Maintainer: James McCoy 
Changed-By: James McCoy 
Closes: 982684
Changes:
 subversion (1.14.1-2) unstable; urgency=medium
 .
   * Temporarily disable testCrash_RequestChannel_nativeRead_AfterException
 (Closes: #982684)
   * rules: Remove clean from .PHONY
Checksums-Sha1:
 8dfd7d1a069a7f808371b21fa2ee170d00e2a36a 3807 subversion_1.14.1-2.dsc
 821a10b4bbe48673569253334ed7c2619485ae88 430180 
subversion_1.14.1-2.debian.tar.xz
Checksums-Sha256:
 d4403b09e1b5c8a0b0bf88b721bf6ad125eac9548393f1717b7853c4b5ba4d35 3807 
subversion_1.14.1-2.dsc
 586fa086bf02350c629db95d0b0ccaefc1bd4b1c4fca0f7c0943a0b395ed726d 430180 
subversion_1.14.1-2.debian.tar.xz
Files:
 14c74a26e8cf71c383babce60f4d194e 3807 vcs optional subversion_1.14.1-2.dsc
 d88611a8755e4b62ddd162b18e63ab2b 430180 vcs optional 
subversion_1.14.1-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQKoBAEBCgCSFiEEkb+/TWlWvV33ty0j3+aRrjMbo9sFAmAtEJZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDkx
QkZCRjRENjk1NkJENURGN0I3MkQyM0RGRTY5MUFFMzMxQkEzREIUHGphbWVzc2Fu
QGRlYmlhbi5vcmcACgkQ3+aRrjMbo9t12Q/+OI2DV9RGSTYmieqVj+LZTeBsU3VX
Y+WPb4MoyHjzp5kiEcaaSsGgqrJZ+arG8DFZ/+8x6QFv4Sk6YyN1lw98E4pah52D
zfStRsLUOspcAjCY526H07aMxQAfHRQiGxn3V7MJ0O7uxPxiBWs0z0svG6FglE/1
y0cBDYhqor+H+bznOJSScOe3O1xP54YAfHMzXDUUrHU+QOZ84m6nLOBHw1uOhv08
21llBkgjf9mexBxlKbBlflqoaLUlTLQg/osah/2DtZaP8udFFr7efdFAnMjb+YSZ
kOfvOV1lLIp6O3sgdFhmJW+ByqfaCRPCRMJrGQmvUtd+4d6ePb/aak0/3cJjTeLr
l+Jplybei22hloZTweHQBZmOvZiu2vmGxi9OZpwQd7uaohl31F/sI51ru6LZGRUN
jQpwiFmed2SwD5PcXYYqCX8MutttIqYeFGJK8Vdu3jODlOhgbOA64HzNE7jPi+gS
8/2oU+sLgUjXrpZeehblr8Dbp7SXaJcTapyhfRWhF9s/3AO2WLT8aB4xb3f/DwY+
kdLXyDdOMh9Ku0E9cpOv8kTXHJc7hzBnZf/ceL65C48ukfXm6s1fog1grHwSVBmj
gNHre4hYdaPgCMEKyXz5qCC4r5gVVr3Rz1VLKEgak4I5/AhbtXuHuRCmnCKz5O36
GBYKUI8BRfqNNbU=
=pACO
-END PGP SIGNATURE End Message ---


Processed: closing 982957

2021-02-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> close 982957 2.7.1+ds2-7
Bug #982957 [src:docker-registry] FTBFS: unsat-dependency: 
golang-github-rsc-letsencrypt-dev:amd64
Ignoring request to alter fixed versions of bug #982957 to the same values 
previously set
Bug #982957 [src:docker-registry] FTBFS: unsat-dependency: 
golang-github-rsc-letsencrypt-dev:amd64
Marked Bug as done
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
982957: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982957
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: notfound 982957 in 2.7.1+ds2-7, found 982957 in 2.7.1+ds2-5, fixed 982957 in 2.7.1+ds2-7

2021-02-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> notfound 982957 2.7.1+ds2-7
Bug #982957 [src:docker-registry] FTBFS: unsat-dependency: 
golang-github-rsc-letsencrypt-dev:amd64
No longer marked as found in versions docker-registry/2.7.1+ds2-7.
> found 982957 2.7.1+ds2-5
Bug #982957 [src:docker-registry] FTBFS: unsat-dependency: 
golang-github-rsc-letsencrypt-dev:amd64
Marked as found in versions docker-registry/2.7.1+ds2-5.
> fixed 982957 2.7.1+ds2-7
Bug #982957 [src:docker-registry] FTBFS: unsat-dependency: 
golang-github-rsc-letsencrypt-dev:amd64
Marked as fixed in versions docker-registry/2.7.1+ds2-7.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
982957: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982957
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: tag patch

2021-02-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 951988 + patch
Bug #951988 [glslang-dev] spirv-tools: spirv.pc is missing required libraries 
in Libs
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
951988: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951988
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#982957: FTBFS: unsat-dependency: golang-github-rsc-letsencrypt-dev:amd64

2021-02-17 Thread Reinhard Tartler
Source: docker-registry
Version: 2.7.1+ds2-7
Severity: serious
Justification: FTBFS

In a rebuild, I noticed that this package fails to build from source:

,
| Install main build dependencies (apt-based resolver)
| 
| 
| Installing build dependencies
| Reading package lists...
| Building dependency tree...
| Reading state information...
| 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:
|  sbuild-build-depends-main-dummy : Depends: golang-github-rsc-letsencrypt-dev 
but it is not installable
| E: Unable to correct problems, you have held broken packages.
| apt-get failed.
| E: Package installation failed
| Not removing build depends: cloned chroot in use
`


Apparently it depends on golang-github-rsc-letsencrypt-dev which is has been
removed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956744


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

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



Bug#982717: udfclient: FTBFS: bmake[1]: no target to make.

2021-02-17 Thread Pali Rohár
On Monday 15 February 2021 18:11:16 Dennis Filder wrote:
> The current bmake backend for debhelper no longer inherits from the
> autoconf backend.  The attached patch devises an override that
> restores the old behaviour, and I've verified that it works.

Hello Dennis! Thank you for investigation and the patch. Will you update
also the package? Or should I do it? Note that I do not have Debian
Developer permissions so I can update new version of package only to
mentors server (which takes a long to appear in Debian archive...).

-- 
Pali Rohár
pali.ro...@gmail.com



Bug#982389: dahdi-dkms: installer package must be in contrib

2021-02-17 Thread Andreas Beckmann
On Sun, 14 Feb 2021 10:10:31 +0200 Tzafrir Cohen 
wrote:
> This script is part of the separate non-free dahdi-firmware
>   package. It should not be part of DAHDI-linux and can be removed
>   if it is. If dahdi-dkms is not co-installable with dahdi-firmware,
>   it is probably a bug.
> 

The download script is
/usr/src/dahdi-DEB_VERSION/drivers/dahdi/firmware/Makefile
which is part of dahdi-dkms

It also gets unpacked from /usr/src/dahdi.tar.bz2 (dahdi-source) as
/usr/src/modules/dahdi/drivers/dahdi/firmware/Makefile

Andreas

PS: please send only plain text emails to the BTS



Bug#982495: marked as done (acpica-unix: FTBFS on mips64el)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 10:03:22 +
with message-id 
and subject line Bug#982495: fixed in acpica-unix 20200925-1.2
has caused the Debian Bug report #982495,
regarding acpica-unix: FTBFS on mips64el
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982495: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982495
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: acpica-unix
Version: 20200925-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

| obj/acpiexamples ../../../source/components/namespace/nswalk.c
| /<>/generate/unix/iasl/obj/aslcompiler.y: In function 
‘AslCompilerparse’:
| /<>/generate/unix/iasl/obj/aslcompiler.y:1094:92: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1094 | | PARSEOP_NAMESTRING{$$ = TrCreateValuedLeafOp 
(PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) $1);}
|   |   
 ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1095:92: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1095 | | PARSEOP_IO{$$ = TrCreateValuedLeafOp 
(PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) "IO");}
|   |   
 ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1096:92: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1096 | | PARSEOP_DMA   {$$ = TrCreateValuedLeafOp 
(PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) "DMA");}
|   |   
 ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1097:92: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1097 | | PARSEOP_IRQ   {$$ = TrCreateValuedLeafOp 
(PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) "IRQ");}
|   |   
 ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1098:92: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1098 | | PARSEOP_FOR   {$$ = TrCreateValuedLeafOp 
(PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) "FOR");}
|   |   
 ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1109:41: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1109 | (ACPI_NATIVE_INT) 
AslCompilerlval.s);}
|   | ^
| /<>/generate/unix/iasl/obj/aslcompiler.y:1482:41: error: cast 
from pointer to integer of different size [-Werror=pointer-to-int-cast]
|  1482 | (ACPI_NATIVE_INT) 
AslCompilerlval.s);}
|   | ^
| obj/acpiexec ../../../source/components/dispatcher/dswload.c

https://buildd.debian.org/status/fetch.php?pkg=acpica-unix=mips64el=20200925-1=1612716867=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Source: acpica-unix
Source-Version: 20200925-1.2
Done: Chris Hofstaedtler 

We believe that the bug you reported is fixed in the latest version of
acpica-unix, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 982...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Chris Hofstaedtler  (supplier of updated acpica-unix package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 17 Feb 2021 09:45:22 +
Source: acpica-unix
Architecture: source
Version: 20200925-1.2
Distribution: unstable
Urgency: medium
Maintainer: Al Stone 
Changed-By: Chris Hofstaedtler 
Closes: 982494 982495
Changes:
 acpica-unix (20200925-1.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Upload to unstable. (Closes: #982495, #982494)

Bug#982494: marked as done (acpica-unix: FTBFS on armhf)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 10:03:22 +
with message-id 
and subject line Bug#982494: fixed in acpica-unix 20200925-1.2
has caused the Debian Bug report #982494,
regarding acpica-unix: FTBFS on armhf
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982494: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982494
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: acpica-unix
Version: 20200925-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

| ++ dpkg-architecture -qDEB_HOST_ARCH_BITS
| + BITS=32
| ++ stat --format=%Y /<>/generate/unix/bin/iasl
| ++ cut '-d ' -f1
| + FDATE=1612117256
| ++ date --date=@1612117256 '+%b %_d %Y'
| + WHEN='Jan 31 2021'
| + sed -e s//20200925/ /<>/debian/badcode.asl.result
| + sed -e s//20200925/ /<>/debian/grammar.asl.result
| + sed -e s//20200925/ 
/<>/debian/converterSample.asl.result
| + /<>/generate/unix/bin/iasl -f badcode.asl
| + tee badcode.asl.actual
| + diff badcode.asl.actual badcode.asl.expected
| + '[' 1 -eq 0 ']'
| + exit 1
| make[2]: *** [Makefile:28: check] Error 1
| make[2]: Leaving directory '/<>'
| make[1]: *** [debian/rules:72: override_dh_auto_test] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:31: build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

See
https://buildd.debian.org/status/fetch.php?pkg=acpica-unix=armhf=20200925-1=1612117350=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Source: acpica-unix
Source-Version: 20200925-1.2
Done: Chris Hofstaedtler 

We believe that the bug you reported is fixed in the latest version of
acpica-unix, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 982...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Chris Hofstaedtler  (supplier of updated acpica-unix package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 17 Feb 2021 09:45:22 +
Source: acpica-unix
Architecture: source
Version: 20200925-1.2
Distribution: unstable
Urgency: medium
Maintainer: Al Stone 
Changed-By: Chris Hofstaedtler 
Closes: 982494 982495
Changes:
 acpica-unix (20200925-1.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Upload to unstable. (Closes: #982495, #982494)
Checksums-Sha1:
 595133dc14ce4dfc9b02ddb7fef76f994e86c2a4 1866 acpica-unix_20200925-1.2.dsc
 3d0f05860f8a9e7b40e3966079365d4f267625ec 66524 
acpica-unix_20200925-1.2.debian.tar.xz
 3f03e14cb5ccff2135dd0d81dde91799ee3f201a 5528 
acpica-unix_20200925-1.2_source.buildinfo
Checksums-Sha256:
 ba16eba08bfa7fc4ec953fb98db8ef24e6d80c1b4fbbb377f8a1a76814ba8c04 1866 
acpica-unix_20200925-1.2.dsc
 22ea719b7303584edd6b10757b80a1ef05b93b14bae0f483250307314866d356 66524 
acpica-unix_20200925-1.2.debian.tar.xz
 6e2ab75ad581d4e5238eabce27898c92268ce1643a14d2823cca60574fde3d56 5528 
acpica-unix_20200925-1.2_source.buildinfo
Files:
 fd535de47bd09f5320ee5995dd178b57 1866 devel optional 
acpica-unix_20200925-1.2.dsc
 4ad50058565619f3b0eee5f1e741bd49 66524 devel optional 
acpica-unix_20200925-1.2.debian.tar.xz
 6a2066246870118dfbb7f884cf11d931 5528 devel optional 
acpica-unix_20200925-1.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfRrP+tnggGycTNOSXBPW25MFLgMFAmAs5ggACgkQXBPW25MF
LgMkGg/7Bk8r7rcsnK15U4cusp9GIXR3i/8TQ/bPI5Do7HEmmodHKX21zkSJp+jK
Jbfy9Mr0FCO1m7jkLOiQx/6tnA4MTvunQizGEMffoQrR6bSA6hhMR5wuW1OKHHiM
B3kdgRX+T1KF4/KQr267s891bWIguR+SqGhNbqYdnP9vpkQE7RLSI1Y6NoqJXT6u
/jDH0LnAUbGPmgw2JoeU2XKIJ3gINjpP8zy3PCAQeV1hWgpuRcrZVSBB/PY2P16d
g2wwgx1nSwcym362ifsKNe7Y8DS/J/yR9hGouZaya9O1mv1ufR9YoRyhvjDT7Q6l
DJQozZLyCRa5ZLndwlfe32/bSqpthUg1ufh23z6J6GDwH5ZFnTq2j/8VtZAJ9sJZ
kFYIx7niSkKc9UUn+Hv3n/4a5yGohKvq8VX+8lO6Z9XOYPSY039gf9jW3lBBPo+Q
Skm/s2dLLJCfbxjZ9acx7Bu8W2euFNQlqq2TcM1WRnQ0+dOm75D7+Sqq1UW24yvm
LWEGtB5EHqsYOXx1ODhnYIXmgdgQCbZz+0LEWuewc0xzMA5fEEoLwbwGNyCY021k
p7VyD7kEAVvB07sZp3d0fngSf9tee/39LbxxwyG3/cNohuAWezJE/IR1kVpkgzyy
3eVa0j/mJtcfaBjPxvfO+PwHSEyBP4exBQ/12qEnZH1Nl7Vo7qo=
=wm+4

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

2021-02-17 Thread Graham Inggs
Hi Martin

On Wed, 17 Feb 2021 at 11:45, Martin Maechler  wrote:
> 1)  I think I might simply disable the check  *on* that platform .. or
> platforms with similar characteristics.

I was able to reproduce the issue on our big-endian PowerPC
architecture as well, so maybe you can use the following in your
check:

> .Platform$endian
[1] "big"

Regards
Graham



Processed: fixed 982495 in 20200925-1.1, fixed 982494 in 20200925-1.1

2021-02-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> fixed 982495 20200925-1.1
Bug #982495 [src:acpica-unix] acpica-unix: FTBFS on mips64el
Marked as fixed in versions acpica-unix/20200925-1.1.
> fixed 982494 20200925-1.1
Bug #982494 [src:acpica-unix] acpica-unix: FTBFS on armhf
Marked as fixed in versions acpica-unix/20200925-1.1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
982494: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982494
982495: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982495
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

2021-02-17 Thread Martin Maechler
Dear Dirk,
I'm in vacations right now ...

1)  I think I might simply disable the check  *on* that platform .. or
platforms with similar characteristics.
Can you send me the outputs of  so I can take some of the entries to
determine I'm on the platform?

sessionInfo()
str(.Machine, digits=10)
capabilities()
.Platform

2)  Can you send me the  result of rankMatrix(Z, method="qr")
i.e.  `rnkZ.`  from the above example ?

Best, Martin

On Mon, Feb 15, 2021 at 5:12 PM Dirk Eddelbuettel  wrote:
>
>
> Martin,
>
> I have this long-running bug report against Matrix, triggered by glmmTMB on
> s390x.  Graham has been chasing this patiently and we are now at the level of
> checking on a shell account on the appropriate hardware.
>
> We validated that everything does in fact "still break" with CRAN-current
> packages of everything (and R 4.0.3, I guess by tomorrow we'd have 4.0.4).
>
> glmmTMB does indeed fail in an example -- but so does Matrix 1.3-2 when I run
>
>   _R_CHECK_FORCE_SUGGESTS_=false R CMD check \
>  --no-manual --no-vignettes Matrix_1.3-2.tar.gz
>
> and I see
>
>   [...]
>   Running 'factorizing.R'
>  ERROR
> Running the tests in 'tests/factorizing.R' failed.
> Last 13 lines of output:
>   + inherits(qrZ, "sparseQR")
>   + inherits(Rz, "sparseMatrix")
>   + isTriangular(Rz)
>   + isDiagonal(Rz) # even though formally a "dtCMatrix"
>   + qr2rankMatrix(qrZ, do.warn=FALSE) == 6
>   + })
>   > options(oo)
>   >
>   > ## problematic rank deficient rankMatrix() case -- only seen in large 
> cases ??
>   > Z. <- readRDS(system.file("external", "Z_NA_rnk.rds", package="Matrix"))
>   > tools::assertWarning(rnkZ. <- rankMatrix(Z., method = "qr")) # gave errors
>   Error in assertCondition(expr, classes, .exprString = d.expr) :
> Failed to get warning in evaluating rnkZ. <- rankMatrix(Z., method  ...
>   Calls:  -> assertCondition
>   Execution halted
> * checking for unstated dependencies in vignettes ... OK
>
> Can you advise if I should dive into a particular routine or comparison to
> see what is up here?
>
> Best,  Dirk
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>


-- 
Martin Maechler,
Seminar fuer Statistik, ETH Zurich



Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target

2021-02-17 Thread Colin Watson
Control: severity -1 important

On Wed, Feb 17, 2021 at 09:36:15AM +0100, Thomas Goirand wrote:
> Package: openssh-server
> Version: 1:8.4p1-4
> Severity: grave

No.  It may yet need to be sorted out before release, but this is a rare
situation and I'm not having it being release-critical right now,
especially because it's not clear that it's openssh-server's problem.

> On a Sid/Testing system, currently we have in /lib/systemd/system/ssh.service:
> 
> After=network.target auditd.service
> 
> While this isn't a problem in most installation, it didn't work under our 
> setup,
> because we use "bgp-to-the-host" networking. In this setup, we need FRR (the
> BGP routing daemon which is a fork of Quagga, if you didn't know) to provide
> network connectivity to the server. Our configuration is something like this:
> 
> # cat /etc/frr/frr.conf
> [...]
> !
> int lo
>  ip address 10.56.17.7/32
> !
> [...]
> 
> This means that, until FRR is fully up and running, with the BGP session
> established, the server IP (10.x.x.x/32 bound to the loopback interface) isn't
> set yet on the server, and the ssh daemon cannot bind on the IP (as it's not
> there yet).

Are you using ListenAddress in sshd_config?  Normally sshd doesn't
require network interfaces to be online - it just binds to 0.0.0.0 or
[::] and that's enough for it to be bound to interfaces as they come up.

If lo has to be up for this to work (which is surprising to me, but
maybe), then I think there's a decent argument for frr to be part of
network.target on such systems.

> Our fix was pretty simple:
> 
> # cat /etc/systemd/system/ssh.service.d/override.conf 
> [Unit]
> After=network-online.target auditd.service
> 
> But IMO, this is very wrong to mandate doing this, and not having ssh
> connectivity after a reboot, is kind of a grave problem.
> 
> So, could you hard-wire this in the openssh-server package directly, so Debian
> users can avoid such an override? Indeed After=network.target doesn't tell you
> that network is ready. After=network-online.target does, and that's IMO what
> the ssh daemon should be using.

I don't agree that network-online.target is appropriate in general, from
its documentation:

   network-online.target
   Units that strictly require a configured network connection
   should pull in network-online.target (via a Wants= type
   dependency) and order themselves after it. This target unit
   is intended to pull in a service that delays further
   execution until the network is sufficiently set up. What
   precisely this requires is left to the implementation of
   the network managing service.

   Note the distinction between this unit and network.target.
   This unit is an active unit (i.e. pulled in by the consumer
   rather than the provider of this functionality) and pulls
   in a service which possibly adds substantial delays to
   further execution. In contrast, network.target is a passive
   unit (i.e. pulled in by the provider of the functionality,
   rather than the consumer) that usually does not delay
   execution much. Usually, network.target is part of the boot
   of most systems, while network-online.target is not, except
   when at least one unit requires it. Also see Running
   Services After the Network is up[1] for more information.

sshd does not in general require a configured network connection just to
start up, and making it do so would be a pretty significant change to
the unit dependency graph on most systems; it would make "is not [part
of the boot process]" above typically untrue, for one thing.

See also
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/, which
among other things (in general the tone of that page is that a
well-written service should not use After=network-online.target) says:

  "If you write a server: listen on [::], [::1], 0.0.0.0 and 127.0.0.1
  only.  These pseudo-addresses are unconditionally available."

That's what sshd does in its default configuration.  If it doesn't work,
the systemd documentation suggests that something else is not fulfilling
its end of a contract somewhere.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]



Processed: Re: Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target

2021-02-17 Thread Debian Bug Tracking System
Processing control commands:

> severity -1 important
Bug #982950 [openssh-server] ssh.service starts sshd before network is online: 
please switch to After=network-online.target instead of just 
After=network.target
Severity set to 'important' from 'grave'

-- 
982950: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982950
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#982757: firmware-brcm80211: [REGRESSION] brcm/brcmfmac43340-sdio.bin missing in sid (20210208-1)

2021-02-17 Thread Andreas Henriksson
On Tue, Feb 16, 2021 at 11:46:26PM +0100, maximilian attems wrote:
> > Actually I think the problem is this commit:
> > https://salsa.debian.org/kernel-team/firmware-nonfree/-/commit/9c597cb850e77c2bff39378503849a92ff522353
> 
> this commit is just fine, the debian package just needs to have the
> corresponding symlinks to the newer version.

FYI I've now tested reverting that commit and the symlinks are back:

Here's the sid vs sid+revert binary package content (files) diff:

--- fbr-sid-files.txt   2021-02-17 09:39:13.679336856 +0100
+++ fbr-sid-rev9c597cb850e7-files.txt   2021-02-17 10:00:12.730055901 +0100
@@ -63,4 +63,13 @@
 ./usr/share/doc/firmware-brcm80211/copyright
 ./usr/share/metainfo/
 ./usr/share/metainfo/firmware-brcm80211.metainfo.xml
+./lib/firmware/brcm/brcmfmac43340-sdio.bin
+./lib/firmware/brcm/brcmfmac43362-sdio.bin
+./lib/firmware/brcm/brcmfmac4339-sdio.bin
+./lib/firmware/brcm/brcmfmac43430-sdio.bin
+./lib/firmware/brcm/brcmfmac43455-sdio.bin
+./lib/firmware/brcm/brcmfmac4354-sdio.bin
+./lib/firmware/brcm/brcmfmac4356-pcie.bin
 ./lib/firmware/brcm/brcmfmac4356-sdio.bin
+./lib/firmware/brcm/brcmfmac43570-pcie.bin
+./lib/firmware/brcm/brcmfmac4373-sdio.bin

And yes, they are all symlinks... eg from the patched/rebuilt package:
$ dpkg -c patched/firmware-brcm80211_20210208-1_all.deb | grep 
brcmfmac43340-sdio
lrwxrwxrwx root/root 0 2021-02-17 09:58 
./lib/firmware/brcm/brcmfmac43340-sdio.bin -> ../cypress/cyfmac43340-sdio.bin




Note also that this is definitely not a general problem with symlinks
as even the existing package in sid has atleast one symlink in it still:

$ dpkg -c sid/firmware-brcm80211_20210208-1_all.deb  | grep -- '->'
lrwxrwxrwx root/root 0 2021-02-09 11:15 
./lib/firmware/brcm/brcmfmac4356-sdio.bin -> ../cypress/cyfmac4356-sdio.bin


The problem is simply that the symlinks are being installed into
debian/build/install/ but then they are not moved over to the
debian/firmware-brcm80211 directory to be included in the binary package.
It might be helpful to improve the packaging logic so files are /moved/
from debian/build/install/ into the respective binary package directory
and then fail the build if debian/build/install/ still contains anything
(ie. similar to --fail-missing in generic dh packages).

Regards,
Andreas Henriksson



Bug#982921: marked as done (python3-packaging: missing dependency on python3-distutils)

2021-02-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Feb 2021 08:48:30 +
with message-id 
and subject line Bug#982921: fixed in python-packaging 20.9-2
has caused the Debian Bug report #982921,
regarding python3-packaging: missing dependency on python3-distutils
to be marked as done.

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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982921: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982921
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: python3-packaging
Version: 20.9-1
Severity: serious
Justification: Policy 3.5

Dear Maintainer,

python3-packaging needs python3-distutils to work correctly:

Traceback (most recent call last):
  […]
from packaging.specifiers import SpecifierSet
  File "/usr/lib/python3/dist-packages/packaging/specifiers.py", line 14, in 

from .utils import canonicalize_version
  File "/usr/lib/python3/dist-packages/packaging/utils.py", line 9, in 
from .tags import Tag, parse_tag
  File "/usr/lib/python3/dist-packages/packaging/tags.py", line 7, in 
import distutils.util
ModuleNotFoundError: No module named 'distutils.util'


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

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

Versions of packages python3-packaging depends on:
ii  python33.9.1-1
ii  python3-pyparsing  2.4.7-1

python3-packaging recommends no packages.

python3-packaging suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: python-packaging
Source-Version: 20.9-2
Done: Matthias Klose 

We believe that the bug you reported is fixed in the latest version of
python-packaging, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 982...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Matthias Klose  (supplier of updated python-packaging package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 17 Feb 2021 09:20:20 +0100
Source: python-packaging
Architecture: source
Version: 20.9-2
Distribution: unstable
Urgency: medium
Maintainer: Matthias Klose 
Changed-By: Matthias Klose 
Closes: 982921
Changes:
 python-packaging (20.9-2) unstable; urgency=medium
 .
   * Use sysconfig.get_platform instead of distutils.util.get_platform.
 Closes: #982921.
Checksums-Sha1:
 c6902b39d04f279b3435ac5f05fbd8251c9c3cde 2034 python-packaging_20.9-2.dsc
 c7372520aaf85a04ce9e5ff62e9af68b84b135fb 4092 
python-packaging_20.9-2.debian.tar.xz
 4278de40f9b67a88f8ec332ae45094101ec80c85 7452 
python-packaging_20.9-2_source.buildinfo
Checksums-Sha256:
 6caeba2bab079974781b8d2125cdeabe7210d62c7cbf97e166685a6dffa6fccb 2034 
python-packaging_20.9-2.dsc
 3053f1a2de5512047a245ed4db08682cdceb8a89bd03ce8586775a9403b60d5b 4092 
python-packaging_20.9-2.debian.tar.xz
 39173e43d67bb7f516bdcd5c2f696eaa5e1b03d685dfded1281a5d7e3a688adc 7452 
python-packaging_20.9-2_source.buildinfo
Files:
 719f526d4cfd1abaa1162c78f7e32ac3 2034 python optional 
python-packaging_20.9-2.dsc
 cfa78704e87a995899f56d84c06a24e4 4092 python optional 
python-packaging_20.9-2.debian.tar.xz
 d16ec9766f5a8ead14077342b9802763 7452 python optional 
python-packaging_20.9-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE1WVxuIqLuvFAv2PWvX6qYHePpvUFAmAs01UQHGRva29AZGVi
aWFuLm9yZwAKCRC9fqpgd4+m9ZNSD/0Xg4QkyEgGqfzZNXCYtjpHDGFbXif0BWor
DrcDCUztCByNqXOZWLZMSXT6kA68YX6N/le4tHi/KdU1s3JUSk3D5EfwMOx0FWD9
aX1eZXmnHklkG+wG+/SqIV331Z4rpfU/hTHuvVfm2lVrJfiUgqO3oYgBRAVmegXe
h5kohOaePD9ELGVl6JypGcfAlXOtUlzWB93eCwEp0aUR2jsdAzRcavfDzs67U8VC
AfNFIj82twjaSCI5P6Oc+W2NC/QBkoQsND72WWYULJe4QIb7JKiT4jOIlnY8V5bI
xtptnd0LjvuHiZ6ACLJGydyr/5R6olW4epfozK4r4irEQhNOQo+M4ksTJGTDdAVi
1yuDN8hML0gS9F8ZoON3xaAWRDI9OWBfg3EeoIFj4zONxIkP7HbbkEAxsNz4ys8u
3qlG3Z+WP9d66u2JKY1aBFm66Eug3yKdajvrFBC18/Joi4QOxxTw0GufUBeFCEvE
nxY4UZkEGh388dAmSz3WUPgXvDMbiq82oMX4w4WaepPpoY7qHLITs4kfrT5eKyU3
FnGmLZnPnNaswO5xVLHg/zmU7ByYhAAZanaB5H2Wk9LYi8qce1uj1OD0VA1HjsRL

Bug#982914: marked as done (chai: broken-symlink /usr/share/doc/chai -> libjs-chai, missing-copyright-file)

2021-02-17 Thread Willy nilly
close #982914

On Wed, Feb 17, 2021 at 6:51 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Wed, 17 Feb 2021 06:49:35 +
> with message-id 
> and subject line Bug#982914: fixed in node-chai 4.2.0+ds+~4.2.14-3
> has caused the Debian Bug report #982914,
> regarding chai: broken-symlink /usr/share/doc/chai -> libjs-chai,
> missing-copyright-file
> to be marked as done.
>
> 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.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 982914: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982914
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Thorsten Glaser 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Tue, 16 Feb 2021 14:15:55 +0100
> Subject: chai: broken-symlink /usr/share/doc/chai -> libjs-chai,
> missing-copyright-file
> Package: chai
> Version: 4.2.0+ds+~4.2.14-2
> Severity: serious
> Justification: Policy 2.3
> User: debian...@lists.debian.org
> Usertags: adequate broken-symlink missing-copyright-file
> X-Debbugs-Cc: t...@mirbsd.de
>
> chai: broken-symlink /usr/share/doc/chai -> libjs-chai
> chai: broken-symlink /usr/share/nodejs/chai/dist -> ../../javascript/chai
> chai: missing-copyright-file /usr/share/doc/chai/copyright
>
> And indeed:
>
> $ ll -d /usr/share/doc/chai /usr/share/doc/libjs-chai
> ls: cannot access '/usr/share/doc/libjs-chai': No such file or directory
> lrwxrwxrwx 1 root root 10 Feb 16 07:05 /usr/share/doc/chai -> libjs-chai
>
> /usr/share/doc/PKGNAME can only ever be a symlink to another
> binary package’s if the other binary package is built from
> the same source *and* version, AND if the link target’s package
> is a Depends.
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500,
> 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1,
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/lksh
> Init: sysvinit (via /sbin/init)
>
> Versions of packages chai depends on:
> ii  node-assertion-error  1.1.0-1
> ii  node-check-error  1.0.2-3
> ii  node-deep-eql 4.0.0-4
> ii  node-get-func-name2.0.0+dfsg-1.1
> ii  node-pathval  1.1.1-1
> ii  node-type-detect  4.0.8-2
> ii  nodejs12.20.2~dfsg-2
>
> chai recommends no packages.
>
> chai suggests no packages.
>
> -- no debconf information
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 982914-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 17 Feb 2021 06:49:35 +
> Subject: Bug#982914: fixed in node-chai 4.2.0+ds+~4.2.14-3
> Source: node-chai
> Source-Version: 4.2.0+ds+~4.2.14-3
> Done: Yadd 
>
> We believe that the bug you reported is fixed in the latest version of
> node-chai, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 982...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Yadd  (supplier of updated node-chai package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Wed, 17 Feb 2021 07:28:36 +0100
> Source: node-chai
> Architecture: source
> Version: 4.2.0+ds+~4.2.14-3
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Javascript Maintainers <
> pkg-javascript-de...@lists.alioth.debian.org>
> Changed-By: Yadd 
> Closes: 982914
> Changes:
>  node-chai (4.2.0+ds+~4.2.14-3) unstable; urgency=medium
>  .
>* Team upload
>* Remove link between chai and libjs-chai (Closes: #982914)
>* Declare compliance with policy 4.5.1
>* Add ctype=nodejs to component(s)
> Checksums-Sha1:
>  58a335008bf256a004efc0b5ea640b09e7afcf43 2616
> node-chai_4.2.0+ds+~4.2.14-3.dsc
>  b9534bb6ea2d178822096d1913d5c1617cb669a8 7280
> node-chai_4.2.0+ds+~4.2.14-3.debian.tar.xz
> Checksums-Sha256:
>  777142d9aa9c20eab7cc66f2aa806e2fe41760e3b1f1b195a57d7e04614ee905 2616
> 

Bug#982622: marked as done (r-cran-matrixstats might need Breaks: r-bioc-matrixgenerics (<< 1.2.1))

2021-02-17 Thread Willy nilly
close #982622

On Wed, Feb 17, 2021 at 7:09 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Wed, 17 Feb 2021 07:04:35 +
> with message-id 
> and subject line Bug#982622: fixed in r-cran-matrixstats 0.58.0-2
> has caused the Debian Bug report #982622,
> regarding r-cran-matrixstats might need Breaks: r-bioc-matrixgenerics (<<
> 1.2.1)
> to be marked as done.
>
> 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.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 982622: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982622
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Adrian Bunk 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 12 Feb 2021 17:21:54 +0200
> Subject: r-cran-matrixstats might need Breaks: r-bioc-matrixgenerics (<<
> 1.2.1)
> Package: r-cran-matrixstats
> Version: 0.58.0-1
> Severity: serious
>
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-matrixgenerics/10405220/log.gz
>
> ...
> > test_check("MatrixGenerics")
> ══ Failed tests
> 
> ── Failure (test-api_compatibility.R:89:2): colAvgsPerRowSet works
> 
> `matrixStats_formals` not identical to
> `MatrixGenerics_default_method_formals`.
> Names: 1 string mismatch
> Length mismatch: comparison on first 7 components
> Component 7: 'is.NA' value mismatch: 0 in current 1 in target
> ── Error (test-api_compatibility.R:360:2): colMads works
> ──
> Error: Argument 'center' should be of the same length as number of columns
> of 'x': 6 != 8
> Backtrace:
> █
>  1. ├─MatrixGenerics::colMads(...) test-api_compatibility.R:360:8
>  2. └─MatrixGenerics::colMads(...)
>  3.   └─MatrixGenerics:::.local(...)
>  4. └─matrixStats::colMads(...)
> ── Error (test-api_compatibility.R:593:2): colSds works
> ───
> Error: Argument 'center' should be of the same length as number of columns
> of 'x': 6 != 8
> Backtrace:
> █
>  1. ├─MatrixGenerics::colSds(...) test-api_compatibility.R:593:8
>  2. └─MatrixGenerics::colSds(...)
>  3.   └─MatrixGenerics:::.local(x, rows, cols, na.rm, center, ...)
>  4. └─matrixStats::colSds(...)
>  5.   └─matrixStats::colVars(...)
> ── Error (test-api_compatibility.R:678:2): colVars works
> ──
> Error: Argument 'center' should be of the same length as number of columns
> of 'x': 6 != 8
> Backtrace:
> █
>  1. ├─MatrixGenerics::colVars(...) test-api_compatibility.R:678:8
>  2. └─MatrixGenerics::colVars(...)
>  3.   └─MatrixGenerics:::.local(x, rows, cols, na.rm, center, ...)
>  4. └─matrixStats::colVars(...)
> ── Error (test-api_compatibility.R:698:2): colWeightedMads works
> ──
> Error: Argument 'center' should be of the same length as number of columns
> of 'x': 1 != 6
> Backtrace:
> █
>  1. ├─MatrixGenerics::colWeightedMads(...) test-api_compatibility.R:698:8
>  2. └─MatrixGenerics::colWeightedMads(...)
>  3.   └─matrixStats::colWeightedMads(...)
> ── Failure (test-api_compatibility.R:856:2): rowAvgsPerColSet works
> ───
> `matrixStats_formals` not identical to
> `MatrixGenerics_default_method_formals`.
> Names: 1 string mismatch
> Length mismatch: comparison on first 7 components
> Component 7: 'is.NA' value mismatch: 0 in current 1 in target
> ── Error (test-api_compatibility.R:1127:2): rowMads works
> ─
> Error: Argument 'center' should be of the same length as number of rows of
> 'x': 16 != 12
> Backtrace:
> █
>  1. ├─MatrixGenerics::rowMads(...) test-api_compatibility.R:1127:8
>  2. └─MatrixGenerics::rowMads(...)
>  3.   └─MatrixGenerics:::.local(...)
>  4. └─matrixStats::rowMads(...)
> ── Error (test-api_compatibility.R:1360:2): rowSds works
> ──
> Error: Argument 'center' should be of the same length as number of rows of
> 'x': 16 != 12
> Backtrace:
> █
>  1. ├─MatrixGenerics::rowSds(...) test-api_compatibility.R:1360:8
>  2. └─MatrixGenerics::rowSds(...)
>  3.   └─MatrixGenerics:::.local(x, rows, cols, na.rm, center, ...)
>  4. └─matrixStats::rowSds(...)
>  5.   └─matrixStats::rowVars(...)
> ── Error (test-api_compatibility.R:1445:2): rowVars works
> ─
> Error: Argument 'center' should be of the same length as number of rows of
> 'x': 16 != 12
> Backtrace:
> █
>  1. ├─MatrixGenerics::rowVars(...) test-api_compatibility.R:1445:8
>  2. └─MatrixGenerics::rowVars(...)
>  3.   └─MatrixGenerics:::.local(x, rows, cols, na.rm, center, ...)
>  4. └─matrixStats::rowVars(...)
> ── Error 

Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target

2021-02-17 Thread Thomas Goirand
Package: openssh-server
Version: 1:8.4p1-4
Severity: grave

Hi there,

On a Sid/Testing system, currently we have in /lib/systemd/system/ssh.service:

After=network.target auditd.service

While this isn't a problem in most installation, it didn't work under our setup,
because we use "bgp-to-the-host" networking. In this setup, we need FRR (the
BGP routing daemon which is a fork of Quagga, if you didn't know) to provide
network connectivity to the server. Our configuration is something like this:

# cat /etc/frr/frr.conf
[...]
!
int lo
 ip address 10.56.17.7/32
!
[...]

This means that, until FRR is fully up and running, with the BGP session
established, the server IP (10.x.x.x/32 bound to the loopback interface) isn't
set yet on the server, and the ssh daemon cannot bind on the IP (as it's not
there yet).

Our fix was pretty simple:

# cat /etc/systemd/system/ssh.service.d/override.conf 
[Unit]
After=network-online.target auditd.service

But IMO, this is very wrong to mandate doing this, and not having ssh
connectivity after a reboot, is kind of a grave problem.

So, could you hard-wire this in the openssh-server package directly, so Debian
users can avoid such an override? Indeed After=network.target doesn't tell you
that network is ready. After=network-online.target does, and that's IMO what
the ssh daemon should be using.

Thanks for maintaining openssh in Debian,
Cheers,

Thomas Goirand (zigo)



Bug#945317: xcftools NMU for CVE-2019-5086 and CVE-2019-5087

2021-02-17 Thread Moritz Muehlenhoff
On Wed, Feb 17, 2021 at 08:31:22AM +0100, Hugo Lefeuvre wrote:
> Do you know if xcftools is only used as a build dependency, or is
> it used by some end users directly? The popcon is not that low
> and my fear is that, even after removing it from Debian, users
> would continue to use it, installing from somewhere else,
> effectively being at even higher risk than with the Debian
> archive's (semi-) patched version.

The risk seems quite low; xcftools can't handle the XCF files
generated by the Gimp version in Buster:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930525

Cheers,
Moritz