Bug#926719: SFTP ProFTPD terminating (signal 11) after Update to 1.3.5e-0+deb8u1

2019-04-11 Thread Ghislain Adnet




Could you send me your sftp configuration snippet for proftpd and tell
me more about your setup? How can you connect via command-line sftp but
not via filezilla?


i use the unmodified package with this sftp configuration


  

SFTPEngine on

AllowOverwrite  on
RequireValidShell   off

# Configure the server to listen on the normal SSH2 port, port 22
Port 2221


SFTPHostKey /etc/ssh/ssh_host_rsa_key
SFTPHostKey /etc/ssh/ssh_host_dsa_key

SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys

SFTPCompression delayed

MaxLoginAttempts 6
DefaultRoot ~
Umask 0026 0027

  



as i said numerous customer reported issues connecting in sftp following the upgrade. We had to rollback and everything 
worked again. Client used where :filezilla and dreamweaver, both up to date.


my command line client ( command SFTP) on ubuntu 18.04 was able to connect but not fillezilla. After rollback to 
previous version both client worked. The new version On debian 9 it works, but on debian 8 it fails.



Ghis.



Bug#923723: Acknowledgement (linux: amdgpu/radeon driver optimization is broken on ARM/arm64)

2019-04-11 Thread Ard Biesheuvel
The patch has been backported, and was released as part of v4.19.29



Bug#926784: firehol: Please document usage of iptables-legacy

2019-04-11 Thread Jerome BENOIT
Hello, thanks for your reports and the patch.

On 10/04/2019 21:29, Libor Klepáč wrote:
> Hi,
> usage of -legacy variant can be patched in during build time.

Indeed. But the question is rather why we should favour the legacy version over 
the default one.

> 
> Included patch tested by manual running (i don't have disk space to install 
> tex) of: 
> ./autogen.sh && ./configure && make 
> 
> and checking generated ./sbin/install.conf

I do not like the patch because it shortcuts update-alternative,
namely the choice made by the user.

Cheers,
Jerome

> 
> 
> Libor
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature


Bug#926784: firehol: Please document usage of iptables-legacy

2019-04-11 Thread Jerome BENOIT
Hello, thanks for your report.

On 10/04/2019 13:10, Libor Klepáč wrote:
> Package: firehol
> Version: 3.1.6+ds-7
> Severity: wishlist
> 
> Hi,
> firehol seems to have problem to reread rules in nofast mode when using 
> iptables-nft.
> See: https://github.com/firehol/firehol/issues/352
> 
> Here is part of output, it goes on to ERROR : # 30
> # firehol nofast try  
> FireHOL: Saving active firewall to a temporary file...  OK 
> FireHOL: Processing file '/etc/firehol/firehol.conf'...  OK  (522 iptables 
> rules)
> FireHOL: Activating ipsets...  OK 
> FireHOL: Activating new firewall (522 rules)... 
> 
> - 
> 
> ERROR   : # 1.
> WHAT: A runtime command failed to execute (returned error 1).
> SOURCE  : 30@/etc/firehol/firehol.conf: blacklist4:
> COMMAND : /usr/sbin/iptables -t filter -N BLACKLIST.bi.1.in 
> OUTPUT  : 
> 
> iptables v1.8.2 (nf_tables): Chain already exists
> - 
> 
> ERROR   : # 2.
> WHAT: A runtime command failed to execute (returned error 1).
> SOURCE  : 30@/etc/firehol/firehol.conf: blacklist4:
> COMMAND : /usr/sbin/iptables -t filter -N BLACKLIST.bi.1.out 
> OUTPUT  : 
> 
> iptables v1.8.2 (nf_tables): Chain already exists
> - 
> 
> 
> It can be solved by using iptables-legacy.
> 
> Can you please document this in NEWS entry?
> Users of firehol should run
> # update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
> # update-alternatives --set iptables /usr/sbin/iptables-legacy
> 
> Thanks,
> Libor
> 
> 


Have you try to reboot your box ?

Jerome


-- 
Jerome BENOIT, Ph.D. | jgmbenoit-at+rezozer*dot_net
https://www.rezozer.net/

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature


Bug#926912: ITP: redasm -- OpenSource Disassembler

2019-04-11 Thread Gürkan Myczko

Package: wnpp
Severity: wishlist

* Package name: redasm
  Version : 2.0+git20190412
  Upstream Authors: Antonio Davide
* URL : https://redasm.io/
* License : GPL-3+
  Description : OpenSource Disassembler
 This is an interactive, multiarchitecture disassembler written in 
modern
 C++11 using Qt5 as UI Framework, its core is modular and it can be 
easily

 extended in order to support new file formats and instruction sets.

Package will be availabe at http://phd-sid.ethz.ch/debian/redasm/



Bug#926911: unblock: epsilon/0.7.1-1.1

2019-04-11 Thread Tobias Frost
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package epsilon, the NMU fixes #924650

Debdiff attached.

unblock epsilon/0.7.1-1.1

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru epsilon-0.7.1/debian/changelog epsilon-0.7.1/debian/changelog
--- epsilon-0.7.1/debian/changelog  2015-10-10 17:43:41.0 +0200
+++ epsilon-0.7.1/debian/changelog  2019-04-06 12:38:25.0 +0200
@@ -1,3 +1,10 @@
+epsilon (0.7.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from BTS to fix, thanks doko for the patch (Closes: #924650)
+
+ -- Tobias Frost   Sat, 06 Apr 2019 12:38:25 +0200
+
 epsilon (0.7.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru epsilon-0.7.1/debian/patches/kernel-4.18-diskstats.diff 
epsilon-0.7.1/debian/patches/kernel-4.18-diskstats.diff
--- epsilon-0.7.1/debian/patches/kernel-4.18-diskstats.diff 1970-01-01 
01:00:00.0 +0100
+++ epsilon-0.7.1/debian/patches/kernel-4.18-diskstats.diff 2019-04-06 
12:16:28.0 +0200
@@ -0,0 +1,13 @@
+--- a/epsilon/scripts/benchmark.py
 b/epsilon/scripts/benchmark.py
+@@ -46,6 +46,10 @@ def parseDiskStatLine(L):
+ appropriate record type (either L{partitionstat} or L{diskstat}).
+ """
+ parts = L.split()
++# https://www.kernel.org/doc/Documentation/ABI/testing/procfs-diskstats
++# ignore new diskstat values
++if len(parts) == 18:
++parts = parts[:-4]
+ device = parts[2]
+ if len(parts) == 7:
+ factory = partitionstat
diff -Nru epsilon-0.7.1/debian/patches/series 
epsilon-0.7.1/debian/patches/series
--- epsilon-0.7.1/debian/patches/series 2015-10-10 17:43:41.0 +0200
+++ epsilon-0.7.1/debian/patches/series 2019-04-06 12:16:28.0 +0200
@@ -1 +1,2 @@
 0001-Gracefully-handle-not-finding-working-directory.patch
+kernel-4.18-diskstats.diff


Bug#921772: CVE-2018-1000652

2019-04-11 Thread tony mancill
On Fri, Feb 08, 2019 at 11:37:20PM +0100, Moritz Muehlenhoff wrote:
> Package: jabref
> Severity: grave
> Tags: security
> 
> This was assigned CVE-2018-1000652:
> https://github.com/JabRef/jabref/issues/4229
> https://github.com/JabRef/jabref/commit/89f855d76713b4cd25ac0830c719cd61c511851e

Hello Moritz,

Attached is a debdiff to address this CVE in stretch.  Please let me
know how/whether you'd like to proceed.  (I could prepare an upload for
stretch-pu instead if that's preferable.)


I have built the binary and tested locally and everything appears to be
working as expected.

Thanks to Gregor putting this together.

Cheers,
tony
diff -Nru jabref-3.8.1+ds/debian/changelog jabref-3.8.1+ds/debian/changelog
--- jabref-3.8.1+ds/debian/changelog2017-01-11 12:27:19.0 -0800
+++ jabref-3.8.1+ds/debian/changelog2019-02-10 11:25:26.0 -0800
@@ -1,3 +1,12 @@
+jabref (3.8.1+ds-3+deb9u1) stretch-security; urgency=medium
+
+  [ gregor herrmann & tony mancill ]
+  * Add patch from upstream commit to fix CVE-2018-1000652: XML External
+Entity attack.
+Thanks to Moritz Muehlenhoff for the bug report. (Closes: #921772)
+
+ -- gregor herrmann   Sun, 10 Feb 2019 20:25:26 +0100
+
 jabref (3.8.1+ds-3) unstable; urgency=medium
 
   * Remove postgresql entry from debian/maven.rules.
diff -Nru 
jabref-3.8.1+ds/debian/patches/100_CVE-2018-1000652_XXE-vulnerability.patch 
jabref-3.8.1+ds/debian/patches/100_CVE-2018-1000652_XXE-vulnerability.patch
--- jabref-3.8.1+ds/debian/patches/100_CVE-2018-1000652_XXE-vulnerability.patch 
1969-12-31 16:00:00.0 -0800
+++ jabref-3.8.1+ds/debian/patches/100_CVE-2018-1000652_XXE-vulnerability.patch 
2019-02-10 11:25:26.0 -0800
@@ -0,0 +1,81 @@
+From 89f855d76713b4cd25ac0830c719cd61c511851e Mon Sep 17 00:00:00 2001
+From: Nick 
+Date: Mon, 30 Jul 2018 16:06:07 +
+Subject: [PATCH] Fix importer vulnerability (#4240)
+
+* Fix importer vulnerability
+Fixed issue #4229  where importer was vulnerable to XXE attacks by
+disabling DTDs along with adding warning to logger if features are
+unavailable. fixes #4229
+
+Bugs-Debian: https://bugs.debian.org/921772
+Bug: https://github.com/JabRef/jabref/issues/4229
+
+--- a/src/main/java/net/sf/jabref/logic/importer/fileformat/MsBibImporter.java
 b/src/main/java/net/sf/jabref/logic/importer/fileformat/MsBibImporter.java
+@@ -6,12 +6,15 @@
+ 
+ import javax.xml.parsers.DocumentBuilder;
+ import javax.xml.parsers.DocumentBuilderFactory;
++import javax.xml.parsers.ParserConfigurationException;
+ 
+ import net.sf.jabref.logic.importer.Importer;
+ import net.sf.jabref.logic.importer.ParserResult;
+ import net.sf.jabref.logic.msbib.MSBibDatabase;
+ import net.sf.jabref.logic.util.FileExtensions;
+ 
++import org.apache.commons.logging.Log;
++import org.apache.commons.logging.LogFactory;
+ import org.w3c.dom.Document;
+ import org.xml.sax.InputSource;
+ 
+@@ -23,6 +26,10 @@
+  */
+ public class MsBibImporter extends Importer {
+ 
++private static final Log LOGGER = LogFactory.getLog(MsBibImporter.class);
++private static final String DISABLEDTD = 
"http://apache.org/xml/features/disallow-doctype-decl;;
++private static final String DISABLEEXTERNALDTD = 
"http://apache.org/xml/features/nonvalidating/load-external-dtd;;
++
+ @Override
+ public boolean isRecognizedFormat(BufferedReader reader) throws 
IOException {
+ Objects.requireNonNull(reader);
+@@ -34,7 +41,7 @@
+  */
+ Document docin;
+ try {
+-DocumentBuilder dbuild = 
DocumentBuilderFactory.newInstance().newDocumentBuilder();
++DocumentBuilder dbuild = 
makeSafeDocBuilderFactory(DocumentBuilderFactory.newInstance()).newDocumentBuilder();
+ docin = dbuild.parse(new InputSource(reader));
+ } catch (Exception e) {
+ return false;
+@@ -65,4 +72,29 @@
+ return "Importer for the MS Office 2007 XML bibliography format.";
+ }
+ 
++/**
++ * DocumentBuilderFactory makes a XXE safe Builder factory from dBuild. 
If not supported by current
++ * XML then returns original builder given and logs error.
++ * @param dBuild | DocumentBuilderFactory to be made XXE safe.
++ * @return If supported, XXE safe DocumentBuilderFactory. Else, returns 
original builder given
++ */
++private DocumentBuilderFactory 
makeSafeDocBuilderFactory(DocumentBuilderFactory dBuild) {
++String feature = null;
++
++try {
++feature = DISABLEDTD;
++dBuild.setFeature(feature, true);
++
++feature = DISABLEEXTERNALDTD;
++dBuild.setFeature(feature, false);
++
++dBuild.setXIncludeAware(false);
++dBuild.setExpandEntityReferences(false);
++
++} catch (ParserConfigurationException e) {
++LOGGER.warn("Builder not fully configured. Feature:'" + feature + 
"' is probably not supported by current XML processor.", e);
++}
++
++return dBuild;
++}

Bug#926910: RFP: node-evacuated-prettier-eslint-cli -- CLI for prettier-eslint

2019-04-11 Thread Jeff Cliff
Package: wnpp
Severity: wishlist

* Package name: node-evacuated-prettier-eslint-cli
  Version : 0.0.0-semantically-released
  Upstream Author : Kent C. Dodds  
* URL : 
https://salsa.debian.org/themusicgod1-guest/evacuated-prettier-eslint-cli/
* License : MIT
  Programming Lang: javascript
  Description : CLI for prettier-eslint

This is a fork of prettier-eslint-cli outside of the NSA/Microsoft walled 
garden.

The problem prettier-eslint-cli addresses:
You have a bunch of files that you want to format using prettier-eslint. But 
prettier-eslint can 
only operate on strings. 

solution:
This is a CLI that allows you to use prettier-eslint on one or multiple files. 
prettier-eslint-cli 
forwards on the filePath and other relevant options to prettier-eslint which 
identifies the 
applicable ESLint config for each file and uses that to determine the options 
for prettier 
and eslint --fix.

prettier-eslint-cli is a prerequisite for node-evacuated-mocha ( #926741 )



Bug#827627: Please support packaging vim addons as vim "packages"

2019-04-11 Thread Josh Triplett
On Thu, Apr 11, 2019 at 10:38:18PM -0400, James McCoy wrote:
> On Sat, Jun 18, 2016 at 03:01:05PM -0700, Josh Triplett wrote:
> > Vim supports loading "packages", typically installed as
> > ~/.vim/pack/$package .  A package consists of files under
> > ~/.vim/pack/$package/start/$name/* and optionally
> > ~/.vim/pack/$package/opt/$name/* .  The files under those directories
> > match the standard runtime directory layout (doc, ftdetect, ftplugin,
> > indent, plugin, ...).
> > 
> > This format has the advantage that the user can add a single directory
> > (or symlink) for a package, keeping all that package's files together.
> > The symlink doesn't need updating when the set of files in the package
> > change (which also makes it simpler and more robust to track in a git
> > home directory).  And since the directory contains a single package, it
> > can compile and include a tags file with helpztags, rather than having
> > vim-addon-manager compile a combined one at user installation time.
> 
> I uploaded a new package, dh-vim-addon, which provides support for
> managing vim addons by leveraging Vim's "packages".  It's available in
> Buster and I'll likely start nudging people to switch to it after Buster
> is released.
> 
> I've started work on converting vim-scripts to use dh-vim-addon, but I
> haven't fully thought through how to manage the migration for users.  At
> the worst, it will simply be a NEWS.Debian entry explaining how to
> handle it.
> 
> The vim addon policy should probably move to dh-vim-addon at some point,
> since that seems like a better home than the vim-doc package (especially
> as dh-vim-addon supports neovim).

Awesome, thank you! I did see dh-vim-addon when it entered the archive,
and it fully addresses this (assuming packages start using it).



Bug#926909: libblis-openmp-dev: blis needs to provide blas shlib dependency files

2019-04-11 Thread Drew Parsons
Package: libblis-openmp-dev
Version: 0.5.1-8
Followup-For: Bug #926909
Control: affects -1 src:slepc

Actually the error is in experimental, so that's with 
libblis2-openmp 0.5.1-8  (m68k sh4)



Bug#926813: unblock: python-scipy/1.1.0-6

2019-04-11 Thread Drew Parsons

On 2019-04-12 11:43, Drew Parsons wrote:


python-scipy/1.1.0-7 is now uploaded.


Here's the debdiff

$ debdiff python-scipy_1.1.0-4.dsc python-scipy_1.1.0-7.dsc
diff -Nru python-scipy-1.1.0/debian/changelog 
python-scipy-1.1.0/debian/changelog
--- python-scipy-1.1.0/debian/changelog	2019-03-14 14:12:00.0 
+0800
+++ python-scipy-1.1.0/debian/changelog	2019-04-12 00:46:35.0 
+0800

@@ -1,3 +1,27 @@
+python-scipy (1.1.0-7) unstable; urgency=medium
+
+  * Team upload.
+  * Patch fix_test_optim_canonical~onstraint_2d7e7e8c.patch applies
+upstream patch 2d7e7e8 to fix occasional random failures in
+test_canonical_constraint.test_concatenation.
+
+ -- Drew Parsons   Fri, 12 Apr 2019 00:46:35 +0800
+
+python-scipy (1.1.0-6) unstable; urgency=medium
+
+  * Team upload.
+  * skip sparsetools.TestInt32Overflow matvec tests on python3 also.
+
+ -- Drew Parsons   Thu, 11 Apr 2019 09:38:17 +0800
+
+python-scipy (1.1.0-5) unstable; urgency=medium
+
+  * Team upload.
+  * Skip sparsetools.TestInt32Overflow matvec tests on python2
+(MemoryError). Closes: #919929.
+
+ -- Drew Parsons   Wed, 10 Apr 2019 16:41:47 +0800
+
 python-scipy (1.1.0-4) unstable; urgency=medium

   * Team upload.
diff -Nru 
python-scipy-1.1.0/debian/patches/fix_test_optim_canonical_constraint_2d7e7e8c.patch 
python-scipy-1.1.0/debian/patches/fix_test_optim_canonical_constraint_2d7e7e8c.patch
--- 
python-scipy-1.1.0/debian/patches/fix_test_optim_canonical_constraint_2d7e7e8c.patch	1970-01-01 
08:00:00.0 +0800
+++ 
python-scipy-1.1.0/debian/patches/fix_test_optim_canonical_constraint_2d7e7e8c.patch	2019-04-12 
00:46:35.0 +0800

@@ -0,0 +1,37 @@
+From 2d7e7e8c6142e8925c44f92f6839147690880e7d Mon Sep 17 00:00:00 2001
+From: Warren Weckesser 
+Date: Wed, 10 Apr 2019 14:20:40 -0400
+Subject: [PATCH] BUG/TST: optimize: Fix a test that occasionally raises 
an

+ exception.
+
+The test `test_initial_constraints_as_canonical()` in
+scipy/scipy/optimize/_trustregion_constr/tests/test_canonical_constraint.py
+occasionally raises an exception when it is run, because the random 
initial
+value `x0` that it generates does not satisfy the nonlinear constraint 
used

+in the test.  To avoid this, use a fixed `x0` instead of generating it
+randomly.
+
+Closes gh-9308.
+---
+ .../_trustregion_constr/tests/test_canonical_constraint.py | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git 
a/scipy/optimize/_trustregion_constr/tests/test_canonical_constraint.py 
b/scipy/optimize/_trustregion_constr/tests/test_canonical_constraint.py

+index 3ac51b6faa8..589f32f1aee 100644
+--- 
a/scipy/optimize/_trustregion_constr/tests/test_canonical_constraint.py
 
b/scipy/optimize/_trustregion_constr/tests/test_canonical_constraint.py

+@@ -234,9 +234,12 @@ def test_empty():
+
+
+ def test_initial_constraints_as_canonical():
++# rng is only used to generate the coefficients of the quadratic
++# function that is used by the nonlinear constraint.
+ rng = np.random.RandomState(0)
+-n = 4
+-x0 = np.random.rand(n)
++
++x0 = np.array([0.5, 0.4, 0.3, 0.2])
++n = len(x0)
+
+ lb1 = [-1, -np.inf, -2, 3]
+ ub1 = [1, np.inf, np.inf, 3]
diff -Nru python-scipy-1.1.0/debian/patches/series 
python-scipy-1.1.0/debian/patches/series
--- python-scipy-1.1.0/debian/patches/series	2019-03-14 
14:12:00.0 +0800
+++ python-scipy-1.1.0/debian/patches/series	2019-04-12 
00:46:35.0 +0800

@@ -4,3 +4,4 @@
 matrix_API_614847c5.patch
 matrix_API_more_e0cfa29e2.patch
 matrix_API_filter_check_87e48c3c5.patch
+fix_test_optim_canonical_constraint_2d7e7e8c.patch
diff -Nru python-scipy-1.1.0/debian/tests/python2 
python-scipy-1.1.0/debian/tests/python2
--- python-scipy-1.1.0/debian/tests/python2	2019-03-14 
14:12:00.0 +0800
+++ python-scipy-1.1.0/debian/tests/python2	2019-04-12 
00:46:35.0 +0800

@@ -27,6 +27,9 @@
 
"sparse.tests.test_sparsetools.TestInt32Overflow.test_bsr_n_block[matmat]",
 
"sparse.tests.test_sparsetools.TestInt32Overflow.test_bsr_n_block[matvecs]",
 
"sparse.tests.test_sparsetools.TestInt32Overflow.test_bsr_n_block[transpose]",

+# postscriptum on Bug#919929
+"sparse.tests.test_sparsetools.TestInt32Overflow.test_matvecs",
+"sparse.tests.test_sparsetools.TestInt32Overflow.test_dia_matvec",
 ]

 junit = "$TMPDIR/junit.xml"
diff -Nru python-scipy-1.1.0/debian/tests/python3 
python-scipy-1.1.0/debian/tests/python3
--- python-scipy-1.1.0/debian/tests/python3	2019-03-14 
14:12:00.0 +0800
+++ python-scipy-1.1.0/debian/tests/python3	2019-04-12 
00:46:35.0 +0800

@@ -19,6 +19,9 @@
 "linalg.tests.test_solvers.test_solve_generalized_discrete_are",
 # fails with atlas
 "linalg.tests.test_solvers.test_solve_discrete_are",
+# postscriptum on Bug#919929
+"sparse.tests.test_sparsetools.TestInt32Overflow.test_matvecs",
+"sparse.tests.test_sparsetools.TestInt32Overflow.test_dia_matvec",
 ]

 junit = "$TMPDIR/junit.xml"



Bug#926909: libblis-openmp-dev: blis needs to provide blas shlib dependency files

2019-04-11 Thread Drew Parsons
Package: libblis-openmp-dev
Version: 0.5.1-11
Severity: normal

blis needs to provide shlib dependency files so that dh_shlibdeps can
determined the package dependencies for libblas.so.3 (probably for
lapack too).

The problem shows up in slepc builds,
https://buildd.debian.org/status/package.php?p=slepc=experimental

On mpich arches (m68k, sh4), libblis2-openmp and libblis-openmp-dev
set themselves up as the default BLAS,
https://buildd.debian.org/status/fetch.php?pkg=slepc=m68k=3.11.0%2Bdfsg1-1exp2=1555015766=0
https://buildd.debian.org/status/fetch.php?pkg=slepc=sh4=3.11.0%2Bdfsg1-1exp2=1555014340=0

Build proceeds, then fails in the dh_shlibs step:

   dh_makeshlibs -a
   dh_shlibdeps -a
dpkg-shlibdeps: error: no dependency information found for 
/usr/lib/m68k-linux-gnu/libblas.so.3 (used by 
debian/libslepc-complex3.11/usr/lib/m68k-linux-gnu/libslepc_complex.so.3.11.0)
Hint: check if the library actually comes from a package.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/libslepc-complex3.11.substvars 
debian/libslepc-complex3.11/usr/lib/m68k-linux-gnu/libslepc_complex.so.3.11.0 
returned exit code 25
dpkg-shlibdeps: error: no dependency information found for 
/usr/lib/m68k-linux-gnu/libblas.so.3 (used by 
debian/libslepc-real3.11/usr/lib/m68k-linux-gnu/libslepc_real.so.3.11.0)
Hint: check if the library actually comes from a package.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/libslepc-real3.11.substvars 
debian/libslepc-real3.11/usr/lib/m68k-linux-gnu/libslepc_real.so.3.11.0 
returned exit code 25
dh_shlibdeps: Aborting due to earlier error



Bug#926813: unblock: python-scipy/1.1.0-6

2019-04-11 Thread Drew Parsons

On 2019-04-12 00:25, Paul Gevers wrote:



E   ValueError: `x0` is infeasible with respect to some
inequality constraint with `keep_feasible` set to True.


Upstream noticed it too,
https://github.com/scipy/scipy/issues/9308

It's a small patch. Should we apply it in a python-scipy/1.1.0-7  ?


Yes please.



python-scipy/1.1.0-7 is now uploaded.



Bug#827627: Please support packaging vim addons as vim "packages"

2019-04-11 Thread James McCoy
On Sat, Jun 18, 2016 at 03:01:05PM -0700, Josh Triplett wrote:
> Vim supports loading "packages", typically installed as
> ~/.vim/pack/$package .  A package consists of files under
> ~/.vim/pack/$package/start/$name/* and optionally
> ~/.vim/pack/$package/opt/$name/* .  The files under those directories
> match the standard runtime directory layout (doc, ftdetect, ftplugin,
> indent, plugin, ...).
> 
> This format has the advantage that the user can add a single directory
> (or symlink) for a package, keeping all that package's files together.
> The symlink doesn't need updating when the set of files in the package
> change (which also makes it simpler and more robust to track in a git
> home directory).  And since the directory contains a single package, it
> can compile and include a tags file with helpztags, rather than having
> vim-addon-manager compile a combined one at user installation time.

I uploaded a new package, dh-vim-addon, which provides support for
managing vim addons by leveraging Vim's "packages".  It's available in
Buster and I'll likely start nudging people to switch to it after Buster
is released.

I've started work on converting vim-scripts to use dh-vim-addon, but I
haven't fully thought through how to manage the migration for users.  At
the worst, it will simply be a NEWS.Debian entry explaining how to
handle it.

The vim addon policy should probably move to dh-vim-addon at some point,
since that seems like a better home than the vim-doc package (especially
as dh-vim-addon supports neovim).

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB



Bug#926907: unblock: python-django-casclient/1.2.0-2.2

2019-04-11 Thread William Blough
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-django-casclient

As explained in bug #926350 [1], python-django-casclient is broken when used
with Django versions >= 1.10, due to Django middleware API changes. Since
Buster will ship with Django 1.11, python-django-casclient is useless in its
current state.

The patch to fix the issue was obtained from upstream [2].  The source
debdiff between the version in testing/unstable and the fixed version I
would like to upload (via unstable) is attached.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926350
[2] https://github.com/kstateome/django-cas/pull/64


unblock python-django-casclient/1.2.0-2.2

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

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru python-django-casclient-1.2.0/debian/changelog 
python-django-casclient-1.2.0/debian/changelog
--- python-django-casclient-1.2.0/debian/changelog  2018-09-22 
05:04:25.0 -0400
+++ python-django-casclient-1.2.0/debian/changelog  2019-04-03 
17:26:47.0 -0400
@@ -1,3 +1,10 @@
+python-django-casclient (1.2.0-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply django 1.10 middleware fix from upstream (Closes: #926350)
+
+ -- William Blough   Wed, 03 Apr 2019 17:26:47 -0400
+
 python-django-casclient (1.2.0-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
python-django-casclient-1.2.0/debian/patches/django_110_middleware_fix 
python-django-casclient-1.2.0/debian/patches/django_110_middleware_fix
--- python-django-casclient-1.2.0/debian/patches/django_110_middleware_fix  
1969-12-31 19:00:00.0 -0500
+++ python-django-casclient-1.2.0/debian/patches/django_110_middleware_fix  
2019-04-03 17:26:47.0 -0400
@@ -0,0 +1,41 @@
+Description: Fix middleware to be compatible with Django 1.10
+Origin: upstream, 
https://patch-diff.githubusercontent.com/raw/kstateome/django-cas/pull/64.diff
+Last-Update: 2019-04-11
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/cas/middleware.py
 b/cas/middleware.py
+@@ -5,6 +5,15 @@ try:
+ except ImportError:
+ from urllib.parse import urlencode
+ 
++
++MIDDLEWARE_BASE = None
++
++try:
++from django.utils.deprecation import MiddlewareMixin
++MIDDLEWARE_BASE = MiddlewareMixin
++except ImportError:
++MIDDLEWARE_BASE = object
++
+ from django.conf import settings
+ from django.contrib.auth import REDIRECT_FIELD_NAME
+ from django.contrib.auth import logout as do_logout
+@@ -19,7 +28,7 @@ from cas.views import login as cas_login
+ __all__ = ['CASMiddleware']
+ 
+ 
+-class CASMiddleware(object):
++class CASMiddleware(MIDDLEWARE_BASE):
+ """
+ Middleware that allows CAS authentication on admin pages
+ """
+@@ -81,7 +90,7 @@ class CASMiddleware(object):
+ return None
+ 
+ 
+-class ProxyMiddleware(object):
++class ProxyMiddleware(MIDDLEWARE_BASE):
+ 
+ # Middleware used to "fake" the django app that it lives at the Proxy 
Domain
+ def process_request(self, request):
diff -Nru python-django-casclient-1.2.0/debian/patches/series 
python-django-casclient-1.2.0/debian/patches/series
--- python-django-casclient-1.2.0/debian/patches/series 1969-12-31 
19:00:00.0 -0500
+++ python-django-casclient-1.2.0/debian/patches/series 2019-04-03 
17:26:47.0 -0400
@@ -0,0 +1 @@
+django_110_middleware_fix


Bug#926906: libc6: range of cyrillic lowercase letters matches also uppercase

2019-04-11 Thread aleksandr barakin
Package: libc6
Version: 2.28-8
Severity: normal

Dear Maintainer, new version (2.28) of libc6 contains collation error.

expected behaviour:
$ echo АБВабв | grep -o '[а-в]'
а
б
в
$ echo АБВабв | sed 's/[а-в]/-/g'
АБВ---

observed behaviour:
$ echo АБВабв | grep -o '[а-в]'
А
Б
а
б
в
$ echo АБВабв | sed 's/[а-в]/-/g'
--В---

this error is also observed in archlinux (libc-2.28) (see discussion in
russian: https://ru.stackoverflow.com/q/968618/178576)

additional info:
$ locale
LANG=
LANGUAGE=ru
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=ru_RU.UTF-8

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
ru_RU.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to ru_RU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libc6 depends on:
ii  libgcc1  1:8.3.0-5

Versions of packages libc6 recommends:
ii  libidn2-0  2.0.5-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.71
pn  glibc-doc  
ii  libc-l10n  2.28-8
ii  locales2.28-8

-- debconf information excluded


Bug#926905: RFP: librust-evacuated-fdlimit-dev -- Rust raise file limit

2019-04-11 Thread Jeff Cliff
Package: wnpp
Severity: wishlist

* Package name: librust-evacuated-fdlimit-dev
  Version : 0.1.1
  Upstream Author : NikVolf 
* URL : 
https://salsa.debian.org/themusicgod1-guest/evacuated-fdlimit/
* License : GPL-3.0
  Programming Lang: Rust
  Description : Rust raise file limit

Utility crate for raising file descriptors limit for OSX and Linux



Bug#900912: Enabling jaw (Java-atk-wrapper) by default ? (Bug#900912)

2019-04-11 Thread Matthias Klose
On 11.04.19 20:24, Paul Gevers wrote:
> Hi doko,
> 
> On 07-04-2019 12:08, Samuel Thibault wrote:
>>> I disagree.  I'll do the next upload with Samuel's proposed patches, not
>>> enabling that by default, together with the planned security update.  Then
>>> people can start testing if the wrapper works.
>>
>> Well, I'm afraid that what will happen is that the people who will
>> test will simply find out that it just works for them (just like it
>> does already for them with openjdk-8) ; will we then conclude near the
>> release that it should be enabled by default for Buster, and then be hit
>> by the much wider exposition to jaw?
>>
>> If on the contrary we enable it by default during the freeze, we will
>> have *way* more testing coverage, and thus be much more confident with
>> keeping it enabled by default in Buster if we don't see bug reports.
> 
> Although I agree with Samuel here, can we please-pretty-please get an
> upload even if you don't enable it, such that we can get this story into
> buster?

yes, will be part of the CPU update next week.



Bug#926904: sip4: SIP 4.19.15 causes wxpython4.0 to FTBFS

2019-04-11 Thread Scott Talbert
Source: sip4
Version: 4.19.15+dfsg-1
Severity: normal

Dear Maintainer,

SIP 4.19.15 has a regression with diamond inheritance hierarchies that causes
wxpython4.0 to FTBFS.  See, for example [1].  This issue is fixed in SIP
4.19.16.

[1] 
https://launchpadlibrarian.net/418460029/buildlog_ubuntu-disco-amd64.wxpython4.0_4.0.4+dfsg-2_BUILDING.txt.gz

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

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



Bug#926903: Package: installation-reports

2019-04-11 Thread Tom Thekathyil
Package: installation-reports

Boot method: dvd
Image version:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/amd64/iso-dvd/firmware-testing-amd64-DVD-1.iso
Date installed: 2019/04/11 morning (AU TZ)

Machine: Desktop
Processor: Ryzen 3 2200G/Vega 8
Memory: 2x4gb ddr4 team 2400
Partitions: all in single partition
   Filesystem Type 1K-blocksUsed Available Use% Mounted on
   udev   devtmpfs   3518520   0   3518520   0% /dev
   tmpfs  tmpfs   713280   17516695764   3% /run
   /dev/sda1  ext4 953224732 4051380 900682448   1% /
   tmpfs  tmpfs  3566380   0   3566380   0% /dev/shm
   tmpfs  tmpfs 5120   4  5116   1% /run/lock
   tmpfs  tmpfs  3566380   0   3566380
0% /sys/fs/cgroup
   tmpfs  tmpfs   713276  16713260
1% /run/user/1000

Output of lspci -knn:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Root Complex [1022:15d0]
Subsystem: ASUSTeK Computer Inc. Raven/Raven2 Root Complex
[1043:876b]
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2
IOMMU [1022:15d1]
Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU
[1022:15d1]
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family
17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3]
Kernel driver in use: pcieport
00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family
17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus A [1022:15db]
Kernel driver in use: pcieport
00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus B [1022:15dc]
Kernel driver in use: pcieport
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus
Controller [1022:790b] (rev 61)
Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller
[1043:876b]
Kernel driver in use: piix4_smbus
Kernel modules: i2c_piix4, sp5100_tco
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC
Bridge [1022:790e] (rev 51)
Subsystem: ASUSTeK Computer Inc. FCH LPC Bridge [1043:876b]
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Device 24: Function 0 [1022:15e8]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Device 24: Function 1 [1022:15e9]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Device 24: Function 2 [1022:15ea]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Device 24: Function 3 [1022:15eb]
Kernel driver in use: k10temp
Kernel modules: k10temp
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Device 24: Function 4 [1022:15ec]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Device 24: Function 5 [1022:15ed]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Device 24: Function 6 [1022:15ee]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Device 24: Function 7 [1022:15ef]
01:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device
[1022:43bc] (rev 02)
Subsystem: ASMedia Technology Inc. Device [1b21:1142]
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD]
Device [1022:43b8] (rev 02)
Subsystem: ASMedia Technology Inc. Device [1b21:1062]
Kernel driver in use: ahci
Kernel modules: ahci
01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device
[1022:43b3] (rev 02)
Kernel driver in use: pcieport
02:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series
Chipset PCIe Port [1022:43b4] (rev 02)
Kernel driver in use: pcieport
02:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series
Chipset PCIe Port [1022:43b4] (rev 02)
Kernel driver in use: pcieport
02:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series
Chipset PCIe Port [1022:43b4] (rev 02)
Kernel driver in use: pcieport
02:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series
Chipset PCIe Port [1022:43b4] (rev 02)
Kernel driver in use: pcieport
05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168]
(rev 15)
Subsystem: ASUSTeK Computer Inc. RTL8111/8168/8411 PCI Express
Gigabit Ethernet Controller [1043:8677]
Kernel driver in use: r8169
Kernel modules: r8169
07:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Raven Ridge [Radeon Vega 

Bug#926902: RFP: golang-salsa-themusicgod1-guest-bigcache-dev -- Efficient cache for gigabytes of data written in Go

2019-04-11 Thread Jeff Cliff
Package: wnpp
Severity: wishlist

* Package name: golang-salsa-themusicgod1-guest-bigcache-dev
  Version : 1
  Upstream Author : BigCache contributors
* URL : https://salsa.debian.org/themusicgod1-guest/bigcache
* License : Apache 2.0
  Programming Lang: go
  Description : Efficient cache for gigabytes of data written in Go

This project used to be found at NSA/Microsoft github...then it was bundled 
as a vendored dependency into the Go Ethereum client. Now it's been 
de-vendored into this project directory.

Fast, concurrent, evicting in-memory cache written to keep big number of 
entries without impact on performance. BigCache keeps entries on heap but
omits GC for them. To achieve that operations on bytes arrays take place,
therefore entries (de)serialization in front of the cache will be needed 
in most use cases.

bigcache is a prerequisite of geth ( #890541 )  



Bug#926901: bcron: init.d script and runit service conflict

2019-04-11 Thread Mathieu Mirmont
Package: bcron
Version: 0.11-8
Severity: important

Dear Maintainer,

The bcron package provides both init.d scripts and runit services.
When installing it in a system where runsvdir is running (for instance
via runit-init or runit-sysv), then the daemons are started by both
runsvdir and by update-rc.d:

$ pstree
bash-+-daemon---bcron-update
 |-daemon---bcron-sched---bcron-exec
 |-daemon---unixserver
 |-pstree
 `-runsvdir-+-runsv-+-bcron-update
|   `-svlogd
|-runsv-+-svlogd
|   `-unixserver
`-runsv-+-bcron-sched---bcron-exec
`-svlogd

This issue is most likely present in all packages that ship both
init.d scripts and runit services, I aritrarily picked bcron to report
the bug, please feel free to re-assign.

I suspect that a fix could be implemented in invoke-rc.d by making it
aware of runsvdir, similarly to how it is already aware of systemd and
openrc?


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages bcron depends on:
pn  libbg2  
ii  libc6   2.28-8
ii  runit-helper2.8.6
ii  sysuser-helper  1.3.3
pn  ucspi-unix  

Versions of packages bcron recommends:
ii  daemon 0.6.4-1+b2
ii  nullmailer [mail-transport-agent]  1:2.2-3
ii  runit  2.1.2-25

Versions of packages bcron suggests:
ii  anacron 2.3-27
ii  runit-init  2.1.2-25



Bug#926900: sslv3 alert illegal parameter

2019-04-11 Thread sergio
Package: reportbug
Version: 7.5.2
Severity: normal

Dear Maintainer,

I'm not sure if this is a reportbug issue, may be python3-reportbug or
python3 itself. Please correct me.


I've an exim4-daemon-heavy 4.92-2 running on buster with

CIPHERS_587 = SECURE256:-CIPHER-ALL:+AES-256-GCM:+CHACHA20-POLY1305

It works fine with all clients that I have, except reportbug:

Connecting to mail:587 via SMTP...
SMTP send failure: [SSL: SSLV3_ALERT_ILLEGAL_PARAMETER] sslv3 alert
illegal parameter (_ssl.c:1056). Do you want to retry (or else save the
report and exit)? [Y|n|q|?]?


exim -d+tls -bd shows:
...
SMTP>> 220 TLS go ahead
GnuTLS<3>: ASSERT: ../../lib/buffers.c[get_last_packet]:1171
GnuTLS<3>: ASSERT:
../../../lib/ext/server_name.c[_gnutls_server_name_recv_params]:109
GnuTLS<3>: ASSERT: ../../lib/hello_ext.c[hello_ext_parse]:273
GnuTLS<3>: ASSERT: ../../lib/extv.c[_gnutls_extv_parse]:69
GnuTLS<3>: ASSERT: ../../lib/hello_ext.c[_gnutls_parse_hello_extensions]:306
GnuTLS<3>: ASSERT: ../../lib/handshake.c[read_client_hello]:698
GnuTLS<3>: ASSERT: ../../lib/handshake.c[_gnutls_recv_handshake]:1545
GnuTLS<3>: ASSERT: ../../lib/handshake.c[handshake_server]:3400
LOG: MAIN
  TLS error on connection from [IP] (gnutls_handshake): An illegal
parameter has been received.
TLS failed to start
...

-- 
sergio.



Bug#923962: 923962: tigervnc-standalone-server: crashes on ARM after VncAuth

2019-04-11 Thread Bernhard Übelacker
Dear Maintainer,
I tried to triage that issue and came to this try and catch block:

146   try {
147 PlainPasswd plainPassword(obfuscated);
148 password->replaceBuf(plainPassword.takeBuf());
149 PlainPasswd plainPasswordReadOnly(obfuscatedReadOnly);
150 readOnlyPassword->replaceBuf(plainPasswordReadOnly.takeBuf());
151   } catch (...) {
152   }

In line 149 a new object is tried to be constructed while there
is no readonly password configured:

(gdb) print obfuscatedReadOnly
$2 = { = {buf = 0xd89b3a10 "\b1\236\253\377\377"}, 
length = 0}

Now in the constuctor an exception is thrown in line 46:

44  PlainPasswd::PlainPasswd(const ObfuscatedPasswd& obfPwd) : 
CharArray(9) {
45if (obfPwd.length < 8)
46  throw rdr::Exception("bad obfuscated password length");


Now I think below __cxa_throw something goes wrong.
As far as I see in libunwind we receive from unw_get_proc_info
a -10 which leads to a:

60if (unw_get_proc_info (, ) < 0)
61  return _URC_FATAL_PHASE1_ERROR;

Therefore in __cxa_throw std::terminate() is called:

93// Some sort of unwinding error.  Note that terminate is a 
handler.
94__cxa_begin_catch (>exc.unwindHeader);
95std::terminate ();

This std::terminate "just" sends a signal that is catched by OsSigHandler.


So I am unsure who has to be asked for.
Should this issue be forwarded to libunwind8 ?


Attached some debugging attempts.


Kind regards,
Bernhard



Problem seem to start here:
(gdb) bt
#0  0x958ebed8 in _Unwind_RaiseException 
(exception_object=exception_object@entry=0xaaab147e2960) at 
unwind/RaiseException.c:60
#1  0x953afba4 in __cxxabiv1::__cxa_throw 
(obj=obj@entry=0xaaab147e2980, tinfo=0xe06f4df8 , dest=0xe05b57e8 ) at 
../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:90
#2  0xe05ee4d4 in rfb::PlainPasswd::PlainPasswd 
(this=0xe2f00d00, obfPwd=...) at ./common/rfb/Password.cxx:46
#3  0xe05dd144 in rfb::VncAuthPasswdParameter::getVncAuthPasswd 
(this=, password=0xe2f00d90, 
readOnlyPassword=0xe2f00d98) at ./common/rfb/SSecurityVncAuth.cxx:149
#4  0xe05dd5a8 in rfb::SSecurityVncAuth::processMsg 
(this=0xaaab148571e0, sc=) at 
./common/rfb/SSecurityVncAuth.cxx:93
#5  0xe05d5348 in rfb::SConnection::processSecurityMsg 
(this=0xaaab1480eea0) at ./common/rfb/SConnection.cxx:213
#6  0xe05e1f64 in rfb::VNCSConnectionST::processMessages 
(this=0xaaab1480eea0) at ./common/rfb/VNCSConnectionST.cxx:151
#7  0xe05bf178 in XserverDesktop::handleSocketEvent 
(this=this@entry=0xaaab14497f70, fd=fd@entry=10, sockserv=0xaaab144ae920, 
read=read@entry=true, write=write@entry=false) at 
././unix/xserver/hw/vnc/XserverDesktop.cc:428
#8  0xe05bf28c in XserverDesktop::handleSocketEvent 
(this=0xaaab14497f70, fd=10, read=, write=) at 
././unix/xserver/hw/vnc/XserverDesktop.cc:377
#9  0xe065e2d8 in ospoll_wait (ospoll=0xaaab14497b80, 
timeout=) at ././unix/xserver/os/ospoll.c:651
#10 0xe0657090 in WaitForSomething (are_ready=0) at 
././unix/xserver/os/WaitFor.c:208
#11 0xe060f774 in Dispatch () at ././unix/xserver/dix/dispatch.c:421
#12 0xe0614ae8 in dix_main (argc=20, argv=0xe2f02218, 
envp=0xe2f022c0) at ././unix/xserver/dix/main.c:276
#13 0x950ecd24 in __libc_start_main (main=0xe04e3150 , 
argc=20, argv=0xe2f02218, init=, fini=, 
rtld_fini=, stack_end=) at ../csu/libc-start.c:308
#14 0xe04e49c0 in _start () at 
/usr/include/c++/8/bits/stl_tree.h:210


Final backtrace:
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x950ec8e8 in __GI_abort () at abort.c:79
#2  0xe06604dc in OsAbort () at ././unix/xserver/os/utils.c:1350
#3  0xe0665c24 in AbortServer () at ././unix/xserver/os/log.c:879
#4  0xe0666984 in FatalError (f=f@entry=0xe0685890 "Caught 
signal %d (%s). Server aborting\n") at ././unix/xserver/os/log.c:1017
#5  0xe065d8b4 in OsSigHandler (unused=, 
sip=0xe2eff670, signo=6) at ././unix/xserver/os/osinit.c:156
#6  OsSigHandler (signo=6, sip=0xe2eff670, unused=) at 
././unix/xserver/os/osinit.c:110
#7  
#8  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#9  0x950ec8e8 in __GI_abort () at abort.c:79
#10 0x953b1ac4 in __gnu_cxx::__verbose_terminate_handler () at 
../../../../src/libstdc++-v3/libsupc++/vterminate.cc:50
#11 0x953af8ac in __cxxabiv1::__terminate (handler=) 
at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:47
#12 0x953af8f8 in std::terminate () at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:57
#13 0x953afc10 in __cxxabiv1::__cxa_rethrow () at 

Bug#926899: RFP: node-evacuated-functional-red-black-tree -- A purely functional red-black tree data structure (in javascript)

2019-04-11 Thread Jeff Cliff
Package: wnpp
Severity: wishlist

* Package name: node-evacuated-functional-red-black-tree
  Version : 1.0.1
  Upstream Author : Mikola Lysenko
* URL : 
https://salsa.debian.org/themusicgod1-guest/evacuated-functional-red-black-tree/
* License : MIT
  Programming Lang: javascript
  Description : A purely functional red-black tree data structure (in 
javascript)

from it's npm:

"A fully persistent red-black tree written 100% in JavaScript. Works both in 
node.js 
and in the browser via browserify.

Functional (or fully presistent) data structures allow for non-destructive 
updates. 
So if you insert an element into the tree, it returns a new tree with the 
inserted 
element rather than destructively updating the existing tree in place. Doing 
this 
requires using extra memory, and if one were naive it could cost as much as 
reallocating the entire tree. Instead, this data structure saves some memory by 
recycling references to previously allocated subtrees. This requires using only 
O(log(n)) additional memory per update instead of a full O(n) copy.

Some advantages of this is that it is possible to apply insertions and removals 
to 
the tree while still iterating over previous versions of the tree. Functional 
and 
persistent data structures can also be useful in many geometric algorithms like 
point location within triangulations or ray queries, and can be used to analyze 
the history of executing various algorithms. This added power though comes at a 
cost, since it is generally a bit slower to use a functional data structure 
than an 
imperative version. However, if your application needs this behavior then you 
may 
consider using this module."

This version of functional-red-black-tree has been evacuated from the 
NSA/Microsoft
walled garden.  functional-red-black-tree is a prerequisite of eslint ( #743404 
).



Bug#864453: fanotify07 LTP testcase hangs process

2019-04-11 Thread Salvatore Bonaccorso
Hi,

On Thu, Jun 08, 2017 at 09:23:33PM +0200, Helge Deller wrote:
> Package: linux
> Version: 4.9.30
> 
> The LTP testcase fanotify07 creates hanging processes
> with debian kernel 4.9.30 on the hppa platform.
> 
> In the source code of LTP's fanotify07.c testcase one can read:
>  * Kernel crashes should be fixed by:
>  *  96d41019e3ac "fanotify: fix list corruption in fanotify_get_response()"
>  *
>  * Kernel hangs should be fixed by:
>  *  05f0e38724e8 "fanotify: Release SRCU lock when waiting for userspace 
> response"
> 
> It seems upstream commit 
> 05f0e38724e8 "fanotify: Release SRCU lock when waiting for userspace response"
> is missing in stable kernel 4.9.30 (and debian kernel), which explains why the
> testcase hangs.
> I didn't checked if the kernel crash fix is in 4.9.30.
> 
> Can you backport at least the commit 05f0e38724e8 ?

That looks has happened for the 4.9 stable series as in
https://lore.kernel.org/stable/20190411032430.17353-1-matthew.ruff...@canonical.com/
and would be included afaics in 4.9.169.

Regards,
Salvatore



Bug#920530: apparmor: Apparmour breaks bind/named DLZ with samba

2019-04-11 Thread Steven Monai
Bernhard Schmidt  writes:
>Any more warnings you experienced?

I'm glad you asked. Since my last message, I have been getting the following 
three logs every two or three days:

Apr 11 00:49:41 dc1 kernel: [489173.713080] audit: type=1400 
audit(1554968981.353:17): apparmor="ALLOWED" operation="mknod" 
profile="/usr/sbin/named" name="/var/tmp/krb5_RCjltFy7" pid=426 
comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=108
ouid=108
Apr 11 00:49:41 dc1 kernel: [489173.713685] audit: type=1400 
audit(1554968981.357:18): apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/named" name="/var/tmp/krb5_RCjltFy7" pid=426 
comm="isc-worker" requested_mask="wrc" denied_mask="wrc"
fsuid=108 ouid=108
Apr 11 00:49:41 dc1 kernel: [489173.835799] audit: type=1400 
audit(1554968981.477:19): apparmor="ALLOWED" operation="rename_src" 
profile="/usr/sbin/named" name="/var/tmp/krb5_RCjltFy7" pid=426 
comm="isc-worker" requested_mask="wrd" denied_mask="wrd"
fsuid=108 ouid=108

Always between 12:00am and 01:00am, and always those same three operations 
(mknod, open, and rename_src) on a randomly-named (with 'krb5' prefix) 
tempfile. I'm not sure what it represents, but it could be some kind of 
periodic house-keeping by the
daemon. I'm not 100% certain that these logs are connected with the Samba 
BIND9_DLZ, but it seems likely, since the 'krb5' prefix hints a Kerberos 
connection.

>> I am unsure how to provide appropriate access to
>> '/dev/urandom', as I don't understand what the denied_mask="wc" means.
>> Maybe simple "read" (r) access would cover it, like this (?):
>> 
>> /dev/urandom r,
>
>I'm unsure about that either. Ccing the Apparmor maintainer, I'm not
>sure whether anything additional is needed for access to /dev/urandom.
>
I think something will need to be added to the 'usr.sbin.named' profile, 
because I added '/dev/urandom r' to my '/etc/apparmor.d/local/usr.sbin.named', 
but I still occasionally get entries in my log that look like this:

Apr  5 09:49:40 dc1 kernel: [ 3176.419143] audit: type=1400 
audit(1554482980.697:10): apparmor="ALLOWED" operation="open" 
profile="/usr/sbin/named" name="/dev/urandom" pid=426 comm="isc-worker" 
requested_mask="wc" denied_mask="wc" fsuid=108 ouid=0

-S.M.




Bug#926866: [Pkg-utopia-maintainers] Bug#926866: network-manager: Typo in help concerning man pages section

2019-04-11 Thread Michael Biebl

Am 11.04.19 um 15:06 schrieb J. A. Corbal:
> The last line of the command 'nmcli' says:
> 
> Consult nmcli(1) and nmcli-examples(5) manual pages for complete usage 
> details.
> 
> But there's no man page 'nmcli-examples (5)'.  The actual man section
> is 7.  It should say:
> 
> Consult nmcli(1) and nmcli-examples(7) manual pages for complete usage 
> details.

Thanks, forwarded this issue upstream.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/157
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#926719: SFTP ProFTPD terminating (signal 11) after Update to 1.3.5e-0+deb8u1

2019-04-11 Thread Markus Koschany
I just found this bug report which may be related:

https://bugs.launchpad.net/ubuntu/+source/proftpd-dfsg/+bug/1794605


Can someone confirm that using RSA keys instead of

SFTPHostKey /etc/ssh/ssh_host_ecdsa_key

works for you?



signature.asc
Description: OpenPGP digital signature


Bug#926330: RFS: cuba/4.2-1 [ITP]

2019-04-11 Thread Francesco Montanari

On 4/5/19 5:27 PM, Sébastien Villemot wrote:
> Done:https://salsa.debian.org/science-team/cuba
>
> I granted you Maintainer access on that project.

Thanks! I updated the package after going through Debian Science
Policy and pushed the changes to the git repository. I'd appreciate if
someone is available to sponsor the package.

As mentioned in the ITP [1], a previous version of the library,
libcuba3, was already in Debian and I based the package on that one. I
reached out to the previous maintainer to verify that he is fine with me
reintroducing the package.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886254

I also checked with upstream author that pointer overflow warnings I
get when compiling (gcc 8.3.0) [2] can be safely ignored.

[2] https://lists.debian.org/debian-science/2019/03/msg00031.html

Best,
Francesco



Bug#926898: simpleid: Homepage is outdated

2019-04-11 Thread sergio

Package: simpleid
Version: 0.8.1-15
Severity: normal

Dear Maintainer,

Homepage: http://www.simpleid.org/
We can’t connect to the server at www.simpleid.org says firefox
The correct url is https://simpleid.org/

--
sergio.



Bug#919377: mysql++: FTBFS with mariadb-10.3: dbdriver.cpp:260:10: error: 'CLIENT_LONG_PASSWORD' was not declared in this scope

2019-04-11 Thread Guillem Jover
Control: tags -1 patch

Hi!

On Tue, 2019-04-02 at 09:53:47 +0300, Otto Kekäläinen wrote:
> Could you please check if it is still valid and happening in Debian
> unstable there has been several updates MariaDB client libraries /
> connector C libraries recently?

A rebuild quickly shows this is still the case. The attached patch
makes this package build again for me, and removes a warning from
using an internal header.

Thanks,
Guillem
Author: Guillem Jover 
Description: Update code against latest mariadb libraries
 - Do not include internal header which emits warnings now.
 - Do not use removed CLIENT_LONG_PASSWORD macro, for the lower bound.
Bug-Debian: https://bugs.debian.org/919377


---
 lib/common.h |2 ++
 lib/dbdriver.cpp |2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

--- a/lib/common.h
+++ b/lib/common.h
@@ -127,11 +127,13 @@
 	#define MYSQLPP_PATH_SEPARATOR '/'
 #endif
 
+#if 0
 #if defined(MYSQLPP_MYSQL_HEADERS_BURIED)
 #	include 
 #else
 #	include 
 #endif
+#endif
 
 namespace mysqlpp {
 
--- a/lib/dbdriver.cpp
+++ b/lib/dbdriver.cpp
@@ -257,7 +257,7 @@ DBDriver::set_option(unsigned int o, boo
 	}
 	
 	if ((n == 1) &&
-			(o >= CLIENT_LONG_PASSWORD) &&
+			(o >= 0) &&
 #if MYSQL_VERSION_ID > 4	// highest flag value varies by version
 			(o <= CLIENT_MULTI_RESULTS)
 #else


Bug#926719: SFTP ProFTPD terminating (signal 11) after Update to 1.3.5e-0+deb8u1

2019-04-11 Thread Markus Koschany
Hello,

Am 11.04.19 um 22:59 schrieb Hilmar Preuße:
[...]
> Your latest upload to Debian oldstable introduced a new bug: the proftp
> server now crashes, upon SSH connections. As I don't have an oldstable
> system at hand: are you able to reproduce the issue using the package
> you built?

I cannot reproduce this issue. The Proftpd sftp server works fine on my
local system and I can connect with a local user. Signal 11 means there
is a segfault but I did not make any extra modifications to the upstream
code.

Could you send me your sftp configuration snippet for proftpd and tell
me more about your setup? How can you connect via command-line sftp but
not via filezilla?

Best regards,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#926886: Please mention video->render change in udev.NEWS

2019-04-11 Thread Michael Biebl
Am 11.04.19 um 23:27 schrieb Michael Biebl:

> Btw, what exactly was the breakage?
> I assume you worked around that for now by adding your user to group
> render?
> Which wayland compositor is that, btw? How do you start it?

Fwiw, GNOME on Wayland (with gdm) seems to work fine here. At least I
didn't recognize any breakage.
And I have

$ getfacl /dev/dri/renderD128
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/renderD128
# owner: root
# group: render
user::rw-
user:michael:rw-
group::rw-
mask::rw-
other::---

If this looks different for you, the output of

$ loginctl show-session $XDG_SESSION_ID

would be useful as well.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#926871: [Pkg-javascript-devel] Bug#926871: Uncaught SyntaxError: Unexpected token export

2019-04-11 Thread Jérémy Lal
Le jeu. 11 avr. 2019 à 17:24, Enrico Zini  a écrit :

> Package: libjs-popper.js
> Version: 1.14.6+ds2-1
> Severity: important
>
> Hello,
>
> these toplevel scripts:
>
> /usr/share/javascript/popper.js/popper.js
> /usr/share/javascript/popper.js/popper.min.js
>
> contain an export definition that doesn't seem to be standard
> JavaScript:
>
> $ tail /usr/share/javascript/popper.js/popper.js
> …
> export default Popper;
>
> and indeed, using them in a browser raises an exception:
>
> Uncaught SyntaxError: Unexpected token export
>
> Using the umd/ versions work:
>
> /usr/share/javascript/popper.js/umd/popper.js
> /usr/share/javascript/popper.js/umd/popper.min.js
>
> I find this to be surprising behaviour, as I'd expect the toplevel
> versions to be valid JavaScript, and other fancy things to be in
> subdirectories, but I'm happy to stand corrected.
>

The top level files should indeed be removed, leaving just the two
directories
- esm stands for "es6 modules" which are the future format, very cool,
though as far as i know is not supported anywhere without some explicit
experimental flag.
- umd stands for "universal modules" and works everywhere

 Jérémy


Bug#926886: Please mention video->render change in udev.NEWS

2019-04-11 Thread Michael Biebl
Am 11.04.2019 um 22:47 schrieb Michael Biebl:
> Am 11.04.19 um 21:46 schrieb Guido Günther:

>> it took me a while to figure out why rendering got broken in my wayland
>> compositor. It would be great if the change from video to render group
>> could be mentioned in udev.NEWS.
> 
> That is unexpected.
> We still apply the uaccess tag for /dev/dri/renderD* so should be
> accessible to local, active sessions (including a wayland session)
> 

Btw, what exactly was the breakage?
I assume you worked around that for now by adding your user to group
render?
Which wayland compositor is that, btw? How do you start it?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#922098: RFE: matrix-synapse.service should have ExecReload

2019-04-11 Thread Jörg Sommer
On Tue, 12 Feb 2019 01:50:49 +0100 Damjan Georgievski  wrote:
> Package: matrix-synapse
> Version: 0.99.0-1
> 
> According to the 0.99 release info
> (https://github.com/matrix-org/synapse/releases/tag/v0.99.0) synapse
> now uses the HUP signal to reload certificates:
> > Synapse will now reload TLS certificates from disk upon SIGHUP. (#4495, 
> > #4524)
> 
> So the matrix-synapse.service unit file should include a reload directive:
> `ExecReload=/bin/kill -HUP $MAINPID`

But Synapse doesn't reload the config on SIGHUP, esp. it does not reload
the `tls_fingerprints` which is needed when certbot updates the TLS key.

Regards Jörg

-- 
Real programmers don't comment their code. It was hard to write,
it should be hard to understand.


signature.asc
Description: PGP signature


Bug#769366: zssh won't start: "out of pty's"

2019-04-11 Thread Jakub Wilk

* Ben Wong , 2017-12-22, 17:03:

Wait, that bug again? I fixed that a long time ago.


Indeed, you did. However, the critical part of the fix was regenerating 
the configure script (and to lesser extent config.h.in) from source. 
This was done at build time by adding:


  DEB_AUTO_UPDATE_AUTOHEADER := 2.61
  DEB_AUTO_UPDATE_AUTOCONF := 2.61

to debian/rules.

It turns out these two lines were removed without explanation in the 
1.5c.debian.1-3.2 NMU.


(This is not the only problem with this upload. It failed to follow the 
NMU guidelines (DevRef §5.11.1) in multiple ways:
* It changes source package format and patch system, whereas "fixing 
cosmetic issues or changing the packaging style [...] in NMUs is 
discouraged."

* The upload was without appropriate delay.
* NMU diff was not posted to the BTS.

Another undocumented change in the NMU is removal of the 
fake_readline/Makefile hunk from the 01_pre_cdbs.diff patch. No idea 
what's the consequence of that.)


It would be probably too invasive to add DEB_AUTO_UPDATE_* back in a 
stable upload (especially now that unstable has an entirely different 
fix for the bug), so I'd like to propose to regenerate autoconf stuff 
once and stick the diff into 04_GNU_openpty.patch. See the attached 
debdiff.


For the avoidance of doubt, I don't intend to do the actual upload. It 
is YunQiang's job to fix the regression.



As a side note, some people noticed that just rebuilding the package 
from source fixes the problem for them. This is because when openpty() 
is not available (or, in our case, when it's not detected correctly), 
the package falls back to getpt(), and that works. However, the 
configure test for UNIX 98 pseudoterminal naming is broken:


  if test -c /dev/ptmx && test -c /dev/pts/0

But /dev/pts/0 doesn't exist when nothing is using ptys at the moment; 
indeed, evidently it didn't exist when this package was built on 
buildds.


So regenerating autotools files is strictly required after all. 
No-change rebuilds wouldn't be sufficient.


--
Jakub Wilk
diff -Nru zssh-1.5c.debian.1/debian/changelog zssh-1.5c.debian.1/debian/changelog
--- zssh-1.5c.debian.1/debian/changelog	2014-07-21 10:27:39.0 +0200
+++ zssh-1.5c.debian.1/debian/changelog	2019-04-11 21:31:11.0 +0200
@@ -1,3 +1,9 @@
+zssh (1.5c.debian.1-3.2+deb9u1) stretch; urgency=low
+
+  * Regenerate autoconf files from source (closes: #769366).
+
+ -- Jakub Wilk   Thu, 11 Apr 2019 21:31:11 +0200
+
 zssh (1.5c.debian.1-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru zssh-1.5c.debian.1/debian/patches/04_GNU_openpty.patch zssh-1.5c.debian.1/debian/patches/04_GNU_openpty.patch
--- zssh-1.5c.debian.1/debian/patches/04_GNU_openpty.patch	2014-07-21 10:27:39.0 +0200
+++ zssh-1.5c.debian.1/debian/patches/04_GNU_openpty.patch	2019-04-11 21:31:11.0 +0200
@@ -40,3 +40,147 @@
  void	getmaster()
  {
  #ifdef DEBUG
+--- zssh-1.5c.debian.1.orig/configure
 zssh-1.5c.debian.1/configure
+@@ -1293,7 +1293,7 @@
+ fi
+ 
+ for ac_hdr in fcntl.h paths.h sys/ioctl.h sys/time.h termios.h unistd.h \
+-	err.h sys/cdefs.h sys/param.h util.h stropts.h
++	err.h sys/cdefs.h sys/param.h util.h stropts.h pty.h
+ do
+ ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'`
+ echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6
+@@ -1827,7 +1827,7 @@
+ 
+ 
+ 
+-for ac_func in _getpty getpseudotty openpty grantpt unlockpt
++for ac_func in _getpty getpseudotty grantpt unlockpt
+ do
+ echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
+ echo "configure:1834: checking for $ac_func" >&5
+@@ -1882,8 +1882,110 @@
+ fi
+ done
+ 
++for ac_func in openpty
++do
++echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
++echo "configure:1889: checking for $ac_func" >&5
++if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
++  echo $ac_n "(cached) $ac_c" 1>&6
++else
++  cat > conftest.$ac_ext <
++/* Override any gcc2 internal prototype to avoid an error.  */
++/* We use char because int might match the return type of a gcc2
++builtin and then its argument prototype would still apply.  */
++char $ac_func();
++
++int main() {
++
++/* The GNU C library defines this for functions which it implements
++to always fail with ENOSYS.  Some functions are actually named
++something starting with __ and the normal name is an alias.  */
++#if defined (__stub_$ac_func) || defined (__stub___$ac_func)
++choke me
++#else
++$ac_func();
++#endif
++
++; return 0; }
++EOF
++if { (eval echo configure:1917: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
++  rm -rf conftest*
++  eval "ac_cv_func_$ac_func=yes"
++else
++  echo "configure: failed program was:" >&5
++  cat conftest.$ac_ext >&5
++  rm -rf conftest*
++  eval "ac_cv_func_$ac_func=no"
++fi
++rm -f conftest*
++fi
++
++if eval "test \"`echo '$ac_cv_func_'$ac_func`\" = yes"; then
++  echo "$ac_t""yes" 1>&6
++ac_tr_func=HAVE_`echo $ac_func | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`

Bug#926897: stretch-pu: package audiofile/0.3.6-4+deb9u1

2019-04-11 Thread Moritz Muehlenhoff
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Fixes two minor security issue, debdiff below.

Cheers,
Moritz

diff -Nru audiofile-0.3.6/debian/changelog audiofile-0.3.6/debian/changelog
--- audiofile-0.3.6/debian/changelog2017-03-16 21:43:45.0 +0100
+++ audiofile-0.3.6/debian/changelog2019-04-11 00:28:31.0 +0200
@@ -1,3 +1,10 @@
+audiofile (0.3.6-4+deb9u1) stretch; urgency=medium
+
+  * CVE-2018-13440 (Closes: #903499)
+  * CVE-2018-17095 (Closes: #913166)
+
+ -- Moritz Mühlenhoff   Thu, 11 Apr 2019 00:28:31 +0200
+
 audiofile (0.3.6-4) unstable; urgency=high
 
   * Team upload.
diff -Nru audiofile-0.3.6/debian/patches/11_CVE-2018-13440.patch 
audiofile-0.3.6/debian/patches/11_CVE-2018-13440.patch
--- audiofile-0.3.6/debian/patches/11_CVE-2018-13440.patch  1970-01-01 
01:00:00.0 +0100
+++ audiofile-0.3.6/debian/patches/11_CVE-2018-13440.patch  2019-04-05 
16:10:40.0 +0200
@@ -0,0 +1,28 @@
+From fde6d79fb8363c4a329a184ef0b107156602b225 Mon Sep 17 00:00:00 2001
+From: Wim Taymans 
+Date: Thu, 27 Sep 2018 10:48:45 +0200
+Subject: [PATCH] ModuleState: handle compress/decompress init failure
+
+When the unit initcompress or initdecompress function fails,
+m_fileModule is NULL. Return AF_FAIL in that case instead of
+causing NULL pointer dereferences later.
+
+Fixes #49
+---
+ libaudiofile/modules/ModuleState.cpp | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/libaudiofile/modules/ModuleState.cpp 
b/libaudiofile/modules/ModuleState.cpp
+index 0c29d7a..070fd9b 100644
+--- a/libaudiofile/modules/ModuleState.cpp
 b/libaudiofile/modules/ModuleState.cpp
+@@ -75,6 +75,9 @@ status ModuleState::initFileModule(AFfilehandle file, Track 
*track)
+   m_fileModule = unit->initcompress(track, file->m_fh, 
file->m_seekok,
+   file->m_fileFormat == AF_FILE_RAWDATA, );
+ 
++  if (!m_fileModule)
++  return AF_FAIL;
++
+   if (unit->needsRebuffer)
+   {
+   assert(unit->nativeSampleFormat == AF_SAMPFMT_TWOSCOMP);
diff -Nru audiofile-0.3.6/debian/patches/12_CVE-2018-17095.patch 
audiofile-0.3.6/debian/patches/12_CVE-2018-17095.patch
--- audiofile-0.3.6/debian/patches/12_CVE-2018-17095.patch  1970-01-01 
01:00:00.0 +0100
+++ audiofile-0.3.6/debian/patches/12_CVE-2018-17095.patch  2019-04-05 
16:10:40.0 +0200
@@ -0,0 +1,26 @@
+From 822b732fd31ffcb78f6920001e9b1fbd815fa712 Mon Sep 17 00:00:00 2001
+From: Wim Taymans 
+Date: Thu, 27 Sep 2018 12:11:12 +0200
+Subject: [PATCH] SimpleModule: set output chunk framecount after pull
+
+After pulling the data, set the output chunk to the amount of
+frames we pulled so that the next module in the chain has the correct
+frame count.
+
+Fixes #50 and #51
+---
+ libaudiofile/modules/SimpleModule.cpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/libaudiofile/modules/SimpleModule.cpp 
b/libaudiofile/modules/SimpleModule.cpp
+index 2bae1eb..e87932c 100644
+--- a/libaudiofile/modules/SimpleModule.cpp
 b/libaudiofile/modules/SimpleModule.cpp
+@@ -26,6 +26,7 @@
+ void SimpleModule::runPull()
+ {
+   pull(m_outChunk->frameCount);
++  m_outChunk->frameCount = m_inChunk->frameCount;
+   run(*m_inChunk, *m_outChunk);
+ }
+ 
diff -Nru audiofile-0.3.6/debian/patches/series 
audiofile-0.3.6/debian/patches/series
--- audiofile-0.3.6/debian/patches/series   2017-03-16 21:38:15.0 
+0100
+++ audiofile-0.3.6/debian/patches/series   2019-04-11 00:28:31.0 
+0200
@@ -8,3 +8,5 @@
 08_Fix-signature-of-multiplyCheckOverflow.-It-returns-a-b.patch
 09_Actually-fail-when-error-occurs-in-parseFormat.patch
 10_Check-for-division-by-zero-in-BlockCodec-runPull.patch
+11_CVE-2018-13440.patch
+12_CVE-2018-17095.patch


Bug#926719: SFTP ProFTPD terminating (signal 11) after Update to 1.3.5e-0+deb8u1

2019-04-11 Thread Hilmar Preuße
On 09.04.19 17:01, Timo Müller wrote:

Hi Markus,

> Package: proftpd-basic
> Version: 1.3.5e-0+deb8u1
> 
> After the upgrade to 1.3.5e-0+deb8u1 is the login to the sftp server no 
> longer possible.
> 
> $ sftp x...@172.31.xxx.xxx
> 
> /var/log/proftpd/proftpd.log
> 2019-04-09 16:21:26,683 XX proftpd[11976] 172.31.XXX.XXX 
> (172.31.XXX.XXX[172.31.XXX.XXX]): SSH2 session opened.
> 2019-04-09 16:21:27,797 XX proftpd[11976] 172.31.XXX.XXX 
> (172.31.XXX.XXX[172.31.XXX.XXX]): USER XXX: Login successful
> 2019-04-09 16:21:27,797 XX proftpd[11976] 172.31.XXX.XXX 
> (172.31.XXX.XXX[172.31.XXX.XXX]): ProFTPD terminating (signal 11)
> 2019-04-09 16:21:27,798 XX proftpd[11976] 172.31.XXX.XXX 
> (172.31.XXX.XXX[172.31.XXX.XXX]): SSH2 session closed.
> 
> I am using Debian 8.11 
> Linux 3.16.0-8-amd64 #1 SMP Debian 3.16.64-2 (2019-04-01) x86_64 GNU/Linux
> 
Your latest upload to Debian oldstable introduced a new bug: the proftp
server now crashes, upon SSH connections. As I don't have an oldstable
system at hand: are you able to reproduce the issue using the package
you built?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature


Bug#920530: apparmor: Apparmour breaks bind/named DLZ with samba

2019-04-11 Thread Bernhard Schmidt
Am 04.04.19 um 18:16 schrieb Steven Monai:
> *Steven Monai writes:*
> So far, my buster Samba AD controller appears to be working correctly
> with the 'usr.sbin.named' profile in 'complain' mode. I will monitor the
> logs for a while to see if any further apparmor-related issues appear
> during my testing.
> 
> Some new apparmor "complaint" logs regarding the 'usr.sbin.named'
> profile have appeared on my buster Samba AD controller. Here are two
> representative log lines:
> 
> Apr  3 14:25:40 dc1 kernel: [19735.831647] audit: type=1400
> audit(1554326740.971:14): apparmor="ALLOWED" operation="file_lock"
> profile="/usr/sbin/named" name="/var/lib/samba/bind-dns/dns.keytab"
> pid=421 comm="isc-worker" requested_mask="k" denied_mask="k"
> fsuid=108 ouid=0
> Apr  3 14:25:40 dc1 kernel: [19735.832328] audit: type=1400
> audit(1554326740.971:15): apparmor="ALLOWED" operation="open"
> profile="/usr/sbin/named" name="/dev/urandom" pid=421
> comm="isc-worker" requested_mask="wc" denied_mask="wc" fsuid=108 ouid=0
> 
> In response to the first log, I have appended the following line to
> '/etc/apparmor.d/local/usr.sbin.named':
> 
> /var/lib/samba/bind-dns/dns.keytab k,

Thanks, I've adapted the previous setting and added "k" to both
dns.keytab entries. Will upload shortly.

Any more warnings you experienced?

> 
> For the second log, I am unsure how to provide appropriate access to
> '/dev/urandom', as I don't understand what the denied_mask="wc" means.
> Maybe simple "read" (r) access would cover it, like this (?):
> 
> /dev/urandom r,

I'm unsure about that either. Ccing the Apparmor maintainer, I'm not
sure whether anything additional is needed for access to /dev/urandom.

Bernhard



Bug#926896: sysvinit-utils: pidof is unreliable

2019-04-11 Thread Witold Baryluk
Package: sysvinit-utils
Version: 2.93-8
Severity: important

root@debian:~# echo; whoami; echo; ps aux | grep 'dd if'; echo; hd 
/proc/41344/cmdline ; echo; ls -l /proc/41344/exe; echo; pidof dd || echo "Not 
found"; echo; ls -l /proc/41344/exe

root

root  41344  2.0  0.0 217704  1960 pts/3D+   20:40   0:09 dd 
if=/dev/sdc of=/dev/null bs=64k
root  42045  0.0  0.0 218480   828 pts/9S+   20:48   0:00 grep dd if

  64 64 00 69 66 3d 2f 64  65 76 2f 73 64 63 00 6f  |dd.if=/dev/sdc.o|
0010  66 3d 2f 64 65 76 2f 6e  75 6c 6c 00 62 73 3d 36  |f=/dev/null.bs=6|
0020  34 6b 00  |4k.|
0023

lrwxrwxrwx 1 root root 0 Apr 11 20:44 /proc/41344/exe -> /usr/bin/dd

Not found

lrwxrwxrwx 1 root root 0 Apr 11 20:44 /proc/41344/exe -> /usr/bin/dd
root@debian:~# 


For some reason pidof can't find 'dd'. pidof dd prints nothing and
returns false (exit code 1).

Both dd and pidof are running as root.

killall -USR1 dd , delivers a signal to correct process, so killall (from
psmisc package) does find it.


Thanks.


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

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

Versions of packages sysvinit-utils depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-8
ii  util-linux   2.33.1-0.1

sysvinit-utils recommends no packages.

sysvinit-utils suggests no packages.

-- no debconf information



Bug#538304: insserv: start and stop in same runlevel

2019-04-11 Thread Jesse Smith
On 4/11/19 7:43 AM, Dmitry Bogatov wrote:
> [2019-01-24 19:42] Jesse Smith 
>> I'm looking into this bug in insserv and want to make sure I'm
>> understanding the issue correctly. As I read it, the problem is that if
>> the user specifies the same runlevel in both the Default-Start and
>> Default-Stop fields, insserv will set up the "Stop" symbolic link, but
>> will not complain about it?
>>
>> Ideally, insserv should probably still use this behaviour, but print a
>> warning that the same runlevels should not be listed in both the
>> Default-Start and Default-Stop fields. Is this a correct summary of the
>> above request?
> Yes, seems so.

I have addressed this upstream. The next version of insserv will print a
warning when an init.d script has the same runlevel specified in the
Default-Start and Default-Stop fields. The output looks like this:

   insserv: Script bluetooth has overlapping Default-Start and
Default-Stop runlevels (2 3 4 5) and (0 1 3 6). This should be fixed.

Apart from the warning, insserv functions as before.

- Jesse



Bug#926891: unblock: libreoffice/1:6.1.5-3

2019-04-11 Thread Rene Engelhard
Hi,

On Thu, Apr 11, 2019 at 10:31:06PM +0200, Rene Engelhard wrote:
> diff -Nru libreoffice-6.1.5/debian/changelog 
> libreoffice-6.1.5/debian/changelog
> --- libreoffice-6.1.5/debian/changelog2019-04-03 13:19:34.0 
> +0200
> +++ libreoffice-6.1.5/debian/changelog2019-04-03 13:19:34.0 
> +0200
> @@ -1,3 +1,10 @@
> +libreoffice (1:6.1.5-3) unstable; urgency=medium
> +
> +  * debian/patches/jp-JP-Reiwa.diff: Introduce next Japanese gengou
> +era 'Reiwa', from libreoffice-6-1 branch
> +
> + -- Rene Engelhard   Wed, 03 Apr 2019 13:19:34 +0200

+ -- Rene Engelhard   Thu, 11 Apr 2019 22:39:53 +0200

obviously, thanks lintian...


Regards,

Rene



Bug#926886: Please mention video->render change in udev.NEWS

2019-04-11 Thread Michael Biebl
Control: notfound -1 243-1
Control: found -1 241-3

Hi Guido

Am 11.04.19 um 21:46 schrieb Guido Günther:
> Package: udev
> Version: 243-1

I suppose you meant 241-3 here...

> Severity: normal
> 
> Hi,
> it took me a while to figure out why rendering got broken in my wayland
> compositor. It would be great if the change from video to render group
> could be mentioned in udev.NEWS.

That is unexpected.
We still apply the uaccess tag for /dev/dri/renderD* so should be
accessible to local, active sessions (including a wayland session)

Can you paste the output of
getfacl /dev/dri/renderD*


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#926894: stretch-pu: package igraph/0.7.1-2.1+deb9u1

2019-04-11 Thread Dylan Aïssi
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,
Upstream has fixed CVE-2018-20349 which is non-dsa.
The patch is already backported to unstable/testing and now I would
like to fix the Stretch version.
Please find attached a corresponding debdiff.

Best,
Dylan


igraph_0.7.1-2.1+deb9u1.debdiff
Description: Binary data


Bug#926895: libxslt: CVE-2019-11068

2019-04-11 Thread Salvatore Bonaccorso
Source: libxslt
Version: 1.1.32-2
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/libxslt/issues/12

Hi,

The following vulnerability was published for libxslt.

CVE-2019-11068[0]:
| libxslt through 1.1.33 allows bypass of a protection mechanism because
| callers of xsltCheckRead and xsltCheckWrite permit access even upon
| receiving a -1 error code. xsltCheckRead can return -1 for a crafted
| URL that is not actually invalid and is subsequently loaded.


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-2019-11068
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11068
[1] https://gitlab.gnome.org/GNOME/libxslt/issues/12
[2] 
https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#926893: RFP: btrfs-profilers -- btrfs-profilers is a collection of BCC based btrfs performance analyse tools

2019-04-11 Thread Christoph Anton Mitterer
Package: wnpp
Severity: wishlist

* Package name: btrfs-profilers
  Version : git
  Upstream Author : Qu Wenruo 
* URL : https://github.com/adam900710/btrfs-profiler
* License : GPLv2
  Programming Lang: Python
  Description : btrfs-profilers is a collection of BCC based btrfs 
performance analyse tools



Bug#926199: stretch-pu: package libreoffice/1:5.2.7-1+deb9u6

2019-04-11 Thread Rene Engelhard
retitle 926199 stretch-pu: package libreoffice/1:5.2.7-1+deb9u7
thanks

Hi,

this is now 1:5.2.7-1+deb9u7 given the Reiwa fix...

New diff will follow.

Regards,

Rene



Bug#926891: unblock: libreoffice/1:6.1.5-3

2019-04-11 Thread Rene Engelhard
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libreoffice

I think we should update busters (via sid...) LibreOffice with the new Japanese 
era.
This is just applying the upstream fix from
https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-1=39de7d73fdab86a1531f19076ab1d07fcff97b55

Diff:

diff -Nru libreoffice-6.1.5/debian/changelog libreoffice-6.1.5/debian/changelog
--- libreoffice-6.1.5/debian/changelog  2019-04-03 13:19:34.0 +0200
+++ libreoffice-6.1.5/debian/changelog  2019-04-03 13:19:34.0 +0200
@@ -1,3 +1,10 @@
+libreoffice (1:6.1.5-3) unstable; urgency=medium
+
+  * debian/patches/jp-JP-Reiwa.diff: Introduce next Japanese gengou
+era 'Reiwa', from libreoffice-6-1 branch
+
+ -- Rene Engelhard   Wed, 03 Apr 2019 13:19:34 +0200
+
 libreoffice (1:6.1.5-2) unstable; urgency=medium

   * debian/patches/mention-java-common-package.diff: update message to
diff -Nru libreoffice-6.1.5/debian/patches/jp-JP-Reiwa.diff 
libreoffice-6.1.5/debian/patches/jp-JP-Reiwa.diff
--- libreoffice-6.1.5/debian/patches/jp-JP-Reiwa.diff   1970-01-01 
01:00:00.0 +0100
+++ libreoffice-6.1.5/debian/patches/jp-JP-Reiwa.diff   2019-04-03 
13:19:34.0 +0200
@@ -0,0 +1,89 @@
+From 39de7d73fdab86a1531f19076ab1d07fcff97b55 Mon Sep 17 00:00:00 2001
+From: Eike Rathke 
+Date: Thu, 26 Jul 2018 20:46:23 +0200
+Subject: Introduce next Japanese gengou era 'Reiwa'
+
+Prepare for "Japan's Y2K" Gengou calendar era switch after 2019-04-30
+
+The emperor Akihito will abdicate on 2019-04-30. The next emperor
+will be Naruhito, but so far neither the new era name (Heisei for
+Akihito) nor its abbreviation or a Unicode character are
+determined. At least introduce the new era with some dummy names
+(Naruhito,Na,N).
+
+Change-Id: I8c0af390ca0408ac259e47e7eaf2e49b5889c9ba
+Reviewed-on: https://gerrit.libreoffice.org/58142
+Reviewed-by: Eike Rathke 
+Tested-by: Jenkins
+
+Introduce next Japanese gengou era 'Reiwa'
+
+starting from 2019-05-01, which has been announced officially.
+
+This fills the provisional slot acknowledged at
+cacbb0faef77ae8462de9ff5c7307a6a2e28b2bb.
+
+Change-Id: Ifb12e6afaad4c66d455f664b46ec946e80324e87
+Reviewed-on: https://gerrit.libreoffice.org/70157
+Reviewed-by: Eike Rathke 
+Tested-by: Jenkins
+Reviewed-on: https://gerrit.libreoffice.org/70185
+---
+ i18npool/source/calendar/calendar_gregorian.cxx | 9 +
+ i18npool/source/localedata/data/ja_JP.xml   | 5 +
+ svl/source/numbers/zformat.cxx  | 3 +++
+ 3 files changed, 13 insertions(+), 4 deletions(-)
+
+diff --git a/i18npool/source/calendar/calendar_gregorian.cxx 
b/i18npool/source/calendar/calendar_gregorian.cxx
+index a4ac0ac..7abef52 100644
+--- a/i18npool/source/calendar/calendar_gregorian.cxx
 b/i18npool/source/calendar/calendar_gregorian.cxx
+@@ -205,10 +205,11 @@ Calendar_hanja::loadCalendar( const OUString& 
/*uniqueID*/, const css::lang::Loc
+ }
+
+ static const Era gengou_eraArray[] = {
+-{1868,  1,  1, 0},
+-{1912,  7, 30, 0},
+-{1926, 12, 25, 0},
+-{1989,  1,  8, 0},
++{1868,  1,  1, 0},  // Meiji
++{1912,  7, 30, 0},  // Taisho
++{1926, 12, 25, 0},  // Showa
++{1989,  1,  8, 0},  // Heisei
++{2019,  5,  1, 0},  // Reiwa
+ {0, 0, 0, 0}
+ };
+ Calendar_gengou::Calendar_gengou() : Calendar_gregorian(gengou_eraArray)
+diff --git a/i18npool/source/localedata/data/ja_JP.xml 
b/i18npool/source/localedata/data/ja_JP.xml
+index 7d75260..c15c665 100644
+--- a/i18npool/source/localedata/data/ja_JP.xml
 b/i18npool/source/localedata/data/ja_JP.xml
+@@ -480,6 +480,11 @@
+   平
+   平成
+ 
++
++  Reiwa
++  令
++  令和
++
+   
+   
+ sun
+diff --git a/svl/source/numbers/zformat.cxx b/svl/source/numbers/zformat.cxx
+index c9bd3d8..e14413c 100644
+--- a/svl/source/numbers/zformat.cxx
 b/svl/source/numbers/zformat.cxx
+@@ -3409,6 +3409,9 @@ void SvNumberformat::ImpAppendEraG( OUStringBuffer& 
OutString,
+ case 4:
+ cEra = 'H';
+ break;
++case 5:
++cEra = 'R';
++break;
+ default:
+ cEra = '?';
+ break;
+--
+cgit v1.1
+
diff -Nru libreoffice-6.1.5/debian/patches/series 
libreoffice-6.1.5/debian/patches/series
--- libreoffice-6.1.5/debian/patches/series 2019-04-03 13:19:34.0 
+0200
+++ libreoffice-6.1.5/debian/patches/series 2019-04-03 13:19:34.0 
+0200
@@ -49,3 +49,4 @@
 apparmor-opencl.diff
 tdf123077.diff
 java.vendor-Debian.diff
+jp-JP-Reiwa.diff

unblock libreoffice/1:6.1.5-3

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-4-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 

Bug#904098: pulseaudio: Pulseaudio only provides Dummy Output until timidity is killed

2019-04-11 Thread Marco Mattiolo
Hi,

just needed to thank you for reporting this: I just upgraded my system 
to Buster (as it is freezed, I hoped for the best) and the only sound 
output in KDE system manager was 'dummy', no audio output. Removing 
timidity got audio back working.

Now I'm not able to change audio output through system tray icon or even 
system manager: changing audio configuration is possible only through 
Pavucontrol.

Definitely an annoying bug!

Kind regards

Marco



Bug#926890: unblock: audiofile/0.3.6-5

2019-04-11 Thread Moritz Muehlenhoff
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package audiofile. It fixes two security issues
and updates the meta data away from Alioth to Salsa.

unblock audiofile/0.3.6-5

Cheers,
Moritz

diff -Nru audiofile-0.3.6/debian/changelog audiofile-0.3.6/debian/changelog
--- audiofile-0.3.6/debian/changelog2017-03-16 21:43:45.0 +0100
+++ audiofile-0.3.6/debian/changelog2019-04-05 16:13:16.0 +0200
@@ -1,10 +1,28 @@
+audiofile (0.3.6-5) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Ondřej Nový ]
+  * d/control: Set Vcs-* to salsa.debian.org
+  * d/copyright: Use https protocol in Format field
+
+  [ Felipe Sateler ]
+  * Change maintainer address to debian-multime...@lists.debian.org
+
+  [ Moritz Mühlenhoff ]
+  * Two security fixes from the https://github.com/wtay/audiofile fork:
+CVE-2018-13440 (Closes: #903499)
+CVE-2018-17095 (Closes: #913166)
+
+ -- Sebastian Ramacher   Fri, 05 Apr 2019 16:13:16 +0200
+
 audiofile (0.3.6-4) unstable; urgency=high
 
   * Team upload.
-  * debian/patches: Apply patches to fix CVE-2017-6829, CVE-2017-6831,
-CVE-2017-6832, CVE-2017-6833, CVE-2017-6834, CVE-2017-6835, CVE-2017-6836,
-CVE-2017-6837, CVE-2017-6838, CVE-2017-6839, CVE-2017-6827, CVE-2017-6828.
-(Closes: #857651)
+  * debian/patches: Apply patches to fix CVE-2017-6827, CVE-2017-6828,
+CVE-2017-6829, CVE-2017-6830, CVE-2017-6831, CVE-2017-6832, CVE-2017-6833,
+CVE-2017-6834, CVE-2017-6835, CVE-2017-6836, CVE-2017-6837, CVE-2017-6838,
+CVE-2017-6839. (Closes: #857651)
 
  -- Sebastian Ramacher   Thu, 16 Mar 2017 21:43:45 +0100
 
@@ -471,7 +489,7 @@
 
 audiofile (0.1.5-5) unstable; urgency=low
 
-  * Added extra documentation (#32366) 
+  * Added extra documentation (#32366)
 
  -- Brian M. Almeida   Wed,  3 Feb 1999 13:13:08 -0500
 
diff -Nru audiofile-0.3.6/debian/control audiofile-0.3.6/debian/control
--- audiofile-0.3.6/debian/control  2017-03-16 21:11:18.0 +0100
+++ audiofile-0.3.6/debian/control  2019-04-05 16:10:40.0 +0200
@@ -1,7 +1,7 @@
 Source: audiofile
 Section: libs
 Priority: optional
-Maintainer: Debian Multimedia Maintainers 

+Maintainer: Debian Multimedia Maintainers 
 Uploaders:
  Alessio Treglia 
 Build-Depends:
@@ -12,8 +12,8 @@
  pkg-config
 Standards-Version: 3.9.8
 Homepage: http://audiofile.68k.org/
-Vcs-Git: https://anonscm.debian.org/git/pkg-multimedia/audiofile.git
-Vcs-Browser: https://anonscm.debian.org/cgit/pkg-multimedia/audiofile.git
+Vcs-Git: https://salsa.debian.org/multimedia-team/audiofile.git
+Vcs-Browser: https://salsa.debian.org/multimedia-team/audiofile
 
 Package: audiofile-tools
 Section: utils
diff -Nru audiofile-0.3.6/debian/copyright audiofile-0.3.6/debian/copyright
--- audiofile-0.3.6/debian/copyright2017-03-16 21:11:18.0 +0100
+++ audiofile-0.3.6/debian/copyright2019-04-05 16:10:40.0 +0200
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: audiofile
 Upstream-Contact: Michael Pruett 
 Source: http://www.68k.org/~michael/audiofile/
diff -Nru audiofile-0.3.6/debian/patches/11_CVE-2018-13440.patch 
audiofile-0.3.6/debian/patches/11_CVE-2018-13440.patch
--- audiofile-0.3.6/debian/patches/11_CVE-2018-13440.patch  1970-01-01 
01:00:00.0 +0100
+++ audiofile-0.3.6/debian/patches/11_CVE-2018-13440.patch  2019-04-05 
16:10:40.0 +0200
@@ -0,0 +1,28 @@
+From fde6d79fb8363c4a329a184ef0b107156602b225 Mon Sep 17 00:00:00 2001
+From: Wim Taymans 
+Date: Thu, 27 Sep 2018 10:48:45 +0200
+Subject: [PATCH] ModuleState: handle compress/decompress init failure
+
+When the unit initcompress or initdecompress function fails,
+m_fileModule is NULL. Return AF_FAIL in that case instead of
+causing NULL pointer dereferences later.
+
+Fixes #49
+---
+ libaudiofile/modules/ModuleState.cpp | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/libaudiofile/modules/ModuleState.cpp 
b/libaudiofile/modules/ModuleState.cpp
+index 0c29d7a..070fd9b 100644
+--- a/libaudiofile/modules/ModuleState.cpp
 b/libaudiofile/modules/ModuleState.cpp
+@@ -75,6 +75,9 @@ status ModuleState::initFileModule(AFfilehandle file, Track 
*track)
+   m_fileModule = unit->initcompress(track, file->m_fh, 
file->m_seekok,
+   file->m_fileFormat == AF_FILE_RAWDATA, );
+ 
++  if (!m_fileModule)
++  return AF_FAIL;
++
+   if (unit->needsRebuffer)
+   {
+   assert(unit->nativeSampleFormat == AF_SAMPFMT_TWOSCOMP);
diff -Nru audiofile-0.3.6/debian/patches/12_CVE-2018-17095.patch 
audiofile-0.3.6/debian/patches/12_CVE-2018-17095.patch
--- audiofile-0.3.6/debian/patches/12_CVE-2018-17095.patch  1970-01-01 
01:00:00.0 +0100
+++ audiofile-0.3.6/debian/patches/12_CVE-2018-17095.patch  2019-04-05 

Bug#926892: stretch-pu: package libreoffice/1:5.2.7-1+deb9u6

2019-04-11 Thread Rene Engelhard
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I think we should update stables LibreOffice with the new Japanese era
(and maybe even stable-updates?):

This is basically the 1:6.1.5-3 fix applied 1:1 with the obvious
changelog/series differences:

diff -Nru libreoffice-5.2.7/debian/changelog libreoffice-5.2.7/debian/changelog
--- libreoffice-5.2.7/debian/changelog  2019-01-23 18:51:09.0 +0100
+++ libreoffice-5.2.7/debian/changelog  2019-04-11 21:48:53.0 +0200
@@ -1,3 +1,10 @@
+libreoffice (1:5.2.7-1+deb9u6) stable; urgency=medium
+
+   * debian/patches/jp-JP-Reiwa.diff: Introduce next Japanese gengou
+ era 'Reiwa', from libreoffice-6-1 branch
+
+ -- Rene Engelhard   Thu, 11 Apr 2019 21:48:53 +0200
+
 libreoffice (1:5.2.7-1+deb9u5) stretch-security; urgency=high
 
   * debian/patches/disableClassPathURLCheck.diff: add workaround to
diff -Nru libreoffice-5.2.7/debian/patches/jp-JP-Reiwa.diff 
libreoffice-5.2.7/debian/patches/jp-JP-Reiwa.diff
--- libreoffice-5.2.7/debian/patches/jp-JP-Reiwa.diff   1970-01-01 
01:00:00.0 +0100
+++ libreoffice-5.2.7/debian/patches/jp-JP-Reiwa.diff   2019-04-11 
21:48:33.0 +0200
@@ -0,0 +1,89 @@
+From 39de7d73fdab86a1531f19076ab1d07fcff97b55 Mon Sep 17 00:00:00 2001
+From: Eike Rathke 
+Date: Thu, 26 Jul 2018 20:46:23 +0200
+Subject: Introduce next Japanese gengou era 'Reiwa'
+
+Prepare for "Japan's Y2K" Gengou calendar era switch after 2019-04-30
+
+The emperor Akihito will abdicate on 2019-04-30. The next emperor
+will be Naruhito, but so far neither the new era name (Heisei for
+Akihito) nor its abbreviation or a Unicode character are
+determined. At least introduce the new era with some dummy names
+(Naruhito,Na,N).
+
+Change-Id: I8c0af390ca0408ac259e47e7eaf2e49b5889c9ba
+Reviewed-on: https://gerrit.libreoffice.org/58142
+Reviewed-by: Eike Rathke 
+Tested-by: Jenkins
+
+Introduce next Japanese gengou era 'Reiwa'
+
+starting from 2019-05-01, which has been announced officially.
+
+This fills the provisional slot acknowledged at
+cacbb0faef77ae8462de9ff5c7307a6a2e28b2bb.
+
+Change-Id: Ifb12e6afaad4c66d455f664b46ec946e80324e87
+Reviewed-on: https://gerrit.libreoffice.org/70157
+Reviewed-by: Eike Rathke 
+Tested-by: Jenkins
+Reviewed-on: https://gerrit.libreoffice.org/70185
+---
+ i18npool/source/calendar/calendar_gregorian.cxx | 9 +
+ i18npool/source/localedata/data/ja_JP.xml   | 5 +
+ svl/source/numbers/zformat.cxx  | 3 +++
+ 3 files changed, 13 insertions(+), 4 deletions(-)
+
+diff --git a/i18npool/source/calendar/calendar_gregorian.cxx 
b/i18npool/source/calendar/calendar_gregorian.cxx
+index a4ac0ac..7abef52 100644
+--- a/i18npool/source/calendar/calendar_gregorian.cxx
 b/i18npool/source/calendar/calendar_gregorian.cxx
+@@ -205,10 +205,11 @@ Calendar_hanja::loadCalendar( const OUString& 
/*uniqueID*/, const css::lang::Loc
+ }
+ 
+ static const Era gengou_eraArray[] = {
+-{1868,  1,  1, 0},
+-{1912,  7, 30, 0},
+-{1926, 12, 25, 0},
+-{1989,  1,  8, 0},
++{1868,  1,  1, 0},  // Meiji
++{1912,  7, 30, 0},  // Taisho
++{1926, 12, 25, 0},  // Showa
++{1989,  1,  8, 0},  // Heisei
++{2019,  5,  1, 0},  // Reiwa
+ {0, 0, 0, 0}
+ };
+ Calendar_gengou::Calendar_gengou() : Calendar_gregorian(gengou_eraArray)
+diff --git a/i18npool/source/localedata/data/ja_JP.xml 
b/i18npool/source/localedata/data/ja_JP.xml
+index 7d75260..c15c665 100644
+--- a/i18npool/source/localedata/data/ja_JP.xml
 b/i18npool/source/localedata/data/ja_JP.xml
+@@ -480,6 +480,11 @@
+   平
+   平成
+ 
++
++  Reiwa
++  令
++  令和
++
+   
+   
+ sun
+diff --git a/svl/source/numbers/zformat.cxx b/svl/source/numbers/zformat.cxx
+index c9bd3d8..e14413c 100644
+--- a/svl/source/numbers/zformat.cxx
 b/svl/source/numbers/zformat.cxx
+@@ -3409,6 +3409,9 @@ void SvNumberformat::ImpAppendEraG( OUStringBuffer& 
OutString,
+ case 4:
+ cEra = 'H';
+ break;
++case 5:
++cEra = 'R';
++break;
+ default:
+ cEra = '?';
+ break;
+-- 
+cgit v1.1
+
diff -Nru libreoffice-5.2.7/debian/patches/series 
libreoffice-5.2.7/debian/patches/series
--- libreoffice-5.2.7/debian/patches/series 2018-12-28 11:20:43.0 
+0100
+++ libreoffice-5.2.7/debian/patches/series 2019-04-11 21:48:53.0 
+0200
@@ -42,3 +42,4 @@
 disableClassPathURLCheck.diff
 keep-pyuno-script-processing-below-base-uri.diff
 show-partial-signatures-even-if-cert-validation-fails.diff
+jp-JP-Reiwa.diff

Given https://lists.debian.org/debian-devel-announce/2018/04/msg7.html
already uploaded.

(Also already fixed in sid for LibreOffice 1:6.1.5-3, filing a unblock bug
for it. too)

Regards,

Rene



Bug#923283: dovecot-sieve: panic in i_stream_concat_close: assertion failed: (cstream->cur_input == cstream->input[cstream->cur_idx])

2019-04-11 Thread Timo Sirainen
On 26 Feb 2019, at 9.20, Graham Cobb  wrote:
> 
> When processing a particular type of notification email, I consistently get 
> the
> following sieve crash during execution of /usr/lib/dovecot/dovecot-lda.
> (note, extracted from mail.log and reformatted a little for readability)
> 
> Feb 25 19:22:46 black dovecot: lda(cobb)<7721>: 
> Panic: file istream-concat.c:
> line 25 (i_stream_concat_close): assertion failed: (cstream->cur_input == 
> cstream->input[cstream->cur_idx])
..
> The actual line in the sieve script being executed at the time of the crash 
> is the first line of
> the following (the test would not be satisfied on this message):
> 
> if body :raw :contains "://docs.google.com" {
>addheader "X-GRC-SIEVE-Message" "Deleted by Google Docs low 
> tolerance filter";
>   fileinto "${spam_medium}";
>   stop;
>}
> 
> If I comment out that test, or even just remove the ":raw" clause, the script 
> executes.
> However a small script just containing that test does not crash.
> 
> I would rather not attach the full scripts to this report, but can provide 
> them to the
> maintainer if required.

Is this still happening? Could you send me/Stephan the full Sieve script that 
causes the crash? As you said, it's not enough to cause the crash with just 
that small snippet.



Bug#926889: unblock: graphviz/2.40.1-6

2019-04-11 Thread Laszlo Boszormenyi (GCS)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi Release Team,

Please unblock graphviz which fixes a vulnerability,
CVE-2018-10196 [1].
The debdiff which is attached contains some extra self-tests over the
fix.

Thanks for consideration,
Laszlo/GCS
[1] https://bugs.debian.org/898841
diff -Nru graphviz-2.40.1/debian/changelog graphviz-2.40.1/debian/changelog
--- graphviz-2.40.1/debian/changelog	2018-10-03 15:04:59.0 +
+++ graphviz-2.40.1/debian/changelog	2019-04-08 15:51:00.0 +
@@ -1,3 +1,10 @@
+graphviz (2.40.1-6) unstable; urgency=high
+
+  * Fix CVE-2018-10196: NULL pointer dereference in rebuild_vlists()
+(closes: #898841).
+
+ -- Laszlo Boszormenyi (GCS)   Mon, 08 Apr 2019 15:51:00 +
+
 graphviz (2.40.1-5) unstable; urgency=medium
 
   * Patch upstream _gv.so symlink creation (closes: #905209).
diff -Nru graphviz-2.40.1/debian/patches/CVE-2018-10196.patch graphviz-2.40.1/debian/patches/CVE-2018-10196.patch
--- graphviz-2.40.1/debian/patches/CVE-2018-10196.patch	1970-01-01 00:00:00.0 +
+++ graphviz-2.40.1/debian/patches/CVE-2018-10196.patch	2019-04-08 15:51:00.0 +
@@ -0,0 +1,605 @@
+diff --git a/configure.ac b/configure.ac
+index b0762993c299fcd3d9040aec19d99425132b42f2..6f743e9d23e072301bd94f58b3fb865fee804f0e 100644
+--- a/configure.ac
 b/configure.ac
+@@ -3363,6 +3363,7 @@ AC_CONFIG_FILES(Makefile
+   tests/unit_tests/lib/common/Makefile
+   tests/regression_tests/Makefile
+   tests/regression_tests/shapes/Makefile
++	tests/regression_tests/vuln/Makefile
+ 	share/Makefile
+ 	share/examples/Makefile
+ 	share/gui/Makefile
+diff --git a/lib/dotgen/conc.c b/lib/dotgen/conc.c
+index dd13e936bf25d17d8baa5b3b9e089cff35c502fe..f7307d23b3ff9151b283c9b045892a80c0d6c055 100644
+--- a/lib/dotgen/conc.c
 b/lib/dotgen/conc.c
+@@ -159,7 +159,11 @@ static void rebuild_vlists(graph_t * g)
+ 
+ for (r = GD_minrank(g); r <= GD_maxrank(g); r++) {
+ 	lead = GD_rankleader(g)[r];
+-	if (GD_rank(dot_root(g))[r].v[ND_order(lead)] != lead) {
++	if (lead == NULL) {
++		agerr(AGERR, "rebuiltd_vlists: lead is null for rank %d\n", r);
++		longjmp(jbuf, 1);
++	}
++	else if (GD_rank(dot_root(g))[r].v[ND_order(lead)] != lead) {
+ 	agerr(AGERR, "rebuiltd_vlists: rank lead %s not in order %d of rank %d\n", 
+ 		agnameof(lead), ND_order(lead), r);
+ 	longjmp(jbuf, 1);
+diff --git a/tests/regression_tests/Makefile.am b/tests/regression_tests/Makefile.am
+index c375449ad3f30834eb10b19a6174977354d41230..c472181c13387de9c579f533e17d1a749fb0b534 100644
+--- a/tests/regression_tests/Makefile.am
 b/tests/regression_tests/Makefile.am
+@@ -1 +1 @@
+-SUBDIRS = shapes
++SUBDIRS = shapes vuln
+diff --git a/tests/regression_tests/vuln/Makefile.am b/tests/regression_tests/vuln/Makefile.am
+new file mode 100644
+index ..e58fc3cde6384a581914f92edcacd815f4738e80
+--- /dev/null
 b/tests/regression_tests/vuln/Makefile.am
+@@ -0,0 +1,2 @@
++check test rtest:
++	python vuln.py
+diff --git a/tests/regression_tests/vuln/input/nullderefrebuildlist.dot b/tests/regression_tests/vuln/input/nullderefrebuildlist.dot
+new file mode 100644
+index ..31a15a1dad27aa8a34bd47b297eb02bfdf1a6f9c
+--- /dev/null
 b/tests/regression_tests/vuln/input/nullderefrebuildlist.dot
+@@ -0,0 +1,55 @@
++digraph G {
++graph [concentrate=true];
++
++routine1;
++routine2;
++
++rfontsize=9;
++nodesep="0.4";
++ranksep="0.4";
++node [fontname=Arial, fontsize=9, shape=box];
++subgraph clustere3ffa58211d69e3db000538bf02fa1d0 { 
++label = "DriveCom Z";
++Ie3ffa58211d69e3db000538bf02fa1d0 [label="", shape=circle, style=filled, color=black, width=.2];
++Se3ffa4bf11d69e3db000538bf02fa1d0 [label="Idle"];
++Se3ffa7b011d69e3db000538bf02fa1d0 [label="Disabled"];
++subgraph clustere3ffa77611d69e3db000538bf02fa1d0 { 
++label = "Active";
++Ie3ffa77611d69e3db000538bf02fa1d0 [label="", shape=circle, style=filled, color=black, width=.2];
++Se3€fa84b11d69e3db000538bf02fa1d0 [label="Undefined"];
++Se3ffa60811d69e3db000538bf02fa1d0 [label="Wait Switch On Inhibit"];
++Se3ffa87211d69e3db000538bf02fa1d0 [label="Switch On Inhibit"];
++Se3ffa65611d69e3db000538bf02fa1d0 [label="Wait Ready To Switch On"];
++Se3ffa61c11d69e3db000538bf02fa1d0 [label="Ready To Switch On"];
++Se3ffa53211d69e3db000538bf02fa1d0 [label="Wait Switched On"];
++Se3ffa8ac11d69e3db000538bf02fa1d0 [label="Switched On"];
++Se3ffa83711d69e3db000538bf02fa1d0 [label="Wait Operation Enabled"];
++Se3ffa81011d69e3db000538bf02fa1d0 [label="Operation Enabled"];
++Se3ffa8d311d69e3db000538bf02fa1d0 [label="Quick Stop Active"];
++ } 
++Se3ffa90d11d69e3db000538bf02fa1d0 [label="Moverlapion"];
++ } 

Bug#926888: unblock: wget/1.20.1-1.1

2019-04-11 Thread Salvatore Bonaccorso
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

Please unblock package wget

It fixes CVE-2019-5953, #926389 a buffer overflow vulnerability in the
handling of Internationalized Resource Identifiers (IRI), it was
adressed as well in DSA-4425-1 for stretch.

Attached is the debdiff between 1.20.1-1 and 1.20.1-1.1.

unblock wget/1.20.1-1.1

Regards,
Salvatore
diff -Nru wget-1.20.1/debian/changelog wget-1.20.1/debian/changelog
--- wget-1.20.1/debian/changelog2018-12-27 18:53:18.0 +0100
+++ wget-1.20.1/debian/changelog2019-04-05 15:36:38.0 +0200
@@ -1,3 +1,10 @@
+wget (1.20.1-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix a buffer overflow vulnerability (CVE-2019-5953) (Closes: #926389)
+
+ -- Salvatore Bonaccorso   Fri, 05 Apr 2019 15:36:38 +0200
+
 wget (1.20.1-1) unstable; urgency=high
 
   * new upstream release 2018-12-26
diff -Nru wget-1.20.1/debian/patches/Fix-a-buffer-overflow-vulnerability.patch 
wget-1.20.1/debian/patches/Fix-a-buffer-overflow-vulnerability.patch
--- wget-1.20.1/debian/patches/Fix-a-buffer-overflow-vulnerability.patch
1970-01-01 01:00:00.0 +0100
+++ wget-1.20.1/debian/patches/Fix-a-buffer-overflow-vulnerability.patch
2019-04-05 15:36:38.0 +0200
@@ -0,0 +1,30 @@
+From: Tim Ruehsen 
+Date: Fri, 5 Apr 2019 11:50:44 +0200
+Subject: Fix a buffer overflow vulnerability
+Origin: 
https://git.savannah.gnu.org/cgit/wget.git/commit/?id=692d5c5215de0db482c252492a92fc424cc6a97c,
+ 
https://git.savannah.gnu.org/cgit/wget.git/commit/?id=562eacb76a2b64d5dc80a443f0f739bc9ef76c17
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-5953
+Bug-Debian: https://bugs.debian.org/926389
+
+* src/iri.c(do_conversion): Reallocate the output buffer to a larger
+  size if it is already full
+---
+ src/iri.c | 12 +---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/src/iri.c
 b/src/iri.c
+@@ -189,9 +189,10 @@ do_conversion (const char *tocode, const
+ {
+   tooshort++;
+   done = len;
+-  len = outlen = done + inlen * 2;
+-  s = xrealloc (s, outlen + 1);
+-  *out = s + done;
++  len = done + inlen * 2;
++  s = xrealloc (s, len + 1);
++  *out = s + done - outlen;
++  outlen += inlen * 2;
+ }
+   else /* Weird, we got an unspecified error */
+ {
diff -Nru wget-1.20.1/debian/patches/series wget-1.20.1/debian/patches/series
--- wget-1.20.1/debian/patches/series   2018-12-15 18:07:46.0 +0100
+++ wget-1.20.1/debian/patches/series   2019-04-05 15:36:38.0 +0200
@@ -1,3 +1,4 @@
 wget-doc-remove-usr-local-in-sample.wgetrc
 wget-doc-remove-usr-local-in-wget.texi
 wget-passive_ftp-default
+Fix-a-buffer-overflow-vulnerability.patch


Bug#926887: Upgrade replaced smb.conf

2019-04-11 Thread Alexander Toresson
Package: samba-common
Version: 2:4.2.14+dfsg-0+deb8u12

Hi,

Suddenly my smb shares stopped working. I found out that an unattended
upgrade of samba-common hade replaced (!) smb.conf, for whatever reason:

Excerpt from /var/log/unattended-upgrades/unattended-upgrades-dpkg.log:
...
Setting up samba-common (2:4.2.14+dfsg-0+deb8u12) ...
Replacing config file /etc/samba/smb.conf with new version
...

This is not something I'd expect to happen on package upgrade, at least not
without being asked about it, which cannot be done for an unattended
upgrade. Also, this was a security upgrade from deb8u11 to deb8u12, on
which I'd expect it even less.

This occured on debian 8.11 armel.

// Alexander


Bug#926821: unblock: feersum/1.406-3

2019-04-11 Thread Xavier
Control: retitle -1 unblock: feersum/1.406-3

Le 10/04/2019 à 22:59, Xavier Guimard a écrit :
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package feersum
> 
> Hi all,
> 
> due to libhttp-tiny-perl bug, feersum build fails when only one CPU is
> available or on very poor configuration. I patched it to:
>  * ignore errors on t/63-plack-apps.t test
>  * don't test t/{13-pre-fork.t,60-plack.t,61-plack-suite.t} if nproc==1
> 
> See https://bugs.debian.org/909480 for the full discussion.
> 
> Feersum has no reverse dependencies.
> 
> Since this patch affects only tests, I think it is not risky to unblock
> this new version. This fixes no bug but workaround #909480, severity
> "normal" and avoid FTBFS.
> 
> Cheers,
> Xavier
> 
> unblock feersum/1.406-2

Hello,

I updated my patch to better manage paralleled jobs. Thanks to gregoa !

Cheers,
Xavier

unblock feersum/1.406-3
diff --git a/debian/changelog b/debian/changelog
index a4832a2..bff23f2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+feersum (1.406-3) unstable; urgency=medium
+
+  * debian/rules: rewrite fix for 1-CPU workaround
+
+ -- Xavier Guimard   Thu, 11 Apr 2019 21:55:38 +0200
+
+feersum (1.406-2) unstable; urgency=medium
+
+  * Declare compliance with policy 4.3.0
+  * Add patch to workaround libhttp-tiny-perl bug in tests and disable 3 other
+tests when only 1 CPU is available (#909480)
+
+ -- Xavier Guimard   Wed, 10 Apr 2019 21:24:03 +0200
+
 feersum (1.406-1) unstable; urgency=medium
 
   * debian/rules: fix Perl path in example files
diff --git a/debian/control b/debian/control
index 081e2ba..e995ca7 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends: debhelper (>= 10),
libtest-leaktrace-perl,
libtest-tcp-perl,
perl
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/perl-team/modules/packages/feersum
 Vcs-Git: https://salsa.debian.org/perl-team/modules/packages/feersum.git
 Homepage: https://metacpan.org/release/Feersum
diff --git a/debian/patches/series b/debian/patches/series
index aba7ccb..2bcab6e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 autopkgtest.patch
+workaround-for-909480.diff
diff --git a/debian/patches/workaround-for-909480.diff 
b/debian/patches/workaround-for-909480.diff
new file mode 100644
index 000..7c22ffb
--- /dev/null
+++ b/debian/patches/workaround-for-909480.diff
@@ -0,0 +1,30 @@
+Description: Workaround for #909480
+ Feersum sometimes FTBFS due to libhttp-tiny-perl
+ bug (https://bugs.debian.org/909480
+ .
+ This workaround adds a "TODO" loop to not fail on build even if HTTP::Tiny
+ tries to reuse closed connections.
+Author: Xavier Guimard 
+Bug-Debian: https://bugs.debian.org/909480
+Forwarded: not-needed
+Last-Update: 2019-04-10
+
+--- a/t/63-plack-apps.t
 b/t/63-plack-apps.t
+@@ -22,6 +22,8 @@
+ use Plack::Request;
+ use Test::TCP;
+ 
++TODO: {
++local $TODO = 'Failure ignored to workaround #909480';
+ via_map: test_psgi(
+ app => builder {
+ mount '/' => Plack::App::File->new(root => 't');
+@@ -85,6 +87,7 @@
+ like $res->content, qr/^\Q$s\E$/m, "found static line (cascade)";
+ }
+ );
++}
+ 
+ __END__
+ # IS THIS FILE STATICALLY SERVED?
diff --git a/debian/rules b/debian/rules
index d1559c8..13bdb95 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,6 +4,7 @@ PACKAGE = $(shell dh_listpackages)
 TMP = $(CURDIR)/debian/$(PACKAGE)
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+TEST_FILES_1_CPU=$(filter-out t/13-pre-fork.t t/60-plack.t 
t/61-plack-suite.t,$(shell echo t/*.t)); \
 
 %:
dh $@
@@ -15,3 +16,12 @@ override_dh_installexamples:
 override_dh_auto_install:
dh_auto_install
sed -i '1s|^#!.*perl|#!/usr/bin/perl|' $(TMP)/usr/*bin/*
+
+override_dh_auto_test:
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES)))
+   if [ `nproc` -gt 1 ]; then \
+   dh_auto_test; \
+   else \
+   dh_auto_test --no-parallel -- TEST_FILES="$(TEST_FILES_1_CPU)"; 
\
+   fi
+endif


Bug#926886: Please mention video->render change in udev.NEWS

2019-04-11 Thread Guido Günther
Package: udev
Version: 243-1
Severity: normal

Hi,
it took me a while to figure out why rendering got broken in my wayland
compositor. It would be great if the change from video to render group
could be mentioned in udev.NEWS.
Cheers,
 -- Guido


-- Package-specific info:

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

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

Versions of packages udev depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libblkid12.33.1-0.1
ii  libc62.28-7
ii  libkmod2 26-1
ii  libselinux1  2.8-1+b1
ii  libudev1 241-1
ii  lsb-base 10.2019031300
ii  util-linux   2.29.2-5+b1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  241-1

-- debconf information excluded



Bug#757794: Error messages should say which host is broken

2019-04-11 Thread Shawn Landden
Source: distcc
Followup-For: Bug #757794

You can get the host if you turn on verbose logging with DISTCC_VERBOSE=1

If you still are not satisfied, please send a pull request on GIthub

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Foreign Architectures: armel, armhf

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



Bug#926475: Review + debdiff

2019-04-11 Thread Stefan Potyra
Hi Bruno,


On Mon, Apr 08, 2019 at 08:14:02PM +0200, Bruno Kleinert wrote:
> 
> Hi Stefan,
> 
> I only had minor improvements, see attached debdiff. Those include:
>  * Set debhelper compatibility level by build dependency magic.
>  * Update the .desktop file patch to remove a broken line and add
>another category for the tool.
>  * Override lintian warning for source tarball repack and provide a
>rationale.

Looks good in the debdiff!

> 
> I *think* the "Copyright (c)" part is redundant in debian/copyright and
> could possibly be removed from lines 27-32.



Actually, the examples all have "Copyright" there.

Debdiff looks fine to me, thanks for the review including the proposed changes.

How to proceed?
Do you want to upload the package with your debdiff applied?
Or should I apply it and propose a new .dsc file?

Cheers,
  Stefan.


signature.asc
Description: PGP signature


Bug#926875: initramfs-tools backward compatibility removal

2019-04-11 Thread Ben Hutchings
Control: reassign -1 dropbear-initramfs 2018.76-5
Control: severity -1 minor

On Thu, 2019-04-11 at 19:04 +0200, Florian Strankowski wrote:
> Package: initramfs-tools
> Version: 0.130
> 
> When ifdown is invoked, it still checks for IFDOWN beeing supplied 
> within /conf/initramfs.conf. Due to the nature of evolution, this has 
> been moved to /etc/dropbear-initramfs/config within the release of stretch.
[...]

This is part of dropbear-initramfs and not initramfs-tools itself.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.



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


Bug#926885: lighttpd: CVE-2019-11072

2019-04-11 Thread Salvatore Bonaccorso
Source: lighttpd
Version: 1.4.53-3
Severity: grave
Tags: security upstream
Forwarded: https://redmine.lighttpd.net/issues/2945

Hi,

The following vulnerability was published for lighttpd.

CVE-2019-11072[0]:
| lighttpd before 1.4.54 has a signed integer overflow, which might
| allow remote attackers to cause a denial of service (application
| crash) or possibly have unspecified other impact via a malicious HTTP
| GET request, as demonstrated by mishandling of /%2F? in
| burl_normalize_2F_to_slash_fix in burl.c.


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-2019-11072
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11072
[1] https://redmine.lighttpd.net/issues/2945
[2] 
https://github.com/lighttpd/lighttpd1.4/commit/32120d5b8b3203fc21ccb9eafb0eaf824bb59354

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#926884: distcc: Does not work with clang

2019-04-11 Thread Shawn Landden
Source: distcc
Severity: important

Dear Maintainer,

dh_auto_configure is providing --build without --host, which results in
autoconf not setting $host, which results in distcc not getting GNU_HOST
which it passes to clang for native builds.

If you try to compile with clang on a native build it quits with 
error: unknown target triple 'unknown', please use -triple or -arch

Please pass --host to autotools

-   if (dpkg_architecture_value("DEB_BUILD_GNU_TYPE") ne 
dpkg_architecture_value("DEB_HOST_GNU_TYPE")) {
-   push @opts, 
"--host=".dpkg_architecture_value("DEB_HOST_GNU_TYPE");
-   }

Thanks,

Shawn Landden
Your upstream.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Foreign Architectures: armel, armhf

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



Bug#926883: php7.3 breaks symfony autopkgtest

2019-04-11 Thread Paul Gevers
Source: php7.3, symfony
Control: found -1 php7.3/7.3.4-1
Control: found -1 symfony/3.4.22+dfsg-1
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of php7.3 the autopkgtest of symfony fails in
testing when that autopkgtest is run with the binary packages of php7.3
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
php7.3 from testing7.3.4-1
symfonyfrom testing3.4.22+dfsg-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I normally copy some of the output to the bottom of this report, but the
output is long and littered with shell makeup code and I was unable to
spot where the error was. All I see is "exit 1" and multiple "OK, but
incomplete, skipped, or risky tests!"

Currently this regression is blocking the migration of php7.3 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? If needed, please change the bug's severity.

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
php7.3/7.3.4-1. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=php7.3

https://ci.debian.net/data/autopkgtest/testing/amd64/s/symfony/2231104/log.gz



signature.asc
Description: OpenPGP digital signature


Bug#926860: [Pkg-swan-devel] Bug#926860: libcharon-extra-plugins: EAP-SIM module not included

2019-04-11 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2019-04-11 at 13:49 +0200, Christophe Devine wrote:
> The eap-sim and eap-sim-file plugins are missing from 
> libcharon-extra-plugins. They are
> required to authenticate a client using 2G authentication vector obtained 
> using for example
> https://github.com/mixja/eap-sim-lab/blob/master/lib/pySim/pySim-run-gsm.py
> 
> Support for eap-sim and eap-sim-file can be enabled with --enable-eap-sim 
> --enable-eap-sim-file

Hi Christophe,

eap-sim is not enabled right now because I had the feeling that it wasn't that
useful/popular on Debian boxes (the only EAP-SIM application I know is
FreeWifi authentication in France, which usually happens on phones not running
Debian).

In any case, I'm not against that, but it'll have to wait for Buster+1.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlyvkHgACgkQ3rYcyPpX
RFu2YAf7BxpfkAlOIivbfsGOI+UEuG0qQNkUM+sl7rXTJsraloUXUzTu5g8oyb4j
eVyLOdDs1JvdEcBcdsp1hTFdrzrkBK61q/SpZMfg+wSXhSZl4bASCtQKEhnhl6al
YQ3Rp0D796+RT29+WGpXWXma72zKNeP7BVEKMeMn5Cd/VUu/dRAqBN8x1/2H6W4G
IOMgaDnLa1NMdBgTTfVap4OyK4EW1zfEmieHlv3IqTTtzDQk8rxd0D+nY/dXdA0A
ruvmI2uULPzK75beZi6txzd9D1ZXTJpVRXhhybC5ScNl3VNSnanIEeIOjgr2xnQi
l+ijCVZAIoDOASUemIo5nGSu1to6+A==
=wqyz
-END PGP SIGNATURE-



Bug#900912: Java Accessibility for Buster

2019-04-11 Thread Sam Hartman



Hi.  I have not been looking forward to having no java accessibility in
buster and it is really good to see the work Samuel has done on this
bug.  I'd really hate to see buster release without some mechanism for
blind users like myself to use Java applications.  Also, in the long
run, if buster does require editing a property file, I hope that we can
get to a place where that's not needed for the next release.

Matthias, I realize that you've got a lot on your plate, and have a lot
of stuff to balance.  I'd appreciate it if you would find the time to
move this forward and get the patch uploaded or let someone else do so.

Thanks for all your hard work,

--Sam



Bug#926882: unblock: pymilter/1.0.3-3

2019-04-11 Thread Daniel Kahn Gillmor
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 src:pymilter

Please unblock package pymilter

pymilter 1.0.3-3 resolves an important bug that causes python3-milter to
fail under a common simple use case (#922733).

The debdiff is attached.

unblock pymilter/1.0.3-3

Thanks for your work on making Buster awesome!

  --dkg

diff --git pymilter-1.0.3-2/debian/changelog pymilter-1.0.3-3/debian/changelog
index 5afa05c..0161d90 100644
--- pymilter-1.0.3-2/debian/changelog
+++ pymilter-1.0.3-3/debian/changelog
@@ -1,3 +1,10 @@
+pymilter (1.0.3-3) unstable; urgency=medium
+
+  * Avoid crashes in Milter.utils.parseaddr (Closes: #922733)
+  * add myself to uploaders
+
+ -- Daniel Kahn Gillmor   Tue, 19 Feb 2019 18:35:31 -0500
+
 pymilter (1.0.3-2) unstable; urgency=medium
 
   * Add preprocessor defines for kfreebsd and hurd
diff --git pymilter-1.0.3-2/debian/control pymilter-1.0.3-3/debian/control
index 016bea6..98901b4 100644
--- pymilter-1.0.3-2/debian/control
+++ pymilter-1.0.3-3/debian/control
@@ -2,7 +2,8 @@ Source: pymilter
 Section: python
 Priority: optional
 Maintainer: Scott Kitterman 
-Uploaders: Debian Python Modules Team 
+Uploaders: Debian Python Modules Team ,
+ Daniel Kahn Gillmor ,
 Build-Depends: debhelper (>= 9), dh-python, python-all-dev (>= 2.6.5-2~), python3-all-dev, libmilter-dev
 Build-Depends-Indep: doxygen
 Standards-Version: 4.3.0
diff --git pymilter-1.0.3-2/debian/patches/0002-utils-import-email.utils.patch pymilter-1.0.3-3/debian/patches/0002-utils-import-email.utils.patch
new file mode 100644
index 000..ee90a3e
--- /dev/null
+++ pymilter-1.0.3-3/debian/patches/0002-utils-import-email.utils.patch
@@ -0,0 +1,25 @@
+From: Daniel Kahn Gillmor 
+Date: Tue, 19 Feb 2019 18:20:18 -0500
+Subject: utils: import email.utils
+
+Without this patch, Milter.utils.parseaddr() fails with:
+
+  File "/usr/lib/python3/dist-packages/Milter/utils.py", line 139, in parseaddr
+res = email.utils.parseaddr(t)
+AttributeError: module 'email' has no attribute 'utils'
+---
+ Milter/utils.py | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/Milter/utils.py b/Milter/utils.py
+index 2ed5db8..85fd635 100644
+--- a/Milter/utils.py
 b/Milter/utils.py
+@@ -8,6 +8,7 @@ import socket
+ import email.errors
+ from email.header import decode_header
+ import email.base64mime
++import email.utils
+ from fnmatch import fnmatchcase
+ from binascii import a2b_base64
+ 
diff --git pymilter-1.0.3-2/debian/patches/series pymilter-1.0.3-3/debian/patches/series
index 44e9f8c..de96083 100644
--- pymilter-1.0.3-2/debian/patches/series
+++ pymilter-1.0.3-3/debian/patches/series
@@ -1 +1,2 @@
 hurd_kfreebsd.patch
+0002-utils-import-email.utils.patch


signature.asc
Description: PGP signature


Bug#922733: python3-milter: Milter.utils.parseaddr() fails: AttributeError: module 'email' has no attribute 'utils'

2019-04-11 Thread Daniel Kahn Gillmor
Control: affects 922733 + src:dkimpy-milter
Control: severity 922733 important
Control: block 922006 by 922733
Control: forwarded 922733 
https://github.com/sdgathman/pymilter/commit/04e0b156400798ab9527385946f632f744ed60d5

> In [2]: Milter.utils.parseaddr('Daniel Kahn Gillmor ')
> ---
> AttributeErrorTraceback (most recent call last)
>  in ()
> > 1 Milter.utils.parseaddr('Daniel Kahn Gillmor ')
>
> /usr/lib/python3/dist-packages/Milter/utils.py in parseaddr(t)
> 137   """
> 138   #return email.utils.parseaddr(t)
> --> 139   res = email.utils.parseaddr(t)
> 140   # dirty fix for some broken cases
> 141   if not res[0]:
>
> AttributeError: module 'email' has no attribute 'utils'

This error has a major effect on the usability of this package in
python3, without making it unusable for everyone, so i'm adjusting the
severity accordingly.

Among other effects, this bug makes it impossible to convert
dkimpy-milter to python3 (also detailed in the Control: stanza above).

The particular fix for this issue has already been reported upstream and
fixed in git (also noted in the Control: stanza).

  --dkg


signature.asc
Description: PGP signature


Bug#926881: Add support for setting tlb_dynamic_lb option in /etc/network/interfaces

2019-04-11 Thread Robert L Mathews
Package: ifenslave
Version: 2.9
Severity: normal
Tags: patch

Bonding driver 3.7.1 and later supports an option called
"tlb_dynamic_lb" for "balance-tlb" mode, but there is no support for
setting it in the /etc/network/interfaces file. This patch adds support
for that.

With this patch, adding "bond-tlb_dynamic_lb 0" to the interfaces file
correctly shows "bond0: Setting dynamic-lb to off (0)" in logs, and
correctly sets the value of
"/sys/class/net/bond0/bonding/tlb_dynamic_lb".

-- 
Robert L Mathews, Tiger Technologies

--- debian/ifenslave.if-pre-up
+++ debian/ifenslave.if-pre-up
@@ -144,6 +144,9 @@
# arp_validate must be after mode (because mode must be active-backup).
sysfs arp_validate "$IF_BOND_ARP_VALIDATE"
 
+   # tlb_dynamic_lb must be after mode (because mode must be active-tlb).
+   sysfs_change_down tlb_dynamic_lb "$IF_BOND_TLB_DYNAMIC_LB"
+
# lacp_rate must be set after mode (because mode must be 802.3ad).
# Changing lacp_rate requires $BOND_MASTER to be down.
sysfs_change_down lacp_rate "$IF_BOND_LACP_RATE"

--- debian/README.Debian
+++ debian/README.Debian
@@ -206,6 +206,9 @@
 * bond-xmit_hash_policy:
Write into /sys/class/net//bonding/xmit_hash_policy
 
+* bond-tlb_dynamic_lb:
+   Write into /sys/class/net//bonding/tlb_dynamic_lb
+
 

 
 The following files in /sys/class/net/bond*/bonding are read-only, so no


Bug#900912: Enabling jaw (Java-atk-wrapper) by default ? (Bug#900912)

2019-04-11 Thread Paul Gevers
Hi doko,

On 07-04-2019 12:08, Samuel Thibault wrote:
>> I disagree.  I'll do the next upload with Samuel's proposed patches, not
>> enabling that by default, together with the planned security update.  Then
>> people can start testing if the wrapper works.
> 
> Well, I'm afraid that what will happen is that the people who will
> test will simply find out that it just works for them (just like it
> does already for them with openjdk-8) ; will we then conclude near the
> release that it should be enabled by default for Buster, and then be hit
> by the much wider exposition to jaw?
> 
> If on the contrary we enable it by default during the freeze, we will
> have *way* more testing coverage, and thus be much more confident with
> keeping it enabled by default in Buster if we don't see bug reports.

Although I agree with Samuel here, can we please-pretty-please get an
upload even if you don't enable it, such that we can get this story into
buster?

Paul



signature.asc
Description: OpenPGP digital signature


Bug#923986: ruby-pygments.rb: FTBFS randomly (failing tests)

2019-04-11 Thread Chris Lamb
Santiago Vila wrote:

> Well, but I can't build packages in your machine, I have to do it in
> my machine, and it fails 50% of the time for me. Try building on a
> START1-XS instance from Scaleway (still available on Amsterdam), or
> ask me for an account in such a machine.

Thank you again for your kind offer of access to such a machine but I
think it may be better long-term to work out why this is not failing for
me locally.

Learning the underlying reason why and how our environments differ
will tell us the way of solving this issue properly. By contrast,
simply reproducing on yours is, I fear, simply confirming what we
already know - ie. that it does not build for you.

Unfortuantely, this is "just a random package" from my point of view
so I am unlikely to find the bandwidth to set myself up with a new
machine/ environment very soon, hence why I posted my brief status
update earlier.


Best wishes,

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



Bug#926878: unblock: exim4/4.92-5

2019-04-11 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Andreas,

On 11-04-2019 19:51, Andreas Metzler wrote:
> The second notable change is related to sa-exim. Exim in Debian was
> patched to allow dlopening a localscan() module. The single consumer of
> this patch in Debian is sa-exim. (The patch also originates there.)
> 
> The patch in Debian has been nonfunctional in unstable for quite some
> time (4.92~RC2-1/experimental/18 Dec, 4.92~RC3-1 unstable/26 Dec and
> buster/03 Jan). The issue only popped up end of March on the upstream
> user support ML.
> 
> Looking at the state of sa-exim (dead upstream since 2006 and buggy: 
> https://lists.exim.org/lurker/message/20180726.113354.6d03efde.en.html
> #879687) we have decided stop patching exim, which resulted in 4.92-5,
> which
> - improves the example/docs for content-scanning in exim without sa-exim
> - drops the abovementioned patch and the virtual Provides for
>   exim4-localscanapi-2.0 and also drops the exim-dev packages (only
>   needed for sa-exim). Exim now also Conflicts with sa-exim.

I am probably missing something, but as far as I see it, your packages
can't migrate to testing/buster because it would make sa-exim
uninstallable. If I am right, please coordinate with the maintainer of
sa-exim (in CC). At least at this moment they should agree that it is
alright to remove sa-exim from buster. I am not seeing any serious bugs
reported against sa-exim so they may not be aware of the issue.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#926880: exiv2: please, update exiv2 version or Nikkor lens list

2019-04-11 Thread i blonchk
Package: exiv2
Version: 0.26-1
Severity: wishlist
Tags: newcomer

Dear Maintainer,

exiv 0.25-4 do not recognize recent Nikkor lens (2015 and 2016) on Nikon D500.

D500 Firmware:
C  1.15
LD 2.017
LF 1.00

Lens IDs:
163=Nikon AF-P DX Nikkor 70-300mm f/4.5-6.3G ED VR
173=Nikon AF-S DX Nikkor 16-80mm f/2.8-4E ED VR

Two NEF test files:
https://www.swisstransfer.com/d/72fe6ae7-8f5c-4ba3-bc91-c6d682abca99

Impact: darktable 2.6.x bin

Finally, i tested rapidly (by working with dartktable):

- exiv 0.26-1 experimental is OK. Darktable 2.6.2 (github src release) rebuild
against libexiv-dev 0.26.1  works.

- exiv 0.27.99 build out of GitHub src tree is OK too. Darktable 2.6.2 seams
also usable after src rebuild.

Kindes regards.
i blonchk




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

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

Versions of packages exiv2 depends on:
ii  libc62.28-8
ii  libexiv2-26  0.26-1
ii  libgcc1  1:8.3.0-5
ii  libstdc++6   8.3.0-5

exiv2 recommends no packages.

exiv2 suggests no packages.

-- no debconf information



Bug#926879: pavucontrol: Untraslated stuff in pt_BR Translation

2019-04-11 Thread Edson Juliano Drosdeck
Package: pavucontrol
Version: 3.0-3.1
Severity: minor
Tags: l10n

There are a few sentences which are untranslated in the pt_BR translation.
These are:

"Advanced", "All Output Devices", "Hardware Output Devices", "Virtual Output
Devices".



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

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

Versions of packages pavucontrol depends on:
ii  libatk1.0-0  2.22.0-1
ii  libatkmm-1.6-1v5 2.24.2-2
ii  libc62.24-11+deb9u4
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libcairomm-1.0-1v5   1.12.0-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libglibmm-2.4-1v52.50.0-1
ii  libgtk-3-0   3.22.11-1
ii  libgtkmm-3.0-1v5 3.22.0-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangomm-1.4-1v5   2.40.1-3
ii  libpulse-mainloop-glib0  10.0-1+deb9u1
ii  libpulse010.0-1+deb9u1
ii  libsigc++-2.0-0v52.10.0-1
ii  libstdc++6   6.3.0-18+deb9u1
ii  libx11-6 2:1.6.4-3+deb9u1

Versions of packages pavucontrol recommends:
ii  pulseaudio  10.0-1+deb9u1

pavucontrol suggests no packages.

-- no debconf information



Bug#926771: knot-resolver: Needs to recommend lua-cqueues for automatic detection of changes to RPZ file

2019-04-11 Thread Daniel Kahn Gillmor
On Wed 2019-04-10 09:50:23 +0200, Frederik Himpe wrote:
> The package should at least recommend the lua-cqueues package, because
> that one is needed for detecting changes to RPZ files.
>
> https://github.com/CZ-NIC/knot-resolver/blob/master/modules/policy/policy.lua#L430

Thanks for this report!

I've added the Recommends: lua-cqueues to the knot-resolver packaging at
https://salsa.debian.org/dns-team/knot-resolver, and it will go into the
next debian release (but probably not before buster, since we're in
freeze).

All the best,

--dkg



Bug#926878: unblock: exim4/4.92-5

2019-04-11 Thread Andreas Metzler
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package exim4:

In the first place it pulls multiple upgrades from upstream's
exim-4.92+fixes branch where important post-release fixes are published.

The second notable change is related to sa-exim. Exim in Debian was
patched to allow dlopening a localscan() module. The single consumer of
this patch in Debian is sa-exim. (The patch also originates there.)

The patch in Debian has been nonfunctional in unstable for quite some
time (4.92~RC2-1/experimental/18 Dec, 4.92~RC3-1 unstable/26 Dec and
buster/03 Jan). The issue only popped up end of March on the upstream
user support ML.

Looking at the state of sa-exim (dead upstream since 2006 and buggy: 
https://lists.exim.org/lurker/message/20180726.113354.6d03efde.en.html
#879687) we have decided stop patching exim, which resulted in 4.92-5,
which
- improves the example/docs for content-scanning in exim without sa-exim
- drops the abovementioned patch and the virtual Provides for
  exim4-localscanapi-2.0 and also drops the exim-dev packages (only
  needed for sa-exim). Exim now also Conflicts with sa-exim.

unblock exim4/4.92-5

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .changes but not in first
-
-rw-r--r--  root/root   /usr/lib/debug/.build-id/45/59933d7d0e4800a65884d62d6506ce390b4f07.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/59/55fdc7b64bc2f31b1e0b63c762a57924c2516e.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/5e/f1dbf7d44b659418b55dd4a173cda74ecad278.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/9b/6cfa23511aa8ae2305e45f556cd5238b07f495.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/bb/23e5a1a9f351c2a608d482dfc1e00d9998c629.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/bc/986da4b151ecfa52558aa9c20d03614d31dd25.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/bd/894614600fc329441d05ceb08017719b489417.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/ca/a4ade19a8e042ebf7f9f22782142cbd56bcd2b.debug

Files in first .changes but not in second
-
-rw-r--r--  root/root   /usr/include/exim4/config.h
-rw-r--r--  root/root   /usr/include/exim4/local_scan.h
-rw-r--r--  root/root   /usr/include/exim4/mytypes.h
-rw-r--r--  root/root   /usr/include/exim4/store.h
-rw-r--r--  root/root   /usr/lib/debug/.build-id/1f/9c1ede6c32409686b1de89bb598ff598b0ee4f.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/23/c3c5b57e50336cc82bb3a27f46b9b354ccb3e6.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/50/c2969f4b54bc47c33c513e27a89cd4a09d728d.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/51/279c0f518a9e2a849c64a89ff8eaadcabe26fa.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/9c/50ed18cc20fbffb26032ecebab97af806afdd3.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/a3/1149847f6ae982b262e6aec59d3afa2e9ae841.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/ef/6c35ac2c5dc055ab4c3a7d10302123129f10b8.debug
-rw-r--r--  root/root   /usr/lib/debug/.build-id/f2/12c147800e2c7a02151217960981dcaa2d4f6c.debug
-rw-r--r--  root/root   /usr/share/doc/exim4-dev/NEWS.Debian.gz
-rw-r--r--  root/root   /usr/share/doc/exim4-dev/changelog.Debian.gz
-rw-r--r--  root/root   /usr/share/doc/exim4-dev/copyright
-rw-r--r--  root/root   /usr/share/man/man1/exim4-localscan-plugin-config.1.gz
-rwxr-xr-x  root/root   /usr/bin/exim4-localscan-plugin-config
lrwxrwxrwx  root/root   /usr/share/doc/exim4-dev/README.Debian.gz -> ../exim4-base/README.Debian.gz
lrwxrwxrwx  root/root   /usr/share/doc/exim4-dev/changelog.gz -> ../exim4-base/changelog.gz

Control files of package exim4: lines which differ (wdiff format)
-
Depends: debconf (>= 1.4.69) | cdebconf (>= 0.39), exim4-base (<< [-4.92-2.1),-] {+4.92-5.1),+} exim4-base (>= [-4.92-2),-] {+4.92-5),+} exim4-daemon-light | exim4-daemon-heavy | exim4-daemon-custom, debconf (>= 0.5) | debconf-2.0
Version: [-4.92-2-] {+4.92-5+}

Control files of package exim4-base: lines which differ (wdiff format)
--
Installed-Size: [-1621-] {+1623+}
Version: [-4.92-2-] {+4.92-5+}

Control files of package exim4-base-dbgsym: lines which differ (wdiff format)
-
Build-Ids: [-1f9c1ede6c32409686b1de89bb598ff598b0ee4f 23c3c5b57e50336cc82bb3a27f46b9b354ccb3e6 9c50ed18cc20fbffb26032ecebab97af806afdd3 ef6c35ac2c5dc055ab4c3a7d10302123129f10b8 f212c147800e2c7a02151217960981dcaa2d4f6c-] {+4559933d7d0e4800a65884d62d6506ce390b4f07 

Bug#905866: uscan: prefers watch files from a random dir over debian/watch

2019-04-11 Thread Daniel Schepler
I find the recursive search feature useful for when I have a large
collection of unpacked source packages in $HOME/src/debian, then I can
"cd ~/src/debian; uscan --report" to check for updates to any of those
source packages.

As for an example I've run into:
https://ftp.gnu.org/gnu/ncurses/ncurses-6.1.tar.gz contains several
invalid debian/watch files which trigger error messages in the
multiple-package uscan run until I manually delete them.
-- 
Daniel Schepler



Bug#921534: pdfarranger: Does not show preview of pages

2019-04-11 Thread Daniel Schröter
I have the same issue. This makes it quit hard to use pdfarranger



Bug#653946: same here

2019-04-11 Thread postings
same here, it is flooding my log file:

cat .xsession-errors | grep xklavier | wc -l
716

cat .xsession-errors |  wc -l
2175

message always the same
![1555003242,000,xklavier_evt_xkb.c:xkl_xkb_process_x_event/]    
ATTENTION! Currently cached group 1 is not equal to the current group
from the event: 0


if this is the wrong place, where else to report this?

Thanks a million, I much much appreciate Debian, and everyone who helps!



Bug#926876: unblock: chiark-utils/6.0.4

2019-04-11 Thread Ian Jackson
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package chiark-utils

chiark-utils is a portmanteau of different utiliies.  I am proposing
to fix two bugs.  Each bug is RC for the corresponding utility in the
sense that the utility is dangerous or useless without the fix.  (The
bugs are not IMO RC for the package as a whole, although I think the
dangerous one is "important".)

1. fishdescriptor has a bug which makes it not work on amd64 and could
cause malfunctions or even UB in the target process.  #926858

2. sync-accounts uses an ancient deprecated perl syntax and is
entirely rejected by current versions of perl.  #865985

Below is the source diff.  Assuming the unblock is granted I will
finalise the changelog entry for 6.0.4 and do a dgit push-source
to do a source-only upload.

(For my records: diff was generated from current master on chiark, ie
 0caba95b1c3f211fa3defcff017dde1374b3caa6)


unblock chiark-utils/6.0.4


diff --git a/debian/changelog b/debian/changelog
index 1d1758f..e0ecabd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+chiark-utils (6.0.4~iwj1) unstable; urgency=medium
+
+  * sync-accounts: Fix perl syntax error.  Closes:#865985.
+  * changelog: Document bug number for bugfix in 6.0.4~citrix1.
+
+ --
+
+chiark-utils (6.0.4~citrix1) unstable; urgency=medium
+
+  * fishdescriptor: cast __errno_location correctly.  Closes:#926858.
+
+ -- Ian Jackson   Mon, 08 Apr 2019 17:03:47 +0100
+
 chiark-utils (6.0.3) unstable; urgency=medium
 
   * Upload to Debian unstable.
diff --git a/fishdescriptor/py/fishdescriptor/indonor.py 
b/fishdescriptor/py/fishdescriptor/indonor.py
index 20bc807..e227fb2 100644
--- a/fishdescriptor/py/fishdescriptor/indonor.py
+++ b/fishdescriptor/py/fishdescriptor/indonor.py
@@ -142,7 +142,7 @@ class DonorImplementation():
 # in my browser).  Also the error is very nonspecific :-/.
 # This seems to happen on jessie, and is fixed in stretch.
 # Anyway:
-return parse_eval(expr_pat % '(*((int (*)(void))__errno_location)())')
+return parse_eval(expr_pat % '(*((int*(*)(void))__errno_location)())')
 
 # calling functions (need to cast the function name to the right
 # type in case maybe gdb doesn't know the type)
diff --git a/sync-accounts/sync-accounts b/sync-accounts/sync-accounts
index cef131c..5348a14 100755
--- a/sync-accounts/sync-accounts
+++ b/sync-accounts/sync-accounts
@@ -64,7 +64,7 @@ sub fields_fmt ($$) {
 my ($pfx,$fmt) = @_;
 my ($vn);
 $vn= "fields_pw_$fmt";
-die "unknown format $fmt\n" unless defined @$vn;
+die "unknown format $fmt\n" unless @$vn;
 fields($pfx,@$vn);
 $vn= "${pfx}_format";
 $$vn= $fmt;


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

Kernel: Linux 4.19.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)



Bug#926875: initramfs-tools backward compatibility removal

2019-04-11 Thread Florian Strankowski

Package: initramfs-tools
Version: 0.130

When ifdown is invoked, it still checks for IFDOWN beeing supplied 
within /conf/initramfs.conf. Due to the nature of evolution, this has 
been moved to /etc/dropbear-initramfs/config within the release of stretch.


###

if grep -q ^DROPBEAR_IFDOWN= /conf/initramfs.conf; then
# XXX backward compatibility; remove once Stretch is the current stable
. /conf/initramfs.conf
IFDOWN="$DROPBEAR_IFDOWN"
fi
if [ -e /etc/dropbear/config ]; then
. /etc/dropbear/config
fi

###

I suggest to move the checks to the accordingly right file which is now 
/etc/dropbear-initramfs/config. Further a backward-compability check for 
upgraded systems should be in place or a warning (like when setting up 
cryptotools) to move already set variables like "IFDOWN=" to the 
appropriate new configuration-path (see above).





Florian Strankowski
uniquoo UG i.G.
Adolph-Schönfelder-Straße 68
22083 Hamburg, Germany



Bug#926874: software-properties-gtk: Untraslated stuff in pt_BR Translation

2019-04-11 Thread Edson Juliano Drosdeck
Package: software-properties-gtk
Version: 0.96.20.2-1
Severity: minor
Tags: l10n

There are a few sentences which are untranslated in the pt_BR translation.
These are:

- "Other Software", "Developer Options", "Intall updates from" , "Automatically
check from updates",
"When there are security updates" , "Download and install automatically",
"Display immediately",
"Download automatically", "When there are other updates", "Propesed updates are
only for testing updates
and providing development feedback. Enabling this may introduce instability."


--system Information:

Distributor ID: Debian
Description:Debian GNU/Linux 9.8 (stretch)
Release:9.8
Codename:   stretch


ii  software-properties-common0.96.20.2-1
ii  software-properties-gtk   0.96.20.2-1



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

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

Versions of packages software-properties-gtk depends on:
ii  gir1.2-gtk-3.0   3.22.11-1
ii  python3  3.5.3-1
ii  python3-gi   3.22.0-2
ii  python3-software-properties  0.96.20.2-1
ii  software-properties-common   0.96.20.2-1

software-properties-gtk recommends no packages.

Versions of packages software-properties-gtk suggests:
ii  gnome-software  3.22.5-1

-- no debconf information



Bug#926849: Generate treeinfo files to ease automatic installations

2019-04-11 Thread Ansgar Burchardt
On Thu, 2019-04-11 at 11:49 +0200, Guido Günther wrote:
> E.g. for amd64 and stretch we'd have a file
> 
>http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/.treeinfo
> 
> looking like
> 
> [checksums]
> current/images/netboot/mini.iso = sha256:...
> current/images/netboot/debian-installer/amd64/initrd.gz =
> sha256:...
> current/images/netboot/debian-installer/amd64/linux = sha256: ...
> 
> [general]
> arch = x86_64
> family = Debian
> name = Debian Stretch
> version = 9.8.0
> platforms = x86_64
> 
> [images-x86_64]
> boot.iso = current/images/netboot/mini.iso
> initrd = current/images/netboot/debian-installer/amd64/initrd.gz
> kernel = current/images/netboot/debian-installer/amd64/linux

Given one can list multiple architectures at one place, shouldn't that
be
  https://deb.debian.org/debian/dists/${release}/main/treeinfo
or
  https://deb.debian.org/debian/dists/${release}/treeinfo

Users shouldn't have to deal with installer-amd64 or such.

"[general]" also seems deprecated (and limited to one arch).

Is there any reason why this should be a hidden file?

Shouldn't such a file be signed in some way?  If for some reason you
only want to trust http(s), the canonical location should probably
*not* be the regular mirror network, but some different place (at which
point anyone could generate these files as well).

Ansgar



Bug#926772: underlinked clang libraries on armel cause build failures

2019-04-11 Thread Adrian Bunk
On Wed, Apr 10, 2019 at 11:12:17AM +0200, Matthias Klose wrote:
> On 10.04.19 10:29, Adrian Bunk wrote:
> > On Wed, Apr 10, 2019 at 10:11:29AM +0200, Matthias Klose wrote:
> >> Package: src:llvm-toolchain-7
> >> Version: 1:7.0.1-8
> >> Severity: serious
> >> Tags: sid buster
> >>
> >> underlinked clang libraries on armel cause build failures, 
> > 
> > Static libraries are not linked.
> 
> ouch
> 
> >> as seen at
> >> https://buildd.debian.org/status/package.php?p=creduce
> >>
> >> /usr/bin/ld:
> >> /usr/lib/llvm-7/lib/libclangFrontend.a(SerializedDiagnosticReader.cpp.o):
> >> undefined reference to symbol '__atomic_load_4@@LIBATOMIC_1.0'
> >> /usr/bin/ld: //usr/lib/arm-linux-gnueabi/libatomic.so.1: error adding 
> >> symbols:
> >> DSO missing from command line
> >> collect2: error: ld returned 1 exit status
> >> make[4]: *** [Makefile:868: clang_delta] Error 1
> >> ...
> > 
> > How does creduce get dependencies for these static libraries from LLVM?
> 
> these are hard coded in clang_delta/Makefile.am.  Is there a better way?  
> Would
> llvm-config --system-libs be a better way to include -latomic on armel?

I don't know what the proper solution would be for this.

A workaround for creduce would be the below patch.

cu
Adrian

--- debian/rules.old2019-04-11 08:58:31.003065232 +
+++ debian/rules2019-04-11 08:59:22.919809159 +
@@ -6,6 +6,10 @@
 
 DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 
+ifneq (,$(filter $(DEB_HOST_ARCH), armel))
+export DEB_LDFLAGS_MAINT_APPEND = -latomic
+endif
+
 CLANG_V= 7
 CLANG  = clang-$(CLANG_V)
 GCC= gcc



Bug#915620: closed by Debian FTP Masters (Bug#915620: Removed package(s) from unstable)

2019-04-11 Thread Paul Gevers
Hi,

On 11-04-2019 17:05, Mattia Rizzolo wrote:
> However, this particular issue was in practice triggered by elbrus that
> wrote the title without considering those words... if he didn't do that,
> there would have been chances that the request would have been ignored
> for a long time (as it has been since December…)

The change was on purpose, as I was under the impression that it could
then be removed as nothing depended on it anymore (I was triggered due
to a removal request from testing). The title didn't get changed back by
anybody after I was told that doko *may* want it in experimental. The
bug was tagged moreinfo at that moment though, which was also the state
when it got removed.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#920759: amdgpu+linux-images 4.9 & 4.19 crash randomly & always after X started

2019-04-11 Thread franckr
Control: retitle -1 amdgpu+linux-images 4.9 & 4.19 crash randomly & always 
after X started
Control: found -1 4.19.28-2~bpo9+1
Control: found -1 4.9.161-1
I wonder why I bought a radeon RX card...



Bug#926813: unblock: python-scipy/1.1.0-6

2019-04-11 Thread Paul Gevers
Hi Drew,

On 11-04-2019 17:49, Drew Parsons wrote:
> On 2019-04-11 23:41, Drew Parsons wrote:
>>
>> The one failure is odd.  It's not in the same class as previous test
>> failures, not a MemoryError.
> ...
>> E   ValueError: `x0` is infeasible with respect to some
>> inequality constraint with `keep_feasible` set to True.
> 
> Upstream noticed it too,
> https://github.com/scipy/scipy/issues/9308
> 
> The randomness of the failure happens because the value is randomly
> generated.
> 
> Apparently fixed with
> https://github.com/scipy/scipy/pull/10046/commits/2d7e7e8c6142e8925c44f92f6839147690880e7d
> 
> 
> It's a small patch. Should we apply it in a python-scipy/1.1.0-7  ?

Yes please.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#917606: ITP: python-deprecated -- Python decorator to deprecate old classes, function, or methods

2019-04-11 Thread Sebastiaan Couwenberg
retitle 917606 ITP: python-deprecated -- Python decorator to deprecate
old classes, function, or methods
owner 917606 !
thanks

On Sat, 29 Dec 2018 08:11:32 +0100 Daniel Stender wrote:
> Like python-deprecation which is already in the archive [1],
> however bloscpack >= 0.16.0 [2] uses this one.

Stetl 2.0 requires this module too, so I've packaged it.

Kind Regards,

Bas

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



Bug#926813: unblock: python-scipy/1.1.0-6

2019-04-11 Thread Drew Parsons

On 2019-04-11 23:41, Drew Parsons wrote:


The one failure is odd.  It's not in the same class as previous test
failures, not a MemoryError.

...

E   ValueError: `x0` is infeasible with respect to some
inequality constraint with `keep_feasible` set to True.


Upstream noticed it too,
https://github.com/scipy/scipy/issues/9308

The randomness of the failure happens because the value is randomly 
generated.


Apparently fixed with 
https://github.com/scipy/scipy/pull/10046/commits/2d7e7e8c6142e8925c44f92f6839147690880e7d


It's a small patch. Should we apply it in a python-scipy/1.1.0-7  ?



Bug#926813: unblock: python-scipy/1.1.0-6

2019-04-11 Thread Drew Parsons

On 2019-04-11 10:54, Drew Parsons wrote:

On 2019-04-11 04:38, Paul Gevers wrote:


The score isn't great (and not all results are in): 3/14 failure (2 in
unstable, 1 in testing so far). Can you please have a look?



Apparently the same test failure does occur in python3 tests, but only
some of the time not all of the time.  Weird.

I've uploaded 1.1.0-6 now to skip the same 2 tests in python3.



1.1.0-6 puts us in the clear with respect to the MemoryError failures.

10/10 test runs passed in unstable

9/10 test runs passed in testing.


The one failure is odd.  It's not in the same class as previous test 
failures, not a MemoryError.


It appears to be a true test failure, failing 
_trustregion_constr.tests.test_canonical_constraint.test_concatenation
in 
/usr/lib/python2.7/dist-packages/scipy/optimize/_trustregion_constr/tests/test_canonical_constraint.py:179 
with


if np.any(f0[mask] < lb[mask]) or np.any(f0[mask] > ub[mask]):

  raise ValueError("`x0` is infeasible with respect to some "
 "inequality constraint with `keep_feasible` 
"

 "set to True.")
E   ValueError: `x0` is infeasible with respect to some 
inequality constraint with `keep_feasible` set to True.




This happens in the atlas tests (atlas provides lapack/blas), which is 
not core scipy as such, since lapack can be provided by openblas.


This particular failure only happened once.



Bug#926873: ITP: pyrundeck -- Python library for the Rundeck REST API

2019-04-11 Thread Benjamin Drung
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: pyrundeck
  Version : 0.9.7
  Upstream Author : Philipp Schmitt 
* URL : https://github.com/pschmitt/pyrundeck
* License : GPL-3
  Programming Lang: Python
  Description : Python library for the Rundeck REST API

Pyrundeck is a library for communicating with Rundeck via a RESTful
(Representational State Transfer) application programming interface
(API).

I will maintian the package in the Python group.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet



Bug#926618: RFP: webext-plasma-integration -- provides integration of web browsers with the Plasma desktop

2019-04-11 Thread Nicholas D Steeves
Found it:  https://tracker.debian.org/pkg/plasma-browser-integration

I wonder if that package fulfills this RFP?  If not, and if this bug
remains inactive for a month, please ping me and I'll take a look.


Bug#926871: Uncaught SyntaxError: Unexpected token export

2019-04-11 Thread Enrico Zini
Package: libjs-popper.js
Version: 1.14.6+ds2-1
Severity: important

Hello,

these toplevel scripts:

/usr/share/javascript/popper.js/popper.js
/usr/share/javascript/popper.js/popper.min.js

contain an export definition that doesn't seem to be standard
JavaScript:

$ tail /usr/share/javascript/popper.js/popper.js
…
export default Popper;

and indeed, using them in a browser raises an exception:

Uncaught SyntaxError: Unexpected token export

Using the umd/ versions work:

/usr/share/javascript/popper.js/umd/popper.js
/usr/share/javascript/popper.js/umd/popper.min.js

I find this to be surprising behaviour, as I'd expect the toplevel
versions to be valid JavaScript, and other fancy things to be in
subdirectories, but I'm happy to stand corrected.


Enrico


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

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

Versions of packages libjs-popper.js depends on:
ii  javascript-common  11

Versions of packages libjs-popper.js recommends:
pn  node-jquery  

libjs-popper.js suggests no packages.

-- no debconf information


Bug#915620: closed by Debian FTP Masters (Bug#915620: Removed package(s) from unstable)

2019-04-11 Thread Mattia Rizzolo
On Thu, Apr 11, 2019 at 11:54:56AM +0100, Jonathan Dowland wrote:
> Currently there's no OpenJDK 1.8 in sid/buster on any architecture and we're 
> in
> hard freeze.  I don't think that was what was intended by the below…
> 
> Matthias Klose wrote:
> > please remove the openjdk-8 binaries on armel mips mipsel mips64el in 
> > unstable.
> ^^

I think Matthias should just learn the syntax of the RM bugs' titles or,
if he doesn't want to learn that, then use reportbug.
However, this particular issue was in practice triggered by elbrus that
wrote the title without considering those words... if he didn't do that,
there would have been chances that the request would have been ignored
for a long time (as it has been since December…)

Anyway, if you need/want the binaires back, you've got to upload them
again…

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#926849: Generate treeinfo files to ease automatic installations

2019-04-11 Thread Bastian Blank
On Thu, Apr 11, 2019 at 11:49:17AM +0200, Guido Günther wrote:
>http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/.treeinfo

Why does it need to exist in this very specific place?  How does the
user know this specific place?

Why not at
http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/.treeinfo,
where it can be supplied by d-i itself?

Regards,
Bastian

-- 
If some day we are defeated, well, war has its fortunes, good and bad.
-- Commander Kor, "Errand of Mercy", stardate 3201.7



Bug#926859: X Server Does Not Start

2019-04-11 Thread Michel Dänzer
On 2019-04-11 1:03 p.m., Toni wrote:
> Package: xserver-xorg
> Version: 1:7.7+19
> Severity: grave
> 
> 
> 
> Hi,
> 
> I am not sure whether this is the correct package to report the bug
> against, since several drivers are involved, and X stopped working for
> every setup simultanously.
> 
> On my laptop with an Optimus graphics, X does no longer start after
> recent upgrades from two days ago until now. The symptom is that the X
> server briefly starts to draw the desktop, but then immediatly exits
> "successfully".

The X server exiting successfully means the problem most likely isn't on
the X server side but on the client side, e.g. the session manager
client disconnects.


> The error messages vary, depending on whether I am loading the nouveau
> driver or not. With the intel driver, I get:
> 
> 
> xf86EnableIOPorts: failed to setIOPL for I/O (Operation not permitted)
> 
> 
> With the nouveau driver, I get:
> 
> 
> Error allocating PGRAPH context for M2MF

These are thus likely red herrings.


-- 
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer



Bug#919484: MR implementing the discussed changes

2019-04-11 Thread Christian Ehrhardt
Thanks for the feedback,
I have followed your preferences and tried to clear all of dh_missing
based on that.

We might instead ignore the doc changes, but take a look first.
I build in unstable from debian/experimental and it seems much better now.

I have opened a new MR for that at
https://salsa.debian.org/libvirt-team/libvirt/merge_requests/15

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd



Bug#922654: debian-policy: Section 9.1.2 points to a wrong FHS section?

2019-04-11 Thread Linda Lapinlampi
On Tue, Apr 09, 2019 at 10:21:29AM -0700, Sean Whitton wrote:
> On Mon 08 Apr 2019 at 11:13PM +00, Linda Lapinlampi wrote:
> 
> > I'm attaching a patch, seems trivial. Here's the word-diff=plain to
> > resolve typos. Hoping this is okay to merge as is, but more feedback is
> > welcome.
> 
> Thanks, applied.

Just fyi: The debian/changelog file references section 9.11 incorrectly
for UNRELEASED 4.3.0.4 version; the section should be 9.1.1. The commit
has it correct.



Bug#922654: debian-policy: Section 9.1.2 points to a wrong FHS section?

2019-04-11 Thread Linda Lapinlampi
On Thu, Apr 11, 2019 at 02:35:26PM +, Linda Lapinlampi wrote:
> Just fyi: The debian/changelog file references section 9.11 incorrectly
> for UNRELEASED 4.3.0.4 version; the section should be 9.1.1. The commit
> has it correct.

Actually, I think I was meant to say 9.1.2 for the changelog.



  1   2   >